Requisitos de Software: Uma abordagem customer-driven utilizando o que você já faz hoje

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.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s