Blog

O desenvolvimento de um software é um processo complexo, composto por várias etapas essenciais e dependentes entre si. Entre elas, a escrita dos requisitos destaca-se como uma das mais importantes, pois nela, define-se as necessidades do cliente, o estabelecimento de regras e funcionalidades para a construção de uma solução eficaz e que atenda as expectativas do usuário.

Importância da Análise e Especificação de Requisitos

Sendo um dos pilares da engenharia de software, seu objetivo principal é compreender as necessidades do usuário, suas regras e processos de negócio, além de documentar todas as informações detalhadamente.

Estudos revelam que cinco dos oito principais fatores de falha em projetos de software estão diretamente relacionados a requisitos, tais como:

• Requisitos incompletos;

• Baixo envolvimento do cliente (pesquisa com usuários);

• Expectativas não realistas (resultados previstos sem ligação com os requisitos);

• Mudanças nos requisitos;

• Requisitos desnecessários.

A falha na comunicação entre o time de desenvolvimento e o cliente pode comprometer o sucesso do projeto, tornando a clareza e a precisão na definição de requisitos indispensáveis. 

Mas afinal, o que é Requisito?

Considerando a etimologia da palavra, podemos dizer que a palavra "requisitos" vem do latim requisītu-, que é o particípio passado do verbo requirĕre, que significa "requerer".

A palavra "Requisito" é um substantivo masculino que significa uma condição necessária para se conseguir algo ou para alcançar um determinado propósito.
Já de forma literal, um requisito pode ser definido como: 

De maneira prática, é tudo o que o software deve oferecer ou executar para atender às expectativas do cliente/usuário final.

Etapas e Processos de Levantamento de Requisitos 

A análise/escrita de requisitos pode ser dividida em duas macro etapas:

1. Levantamento ou Identificação (Discovery):

Os requisitos são identificados a partir do conhecimento do problema e do domínio do negócio. Para isso, algumas técnicas são utilizadas para obter informações sobre as funcionalidades e restrições do sistema, sempre com o envolvimento do cliente.

A comunicação transparente entre analistas, clientes e usuários finais é essencial para garantir um levantamento preciso.

As principais técnicas utilizadas para escrever requisitos incluem:

• Entrevista: O analista conversa diretamente com o cliente que utilizará a ferramenta ou software, fazendo perguntas podem ser coletadas de diversas formas, desde a utilização de uma matriz SWOT, até mesmo a criação de mapas de empatia com o usuário final.
  
  

• Questionário: É enviado ao usuário para coletar respostas objetivas sobre suas necessidades. Esse método é especialmente útil no desenvolvimento de macro produtos, que envolvem diferentes perfis de usuários, permitindo a criação de um padrão de usabilidade adaptado a diversas experiências.

• JAD (Joint Application Design): Reuniões colaborativas entre clientes, usuários e equipe técnica para definição conjunta dos requisitos, ou também chamado de “Validação de Escopo”, esse processo funciona como uma escrita de requisitos a 4 mãos, tendo uma participação muito ativa do usuário final.
  
  

• Prototipação: Um modelo inicial da solução é criado para validar e refinar os requisitos junto ao cliente. Geralmente utilizando ferramentas como Figma, Miro, Google Docs ou até mesmo capturas de tela com formas.
  
  

• Brainstorming: Reuniões onde ideias são livremente sugeridas e posteriormente organizadas em prioridades.
  
  

• Observação: O analista acompanha o ambiente de trabalho do usuário para entender como o sistema será utilizado na prática.

Não existe uma única e correta técnica, a escolha depende do perfil do projeto e dos stakeholders envolvidos.

2. Registro e Documentação:

Após a coleta de informações, os requisitos são documentados na Especificação de Requisitos de Software (ERS). Esse registro deve ser elaborado de forma clara, simples e compreensível, garantindo a compreensão de todos os envolvidos no projeto, desde os usuários até aos desenvolvedores.

O Escopo do Sistema/Produto definido na documentação deve responder às seguintes perguntas sempre:

• O que será criado?

• Como será criado?

• Para que será criado?

• Para quem será criado?

• Quais são as regras e restrições do sistema?

• Como será a visualização inicial da solução (protótipos)?

Para garantir que os requisitos sejam bem estruturados e descritos, algumas boas práticas necessitam ser seguidas:

Organização e Categorização:

Os requisitos geralmente vão ser divididos em:

• Requisitos Funcionais: Descrevem as funcionalidades do sistema, por exemplo, "O sistema permite o cadastro de usuários".

• Requisitos Não Funcionais: Definem características qualitativas do sistema, como desempenho, segurança e usabilidade, como por exemplo, "O tempo de resposta da aplicação não deve exceder 5 segundos".

Clareza e Objetividade

Cada requisito deve ser detalhado de forma precisa e sem ambiguidades. Para ser compreensível, é necessário:

• Ser claro: Não deixa espaço para múltiplas interpretações.

• Ser conciso: Vai direto ao ponto, sem informações desnecessárias.

• Ser testável: Pode ser validado posteriormente com testes.

Uso de Modelos e Padrões

A documentação pode ser complementada com diagramas, fluxogramas e protótipos, facilitando a compreensão dos requisitos por todas as partes envolvidas usando o máximo de objetividade e clareza.

Conclusão:

A análise e especificação de requisitos são essenciais para garantir o sucesso de um projeto de software. Sem um levantamento adequado, os riscos de retrabalho, custos extras e insatisfação do cliente aumentam consideravelmente, além de também definirem o ciclo de vida de um projeto/produto.

Cada projeto tem suas particularidades, e as técnicas utilizadas devem ser adaptadas conforme o contexto e a necessidade do cliente/projeto. 

O mais importante é garantir que, ao final do processo, a solução atenda às expectativas dos usuários e cumpra seu propósito com qualidade, como por exemplo a escrita deste artigo que para ser feito precisou ter seus requisitos levantados e especificados.

Referências:

• Livro: Engenharia e Projeto de Sofware (Prof. Pedro Sidnei Zanchett)

• Livro: The Requirements Engineering Handbook" – Ralph R. Young (2004)
  
  

Autores: