Artigos Java Requisitos e Casos de Uso x User Story

Por que eu devo ler este artigo:Conhecer as diferentes técnicas de especificação de requisitos utilizadas atualmente é crucial para sobreviver em um mercado de TI que frequentemente vem exigindo profissionais capacitados e que saibam trabalhar ora em ambientes formais e sob regimento de normas e padrões rigorosos, ora em projetos que usam modelos de metodologias de desenvolvimento ágeis e flexíveis, mas sempre sem perder a qualidade.

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 ...

Quer ler esse conteúdo completo? Tenha acesso completo