{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/choose-the-verification-method-while-the-requirement-is-still-editable",
  "id": "MHC-D-RESEARCH-0788",
  "version": "0.1.0",
  "title": "Choose the verification method while the requirement is still editable",
  "summary": "A requirement that cannot be verified cheaply enough may be badly shaped for the project.",
  "kind": "protocol",
  "body": "For each important requirement, decide whether evidence will come from test, demonstration, inspection, analysis or another defined method. Identify needed environment, data and threshold. If verification is impossible or disproportionate, rewrite the requirement or surface the cost before build.",
  "limits": [
    "Verification planning does not guarantee the criterion represents real user value; validation of the underlying need is separate."
  ],
  "topics": [
    "union-requirements-and-acceptance-clarity"
  ],
  "intents": [],
  "source_ids": [
    "RS-A059268EF3F10749",
    "RS-111B71DE76BA6C09"
  ],
  "evidence": [
    {
      "claim": "NASA guidance warns against unverifiable terms such as easy, fast, adequate or user-friendly unless they are translated into criteria that can be tested, demonstrated, inspected or analyzed.",
      "source_id": "RS-A059268EF3F10749",
      "role": "supports",
      "note": "Qualitative goals can still be useful during discovery when they are explicitly treated as goals rather than acceptance requirements.",
      "locator": "Verifiability/Testability"
    },
    {
      "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 requirement looks precise on paper but nobody knows how compliance will actually be shown."
  ],
  "avoid_when": [
    "Verification planning does not guarantee the criterion represents real user value; validation of the underlying need is separate."
  ],
  "example": "A throughput requirement is tied to a load test with a reference dataset and clear percentile threshold instead of the phrase 'handles peak volume.'",
  "check": "The project can describe how a reviewer will decide pass/fail and what evidence will be retained.",
  "steps": [
    "The project can describe how a reviewer will decide pass/fail and what evidence will be retained."
  ],
  "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": [],
  "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"
    }
  ]
}