Requirements management keeps a project's promises connected to the work that implements and verifies them. It matters whenever a change to one feature can affect another feature, a test, or a customer's expectations.
NASA's systems engineering guidance treats this as continuing work: establish an agreed baseline, track relationships between requirements, assess proposed changes, and communicate approved changes. A requirement should remain traceable both to the need that justified it and to the lower-level work that satisfies it. NASA requirements management.
A small working example
Consider an illustrative article reader. A user needs to open a title and read the complete article. A useful requirement could be: “Selecting a published title displays the article body, or an explicit error with a retry action.”
Give that requirement an identifier, such as READ-01. Link it to the reader component, the content endpoint, and a check that opens a published article. Keep the original user need alongside it. A passing homepage check alone would not demonstrate READ-01.
If someone proposes returning only a preview to reduce response size, the links expose the impact: the endpoint contract, reader behavior, and verification all need reconsideration. Record the decision and its rationale before calling the change complete.
Make requirements testable
“The reader should be good” leaves too much interpretation. Describe observable behavior, keep distinct obligations separate, and define how each will be checked. NASA's writing checklist emphasizes clarity, verifiability, and one thought per requirement. How to write a good requirement.
For a small project, a table can hold the identifier, statement, owner, source, implementation link, test link, and current status. This is an example workflow, not a prescribed NASA template. The useful property is that a reviewer can follow a promise to evidence and follow a proposed change back to the promises it affects.
What counts as completion?
A status label is a claim; a linked verification result supports that claim. When a requirement changes, preserve its history and update the affected checks. Otherwise yesterday's successful test may describe behavior the product no longer promises.