Requirements Modeling uses graphical models, primarily from UML and SysML, to make complex requirements understandable and verifiable. This is accomplished by highlighting what matters and hiding unnecessary detail. Essentially, requirements modeling is the systematic abstraction of reality, aiming to reduce complexity.
Requirements Modeling Views According to IREB
In order to fully specify a system, it must be examined from multiple angles. According to the CPRE Foundation Level, the International Requirements Engineering Board (IREB) therefore recommends analyzing requirements from three core perspectives: the static-structural view, the behavioral view, and the functional view.
However, modern systems are becoming increasingly complex. To stay in control, teams benefit from a more granular perspective. The CPRE Advanced Level Requirements Modeling syllabus proposes more detailed requirement views and suitable models to describe them. Most of these models originate from UML/SysML. Below is a high-level overview of the requirement views.
The Context View
The context view marks the starting point of every modeling effort. It focuses on understanding the system environment, including external systems, roles/people, and relevant properties, and helps identify interfaces to the outside world. Key question: Who and what interacts with the system?
Typical diagram types include context diagram, UML Use Case Diagrams, and SysML Block diagrams.
The Information Structure View
This view focuses on the static, structural aspects of system functionality, specifically the data structures to be processed.
Typical diagram types include Class diagram and specialized entity-relationship models.
The Quality View
This view captures quality attribute requirements related to the system or its components. In practice, quality requirements are usually documented in text form. Model-based approaches have not become widely established in this area.
The Constraints View
This view covers requirements that act as boundary conditions (external constraints) on the system or development process. These include organizational, regulatory, and technical constraints. Most constraints are initially documented in text form. However, organizational and technical constraints can also be modeled using diagram types, such as Class diagrams or Component diagrams.
The Dynamic View
This view addresses requirements related to the dynamic aspects of system functionality. Because system behavior can be highly complex, the dynamic view is divided into subviews:
- Use Case View: Describes high-level user functions and their relationships to actors in the system context (using use case diagrams).
- Data Flow View: Specifies functions visible at system interfaces and their data dependencies, both among themselves and with contextual actors (often using Activity diagrams with Object Flow)
- Â Control Flow View: describes processes/actions visible at system interfaces and their execution logic (e.g., sequential, alternative, or concurrent), typically using activity diagrams.
- State-oriented View: models the state space and state transitions (event- or time-driven) at the system interface, usually with State diagrams)
- Szenario View: describes interaction sequences between actors and the system that enable actors to achieve goals or gain value. Scenarios concretize use cases (often using sequence diagrams).
CPRE Advanced Level – Become an Expert
Requirements modeling is a specialized discipline within requirements engineering. The IREB offers the CPRE Advanced Level Requirements Modeling certification for professionals. At this level, participants learn to apply models strategically to improve quality and eliminate misinterpretations.
Your Path to Certification
microTOOL is an accredited training provider as well as a tool vendor. Join our CPRE Advanced Level Requirements Modeling Training to master the IREB syllabus theory and practical application.
The biggest hurdle in requirements modeling is maintaining consistency across multiple views. In traditional drawing tools, diagrams are isolated graphics. Any change must be manually propagated across documents. Without a strong link between models and textual requirements, teams risk creating a “document graveyard” full of inconsistencies.
With objectiF RPM, Requirements Modeling becomes a living system. The software supports standard UML and SysML and it stores models, elements, relationships, and associated texts without redundancy in a central repository. What this means for you:
- Single Source of Truth: rename an element once, and updates appear everywhere in real time. The result is a consistent requirements model.
- Traceability: Relationships remain transparent and up to date (e.g., between use cases and requirements, requirements and refinements, requirements and test cases, or requirements and the system elements that fulfill them).
- Version Confidence: Secure versioning captures change history and enables precise differencing.
- Automates Documentation: Specifications and requirements documents are generated directly from the repository, ensuring they are always consistent and current.
CPRE Certification According to IREB
Our 3-day CPRE seminars for Foundation and Advanced Level integrate methodological expertise with real-world application.
FAQ
Does the model replace the text specification?
In most cases, models and text complement each other. Models provide structure and logic, while natural language provides detail and explanation.
Is modeling more time-consuming than a pure text specification?
Of course, there is an initial investment, though it remains low with tools like objectiF RPM. However, the payoff comes quickly. As specifications grow in scope, models significantly improve navigation and clarity. These models are powerful communication tools that expose logic flaws and gaps which would easily remain hidden in text-heavy documents. In short, the investment pays for itself.
Which notation matters most?
It depends on your objective. As a general rule, start with the context view and use context diagrams to establish the system boundaries. For data-intensive systems, the information structure view is usually the next best step. For process-driven systems (e.g., automation), the data flow, control flow, and state-oriented views are critical. This is where activity and state diagrams are most valuable. If your primary focus is stakeholder communication, use case diagrams are often the most effective choice. The CPRE Advanced Level teaches you how to select the right modeling approach for each situation.
Want to Know More?
Explore more knowledge base articles online or download one of our whitepapers.
What is Requirements Engineering?
Requirements engineering (RE) involves eliciting, documenting, validating, and managing requirements. Learn how professional RE can safeguard your projects.
What is CPRE?
The CPRE (Certified Professional for Requirements Engineering) is the international standard for RE certification. Find information on the program’s content, levels, and exams.
objectiF RM – Whitepaper
Requirements Engineering for Software and Systems. Read about benefits and options of objectiF RM in this whitepaper.
objectiF RPM – Whitepaper
Increase your business agility. Get to know objectiF RPM in this whitepaper. From the needs of stakeholders to IT systems for successful business.