1
00:00:07,907 --> 00:00:10,510
Antes de entrar
no universo dos requisitos,

2
00:00:10,510 --> 00:00:14,114
vamos entender um pouco o contexto
de um projeto de software

3
00:00:14,114 --> 00:00:16,916
e como os requisitos
se encaixam nesse processo.

4
00:00:16,916 --> 00:00:20,178
Quando iniciamos o processo
de construção de um software,

5
00:00:20,178 --> 00:00:24,457
precisamos levantar todas as características
que as partes interessadas,

6
00:00:24,457 --> 00:00:28,561
também conhecidas como stakeholders,
desejam que esse software tenha.

7
00:00:28,561 --> 00:00:32,766
Todas essas solicitações podem
ser de naturezas bem diferentes,

8
00:00:32,766 --> 00:00:35,768
por exemplo, uma tela
com um layout específico,

9
00:00:35,768 --> 00:00:38,939
um relatório que contém informações
de vários departamentos

10
00:00:38,939 --> 00:00:42,909
ou até mesmo a necessidade
de que uma determinada transação ocorra

11
00:00:42,909 --> 00:00:45,145
em um intervalo mínimo de tempo.

12
00:00:45,145 --> 00:00:49,916
Fica claro que precisamos anotar todos
esses desejos de modo organizado,

13
00:00:49,916 --> 00:00:53,887
já que eles serão o ponto de partida
para o projeto do nosso software.

14
00:00:53,887 --> 00:00:58,002
Atualmente, a comunidade de software,
formada pelos que produzem

15
00:00:58,002 --> 00:01:03,329
e pelos que consomem software, atua
com o paradigma dos projetos ágeis.

16
00:01:03,329 --> 00:01:07,467
Esses projetos ágeis promovem
entregas mais rápidas,

17
00:01:07,467 --> 00:01:11,137
sejam entregas completas
ou entregas parciais.

18
00:01:11,137 --> 00:01:16,075
Já essas entregas permitem que os usuários
aproveitem o valor do software

19
00:01:16,075 --> 00:01:19,412
mesmo antes do projeto
ser totalmente concluído.

20
00:01:19,412 --> 00:01:23,920
Um processo ágil de desenvolvimento
de software tem como ponto central

21
00:01:23,920 --> 00:01:28,921
a entrega dele funcionando, empregando
menos esforço em atividades

22
00:01:28,921 --> 00:01:31,758
que não sejam a sua
construção em si.

23
00:01:31,758 --> 00:01:37,238
Com isso, o escopo dos stakeholders
pode ser ajustado ao longo do projeto,

24
00:01:37,238 --> 00:01:39,666
conforme a necessidade, é claro.

25
00:01:39,666 --> 00:01:44,370
Agora que entendemos melhor esse processo
ágil do desenvolvimento de software,

26
00:01:44,370 --> 00:01:49,042
vamos revisitar brevemente o processo
clássico, o modelo cascata.

27
00:01:49,042 --> 00:01:52,578
O modelo cascata é
composto por fases fixas,

28
00:01:52,578 --> 00:01:57,050
onde todas as atividades de uma fase
devem ser completamente finalizadas

29
00:01:57,050 --> 00:01:59,189
para que a próxima comece.

30
00:01:59,189 --> 00:02:03,823
Na fase de análise, fazemos a coleta
e a organização dos requisitos

31
00:02:03,823 --> 00:02:09,429
e, quando finalizada, o modelo não prevê
a repetição dessas atividades durante o projeto.

32
00:02:09,429 --> 00:02:12,398
Para efeito de comparação,
no processo ágil,

33
00:02:12,398 --> 00:02:15,868
essas atividades de coleta
e organização de requisitos

34
00:02:15,868 --> 00:02:19,839
podem acontecer repetidamente
em qualquer momento do projeto.

35
00:02:19,839 --> 00:02:26,546
Outra característica importante do processo
ágil é que ele ocorre em ciclos ou espirais.

