Capítulo 5 — Comunicação em engenharia
Mapa da aula
Aula 05 publicada. Mapa, exemplo, EX010.
flowchart TD
N0["5.1 Escrever para decisões"]
N1["5.2 Requisitos que podem ser verificados"]
N2["5.3 Números, incerteza e figuras"]
N3["5.4 Comunicar risco a leitores diferentes"]
N4["5.5 Informação sensível"]
N5["5.7 Atividade prática"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX010"]
Desenho lógico
flowchart LR
N0["5.1 Escrever para decisões"]
N1["5.2 Requisitos que podem ser verificados"]
N2["5.3 Números, incerteza e figuras"]
N3["5.4 Comunicar risco a leitores diferentes"]
N4["5.5 Informação sensível"]
N5["5.7 Atividade prática"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX010"]
[5.1 Escrever para decisões]
|
v
[5.2 Requisitos que podem ser verificados]
|
v
[5.3 Números, incerteza e figuras]
|
v
[5.4 Comunicar risco a leitores diferentes]
|
v
[5.5 Informação sensível]
|
v
[5.7 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX010]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) escrever um requisito que possa ser verificado; (2) produzir uma nota de projeto de uma página, um registro de decisão e um relatório de teste que outro engenheiro consiga conferir; (3) apresentar risco e incerteza a operadores, gestores e reguladores sem exagerá-los nem escondê-los; e (4) tratar de forma adequada, em documentos, detalhes sensíveis de infraestrutura. Ele se apoia nos capítulos 1–4, cujos números você agora precisa comunicar, e prepara os ateliês de projeto (capítulos 25 e 35).
5.1 Escrever para decisões
Documentos de engenharia existem para que alguém possa tomar ou conferir uma decisão. Comece pela decisão e por sua base; deixe as deduções para depois. Uma boa nota de projeto responde, nesta ordem: o que está sendo decidido, as opções consideradas, a recomendação, as evidências e as suposições por trás dela, o que mudaria a recomendação e quem precisa aprová-la. Os registros de decisão de arquitetura (ADRs) — notas curtas, datadas e numeradas que registram uma decisão, seu contexto e suas consequências — mantêm visíveis os motivos de um projeto anos depois, quando a equipe original já seguiu adiante.
5.2 Requisitos que podem ser verificados
Um requisito é uma afirmação que o sistema precisa satisfazer, escrita de modo que um teste, uma análise, uma inspeção ou uma demonstração possa mostrar se ele a satisfaz. O NASA Systems Engineering Handbook recomenda requisitos necessários, inequívocos, verificáveis, viáveis e rastreáveis. Compare: "A telemetria deverá ser segura" (não verificável) com "Cada mensagem de telemetria de uma RTU de campo para o centro de controle deverá levar um código de autenticação de mensagem sobre seu conteúdo e um contador monotônico; o receptor deverá rejeitar as mensagens que falharem em qualquer das verificações e gerar um alarme em até 60 s" (verificável por teste). Use "deverá" para requisitos, mantenha um requisito por frase e dê a cada um deles um identificador.
5.3 Números, incerteza e figuras
Informe os números com unidades, o método que os produziu e sua incerteza ou suas suposições: "autonomia de 14,6 h (modelo de demanda integrada, início às 06:00, nível inicial de 85%; 17,3 h se for assumida a demanda média)". Prefira tabelas para valores exatos, gráficos de linha para séries temporais, e nunca um gráfico sem eixos rotulados e unidades. Evite a falsa precisão: uma autonomia de bateria calculada a partir de cargas estimadas é de "cerca de 19 h", não de "18,83 h". Faça figuras legíveis em tons de cinza e por pessoas com deficiência na visão de cores.
Na LRWA, o valor de autonomia no dossiê do TMRP traz seu horário de início e seu nível inicial, para que ninguém o cite para um cenário diferente.
5.4 Comunicar risco a leitores diferentes
Operadores precisam saber o que fazer e quando; gestores precisam de consequência, custo e opções; reguladores precisam de evidências de conformidade e de raciocínio. A mesma constatação — "setpoints remotos são aceitos sem autenticação" — torna-se, para um operador, "até a correção, confirme por telefone com a sala de controle qualquer mudança inesperada de setpoint"; para um gestor, "um comando forjado poderia ligar ou desligar bombas; custo da correção 120 mil, três meses"; para um regulador, uma lacuna de controle mapeada com um plano datado. Nenhuma dessas versões pode contradizer outra.
5.5 Informação sensível
Documentos de infraestrutura costumam conter endereços de rede, modelos de dispositivos, vulnerabilidades e limites de capacidade. Classifique os documentos por sensibilidade, compartilhe-os com base na necessidade de saber e retire detalhes das versões destinadas a públicos amplos. Relatórios públicos e trabalhos de estudantes devem descrever os sistemas no nível do NIST Guide to OT Security (SP 800-82 Rev. 3) — padrões de arquitetura —, e não as fraquezas específicas de um operador identificado. Neste livro todo número da LRWA é sintético, mas pratique o hábito mesmo assim: classifique as notas de projeto para uso interno, mantenha endereços de rede fora dos slides e produza uma versão reduzida para públicos de fora da equipe de engenharia.
5.6 Exemplo resolvido: um registro de decisão do TMRP (sintético)
ADR-007 — Autenticar a telemetria de campo na camada de aplicação. Data: 2026-03-04. Situação: aceito. Contexto: o tráfego RTU–SCADA atravessa uma rede LTE privada operada por terceiros; a cifração da LTE termina na operadora. Opções: (a) confiar na cifração da operadora; (b) túneis IPsec por RTU; (c) HMAC na camada de aplicação com contadores. Decisão: (c), com (b) onde as RTUs o suportarem. Consequências: +22 bytes por mensagem (Laboratório 8); gestão de chaves necessária (Capítulo 19); as RTUs legadas da PS1 e da PS2 precisam de um gateway. Rever se: o contrato com a operadora mudar ou o firmware das RTUs ganhar protocolos seguros nativos.
5.7 Atividade prática
Reescreva em forma verificável três requisitos vagos de um briefing sintético ("o sistema deverá ser resiliente", "os alarmes deverão ser oportunos", "os logs deverão ser protegidos"), cada um com um método de verificação. Para cada reescrita, nomeie a evidência que mostraria que o requisito foi atendido: um teste com critério de aprovação, uma análise com suposições declaradas, uma inspeção ou uma demonstração. Use o contexto da LRWA onde ajudar. Um sistema resiliente pode virar uma autonomia declarada durante uma falta de energia da rede elétrica, alarmes oportunos podem virar uma meta de latência para uma parcela declarada dos eventos, e logs protegidos podem virar proteção de integridade com âncoras guardadas fora da zona de controle, como R8 exigirá mais adiante. Mantenha cada afirmação com um único requisito.
5.8 Erros comuns e limites
- Enterrar a recomendação; escrever uma cronologia em vez de um argumento.
- Requisitos contendo "e/ou", "conforme apropriado", "amigável", "seguro".
- Números sem unidades, método ou incerteza.
- Histórias diferentes para públicos diferentes.
- Compartilhar detalhes sensíveis em excesso, ou compartilhar tão pouco que os revisores não conseguem conferir o trabalho.
A maioria desses erros aparece primeiro nos conjuntos de requisitos. Um requisito que contém seguro não pode ser testado, então ele será discretamente abandonado ou declarado atendido sem evidência. Histórias diferentes para públicos diferentes são igualmente danosas: se a nota ao operador, o resumo ao gestor e a declaração ao regulador do EX010 discordarem sobre a bateria da PS4, quem ler duas delas não confiará em nenhuma.
Exercícios — capítulo 5
EX009 — Torne verificável. Objetivo: escrever requisitos testáveis. Entradas: os três requisitos vagos da §5.7. Passos: reescreva cada um como uma ou mais afirmações com "deverá", com um identificador e um método de verificação (teste, análise, inspeção, demonstração). Evidência esperada: tabela. Rubrica: 3 = cada um mensurável, único, viável, com um método adequado; 2 = um ainda vago; 1 = apenas troca de palavras; 0 = nada.
EX010 — Três públicos. Objetivo: comunicar uma constatação de forma consistente. Entradas: "A bateria da telemetria da PS4 dura 6 h no fim da vida útil; o requisito R5 é de 24 h". Passos: escreva uma nota de duas frases ao operador, um resumo de 100 palavras ao gestor, com opções, e uma declaração de lacuna dirigida ao regulador. Evidência esperada: três textos. Rubrica: 3 = fatos consistentes, ações adequadas a cada público, sem excesso de detalhes sensíveis; 2 = uma inconsistência; 1 = o mesmo texto três vezes; 0 = nada.
Síntese do capítulo
Escreva para viabilizar decisões: a recomendação primeiro, as evidências e suposições em seguida, as condições de mudança por último. Torne todo requisito verificável e rastreável; informe números com unidades, métodos e incerteza; adapte a mensagem, não os fatos, ao leitor; e trate os detalhes de infraestrutura como informação sensível, com um público definido.
Continue estudando — capítulo 05 de 50
← Capítulo 04 · Índice de capítulos do curso · Capítulo 06 →
Siga para a próxima lição escrita.