ISO/IEC/IEEE 29148 — Requirements Engineering
How ISO 29148 requirements engineering processes and quality characteristics align with the NexoGraph metamodel.
ISO/IEC/IEEE 29148:2018 (Systems and software engineering — Life cycle processes — Requirements engineering) is the primary international standard for requirements engineering practice. It defines the processes, concepts, and quality characteristics needed to produce well-formed stakeholder needs and system requirements throughout a system's life cycle.
ISO 29148 is a companion standard to ISO 15288: where 15288 defines what life cycle processes produce, 29148 specifies how to produce requirements artefacts and what quality they must meet.
Process Model
ISO 29148 defines four requirements-related processes:
| Process | Abbreviation | Purpose | Output artefact |
|---|---|---|---|
| Business or Mission Analysis | BoMA | Define the problem space, operational context, and measures of success | Business Analysis Report, ConOps |
| Stakeholder Needs and Requirements Definition | StNR | Elicit and document what stakeholders need from the system | Stakeholder Requirements Specification (StRS) |
| System Requirements Definition | SyRD | Transform stakeholder needs into verifiable system requirements | System Requirements Specification (SyRS) |
| Software Requirements Definition | SwRD | Refine system requirements into software-level requirements | Software Requirements Specification (SwRS) |
The traceability chain that ISO 29148 mandates runs the full length of this pipeline: every system requirement must trace back to a stakeholder need, and every stakeholder need must trace forward to at least one system requirement.
NexoGraph Alignment
Entities
| ISO 29148 concept | NexoGraph entity | Notes |
|---|---|---|
| Stakeholder | Stakeholder | Category, influence, and interest attributes support stakeholder register |
| Stakeholder need (StRS output) | StakeholderNeed | Owns needText, rationale, priority, source |
| Operator/user stakeholder | User | Separate entity type for end-user personas |
| User need | UserNeed | Distinct from StakeholderNeed; linked via HAS_USER_NEED relation |
| Stakeholder requirement (StRS output) | Requirement with reqType: STAKEHOLDER | Formalized stakeholder requirement under STAKEHOLDER_REQUIREMENTS |
| System requirement (SyRS output) | Requirement with reqType: SYSTEM | ReqType field distinguishes stakeholder/system/subsystem/SW/HW tiers |
| Subsystem requirement | Requirement with reqType: SUBSYSTEM | Same entity type, distinguished by type and Package allocation |
| Software requirement (SwRS output) | Requirement with reqType: SOFTWARE | |
| Hardware requirement | Requirement with reqType: HARDWARE |
Requirement attributes
ISO 29148 §5.2.6 lists the attributes every well-managed requirement should carry. The table below shows how NexoGraph's Requirement and Need entities cover them:
| ISO 29148 attribute | NexoGraph field | Coverage |
|---|---|---|
| Unique identifier | uuid, shortId, customId | Full |
| Text statement | reqText / needText | Full |
| Source | source | Full |
| Rationale | rationale | Full |
| Priority | priority (CRITICAL/HIGH/MEDIUM/LOW) | Full |
| Category / type | reqCat, reqType | Full — 13-value category enum, 5-value type enum |
| Tags | tags | Full |
| Lifecycle status | lifecycleStateId / lifecycleStateName | Full — managed by the lifecycle service |
| Audit trail | createdAt, updatedAt, createdBy, updatedBy, revision | Full |
| Verification method | — | Gap — no IDAD (Inspection/Demo/Analysis/Test) field |
| Fit criteria | — | Gap — UserStory has acceptanceCriteria but Requirement does not |
| Conditions | — | Gap — no pre/postcondition field |
| Stability | — | Gap — no stability/volatility attribute |
| Risk | — | Gap — no requirement-level risk rating |
Traceability
ISO 29148 mandates bidirectional traceability across the full chain: stakeholder need → system requirement → software requirement → verification.
The upper traceability path (Stakeholder → StakeholderNeed → Requirement → SystemCapability) is supported through REFINES_INTO and SATISFIED_BY reference relations. User needs may also refine into stakeholder requirements when user concerns need formal stakeholder-level treatment.
Well-Formed Requirement Characteristics
ISO 29148 §5.2.5 defines nine characteristics that determine whether a single requirement is well-formed. NexoGraph supports authoring-time enforcement of these through the AI inline suggestion service.
| Characteristic | Definition | NexoGraph support |
|---|---|---|
| Necessary | Removes a need only at cost — no "TBD" terms | AI suggestions flag TBD/TBC text |
| Appropriate | Correct level of abstraction for the intended audience | RequirementType (STAKEHOLDER vs SYSTEM vs SOFTWARE) enforces abstraction level |
| Unambiguous | Single interpretation — no "and/or", hedging words | AI writing assist steers toward precise language |
| Complete | Contains all essential information with no missing clauses | Mandatory fields (reqText, rationale) enforce baseline completeness |
| Singular | States one and only one condition or capability | AI inline suggest can detect compound requirements |
| Feasible | Achievable within known constraints | Rationale and source fields document feasibility basis |
| Verifiable | Can be confirmed by inspection, test, analysis, or demonstration | Gap — verification method field not yet present |
| Correct | Accurately represents a real stakeholder need | Traceability to StakeholderNeed/UserNeed via REFINES_INTO provides upstream confirmation |
| Conforming | Complies with standard templates and writing conventions | AI prompts follow 29148-style sentence patterns |
Requirements Specification Characteristics
ISO 29148 §5.2.8 adds five quality characteristics that apply to a requirements set (a Package or root collection), not just individual requirements:
| Characteristic | Definition | NexoGraph support |
|---|---|---|
| Complete | Every stated need is addressed | Coverage analysis via reference relations |
| Consistent | No requirement contradicts another | AI batch consistency-check job |
| Affordable | Set as a whole is achievable within budget/schedule | Business Case linked to requirements root |
| Bounded | Scope is clearly defined and stable | Package hierarchy defines scope boundaries |
| Comprehensible | Stakeholders can understand and use the specification | Description, category, and type fields aid legibility |
Gap Analysis
The table below summarises what ISO 29148 compliance requires that NexoGraph does not yet implement:
| Gap | ISO 29148 clause | Impact | Status |
|---|---|---|---|
| Verification method field on Requirement | §5.2.6 | Requirements cannot be formally assigned an IDAD verification type | Planned |
| Fit criteria on Requirement | §5.2.6 | Acceptance cannot be quantified at the requirement level | Planned |
| Operational Concept (ConOps) entity | §6.2.1 BoMA output | No structured representation of operational scenarios/use cases above Stakeholder level | Under consideration |
| Measures of Effectiveness (MoE) | §6.2.2 StNR output | Stakeholder-level success criteria not captured as first-class entities | Under consideration |
| Measures of Performance (MoP) | §6.2.3 SyRD output | System-level performance targets not captured as first-class entities | Under consideration |
| Stability / volatility attribute | §5.2.6 | Change management cannot prioritise volatile requirements | Under consideration |
| Risk attribute on Requirement | §5.2.6 | Cannot flag high-risk requirements for additional scrutiny | Under consideration |
Recommended Workflow
To produce a 29148-aligned requirement set in NexoGraph, follow this sequence:
-
Identify stakeholders — Create
Stakeholderentities for each stakeholder group. Record category (INTERNAL/EXTERNAL/CUSTOMER/REGULATORY/PARTNER/SUPPLIER) and influence/interest levels to build the stakeholder register. -
Elicit stakeholder needs — Under the
STAKEHOLDER_NEEDSroot, createStakeholderNeedentities. Link each need to its owning stakeholder via theHAS_STAKEHOLDER_NEEDrelation. Populate source, rationale, and priority. -
Capture user needs separately — For operator/end-user stakeholders, create
Userentities and linkUserNeedentities viaHAS_USER_NEED. This keeps the ISO 42010 concern model intact: user concerns are distinct from organizational stakeholder needs. -
Write stakeholder requirements — Under the
STAKEHOLDER_REQUIREMENTSroot, createRequiremententities typed as STAKEHOLDER. Use thereqCatfield to classify each requirement (FUNCTIONAL, PERFORMANCE, INTERFACE, etc.). -
Establish traceability — Link each
Requirementback to theStakeholderNeedorUserNeedit refines usingREFINES_INTO, then link requirements to satisfying capabilities withSATISFIED_BY. -
Run AI consistency checks — Trigger the batch consistency-check job to detect conflicting requirements within a Package before review gates.
-
Advance lifecycle states — Move entities through draft → review → approved states to record the formal review and baseline events that ISO 29148 §6.2.4.3 requires.