No contexto do desenvolvimento de software, a rastreabilidade de requisitos é uma prática que acompanha e documenta os requisitos ao longo de todo o ciclo de vida do projeto. Para garantir que cada requisito seja identificado e monitorado de forma eficaz, essa prática adota dois recursos fundamentais. Quais são eles?
Questão
No contexto do desenvolvimento de software, a rastreabilidade de requisitos é uma prática que acompanha e documenta os requisitos ao longo de todo o ciclo de vida do projeto. Para garantir que cada requisito seja identificado e monitorado de forma eficaz, essa prática adota dois recursos fundamentais. Quais são eles?
Alternativas
A) Atribuição de um identificador exclusivo a cada requisito e registro em um repositório centralizado de requisitos.
B) Classificação dos requisitos por prioridade e distribuição em planilhas individuais por equipe de desenvolvimento.
C) Criação de diagramas de fluxo para cada requisito e armazenamento em pastas físicas organizadas por data.
D) Validação dos requisitos pelo cliente ao final do projeto e inserção em um banco de dados relacional de código aberto.
E) Agrupamento dos requisitos por funcionalidade e registro em atas de reunião assinadas pelos stakeholders.
Explicação
Para que a rastreabilidade de requisitos funcione ao longo de todo o ciclo de vida (da elicitação até validação/manutenção), é essencial conseguir:
- Identificar inequivocamente cada requisito ao longo do tempo, mesmo que seu texto mude.
- Isso é feito pela atribuição de um identificador único (ID) para cada requisito (ex.: RF-001, RNF-012). Esse ID permite referenciar o requisito em casos de uso, histórias, testes, código, mudanças, defeitos etc.
- Manter um registro controlado e acessível do conjunto de requisitos e seus vínculos (links) com artefatos do projeto.
- Para isso, utiliza-se um repositório centralizado de requisitos (ferramenta/registro único), onde os requisitos são armazenados, versionados e relacionados a outros artefatos (matriz de rastreabilidade, links para testes, commits, itens de backlog etc.).
Analisando as alternativas:
- A traz exatamente esses dois recursos básicos: ID único + repositório central.
- B, C, D e E citam práticas que podem existir em projetos, mas não são os dois recursos fundamentais para garantir identificação e monitoramento eficaz (planilhas por equipe, pastas físicas, validação só no fim, atas) e ainda introduzem fragilidades de controle/centralização.