Esse artigo procura abranger as técnicas mais conhecidas para identificação e registro de requisitos (Especificação de Requisitos de Software, Casos de Uso e User Stories), buscando a essência do assunto e mostrando as diferenças e semelhanças em cada técnica.
Ele não tem a intenção de definir uma técnica em detrimento de outra, mas pelo contrário, permitir que o leitor consiga, por si só, aplicar a melhor técnica para o projeto ou processo de desenvolvimento de software mais apropriado, com embasamento teórico e exemplos de aplicação.
Em algum momento na carreira de um analista de negócios, analista de sistemas ou desenvolvedor, eles acabam se deparando com alguns dilemas ou com a dificuldade em escolher ou entender as diferentes técnicas para registrar os pedidos dos usuários.
Independente se você pratica uma metodologia de desenvolvimento de software mais formal ou mais ágil, a qualidade do que se entrega é fundamental. Porém, o que é qualidade senão entregar o que foi solicitado e especificado para atender uma necessidade ou resolver um problema do usuário.
Pensando nisso, não podemos evitar de ter que adotar umas práticas de descoberta e registro dessas solicitações e especificações para nos guiar durante o ciclo de software e para garantir que estamos entregando exatamente o que foi acordado entre duas partes, ainda que, obviamente, mudanças possam ocorrer, pois claramente as solicitações e especificações do software vão se tornando mais próximas da solução à medida que avançamos no tempo em um projeto de software.
É natural identificarmos mudanças ou adequações necessárias tanto para que o software funcione conforme esperado quanto para que o nosso usuário saia satisfeito com o produto que recebeu. Agora imagine não ter nenhuma base de referência e deixar isso somente pelo que está na cabeça do desenvolvedor, que pode ter entendido uma coisa completamente diferente do que o usuário está pensando. Uma origem comum dos problemas citados são acordos que usam somente a comunicação verbal e que muitas vezes são falhos.
Ao contrário do que pensamos, a comunicação verbal possui muitas falhas devido ao fato de ter como guia regras de moral ou polidez que impedem um pensamento analítico e estruturado.
Veja, por exemplo, quando tentamos falar com uma pessoa procurando ser extremamente explícitos e diretos no que queremos dizer e como pode soar estranho, quando não, mal-educado: “Preciso que você identifique os pedidos dos clientes para que você possa registrá-los e garantir que você não esquecerá do que foi solicitado pelo cliente e que as demais pessoas entendam o que você está fazendo”.
É óbvio que não falamos dessa maneira, por educação e também para soar menos autoritário e mais amigável. Por outro lado, esse excesso de polidez e até a própria estrutura da língua exige um texto que muitas vezes pode-se tornar ambíguo.
Veja no exemplo a seguir como o texto pode soar estranho: “Maria devolveu a José o seu livro”. De quem era o livro? De Maria ou de José.
Observe mais alguns exemplos de ambiguidade:
· “Roberto e Cláudia vão se divorciar”. Um vai se divorciar do outro ou ambos vão se divorciar dos respectivos cônjuges?
· “Eles viram os animais quando estavam presos”. Quem estava preso? “Eles” ou os animais?
· “Frederico encontrou Godofredo na rua e lhe disse que seu primo estava em casa”. O primo de qual dos dois está em casa?
O que acontece em geral é que recebemos instruções ou pedidos de maneira muito informal, sucinta e sem detalhes suficientes para que o entendimento seja o mesmo entre os envolvidos, levando a solicitações com detalhes omitidos ou subentendidos.
Essas omissões podem ter diversos motivos, a saber:
1. O usuário não quer transparecer que não sabe o detalhe;
2. O usuário espera ser questionado quanto ao detalhe, pois acredita que não é sua responsabilidade ter que identificá-lo;
3. O usuário pensa que o desenvolvedor ou analista já conhece o detalhe porque supõe que o mesmo tenha experiência e conhecimento do produto ou do negócio em questão.
Sendo assim, registrar os pedidos e especificações do software que iremos desenvolver passa a ser essencial para evitarmos essas e outras armadilhas de entendimento.
Porém, nada é tão simples. Devido à
variedade de ...
