Melhorar os requisitos
Idealmente, todos os requisitos seriam perfeitos e implementáveis, mas a realidade é que alguns precisarão ser refinados, consolidados ou removidos para que você tenha um conjunto sólido de requisitos. Avaliando cada requisito, você pode procurar áreas de aprimoramento.
Ao avaliar, considere fazer a si mesmo as seguintes perguntas:
Os requisitos são claros e completos?
Existem lacunas que você sabe que precisarão ser abordadas, mas não são capturadas nos requisitos?
Todas as necessidades regulatórias e de conformidade foram incluídas?
Esse requisito é uma duplicata de outro e deve ser consolidado?
O requisito inclui componentes que estão fora do escopo?
O requisito inclui projetos/implementações específicos?
O requisito especifica como o sistema herdado tratou o problema, não o problema de negócios real?
Os requisitos destinam-se a explicar o problema que precisa ser resolvido, não como resolvê-lo. A solução do problema ocorre examinando todos os requisitos e mapeando-os para uma solução como parte do processo de design. Os usuários que fornecem os requisitos não precisam saber como o problema será resolvido quando fornecem informações sobre um requisito.
Exemplo — inclui especificações de design
Esse exemplo descreve um requisito que inclui especificações de design.
O gerente de conta do cliente será notificado por email de um fluxo do Microsoft Power Automate que é disparado na criação de uma nova ocorrência no Dynamics 365 quando ele for o proprietário da linha da conta no Microsoft Dataverse.
Esse requisito poderia ser mais simples: Como gerente de contas do cliente, quero ser notificado quando meu cliente abrir uma nova ocorrência.
Quando possível, tente trazer um requisito de volta para o quê, quem e por que; evite incluir como isso será feito na nova solução. Elevando a discussão para a necessidade de negócios, você terá uma compreensão mais clara do problema que precisa ser resolvido. Em muitos casos, pode estar disponível uma maneira melhor de implementar o requisito, em vez do que foi feito no sistema herdado.
Exemplo — detalhes ausentes
Esse exemplo descreve um requisito em que há detalhes ausentes.
As contas não terão um limite de crédito alto durante o primeiro ano como cliente.
Conforme escrito, esse requisito não pode ser implementado porque você não sabe qual é o limite e o que é considerado alto. Além disso, esse aspecto não pode ser testado. O requisito real para um limite pode ser tão simples quanto um valor real de US$ 2 milhões, ou pode ser mais complexo, como um limite para cada região. O segundo aumenta a complexidade geral do requisito. Embora esse exemplo seja simples, imagine que, se for um requisito mais complexo, não ter uma boa clareza poderá afetar o escopo e os recursos do projeto.