Learning objectives
After this chapter you should be able to:
- Write a requirement as a shall-statement, a use case and a user story, and check it for the qualities that matter most here.
- State the load-bearing assumption of classical requirements engineering and use the negation test to show which half fails when the implementer proceeds without asking.
- Summarize what has been measured about code generation from ambiguous specifications.
- Explain, with Chapter 2's decision rule, why the activity inverts while the specification mechanism recalibrates.
- Write an executable specification, with every property bound to a check, and make clarification a gate in the workflow.
- Classify defects by root cause, and say what data would show specification is not the largest source.
Opening case
A composite case, not a real engagement.
The ticket was four sentences, written by a consultant after a thirty-minute call with a logistics company's operations manager. "Dispatchers can reassign jobs to other drivers. Late jobs are highlighted. Customers are notified when a job's status changes. A daily report shows on-time performance." The consultant and the manager knew what each sentence meant. It summarized a conversation, which is what a ticket is for.
The chapter continues from here.
What the chapter covers
- 4.1 The classical method
- 4.1.1 What requirements engineering is for
- 4.1.2 Functional and quality requirements, and the standard
- 4.1.3 Elicitation is a conversation
- 4.1.4 The forms requirements take
- 4.1.5 A worked example: Dispatch, specified for people
- 4.1.6 What it got right
- 4.2 The assumption it depends on
- 4.3 What agents change
- 4.3.1 Agents fill gaps and, by default, do not ask
- 4.3.2 Tacit intent reaches the model only if someone writes it down
- 4.3.3 The Mission Brief
- 4.4 The verdict
- 4.5 What replaces it: the executable specification
- 4.5.1 Parts of an executable specification
- 4.5.2 Behavior rules in EARS
- 4.5.3 Examples in Gherkin
- 4.5.4 Property-based acceptance
- 4.5.5 Non-goals and open decisions
- 4.5.6 Binding every property to a named check
- 4.5.7 Dispatch, rewritten
- 4.5.8 Using the specification, and making clarification a requirement
- 4.6 Lab: Executable specification
- 4.7 What would make this verdict false
Lab and prediction
Lab: Executable specification
Feeds milestone M1. How the labs fit the project
The lab tests this prediction from the working paper the book grows from (Smith 2026a):
- P2 Defects traced to missing or ambiguous specification are the largest root-cause category
A result that contradicts a prediction, honestly reported, is a result. You are graded on accurate records and reasoned interpretation, not on agreeing with the book.
Summary
- Load-bearing assumption: implementers fill gaps with tacit knowledge and ask when unsure; the user-story tradition states it outright.
- Evidence: in benchmarks, models by default write code rather than ask, lose correctness on ambiguous descriptions, and improve when they do ask. No study measures the effect over a real multi-week project.
- Verdict: inverts. Explicit, checkable intent is scarce, and the specification package becomes the primary input. The specification mechanism itself recalibrates: the same documents and checks at a higher completeness bar.
- Replacement: the executable specification, with every property bound to a named check, plus clarification enforced by the workflow: questions before code, a gate on open decisions, answers recorded.
- The verdict would soften to recalibrate if agents reliably asked unprompted or had the tacit context.
Key terms
- Tacit knowledge
- knowledge people hold and use but cannot fully state (Polanyi 1966).Also used in 1, 2, 10
- Executable specification
- a specification whose every statement of required behavior is a runnable check or bound to one.Also used in 3, 5, 13, 18
- Specification package
- the specification plus its linked, versioned decisions and context.
- EARS
- Easy Approach to Requirements Syntax; five sentence templates.
- Gherkin
- the Given/When/Then format for scenarios.
- Property-based acceptance
- acceptance stated as properties that hold over a domain of inputs.Also used in 13
- Non-goal
- an explicit statement of what is out of scope.
- Open decision
- a stakeholder's choice not yet made, recorded with an owner and a default.
- Clarification gate
- a workflow step requiring the agent to raise open questions before implementing, and blocking work while open decisions are unresolved.
- Property Coverage Index (PCI)
- the fraction of acceptance properties bound to a named check and evidence location.
Connections
Where this chapter and another point to each other most often.
- Chapter 2: The Assumption Audit: A Method That Outlasts the Tools
Explain, with Chapter 2's decision rule, why the activity inverts while the specification mechanism recalibrates. 5. - Chapter 3: Life-Cycle Models When Iteration Is Cheap
The economic argument for doing it early is old: fixing a problem after delivery is often 100 times more expensive than fixing it during requirements and design (Boehm and Basili 2001), though the escalation is not a law (Menzies et al. 2017; Section 3.1.5). - Chapter 6: Cost and Schedule Estimation After COCOMO
It is the dispatch dashboard of Chapter 6, seen from the specification side.* The ticket was four sentences, written by a consultant after a thirty-minute call with a logistics company's operations manager. "Dispatchers can reassign jobs to other drivers. - Chapter 8: Coordination at Scale: Shared Context vs. Shared Messages
From Chapter 8: The specification never said what a reassignment means, and each agent filled the gap plausibly (Chapter 4 explains why). - Chapter 12: Reviews: Inspecting Evidence, Not Diffs
From Chapter 12: Intent lives in the specification and acceptance properties a human wrote before generation (Chapter 4), and review should check the change against those, not the agent's story. ### 12.3.3 Agent defect classes Agents make some defects people rarely make, and make them look right. - Chapter 13: Testing, Evaluation, and Tests as Steering
And the checks should be read-only to the implementing agent, which could otherwise edit them to pass (Chapter 13). ### 4.5.7 Dispatch, rewritten Here is each requirement of Table 4.1 in executable form. - Chapter 16: Roles and the Four Conditions for Assurance
From Chapter 16: It needs an executable attack: replay the request as a different user and expect a refusal. - The four specification ambiguities. No agent role settles these; a person does (Chapter 4).
Further reading
- Brooks (1987), "No Silver Bullet." The requirements passage is the shortest, clearest statement of why this part of engineering is hard.
- Jeffries (2001), "Essential XP: Card, Conversation, Confirmation." This chapter's load-bearing assumption, in the words of the people who held it.
- Wu and Fard (2025) and Vijayvargiya et al. (2026). Two careful studies of whether models ask. Read the threats to validity, then ask what a study on a real project would need.