Tipos de Requisitos

Tipos de Requisitos

1. Domínio do Problema

   • Espaço designado as decisões sobre objetivos organizacionais que devem ser tomadas
     • Fronteiras que as delimitam
     • Partes Interessadas chave
     • Interações dessas partes com aquelas áreas
   • Importância: Define escopo inicial, incluindo partes importantes e informações de autoridade, orientando analista de requisitos.

2. Requisitos de Negócio

   • Metas e objetivos da organização, justificando projetos e medindo sucesso. Amplos e abrangem a organização completa.
     • Importância
       • Liberdade para conceber soluções. Indica valor comercial das solicitações. Facilita priorização. Maior controle em projetos longos, evitando desvios.
     • Critério de Qualidade
       • Método SMART
     • Papel do Analista
       • Melhorar compreensão inicial de intenções ao refinar requisitos de negócio, sem focar em soluções alternativas.

3. Restrições e Premissas

   • Informações cruciais para o projeto, descobertas ao estudar o domínio, influenciam a definição dos requisitos.
     • Restrições
       • Restrições limitam o software ao produto, não ao projeto. Não são requisitos, mas influenciam os específicos, originadas de negócios ou técnicas, sem possibilidade de negociação.
     • Papel do analista
       • Validar restrições do trabalho de requisitos, pois algumas podem ser incorretas.

4. Requisitos das partes interessadas

   • Feedback sobre compreensão dos requisitos, intermediários, detecta conflitos e une requisitos similares, são o resultado das necessidades de negócio em relação à especificação da solução.
     • São registrados em gravações, notas ou atas. Durante o levantamento, pontos-chave são anotados ou gravados em áudio/vídeo. Atas agem como memória de levantamento.

5. Requisitos da Solução

   • Surgem da resolução de conflitos e lacunas, são especificações que descrevem características para atender requisitos de negócio e partes interessadas.
     • Importância
       • Armazena decisões do escopo e comportamento do software, antecipa necessidades, evita premissas desnecessárias, valida entendimento e identifica problemas nas especificações.
     • Processo geral de desenvolvimento dos requisitos
       • 1. Organização dos requisitos das partes interessadas no escopo, focando na abrangência inicial.
       • 2. Desenvolvimento dos requisitos, resolvendo conflitos, eliminando redundâncias e preenchendo lacunas para detalhar a solução.
       • 3. Fechamento com profundidade para atualizar arquitetura, implementar e testar unidades, conforme o processo de Engenharia de Requisitos.

6. Requisitos de Transição

   • Requisitos temporários, transição operação, definidos após desenho, descartados pós entrega, técnicas iguais.
     • Importância
       • Melhor organização de especificações, gestão do conhecimento, comunicação e medição funcional. Separação de requisitos para entendimento. Insumos para análise de pontos de função, parte complexa do projeto.
     • Papel do analista
       • Identificação de requisitos de transição antes de avaliar cenários atuais e futuros. Comparando-os, identificam-se ações a serem atendidas para a solução entrar em pleno funcionamento.

7. Requisitos de Software

   • Incluem requisitos da solução e de transição, funcionais e não funcionais.
     • Funcionais: descrevem a ação do software.
     • Não funcionais: descrevem qualidades e limitações do produto.
     • Armazenados em vários artefatos, variando com a metodologia de desenvolvimento da organização.

8. Requisitos Funcionais

   • Descrevem ações do software para tarefas do usuário, não substituindo detalhes técnicos. Requisitos podem mudar de funcional para não funcional em cenários diversos.
     • São armazenados em documentos que recebem a nominação de especificação funcional
     • Papel do analista
       • Detalhar requisitos amplos ou unir fragmentos para a especificação adequada. Espera-se granularidades diferentes nas especificações dos requisitos funcionais.
         • Nível de granularidade
           • Ampla ou limitada descrição do comportamento esperado do software em especificações funcionais. A amplitude está relacionada ao objetivo do requisito nessa especificação.
   • Objetivo de usuário
     • Trata-se do requisito funcional padrão, descrevendo uma tarefa única para um usuário, com tudo necessário para concluir a tarefa até sua responsabilidade.
       • Importância
         • Identificar requisito funcional desse nível define claramente o escopo. Facilita validação, é padronizado, verificável objetivamente conforme políticas de qualidade e critério em metodologias.
   • Objetivo agregador
     • Requisitos que agregam objetivos de usuários em alto nível, mais amplos em níveis maiores. São colaborativos, abrangentes, resumindo tarefas de vários usuários.
       • Importância
         • Resumir várias tarefas do usuário em um único item quando não são totalmente conhecidas.
       • Papel do analista
         • Detalhar requisitos agregados, tornando-os mais específicos até alcançar um nível apropriado para um requisito final.
   • Objetivo de subfunção
     • Semelhantes aos requisitos agregadores, mas opostos em direção. Fragmentos em nível inferior aos objetivos do usuário. Sozinhos, não atendem a um objetivo do usuário.
       • Importânica
         • Frequentemente compartilhados entre diferentes requisitos funcionais. Especificar independentemente melhora a gestão de requisitos.
       • Papel do analista
         • Identificar subfunções e verificar em quais requisitos funcionais elas se encaixam. Ao criar especificações, aproveitar oportunidades para melhorar a gestão de requisitos.

9. Requisitos não Funcionais

   • Descrevem limitações gerais, complementam especificações de software. Estabelecem níveis de serviço esperados e indicam restrições relativas.
     • Requisitos não funcionais são geralmente expressos de maneira ampla em relação ao software, enquanto os funcionais são mais específicos em sua manifestação.