Como fazer um levantamento de requisitos eficaz para qualquer aplicação

Antes de começar a desenvolver uma aplicação (seja ela qual for), é importante fazer algum levantamento de requisitos. Isso é intuitivo, certo? Pra programar precisamos saber o que estamos fazendo e como deve ser feito.

Mas, claro, tem mais de um jeito de fazer isso e se você pesquisar na internet vai encontrar algumas técnicas e diagramas complexos, que podem ser teóricos ou mesmo “verbosos” demais para o seu contexto.

Neste post, o meu objetivo é trazer uma abordagem prática, que usei no meu último projeto e recomendo para aplicações de pequeno e médio porte (pode ser que funcione perfeitamente para aplicações de grande porte, mas não tenho propriedade pra afirmar isso com base em experiência própria).

Requisitos: não é tudo a mesma coisa

Primeiramente, é importante entender que conseguimos dividir “requisitos” em três principais categorias: requisitos funcionais, requisitos não-funcionais e regras de negócio. Ter isso em mente facilita muito a coleta dos requisitos e divisão de responsabilidade do código.

Requisitos Funcionais

Os requisitos funcionais (carinhosamente apelidados de RF) são o nosso “o que”, o que o cliente quer que o programa faça. Como o próprio nome sugere, dizem respeito às funcionalidades do mesmo. Mais formalmente, essa é parte da definição no Wikipedia:

Em engenharia de software, um requisito funcional define uma função de um sistema de software ou seu componente. O requisito funcional representa o que o software faz, em termos de tarefas e serviços.

Alguns exemplos reais de RFs do último sistema que desenvolvi são:

• O usuário deve poder listar todos os Clientes, filtrando por nome ou CPF
• O usuário deve poder cadastrar uma Ordem de Serviço enviando o nome do produto, modelo…
• O usuário deve poder listar as entradas e saídas para um dia específico

Uma observação interessante é que todos se iniciam com “O usuário deve poder”, reforçando a visualização deles como tarefas que o usuário será capaz de executar uma vez que o sistema estiver de acordo com o esperado.

Note que os RFs não contêm nenhuma informação sobre qual tipo de banco de dados deve ser usado, qual a lógica para lidar com um Cliente duplicado, etc. Isso são requisitos de outros tipos, que veremos a seguir.

Requisitos Não-Funcionais

Os requisitos não-funcionais (carinhosamente apelidados de RNF) são o nosso “como”, como vamos fazer funcionar “por baixo dos panos” aquilo que o cliente espera do programa. Segundo a definição do Wikipedia:

Requisitos não funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas.

Alguns exemplos reais de RNFs:

• Deve ser criada uma tabela de Ordens de Serviço
• Deve ser criado um campo de ID do tipo UUID
• Deve ser criado um campo Tipo que pode ser:
  • 0: Normal
  • 1: Retorno
• Deve ser criada uma relação com um Cliente específico (One-to-Many: um Cliente pode ter várias OS’s).

No caso desse sistema, não haviam requisitos no sentido de velocidade, por exemplo. Os RNFs acabaram girando em torno da infraestrutura do banco de dados (coisas que o cliente provavelmente não tem contato, portanto “não-funcionais”).

Veja como todos se iniciam com a palavra “deve”, não deixando ambiguidade sobre o resultado esperado.

Regras de Negócio

As regras de negócio (carinhosamente apelidadas de RN — não confundir com React Native ou Recém-Nascido 😂) são a lógica que precisamos seguir quando desenvolvendo as funcionalidades. Pela definição do Wikipedia:

Regras de Negócio são declarações sobre a forma da empresa fazer negócio. Elas refletem políticas do negócio.

Ok, talvez com a definição não tenha ficado totalmente claro, então seguem alguns exemplos:

• O usuário não deve poder alterar o tipo de uma Ordem de Serviço

• O usuário deve confirmar seu login e senha para cancelar uma Ordem de Serviço

• Cada Ordem de Serviço deve possuir um “número” único

