{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/write-the-need-before-naming-the-implementation",
  "id": "MHC-D-RESEARCH-0780",
  "version": "0.1.0",
  "title": "Write the need before naming the implementation",
  "summary": "A solution written too early can hide the requirement it was supposed to satisfy.",
  "kind": "protocol",
  "body": "Ask why the requested implementation is needed and write the desired capability or outcome separately. Keep hard constraints, but distinguish them from a proposed way to meet the need. Only then compare solution options.",
  "limits": [
    "Some implementation choices are genuine constraints because of standards, contracts, architecture or interoperability; label the source of that constraint."
  ],
  "topics": [
    "union-requirements-and-acceptance-clarity"
  ],
  "intents": [],
  "source_ids": [
    "RS-A059268EF3F10749",
    "RS-AA4CF71A3FB24D22"
  ],
  "evidence": [
    {
      "claim": "NASA guidance recommends requirements that identify the responsible product or party and needed behavior, use consistent terminology, state what is needed rather than prescribing implementation, and include rationale and assumptions.",
      "source_id": "RS-A059268EF3F10749",
      "role": "supports",
      "note": "Some constraints legitimately specify implementation when mandated by architecture, regulation or compatibility.",
      "locator": "Editorial checklist; general goodness checklist"
    },
    {
      "claim": "GOV.UK user-story guidance recommends recording the actor, needed action and goal, focusing on why the need exists, and using acceptance criteria to state observable outcomes that show the job is done.",
      "source_id": "RS-AA4CF71A3FB24D22",
      "role": "supports",
      "note": "User-story syntax is one framing method and is not appropriate for every technical, regulatory or infrastructure requirement.",
      "locator": "What to include; Focus on the goal; Acceptance criteria"
    }
  ],
  "use_when": [
    "A requirement arrives already phrased as a feature, field, button, tool or technical solution and the underlying job is unclear."
  ],
  "avoid_when": [
    "Some implementation choices are genuine constraints because of standards, contracts, architecture or interoperability; label the source of that constraint."
  ],
  "example": "'Add an Excel export button' becomes 'Users need to reconcile selected records outside the system without manual re-entry'; export is then one candidate solution.",
  "check": "The requirement still makes sense if the first proposed implementation is replaced by another feasible approach.",
  "steps": [
    "The requirement still makes sense if the first proposed implementation is replaced by another feasible approach."
  ],
  "sources": [
    {
      "id": "RS-A059268EF3F10749",
      "title": "Appendix C: How to Write a Good Requirement",
      "url": "https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/"
    },
    {
      "id": "RS-AA4CF71A3FB24D22",
      "title": "Writing user stories",
      "url": "https://www.gov.uk/service-manual/agile-delivery/writing-user-stories"
    }
  ],
  "relations": [
    {
      "from": "MHC-D-RESEARCH-0780",
      "to": "MHC-D-RESEARCH-0781",
      "type": "use_before",
      "url": "/knowledge/give-each-requirement-one-behavior-to-prove"
    }
  ],
  "collections": [
    {
      "id": "RC-272C54FF0D8FF2BA",
      "title": "Turn ambiguous work into requirements that can be checked",
      "url": "/collections/turn-ambiguous-work-into-requirements-that-can-be-checked"
    }
  ]
}