Requisitos de software: um guia prático do que fazer e não fazer

Requisitos de Software

Fazer levantamento de requisito de software significa descrever o que o sistema deve ou não fazer. Esta é uma das etapas mais importante do ciclo de vida de um software e deve, na medida do possível, ser elicitada juntamente com área de negócios, desenvolvedores, QAs e stakeholders. Sabe-se que 70% da falha de projetos de software advêm de uma má elicitação de requisitos. Este processo inclui não apenas perguntar aos usuários o que eles querem, mas também analisar o contexto do negócio, os processos envolvidos e os problemas a serem resolvidos.

Neste artigo do SW Academy, iremos relatar o que se deve fazer e não fazer na etapa de levantamento de requisitos de software. E, no final, recomendaremos artigos complementares para aprofundamento do tema.

Requisitos de software são descrições detalhadas de funcionalidades, bem como suas respectivas restrições. Requisitos bem escritos proporcionam um entendimento compartilhado dos objetivos do projeto, reduzem mal-entendidos e ajudam a controlar o aumento do escopo. Eles servem também como base para a escrita de cenários de testes e homologação.

Como escrever requisitos de softwares?

Praticamente, há 5 tópicos que você deve considerar quando fazer a elicitação de requisitos:

  • Use a linguagem do usuário e, sempre que possível, não use termos técnicos!
  • Requisitos devem indicar o que o software deve fazer, mas não como ele deve fazer, por exemplo:
Requisito desfavorávelBoa prática
O software deve exibir o guia de integração usando uma janela modal com largura de 500px e altura de 300px.O usuário deve conseguir visualizar o guia de integração independentemente da tela em que estiver.
  • Envolva os stakeholders o mais cedo possível e com frequência;
  • Priorize os requisitos, como por exemplo, em usando uma escala de 1-5 (likert) onde 1 representa baixa prioridade e, 5, alta prioridade;
  • Tenha uma gestão de mudanças clara.

O que não fazer na hora de escrever os requisitos?

  • Não escrever os requisitos não-funcionais;
  • Não escrever critérios de aceite;
  • Usar frases ambíguas e termos técnicos, como por exemplo:

"O sistema deve carregar rapidamente a página inicial quando o usuário acessá-la."

a palavra rapidamente é ambígua, pois pode significar 1 segundo para uma pessoa ou, 10 segundos para outra. Um exemplo de escrita correta seria:

"O sistema deve carregar a página inicial em até 2 segundos, em 95% das vezes, considerando uma conexão de internet com no mínimo 10 Mbps."

A seguir, iremos destacar alguns sites que abordam este tema para você se aprofundar ainda mais!