Técnicas
As equipes de projeto podem usar diferentes técnicas para capturar e gerenciar requisitos. Os itens de trabalho do Microsoft Azure DevOps e os problemas do GitHub são comumente usados para facilitar a colaboração sobre os requisitos pela equipe do projeto. Além disso, estão disponíveis ferramentas especializadas em gerenciamento de lista de pendências e roteiros que as equipes podem usar. Os requisitos serão capturados nessas ferramentas ou em um documento de requisitos em um formato de narrativa ou história do usuário.
As histórias de usuários se concentram em quem é o usuário, o que ele deseja e por que quer que o sistema faça algo.
Por exemplo, "Como usuário de vendas, quero poder enviar um desconto a meu cliente usando o email."
Os requisitos são geralmente categorizados em uma lista de pendências enquanto aguardam para ser priorizados em um sprint/iteração de projeto ativo a ser implementado. Considere a lista de pendências como uma lista de ideias que estão aguardando para serem implementadas. Pense em um sprint ou uma iteração como um tempo ou trabalho definido que foi agrupado para a equipe do projeto implementar na solução.
Ao planejar um sprint ou uma iteração, você pode ser solicitado a ajudar a priorizar e estimar a quantidade de trabalho para um item de trabalho/problema na lista de pendências. Equipes diferentes usam abordagens diferentes para estimar o nível de esforço. Algumas usam horas, enquanto outras usam uma referência, como um tamanho de camiseta. Basicamente, para estimar um item, você pode categorizá-lo como pequeno, médio ou grande. Em seguida, as equipes usarão o tamanho para ajudar a agrupar itens para implementação em um sprint ou em uma iteração.
Os requisitos devem ser viáveis de implementar e não muito grandes, para serem concluídos em um único sprint ou iteração. Você pode dividir grandes necessidades em requisitos menores que podem ser mais fáceis de realizar. Algumas metodologias se referem a um requisito grande como um epic, que é a necessidade de alto nível antes de ser dividida em partes menores.
Frequentemente, os requisitos são considerados funcionais ou não funcionais. Os requisitos funcionais descrevem o que a solução precisa fazer ou seus comportamentos. Os requisitos não funcionais normalmente descrevem os aspectos sem comportamento da solução, como requisitos de desempenho. Para descrever completamente o que é esperado de uma nova solução, você deve ter requisitos funcionais e não funcionais.
Requisitos funcionais
Os requisitos funcionais devem se concentrar em quem, o que e por que do requisito. Por exemplo, "Como representante do SAC, preciso ser capaz de pesquisar problemas de clientes semelhantes que foram resolvidos, a fim de encontrar uma solução para o problema atual do cliente" descreve um requisito funcional do Microsoft Dynamics 365 Customer Service.
A maioria de seus requisitos funcionais virá dos usuários da solução finalizada.
Você pode usar requisitos não funcionais na captura de tópicos com os quais os usuários se preocupam, mas que são importantes para o sucesso da solução. Esses tipos de requisitos normalmente abordam tópicos como o desempenho da solução, a capacidade, a privacidade, a segurança e a conformidade.
Por exemplo, "O sistema deve lidar 2500 relatórios de problemas de entrada de cliente simultâneos durante interrupções " descreve um requisito não funcional do Dynamics 365 Customer Service.
Requisitos não funcionais
A maioria de seus requisitos não funcionais virá da equipe de TI ou de conformidade corporativa e não de seus usuários finais.
Os requisitos não funcionais devem ser claros sobre como medir e determinar o sucesso. Muitas vezes, os requisitos não incluem pontos iniciais e finais claros nas medidas para medir com precisão o sucesso. Também é comum incluir requisitos não funcionais fora do seu controle; é importante identificar esses requisitos e mitigar o risco com o cliente. Um exemplo desse cenário pode ser um requisito de desempenho de menos de um segundo em dispositivos móveis em campo.
Os requisitos não funcionais geralmente são de responsabilidade do arquiteto de soluções, que deve determinar como atendê-los. No entanto, um consultor deve ser informado dos requisitos não funcionais da solução. Em muitos casos, você pode ser solicitado a implementar uma alteração que dê suporte ao objetivo do requisito não funcional.
É importante reservar tempo para garantir que os requisitos sejam de alta qualidade e representem o que você concordou em fornecer. Em muitos casos, essa garantia pode fazer a diferença no sucesso da implantação do Dynamics 365 após a implementação dos requisitos.