Requirements engineering visualization

A brief history of requirements modeling language

Nicolas Delattre
UMP, [Link]@[Link]

ABSTRACT
Requirements Engineering Visualization provides many
tools to better understand and identify requirements. The
Requirements Modeling Language is divided into four
parts: Objectives models, People models, Systems models
and Data models. This term paper presents fourteen
different models. It also allows to see the presentation of
different results to satisfy all the stakeholders.

INTRODUCTION Figure 1: An example of a long list of requirements

Requirements engineering visualization is one of the best These requirements can be created via interviews and
ways to identify requirements engineering and software working sessions. It is nearly impossible to read a lot of
requirements. They help the analyst to ensure that all requirements and come out with confidence that the
stakeholders (experts, executives, customers, users, technical requirements are complete. When you have thousands of
teams…) understand the proposed solution. Requirements requirements, it can be difficult to determine which
engineering visualization creates a picture of the solution that requirements should be removed without somehow
helps stakeholders understand what the solution should and associating those requirements with values.
should not be. Despite this, many business analysts or Agile approaches such as Scrum have product backlogs, user
managers still create non-visual requirements using, for stories, and acceptance criteria. Many Scrum evangelists say
example, documents listing thousands of lines. These difficult that the product backlog should be a united list of stories,
and incomprehensible documents are boring to review and which is no better than a long list of requirements.
extremely difficult to analyze for missing requirements. Requirements models organize and present a large amount of
This Term paper describes a simple but comprehensive information and helps identify missing information. Most
language of visual models for software requirements called importantly, templates provide visual groupings that allow
RML (Requirements Modeling Language). Many RMLs are you to quickly analyze large amounts of information. It is
presented in an introductory way, without going into too difficult to identify gaps in a requirements document
much detail. A deeper analysis is recommended to use the containing thousands of "the system shall" statements, but
different RMLs presented. templates can help.
RML models are designed with the simplest possible syntax
while allowing the model to provide the necessary
INTRODUCTION TO RML
information.
RML (Requirements Modeling Language) is a language
designed specifically to visually model requirements to make
them easier to consume by executive, business and technical MODEL CATEGORIZATION
stakeholders. RML is not an academic modeling language. The RML models are organized into four categories:
However, today Requirements engineering visualization is • Objectives models
not well known and used. Traditional software requirements • People models
practice unfortunately support the use of thousands of • Systems models
“system shall” requirements similar to the list shown in • Data models
Figure 1. Commonly referred to as OPSD.
The RML classification, represented by the diagram in
Figure 2, offers several complete model tools for the analysis
of the solution to be built

1
12/2022
 OBJECTIVES MODELS
Objectives models describe the business value of the system.
I. Business Objectives Model
The core of each project is its value to the user or the
company. Without focusing on business goals to drive scope,
projects can become overloaded with irrelevant features that
don't contribute to the project's core goals. Business
Objectives Model allows stakeholders to determine the value
of the project and then use that value on a daily basis to meet
requirements.
Figure 2: The OPSD classification of RML models Business Objectives Model Template
Objectives, People, Systems, and Data models (OPSD) The business objectives template consists of boxes that
contain a business problem, a business objective or a product
The RML organizational structure is based on these concept with certain characteristics and arrows between the
traditional model domains, grouping the models by boxes to show how they relate (Figure 3).
objectives, people, systems, and data (OPSD). These areas
represent four categories of information that must be
considered in order to thoroughly analyze the solution (Table
1).
Table 1: RML Model Categorization

Description Models
Objectives Describe the • Business
business value of Objectives
the system and help Model
to prioritize • Objective
Chain Figure 3: An example of multiple business objectives for one
features.
• Feature Tree business problem
• Requirements
Mapping The best moment to create a Business Objectives Model
Matrix should be early in the project. It should be used throughout
People Describe who is the project lifecycle so that stakeholders can focus on the
using the system, • Org Chart value of the solution.
along with their • Process Flow II. Objective Chain
business processes • Use Case
and goals The Objective Chain is an RML objectives model that
Systems Describe existing • Ecosystem measurably links features to business objectives. Because
systems, what the Map multiple features are often associated with each business goal,
user interface looks • System Flow and each feature can address multiple business goals, it is
like, how the • User helpful to have a model for determining the relative value of
systems interact and Interface each feature.
Flow
how they behave.
• System Objective Chain Template
Interface
Objective Chains are described in a hierarchy of boxes by
Table
using a tree structure, as shown in Figure 4. The box in the
Data Describe the
upper left is a business objective, and the boxes placed in the
relationships
• Business lower right are features. The branches in between the two
between enterprise
Data include a series of boxes containing objective factors and
data objects from
Diagram objective equations.
the user's
• Data Flow
perspective, the data Diagram
life cycle, and how • State
reports can use this Diagram
data to make
decisions.

