Especificando Requisitos de Software

1. O Documento de Requisitos

2. Priorizando Requisitos

2.1. Critérios de Priorização

• A definição dos critérios utilizados para priorizar requisitos deve considerar o contexto do projeto. Abaixo estão alguns critérios comuns adotados na literatura e na prática:

  • Impacto no(a) usuário(a): Requisitos que afetam diretamente a experiência de uso, a usabilidade ou a acessibilidade do sistema tendem a ter alta prioridade.

  • Valor de negócio: Requisitos que geram vantagem competitiva, retorno financeiro ou que atendem necessidades críticas do(a) cliente devem ser priorizados.

  • Risco: Requisitos que envolvem alto risco técnico, jurídico ou de segurança podem ser antecipados para mitigar possíveis impactos.

  • Dependências: Requisitos que são pré-requisitos para outros componentes funcionais precisam ser implementados antes para destravar outras funcionalidades.

• Outros critérios podem incluir complexidade, frequência de uso, custos estimados, entre outros.

2.2. Métodos para Apoio à Priorização

• Existem diversas técnicas de priorização que podem ser utilizadas para apoiar a tomada de decisão, como:

  • MoSCoW (Must, Should, Could, Won’t): Classifica os requisitos em quatro categorias de prioridade: Must (obrigatórios), Should (importantes), Could (desejáveis) e Won’t (não serão incluídos agora).

  • 100 Points Method: Cada stakeholder recebe 100 pontos para distribuir entre os requisitos, de acordo com sua percepção de importância.

  • Análise Custo x Benefício: Compara o valor que cada requisito traz para o negócio com seu custo estimado de implementação, priorizando os que oferecem maior retorno.

  • Matriz de Impacto x Esforço: Coloca os requisitos em uma matriz 2x2, avaliando o impacto gerado versus o esforço necessário para implementá-los, favorecendo ações de alto impacto e baixo esforço.

  • Planning Poker: As pessoas da equipe estimam a complexidade ou esforço de um requisito com cartas numeradas, discutindo até chegar a um consenso — útil também para refletir prioridade.

• Nesta disciplina, adotaremos uma abordagem simples e prática de priorização de requisitos em três níveis, levando em consideração as dependências e o impacto no desenvolvimento. 

• Essa estratégia é especialmente útil na definição das entregas de uma primeira versão do sistema, como um MVP (Produto Mínimo Viável).

• 🔺 Alta:  Requisitos obrigatórios e essenciais, sem os quais o sistema não cumpre sua principal função.

  • Devem estar necessariamente presentes na primeira versão (MVP).

  • São frequentemente requisitos de núcleo, críticos para a operação e que desbloqueiam outros componentes.

  • Exemplo: Em um sistema de agendamento de consultas médicas, o cadastro de pacientes e a marcação de consultas são funcionalidades de prioridade alta.

• 🔸 Média: Requisitos importantes, mas que podem ser entregues após os de alta prioridade.

  • Inclui tanto requisitos obrigatórios quanto desejáveis, desde que não sejam essenciais para o MVP.

  • Devem constar no sistema final, mas sua entrega pode ser planejada em fases posteriores.

  • Exemplo: Em um sistema de agendamento de consultas médicas, a visualização de histórico de agendamentos, o envio de lembretes por e-mail e cadastro de especialidades médicas pode ter prioridade média.

• 🔻 Baixa: Requisitos desejados que não são essenciais, e podem ser implementados em versões futuras.

  • Sua inclusão está condicionada a uma (re)avaliação posterior, dependendo da viabilidade técnica, tempo, recursos e impacto no projeto.

  • Só devem ser desenvolvidos se não interferirem negativamente nos requisitos de maior prioridade.

  • Exemplo: Em um sistema de agendamento de consultas médicas, a avaliação de médicos pelos pacientes, a personalização da interface com escolha de temas e a integração com calendário do Google podem ser considerados de prioridade baixa.

• ✅ Essa priorização orienta tanto a análise quanto a implementação dos requisitos, contribuindo para decisões mais estratégicas e realistas no planejamento do projeto.

3. Matriz de Rastreabilidade

• A rastreabilidade de requisitos (requirements traceability) é a capacidade de estabelecer ligações bidirecionais entre os requisitos e os demais artefatos do sistema — como código-fonte, testes, diagramas e documentos. Em termos práticos, isso significa que devemos ser capazes de:

  • Identificar quais trechos de código implementam cada requisito;

  • Verificar, a partir de um trecho de código, quais requisitos ele atende.

  • Essa rastreabilidade é essencial para garantir alinhamento entre o que foi solicitado e o que foi de fato desenvolvido, além de facilitar a manutenção e a gestão de mudanças no projeto.

