5 dicas para a sua documentação de requisitos gerar valor

Há alguns anos atrás a análise de requisitos era um tanto renegada no mercado de desenvolvimento de software, onde alguns profissionais diziam que encareciam muito um projeto e não geravam valor. Mas nos últimos anos essa realidade tem mudado. Os números demonstram que projetos com análise e especificação de requisitos agregam valor para o desenvolvimento e para o negócio e o seu valor é justificado.  

Mas é claro, é melhor não ter nenhuma documentação escrita do que ter uma especificação que não faça sentido para o projeto. Então, para lhe ajudar a entregar valor com sua documentação eu reuni cinco dicas para lhe auxiliar nessa tarefa. Mas como não existe “Bala de Prata” na engenharia de requisitos, você deve seguir aquelas que fazem sentido para a sua realidade e negócio.  

1 – Padrão de documentação 

 

 

Padronizar os documentos de requisitos do seu projeto é importante para guiar os analistas durante a especificação. Uma vez que não terão que perder tempo na hora da criação de um novo documento. A padronização também agrega valor para os desenvolvedores que recebem esses documentos na hora do desenvolvimento, pois eles já conheceram a estrutura do documento e sua navegação se tornará mais eficiente.  

O primeiro passo para criar um padrão de documento é criar uma estrutura de tópicos bem definidos e descrever a sua finalidade para guiar o analista no preenchimento da documentação.

Exemplos de tópicos:

• Índice
• Riscos
• Premissa
• Escopo da funcionalidade que será descrita no documento
• Requisitos funcionais
• Requisitos não funcionais (Confira o que são requisitos não funcionais aqui)
• Regra de negócios
• Mensagens, entre outros.  

Vamos supor que colamos o tópico “Restrições” no modelo padrão de documento. Logo abaixo descreva a sua finalidade. E quando o documento for preenchido, este texto deverá ser apagado. 

Restrições 

Explicação de qualquer limitação, que limita a solução. Podem ser políticas corporativas, as limitações  de hardware, tecnologias específicas, etc. 

É possível utilizar a estrutura de tópicos, mesmo se estiver trabalhando com uma documentação mais enxuta.  

2 – Desenhe o processo 

 

Fluxos de processos são interessantes pois facilmente você consegue explicar um processo de forma simples e clara que todos possam entender. É uma linguagem que tanto pessoas técnicas como as de negócios irão entender o que o processo quer dizer. Utilize notação como o BPMN (Business Process Modeling Notation).  

A Notação de modelagem de processos de negócio (BPMN, em inglês) é um método de fluxograma que modela as etapas, de ponta a ponta, de um processo de negócios planejado. Peça-chave na gestão de processos de negócios, representa de forma visual uma sequência detalhada de atividades de negócios e fluxos de informação necessários para concluir um processo. 

Da perspectiva do alto nível, a BPMN é destinada a participantes e outras partes interessadas em um processo de negócio para aumentar sua compreensão por meio de uma representação visual prática das etapas. Em um nível mais envolvido, é orientada a pessoas que implementarão o processo, fornecendo detalhes suficientes para permitir a implementação precisa. Ela fornece uma linguagem padrão comum para todas as partes interessadas, seja técnica ou não técnica: analistas de negócios, participantes do processo, gerentes e desenvolvedores técnicos, bem como equipes e consultores externos. Idealmente, ela preenche a lacuna entre a intenção e a implementação de processos, fornecendo detalhes e clareza suficiente na sequência de atividades empresariais. 

A diagramação é muito mais fácil de entender do que o texto narrativo. Ela permite a fácil comunicação e colaboração, resultando em um processo eficiente que produz um resultado de alta qualidade. Ela também ajuda na comunicação com documentos XML (linguagem de marcação extensível), necessários para executar vários processos. Um padrão principal XML é chamado de BPEL ou BEPEL4WS, ou seja, linguagem de execução do processo de negócios com definições de serviços web. (Fonte: Lucid Chart – O que é BPMN) 

3 – Protótipos 

 

