Reutilizar requisitos sem perder o contexto

1. Identificar o que está a ser reutilizado

Uma equipa recebe um requisito usado por uma aplicação de fundos: “publicar o resultado até 30 minutos após receção”. A nova aplicação também publica resultados, mas chama receção ao fim da validação; a anterior chamava receção à chegada completa do ficheiro.

Copiar a frase conserva as palavras e altera o relógio de negócio. Antes de reutilizar, separa a necessidade, a definição dos eventos, o âmbito, os parâmetros e a origem da decisão. Pode ser reutilizável a estrutura da pergunta sem ser reutilizável o valor de 30 minutos.

Uma biblioteca útil explicita essas distinções e mostra quem pode confirmar cada condição. A existência de uma aprovação anterior demonstra uma decisão para o contexto registado. Não preenche automaticamente dados em falta no contexto novo, mesmo que os nomes das aplicações sejam parecidos.

2. Separar invariantes comuns de escolhas locais

O acordo fictício da biblioteca exige que quem pede uma operação não seja a pessoa que a aprova. Este invariante aplica-se a todas as aplicações abrangidas. A equipa pode escolher localmente os grupos de aprovadores e a forma de apresentar a decisão, dentro desse limite.

Uma variante permite que o próprio requerente aprove pedidos urgentes. Não é apenas um parâmetro preenchido: contradiz o invariante comum. A revisão precisa de identificar a incompatibilidade e obter a decisão competente sobre a variante ou sobre a regra comum.

Não basta que a variante tenha um nome diferente. Ao organizar o conteúdo, regista que elementos são obrigatórios, quais são configuráveis e que relações limitam as configurações. A flexibilidade útil vem de explicitar escolhas permitidas, não de esconder exceções num texto copiado.

3. Tratar parâmetros como decisões com unidades

Um requisito reutilizável limita o ficheiro a M registos e define T minutos até à publicação, contados desde chegada completa. A aplicação A usa M=800 e T=20; B usa M=1 200 e ainda não definiu T. A configuração de B não fica completa por copiar silenciosamente T de A.

Mantém o parâmetro em aberto e liga-o à necessidade e à decisão que o devem preencher. Também não confundas 800 registos com 800 megabytes: o valor numérico igual não torna as unidades equivalentes. Se uma variante exigir transformação de unidades, regista o modelo e os dados que a sustentam.

A biblioteca pode validar presença, tipo e intervalo admitido; essa verificação estrutural não prova que o limite escolhido satisfaz o negócio. Quem utiliza o requisito deve conseguir distinguir configuração completa de configuração adequada.

4. Explicitar como as regras se combinam

Um pacote comum limita ficheiros a 1 000 registos. Uma regra local limita-os a 600. O acordo fornecido diz que todas as condições aplicáveis têm de ser cumpridas; não existe substituição pela regra mais recente.

O conjunto permite, portanto, até 600 registos. Se a regra local passar a 1 500, o limite comum de 1 000 continua a restringir o resultado. Somar os limites ou escolher sempre o último valor produziria outro contrato.

Se o negócio pretende permitir que uma regra local substitua a comum, a precedência precisa de uma decisão explícita, com elementos substituíveis e limites definidos. Não deduzas a precedência do nome do ficheiro, da ordem de leitura ou do nível hierárquico de quem enviou a mensagem.

O requisito mantido deve permitir reconstruir a decisão sem depender dessa convenção implícita.

5. Reutilizar um exemplo sem reutilizar indevidamente a sua conclusão

Um caso de teste descreve um ficheiro com 900 registos e espera aceitação na aplicação A, cujo limite é 1 000. O mesmo estímulo pode ser útil em B, mas B tem limite aprovado de 600 e a resposta esperada passa a ser rejeição. A biblioteca pode conservar o exemplo e parametrizar a expectativa pelo contexto.

Não copies a marca “passou em A” como evidência de execução em B. São objetos diferentes: descrição do caso, resultado esperado e observação de uma execução identificada. Esta distinção permite reaproveitar trabalho sem afirmar cobertura que não existe.

Quando as condições forem realmente iguais, regista essa conclusão e a razão para reutilizar o artefacto. Continuará a ser necessário saber qual versão do sistema foi observada e qual afirmação essa execução permite sustentar.

6. Manter a informação também depois da entrega

O projeto encerra, mas APS continua a usar o requisito de recuperação, a descrição de estados e os exemplos de exceção. O fecho do projeto não torna esses artefactos inúteis. Define quem os mantém durante a operação e que acontecimentos desencadeiam revisão: mudança de configuração, incidente que revela uma condição omitida, alteração de consumidor ou retirada de uma capacidade.

Nem todas as notas de trabalho merecem o mesmo esforço de manutenção. Distingue artefactos ainda usados para decisões de registos históricos guardados para explicar decisões anteriores. Um documento pode estar arquivado e continuar relevante como evidência; outro pode estar numa pasta “atual” e conter informação desatualizada.

A classificação deve refletir uso, validade e responsabilidade, não apenas a localização no repositório.

7. Explicar o efeito semântico de uma edição

O requisito original usa “até 600 registos”, com igualdade incluída nos exemplos confirmados. Uma revisão editorial muda a frase para “menos de 600 registos”. A diferença de uma palavra exclui ficheiros com exatamente 600; não é apenas uma melhoria de redação.

