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.400
Esses projetos ágeis
promovem entregas mais rápidas,

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

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

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

00:01:19.412 --> 00:01:22.415
Um processo ágil
de desenvolvimento de software

00:01:22.548 --> 00:01:26.119
tem como ponto central
a entrega dele funcionando,

00:01:26.185 --> 00:01:28.921
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:34.761
Com isso, o escopo dos stakeholders

00:01:34.761 --> 00:01:39.565
pode ser ajustado ao longo do projeto,
conforme a necessidade, Claro.

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

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

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

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

00:01:57.050 --> 00:02:00.453
para que a próxima comece
na fase de análise.

00:02:00.520 --> 00:02:03.756
Fazemos a coleta
e a organização dos requisitos

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

00:02:08.227 --> 00:02:09.429
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.768
essas atividades de coleta
e organização de requisitos

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

00:02:19.839 --> 00:02:22.809
Outra característica
importante do processo ágil

00:02:22.875 --> 00:02:26.479
é que ele ocorre em ciclos ou espirais.

00:02:26.546 --> 00:02:30.950
Em cada espiral, os requisitos
são revistos e complementados

00:02:31.017 --> 00:02:32.819
se houver necessidade.

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

00:02:37.924 --> 00:02:42.361
O incremento da solução é construído,
testado e entregue para uso.

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

00:02:46.899 --> 00:02:49.735
O ponto de partida
é uma lista de requisitos

00:02:49.735 --> 00:02:53.539
que o software precisa
atender, ou seja, o backlog do produto.

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

00:02:57.743 --> 00:03:02.215
e entrega dentro de um ciclo de trabalho
conhecido como Sprint.

00:03:02.315 --> 00:03:06.586
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.526
onde cada uma implementa
uma parte da relação dos requisitos

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

00:03:18.097 --> 00:03:21.734
Comentamos mais de uma vez
que essa lista de requisitos

00:03:21.801 --> 00:03:24.804
deve ser anotada e classificada.

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

00:03:28.207 --> 00:03:32.378
mas ao final desse processo
devemos ter necessário em mente

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

00:03:36.949 --> 00:03:40.553
Os requisitos funcionais
são aqueles que se relacionam

00:03:40.553 --> 00:03:45.925
com uma funcionalidade, ou seja,
um serviço que o software deve fornecer.

00:03:46.025 --> 00:03:47.193
Por meio deles.

00:03:47.193 --> 00:03:52.264
Entendermos quais dados o sistema deve
guardar, recuperar e apresentar,

00:03:52.331 --> 00:03:56.469
quais transações devem acontecer,
como devem ser as interações

00:03:56.469 --> 00:04:01.407
com os usuários, 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.