A functional requirements document connects the originating need with inputs, processing, outputs, and state changes. Check that each transition preserves the data conditions the document promises. That gives analysts and developers a concrete inconsistency to resolve before implementation.
This original fictional equipment-return register supplies three rules and fixed walkthrough cases. The walkthrough checks the proposed specification; it is not a test of a delivered register.
Begin with the need and data conditions
Need N1 is to distinguish outstanding items from returned items in a register.
The model uses three data fields: itemID, status, and returnReference. Status is either CheckedOut or Returned. Its invariant is: a Returned item must have a returnReference. An invariant is a condition that must remain true across the relevant operations.
For this exercise, a valid return event supplies a known item ID and a nonempty return reference. The exact user-facing message wording remains a review question; message labels below describe the required outcome.
Archived U.S. Department of Justice requirements-analysis guidance connects functional and data requirements, inputs/processes/outputs, state changes, traceability, and test planning. We use those historical analysis principles here, without adopting the agency's approval or legal procedures. Read the archived requirements-analysis chapter.
Specify each rule through its transition
| Rule | Input and current state | Required processing and output | Next state and data |
|---|---|---|---|
| R1, from N1 | Known item, CheckedOut; valid return event supplies reference | Record the supplied reference and report the return outcome | Returned, with that reference recorded |
| R2, from N1 | Known item already Returned; duplicate return event | Report Already returned; do not overwrite the original reference | Returned, original reference unchanged |
| R3, from N1 | Unknown item ID; return event | Report unknown-item outcome; do not create a returned item | No new item or returned record |
R1 must specify both the status change and the reference. R2 prevents a repeated event from replacing the first return's record. R3 prevents an unknown identifier from creating the appearance of a completed return.
The table defines observable behavior without choosing a database, screen layout, or service architecture. Those choices need not be invented to make the rule clear.
Walk through the fixed examples
The original model fixtures are:
| Case | Starting record and event | Specified outcome |
|---|---|---|
| F1 → R1 | E17, CheckedOut, no reference; event reference RET-01 | E17 becomes Returned with RET-01. |
| F2 → R2 | E18, Returned, reference RET-00; repeated event offers RET-02 | Already returned; RET-00 remains. |
| F3 → R3 | E99 is absent; return event offers RET-03 | Unknown item; E99 is not created. |
For each case, ask which need it traces to, which rule applies, and whether the proposed output preserves the invariant. These are expected model outcomes. The example does not record actual application execution or user acceptance.
Invalid or missing return-reference behavior for a new return is not fully specified in this small packet. Keep that exception visible as a question for requirements review instead of making the walkthrough invent a production rule.
Compare the incomplete rule
Incomplete R1 says only: “When a return event is received for a CheckedOut item, change its status to Returned.” Applied to F1, that statement leaves the reference unrecorded. The resulting description conflicts with the invariant.
The completed R1 explicitly records the supplied reference along with the status change. That repairs the specification's missing data effect. It does not prove the eventual code will implement it correctly; the proposed verification example now gives a tester something specific to check later.
In the interactive example, select R1, R2, or R3 to inspect the need/input/state/process/output/data chain. Compare incomplete and completed R1, then walk through the three fixed fixtures. Keep the distinction between a model-consistency result and an actual software test visible.
Copy this prompt to review your requirements
Create a complete self-contained HTML functional-requirements review.
Originating need: [ID/text]. Data fields/states/invariants: [definitions].
Rules: [inputs/currentstate/processing/outputs/nextstate]. Verification
examples: [expected fixtures, not actual results]. Open behavior: [gaps].
Include a separate fictional equipment-return register. N1 distinguish
outstanding/returned items. Data itemID/status/returnReference; states
CheckedOut/Returned; invariant Returned requires returnReference.
R1 knownCheckedOut+validreturnevent with nonemptyreference records it
and changes Returned. R2 alreadyReturned+duplicateevent reports Already
returned and preservesoriginalreference. R3 unknownID nevercreatesitem.
Every rule traces N1. Message outcome labels are specified, exactwording
unagreed. Newreturn missingreference behavior remains an openquestion.
Fixtures F1 E17CheckedOut/noRef +RET-01→Returned/RET-01; F2 E18Returned/
RET-00 +repeateventRET-02→Alreadyreturned/originalRET-00; F3 absentE99
+RET-03→unknown/noitemcreated. Walkthrough model only, not actualproduct
testing. Compare incompleteR1 changesstatus but omits recordingreference
with completedR1; expose invariantconflict. No UI/database architecture,
implementation, UATapproval or testedproduction claim.
Allow requirementtrace inspection, threefixture walkthroughs, incomplete/
complete comparison, blank need/rule/data/invariant/example fields,
named missing-need/rule feedback, temporarynotes retained across views/
validation, confirmedreset. Display usertext safely as text. Labeled
keyboard-accessible controls, visiblefocus, systemfonts at least16px,
readable360px layout without horizontal scrolling, inline CSS/JavaScript,
no dependencies. Return complete HTML.
Keep the missing behavior beside the rule
Review the prepared specification in NOS with the analyst and developer responsible for returns. Directly clarify the visible R1 wording so the status and reference changes appear together. Then take the missing-reference question into their requirements discussion; a neat table should make that gap easier to see.