ISO 29148 Explained: What It Requires and How Modern Requirements Helps

July 16, 2026
Reading Time: 8 minutes

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.

Puntos clave

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.

Preguntas frecuentes

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.

Start using
Modern Requirements
today

✅ Defina, gestione y realice un seguimiento de los requisitos en Azure DevOps
✅ Colabore sin problemas entre equipos regulados
✅ Empiece GRATIS, sin necesidad de tarjeta de crédito

Comience la prueba gratuita