36
00:02:26,546 --> 00:02:32,819
Em cada espiral, os requisitos são revistos
e complementados se houver necessidade.

37
00:02:32,819 --> 00:02:36,902
Além disso, as especificações
técnicas são modeladas.

38
00:02:36,902 --> 00:02:42,428
Assim, o incremento da solução é
construído, testado e entregue para uso.

39
00:02:42,428 --> 00:02:46,899
Um exemplo que ilustra o processo ágil
com ciclos de entrega é o Scrum.

40
00:02:46,899 --> 00:02:51,386
O ponto de partida é uma lista de requisitos
que o software precisa atender,

41
00:02:51,386 --> 00:02:53,639
ou seja, o backlog do produto.

42
00:02:53,639 --> 00:02:57,743
A partir dele, são criadas
atividades de modelagem, construção

43
00:02:57,743 --> 00:03:02,215
e entrega dentro de um ciclo de trabalho
conhecido como Sprint.

44
00:03:02,315 --> 00:03:06,586
Ao fim desse ciclo se espera a entrega
de uma parte do software para o cliente.

45
00:03:06,652 --> 00:03:09,422
O projeto é composto por várias sprints,

46
00:03:09,422 --> 00:03:13,526
onde cada uma implementa
uma parte da relação dos requisitos

47
00:03:13,626 --> 00:03:17,997
e os ajustes do backlog do produto
podem ocorrer em qualquer momento.

48
00:03:18,097 --> 00:03:21,734
Comentamos mais de uma vez
que essa lista de requisitos

49
00:03:21,801 --> 00:03:24,804
deve ser anotada e classificada.

50
00:03:24,937 --> 00:03:28,140
Podemos classificar os requisitos
de diversas maneiras,

51
00:03:28,207 --> 00:03:32,378
mas ao final desse processo
devemos ter necessário em mente

52
00:03:32,445 --> 00:03:36,749
dois tipos de requisitos
os funcionais e os não funcionais.

53
00:03:36,949 --> 00:03:40,553
Os requisitos funcionais
são aqueles que se relacionam

54
00:03:40,553 --> 00:03:45,925
com uma funcionalidade, ou seja,
um serviço que o software deve fornecer.

55
00:03:46,025 --> 00:03:47,193
Por meio deles.

56
00:03:47,193 --> 00:03:52,264
Entendermos quais dados o sistema deve
guardar, recuperar e apresentar,

57
00:03:52,331 --> 00:03:56,469
quais transações devem acontecer,
como devem ser as interações

58
00:03:56,469 --> 00:04:01,407
com os usuários, atendendo, é claro,
as regras de negócio envolvidas.

59
00:04:01,507 --> 00:04:05,077
Já os requisitos não funcionais
recebem este nome

60
00:04:05,077 --> 00:04:08,748
por serem de natureza
oposta aos funcionais.

61
00:04:08,814 --> 00:04:13,119
São os que se relacionam à performance,
aspecto de interface

62
00:04:13,119 --> 00:04:16,956
e usabilidade do software
e condições de segurança.

63
00:04:17,022 --> 00:04:19,658
Eles envolvem a solução como um todo.

64
00:04:19,658 --> 00:04:23,295
Vale ressaltar
que o conjunto dos requisitos funcionais

65
00:04:23,295 --> 00:04:28,467
e não funcionais de um sistema
é conhecido como requisitos de software.

66
00:04:28,567 --> 00:04:32,738
Conhecendo esses requisitos,
podemos delimitar o escopo do software

67
00:04:32,738 --> 00:04:36,208
a ser construído,
planejar o seu desenvolvimento

68
00:04:36,308 --> 00:04:41,747
e ter bases para estimar qual o custo
e o tempo envolvidos em sua construção.

69
00:04:41,847 --> 00:04:46,285
Pronto, agora você já compreende
o contexto de um projeto de software

70
00:04:46,385 --> 00:04:49,255
e como ele serve de plano
de fundo para os requisitos.