Estutura Típica do Relatório de Requisitos

• Introdução
  • Objectivo do projecto
  • Enquadramento do sistema a desenvolver no negócio/organização
  • Riscos
• Lista de requisitos do sistema
  • Descrever os requisitos do sistema a desenvolver, não se limitando ao software, em linguagem corrente facilmente compreendida pelos utilizadores e clientes finais
  • Esta listagem é opcional (ver utilidade caso a caso), porque os requisitos se podem distribuir pelos casos de uso
• Modelo de casos de uso
  • Formalizar e aprofundar os requisitos anteriores
  • Começar com uma visão geral, com diagrama(s) de casos de uso e uma descrição
  • Tem fronteira do sistema, actores, casos de uso, pacotes de casos de uso
  • Os casos de uso descrevem os requisitos funcionais e podem ter associados alguns requisitos não funcionais
  • Casos de uso podem ser detalhados com esboços ou protótipos de interfaces para o utilizador e com diagramas dinâmicos (particularmente diagramas de sequência)
  • Diagramas de actividade podem ser usados para descrever fluxos de trabalho que atravessam vários casos de uso
• Requisitos suplementares
  • com restantes requisitos não funcionais
• Modelo de classes do domínio (vocabulário do domínio)
• Descrição de sistemas existentes com os quais o software a desenvolver tem de comunicar (BD's)
• Tudo aquilo que interessa validar junto do cliente (sobre o que deve ser feito e porquê, e restrições a considerar no como)
• Glossário (dicionário de termos do vocabulário do domínio)