0:00:07.907,0:00:10.510
Antes de entrar[br]no universo dos requisitos,

0:00:10.510,0:00:14.114
vamos entender um pouco o contexto[br]de um projeto de software

0:00:14.114,0:00:16.916
e como os requisitos[br]se encaixam nesse processo.

0:00:16.916,0:00:20.178
Quando iniciamos o processo[br]de construção de um software,

0:00:20.178,0:00:24.457
precisamos levantar todas as características[br]que as partes interessadas,

0:00:24.457,0:00:28.561
também conhecidas como stakeholders,[br]desejam que esse software tenha.

0:00:28.561,0:00:32.766
Todas essas solicitações podem[br]ser de naturezas bem diferentes,

0:00:32.766,0:00:35.768
por exemplo, uma tela[br]com um layout específico,

0:00:35.768,0:00:38.939
um relatório que contém informações[br]de vários departamentos

0:00:38.939,0:00:42.909
ou até mesmo a necessidade[br]de que uma determinada transação ocorra

0:00:42.909,0:00:45.145
em um intervalo mínimo de tempo.

0:00:45.145,0:00:49.916
Fica claro que precisamos anotar todos[br]esses desejos de modo organizado,

0:00:49.916,0:00:53.887
já que eles serão o ponto de partida[br]para o projeto do nosso software.

0:00:53.887,0:00:58.002
Atualmente, a comunidade de software,[br]formada pelos que produzem

0:00:58.002,0:01:03.329
e pelos que consomem software, atua[br]com o paradigma dos projetos ágeis.

0:01:03.329,0:01:07.467
Esses projetos ágeis promovem[br]entregas mais rápidas,

0:01:07.467,0:01:11.137
sejam entregas completas[br]ou entregas parciais.

0:01:11.137,0:01:16.075
Já essas entregas permitem que os usuários[br]aproveitem o valor do software

0:01:16.075,0:01:19.412
mesmo antes do projeto[br]ser totalmente concluído.

0:01:19.412,0:01:23.920
Um processo ágil de desenvolvimento[br]de software tem como ponto central

0:01:23.920,0:01:28.921
a entrega dele funcionando, empregando[br]menos esforço em atividades

0:01:28.921,0:01:31.758
que não sejam a sua[br]construção em si.

0:01:31.758,0:01:37.238
Com isso, o escopo dos stakeholders[br]pode ser ajustado ao longo do projeto,

0:01:37.238,0:01:39.666
conforme a necessidade, é claro.

0:01:39.666,0:01:44.370
Agora que entendemos melhor esse processo[br]ágil do desenvolvimento de software,

0:01:44.370,0:01:49.042
vamos revisitar brevemente o processo[br]clássico, o modelo cascata.

0:01:49.042,0:01:52.578
O modelo cascata é[br]composto por fases fixas,

0:01:52.578,0:01:57.050
onde todas as atividades de uma fase[br]devem ser completamente finalizadas

0:01:57.050,0:01:59.189
para que a próxima comece.

0:01:59.189,0:02:03.823
Na fase de análise, fazemos a coleta[br]e a organização dos requisitos

0:02:03.823,0:02:09.429
e, quando finalizada, o modelo não prevê[br]a repetição dessas atividades durante o projeto.

0:02:09.429,0:02:12.398
Para efeito de comparação,[br]no processo ágil,

0:02:12.398,0:02:15.868
essas atividades de coleta[br]e organização de requisitos

0:02:15.868,0:02:19.839
podem acontecer repetidamente[br]em qualquer momento do projeto.

0:02:19.839,0:02:26.546
Outra característica importante do processo[br]ágil é que ele ocorre em ciclos ou espirais.

0:02:26.546,0:02:32.819
Em cada espiral, os requisitos são revistos[br]e complementados se houver necessidade.

0:02:32.819,0:02:36.902
Além disso, as especificações[br]técnicas são modeladas.

0:02:36.902,0:02:42.428
Assim, o incremento da solução é[br]construído, testado e entregue para uso.

0:02:42.428,0:02:46.899
Um exemplo que ilustra o processo ágil[br]com ciclos de entrega é o Scrum.

0:02:46.899,0:02:51.386
O ponto de partida é uma lista de requisitos[br]que o software precisa atender,

0:02:51.386,0:02:53.639
ou seja, o backlog do produto.

0:02:53.639,0:02:57.743
A partir dele, são criadas[br]atividades de modelagem, construção

0:02:57.743,0:03:02.215
e entrega dentro de um ciclo de trabalho[br]conhecido como Sprint.

0:03:02.315,0:03:06.586
Ao fim desse ciclo se espera a entrega[br]de uma parte do software para o cliente.

0:03:06.652,0:03:09.422
O projeto é composto por várias sprints,

0:03:09.422,0:03:13.526
onde cada uma implementa[br]uma parte da relação dos requisitos

0:03:13.626,0:03:17.997
e os ajustes do backlog do produto[br]podem ocorrer em qualquer momento.

0:03:18.097,0:03:21.734
Comentamos mais de uma vez[br]que essa lista de requisitos

0:03:21.801,0:03:24.804
deve ser anotada e classificada.

0:03:24.937,0:03:28.140
Podemos classificar os requisitos[br]de diversas maneiras,

0:03:28.207,0:03:32.378
mas ao final desse processo[br]devemos ter necessário em mente

0:03:32.445,0:03:36.749
dois tipos de requisitos[br]os funcionais e os não funcionais.

0:03:36.949,0:03:40.553
Os requisitos funcionais[br]são aqueles que se relacionam

0:03:40.553,0:03:45.925
com uma funcionalidade, ou seja,[br]um serviço que o software deve fornecer.

0:03:46.025,0:03:47.193
Por meio deles.

0:03:47.193,0:03:52.264
Entendermos quais dados o sistema deve[br]guardar, recuperar e apresentar,

0:03:52.331,0:03:56.469
quais transações devem acontecer,[br]como devem ser as interações

0:03:56.469,0:04:01.407
com os usuários, atendendo, é claro,[br]as regras de negócio envolvidas.

0:04:01.507,0:04:05.077
Já os requisitos não funcionais[br]recebem este nome

0:04:05.077,0:04:08.748
por serem de natureza[br]oposta aos funcionais.

0:04:08.814,0:04:13.119
São os que se relacionam à performance,[br]aspecto de interface

0:04:13.119,0:04:16.956
e usabilidade do software[br]e condições de segurança.

0:04:17.022,0:04:19.658
Eles envolvem a solução como um todo.

0:04:19.658,0:04:23.295
Vale ressaltar[br]que o conjunto dos requisitos funcionais

0:04:23.295,0:04:28.467
e não funcionais de um sistema[br]é conhecido como requisitos de software.

0:04:28.567,0:04:32.738
Conhecendo esses requisitos,[br]podemos delimitar o escopo do software

0:04:32.738,0:04:36.208
a ser construído,[br]planejar o seu desenvolvimento

0:04:36.308,0:04:41.747
e ter bases para estimar qual o custo[br]e o tempo envolvidos em sua construção.

0:04:41.847,0:04:46.285
Pronto, agora você já compreende[br]o contexto de um projeto de software

0:04:46.385,0:04:49.255
e como ele serve de plano[br]de fundo para os requisitos.