Business

Requisito ou Regra de Negócio?

Por: , novembro 5, 2013


Assim como outras disciplinas de TI, a Análise de Requisitos é uma composição de conceitos com linhas tênues entre eles. Os conceitos mais básicos dessa disciplina são comumente confundidos e, apesar de parecer não impactar muito no trabalho de desenvolvimento de software, confundir requisito com regra de negócio pode gerar uma boa confusão para quem está gerindo o escopo do projeto. E para os desenvolvedores também.

Vamos começar definindo o limite entre requisito e regra de negócio. Para simplificar:
Regra de negócio é o que define a forma de fazer o negócio, refletindo a política interna, o processo definido e/ou as regras básicas de conduta.  Ou seja, é um conjunto de instruções que os usuários já seguem e que o sistema a ser desenvolvido deve contemplar. Restrições, validações, condições e exceções do processo são exemplos clássicos de regras de negócio. Uma regra de negócio não necessariamente será refletida no sistema como uma funcionalidade, mas ela com certeza determinará o comportamento de uma ou mais funcionalidades do sistema.
Requisitos são instruções que definem como atingir o objetivo de negócio. Em geral, refletem funções que o usuário precisa realizar para atingir o objetivo do sistema ou funções de apoio à estratégia do negócio. Registros, controle de fluxo, consultas e cadastros são requisitos típicos. Em geral, requisito é algo que o usuário solicita explícitamente (ou requisita). O requisito é algo que reflete a forma como o usuário enxerga a solução para o seu problema, já convertida em fases do processo. É muito comum que os requisitos reflitam diretamente em telas e ações do sistema.Durante a atividade de extração ou detalhamento de requisitos, seja em entrevista ou observação do processo, o analista deve estar atento para identificar, nas entrelinhas, as regras de negócio ocultas. Como a maioria das pessoas já se habituou ao mundo informatizado, cabe ao analista identificar na lista de requisitos fornecida pelo usuário, aqueles requisitos que realmente são necessários para atingir os objetivos de negócio da forma mais simples.
É muito comum que o cliente já saiba o que quer: quais cadastros, quais telas e ações o sistema deve oferecer. Porém, os usuários tem muita dificuldade de fornecer as regras de negócio ao analista. Isto se dá por dois motivos, em geral: ou o usuário não acredita que seja possível informatizar aquela regra específica de negócio, por ser complexa ou depender de muitas variáveis, ou o usuário já está tão acostumado com a regra que toma como fato notório e não se lembra de citá-la nas reuniões.
Este cenário típico de desenvolvimento de software é o que demonstra a importância de entender bem a diferença entre os dois termos. Na prática, o nome que se dá é indiferente: o importante é que o sistema final atenda a todos os itens levantados.
Para efeito de documentação, eu gosto de usar a seguinte regrinha:

  1. Listar todas as solicitações do usuário.
  2. Identificar as necessidades de negócio “não faladas”.
  3. Avaliar o processo de trabalho e identificar se as solicitações estão alinhadas ao negócio e se fazem sentido frente ao problema apresentado pelo usuário.
  4. Rever a lista e validar se é a forma mais simples de solucionar o problema. Nesta fase, é interessante envolver algum desenvolvedor experiente.
  5. Para cada item identificar se ele define “o que” o sistema deve oferecer (requisito) ou “como” o sistema deve se comportar (regra).



Depois de listar todos os requisitos e regras, validar o processo com desenvolvedores e com o cliente, é hora de se perguntar: este é um sistema que deva ser informatizado? A resposta sendo sim – e na maioria das vezes é -, está na hora de olhar os requisitos de forma mais técnica.
Agora é o momento de subdividirmos os requisitos em Funcionais e Não Funcionais. Esta parte é mais fácil do que separar requisitos de regras, mas precisa que o analista tenha uma maior perspicácia. Por isto, muitos utilizam checklists ou perguntas simples para ter certeza de que os requisitos todos foram coletados. Vamos ver por quê:
Requisito Funcional é todo aquele que define o funcionamento perceptível do sistema pelos usuários. Telas, informações, relatórios, fluxo de negócio são requisitos funcionais.
Requisito Não Funcional é aquele que define os parâmetros de funcionamento do sistema, que trarão ao usuário uma melhor experiência no uso do sistema, porém não são diretamente acionados por ele. Nesta categoria estão os requisitos de arquitetura, desempenho, usabilidade, tempo de resposta, padrão de nomenclatura, entre outros.
Em geral, os usuários finais do sistema tem uma boa noção dos requisitos não funcionais desejados, porém, pela própria subjetividade deles, o usuário não os explicita diretamente. Ou, nos melhores casos, o usuário fala coisas como: “que o sistema seja rápido”, “fácil de usar”, “atalhos”, “esteja sempre disponível”, “não dependa de ninguém para usar”.
Em geral, o analista deve procurar usuários especializados para definir os requisitos não funcionais, como gestores de TI, administradores de rede ou de sistemas. Além disto, é interessante envolver alguém especializado em UX Design para fazer protótipos e entrevistas especializadas com o usuário, a fim de identificar os requisitos não funcionais.
Mas por que é tão importante identificar essas coisas? Bom, primeiro porque, atualmente, não existem mais usuários que não saibam o que é um sistema informatizado. Há anos somos bombardeados por sistemas de todos os tipos, direta ou indiretamente. E com a popularização da internet, todo usuário tem já uma expectativa de tempo de resposta e facilidade de uso. Isto porque o usuário médio de internet hoje já tem experiência com vários tipos de sistemas. E muitos tem como parâmetro as ferramentas da Google. E isto não é uma boa notícia para os desenvolvedores de sistema, já que o desempenho da ferramenta de busca e e-mail da Google é extraordinário.
Um dos maiores problemas que enfrentamos hoje em desenvolvimento de sistemas é que esquecemos de perguntar duas coisas ao usuário: sua expectativa em relação ao sistema e seus parâmetros de desempenho. A única coisa que perguntamos é o que ele quer que o sistema faça. E isto, em muitos casos, leva à frustação do usuário quando vê o resultado final do desenvolvimento.

  • Receba nosso conteúdo em primeira mão.