What’s new in Modern Requirements4DevOps NextGen
A live tour of the NextGen release. See the rebuilt...
ISO 29148 Explained: What It Requires and How Modern Requirements Helps
Listen to this blog
According to PMI research, nearly half of the projects fail to meet their goals because of inaccurate requirements management, and this issue is common in all industries.
ISO/IEC/IEEE 29148 exists to close that gap. It covers how requirements and information within different types of documents should be managed and what characteristics individual requirements and a set of requirements should follow to accomplish the project successfully.
In this blog, we will cover what ISO/IEC/IEEE 29148 is, its three core pillars, documents that need to be implemented, key characteristics that requirements should follow, and how Modern Requirements4DevOps helps to achieve ISO 29148 compliance for teams working in Azure DevOps.
Points clés
What you’ll learn in this article
-
ISO/IEC/IEEE 29148:2018 is the international standard for requirements engineering — a common framework for eliciting, documenting, and managing requirements across the full system and software lifecycle.
-
It rests on three pillars: requirements processes (Clause 6), information items (Clause 7), and requirement quality criteria (Clause 5).
-
The standard defines a document family — BRS, StRS, OpsCon, SyRS, and SRS — each scoped to a different audience and level of technical detail.
-
Quality is measurable, not subjective: 9 characteristics judge a single requirement and 5 more judge the requirement set as a whole. It’s not a certifiable standard, but Clause 4 lets teams declare conformance.
-
Modern Requirements4DevOps turns each pillar into a native Azure DevOps workflow — living StRS/SyRS/SRS documents, auto-updating traceability matrices, and AI-assisted quality checks.
Want to apply ISO 29148 without leaving Azure DevOps?
Get a Demo
What Is ISO/IEC/IEEE 29148?
The formal title for ISO/IEC/IEEE 29148:2018 is Systems and Software Engineering, Life Cycle Processes, Requirements Engineering. It is the international standard for requirements engineering across the system and software lifecycle. Instead of describing product development methods, it provides a common framework for eliciting, analyzing, documenting, reviewing, validating, verifying, and managing requirements from initial stakeholder needs through system delivery and ongoing maintenance.
Scope-wise, it covers four things:
- The requirements engineering processes
- The information items that those processes produce
- The mandatory content inside each item
- Formatting guidance for presenting that content consistently across a project.
In short, unlike other standards that just focus on individual documents, ISO 29148 brings requirement processes, specification artifacts, and requirement quality characteristics into a single framework. Due to that, it became the reference point for organizations building complex products or safety-critical systems in regulated industries where quality directly affects project outcomes.
What Does ISO 29148 Cover? The Three Core Pillars
Pillar 1: Requirements Processes
Clause 6 in ISO 29148 covers everything related to managing the requirements engineering process, and it contains multiple subsections. For example, Clause 6.2 is related to business or mission analysis, which covers how to define the problem or opportunity space before anyone drafts the requirement. Similarly, Clause 6.3 is related to stakeholder needs and requirement definition, which explains how to identify stakeholders, capture what they actually need, and transform that input into the requirement statements. This helps in making design decisions better before anything starts.
Clause 6.4 contains definitions and a process for converting stakeholder requirements into technical, testable work items and user stories. It also helps in writing verifiable and complete system requirements. Other than that, it also covers how requirement management throughout the project should be done with change control, versioning, etc., in Clause 6.6, so that nothing drifts unnoticed as scope evolves.
Pillar 2: Information Items
Clause 7 is all about which documents teams need to produce during requirements engineering. It explains when to use different types of documents, including BRS, SRS, SyRS, StRS, OpsCon, etc., and what to include in them. Basically, it teaches how to document business-level needs and convert them into software-level details, for each scope to a different audience and level of technical precision.
We’ve explained more about each type of document covered in Clause 7 in the next section.
Pillar 3: Quality Criteria
Clause 5 defines the quality criteria for requirements. It covers what separates a usable requirement from a vague one in measurable terms rather than a personal judgment. It provides 9 characteristics that apply to a single requirement statement and 5 that apply only when judging the requirement set as a whole. These are all quality criteria we have covered in the upcoming section of this blog.
Understanding the ISO 29148 Document Family
Document
Primary Focus
Typical Author
Where It Lives
BRS
Business Requirements Specification
Defines business objectives, including goals, scope, success criteria, constraints, and expected outcomes.
Business analysts, product owners, sponsors
Clauses 8 & 9
OpsCon
Operational Concept
Covers operational scenarios, user roles, workflows, etc., and explains how the solution will operate in its intended environment.
Systems engineers, solution architects
Annex A, normative
StRS
Stakeholder Requirements Specification
Captures stakeholder expectations with acceptance criteria and without implementation details.
Business analysts, requirements engineers
Clauses 8 & 9
SyRS
System Requirements Specification
Defines what the complete system must deliver across hardware, software, interfaces, and people — including functional, non-functional, interface, and performance requirements.
Systems engineers
Clauses 8 & 9
SRS
Software Requirements Specification
Documents software behavior in sufficient detail for development and testing.
Software architects, software engineers
Clauses 8 & 9
ISO 29148 Requirement Quality Characteristics Explained
Nine Characteristics for Individual Requirements
- Necessary: If removing any requirement wouldn’t leave a gap in what the system must do, it is not necessary.
- Complete: Every threshold and condition a reader would need must be written.
- Singular: Each requirement statement must cover exactly one action or capability.
- Unambiguous: The wording of requirements should not be vague. For example, “Increase website speed” is vague, but “Increase website loading speed by 1 second” is a proper requirement.
- Correct: The requirement should accurately represent the needs of stakeholders.
- Verifiable: Requirements should not contain subjective language like “user-friendly”, which is not verifiable.
Other than the above 6 ISO 29148 requirements characteristics, requirements should be appropriate and feasible, which means requirements should be achievable within the project’s actual technical boundary, budget, and regulatory constraints.
Five Characteristics for a Requirement Set
A set of individual requirements that follow the given characteristics might fail as a whole, but the five characteristics catch what individual requirements miss.
- Complete: The requirement set should cover everything that the solution needs.
- Consistent: Make sure that none of the requirements contradict each other and that the terminologies are consistent.
- Feasible: It should be possible to implement the requirements set within the project’s real budget, schedule, and technical limits when considered together.
Other than that, the requirement set should be comprehensible, and teams must be able to validate it so that it can be checked against genuine stakeholders’ intent.
Is ISO 29148 Mandatory? Can You Get Certified?
ISO/IEC/IEEE 29148 is not a mandatory regulatory standard, and there is no regulatory body that provides certifications against it. Unlike other ISO standards such as ISO 9001 or ISO/IEC 27001, it just serves as guidance for establishing consistent requirement engineering practices. Generally, companies adopt the requirement engineering framework offered by it when customers, regulators, or contractual agreements require a structured approach to requirement development and management.
However, clause 4 in the standard lets the organization declare full conformance to its processes, its information items, or both.
How Modern Requirements4DevOps Helps Teams Apply ISO 29148
Applying ISO 29148 manually means juggling between Microsoft Word files for documentation, spreadsheets for traceability matrices, and emails for reviews. However, Modern Requirements4DevOps turns each pillar into a native Azure DevOps workflow instead. Here is how it helps:
- Create living documents mentioned in ISO 29148, Clause 7: Develop different types of living documents, including StRS, SyRS, and SRS, by drag-and-drop requirements, keeping Pillar 2’s document family tied to live work items, not a disconnected export. So, documents can be audit-ready at any time.
- Ensure end-to-end requirements traceability: As mentioned in Clause 6 and Clause 9 Annex A, teams need to implement end-to-end traceability between requirements. With Modern Requirements4DevOps, teams can automatically generate horizontal matrices that trace from epics to test cases and intersectional matrices that allow finding the gap between any two types of work items. Also, whenever a link between requirements changes, traceability matrices automatically update and reduce the headache of manually maintaining a spreadsheet.
- Use AI to assess quality gaps in requirements: The analyze feature of Copilot4DevOps allows teams to find gaps and ensures users have complete, feasible requirements and follow all characteristics mentioned in clause 5.
Furthermore, teams can review requirements with e-signature directly within Azure DevOps and stay CFR 21 Part 11 compliant. The baseline module helps teams to look at and approve requirements that follow ISO 29148, so while implementing, development teams don’t drift from them. Furthermore, if required to ship the same product in a different region and follow different compliance requirements, the team can clone the same requirements and create a different variant of that.
Overall, Modern Requirements4DevOps automates compliance within Azure DevOps and keeps everything audit-ready.
Questions fréquemment posées
Did ISO 29148 officially replace the older IEEE 830?
Yes, it superseded IEEE 830 in 2011 and expanded coverage to include quality criteria and management processes.
Is ISO 29148 mandatory, and can teams get certified?
No accreditation body certifies it, though contracts in regulated industries often mandate conformance, which the standard formally defines.
Does ISO 29148 support Agile development methodologies too?
Yes, it explicitly permits user stories instead of formal shall statements, and doesn’t mandate any single methodology.
How do teams apply ISO 29148 inside Azure DevOps?
Tools like Modern Requirements4DevOps author specification documents, build traceability matrices, and run AI-assisted quality checks natively within Azure DevOps.
Table des matières
Articles récents
BRD vs SRS vs PRD: Which Requirements Document to Use When
Understand the distinct roles of a BRD, SRS, and PRD....
How to Baseline Requirements in Azure DevOps (Step by Step with Modern Requirements4DevOps)
Azure DevOps cannot lock a requirements snapshot on its own....
