WEBVTT

00:00:08.308 --> 00:00:11.311
Durante todo
o processo de desenvolvimento de software.

00:00:11.544 --> 00:00:15.048
A qualidade é algo que deve estar presente
em todos os momentos.

00:00:15.148 --> 00:00:19.052
E em relação aos requisitos,
isso não é diferente.

00:00:19.119 --> 00:00:23.089
Podemos estabelecer a seguinte
relação entre qualidade e requisitos.

00:00:23.189 --> 00:00:26.993
Qualidade
é estar em conformidade com os requisitos.

00:00:27.093 --> 00:00:30.997
A especificação de requisitos
funcionando como um artefato base

00:00:30.997 --> 00:00:34.801
para expressar claramente
os requisitos e as suas tratativas.

00:00:34.868 --> 00:00:39.939
Precisa ter algumas características
para poder refletir a qualidade.

00:00:40.006 --> 00:00:42.208
A primeira delas é a correção.

00:00:42.208 --> 00:00:45.211
Uma especificação é considerada correta

00:00:45.245 --> 00:00:50.016
se cada requisito é essencial
para o desenvolvimento do software.

00:00:50.083 --> 00:00:51.818
Temos também a precisão.

00:00:51.818 --> 00:00:55.021
Uma especificação é precisa
quando todos entendem

00:00:55.021 --> 00:00:57.690
os requisitos da mesma forma.

00:00:57.690 --> 00:01:00.093
Além dela, temos a completude.

00:01:00.093 --> 00:01:04.631
Uma aplicação é considerada completa
se abranger todos requisitos

00:01:04.631 --> 00:01:09.135
em relação a funcionalidade,
desempenho e restrições.

00:01:09.202 --> 00:01:10.436
E não para por aí.

00:01:10.436 --> 00:01:12.472
Vamos falar de consistência.

00:01:12.472 --> 00:01:17.043
Uma especificação é consistente
se um requisito não entrar em conflito

00:01:17.043 --> 00:01:18.478
com o outro.

00:01:18.478 --> 00:01:21.981
Já na priorização,
os requisitos devem ser priorizados

00:01:21.981 --> 00:01:26.185
conforme sua importância
e possibilidade de alteração

00:01:26.286 --> 00:01:27.720
na verificação.

00:01:27.720 --> 00:01:32.292
Uma especificação deve refletir
por meio de um processo de verificação,

00:01:32.358 --> 00:01:35.361
o que foi implementado no software.

00:01:35.361 --> 00:01:38.631
Não podemos esquecer da modificação aqui.

00:01:38.731 --> 00:01:42.001
Não devemos encontrar redundâncias
na especificação,

00:01:42.068 --> 00:01:46.739
sendo possível alterá la de modo
fácil, completo e consistente.

00:01:46.839 --> 00:01:49.809
E por fim, nós temos a rastreabilidade.

00:01:49.976 --> 00:01:54.180
Uma especificação
deve permitir a localização da origem

00:01:54.280 --> 00:01:59.085
e quais são os resultados
ou consequências dos requisitos.

00:01:59.152 --> 00:02:01.687
Quando não observamos as características

00:02:01.687 --> 00:02:04.924
que entregam qualidade
em uma especificação de requisitos,

00:02:04.991 --> 00:02:08.361
estamos contribuindo
para um sistema de baixa qualidade

00:02:08.461 --> 00:02:11.030
e este definitivamente não é o caminho.