Protótipos são amplamente utilizados em muitas indústrias. Na engenharia por meio de maquetes, na indústria automobilística por meio de protótipos. Assim como nesses outros negócios os protótipos servem para a validação de ideias, na indústria do desenvolvimento de software não é diferente.  

Protótipos são extremamente importantes para o alinhamento de expectativas, construção de algo que realmente irá gerar valor e ser utilizado pelo usuário final e também tirar o usuário no mundo da imaginação e dar algo palpável para ele ver se a solução irá realmente atender seu problema com eficácia.  

Existem alguns tipos de protótipos: 

• Sketch: São protótipos em forma de rabiscos e rápidos de fazer. São utilizados para validação de ideia; 
• Wireframes: Utilizam estruturas básicas de telas utilizando formas geométricas e utilizam o desenho e layout próximos do produto final; 

• Mockups: Utilizam componente realistas com a representação de acordo com o produto final, por isso é muito utilizado para a validação do resultado; 
• Protótipos funcionais: Possuem as mesmas características dos mockups, no entanto, é possível interagir com esse tipo de protótipo de forma que se pode ter uma experiência próxima da aplicação real e testar de forma mais assertiva se a necessidade será atendida.
  

Você deve utilizar aquele tipo que fizer mais sentido para a sua necessidade, mas você pode utilizar os três ao mesmo tempo. Você pode iniciar com sketch e evoluir a mesma ideia até um protótipo funcional para finalizar a concepção de uma nova ideia. Vai da necessidade de seu cliente, usuário e momento do seu projeto. 

4 – Exemplos de resultados esperados 

 

Algo que agrega valor para os requisitos são exemplos de resultados esperados de regras de negócios e dos processos descritos. Principalmente para os desenvolvedores e testers, pois para eles fica mais fácil de entender determinadas regras.  

Além de ser muito útil para os desenvolvedores, é um importante artefato para você validar as regras que estão escritas no documento com o seu cliente. É uma forma de demonstrar qual será o resultado que determinada funcionalidade irá retornar.  

Para isso, você pode utilizar Gherkin, que é uma linguagem para descrever comportamentos. Você pode conhecer mais sobre ela em Aqui. 

Exemplo: 

Funcionalidade: Algum texto descritivo conciso do que é desejado 

A fim de realizar um valor de negócio 

Como ator explícito do sistema 

Eu quero ganhar algum resultado benéfico que promova a meta 

 

Texto adicional… 

 

Cenário: Uma determinada situação de negócios 

Dado uma pré condição 

E uma outra pré condição 

Quando uma ação é feita pelo ator 

E uma outra ação 

E outra ação diferente 

Então um resultado testável é alcançado 

E outra coisa que possamos verificar também acontece 

 

Cenário: Uma situação diferente 

… 

5 – Verificação em pares 

 

Depois que os requisitos estão concluídos, é interessante que alguém revise seus requisitos. Para o fim de ver algo que o autor não conseguiu visualizar e não com a finalidade fiscalizadora. Essa verificação deve ser para agregar valor e garantir a entrega com qualidade. 

Uma dica é que essa verificação seja feita por alguém, além do cliente, do time de desenvolvimento ou homologação, se possível um outro analista de requisitos. Por exemplo, o desenvolvedor poderá identificar itens que impactam a viabilidade técnica, a homologação poderá encontrar impactos em outras partes do sistema que não foi previsto no requisito e o outro analista poderá verificar aspectos de negócio. Mas vale dizer que é importante a participação desse papéis durante a construção do requisito.  

Conclusão 

“There is no silver bullet” como já dizia Fred Brooks, em seu artigo sobre não existir uma bala de prata que solucione todos problemas do desenvolvimento de software. Mas com essas dicas lhe dará ferramentas para enfrentar os problemas do dia a dia e solucionar alguns problemas além do principal que é a entrega de valor que seu cliente perceba. Com esses processos implantados é importante que eles sejam constantemente revisados e melhorados. Melhoria contínua sempre. E para você se aperfeiçoar como engenheiro de software, uma última sugestão é a certificação CPRE-FL de engenharia de requisitos, neste post eu explico como ela funciona!

Até a próxima!