Mission Engineering 05: Turning Vague Requests into Verifiable Requirements

The article continues from previous task decomposition, addressing vague family statements such as "don't make me wait too long," "prepare utensils the night before," and "change the kettle." It emphasizes separating original statements, candidate solutions, and verified requirements before jumping to implementation ideas.

Separate Original Statements, Requirements, and Solutions

A three-column table captures: (1) heard or thought statements, (2) where to place them (original statement, pending requirement, candidate solution), and (3) follow-up questions. Example rows:

"Don't let me wait too long" → original statement → "Latest time to serve?"

"Serve by 7:28 on confirmed workdays" → pending time requirement → "Is this time suitable? Can you schedule to meet it?"

"Prepare utensils night before" → candidate solution → "How much morning time saved? What extra work night before?"

"Change kettle" → another candidate → "Currently waiting for water? Is new equipment allowed this round?"

The article notes this round explicitly prohibits new equipment; future purchases require separate discussion.

Metrics Tell You How to Measure, Requirements State What Must Be Achieved

Previous metrics CF-T01 (duration from start to serve) and CF-S02 (timeliness) are reused. The distinction: metrics answer "what to observe, how to record"; requirements answer "under what conditions, who must achieve what." A time requirement needs a timestamp or duration; recording requirements need listed content, not just a single number.

Example: if start at 7:15, take 9 minutes, serve at 7:24, the 7:28 deadline is met but an added "≤8 minutes" rule would fail. Adding extra requirements changes the conclusion. Early start is recorded but does not prove the original 7:20 start works; the family's actual drinking window still needs confirmation.

Write a Negotiable Requirement First

A requirement card for CF-REQ01 v0.1 includes fields:

Source: family wants coffee before leaving; linked to scenario card CF-WD v1.

Applicability: workday scenario, family leaves 7:35, materials/utensils per scenario card, planned start 7:20, actual start recorded separately.

Who does what: you serve by 7:28.

Linked tasks: CF-A01 – CF-A04.

Verification: record actual serve time, compare to 7:28; reuse CF-S02 definitions; CF-T01 for analysis only.

Evidence location: serve time in brewing record, linked to scenario, recipe, definition versions.

Who confirms: you and family confirm time agreement; you record time, family confirms receipt.

Missing evidence: missing time + no credible basis → temporarily undetermined; known late → unsatisfied; estimates marked as estimates.

Importance: proposed must-satisfy.

Agreement status: draft, pending confirmation.

Verification evidence/results: not yet tried; later link specific records.

The card only covers serve time; drinking-time adequacy and taste acceptance are separate. Confirming this requirement also records task and metric versions for traceability. If start is delayed, record actual start and check if 7:28 is still met—do not automatically shift serve time. Changes require re-negotiation and a new version from a specific occurrence.

Link Requirements Back to Tasks and Evidence

A traceability matrix maps five requirements: CF-REQ01: serve by 7:28 (source: family schedule) → tasks A01–A04 → verification per card → proposed must-satisfy, pending confirmation. CF-REQ02: acceptable coffee per taste (source: taste statements) → tasks A01, A03, A05 → record evaluator, original words, evaluation time per CF-S01 → proposed must-satisfy, taste details pending family confirmation. CF-REQ03: start brewing only after conditions verified (source: task dependency) → checkpoint A02→A03 → compare against recipe preparation checklist per CF-E01; missing/unclear items must be resolved before start → candidate check requirement, checklist and judgment conditions need definition. CF-REQ04: retain necessary records (source: improvement need) → tasks A01–A04 collect, A05 organize → check against confirmed checklist per CF-R01; recalled entries marked separately → proposed basic record, fields and collection points pending confirmation. CF-REQ05: use existing equipment only (source: scope agreement) → task A01 and execution → verify equipment list and any new purchases → agreed scope constraint; changes require re-negotiation.

Bidirectional traceability (requirement → task → metric → record) is emphasized. The article references the Mission Engineering Guide (DoD MEG 2.0, §2.2, 2.3.1) for repeatable, traceable analysis and task-to-solution links, noting the tables are teaching aids, not standard templates. Reference: U.S. Department of Defense, Mission Engineering Guide , Version 2.0, 2023-10-01, §2.2 & 2.3.1, pp. 4–6. URL:

https://ac.cto.mil/wp-content/uploads/2023/11/MEG_2_Oct2023.pdf

Don't Write 'Repeatable Next Time' as a Guarantee Yet

Recording bean batch, recipe version, amounts, and timestamps enables reference but does not guarantee identical results. To make "repeatable" a verifiable requirement, one must define: under what conditions, by whom, acceptance criteria (family acceptance vs measured ranges), test scenarios, exception handling. Since these are unresolved, the article suggests noting "future trials needed" and listing open questions. First decide what to record; trial design comes later (episode 11).

Can You Handle Both Requirements Together?

Example: recording each pour's time/amount vs keeping the morning routine uninterrupted. Each alone is reasonable but combined may overload one person. Determine needed information first, then choose recording method. Tools may capture raw readings for later transcription; if recall-based, mark as estimates. If basic recording interferes with critical operations, renegotiate: what is essential now, what for later trials, or choose a more relaxed scenario for detailed recording. Mark unrecorded items—don't pretend completeness. Document changes, reasons, and who agreed. Resource allocation is covered next episode.

Agreement Doesn't Guarantee Feasibility

Agreeing on a 7:28 target only confirms mutual understanding, not that the current method can achieve it. One successful trial only supports that specific instance under those conditions. The requirement card separates:

Agreement status: discussion vs confirmed, which version.

Evidence status: untried vs records, which runs satisfied/unsatisfied, untested conditions.

Both can coexist: "confirmed" and "untried" simultaneously. Each trial adds a condition/result record.

Summary

Family says "early done" → card must show agreed time, conditions, verification. You say "record details" → must list exact items. Next episode: check if household equipment and solo operation can meet requirements; assign tasks to people/tools, see if paper plan works in morning.

Requirement Card Template

需求编号与版本：
从哪里来：
在什么条件下适用：
谁要做到什么：
关联哪些任务：
怎样核对：
依据放在哪里：
谁来确认约定与结果：
缺证据或没做到怎么办：
重要程度：
约定确认状态：
验证证据与结果：