Capítulo 16 — Engenharia de sistemas
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX046.
flowchart TD
N0["16.1 Requisitos testáveis"]
N1["16.2 Rastreabilidade"]
N2["16.3 Interfaces"]
N3["16.3b SLAs de interface"]
N4["16.1b Glossário para as partes interessadas"]
N5["Nota de prática"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX046"]
Desenho lógico
flowchart LR
N0["16.1 Requisitos testáveis"]
N1["16.2 Rastreabilidade"]
N2["16.3 Interfaces"]
N3["16.3b SLAs de interface"]
N4["16.1b Glossário para as partes interessadas"]
N5["Nota de prática"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX046"]
[16.1 Requisitos testáveis]
|
v
[16.2 Rastreabilidade]
|
v
[16.3 Interfaces]
|
v
[16.3b SLAs de interface]
|
v
[16.1b Glossário para as partes interessadas]
|
v
[Nota de prática]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX046]
Objetivos de aprendizagem
Você vai (1) escrever requisitos testáveis; (2) rastrear um requisito até um artefato; (3) gerenciar as interfaces entre TrackScope, FindingsDesk e PulseMap.
16.1 Requisitos testáveis
"O sistema deve ser seguro" não é um requisito. "O TrackScope rejeita qualquer alvo fora do conjunto assinado de CIDRs/portas e registra o código do motivo" é. Cada requisito precisa de um id, uma declaração com "deve", um método de verificação (teste, inspeção, análise) e um dono. Declarações com "deve" e ids transformam discussões em verificações. O método de verificação e o dono impedem requisitos que ninguém consegue provar e ninguém mantém. Sam escreve o comportamento de rejeitar e registrar do TrackScope como o requisito TS-SCOPE-1, com um teste unitário como método. Qualquer coisa mais fraca é reescrita antes de o design começar.
16.2 Rastreabilidade
Uma matriz simples: requisito → elemento de design → caso de teste → evidência do engajamento. Quando um achado mostra um contorno de escopo, você sabe qual requisito e qual teste falharam. Sem a matriz, os post-mortems viram caça a culpados. Quando aparece um contorno de escopo, a matriz nomeia o teste quebrado e o requisito que ele deveria impor. Culturas de culpa crescem na lacuna em que esse vínculo falta. Sam atualiza a matriz na mesma mudança que o código, para que o vínculo não apodreça por uma semana. Os post-mortems começam por essa linha.
16.3 Interfaces
O TrackScope emite eventos de permissão/negação; o FindingsDesk consome rascunhos de achados; o PulseMap consome etiquetas de técnicas. Combine esquemas JSON e versione-os. Uma mudança de interface é um release, não uma edição silenciosa. Edições silenciosas de esquema quebram as páginas de condição de parada no pior momento. Contratos JSON versionados fazem da quebra um release deliberado, com uma nota de migração. Cada consumidor declara as versões que aceita. Os testes de integração de Sam publicam um evento de exemplo em cada versão suportada.
Caso sintético — Riverstone Transit. O requisito R-17, "os motivos de negação são imutáveis após a inserção", foi rastreado até a tabela de eventos somente-acréscimo do FindingsDesk e até o teste T-17, que tenta um UPDATE e espera uma falha.
16.4 Erros e limites
Matrizes de rastreabilidade apodrecem se não forem atualizadas no mesmo PR que o código. Mantenha-as ao lado do código. Uma matriz numa apresentação de slides é a primeira a morrer. Mantê-la ao lado do código significa que a mesma revisão que faz o merge de uma funcionalidade vê a atualização da rastreabilidade. Sam faz a CI falhar se um novo id de requisito não tiver uma linha de teste. Matrizes só em slides são rejeitadas na revisão. Os donos recebem um e-mail semanal se suas linhas estiverem atrasadas em relação ao código do merge, e o engajamento não pode citar um requisito que não tenha um teste atual.
16.3b SLAs de interface
SLAs internos entre serviços importam: o TrackScope pode precisar que o FindingsDesk aceite um evento em até N segundos durante uma condição de parada. Escreva isso como um requisito com um teste de carga sintético. Sem ele, as páginas de condição de parada chegam depois que a pessoa já ligou para o cliente. Um evento de condição de parada que chega atrasado é um evento que falhou em seu propósito. Testes de carga sintéticos provam que o FindingsDesk aceita rajadas quando o TrackScope nega muitos alvos de uma vez. Escrever o orçamento de latência como requisito o torna visível no planejamento, não só numa indisponibilidade. Sam aciona alertas para violações de SLA durante os exercícios, para que o caminho seja ensaiado.
16.1b Glossário para as partes interessadas
Mantenha um glossário de uma página: ROE, ScopeVersion, lista de exclusão, técnica planejada, evidência lacrada. As partes interessadas usam "cobertura" e "risco" de forma errada o tempo todo; o glossário é um artefato de requisitos, não decoração, e aparece na apresentação do kickoff do engajamento. Cobertura e risco são palavras do dia a dia com significados especiais aqui, e o uso errado leva a más decisões. Um glossário de uma página na apresentação do kickoff dá a todos as mesmas definições antes de a janela abrir. ROE, ScopeVersion e evidência lacrada ganham, cada uma, uma frase simples. Sam lê em voz alta os três termos mais mal usados no kickoff e deixa a página na pasta compartilhada.
Nota de prática
A rastreabilidade também cobre a aposentadoria: quando um requisito é retirado, marque-o como substituído, com um ponteiro para o substituto, em vez de apagar a linha. Achados históricos ainda citam os ids antigos. Uma matriz viva que esquece a história torna o dossiê do ano passado inverificável e ensina os engenheiros a tratar requisitos como slides descartáveis, em vez de artefatos de engenharia que sobrevivem a um único trem de release.
Exercícios
- EX046 — Deve. Reescreva "tornar a varredura segura" como dois requisitos com "deve". Rubrica: 3 = dois "deve" testáveis, com método de verificação; 2 = um bom; 1 = ainda vago; 0 = nada.
- EX047 — Rastreio. Para o R-17 acima, nomeie o artefato e o sinal de teste que falha. Rubrica: 3 = tabela de eventos + o UPDATE falha; 2 = um; 1 = vago; 0 = nada.
- EX048 — Interface. Liste três campos de um evento de negação do TrackScope. Rubrica: 3 = carimbo de tempo, alvo, motivo (ou equivalentes); 2 = dois; 1 = um; 0 = nada.
Síntese
Requisitos que você consegue testar, vínculos que você consegue seguir, esquemas que você versiona.
Continue estudando — capítulo 16 de 50
← Capítulo 15 (rascunho) · Índice de capítulos do curso · Capítulo 17 (rascunho) →