Escopo de sistema sob medida: o que devo definir antes de fechar?

O escopo começa pelo problema ou pela lista de telas?

Comece pelo trabalho que precisa melhorar, não por uma lista de telas. Descreva quem executa a rotina, onde ela começa, qual resultado precisa produzir e o que hoje atrapalha esse caminho. [1]

Uma pequena empresa pode, por exemplo, acompanhar pedidos que passam por vendas, estoque e faturamento. O escopo deve explicar o que cada pessoa precisa fazer e quais informações precisam chegar à próxima etapa. Assim, a equipe que desenvolve entende o processo completo, não apenas o nome de uma tela.

A orientação de descoberta do GOV.UK recomenda entender o problema, as pessoas usuárias, o contexto e as restrições antes de decidir construir. Use essa ideia para avaliar se um sistema próprio é mesmo o caminho ou se uma ferramenta existente pode atender à rotina. [1]

Como descrever a rotina da empresa com clareza?

Descreva uma rotina real do início ao fim e confirme o relato com quem faz o trabalho. Separe as etapas, os responsáveis e as informações necessárias em cada passagem. [1]

Evite escrever apenas “controlar pedidos” ou “organizar clientes”. Diga, por exemplo, quem recebe o pedido, quais campos precisa conferir e quem vê o andamento depois da aprovação. Esse nível de detalhe ajuda a revelar regras que poderiam ficar escondidas até os testes.

Como registrar regras e exceções sem deixar dúvidas?

Escreva o que acontece em cada situação relevante e quem pode decidir quando a regra não se aplica. Uma regra clara descreve a condição, a ação esperada e o resultado que a equipe deve ver. [2]

• Se um pedido chegar sem uma informação obrigatória, indique quem completa o dado e se ele pode seguir.
• Se uma pessoa recusar uma solicitação, registre como o motivo aparece para quem precisa dar retorno.
• Se houver uma exceção, defina quem pode autorizá-la e onde essa decisão fica registrada.
• Se uma etapa depender de outro sistema, diga qual informação chega e quem confere o resultado.

Diretrizes internacionais de segurança, como as do NIST (órgão de padrões de tecnologia), recomendam que compradores e fornecedores usem uma linguagem comum para conversar sobre desenvolvimento seguro. Leve perguntas de segurança, acesso e tratamento de falhas para a definição do sistema, em vez de deixar esses assuntos vagos. [2]

Quais dados e integrações precisam entrar no escopo?

Liste de onde vêm as informações, onde serão usadas e quais ferramentas precisam trocar dados. Para cada integração, anote quem libera o acesso, que tipo de informação circula e como a equipe percebe uma falha. [3]

Se o sistema tratar dados pessoais, identifique quais são necessários para a rotina, quem pode consultá-los e por quanto tempo a empresa precisa mantê-los. A LGPD prevê medidas de segurança para proteger esses dados; a empresa deve definir responsabilidades e levar esses cuidados ao projeto. [3] [4]

• Qual sistema é a origem de cada informação?
• Quem pode visualizar, alterar ou aprovar cada registro?
• O que deve acontecer se um dado não chegar ou vier incompleto?
• Quem confirma que a troca entre as ferramentas está correta?

Como definir uma entrega que a equipe consiga verificar?

Descreva uma ação que a equipe possa testar e o resultado que deve aparecer. Em vez de pedir uma tela “simples de usar”, combine tarefas observáveis, como registrar um pedido, aprová-lo e localizar depois quem tomou a decisão.

Essa sequência de etapas é uma forma prática de organizar a conversa. O escopo também deve dizer quem valida cada etapa e quais dados ou acessos a empresa precisa fornecer para que o teste represente a rotina.

O que deve ficar fora do escopo ou registrado como dependência?

Registre o que não será feito agora e o que depende da empresa ou de outro fornecedor. Se uma função não for necessária para concluir a primeira rotina, deixe claro que ela será avaliada em outra etapa. [1]

• Recursos que não fazem parte da primeira entrega.
• Acessos, arquivos ou decisões que ainda precisam ser providenciados.
• Regras que dependem de confirmação de outra área ou fornecedor.
• Como uma mudança será avaliada e registrada depois do início.

Distinguir essas condições evita tratar toda ideia nova como parte da entrega inicial. Se uma pendência mudar a rotina, registre quem vai resolvê-la e qual etapa precisa aguardar essa definição.