2
12/2022
 Figure 6: A Requirements Mapping Matrix template

PEOPLE MODELS
People models show who uses the system and how.
Figure 4: The Objective Chain template V. Organization Chart
III. Feature Tree The organization chart is an RML people model that shows
the structure in which people or roles in an organization work.
The Feature Tree is an RML objectives model that shows the It is used to identify all users and stakeholders who can
organization of the features in logical groups, showing the full contribute to the solution. The organization chart ensures that
scope of a solution on a single page. you identify all stakeholders.
The structure of Feature Trees is based on fishbone diagrams, It is used by many organizations, so a lot of people are
which is used to organize information into logical groupings probably familiar with it.
based on relationships. Fishbone diagram is typically used to
model cause-and-effect relationships, but Feature Trees Organization Chart Template
specifically organize the features of a solution. An organization chart is a collection of boxes connected by
Feature Tree Template lines with a hierarchical structure. Each box contains the
name of an organizational department, role or person, and the
Feature Trees are models that visually show the relationships lines between the boxes indicate the reporting relationships
between features. The features are simply words on the tree, within the organization, as shown in Figure 7.
and the lines link related features together.

Figure 7: The organization chart template

Figure 5: The complete Feature Tree template
Some colors can be used to accentuate organization chart to
When all the characteristics of the template are fulfilled, as in provide additional information. Color can be used to
Figure 5, the tree looks like the bones of a fish, thus the name distinguish between different groups of people who have
fishbone. different influence on the project.
IV. Requirements Mapping Matrix VI. Process Flow
The Requirements Mapping Matrix (RMM) is an RML The Process Flow is an RML people model that describes a
objectives model that maps information in models to business process that will be executed by people. Process
requirements and business rules. An RMM can contain Flows show the activities to be performed and the different
multiple levels of mappings. decisions that users make to achieve a desired result. Process
Flows can help you understand complex information by
RMM Template
depicting processes graphically. This way, you can quickly
RMMs are created in a matrix. There are at least five columns: see how the steps are related.
the first three columns contain some process flow steps, and
Process Flow Template
the fourth contains unique requirement identifiers, and the
fifth contains the requirements. Each row of the matrix Process Flows have process steps connected by arrows that
contains a correspondence between a process step and a indicate all possible paths the process can take. Each Process
requirement. Flow has a clearly defined starting and ending point.
The template for a standard RMM is shown in Figure 6. In The elements of Process Flows in RML are shown in Figure
this case, a feature column was added and two business rule 8. The types of symbols and the number of alternative paths
columns were added. vary by process.

3
12/2022
Figure 8: A Process Flow template

VII. Use Case

The use case is an RML people model that describes the
interactions between the users and a system. The value of a
use case is to help you visualize how a user would perform a
Figure 10: The Ecosystem Map template
task and identify the functionality needed to support each
step.
IX. System Flow
Use Case Template
The system flow is an RML systems model that describes the
Use Cases are structured text presented in a template table that activities that systems execute. It shows system activities,
has prespecified fields, as shown in Figure 9. The structure sequence, and system logic. System helps stakeholders
helps ensure that you don’t forget any details when you are understand complex system interactions in a visual way. In
creating a Use Case and helps the Use Case reader jump to order to easily see the interactions between systems, as well
relevant information as needed. as the complex links within systems.
System Flow Template
System Flow model following list highlights the key
differences between system flow elements and process flow
elements:
• Steps and decisions are primarily actions taken by
the system.
• References to inbound, outbound, and other
processes generally refer to other system flows, but
can also refer to process flows.
The full template for System Flows looks like a Process Flow
template, as you can see in Figure 11.
Figure 9: The Use Case template

