Engenharia de Requisitos: Guia Completo

Análise de Requisitos

A Análise de Requisitos é o processo de descobrir, analisar, documentar e verificar os serviços requeridos para um sistema, bem como suas restrições operacionais.

O que é um Requisito?

Um requisito pode variar de uma declaração abstrata de alto nível de um serviço ou de uma restrição do sistema a uma especificação matemática funcional detalhada. Ele serve como base para o desenvolvimento do sistema.

Tipos de Requisitos

• Requisitos de Usuário: Declarações em linguagem natural, complementadas por diagramas, que descrevem os serviços que o sistema fornece e suas restrições operacionais. São escritos para os usuários.
• Requisitos de Sistema: Um documento estruturado que apresenta descrições detalhadas das funções, serviços e restrições operacionais do sistema. Define o que deve ser implementado e pode fazer parte de um contrato entre o cliente e o desenvolvedor.

O Sistema LIBSYS

O LIBSYS é um sistema de biblioteca que oferece uma interface única para diversos bancos de dados de artigos em diferentes bibliotecas.

Requisitos de Usuário e de Sistema

• Requisitos de Usuário: Destinados a gerentes de clientes, usuários finais do sistema, engenheiros de cliente, gerentes de fornecedores e arquitetos de sistemas.
• Requisitos de Sistema: Destinados a usuários finais do sistema, engenheiros e clientes, arquitetos de sistema e desenvolvedores de software.

Requisitos Funcionais e Não Funcionais

• Requisitos Funcionais: Descrevem a funcionalidade ou os serviços do sistema. Dependem do tipo de software, dos usuários esperados e do tipo de sistema onde o software é usado. Requisitos funcionais do sistema devem descrever os serviços em detalhes.
• Exemplos:
  • O usuário deve ser capaz de pesquisar em todo o conjunto inicial de bancos de dados ou selecionar um subconjunto dele.
  • O sistema deve fornecer visualizadores apropriados para o usuário ler os documentos no repositório de documentos.
• Requisitos Não Funcionais: Definem propriedades e restrições do sistema (confiabilidade, tempo de resposta, requisitos de armazenamento, etc.). Podem ser mais críticos do que os requisitos funcionais.
• Exemplos:
  • Requisitos de Produto: Especificam como o produto entregue deve se comportar (velocidade de execução, confiabilidade, etc.).
  • Requisitos Organizacionais: Derivam de políticas e procedimentos da organização (padrões de processo, requisitos de implementação, etc.).
  • Requisitos Externos: Fatores externos ao sistema e seu processo de desenvolvimento (requisitos de interoperabilidade, requisitos legais, etc.).

Requisitos de Domínio

Derivados do domínio de aplicação, descrevem características do sistema que refletem esse domínio. Podem restringir requisitos funcionais existentes ou definir cálculos específicos. O não cumprimento dos requisitos de domínio pode inviabilizar o sistema.

Problemas de Requisitos de Domínio:

• Compreensibilidade: Os requisitos são expressos na linguagem do domínio da aplicação, que nem sempre é compreendida pelos engenheiros de software.
• Implicitude: Especialistas da área podem ter tanto conhecimento implícito que não explicitam os requisitos de domínio.

Documento de Especificação de Requisitos

O Documento de Especificação de Requisitos deve conter sentenças em linguagem natural, seguindo padrões:

1. Usar "deve" para requisitos obrigatórios e "deveria" para requisitos desejáveis. Exemplo: "O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX ou superior."
2. Organizar os requisitos logicamente.
3. Cada requisito deve ter um identificador único (ex: numérico) para referência.
4. Dividir os requisitos em funcionais e não funcionais.
5. Evitar jargões de computação.

Formato da Especificação de Requisitos (Padrão IEEE/ANSI 830/1998)

(Introdução > Descrição Geral > Requisitos Específicos > Apêndices > Índice)

Problemas com a Especificação em Linguagem Natural

• Ambiguidade: Leitores e escritores precisam interpretar as palavras da mesma forma. A linguagem natural é inerentemente ambígua.
• Flexibilidade Excessiva: A mesma informação pode ser expressa de várias maneiras.
• Falta de Modularização: Estruturas de linguagem natural são inadequadas para estruturar requisitos de sistema.

Engenharia de Requisitos

A Engenharia de Requisitos envolve quatro fases principais:

1. Estudo de Viabilidade
2. Elicitação e Análise de Requisitos
3. Validação dos Requisitos
4. Gerenciamento dos Requisitos

Estudo de Viabilidade

Um estudo breve e focado para decidir se vale a pena investir no sistema proposto. Verifica:

• Se o sistema contribui para os objetivos da organização.
• Se o sistema pode ser implementado com a tecnologia atual e dentro do orçamento.
• Se o sistema pode ser integrado a outros sistemas existentes.

Elicitação e Análise de Requisitos

Envolve a coleta de informações sobre o sistema proposto e os sistemas existentes. Fontes incluem documentos, a organização, especificações existentes, observações e entrevistas.

Dificuldades:

• Stakeholders podem não saber exatamente o que querem ou ter dificuldade em expressar suas necessidades.
• Stakeholders expressam requisitos em seus próprios termos, que podem ser diferentes entre si.
• Fatores políticos podem influenciar os requisitos.
• O ambiente é dinâmico e muda constantemente.

Validação de Requisitos

Visa demonstrar que os requisitos definem o sistema que o cliente realmente deseja. Erros de requisitos são caros, portanto, a validação é crucial.

• Verificação de Validade: O sistema atende às necessidades do cliente?
• Verificação de Consistência: Há conflitos entre os requisitos?
• Verificação de Completeza: Todas as funções requisitadas foram incluídas?
• Verificação de Realismo: Os requisitos podem ser implementados com o orçamento e a tecnologia disponíveis?
• Facilidade de Verificação: Os requisitos podem ser verificados?

Gerenciamento de Requisitos

É o processo de gerenciar as mudanças nos requisitos durante a engenharia de requisitos e o desenvolvimento do sistema. Requisitos são, inevitavelmente, incompletos e inconsistentes.

Rastreabilidade

Relaciona-se aos relacionamentos entre os requisitos, suas fontes e o projeto do sistema.

• Rastreabilidade da Fonte: Liga os requisitos aos stakeholders que os propuseram.
• Rastreabilidade de Requisitos: Liga os requisitos dependentes entre si.
• Rastreabilidade de Projeto: Liga os requisitos aos módulos de projeto.