Revisão de Requisitos de SW

Requisitos de Software
Engenharia de requisitos de software

• Requisitos são as funções e restrições que
estabelecem exatamente o que o software deve
fazer.
• O processo de descobrir, analisar, documentar,
rastrear e verificar essas funções e restrições é
chamado de Engenharia de Requisitos
Ex. Requisitos do usuário
• O software deve oferecer um meio de representar
e acessar arquivos externos.
• O software deve possibilitar ao usuário a consulta
de livros por autor e palavra-chave.
• O software deve possibilitar a impressão de
relatórios de vendas diárias.
• Quando o usuário inserir o CPF, este deve ser
automaticamente validado pelo software.
• O campo data deve estar no formato
DD/MM/AAAA
Classificação de requisitos
• Funcionais: declarações sobre
– O que o software deve fazer (e o que não deve fazer)
– Como o software deve reagir a entradas específicas.
• Não funcionais:
– restrições sobre as funções oferecidas pelo software
• Domínio:
– Refletem características de um domínio.
– Podem ser funcionais ou não-funcionais.
Ex. Requisitos funcionais
• O usuário deverá ser capaz de pesquisar todos
os boletos não pagos nos últimos 30 dias.
• O software fornecerá telas apropriadas para o
usuário ler documentos do repositório de
documentos
• Cada pedido será alocado a um único
identificador
Sobre os requisitos funcionais
• Podem (e devem) ser escritos em diferentes
níveis de abstração.
• Deve-se evitar ambiguidades.
– Ex. O que são “telas apropriadas” ?
Sobre os requisitos funcionais
• A especificação deve ser:
– Completa: todas as funções requeridas devem
estar definidas
– Consistente: requisitos não podem ter definições
contraditórias
Sobre requisitos não-funcionais
• Não dizem respeito diretamente às funções do software
• Estão relacionados a propriedades emergentes
• Relativos a um conjunto do sistema, e não a partes dele
– Ex. confiabilidade, desempenho, segurança
• Devem ser quantificados na especificação de requisitos
– Somente assim podem ser testados
Problemas na escrita de requisitos
1a) O software deve gerar o boleto a ser pago de forma rápida.
1b) O software deve gerar o boleto a ser pago o mais rápido
possível.
1c) O software deve gerar o boleto a ser pago instantaneamente.
Problemas na escrita de requisitos
1d) O software deve gerar o boleto em no máximo 5 segundos.
1e) O software deve gerar o boleto em no máximo 5 segundos
em pelo menos 90% dos pedidos.
1f) O software deve gerar o boleto em no máximo 5 segundos em
pelo menos 90% dos pedidos, e em no máximo 10 segundos
em 100% dos pedidos.
*ilities
• Accessibility, Administrability, Understandability, Generality,
Operability, Simplicity, Mobility, Nomadicity, Portability, Accuracy,
Efficiency, Footprint, Responsiveness, Scalability, Schedulability,
Timeliness, CPU utilization, Latency, Throughput, Concurrency,
Flexibility, Changeability, Evolvability, Extensibility, Modifiability,
Tailorability, Upgradeability, Expandability, Consistency,
Adaptability, Composability, Interoperability, Openness,
Integrability, Accountability, Completeness, Conciseness,
Correctness, Testability, Traceability, Coherence, Analyzability,
Modularity, Reusability, Configurability, Distributeability,
Availability, Confidentiality, Integrity, Maintainability, Reliability,
Safety, Security, Affordability, Serviceablility, …
Requisitos do domínio
• São derivados do domínio, não de
necessidades específicas dos stakeholders
• Podem ser:
– Novos requisitos funcionais
– Estabelecer como cálculos específicos são feitos
– Restrições dos requisitos funcionais
Documento de requisitos
• SRS (Software Requirements Specification)
• Diferentes stakeholders o usam:
• Clientes
– Verificam se os requisitos atendem suas necessidades
– Especificam mudanças nos requisitos
• Gerentes
– Planejam o pedido de proposta do sistema
– Planejam o processo de desenvolvimento do sistema
• Desenvolvedores
– Compreender que sistema será desenvolvido
– Desenvolver testes do sistema (validação)
Padrão IEEE 830/1998
• 1 – Introdução
– 1.1 propósito do documento
– 1.2 escopo do produto
– 1.3 definições, abreviações
– 1.4 referências
– 1.5 visão geral do restante do documento
• 2 – Descrição geral
– 2.1 perspectiva do produto
– 2.2 funções do produto
– 2.3 características do usuário
– 2.4 restrições gerais
– 2.5 suposições e dependências
Padrão IEEE 830/1998
• 3 – Requisitos específicos (não há padrão
neste tópico)
– Requisitos funcionais
– Requisitos não-funcionais
– Requisitos de interface
– Requisitos do domínio
– Restrições em geral, propriedades, características
• 4 – Apêndice
• 5 - Índice
Documentação de requisitos
• Vários diferentes diagramas, notações, técnicas
• Vamos usar linguagem natural:
– “O sistema deve ...”
– “Se o sistema receber a entrada X, ele deve
responder com a saída Y”
– “O usuário deve entrar com X”
– “O sistema deve ser capaz de X”
– “Quando o usuário entrar com X, o software deve
responder Y”.

Revisão de Requisitos de SW

Enviado por

Direitos autorais:

Formatos disponíveis

Revisão de Requisitos de SW

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Revisão de Requisitos de SW

Enviado por

Direitos autorais:

Formatos disponíveis

Requisitos de Software

Engenharia de requisitos de software

Você também pode gostar