Requirements Library
| Type | Level | UID | PREFIX | REFS | Title | Statement | Rationale | Comment |
|---|---|---|---|---|---|---|---|---|
| TEXT | This is the requirements library for Lighthouse Way projects. Requirements are organized in a top-down hierarchy, each level answering a different question: CAP- Capabilities Why does this matter? (strategic) UC- Use Cases Who does what, when? (behavioral) FEAT- Features What does the system provide? (functional grouping) FN- Functions How exactly must it behave? (testable behavior) DATA- Data Models What does the system know? (information) INTF- Interfaces What does it connect to? (integration) Traceability flows downward: each requirement links to its parent via [RELATION]. Implementation traceability links requirements to source code and tests via UID annotations in code comments. |
|||||||
| REQUIREMENT | 1 | META-001 | UID Format |
All requirements SHALL use the format PREFIX-NNN where: - PREFIX is the type code (CAP, UC, FEAT, FN, DATA, INTF) - NNN is a zero-padded sequential number within that type - UIDs are immutable once assigned |
||||
| REQUIREMENT | 2 | META-002 | Traceability Convention |
Source code referencing a requirement SHALL include a comment with the UID and a verb: - impl -- this code implements the requirement - verify -- this code tests/verifies the requirement - depends -- this code depends on the requirement - related -- this code is related to the requirement |
||||
| REQUIREMENT | 3 | META-003 | Status Values |
Requirements SHALL use one of these statuses: - Draft -- under development, not yet reviewed - Active -- approved and in effect - Obsolete -- superseded or no longer applicable - Template -- example/placeholder, not a real requirement |