WEBVTT

00:00:07.907 --> 00:00:10.510
Antes de entrar
no universo dos requisitos,

00:00:10.510 --> 00:00:14.114
vamos entender um pouco o contexto
de um projeto de software

00:00:14.114 --> 00:00:16.916
e como os requisitos
se encaixam nesse processo.

00:00:16.916 --> 00:00:20.178
Quando iniciamos o processo
de construção de um software,

00:00:20.178 --> 00:00:24.457
precisamos levantar todas as características
que as partes interessadas,

00:00:24.457 --> 00:00:28.561
também conhecidas como stakeholders,
desejam que esse software tenha.

00:00:28.561 --> 00:00:32.766
Todas essas solicitações podem
ser de naturezas bem diferentes,

00:00:32.766 --> 00:00:35.768
por exemplo, uma tela
com um layout específico,

00:00:35.768 --> 00:00:38.939
um relatório que contém informações
de vários departamentos

00:00:38.939 --> 00:00:42.909
ou até mesmo a necessidade
de que uma determinada transação ocorra

00:00:42.909 --> 00:00:45.145
em um intervalo mínimo de tempo.

00:00:45.145 --> 00:00:49.916
Fica claro que precisamos anotar todos
esses desejos de modo organizado,

00:00:49.916 --> 00:00:53.887
já que eles serão o ponto de partida
para o projeto do nosso software.

00:00:53.887 --> 00:00:58.002
Atualmente, a comunidade de software,
formada pelos que produzem

00:00:58.002 --> 00:01:03.329
e pelos que consomem software, atua
com o paradigma dos projetos ágeis.

00:01:03.329 --> 00:01:07.467
Esses projetos ágeis promovem
entregas mais rápidas,

00:01:07.467 --> 00:01:11.137
sejam entregas completas
ou entregas parciais.

00:01:11.137 --> 00:01:16.075
Já essas entregas permitem que os usuários
aproveitem o valor do software

00:01:16.075 --> 00:01:19.412
mesmo antes do projeto
ser totalmente concluído.

00:01:19.412 --> 00:01:23.920
Um processo ágil de desenvolvimento
de software tem como ponto central

00:01:23.920 --> 00:01:28.921
a entrega dele funcionando, empregando
menos esforço em atividades

00:01:28.921 --> 00:01:31.758
que não sejam a sua
construção em si.

00:01:31.758 --> 00:01:37.238
Com isso, o escopo dos stakeholders
pode ser ajustado ao longo do projeto,

00:01:37.238 --> 00:01:39.666
conforme a necessidade, é claro.

00:01:39.666 --> 00:01:44.370
Agora que entendemos melhor esse processo
ágil do desenvolvimento de software,

00:01:44.370 --> 00:01:49.042
vamos revisitar brevemente o processo
clássico, o modelo cascata.

00:01:49.042 --> 00:01:52.578
O modelo cascata é
composto por fases fixas,

00:01:52.578 --> 00:01:57.050
onde todas as atividades de uma fase
devem ser completamente finalizadas

00:01:57.050 --> 00:01:59.189
para que a próxima comece.

00:01:59.189 --> 00:02:03.823
Na fase de análise, fazemos a coleta
e a organização dos requisitos

00:02:03.823 --> 00:02:09.429
e, quando finalizada, o modelo não prevê
a repetição dessas atividades durante o projeto.

00:02:09.429 --> 00:02:12.398
Para efeito de comparação,
no processo ágil,

00:02:12.398 --> 00:02:15.868
essas atividades de coleta
e organização de requisitos

00:02:15.868 --> 00:02:19.839
podem acontecer repetidamente
em qualquer momento do projeto.

00:02:19.839 --> 00:02:26.546
Outra característica importante do processo
ágil é que ele ocorre em ciclos ou espirais.

00:02:26.546 --> 00:02:32.819
Em cada espiral, os requisitos são revistos
e complementados se houver necessidade.

00:02:32.819 --> 00:02:36.902
Além disso, as especificações
técnicas são modeladas.

00:02:36.902 --> 00:02:42.428
Assim, o incremento da solução é
construído, testado e entregue para uso.

00:02:42.428 --> 00:02:46.899
Um exemplo que ilustra o processo ágil
com ciclos de entrega é o Scrum.

00:02:46.899 --> 00:02:51.386
O ponto de partida é uma lista de requisitos
que o software precisa atender,

00:02:51.386 --> 00:02:53.639
ou seja, o backlog do produto.

00:02:53.639 --> 00:02:58.445
A partir dele, são criadas atividades
de modelagem, construção e entrega

00:02:58.445 --> 00:03:02.315
dentro de um ciclo de trabalho
conhecido como Sprint.

00:03:02.315 --> 00:03:06.652
Ao fim desse ciclo, se espera a entrega
de uma parte do software para o cliente.

00:03:06.652 --> 00:03:09.422
O projeto é composto
por várias sprints,

00:03:09.422 --> 00:03:13.626
onde cada uma implementa
uma parte da relação dos requisitos

00:03:13.626 --> 00:03:18.097
e os ajustes do backlog do produto
podem ocorrer em qualquer momento.

00:03:18.097 --> 00:03:24.937
Comentamos mais de uma vez que essa lista
de requisitos deve ser anotada e classificada.

00:03:24.937 --> 00:03:28.207
Podemos classificar os requisitos
de diversas maneiras,

00:03:28.207 --> 00:03:32.445
mas, ao final desse processo,
devemos ter necessariamente

00:03:32.445 --> 00:03:36.949
dois tipos de requisitos:
os funcionais e os não funcionais.

00:03:36.949 --> 00:03:41.969
Os requisitos funcionais são aqueles
que se relacionam com uma funcionalidade,

00:03:41.969 --> 00:03:46.025
ou seja, um serviço
que o software deve fornecer.

00:03:46.025 --> 00:03:50.236
Por meio deles, entendemos quais
dados o sistema deve guardar,

00:03:50.236 --> 00:03:54.566
recuperar e apresentar, quais
transações devem acontecer,

00:03:54.566 --> 00:03:57.581
como devem ser as interações
com os usuários,

00:03:57.581 --> 00:04:01.507
atendendo, é claro, as regras
de negócio envolvidas.

00:04:01.507 --> 00:04:05.077
Já os requisitos não funcionais
recebem este nome

00:04:05.077 --> 00:04:08.748
por serem de natureza
oposta aos funcionais.

00:04:08.814 --> 00:04:13.119
São os que se relacionam à performance,
aspecto de interface

00:04:13.119 --> 00:04:16.956
e usabilidade do software
e condições de segurança.

00:04:17.022 --> 00:04:19.658
Eles envolvem a solução como um todo.

00:04:19.658 --> 00:04:23.295
Vale ressaltar
que o conjunto dos requisitos funcionais

00:04:23.295 --> 00:04:28.467
e não funcionais de um sistema
é conhecido como requisitos de software.

00:04:28.567 --> 00:04:32.738
Conhecendo esses requisitos,
podemos delimitar o escopo do software

00:04:32.738 --> 00:04:36.208
a ser construído,
planejar o seu desenvolvimento

00:04:36.308 --> 00:04:41.747
e ter bases para estimar qual o custo
e o tempo envolvidos em sua construção.

00:04:41.847 --> 00:04:46.285
Pronto, agora você já compreende
o contexto de um projeto de software

00:04:46.385 --> 00:04:49.255
e como ele serve de plano
de fundo para os requisitos.