RMMi 1.0: A New Maturity Model for Requirements Engineering

Introduction

Requirements engineering has long been recognized as a cornerstone of software and systems development. Yet, despite decades of research and the availability of standards, many organizations still struggle with requirements that are incomplete, inconsistent, or poorly managed. Existing maturity models such as CMMI and TMMi have successfully structured the disciplines of development and testing, but none has focused exclusively on the practices that define the quality of requirements themselves.

The RMMi was designed to fill this gap. Initiated in 2019 and shaped by iterative development and practitioner feedback, it consolidates years of exploration into a coherent framework. With the release of version 1.0 in 2025, RMMi offers a stable and recognized reference model for organizations seeking to improve their requirements engineering practices.

Structure and Maturity Levels of RMMi 1.0

This section outlines the four core RMMi domains and explains how they interlock with the five capability maturity stages that are used in common maturity models.
At the heart of the RMMi are four domains - elicitation, documentation, validation, and management - that together reflect the natural lifecycle of requirements. While these domains align with the competences emphasized in the IREB CPRE syllabi, their originality within the RMMi lies in how they are operationalized into maturity practices and levels. They are not mere copies but reinterpreted pillars, integrated into a maturity pathway that allows organizations to benchmark, evaluate, and improve over time.

Elicitation addresses the ability to understand stakeholders, not merely in terms of what they ask for but also in terms of their latent needs, expectations, and constraints. Documentation transforms the raw material from elicitation into a structured set of functional, quality, and constraint requirements. Validation ensures that what has been written truly corresponds to what is needed, turning vague obligations into clear, testable acceptance criteria. Finally, Management provides continuity by governing the evolution of requirements throughout the lifecycle.

Together, these four domains establish a backbone for requirements maturity. Each domain contributes in its own way, but it is their integration into a maturity scale - from ad hoc practices to optimized, continuously improving ones - that makes the RMMi truly distinctive.

Additionally, RMMi defines several cross-cutting domains that complement the four central domains of requirements engineering. These domains notably address alignment with organizational strategy and governance, the use of Automation and AI in requirements processes, the definition of roles and skill development, as well as ethical and sustainability considerations, including digital sobriety. One of these domains focuses more specifically on quality criteria applied to requirements (for example the INVEST principle – Independent, Negotiable, Valuable, Estimable, Small, Testable, originally introduced by Bill Wake in 2003).

Meeting the Challenges of the 21st Century

What sets RMMi apart is its deliberate response to the challenges that requirements engineering faces today.
Artificial intelligence has made systems more powerful but also more opaque. Requirements are no longer confined to specifying functional outputs; they must now address explainability, accountability, and fairness. Stakeholders want to know not only that a decision was made, but also why it was made, under what data assumptions, and with what degree of confidence.
Cybersecurity and data protection are equally pressing. The cost of breaches is measured not only in financial loss, but also in loss of trust and reputation. Requirements must anticipate potential threats, define resilience criteria, and embed compliance obligations from the start. Unlike vague statements of intent, RMMi practices encourage precise and verifiable security requirements.

Ethics and regulation have become unavoidable dimensions of requirements engineering. Systems are judged not only on their efficiency but on their societal impact. Whether in biometric systems or automated decision-making, requirements must capture ethical boundaries and demonstrate compliance with evolving regulatory landscapes such as GDPR or the upcoming AI Act.

Sustainability introduces another layer. Systems must now account for their environmental footprint, energy consumption, and lifecycle responsibility. Requirements specifying maximum energy budgets, limitations on data retention, or the use of green infrastructures are becoming part of mainstream engineering practices.

Finally, the increasing interconnection of systems means that interoperability and resilience are no longer optional. Requirements must anticipate failures in third-party APIs, cloud infrastructures, or IoT ecosystems, ensuring that systems degrade gracefully rather than collapse.

By embedding these dimensions, RMMi ensures that requirements are not simply technical artifacts but instruments for building systems that are responsible, trustworthy, and future-proof.

Real-World Application

Healthcare (AI diagnostics): A hospital deploying an AI-based cancer diagnostic assistant must reconcile speed, accuracy, patient safety, and regulatory compliance. Through RMMi, elicitation captures the perspectives of radiologists, patients, and regulators. Documentation organizes these into precise categories, distinguishing diagnostic functionalities from quality requirements (e.g., subsecond response time, 99% availability) and constraints (medical device certification, data protection). Validation cross-checks model predictions against physician diagnoses with measurable acceptance criteria and defined error tolerances. Management versions models/datasets, keeps end-to-end traceability from clinical needs to validation protocols, and controls change. Mapped to maturity, this scenario typically progresses from Level 3 to Level 4: from standardized reviews and complete traceability (L3) to predictive control with drift thresholds, review escape rate targets, and validation lead-time SLAs, all supported by dashboards and automated alerts (L4).

Banking (credit scoring): A bank automating loan decisions must balance efficiency, fairness, and regulatory transparency. RMMi ensures that elicitation captures customer expectations for fairness, regulatory demands for explainability, and business objectives for decision latency and scalability. Documentation goes beyond “compute a score” to include explainability obligations, service level objectives, and non-discrimination constraints. Validation tests not only accuracy but also cohort consistency and the ability to provide justifications for adverse decisions. Management maintains version control of models and scoring rules, links changes to business/regulatory updates, and maintains traceability. Mapped to maturity, the bank exhibits Level 3 when policies/templates/workflows are standardized and traceability is complete; it reaches Level 4 when fairness and stability metrics are tracked against control limits with dashboards and predefined corrective actions.

Maturity Levels

