{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/give-each-requirement-one-behavior-to-prove",
  "id": "MHC-D-RESEARCH-0781",
  "version": "0.1.0",
  "title": "Give each requirement one behavior to prove",
  "summary": "One sentence can hide three different definitions of done.",
  "kind": "heuristic",
  "body": "Split independently verifiable behaviors into separate requirement or acceptance statements. Keep shared rationale outside the statements. If two behaviors must always be verified together, explain why rather than joining them for convenience.",
  "limits": [
    "Do not fragment a single coherent condition into tiny statements that lose necessary context; the unit is one independently meaningful behavior."
  ],
  "topics": [
    "union-requirements-and-acceptance-clarity"
  ],
  "intents": [],
  "source_ids": [
    "RS-A059268EF3F10749",
    "RS-111B71DE76BA6C09"
  ],
  "evidence": [
    {
      "claim": "NASA's requirements checklist emphasizes clarity, one thought per requirement, completeness, explicit assumptions, consistency, traceability, feasibility and verifiability.",
      "source_id": "RS-A059268EF3F10749",
      "role": "supports",
      "note": "The checklist is for systems engineering; smaller tasks can apply the principles proportionally.",
      "locator": "Requirements validation checklist"
    },
    {
      "claim": "NASA recommends identifying a verification approach for requirements and keeping each requirement uniquely identifiable with a definitive source.",
      "source_id": "RS-111B71DE76BA6C09",
      "role": "supports",
      "note": "The appropriate verification method and documentation depth depend on risk and project scale.",
      "locator": "Requirements Verification Matrix"
    }
  ],
  "use_when": [
    "A sentence contains several actions, exceptions and outcomes joined by 'and' so partial completion is hard to see."
  ],
  "avoid_when": [
    "Do not fragment a single coherent condition into tiny statements that lose necessary context; the unit is one independently meaningful behavior."
  ],
  "example": "'The service validates the file, rejects invalid rows and emails a report' becomes three checkable outcomes with their own error cases.",
  "check": "Each statement can be marked pass or fail without the answer depending on another clause in the same sentence.",
  "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-111B71DE76BA6C09",
      "title": "Appendix D: Requirements Verification Matrix",
      "url": "https://www.nasa.gov/reference/appendix-d-requirements-verification-matrix/"
    }
  ],
  "relations": [
    {
      "from": "MHC-D-RESEARCH-0781",
      "to": "MHC-D-RESEARCH-0783",
      "type": "useful_with",
      "url": "/knowledge/write-acceptance-evidence-before-implementation-starts"
    }
  ],
  "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"
    }
  ]
}