• 🧭 Matriz de Rastreabilidade segundo o PMBOK®

  • De acordo com o Guia PMBOK® (Project Management Body of Knowledge), a matriz de rastreabilidade dos requisitos (ou Requirements Traceability Matrix – RTM) associa cada requisito:

    • às suas origens (ex: entrevistas com usuários, regulamentos, metas de negócio),

    • aos seus artefatos de implementação (ex: diagramas UML, código, casos de teste),

    • e aos objetivos de negócio e do projeto.

• Essa associação deve ser mantida ao longo de todo o ciclo de vida do sistema, garantindo que:

  • Apenas requisitos aprovados sejam implementados;

  • Cada item desenvolvido agregue valor ao projeto;

  • Mudanças no escopo possam ser controladas com mais segurança e previsibilidade.

• A rastreabilidade pode ser representada em diferentes formatos de matriz, a depender do que se deseja rastrear. Alguns exemplos:

  • Requisitos x Artefatos: Relaciona requisitos às suas representações em modelos (como casos de uso, diagramas de classe, código-fonte).

  • Requisitos x Testes: Garante que cada requisito tenha um ou mais testes que o validem.

  • Requisitos x Fontes: Indica a origem de cada requisito (entrevista, legislação, análise de concorrência, etc.).

  • Requisitos x Dependências: Mostra quais requisitos dependem de outros para serem implementados.

  • Requisitos x Interfaces do Sistema: Útil em sistemas com múltiplas integrações, identificando em quais interfaces cada requisito atua.

4. Dependência entre Requisitos

• Na Engenharia de Requisitos, dependência refere-se à relação entre dois ou mais requisitos em que a implementação, verificação ou validade de um está condicionada ao outro.

  • Isso significa que um requisito só pode ser completamente compreendido, implementado ou validado considerando o estado de outro.

  • Exemplo: O requisito de "emitir relatório de consultas realizadas" depende do requisito de "registrar consultas no sistema" — sem o registro das consultas, não há dados para gerar o relatório.

4.1. Tipos Comuns de Dependência entre Requisitos

• 🔗 Dependência Funcional: Ocorre quando uma função depende da execução de outra para funcionar corretamente.

  • Exemplo: No sistema de agendamento de consultas, o requisito "Enviar lembrete por e-mail" depende do requisito "Cadastrar e-mail do paciente". Sem o e-mail cadastrado, o lembrete não pode ser enviado.

• 🔢 Dependência de Sequência: A ordem de execução dos requisitos é crucial. Um requisito deve ocorrer antes ou depois de outro.

  • Exemplo: "Salvar informações no prontuário de consulta" deve ocorrer antes do requisito "Emitir atestado médico", garantindo que o documento seja criado baseado no registro da uma consulta documentada.

• ⚙️ Dependência Lógica: A lógica do sistema exige que certos requisitos coexistam para fazer sentido funcional.

  • Exemplo: O requisito "Gerar alerta de risco clínico" depende do requisito "Avaliar sintomas informados pelo paciente". O alerta só pode ser emitido se a avaliação dos sintomas estiver implementada.

• 🖥️ Dependência de Recursos: O atendimento a um requisito depende de recursos técnicos, como hardware, software ou infraestrutura.

  • Exemplo: "Atendimento por vídeo chamada" pode depender da existência de uma conexão adequada disponível no local.

• 🌐 Dependência de Restrições Externas: Relaciona-se a condições ou sistemas externos ao projeto, como normas, integrações ou APIs de terceiros.

  • Exemplo: "Emitir receitas digitais" depende da integração com um sistema externo de certificação digital.

• A identificação e o gerenciamento adequado das dependências entre requisitos são fatores críticos para o sucesso da engenharia de requisitos. 

  • Compreender como os requisitos se relacionam impacta diretamente o planejamento do projeto, a ordem de implementação das funcionalidades e a qualidade final do sistema.

  • Quando as dependências são mapeadas corretamente, a equipe consegue evitar conflitos, reduzir retrabalho e garantir que funcionalidades essenciais estejam disponíveis no momento certo.

• Por outro lado, ignorar ou tratar superficialmente essas dependências pode resultar em:

  • Atrasos no cronograma;

  • Implementações incompletas ou fora de ordem;

  • Dificuldades na verificação e validação dos requisitos;

  • Problemas de integração entre módulos do sistema.

• Assim, mapear as dependências não é apenas uma etapa técnica: é uma estratégia para garantir a entrega de um software coeso, funcional e confiável.