Considere que você e sua equipe são responsáveis por conduzi...

Comentário: A I e a II estão corretas, as atividades de escrita - validação e testes - correção realmente devem ser alocadas a pessoas diferentes. No entanto, a validação do requisito não deve ser feita apenas pelo stakeholder principal. Gabarito letra D.

http://dropsti.blogspot.com.br/2015/08/engenharia-de-requisitos.html

O erro da III está no "Apenas".. Como sempre..

d-

Evitar que o autor seja o que vai validar é um principio da governança - por questoes de ética, algumas funcoes devem ser feitas por quem nao tem interesse (stakes) no resultado

A resposta correta é a alternativa D - somente I e II. Vamos analisar o porquê dessas recomendações serem consideradas adequadas para a melhoria da qualidade da validação de requisitos em projetos de sistemas de software.

I. Evite que o autor de um requisito também seja a pessoa que vai validar o requisito.
Esta recomendação é importante pois ajuda a evitar o viés de confirmação, onde o criador do requisito pode não ser capaz de identificar falhas por estar muito envolvido ou comprometido com o trabalho que produziu. Ter uma pessoa diferente para validar ajuda a garantir uma avaliação mais objetiva e imparcial dos requisitos.

II. Separe a atividade de identificação de falhas nos requisitos da atividade de correção.
A separação das atividades de identificação de falhas e a correção das mesmas permite um foco maior em cada tarefa. Primeiro, deve-se dar atenção completa para encontrar inconsistências, ambiguidades, ou qualquer outro tipo de problema nos requisitos sem a preocupação imediata de como resolvê-los. Depois, na fase de correção, as soluções podem ser mais bem planejadas e executadas, sem o risco de realizar ajustes precipitados que podem não resolver os problemas de forma eficaz.

A recomendação III. Valide requisitos somente a partir do ponto de vista do stakeholder principal. não é correta e, portanto, não contribui para a validade da resposta. Isso porque a validação de requisitos deve levar em consideração as perspectivas de todos os stakeholders relevantes, não apenas a do principal. Cada stakeholder pode ter diferentes necessidades e preocupações, e é essencial considerar todas essas visões para garantir que o sistema atenda a todos os requisitos de negócios e de usuários.

Portanto, ao seguir as recomendações I e II, você está aplicando práticas que ajudam a assegurar uma revisão e validação bem-sucedidas dos requisitos de software, promovendo assim uma melhor qualidade do resultado final do projeto.