1. REQUISITOS FUNCIONAIS
E NÃO FUNCIONAIS.
OUTRAS CLASSIFICAÇÕES.
P R O F. : M A R C O S M O R A I S
M A R C O S M O R A I S D E S O U S A @ G M A I L . C O M

2. EXEMPLO DE REQUISITO
O problema da pedra...
Me traz uma pedra?
Pequena?
Parece de vidro!

3. Ela é azul!
Parece uma bola!

4. O QUE VIMOS NESSA CONVERSA?
A criança quer uma coisa;
A criança não sabe exatamente o que é essa coisa;
O pai interpreta o pedido da criança;
O pai tenta trazer o pedido da forma mais exata possível.

5. E NO MUNDO DO SOFTWARE?
Acontece da mesma forma;
O usuário tem desejos;
Esse desejo precisa ser bem descrito.

6. MAS, O QUE É UM REQUISITO?
Requisito (Padrão IEEE)
É uma sentença identificando uma capacidade, uma
característica física ou um fator de qualidade que
limita um produto ou um processo.

7. EXEMPLOS DE REQUISITOS
O sistema deverá permitir a busca do preço de um produto
dado o código de barra.
O sistema deverá emitir o histórico escolar de cada aluno.

8. QUAL O SEGREDO?
Para atender o usuário é preciso definir os verdadeiros requisitos de
software;

9. CATEGORIAS DE REQUISITOS
Requisitos que devem ser totalmente satisfeitos;
Requisitos que são altamente desejáveis;
Requisitos possíveis.

10. TIPOS DE REQUISITOS
Software
Sistema
Usuário

11. REQUISITO DE USUÁRIO
É algum comportamento ou característica que o usuário deseja do
software;
O que o usuário quer;
São escritos pelo próprio usuário ou levados por um engenheiro de
requisitos.

12. REQUISITOS DO SISTEMA
É algum comportamento ou característica exigido do sistema como um
todo, incluindo hardware e software;
O comportamento desejado do sistema;
São normalmente levantados por engenheiros.

13. REQUISITOS DO SOFTWARE
É algum comportamento ou característica que é exigido do software;
Normalmente levantado por engenheiros.

14. DEPENDÊNCIA DE REQUISITOS
Requisitos podem depender uns dos outros
 Necessidades do negócio;
 Necessidades de implementação;
Cada dependência fora de ordem aumenta o risco do projeto.

15. PRIORIDADE DE REQUISITOS
Fatores
Diminuir o custo da implementação;
Tempo para implementar;
Obrigação para com alguma autoridade
externa.

16. MUDANÇA
Requisitos inevitavelmente mudam, antes, durante e após o desenvolvimento, dos
projetos;
Não se deve esperar defini-los completamente, mas gerenciar suas mudanças;
A única constante é a mudança.

17. GERÊNCIA DE CONFIGURAÇÃO
Trata-se de um conjunto de procedimentos que controlam:
 O que o sistema deverá fazer;
 Os módulos de projeto gerados;
 O código do programa;
 Os testes;
 Os documentos.

18. IMPACTO DOS REQUISITOS

19. CUSTO RELATIVO DE CORREÇÃO
Requisito 1
Projeto 5
Codificação 10
Teste de unidade 20
Teste de aceitação 50
Manutenção 200

20. CUSTO DE ERROS DE REQUISITOS
São o tipo mais comum de erro;
É o tipo mais caros de se concertar;
25% a 45% do projeto.

21. REQUISITOS FALSOS E VERDADEIROS
Um requisito é verdadeiro quando o sistema deve cumpri-lo qualquer que
seja a tecnologia de implementação;
Se um sistema pode cumprir sua finalidade sem que o requisito seja
implementado, então o requisito é falso.

22. VALIDAÇÃO DE REQUISITOS
Leitura;
Entrevistas;
Revisão;
Cenários;
Protótipos.

23. REVISÃO DE REQUISITOS
Rever metas e objetivos estabelecidos para o sistema;
Comparar requisitos, metas e objetivos;
Descrever o ambiente operacional;
Examinar;
 Interfaces, fluxos de informações, funções;
Verificar omissões;
Documentar riscos;
Discutir estratégias de testes.

24. TIPOS DE REQUISITOS
Requisitos funcionais:
 Representa algo que o sistema deve fazer.
Exemplos típicos:
 Emissão de relatórios;
 Realização e manutenção de cadastros.

25. CATEGORIAS DE FUNÇÕES
Evidente
 Deve ser executada com conhecimento do usuário;
Oculta
 Deve ser executada mais não necessariamente visível para o usuário;
Enfeite ou Decoração
 Opcional, sua adição não afeta as outras funções;

26. Requisitos não funcionais:
 Fala da forma como os requisitos não funcionais devem ser alcançados;
 Define prioridades e restrições do sistema;
Exemplos:
 Requisitos de qualidade;
 Robustez;
 Escolha de qual tecnologia usar.

27. TIPOS DE REQUISITOS
Ambiente físico;
Interfaces;
Usuários e fatores humanos;
Segurança;
Recursos;
Dentre outros.

28. ELICITANDO REQUISITOS

29. PROBLEMAS POSSÍVEIS
Os Stakeholders
 Podem saber o que querem, mais não sabem articular;
 Podem não saber o que querem;
 Podem pensar saber o que querem até receberem o que pediram;
Os Analistas
 Podem pensar que entendem o problema melhor que os usuários.

30. POR FIM, AVALIANDO REQUISITOS
Os requisitos estão completos?
 Existe algum requisito ausente?
 Existe alguma informação faltando em um requisito?
Os requisitos são consistentes?
 Existe alguma contradição?
Os requisitos podem ser compreendidos?
 Os leitores do documento entendem o que está escrito?