SYSTEMS MODELS
System models describe the systems themselves, what they
look like, and how they interact with users and other systems.
VIII. Ecosystem Map
The Ecosystem Map is an RML systems model that shows
which systems interact with each other and the nature of the
relationship. The Ecosystem Map shows all systems in the
solution ecosystem, which ensures that you are analyzing all
systems.
Ecosystem Map Template
An Ecosystem Map is a simple diagram that requires the use Figure 11: The System Flow template
of only two types of symbols: boxes representing systems and
lines representing interfaces between systems (Figure 10). X. User Interface Flow
The User Interface Flow (UI Flow) is an RML systems model
which shows how the user will navigate in the user interface.
A UI Flow contains the screens and the navigation paths
between them.
UI Flow Template

4
12/2022
A UI Flow template must at a minimum include screens and
the arrows that represent the navigation path between the
screens. Each screen should have at least one arrow coming
into it and at least one arrow leaving it, otherwise there would
be no way to access or leave that screen (Figure 12).

Figure 14: The business data diagram template

XIII. Data Flow Diagram

The Data Flow Diagram (DFD) is an RML data model that
provides a graphical representation of the flow of information
through a solution. It focuses on how data is transformed
Figure 12: A UI Flow template when it is manipulated or used in processes.

XI. System Interface Table DFD Template

The System Interface Table is an RML systems model. A The data flow lines must come from data stores or entities
System Interface Table details the communication between through processes, because external entities and data stores
two systems. cannot pass data directly to each other. The diagram in Figure
It shows the details of the interaction between two systems 15 is a DFD template.
from a business stakeholder’s point of view rather than from
a technical point of view.
System Interface Table Template
A System Interface Table contains data about the
requirements of the interface between two systems and does
not include the exact nature of the technical protocol flow.
The template is shown in Figure 13 and includes descriptions
of each field.
Figure 15: A DFD Template

XIV. State Diagram

The State Diagram is an RML data model that shows the
transitions between states of objects in a solution. State
Diagrams show the life cycle of an object’s states, including
any events that cause state changes.
State Diagram Template
A State Diagram contains circles, transition arrows between
Figure 13: The System Interface Table template states, and labels on the transitions.
Figure 16 shows a State Diagram template, but you can have
DATA MODELS as many states as you need.

Data models focus on the information in the system and how

it is modified.
XII. Business Data Diagram
The business data diagram is an RML data model that shows
the relationships between business data objects.
Business data diagram Template
A business data diagram template in its simplest form Figure 16: The State Diagram template
contains boxes, lines, and labels to designate the nature of the
CONCLUSION
relationships. Figure 14 shows the business data diagram
template. There are many different templates to identify requirements
engineering and software requirements. Requirements

5
12/2022
Modeling Language is sometimes used, but not always as it John R Cooper, Seok-Won Lee, Robin A. Gandhi, & Orlena
should be. I think that using RML more often can make it Gotel. (2009). Requirements Engineering
easier to start and finish a software project by satisfying the Visualization: A Survey on the State-of-the-Art.
requirements engineering. Malik, A. N. (2009). Enterprise Business Motivation Model.
Retrieved from motivationmodel:
REFERENCES [Link]
Zahra Shakeri Hossein Abad, Guenther Ruhe, & Mohammad
Noaeen. (2016). Requirements Engineering
Beatty, J., & Chen, A. (2009). Visual Models for Software Visualization: A Systematic Literature Review.
Requirements. Microsoft Press. Retrieved from researchgate:
Burch, M. (2020). The Importance of Requirements [Link]
Engineering for Teaching Large Visualization 3_Requirements_Engineering_Visualization_A_Sy
Courses. stematic_Literature_Review
Data Modeling in System Analysis. (2010). Retrieved from
umsl:
[Link] AUTHOR INFORMATION
pers/Gao/
Group, T. S. (2009). CHAOS Summary 2009. West Nicolas Delattre, French Student at Université Savoie Mont
Yarmouth. Blanc and UPM (as Erasmus student).

6
12/2022