Shaping

Shaping negotiates what to build. It keeps requirements separate from mechanisms, compares real alternatives, and leaves the user in control of scope and tradeoffs.

Do not force a shaping ceremony onto a clear specification. If the request already defines the behavior and constraints, proceed to planning or implementation as requested.

Core notation

• R0, R1, ... are requirements: outcomes, constraints, or business rules.
• A, B, C, ... are mutually exclusive solution shapes.
• A1, A2, ... are parts that combine within a shape.
• A2-A, A2-B, ... are alternatives for one part.
• CURRENT describes the existing system when a baseline helps.
• Detail A expands a selected shape; it is not a new alternative.

Requirements state what must be true. Shape parts state the concrete mechanism that makes it true. If a part merely repeats a requirement, it is not yet a mechanism.

Keep at most nine top-level requirements. Group related detail under sub-requirements such as R3.1 when needed.