WEBVTT

00:00:07.694 --> 00:00:10.360
Antes de entrar
no universo dos requisitos,

00:00:10.360 --> 00:00:13.974
vamos entender um pouco o contexto
de um projeto de software

00:00:13.974 --> 00:00:16.872
e como os requisitos
se encaixam nesse processo.

00:00:16.872 --> 00:00:19.868
Quando iniciamos o processo
de construção de um software,

00:00:19.868 --> 00:00:24.307
precisamos levantar todas as características
que as partes interessadas,

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

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

00:00:32.626 --> 00:00:35.618
por exemplo, uma tela
com um layout específico,

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

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

00:00:42.719 --> 00:00:44.965
em um intervalo mínimo de tempo.

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

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

00:00:53.724 --> 00:00:57.962
Atualmente, a comunidade de software,
formada pelos que produzem

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

00:01:03.129 --> 00:01:07.297
Esses projetos ágeis promovem
entregas mais rápidas,

00:01:07.297 --> 00:01:10.977
sejam entregas completas
ou entregas parciais.

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

00:01:15.925 --> 00:01:19.087
mesmo antes do projeto
ser totalmente concluído.

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

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

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

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

00:01:37.378 --> 00:01:39.489
conforme a necessidade, é claro.

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

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

00:01:48.955 --> 00:01:52.388
O modelo cascata é
composto por fases fixas,

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

00:01:56.870 --> 00:01:59.009
para que a próxima comece.

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

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

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

00:02:12.248 --> 00:02:15.718
essas atividades de coleta
e organização de requisitos

00:02:15.718 --> 00:02:19.719
podem acontecer repetidamente
em qualquer momento do projeto.

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

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

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

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

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

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

00:02:51.266 --> 00:02:53.469
ou seja, o backlog do produto.

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

00:02:58.415 --> 00:03:02.278
dentro de um ciclo de trabalho
conhecido como Sprint.

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

00:03:06.498 --> 00:03:09.242
O projeto é composto
por várias Sprints,

00:03:09.242 --> 00:03:13.426
onde cada uma implementa
uma parte da relação dos requisitos,

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

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

00:03:24.777 --> 00:03:28.027
Podemos classificar os requisitos
de diversas maneiras,

00:03:28.027 --> 00:03:32.235
mas, ao final desse processo,
devemos ter, necessariamente,

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

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

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

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

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

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

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

00:04:01.169 --> 00:04:03.844
Já os requisitos não funcionais

00:04:03.844 --> 00:04:08.604
recebem esse nome por serem
de natureza oposta aos funcionais.

00:04:08.604 --> 00:04:12.919
São os que se relacionam à performance,
a aspectos de interface

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

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

00:04:19.464 --> 00:04:25.127
Vale ressaltar que o conjunto dos requisitos
funcionais e não funcionais de um sistema

00:04:25.127 --> 00:04:28.357
é conhecido como requisitos
de software.

00:04:28.357 --> 00:04:30.105
Conhecendo esses requisitos,

00:04:30.105 --> 00:04:36.048
podemos delimitar o escopo do software a ser
construído, planejar o seu desenvolvimento

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

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

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