Requirement
Stable requirement identity immutable revisions acceptance criteria outbound revision-pinned trace links and derived revision-set views
Bundle → Layer → Finding → Questions Filled
3 bundles · 3 layers · 5 findings · 10 questions
Identity and revisions Which requirement and which version.
Stable identity
One identifier across all revisions.
Requirement identity
The identifier and owner of the requirement.
- What is the requirement's stable identifier, and who owns it?
- Which specification or baseline does it belong to?
Revision
Immutable revisions with their change reasons.
- Which revision is current, and what changed from the previous one?
- Who approved the revision, and when?
Content What is required and how it is accepted.
Statement and criteria
The requirement text and its acceptance criteria.
Statement quality
The text is necessary, unambiguous and verifiable.
- Is the statement singular, unambiguous and verifiable?
- Which type is it, such as functional, performance or constraint?
Acceptance criteria
How satisfaction is judged.
- Which acceptance criteria define when the requirement is met?
- Which verification method is planned: test, analysis, inspection or demonstration?
Traceability Where it comes from and what meets it.
Trace links
Revision-pinned links to sources, designs and tests.
Upstream and downstream
Links to stakeholder needs, design elements and verification.
- Which need, regulation or parent requirement does it derive from?
- Which design elements and tests are linked, and to which revision?
Classifiers Filled
- Family
- World Models
- Category
- Information and virtual systems
- Entry kind
- standalone-mm
- Navigation path
- NAV.INF.REC.REQ
- Domain
- INF.REC.REQ
- Industry
- Cross-industry
- Tags
- requirementinf.rec.req
What it is Filled
A requirement is a stated need or condition that a system, product or service must meet, kept as a record with a stable identity, immutable revisions, acceptance criteria and trace links to its origin and to what satisfies or verifies it. It is the recorded statement, not the design that answers it or the test that checks it.
Why it exists Filled
Stable requirement identity immutable revisions acceptance criteria outbound revision-pinned trace links and derived revision-set views
Distinguishing features Filled
- Identity is stable while revisions are immutable, so links can pin the exact text they refer to.
- It carries acceptance criteria that make it verifiable, unlike a goal or wish.
- Trace links point outward to sources, designs and tests, which live in their own records.
- Distinct from a policy rule or constraint, which governs behaviour generally rather than a specific system.
What robots and AI may and may not do Filled
Must not
- Edit an approved revision in place instead of creating a new one.
- Approve or baseline requirements.
- Delete trace links to hide gaps in verification.
- Mark a requirement as verified without linked evidence.
Only with a human decision
- Approving and baselining requirements.
- Accepting changes to requirements under contract or regulation.
- Waiving a requirement or accepting a deviation.
May
- Draft requirements and acceptance criteria for human review.
- Check statements for ambiguity, duplication and missing criteria.
- Report trace coverage and links pinned to outdated revisions.
- Generate test ideas from acceptance criteria.
Moral aspects Filled
- Missing or wrong safety requirements lead to harmful products.
- Requirements decide whose needs are served, so affected users should be represented.
- Traceability supports accountability when things go wrong.
Who is affected
- End users of the system
- Engineering and test teams
- Customers, regulators and certifiers
Owners Filled
Steward
The requirements owner or systems engineer responsible for the specification, under the project's change control.
Master systems
- Requirements management tool
- Application lifecycle management system
Links to other meta-models Filled
neighbor
- wm-knw-013-constraint-requirement-rule - General constraints and rules versus system-specific requirements.
references
- wm-sft-015-test-case-test-result - Tests verify requirements through trace links.
requires
- wm-xct-022-version-change-history - Immutable revisions follow the version history pattern.
What else AI and robots need to interact with it Filled
Identity and identifiers required Filled
- A requirement is identified by a stable identifier within its specification plus a revision number.
- ReqIF exchange uses identifiers for each specification object.
Direct properties not applicable Not applicable
Not applicable
A requirement is an information record; it may state physical limits but has no physical properties itself.
Recognition optional Filled
- A requirement has an identifier, a shall-type statement, a revision and acceptance criteria.
- Often confused with goals, design decisions, user stories without criteria and test cases.
Capabilities and actions required Filled
- Requirements can be revised, baselined, linked, verified, deferred or retired.
- Revision sets can be derived as views of a specification at a point in time.
Hazards and failure modes required Filled
- Silent changes that break the link between requirement and verification.
- Ambiguous requirements leading to unsafe or disputed outcomes.
Standards and interfaces required Filled
- OMG ReqIF for exchange of requirements between tools.
- OSLC Requirements Management for linking across lifecycle tools.
- ISO/IEC/IEEE 29148 for requirement content and quality.
Context of use required Filled
- Used in systems, software and product engineering and in procurement.
- Regulated sectors such as aviation, medical devices and automotive require traceability.
Sources Filled
- ISO/IEC/IEEE 29148 Systems and software engineering - Requirements engineering (ISO/IEC/IEEE)
- Requirements Interchange Format ReqIF (Object Management Group)
- Guide to Writing Requirements (INCOSE)
Open questions
- Planned model: boundary questions, research and every section remain to be written.
Machine files
Provenance
planned (registry candidate) · todo
Built from: models/runtime-index.json, ver-cy/world-models/card-supplements/wm-rec-006-requirement.json
Planned entry, hidden from the catalogue until researched.