Esses requisitos podem ser bem diversos, e geralmente são específicos do nicho e da realidade da empresa. Se você quiser saber um pouco mais sobre o que aprendi aplicando isso, sugiro este post.

Como coletar os requisitos

Beleza, você entendeu a “aparência” dos requisitos e os critérios pelos quais eles são divididos. Mas como podemos obtê-los? Primeiro como não devemos obtê-los: puramente da nossa imaginação.

Isso porque, como desenvolvedores(as), fazemos software para alguém, e essa pessoa (ou grupo de pessoas) tem muito mais conhecimento sobre o próprio dia-a-dia do que nós teremos apenas pela intuição ou observação.

Portanto, o método mais comum para levantamento de requisitos é o diálogo, através de uma espécie de entrevista na qual se busca conhecer os problemas, necessidades e expectativas do cliente.

Isso pode ser difícil, porque na maioria das vezes você estará se comunicando com uma pessoa que tem conhecimento na área em que atua, não em programação. Então o seu papel é “traduzir” os desejos em funcionalidades concretas para o software.

Como organizar os requisitos

A partir deste levantamento, é possível montar um documento (seja no papel ou num arquivo de texto) que sintetize os requisitos funcionais, não-funcionais e regras de negócio.

A organização que gosto de seguir é citar as funcionalidades macro da aplicação e, para cada uma delas, enumerar os RFs, RNFs e RNs correspondentes. Dá uma olhada no exemplo:

# Funcionalidades Macro do Backend

**Legenda:**

- **RF:** Requisitos Funcionais
- **RNF:** Requisitos Não Funcionais
- **RN:** Regras de Negócio

## Funcionalidades
- Cadastro e atualização de Clientes
- Cadastro e atualização de Ordens de Serviço (OS)
- Entradas e Saídas no Caixa
- Usuário

## Cadastro e atualização de Ordens de Serviço (OS)

### RF
- [x] O usuário deve poder **listar todas as OS's**, filtrando por:
  - Número (string) (opcional);
- [x] O usuário deve poder **mostrar uma OS**, incluindo todas as transações relacionadas a esta OS (para saber o que foi pago antecipadamente pelo cliente)
- [x] O usuário deve poder **cadastrar uma OS normal** enviando:
  - ID do Cliente (uuid) (obrigatório)
  - Tipo (int) (obrigatório)
  - Nome do produto (string) (obrigatório)
  - ...
- [x] O usuário deve poder **atualizar os dados da OS**
- [x] O usuário deve poder **cancelar uma OS**
- [x] O usuário deve poder **deletar uma OS**, confirmando suas credenciais

### RNF
- [x] Deve ser criada uma *tabela* de Ordens de Serviço
- [x] Deve ser criado um campo de *ID* do tipo UUID
- [x] Deve ser criado um campo *Tipo* que pode ser:
  - 0: Normal
  - 1: Retorno
- [x] Deve ser criada uma *relação com um Cliente específico* (One-to-Many/Many-to-One: um Cliente pode ter várias OS's).

### RN
- [x] Os campos de valor não podem ser negativos
- [x] Cada OS deve possuir um "número" único.
- [x] O usuário deve confirmar seu login e senha para cancelar uma OS
- [x] O usuário não deve poder alterar o tipo de uma OS

...

[Demais funcionalidades macro]

Tenha em mente que, para uma determinada funcionalidade macro, pode não haver algum RNF, por exemplo. Outra questão que costuma surgir é a separação nas categorias (“isso é RF ou RN?”, por exemplo). Quando isso acontecer, faça um esforço para tentar categorizar “corretamente”, mas não se prenda a isso.

O importante é que esse documento ajude você — e a sua equipe, se estiver programando com mais pessoas — a compreender a visão que o usuário final tem do software e como desempenhar seu papel da melhor forma possível.

Você tem alguma dica para fazer um bom levantamento de requisitos? Compartilha aí nos comentários!

E manda esse post pra alguém que vai gostar de aprender sobre esse tema :)