0:00:07.694,0:00:10.360
Antes de entrar[br]no universo dos requisitos,

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

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

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

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

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

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

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

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

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

0:00:42.719,0:00:44.965
em um intervalo mínimo de tempo.

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

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

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

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

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

0:01:07.297,0:01:10.977
sejam entregas completas[br]ou entregas parciais.

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

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

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

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

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

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

0:01:37.378,0:01:39.489
conforme a necessidade, é claro.

0:01:39.489,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:58.445
A partir dele, são criadas atividades[br]de modelagem, construção e entrega

0:02:58.445,0:03:02.315
dentro de um ciclo de trabalho[br]conhecido como Sprint.

0:03:02.315,0:03:06.652
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[br]por várias sprints,

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

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

0:03:18.097,0:03:24.937
Comentamos mais de uma vez que essa lista[br]de requisitos deve ser anotada e classificada.

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

0:03:28.207,0:03:32.445
mas, ao final desse processo,[br]devemos ter necessariamente

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

0:03:36.949,0:03:41.969
Os requisitos funcionais são aqueles[br]que se relacionam com uma funcionalidade,

0:03:41.969,0:03:46.025
ou seja, um serviço[br]que o software deve fornecer.

0:03:46.025,0:03:50.236
Por meio deles, entendemos quais[br]dados o sistema deve guardar,

0:03:50.236,0:03:54.566
recuperar e apresentar, quais[br]transações devem acontecer,

0:03:54.566,0:03:57.581
como devem ser as interações[br]com os usuários,

0:03:57.581,0:04:01.507
atendendo, é claro, as regras[br]de negócio envolvidas.

0:04:01.507,0:04:03.694
Já os requisitos não funcionais

0:04:03.694,0:04:08.814
recebem esse nome por serem[br]de natureza oposta aos funcionais.

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

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

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

0:04:19.658,0:04:25.127
Vale ressaltar que o conjunto dos requisitos[br]funcionais e não funcionais de um sistema

0:04:25.127,0:04:28.567
é conhecido como requisitos[br]de software.

0:04:28.567,0:04:30.125
Conhecendo esses requisitos,

0:04:30.125,0:04:36.308
podemos delimitar o escopo do software a ser[br]construído, planejar o seu desenvolvimento

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

0:04:41.847,0:04:46.385
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.