Spec Driven Development — Chapter 07: 2c - The Scope of a Spec: How Much Fits in One Specification

1. Pre-Reading Briefing

Core Question: How much work should one specification cover so it can be reviewed and its result checked as a useful piece of software?
Key Points to Watch For:
- Notice what Ködel treats as the unit of a spec, and how he tests whether the boundary is small enough to review but large enough to deliver value.
- Compare his reasons for grouping “complete and reopen” while separating “create and delete.”
- Watch how he proposes splitting a large feature and what becomes visible to a user after each slice.
- Look for warning signs that a split follows technical layers rather than user-visible behavior.
- Identify the situations where he says the method's up-front work may not pay off, and ask what assumptions those exceptions rely on.
Context & Thread from Prior Chapters: Chapter 5 identified the parts of a spec; Chapter 6 examined the precision of each requirement sentence. This chapter moves to the size and boundary of the spec as a whole. Keep the earlier edit-task example in mind: a reviewable boundary should help expose decisions like whether a task counts its own unchanged title as a duplicate.

Pending reading.

Pending post-reading review.