Este é um post dedicado ao tema da palestra que fiz ontem, dia 13 de agosto de 2019, na UFSC campus Araranguá-SC.
Na Engenharia de Software na disciplina de Engenharia de Requisitos temos por definição e conceitos os seguintes tipos de Requisitos de Software: Requisitos Funcionais, Requisitos Não Funcionais e Requisitos de Domínio. Não entrarei no mérito e no detalhe de cada um deles, pois isto pode ser encontrado em buscas na internet e diversos livros de Engenharia de Software, meu objetivo aqui é apresentar uma visão pragmática para o atendimento da disciplina no dia a dia.
No dia a dia e na realidade de muitas frentes de trabalho não nos preocupamos necessariamente em entender que tipo de requisito estamos atendendo naquela definição que estamos a desenvolver.
Na definição de um requisito, o que é importante de fato é:
PARA QUEM? e o POR QUÊ?
Como, partindo de um ponto A, chegaremos em um ponto B?
Quais são os elementos que estão no meio deste caminho e que precisamos conhecer para as tomadas de decisões e melhor estratégia de resolução daquele negócio?
Partindo desta perspectiva, podemos utilizar algumas metodologias que nos ajudem a entender melhor do contexto, realidade e situação posta, para que possamos projetar um cenário de solução futura. Dentre estas possibilidades está o processo de Design, representando pela imagem do “duplo diamante”
Encontramos, muitas vezes, problemas de comunicação entre os envolvidos no processo de definição e desenvolvimento de produtos. Pouco alinhamento entre negócio e tecnologia. Circunstâncias que um não fala “a lingua” do outro, onde cada um está com visões distintas sobre o andar da carruagem.
Requisitos de software devem habilitar o time a trabalhar, devemos manter o alinhamento e comunicação clara. Para isto, alguns modelos foram criados e estabecem os tipos de informações que precisamos comunicar.
Quem está solicitando… <quem?>
O que queremos… <o quê>
O resultado esperado… <por quê>
Com este direcionamento, temos a escrita de Histórias de Usuários e técnicas de BDD (Behavior Driven Development) + Especificação por Exemplos. Alguns detalhes sobre estes formatos podem ser acessados no post User Story My Story. Nele apresento o meu ponto de vista sobre a criação destas Histórias de Usuários e discuto sobre alguns exemplos.
É importante que tenhamos a clareza e a percepção que podemos evoluir, que podemos melhorar a cada dia a nossa experiência e como identificamos requisitos e como estes são expostos e disponibilizados para entendimento do time. Podemos acrescentar informações ou tipos de dados diferentes que possam nos deixar mais seguros para o entendimento da necessidade e comportamento esperado, como:
- Critérios de Aceitação
- Tabelas
- Matrizes
- Exemplos Reais
- Imagens
- Wireframes
- Vídeos
- …
Avance!!!
Busque a excelência!!!
Comece a escrever requisitos que contenham, no mínimo, os três fatores:
Para quem?
O quê?
Qual é o resultado esperado?
Entenda as reais necessidades de quem vai usar aquele Requisito de Software. Que tal utilizar Personas para isto?
Evite usar práticas novas que mudem drasticamente o que você faz hoje. Cadência na evolução é garantia e sucesso!
Mude de forma evolucionária e não de maneira revolucionária.
Diraci Junior 