Volte ao caso de Ana
Ana recebeu o orçamento e respondeu: “Pode fazer o reparo.” No processo antigo, essa aprovação podia ficar perdida numa mensagem. No processo futuro, decidimos que ela deve ficar ligada à ordem.
Agora aparece uma pergunta muito prática: o que o sistema precisa permitir para isso realmente acontecer?
Vamos escrever primeiro sem usar nenhum nome técnico
O que precisamos conseguir fazer?
O atendente precisa localizar a ordem de Ana, registrar que ela aprovou o orçamento e deixar essa decisão disponível para o técnico.
Essa frase já está muito perto de um requisito.
Então o que é um requisito?
Um requisito é uma forma clara de dizer algo que a solução precisa permitir, garantir ou respeitar.
Por exemplo:
O sistema deverá permitir registrar a aprovação ou a recusa informada pelo cliente e vinculá-la à ordem de serviço.
Perceba: não estamos inventando uma função. Ela nasceu de um problema que vimos no levantamento e no AS-IS.
Necessidade e requisito não são a mesma coisa
A necessidade costuma aparecer primeiro na fala das pessoas.
Necessidade
“Eu preciso saber rapidamente em que situação está o notebook do cliente.”
Requisito
“O sistema deverá permitir consultar uma ordem e visualizar sua situação atual.”
A necessidade explica por que isso importa. O requisito diz o que a solução precisa atender.
Agora faz sentido falar em Engenharia de Requisitos
Engenharia de Requisitos é o trabalho de descobrir, organizar, escrever, revisar e validar esses requisitos.
O nome parece formal, mas a ideia é simples: pegar necessidades reais e transformá-las em algo claro o suficiente para ser construído e conferido depois.
Nem todo requisito fala de uma ação
Veja três situações diferentes da Conecta:
O sistema precisa fazer algo
Permitir consultar a situação da ordem.
Isso é um Requisito Funcional.
O sistema precisa funcionar de determinada maneira
A consulta deve funcionar adequadamente em smartphone.
Isso é um Requisito Não Funcional.
O negócio possui uma regra
O reparo não pode começar antes da aprovação.
Isso é uma Regra de Negócio.
Por que aparecem RF, RNF e RN?
Quando a lista cresce, usamos códigos curtos para encontrar cada item com facilidade. Não há mistério:
- RF = Requisito Funcional;
- RNF = Requisito Não Funcional;
- RN = Regra de Negócio.
Então RF04 quer dizer apenas Requisito Funcional número 4. O número não indica importância; é só um identificador.
Veja como as descobertas viraram requisitos
| ID | O que o sistema precisa atender | De onde veio |
|---|---|---|
| RF01 | Cadastrar cliente e equipamento. | Atendimento |
| RF02 | Abrir ordem de serviço vinculada ao cliente e ao equipamento. | Processo atual |
| RF03 | Registrar diagnóstico técnico da ordem. | Técnico |
| RF04 | Consultar situação atual da ordem. | Problema inicial |
| RF05 | Gerar orçamento a partir do diagnóstico. | Processo futuro |
| RF06 | Registrar reparo, teste e uso de peças. | Técnico + estoque |
| RF07 | Registrar aprovação ou recusa informada pelo cliente. | Gerência + atendimento |
| RF08 | Registrar entrega ou encerramento da ordem. | Atendimento |
| RNF01 | A consulta deverá funcionar adequadamente em smartphone. | Necessidade do cliente |
Leia uma linha como uma história
RF07 não nasceu porque alguém achou bonito ter “aprovação” no sistema. Ele nasceu porque vimos que a decisão do cliente podia ficar perdida numa mensagem. A coluna De onde veio serve justamente para não esquecer essa origem.
E as regras que o sistema não pode desrespeitar?
| ID | Regra | De onde veio |
|---|---|---|
| RN01 | Reparo que exige orçamento não pode começar antes da aprovação. | Gerência + técnico |
| RN02 | Recusa do orçamento impede o início do reparo e encaminha encerramento sem reparo. | Processo atual + futuro |
| RN03 | Teste reprovado devolve a ordem ao reparo; não marca a ordem como pronta. | Processo atual |
| RN04 | Mudanças críticas de situação e decisão devem manter autor e data/hora. | Problema de rastreabilidade |
Neste projeto, o cliente decide sobre o orçamento e o atendente registra essa decisão no sistema. Se quisermos que o cliente aprove diretamente pelo portal, estaremos mudando o escopo e precisaremos analisar outras questões.
Uma frase pode parecer requisito e ainda estar ruim
“O sistema deve ser rápido.”
Rápido em quê? Para quem? Em qual situação? A frase parece boa, mas ainda não dá para conferir se foi atendida.
“O sistema deve ser fácil.”
Fácil para qual pessoa e para qual tarefa?
Um requisito útil precisa ser compreensível e permitir alguma forma de verificação.
Como saber se escrevemos a coisa certa?
Verificação
Pergunta: “Escrevemos isso de forma clara?”
Validação
Pergunta: “Isso representa mesmo o que as pessoas precisam?”
Um requisito pode estar muito bem escrito e ainda assim descrever a coisa errada. Por isso precisamos das duas perguntas.
Vamos testar um requisito com uma situação real
Veja a regra do reparo. Como podemos conferir se ela foi respeitada?
Uma pequena história de teste
Dado que existe um orçamento pendente,
quando o técnico tentar iniciar o reparo,
então o sistema deverá bloquear a operação e informar que a aprovação é necessária.
Esse tipo de frase é um critério de aceitação: algo observável que nos ajuda a confirmar se o comportamento esperado foi atendido.
E se tivermos requisitos demais para a primeira versão?
Aí precisamos priorizar. Uma forma simples é separar em quatro grupos:
Must — deve ter
Sem isso, a primeira versão não cumpre seu objetivo.
Should — deveria ter
É importante, mas pode existir uma solução temporária.
Could — poderia ter
Ajuda, mas pode esperar.
Won't now — não agora
Fica conscientemente fora desta entrega.
Essa forma de priorização é conhecida como MoSCoW. O nome só ajuda a lembrar os quatro grupos; o mais importante é saber por que cada item entra ou fica para depois.
Veja o caminho inteiro até aqui
É isso que mantém o trabalho conectado. Um requisito não deveria aparecer do nada.
Faça agora
- Escolha RF07 e conte de qual problema real ele nasceu.
- Explique com suas palavras a diferença entre necessidade e requisito.
- Diga o que significam RF, RNF e RN.
- Escolha uma necessidade encontrada no levantamento e transforme-a em um requisito.
- Escreva uma regra de negócio ligada ao processo.
- Crie um critério de aceitação no formato Dado — Quando — Então.
- Para cada item, registre de onde ele veio.
O que o sistema precisa atender
Guarde seus requisitos junto com a origem. Se você não consegue explicar de onde um item veio, volte ao levantamento ou ao processo e investigue.
Checkpoint 4 — Você consegue explicar antes de codificar?
Diante de uma necessidade da Conecta, você consegue dizer o que o sistema precisa fazer, que regra precisa respeitar e como saberemos se isso funcionou?
Agora sabemos o que precisa existir. Mas quem usa isso e para quê?
Temos requisitos como “abrir ordem”, “registrar diagnóstico” e “consultar situação”. Só que ainda falta olhar para essas funções pelo ponto de vista de quem vai usar o sistema.