Requisitos de Software – o que realmente é isso?
Achar uma definição objetiva e exata para a palavra “requisito” é difícil. A palavra possui alguns significados (conforme os dicionários), mas chega a ser um pouco abstrata. Mas basicamente, quando falamos de requisito, estamos falando de necessidade, exigência, desejo, solicitação.
Levando esta palavra para o contexto de um software, estamos falando de necessidades de um usuário, exigências do negócio, desejos da empresa, solicitação da empresa, tudo isso devendo ser realizado por um sistema, ou seja, o software deverá atender estas necessidades, exigências, desejos e solicitações, e materializar isso em um sistema.
Requisitos como ferramentas
Acho legal pensarmos no software como uma caixa de ferramentas, onde cada ferramenta contida dentro desta caixa é uma funcionalidade, que atende um ou mais requisitos do sistema.
No escopo de um software é comum se ter muitos requisitos, e por uma questão de método, estes requisitos são agrupados e trabalhados conforme seus objetivos.
Entendemos que requisitos possuem um objetivo só, que é atender a uma exigência informada por alguém, mas a natureza de tal exigência pode ser diferente para cada requisito.
Em função disso separamos e trabalhamos os requisitos conforme a natureza de cada um, conforme o tipo de cada necessidade, o tipo de cada requisito.
Na Engenharia de Software existe um hábito de se categorizar demais, de se classificar demais, e isso torna os métodos/processos aplicados muito inchados, com muitas coisas para fazer (em termos de documentação por exemplo), coisas que nem sempre geram valor na produção final de um sistema.
Isso ainda é uma realidade, infelizmente, mas percebo que é uma realidade que tem ficado mais no campo da teoria, não mais indo para a prática como acontecia nas décadas pretéritas.
/* A Engenharia de Software é uma ciência/área de conhecimento relativamente nova. Tudo começou formalmente na década de 1960, então estamos falandode uma área de conhecimento com menos de 70 anos. Áreas como a engenharia civil já existem há mais de 3000 anos, apenas para comparação. Qualquer área de conhecimento que surge começa no caos até que se conheça melhor o todo e suas partes, para daí se buscar sair do caos e ir para a ordem. Mas quando essa busca pela ordem começa, todos querem organizar tudo, e geralmente utilizam-se métodos e processos para isso, baseando-se consciente/inconscientemente no método científico. E neste momento é natural o exagero na burocracia. Tempos depois, chega-se ao equilíbrio. Estamos vendo isso na Engenharia de Software hoje com os métodos ágeis, que pregam menos burocracia e mais software executável para geração de valor, muito diferente do que tínhamos na década de 90, que era a tentativa de organizar o caos que se criou nas décadas de 70/80/90 a um custo proibitivo em termos de burocracia. */
A literatura e a prática
Algumas literaturas definem diversas classificações/tipos para requisitos: requisitos de sistema, requisitos de software, requisitos emergentes, requisitos de produto, requisitos de projeto, requisitos de processo, requisitos de teste etc. E na prática, no dia a dia nas fábricas de software, nos projetos e nas operações das empresas, fica claro que quanto menos “denominações” existirem mais simples ficam as coisas e mais objetivas e rápidas também.
Eu defendo e acredito que em projetos de software é mais do que necessário haver apenas três tipos de requisitos: requisitos funcionais, requisitos não funcionais e regras de negócio.
/* Na literatura de engenharia de software, de um modo geral, regras de negócio não são tratadas como requisitos, em vários casos nem são mencionadas. Mas eu as coloco no mesmo nível de importância que os requisitos funcionais e não funcionais, pois sem elas não existe sistema, sem elas não existem requisitos funcionais. */
Os tipos de Requisitos
Abaixo segue a visão que citei anteriormente, para requisitos de software e seus elementos:
Na imagem, o que temos é uma especialização de requisitos de software.
O “requisito de software” é o tipo mais genérico (generalização), e “Requisito Funcional”, “Regra de Negócio” e “Requisito Não-Funcional” são tipos mais especializados (especialização).
Conceitualmente falando, um sistema nada mais é que: um escopo, dividido em módulos, cada módulo com seus requisitos funcionais e regras de negócio, e requisitos não funcionais fora dos módulos, permeando todo o sistema. Abaixo uma figura ilustrando um pouco dessa decomposição das partes, no todo que é o software.
Entendendo melhor cada tipo de requisito
Abaixo, veja em detalhes cada um dos três tipos de requisitos abordados neste post (requisito funcional, requisito não-funcional e regra de negócio):
Requisito Funcional
Requisito Não-Funcional
Regra de Negócio
Bom, basicamente é isso. Espero que o conteúdo tenha sido útil.
Abraços!