jan 082014
 
É fato que Requisitos bem definidos dependem fortemente das técnicas empregadas durante as atividades de levantamento; por esta razão o Analista de Negócios (ou de Requisitos) deve possuir sólidos conhecimentos em diferentes técnicas que enriquecem a qualidade dos requisitos identificados, bem como aumentam a eficiência do processo de levantamento.
Neste post serão abordados alguns dos aspectos relacionados à qualidade dos Requisitos, com foco na forma de escrita dos mesmos.
Os Requisitos surgem em diferentes momentos, situações e em diferentes níveis de detalhamento/granularidade. Porém, em comum, os Requisitos são tipicamente descritos em linguagem natural (principalmente quando “nascem”, pois à medida que evoluem, muitos Requisitos demandam detalhamentos adicionais feitos na forma de fluxos gráficos, ou de protótipos, por exemplo)
E a linguagem natural pode ser altamente propícia a ambiguidades e distorções, a menos que  algumas ações sejam executadas e alguns comportamentos sejam adotados durante a escrita dos Requisitos para aumentar a clareza, qualidade e conteúdo dos mesmos, conforme tentamos introduzir nas 10 macro-recomendações deste post:
1. Evite ao máximo as ambiguidades: descreva termos de modo único; sempre que aplicável crie “glossários de termos” para explicar jargões, siglas ou conceitos que admitam múltiplas interpretações (como exemplo, a sigla CRM pode tanto representar o conceito de ‘Customer Relationship Management’quanto pode significar ‘Conselho Regional de Medicina’).
2. Evite sinônimos: seja coerente, utilize os mesmos termos do início ao fim da documentação de requisitos.
3. Seja explícito ao mesmo tempo que evita o re-trabalho: defina claramente cada conceito/termo utilizado na descrição dos seus requisitos e SEMPRE que possível DEFINA externamente os elementos que se repetem; deste modo se a definição do termo mudar, haverá somente um local a ser alterado E esse local deve ser referenciado nos requisitos que “consumirem” o conceito/termo.
4. Evite a mistura de assuntos ao declarar requisitos: Utilize frases curtas, diretas, objetivas, que se complementam quando necessário. Adicionalmente, o uso do termo “e” pode muitas vezes levar à fusão de conceitos; consequentemente, algo que deveria ser declarado através de 2 ou mais requisitos pode, erroneamente, ser declarado como um único requisito.
5. Lembre-se que ao escrever requisitos, “menos é mais”: é preferível adotar um vocabulário restrito, com termos que se repetem, ao invés de utilizar um vocabulário recheado de sinônimos e “elocubrações” (como reforço nos treinamentos ministrados pela OAT Solutions, o trabalho do Analista é técnico; documentos de Requisitos não são obras literárias) .
6. Evite termos amplos ou genéricos, tais como: “etc”, “entre outros”, “e assim por diante…”. Lembre-se que um bom requisito é COMPLETO (carrega todas as informações necessárias ao seu entendimento).
7. Teste seus requisitos contra o princípio LISO: novamente mencionando algo que é trabalhado intensivamente nos treinamentos ministrados pela OAT Solutions, é fato sabido que há alguns vilões durante as atividades de levantamento, descrição e validação de requisitos.
O acrônimo LISO sintetiza os termos “Lógico”, “Implícito”, “Subentendido” e “Óbvio”; geralmente quando estes termos surgem durante uma conversa sobre os requisitos é sinal de que alguma coisa está errada. Portanto testar, neste caso, significa verificar se o(s) requisito(s) está(ão) bem definido(s), ou seja, se não faltam informações que podem posteriormente se transformar em problemas de entendimento.
8. Evite o uso do termo “não…”: o cérebro humano tem grandes dificuldades em lidar com a descrição de restrições que envolvam a negativa (…não…), principalmente se houver a repetição da negativa (…não……..não…).
Ao invés disso, utilize termos enfáticos que demonstrem a restrição (por exemplo os termos EVITAR, IMPEDIR ou BLOQUEAR substituem com eficiência o uso do “não” na maioria das situações)
9. Evite requisitos “chumbados” (é verdade, esse termo não é dos mais bonitos, mas a situação de aplicação é extremamente prática e tem inúmeros impactos negativos): um requisito “chumbado” é aquele que faz referências externas sem declarar exatamente o que se espera que seja feito ou alcançado.
Por exemplo, suponha que o cliente queira que o sistema tenha uma funcionalidade de pesquisa de notas fiscais emitidas, que gere um relatório. Para demonstrar o que deseja, o cliente imprime um exemplo a partir de um relatório já existente em outro sistema, com layout ou formatação semelhante ao que deseja e formaliza a sua necessidade durante uma reunião, mais ou menos assim: “eu quero que o sistema tenha um relatório de Notas Fiscais emitidas, parecido com o relatório de Pedidos de Compra” – e entrega um exemplo impresso. Ao declarar o requisito, o Analista formaliza que “O sistema deve permitir a emissão de um relatório de Notas Fiscais emitidas”, porém ao descrever/detalhar, ERRONEAMENTE o analista informa que “o relatório deve ser semelhante ao que é gerado pelo sistema de emissão de pedidos de compra”. Para completar, aquele exemplo impresso pelo cliente é descartado (!) em algum ponto do caminho. O resultado é previsível, principalmente se houver a probabilidade de que o relatório que serviu de exemplo mude entre o momento em que o Cliente hipotético declarou sua necessidade e o momento em que ele irá efetivamente receber o relatório que solicitou; nesse cenário, alguns problemas são típicos: como testar ? como garantir que/se o relatório usado como base for modificado, ele ainda será visto como uma boa referência pelo Cliente ?
Portanto, lembre-se sempre de declarar O QUE se espera, ou seja, busque identificar e descrever o que está na essência da necessidade, ao invés de descrever elementos físicos. Novamente retomando o exemplo deste tópico, talvez o que o Cliente queira é que o relatório de Notas Fiscais permita identificar por cores diferentes o mês de emissão de cada Nota, ou ainda, que o relatório seja impresso de tal forma que o cabeçalho e descrição de cada nota sejam sempre impressos na mesma folha. Estes “desejos” e outros mais ficaram “implícitos” quando o Cliente usou como referência um outro relatório que continha essas características; porém se isso não for tornado explícito, o problema vai longe…

10. Para evitar esquecimentos, trabalhe com “check-lists” das atividades e boas práticas: certamente se você testar seus requisitos em relação aos princípios listados acima, já irá identificar inúmeros pontos de melhoria; e se essa verificação  não ocorrer antes da validação junto ao Cliente, é altamente provável que os “defeitos” contidos irão acompanhar a vida toda de cada requisito, gerando impactos provavelmente durante os Testes, ou ainda pior, após a aprovação do sistema pelo Cliente.

Enfim, ainda há muito mais a explorar no quesito “qualidade do requisito”, como será abordado em outros posts, mas há que se começar por algum lugar!

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>