Você sabia que requisitos de software podem estar relacionados ao sucesso ou fracasso de soluções digitais? Isso acontece porque eles representam as funções, propriedades e restrições que o software deve possuir para atingir o seu objetivo. Dentro da área de Engenharia de Software, um requisito é definido como uma descrição do que determinado sistema deve executar: reflete a necessidade do negócio sobre o produto digital.
Um software possui um conjunto de requisitos divididos entre Funcionais (RF) e Não Funcionais (RNF). Essa classificação facilita o seu entendimento, como veremos a seguir.
Requisitos Funcionais
Eles dizem respeito às funções e informações que o software deve possuir, ou seja, ao seu comportamento: a como ele deve reagir a entradas específicas, como ele irá se portar em determinadas situações, e até mesmo declarar o que o sistema não deve fazer.
Por exemplo: um aplicativo de uma instituição financeira, voltado ao cliente, deve ser capaz de realizar transações via PIX, de pagar boletos e de fazer investimentos. Esses são três requisitos do produto digital que permitem aos usuários a realização de tais funções.
Os Requisitos de Software Funcionais podem ainda ser classificados conforme seu nível: a diferenciação mais comum é em relação à requisitos de negócio, requisitos de usuário e requisitos técnicos.
Requisitos Não Funcionais
Eles, por sua vez, podem referir-se aos critérios que qualificam os requisitos funcionais: estão relacionados a qualidades específicas e restrições que o software deve atender, ou seja, não se referem a funcionalidades em si, mas fazem parte do escopo do produto.
Os Requisitos de Software Não Funcionais por vezes são chamados de atributos de qualidade, o que quer dizer que são uma definição estruturada e categorizada daquilo que é necessário para exprimir que um produto tem qualidade, de acordo com seu contexto específico.
Assim como os Requisitos Funcionais, eles subdividem-se em requisitos de produto, como confiabilidade, eficiência, portabilidade, usabilidade, desempenho e espaço; requisitos organizacionais, como de entrega, implementação e padrões; e requisitos externos, como interoperabilidade, éticos, de segurança, privacidade e legislativos.
Podemos exemplificar citando a adequação à LGPD, que é um RNF muito comum hoje em dia. Outro exemplo é afirmar que um software precisa ser multi-plataforma, operando em Android e iOS. Ou ainda, quando definimos que uma solução precisa utilizar criptografia, pois manipula dados sensíveis de usuários.
A Transversalidade dos Requisitos Não Funcionais
Para o time que está construindo o produto, os Requisitos Não Funcionais podem ser restrições, padrões a seguir, ou ainda exigir soluções bem específicas. É normal, por exemplo, que eles precisem ser resolvidos no nível da arquitetura do software e não na programação, porque os RNFs são ‘transversais’, ou seja, afetam todas as funcionalidades.
Certa vez, desenvolvemos um produto que possuía um Requisito Não Funcional muito crítico em relação à disponibilidade: a aplicação precisava operar 24×7, durante três meses, pois era uma das aplicações utilizadas na operação de um programa de televisão de reality show. Esse tipo de requisito exige uma análise arquitetural: é preciso identificar e remover pontos de falha, criar soluções de fall-back (plano b) e de recuperação automática. O requisito afeta até mesmo o hardware e a infraestrutura, que precisam trabalhar com soluções de alta-disponibilidade para que possam ser feitas manutenções sem impactos na disponibilidade do software.
Onde estão os requisitos?
Você já reparou que, apesar de ser um dos conceitos centrais na Engenharia de Software, não é mais comum ouvirmos falar de requisitos? Isso acontece porque eles acabaram associados a um modelo de trabalho cascata (Waterfall), burocrático e preditivo.
A culpa não é dos requisitos, mas sim dos profissionais: analistas que esperavam que o cliente ou o usuário definisse seus requisitos para, então, se apegar àquela lista até o momento da entrega. Não havia espaço para aprendizado, feedback ou mudanças estratégicas.
Quando o mercado de tecnologia evoluiu para as abordagens ágeis, focadas em produto, esse comportamento perdeu o sentido. A área buscou outras ferramentas que ajudassem a mudar a relação entre a equipe e os stakeholders, adotando conceitos como OKRs (Objectives and Key Results), métricas de produto, objetivos de negócio, histórias de usuário, BDD (Behavior Driven Development) e critérios de aceite.
Mas isso não significa o ‘fim dos requisitos’. Essas ferramentas representam mais uma evolução na forma de defini-los, assim como outras técnicas que já haviam surgido anteriormente. No caso das ferramentas atuais, elas têm as seguintes vantagens:
- São mais focadas no impacto no negócio e data-driven;
- São user-centered – focadas nas pessoas;
- São menos verbosas, mais focadas na interação do que na documentação;
- São mais colaborativas, porque o trabalho fica menos centralizado em um Analista, à medida que fica mais distribuído em um time interdisciplinar;
- São mais change-friendly, ou seja, criam uma dinâmica que aceita melhor as mudanças e evoluções do produto.
Quem define os requisitos e quando?
Isso depende do tipo de processo e de ciclo de vida adotado, dois conceitos que também vem da Engenharia de Software. Em um ciclo de vida mais antigo, era normal que os requisitos fossem definidos todos no início do projeto. Era comum usar o termo ‘coletar’ ou ‘elicitar’, ou seja: a ideia era que um Analista de Sistemas ou de Negócios iria obter requisitos dos usuários.
Hoje, nos métodos atuais, partimos de pressupostos um pouco diferentes. Entendemos que para produtos inovadores é impossível descobrir todos os requisitos no início do projeto; que o usuário precisa fornecer feedbacks de uso; e que é trabalho do time de produto traduzir esses feedbacks em requisitos.
Por esse motivo, a construção dos requisitos é colaborativa. A configuração varia muito, mas podemos ter um Product Manager (PM) atuando em nível de negócio, definindo visão de produto, métricas e objetivos de negócio. Já o Product Owner (PO), que está em contato direto com o time de desenvolvimento, facilita o processo de transformar os grandes objetivos em histórias de usuário. E o time, por fim, participa desse refinamento, à medida que é responsável por definir a solução técnica que atenderá às necessidades propostas.