Compara as entradas aceites antes e depois e conserva um exemplo que testemunhe a diferença. Em contraste, corrigir uma gralha no nome da aplicação pode não alterar o comportamento esperado, embora deva seguir as regras de gestão de informação aplicáveis.

O tamanho do diff não decide o impacto. Regista se a alteração esclarece o significado já acordado ou propõe outro comportamento, apresentando a base dessa conclusão. Se o significado anterior não estiver definido, preserva essa incerteza em vez de inventar uma baseline precisa para facilitar a comparação.

8. Exercício: preparar uma instância utilizável

Antes de ler a resolução, prepara a revisão da instância B. A biblioteca exige aprovação por pessoa diferente do requerente e ficheiros até 1 000 registos; todas as condições aplicáveis combinam-se. B define limite local 600, deixa o prazo T por decidir e inclui uma exceção que permite autoaprovação urgente.

Um caso com 900 registos foi aceite em A. Resolução: o limite efetivo de B é 600; o caso de 900 deve esperar rejeição em B e ainda não tem execução demonstrada aí. T continua em aberto.

A exceção urgente contradiz o invariante e precisa de resolução autorizada. Classifica estas conclusões separadamente: um valor calculável, uma expectativa adaptada, evidência de execução ausente, parâmetro em falta e conflito de requisitos.

Este registo ajuda o PM a organizar ações concretas com Business, QA e APS, sem apresentar a cópia do pacote como prontidão.

Base, exceção, vigência e arquivo

A manutenção deve permitir interpretar o presente e reconstruir o passado. Uma biblioteca contém uma regra base de sete anos com fonte P v2; a instância Q tem exceção aprovada de dez. P v3 muda a base para cinco a partir do próximo mês, enquanto a autoridade confirma que Q mantém dez. Atualizar todos os registos para cinco perde tanto a exceção como o significado histórico. Mantém versão base, fonte, intervalo de vigência e vínculo da exceção à instância aplicável. Estes prazos são uma política fictícia do exemplo, não aconselhamento sobre retenção legal.

A consulta histórica usa a referência correspondente à data e ao âmbito que o contrato de consulta define. Não deduzas que uma aprovação recente muda transações anteriores ou que a data de gravação substitui a data de vigência. Uma política nova pode aplicar-se ao futuro sem sobrescrever os registos que explicam decisões antigas.

Quando a fonte externa deixa de estar disponível, verifica se existe uma cópia identificada cuja conservação é permitida. Preserva versão, data, integridade conhecida e decisão que usou a fonte. Não substituas silenciosamente a fonte histórica por uma versão atual. O arquivo pode ser útil para explicar transações e continuar inadequado para reutilização sem revisão. Oficina: cria uma linha temporal para base e exceção, responde a uma consulta antes e outra depois da mudança e identifica o responsável pela revisão de reutilização. Resumo: conservação, aplicação corrente e autorização de reutilizar são estados distintos que o registo deve tornar visíveis.

Responder a duas perguntas temporais

Uma alteração pode ser conhecida numa data e aplicar-se a eventos de outra data. Para explicar uma decisão anterior, não basta consultar a regra que hoje se considera correta. É necessário conservar o que era conhecido, qual evento selecionava a regra e que correção foi posteriormente autorizada. A vigência e o conhecimento são dimensões distintas da informação.

Exemplo fictício de classificação interna: a regra conhecida em 4 de abril atribui classe A aos eventos desde dia 1. Em 10 de abril chega uma correção autorizada que atribui B apenas aos eventos de um subconjunto S entre dias 2 e 5, inclusive. Um evento de S no dia 3 foi decidido no dia 4 como A. A consulta sobre o que era conhecido nessa decisão deve continuar a responder A; a consulta atual sobre a regra aplicável ao mesmo evento responde B. Um evento de S no dia 6 continua A, tal como um evento fora de S no dia 3.

O registo da correção precisa do seu âmbito, fonte autorizadora, intervalo de vigência e instante de receção. A decisão original mantém a versão e a evidência usadas. Uma decisão corrigida liga-se à anterior e explica a diferença. Sobrescrever A por B no registo original produziria uma história falsa de conhecimento; ignorar B porque chegou depois impediria aplicar a correção autorizada. Nenhum destes objetivos exige eliminar a outra resposta.

Ao reutilizar requisitos, confirme a semântica das datas. Data de processamento, data do evento e data de aprovação podem selecionar regras diferentes. Não transfira automaticamente uma convenção de um sistema para outro. A existência de uma versão mais recente também não elimina uma exceção preservada ou amplia um intervalo limitado. Faça perguntas de fronteira: primeiro e último dia incluídos, evento fora do âmbito e consulta feita antes de conhecer a correção.

Oficina: compare o evento de S no dia 3 em duas consultas de conhecimento, uma no dia 8 e outra no dia 11. Resolução comentada: ambas referem o mesmo evento, mas a primeira ainda conhece A e a segunda já conhece B como aplicável. Explique também a resposta para o dia 6, fora do intervalo. Resumo: conserve identidade, âmbito e as duas dimensões temporais. Este é um modelo de informação fictício; não define obrigações legais nem autoriza ações operacionais sobre dados.

Armadilhas comuns

Copiar valores para parâmetros em falta; deduzir precedência pela ordem dos ficheiros; confundir casos reutilizáveis com resultados executados; arquivar tudo sem dono; tratar um diff pequeno como alteração sem impacto.