Methodology catalog
Each entry says when it fits and, as importantly, when it does not. Candidates are listed but not yet researched.
| Methodology | Domain | Family | State | Source of truth | Unfit when |
|---|---|---|---|---|---|
| Customer development / lean experimentation no answers recorded | business | exploratory | candidate | To research | |
| Process modelling (BPMN-led) no answers recorded | business | model-driven | candidate | To research | |
| Set-based concurrent engineering 4 of 4 answers assumed | physical | exploratory | listed | A set of design alternatives and the constraints that narrow it; the chosen design emerges late | Constraints are already fixed and one design clearly satisfies them, The team cannot afford to carry several alternatives in parallel |
| V-model no answers recorded | physical | verification-paired | candidate | To research | |
| Urban planning methods no answers recorded | physical/built-environment | planning | candidate | To research | |
| Building information modelling 6 of 6 answers assumed | physical/built-environment/buildings | model-driven | listed | A shared building information model; drawings and schedules are derived from it | A small, simple building where full ISO 19650 information management outweighs its benefit (the standard allows scaling down; scale it), No partner can read or build from the model |
| Model-based systems engineering no answers recorded | physical/hardware | model-driven | candidate | To research | |
| Behaviour-driven development 5 of 5 answers assumed | software | test-first | listed | Automated Given/When/Then scenarios | Internal library code, Wire-level details: use a contract |
| Consumer-driven contracts 4 of 4 answers assumed | software | contract | listed | Each consumer's published expectations | One consumer, Unknown public consumers |
| Contract-first / API-first 5 of 5 answers assumed | software | contract | listed | A machine-readable contract (OpenAPI, AsyncAPI) | A solo spike with no second consumer yet |
| Design by contract 5 of 5 answers assumed | software | contract | listed | Preconditions, postconditions and invariants | Types plus tests express the same thing more cheaply |
| Model-driven development 4 of 4 answers assumed | software | model-driven | listed | A model; code generated from it | General product development |
| Small change 4 of 4 answers assumed | software | maintenance | listed | Existing tests, contract or code | New module behaviour or a new public endpoint |
| Spec-anchored (SAD) 5 of 5 answers assumed | software | spec-driven | listed | A living spec kept beside the code | The spec is unverified prose |
| Spec-as-source 5 of 6 answers assumed | software | spec-driven | evidenced | Spec; code is generated from it and not edited by hand | Exploratory or UI-heavy work where behaviour is discovered by building, Repository-scale systems specified in prose, No automated check stands between regeneration and merge |
| Spec-first 5 of 5 answers assumed | software | spec-driven | listed | A change spec that expires at merge | Tiny changes, Intent that must stay true for months |
| Spike / prototype 5 of 5 answers assumed | software | exploratory | listed | Running experiment plus a short learning note | A public surface, custody or identity risk, Multiple consumers already depend on it |
| Test-driven development 5 of 6 answers assumed | software | test-first | evidenced | Tests | The product shape is unknown: spike first, Visual or interaction exploration |