Engenharia de Requisitos: Boas Práticas e Processos

Engenharia de Requisitos

É o conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, auxiliando a Engenharia de Software a compreender melhor o problema.

O que é um Requisito?

• Pode ser uma parte abstrata de alto nível de um serviço.
• Pode ser uma restrição do sistema.

Elicitação de Requisitos

A elicitação, ou descoberta de requisitos, envolve técnicos trabalhando com o cliente para levantar dados sobre:

• O domínio da aplicação.
• Os serviços que o sistema fornece.
• As restrições operacionais do sistema.

Processos da Elicitação

1. Descoberta de Requisitos: Processo para coletar informações do sistema e separar os requisitos de usuário e sistemas.
2. Classificação e Organização de Requisitos: Por tipo, origem e prioridade.
3. Priorização e Negociação de Requisitos: Participação do cliente ou usuário, atendimento ao escopo.
4. Especificação de Requisitos: Registro dos requisitos em comum acordo.

Problemas de Análise de Requisitos

• Stakeholders:
  • Não sabem o que querem.
  • Expressam requisitos em seus próprios termos.
• Diferentes stakeholders podem ter requisitos conflitantes.
• Fatores políticos e organizacionais podem mudar os requisitos.
• Surgimento de novos stakeholders pode fazer com que o ambiente de negócios mude.

Validação de Requisitos

• Validade: O sistema fornece as funções que melhor atendem à necessidade do cliente?
• Consistência: Existe algum conflito de requisitos?
• Completude: Estão incluídas todas as funções e restrições pedidas pelo cliente?
• Realismo: Os requisitos podem ser implementados com o orçamento e a tecnologia disponível?
• Verificabilidade: Os requisitos podem ser verificados?

Técnicas de Validação de Requisitos

• Revisões de Requisitos: Análise manual dos requisitos.
• Prototipação: Uso de um modelo executável para testar os requisitos.
• Geração de Caso de Teste: Desenvolvimento de testes para verificar os requisitos implementados.

Avaliação da Revisão

• Verificabilidade: A exigência é realmente testável?
• Compreensibilidade: O requisito é adequadamente compreendido?
• Rastreabilidade: A origem do requisito é clara?
• Adaptabilidade: Pode ocorrer alteração sem causar danos a outros requisitos?

Modelo Espiral de Boehm

• Não existe fase fixa como especificação ou projeto. Os loops no espiral são escolhidos de acordo com a necessidade do projeto.
• Os requisitos são avaliados explicitamente e resolvidos no decorrer do processo.

Setores do Modelo Espiral

• Desenvolvimento e Validação: Escolha do modelo de desenvolvimento.
• Planejamento: O projeto é revisto e a próxima fase da espiral é planejada.

Rational Unified Process (RUP)

É um processo genérico moderno, derivado do trabalho em UML e processos associados. Reúne aspectos dos 3 modelos genéricos.

Perspectivas

• Dinâmica: Mostra fases no tempo.
• Estática: Mostra atividades do processo.
• Prática: Sugere boas práticas.

Fases do RUP

• Concepção: Estabelece o business case para o sistema.
• Elaboração: Desenvolve um entendimento da extensão do problema e da arquitetura do sistema.
• Construção: Projeta o sistema, testa e programa.
• Transição: Implanta o sistema no seu ambiente de operação.

Boas Práticas do RUP

• Desenvolver software iterativamente.
• Gerenciar os requisitos.
• Usar arquitetura baseada em componentes.
• Modelar o software visualmente.
• Verificar a qualidade do software.
• Controlar as mudanças do software.

XP (Programação Extrema)

Pode ser usado para complementar o método Scrum, porque foca mais em processos de engenharia e desenvolvimento de software.

Características

• Leve.
• Não é prescritivo (só dá as instruções).
• Tende a fundamentar suas práticas por um conjunto de valores.

Objetivo

Levar ao extremo um conjunto de práticas que são ditas como boas na engenharia de software.

Valores

• Comunicação.
• Simplicidade.
• Feedback.
• Coragem.
• Respeito.

Princípios Básicos

• Feedback rápido.
• Presumir simplicidade.
• Mudanças incrementais.
• Abraçar mudanças.
• Trabalho em alta qualidade.

Práticas

• Jogo de Planejamento (Planning Game): Reuniões com clientes feitas em iterações semanais.
• Fases Pequenas (Small Releases): Liberação de pequenas partes do projeto.
• Metáfora: Procura facilitar a comunicação com o cliente.
• Design Simples (Simple Design): Trazer simplicidade para o produto.
• Teste de Aceitação (Customer Tests): Testes construídos pelo cliente para aceitar os requisitos.