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:58,445
A partir dele, são criadas atividades
de modelagem, construção e entrega

43
00:02:58,445 --> 00:03:02,315
dentro de um ciclo de trabalho
conhecido como Sprint.

44
00:03:02,315 --> 00:03:06,652
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,626
onde cada uma implementa
uma parte da relação dos requisitos

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

48
00:03:18,097 --> 00:03:24,937
Comentamos mais de uma vez que essa lista
de requisitos deve ser anotada e classificada.

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

50
00:03:28,207 --> 00:03:32,445
mas, ao final desse processo,
devemos ter necessariamente

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

52
00:03:36,949 --> 00:03:41,969
Os requisitos funcionais são aqueles
que se relacionam com uma funcionalidade,

53
00:03:41,969 --> 00:03:46,025
ou seja, um serviço
que o software deve fornecer.

54
00:03:46,025 --> 00:03:50,236
Por meio deles, entendemos quais
dados o sistema deve guardar,

55
00:03:50,236 --> 00:03:54,566
recuperar e apresentar, quais
transações devem acontecer,

56
00:03:54,566 --> 00:03:57,581
como devem ser as interações
com os usuários,

57
00:03:57,581 --> 00:04:01,507
atendendo, é claro, as regras
de negócio envolvidas.

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

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

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

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

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

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

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

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

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

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

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

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