Gerenciamento e Comunicação dos Requisitos - Análise de Negócios

Esta área é se não umas das mais criticas, pois não se trata apenas de notificar ou informar os envolvidos no processo, pois nos projetos em que você atou ou atuará com certeza verá uma equipe de pessoas envolvidas em diversas áreas, isto significa que todos os envolvidos devem ter o conhecimento nivelado. 

Por exemplo se em um projeto de desenvolvimento de software, para uma área jurídica, será preciso que o Analista de Negócio (AN), entenda o problema a ser solucionado, utilizando a Eliciação nesta fase. Porém quando  AN for transmitir o conhecimento obtido com a área solicitante e dizer ao setor de Ti que: " A jurisprudência xpto nos dá uma visão sobre como o sistema deverá se comportar" ou "A nova lei 0000-00 impacta diretamente o registros ABC".


A equipe de Ti não irá entender o que deverá ser feito, por isso o conhecimento sobre o que será feito deve ser feito em um nível de entendimento comum entre as partes interessadas.

Mas porque o AN deve gerenciar e comunicar estes requisitos?

Bom por definição no Babok: 

O gerenciamento dos requisitos ajuda a entender os efeitos das mudanças e as ligações entre os objetivos e metas dos negócios com a solução que de fato é construída e entregue.

Neste trecho me ocorreu a ligação direta com o uso do Scrum para a construção alinhada aos objetivos, voltado ao negócio, que no final será entregue a solução ou parte dela - trabalho continuo.

Como todo o processo conduzido pelo AN, ele precisa ter métricas para saber como anda esta fase é preciso ter em mãos o Planejamento e Monitoramento da Análise de Negócios.

Esta área de conhecimento é sub-dividida em cinco partes sendo elas:

1. Gerenciar o Escopo e os Requisitos da Solução
2. Gerenciar Rastreabilidade dos Requisitos
3. Manter Requisitos para Reutilização
4. Preparar o Pacote de Requisitos
5. Comunicar Requisitos

Gerenciar o Escopo e os Requisitos da Solução

Entrar em consenso geral com os envolvidos sobre o escopo neste momento que será ser genérico e como os requisitos serão implementados. Os requisitos deverão ser aprovados pelas partes interessadas, sendo que o(s) aprovador(es) devem ter autoridade para tal atividade, que eles possam também auxiliar nas questões que surjam durante o andamento do projeto.

Vale ressaltar que os requisitos são mutáveis, ou seja, o trabalho do AN é um ciclo e sempre deverá revisar e evoluir os requisitos.

É importante nesta fase o AN ter bem definido o escopo da solução para que possa ser encaminhado para a elaboração dos requisitos, as pessoas e as suas responsabilidades, veja a matriz RACI neste tópico Planejamento e Monitoramento da Análise de Negócios.

Gerenciar Rastreabilidade dos Requisitos

É altamente recomendável que os requisitos sejam rastreáveis, o que isso significa? 

Quando temos um cenário de mudança de requisito é extremamente importante que possa ser identificado o que será impactado na mudança do mesmo, como exemplo ser alterarmos um requisito que altera a rotina que efetua o pagamento ou recebimento de contas de uma empresa.

Não é apenas uma alteração, mas Contas a Pagar e o Contas a Receber são itens muitos importantes para o fluxo de caixa e para a saúde financeira de uma empresa.

Eu recomendo - pois já utilizei - o uso da ferramenta Enterprise Architect da Sparx Systems, não ganho nada com a indicação, existem outras ferramentas - comente caso tenha outras sugestões neste post.

O EA como é chamado, lhe possibilita o uso de diagramas da UML que é uma linguagem internacional para anotações, estrutura de aplicações, criações de modelos, etc, o grupo mantenedor é o Object Management Group (Grupo responsável pela normalização dos objetos na UML) 

Um dos grandes motivos para realizar a rastreabilidade é a análise de impacto que a mudança poderá impactar no projeto, quais os recursos necessários para resolver a nova demanda - mesmo que apenas na identificação é preciso identificar o que será preciso para solucionar o problema. 

Manter Requisitos para Reutilização

A organização dos requisitos e a forma que é conduzido o processo de documentação é possível identificar qual(is) requisito(s) são reusáveis. Com esta identificação é preciso tomar um certo cuidado, pois este item será otimizado e poderá também ser uma parte frágil do sistema dependendo do modo que for conduzido.

Requisitos que permitem reuso precisa de certa forma ser nomeado de modo claro e objetivo para que outros AN's possam ter consciência da importância deste para o projeto.

Todos os requisitos possuem especialistas, sendo eles o AN, o Especialista no assunto  e o Especialista na implantação da solução de modo geral.

O AN não pode tomar partido de nada sem consultar  os demais Especialistas, pois como "tradutor" da necessidade do cliente para o "tequineis" ele precisa estar amparado pelos Especialistas. 

Preparar o Pacote de Requisitos

Uma vez que todos os requisitos foram mapeados já é possível criar um pacote dos requisitos que serão utilizado no desenvolvimento do sistema.

O importante neste fase é que o requisito seja compreendido pelas partes interessadas, sendo claros, precisos e a documentação dos requisitos devem ser criadas como a extensão dos mesmos.

Neste caso o Scrum prega o desenvolvimento do sistema sem qualquer requisito escrito e o Product Owner deve fazer depois ou durante o desenvolvimento do mesmo, em minha opinião pessoal acho um risco muito alto, visto que requisitos que possuem reuso podem gerar impactos de grandes proporções e se não temos como rastrear algo que não foi escrito, como saber o impacto?

O que acredito que seja interessante é o AN fazer a documentação apresentar ao time de desenvolvimento e o time realizar a Sprint, enquanto ao AN prepara a documentação para a próxima semana.

O AN deve apresentar os requisitos as partes interessadas, realizando reuniões, utilizando o Power Point, matriz Raci, enfim tudo o que foi construído até o momento para que o pacote seja aprovado.

Comunicar Requisitos

Uma vez que o pacote foi fechado é tarefa do AN comunicar as partes interessadas este pacote, que poderá conter, conversas, documentos, todo e qualquer artefato que foi utilizado para a construção do mesmo.

É possível utilizar apresentações para definir em conjunto com os envolvidos quais os padrões de qualidade interna do projeto e como esta será respeitada, para aprovação dos itens, para entregas, etc..

Existem também algumas técnicas disponíveis no Babok no capítulo 9.

Espero que tenha dado uma noção de como funciona o Gerenciamento e Comunicação dos Requisitos, o assunto é vasto e posso ter me esquecido de citar alguma coisa, para uma mais profunda abordagem do assunto recomendo a você a leitura do capítulo 4 do Babok, lembrando que temos o link direto para o Babok ao lado direito do site.