1 requisitos funcionais e não funcionais ok

REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS.OUTRAS CLASSIFICAÇÕES.

P R O F. : M A R C O S M O R A I SM 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

EXEMPLO DE REQUISITO

O problema da pedra...

Me traz uma pedra?

Pequena?

Parece de vidro!

Ela é azul!

Parece uma bola!

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.

E NO MUNDO DO SOFTWARE?

Acontece da mesma forma;

O usuário tem desejos;

Esse desejo precisa ser bem descrito.

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.

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.

QUAL O SEGREDO?

Para atender o usuário é preciso definir os verdadeiros requisitos de software;

CATEGORIAS DE REQUISITOS

Requisitos que devem ser totalmente satisfeitos;

Requisitos que são altamente desejáveis;

Requisitos possíveis.

TIPOS DE REQUISITOS

Software

Sistema

Usuário

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.

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.

REQUISITOS DO SOFTWARE

É algum comportamento ou característica que é exigido do software;

Normalmente levantado por engenheiros.

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.

PRIORIDADE DE REQUISITOS

FatoresDiminuir o custo da implementação;

Tempo para implementar;

Obrigação para com alguma autoridade externa.

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.

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.

IMPACTO DOS REQUISITOS

CUSTO RELATIVO DE CORREÇÃO

Requisito 1Projeto 5Codificação 10Teste de unidade 20Teste de aceitação

50

Manutenção 200

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.

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.

VALIDAÇÃO DE REQUISITOS

Leitura;

Entrevistas;

Revisão;

Cenários;

Protótipos.

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.

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.

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;

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.

TIPOS DE REQUISITOS

Ambiente físico;

Interfaces;

Usuários e fatores humanos;

Segurança;

Recursos;

Dentre outros.

ELICITANDO REQUISITOS

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.

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?