“Quantidade adequada” parece claro?
Imagine que a única orientação entregue ao desenvolvedor fosse esta:
“O sistema deve aceitar quantidades adequadas.”
Agora tente decidir se 0, 1, 10, 11 ou 20 devem ser aceitos.
Não dá para saber com segurança.
A palavra adequadas parece simples, mas deixa espaço demais para interpretação.
Quando a intenção vira uma regra clara
A cantina então explica:
Cada item do pedido deve ter de 1 a 10 unidades, inclusive.
Agora conseguimos comparar situações concretas:
| Quantidade | Comportamento esperado |
|---|---|
| 0 | Rejeitar |
| 1 | Aceitar |
| 5 | Aceitar |
| 10 | Aceitar |
| 11 | Rejeitar |
Uma frase mais precisa tornou o comportamento verificável.
Requisito: uma referência para construir e testar
Um requisito descreve uma necessidade, uma condição, uma capacidade ou um comportamento esperado do sistema.
Na Cantina Horizonte, podemos registrar:
RF-03 · Quantidade
O prefixo RF significa Requisito Funcional. O número 03 serve apenas para identificar o requisito.
Cada item deve ter quantidade inteira entre 1 e 10 unidades, inclusive.
Agora o testador, o desenvolvedor e quem pediu o sistema têm uma mesma referência para conversar.
E o que é uma regra de negócio?
Nem toda regra nasce da tecnologia.
O Python não decidiu que o máximo deveria ser 10. O banco de dados também não. Essa é uma decisão da própria cantina.
Regra de negócio
É uma regra que vem do funcionamento da organização, do serviço ou da atividade que o sistema precisa apoiar.
Exemplos:
- não vender mais unidades do que existem em estoque;
- permitir no máximo 10 unidades do mesmo produto por item;
- aceitar um cupom somente dentro das condições definidas pela cantina;
- não permitir que um pedido entregue volte para “Em preparação”.
O software transforma essas regras em comportamento.
Necessidade, regra e requisito não são a mesma coisa
Veja como uma ideia pode ganhar precisão aos poucos:
Necessidade: evitar vendas impossíveis.
Regra de negócio: não vender mais do que existe em estoque.
Requisito: o sistema deve rejeitar quantidade superior ao estoque disponível.
Critério de aceitação: com estoque 8, uma tentativa de pedir 9 deve ser rejeitada.
Teste: preparar estoque 8, solicitar 9 e observar o resultado.
Critério de aceitação: como reconhecer que ficou certo?
Um requisito pode estar claro e ainda precisar de exemplos objetivos para orientar a aceitação.
Critério de aceitação
É uma condição observável que ajuda a decidir se determinado comportamento atende ao que foi combinado.
Para o requisito de quantidade, podemos ter:
- quantidade menor que 1 deve ser rejeitada;
- quantidade entre 1 e 10 deve ser aceita, desde que haja estoque;
- quantidade maior que 10 deve ser rejeitada;
- quantidade superior ao estoque deve ser rejeitada.
Perceba que já estamos quase escrevendo testes — mas ainda estamos esclarecendo o comportamento esperado.
Requisito funcional
Um requisito funcional descreve algo que o sistema deve fazer ou uma regra de comportamento que ele precisa executar.
Exemplos da Cantina Horizonte:
Calcular
O sistema deve calcular o total do pedido.
Validar
O sistema deve rejeitar quantidade acima do estoque.
Registrar
Ao finalizar, o pedido deve ser gravado.
Atualizar
O estoque deve diminuir pela quantidade vendida.
E quando a preocupação é a qualidade do comportamento?
Algumas exigências não descrevem uma nova função, mas uma característica que o sistema precisa apresentar.
Você pode encontrar a expressão requisito não funcional. Neste módulo, também vamos chamá-lo de requisito relacionado à qualidade quando isso deixar a ideia mais clara.
Nos documentos da Cantina Horizonte, esse tipo de requisito recebe o prefixo RQ, que significa Requisito de Qualidade.
Mensagem compreensível
Quando uma operação for rejeitada, a mensagem deve explicar o motivo para o usuário.
Uso em tela pequena
As funções principais devem continuar utilizáveis em uma tela estreita, sem exigir rolagem horizontal da página.
Mais adiante vamos separar também testes funcionais e testes não funcionais. Por enquanto, basta perceber que requisitos podem tratar tanto do que o sistema faz quanto de características de qualidade.
Uma frase bonita pode ser um requisito ruim
Compare:
“O sistema deve ser rápido.”
Quanto é rápido? Em qual operação? Em que condição?
“O sistema deve ser intuitivo.”
Como vamos observar isso? Para qual pessoa? Em qual tarefa?
O problema não é a intenção. O problema é tentar testar uma frase que ainda não diz claramente o que observar.
Um bom requisito reduz ambiguidades e fornece informação suficiente para que seu atendimento possa ser verificado.
O cupom mostra como lacunas aparecem
Imagine receber apenas esta frase:
“O cupom MBB10 dá 10% de desconto em compras de R$ 30.”
Parece claro até começarmos a perguntar:
- R$ 30,00 exatamente recebe desconto?
- é R$ 30,00 antes ou depois de outro desconto?
- o cupom pode estar vencido?
- pode ser usado mais de uma vez?
Tentar imaginar os testes nos ajuda a perceber o que ainda falta esclarecer.
Uma versão melhor da regra
O cupom MBB10 concede 10% de desconto quando o subtotal for maior ou igual a R$ 30,00, o cupom estiver dentro da validade e ainda não tiver sido utilizado.
Agora temos três condições explícitas. Mais adiante, quando essas combinações começarem a ficar difíceis de organizar, surgirá uma técnica própria para isso.
Abra a especificação-base do projeto
A partir de agora, a Cantina Horizonte passa a ter uma pequena referência escrita. Ela não é um documento gigante: contém somente as regras necessárias para sabermos o que estamos avaliando.
O arquivo termina em .md. Essa extensão indica um arquivo Markdown, um formato de texto simples muito usado em documentação de projetos. Não é necessário aprender a sintaxe do Markdown agora; nesta etapa, vamos apenas ler o conteúdo.
Documento de referência
Abrir requisitos-base da Cantina Horizonte →
Leia principalmente RF-03, RF-04 e RF-05. RF significa Requisito Funcional; RQ significa Requisito de Qualidade.
Prática · torne a frase testável
Reescreva estas frases de modo que outra pessoa tenha uma referência melhor para testar:
- “A quantidade deve ser normal.”
- “O sistema deve responder rápido.”
- “Pedidos grandes recebem desconto.”
- “A mensagem de erro deve ser boa.”
Não existe uma única redação perfeita. O importante é perguntar: outra pessoa consegue observar objetivamente se isso foi atendido?
Mas existe uma surpresa
Agora que temos documentos, podemos compará-los.
Imagine encontrar estas duas frases em lugares diferentes:
Documento A
Cupom MBB10 a partir de R$ 30,00.
Documento B
Cupom MBB10 a partir de R$ 40,00.
Nem sequer executamos o programa e já existe um problema que precisa ser resolvido.
Será que também podemos encontrar defeitos antes de executar o software?
Antes de seguir
Você deve conseguir explicar:
- por que precisamos de uma referência para definir o resultado esperado;
- a diferença básica entre necessidade, regra de negócio, requisito e critério de aceitação;
- o que significam RF e RQ nos documentos da Cantina Horizonte;
- por que uma frase vaga pode dificultar tanto o desenvolvimento quanto os testes.