From its early drafts, the RMMi experimented with different approaches to structuring maturity. During the first three years of development, the model evolved through versions with three and then four levels. This experimentation was useful to explore alternative ways of describing organizational progress.

However, the decision was ultimately made to adopt a five-level maturity structure, consistent with established models such as CMMI and TMMi. The rationale was clear: most organizations, consultants, and auditors are already familiar with this format, which makes it easier to position the RMMi within the broader ecosystem of maturity models. By aligning with a structure that is already widely accepted, the RMMi maximizes accessibility and comparability, while keeping its unique focus on requirements engineering.

The five levels follow the familiar progression:

• Level 1 – Basic: practices are informal, inconsistent, and largely dependent on individuals.
• Level 2 – Managed: practices are repeatable, with local standards and basic governance.
• Level 3 – Defined: requirements practices are standardized and documented at the organizational level.
• Level 4 – Predictable: quantitative metrics and KPIs are applied to manage and predict performance.
• Level 5 – Optimizing: continuous improvement is embedded, with feedback loops and innovation driving evolution.

This staged approach gives organizations a clear roadmap. It shows not only where they are but also how to improve, while preserving comparability with other maturity frameworks. The distinction of the RMMi lies in applying this proven maturity model logic to the domain of requirements engineering, with practices, criteria, and indicators tailored to the characteristics of elicitation, documentation, validation, and management.

Assessing Maturity with RMMi

Organizations applying the RMMi are not left with abstract levels alone. Each level is supported by evaluation criteria that allow the organization to determine its current position. These criteria cover a combination of methods, practices, tools, and measurable indicators.

• At Level 1 (Basic), the absence of standardized practices is the primary indicator.
• At Level 2 (Managed), repeatable techniques such as stakeholder interviews, basic templates, and local guidelinesappear.
• At Level 3 (Defined), indicators include standardized templates across projects, formal reviews, and tool support for (at least) traceability.
• At Level 4 (Predictable), quantitative KPIs such as requirements coverage, defect density, and validation lead time are used to monitor and manage performance.
• At Level 5 (Optimizing), continuous improvement is evidenced by systematic lessons learned, feedback loops, and innovation such as AI-assisted requirement analysis.

The RMMi Guide describes this global evaluation approach and the logic of indicators. More detailed criteria, including checklists, metrics, and practices for each level, will be provided in the RMMi Syllabus and supporting training material. This ensures consistency while keeping the guide accessible as a framework reference.

Conclusion

With the release of RMMi 1.0, requirements engineering now has a dedicated maturity model. By grounding its practices in four well-defined domains aligned with the IREB CPRE syllabi and by structuring improvement along a common five-level maturity path, RMMi offers a framework tailored to the realities of modern systems. It enables organizations to explicitly address contemporary concerns - such as auditability, sustainability, and ethical responsibility - through requirements rather than as afterthoughts.

Its ambition is not only to guide organizations in assessing and improving their requirements practices but also to embed trust as a measurable quality. The road ahead for RMMi includes the development of training material and certification programs, assessment tools, and continued refinement through practitioner feedback.
Ultimately, RMMi 1.0 is more than a model. It is a commitment to professionalizing requirements engineering and ensuring that digital systems are not only built to function but built to be trusted.

RMMi® is a registered mark. © 2025 Cyrille Babin – All Rights Reserved.

Appendix — Editorial Additions

Assessing Maturity with RMMi (practical guidance)

RMMi can be actioned immediately by combining its four domains × five levels with widely accepted sources for practices, indicators, and improvement paths. The brief guidance below helps readers get started now; the full indicator catalogs and rubrics will be provided in the upcoming RMMi Syllabus.

Mini‑mapping: domains → typical sources & evidence

Examples of evidence for Level 3 vs Level 4 (no thresholds)

• Traceability coverage (bi‑directional links to upstream/downstream).
• Review compliance (% of requirements reviewed against a checklist).
• Validation lead time (spec → acceptance criteria → tested).
• Change request cycle time (submit → CAB decision).
• Requirements‑related defect density (pre‑UAT or pre‑release).
• Automated consistency checks (missing links/orphans/conflicts).
• Predictive dashboards (trends + predefined corrective actions).

Standards & further reading

• ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering.
• ISO 15939:2017 — Systems and software engineering — Measurement process.
• IEEE 828:2012 — Configuration management in systems and software engineering.
• ISO/IEC 20000-1:2018 — IT service management — Service management system requirements (change enablement context).
• ITIL® 4 — Change Enablement and Continual Improvement practices.
• INCOSE Systems Engineering Handbook, v5 — Traceability, V&V integration.
• PMI, PMBOK® Guide (7th ed.) — Performance domains, governance, measurement.
• ISO/IEC 33001:2015 and ISO/IEC 33014:2013 — Process assessment & improvement guidance.
• ISO/IEC 12207:2017 — Software life cycle processes.
• IREB CPRE Syllabi (Foundation & Advanced RM) — Practices, techniques, indicators alignment.

Authorship & IP notice

RMMi® (Requirements Maturity Model integration) Version 1.0 (2025) is authored solely and exclusively by Cyrille Babin. Early exploratory discussions (2019–2022) with peers informed the context, but the design, structure (4 domains × 5 levels), transversal dimensions, practices, indicators, and the model’s documentation were conceived and written by Cyrille Babin between 2023 and 2025.

Trademark / Ownership: RMMi® is a registered trademark of Cyrille Babin — INPI registration no. 5141365 (filed 2025-04-23, registered 2025-08-09), Nice class 42 (software engineering / consulting services). © 2025 Cyrille Babin — All Rights Reserved.