Model-Based Requirements Engineering: Architecting

for System Requirements with Stakeholders in Mind

Yaniv Mordecai Dov Dori
Faculty of Industrial Engineering & Management Faculty of Industrial Engineering & Management
Technion – Israel Institute of Technology Technion – Israel Institute of Technology
Haifa, Israel Haifa, Israel
yanivmor@technion.ac.il dori@ie.technion.ac.il

Abstract— Specifying system requirements (SysReqs) is a requests, expectations, preferences, goals, objectives,
critical activity in complex systems development. The SysReqs and constraints, intentions, guidelines, desires, and aspirations,
emerging architecture are constructed through gradual and collectively called stakeholder requirements, must be expressed.
iterative transition from the problem domain and operational The INCOSE Systems Engineering Handbook discusses the
stakeholder requirements to the conceptual solution domain. They importance of stakeholder requirement (SHR) understanding,
later constitute the basis for functional requirements elaborating, elicitation, and analysis as a key success factor [1].
concept formation, technology selection, function-to-form
allocation, and asset utilization. Only rarely can stakeholder While SHRs are the starting point for most system
requirements (SHRs) readily translate to SysReqs. Systems development programs, they are often deficient due to
engineers must therefore elicit, analyze, and evolve the SysReqs, stakeholders’ lack of knowledge in defining requirements.
as these will radically affect the system’s performance, robustness, Systems engineers should therefore work closely with the
endurance, and appeal. Model-Based Systems Engineering stakeholders to crystalize and clarify their needs and to try to
(MBSE) provides a framework for effective and consistent systems agree on coherent, realistic goals. Stakeholders often have
engineering and architecting. MBSE relies on modeling languages, insufficient knowledge in the relevant technology, but rather
such as Object-Process Methodology (OPM). OPM is a holistic than issue a request for information (RFI) first, all too often they
MBSE paradigm and language for complex systems and processes, issue a request for proposals (RFP), which is equivalent to a
standardized as ISO 19450, which relies on the principle of
tender. Stakeholders often construct a mental model of the
minimal universal ontology. In this paper, we propose a model-
solution, to which they become fixated, even if it is not adequate,
based requirement engineering (MBRE) approach to facilitate the
transition from SHRs to SysReqs, and from SysReqs to system
proper, or close to being optimal. In some cases, stakeholders
architecture specification. We demonstrate the applicability of this order commercial off-the-shelf (COTS) products, indicating that
framework in architecting a robotic baggage loading system for a they have reached a decision to apply a readily-available
leading international airport. solution for their problem, without validating the solution first.
Stakeholder requirements documents (SHRDs) explain the
Keywords—Model-Based Systems Engineering; Object-Process
problem or environmental context, currently available solution,
Methodology; Requirements Engineering; Systems Architecting;
gaps and issues with the current solution, and requirements and
expectations for a future solution. Some stakeholders focus on
ACRONYMS the current situation and problem without specifying any goals
CfP Call for Proposals and objectives, while others provide no problem domain context
COTS Commercial Off-The-Shelf and merely specify their requirements from the contractor.
ISO International Organization for Standardization
MBRE Model-Based Requirements Engineering The more sophisticated stakeholders are those who request
MBSE Model-Based Systems Engineering solutions to problems without specifying the solution design,
OPD Object-Process Diagram and avoid being prematurely committed to a specific solution,
OPL Object-Process Language even if they might have considered it. Such stakeholders are
OPM Object-Process Methodology
aware of the need to acquire enough information and knowledge
RFI Request for Information
RFP Request for Proposal
before they can evaluate the merit of proposals to solve the
SHRD Stakeholder Requirement Document stated problem in technical and business terms. They then
SOW Statement of Work negotiate the project’s scope to optimize cost, benefit, and risk.
SHR Stakeholder Requirement
SRR System Requirement Review
Clean separation between the problem domain and the
SysML Systems Modeling Language solution domain is ideal, but real-world problems are seldom
SysReq System Requirement completely solution-independent. Rather, currently used or
UML Unified Modeling Language binding technology, infrastructure, regulations, or contractual
commitments often dictate a solution direction or anchor the
I. INTRODUCTION problem in the solution domain. In such cases, solving the
Every system begins with an idea or vision in someone’s problem involves consideration of possible ways to integrate
mind, a concept for solving some problem. For the idea or future solutions into the current one, replace the existing system,
concept to become a system, a set of needs, assumptions, or adjust it to solve the problem at hand. SHRs must therefore
be prudent and open to a variety of solution approaches.
Sometimes, several stakeholders share the risk or cost by
aiming for a common solution to a set of similar or related
problems, further complicating the quest. In such cases, the
SHRs are loosely coordinated, and the needs, preferences, and
goals are often contradictory. The major partners usually have
the prerogative to secure their interests first, while the minor
partners may have to compromise. Consequently, SHRs become
unbinding, fuzzy, and cost- or risk-dependent, making them an
inadequate basis for engineering the system. The appropriate
identification of stakeholders is critical for effective elicitation
of a representative set of SHRs, but this early system lifecycle
phase has received little attention in the literature and in
requirements engineering standards [2].
Given this state of affairs, it becomes obvious that a set of
system requirements (SysReqs) must be elicited based on the
SHRs [1], [3], [4]. Yet, there is little guidance on developing
SysReqs from SHRs. That guidance focuses mostly on holding
discussions with the customer and trying to write the
requirements clearly [4].
SysReqs must correspond to the contractor’s understanding
of what is requested and ability to deliver a good or at least
satisfactory solution. Such a solution can be based on a
commercial product, a demonstrated technology, a solution to a
similar problem, protected intellectual property, or the promise
and belief that the contractor will be able to deliver. It is
therefore critical to hold a system requirements review (SRR)
with all stakeholders, and obtain approval for the project scope.
The requirements engineering paradigm has been gradually
but steadily shifting from being natural language text-based to
being model-based [5]–[10]. Model-based requirements are
more formal, consistent, and visual than textual ones. Most
importantly, they are amenable to checking, simulation, and
verification. Yet, stakeholders still specify their requirements
mostly in textual documents, often negligent of good
requirement authoring practices. Therefore, it is difficult to trace
SysReqs that systems engineering teams elicit and build to
SHRs. In addition, there is a need to map visual models to textual
specifications and to cover the problem domain and the
conceptual solution domain in a single model. This has remained
a challenge even in model-driven approaches.
In this paper, we propose to utilize Object Process
Methodology, OPM [11], [12] as a model-based requirements
elicitation framework. OPM can provide the basis for model-
based documentation of SHRs and for the gradual transition
towards the model-based specification of SysReqs. OPM can
serve firstly to define the generic requirements elicitation
process, thus adding formality and consistency to the definition
of the process itself. Secondly, OPM can represent a system
model that covers the SHRs, SysReqs, and system architecture,
with adequate mapping between the SHR set and the SysReq set,
and between the SysReq set and architectural features – form
and function.
The evolving system model is the basis for the requirements
engineering process. OPM’s bimodal graphical-textual
representation allows for generating textual specifications of
SHR coverage by SysReqs. This approach can be especially
beneficial when multiple stakeholders are involved, as it allows
for exploitation, reuse, or gradual adjustment and extension of
SysReqs. The OPM model-based approach allows continuous
evolution of SHRs and SysReqs, as the requirements in modern
systems never cease to change throughout the project, a major
departure from the traditional Vee Model approach [13].
The rest of this paper is organized as follows: In Section II
we review previous related work, mostly in the area of model-
based requirements engineering (MBRE). Section III provides
an overview of the framework for OPM-based requirements
documentation, elicitation, and elaboration, which facilitate the
transition from SHRs to SysReqs. In Section IV, we exemplify
the implementation of the proposed approach via the design and
development of a robotic baggage loading system for a top-tier
international airport. In section V we discuss our main results,
benefits, conclusions, and prospects for future research.
II. RELATED WORK
According to a recent survey of international standards for
requirements engineering in complex systems [14], seven
different relevant ISO, IEC, and IEEE standards exist. Some of
these standards are partially aligned, raising questions on the
need for so many standards. The widely-used ISO/IEC/IEEE-
15288 standard for systems and software engineering – system
life cycle processes [15], sometimes referred to as the “bible” of
systems engineering, holds most of the knowledge, and the other
standards are aligned with it. ISO/IEC/IEEE 29148 is dedicated
specifically to requirements engineering.
In a survey of methodologies for requirements elicitation (or
requirements development), we found various methods for
transforming SHRs, which are, for the most part, needs and
expectations, to SysReqs, which are structured and actionable
specifications [4]. The MBSE paradigm was found to be a
promising approach for model-based requirements engineering
(MBRE), with use case modeling, Object-Process Methodology,
and requirements graphs. Use case models were found helpful
in ensuring the derivation of requirements based on usage and
functionality, and the coverage of needed functionality by
adequate specifications. Surprisingly, the SysML requirements
diagram was not mentioned in [4] as a method for system
requirements elicitation, but it was applied for user requirements
elicitation in [10] and [16].
Another model-based approach is the Approach for Context-
based Requirements Engineering (ACRE) [17], which was
found suitable for systems and systems-of-systems (SoS).
ACRE has a requirements ontology, which is the basis for six
views: source element view, requirement description view, rule
set definition view, requirement context view, validation view,
and traceability view. The COMPASS approach for MBRE [8]
wraps ACRE notation with a framework of view-defining and
view-generating. The contribution of view-multiplicity and
-redundancy to requirements elicitation is not completely clear.
MBRE has not yet reached a degree of acceptability like
MBSE [18]. Difficulties with assimilation and domain expert
cooperation, as well as challenges with non-functional
requirements may explain the slow adoption. However, the use
of various MBRE techniques was reportedly beneficial for
visual communication, customer confidence, knowledge
transfer, new team-member training, and holistic system information on or around pivotal elements through dedicated
understanding. An interesting notion is that visual modeling views. Every model fact needs to be defined at least once in
paradigms with multiple diagram notations, such as UML and some OPD in order for it to be true for the entire model. A model
SysML, may divert the focus towards drawing diagrams rather fact can appear in any one of the OPDs in the OPD set specifying
than building coherent and reflective system design and the model. Any model fact can be replicated in any OPD, but it
specification models. In addition, the lack of dedicated notation applies to any OPD even if it is not expressed in it explicitly.
for requirements, goals, constraints, risks, etc. makes them at
most implicit in the model, and usually lost in the modeling
process: the model describes “what” or “how” but not “why”.
The Unified Requirements Modeling Language (URML) [6]
was intended to resolve many of the issues in UML-based RE.
Looking forward, the Next Generation Requirements
Engineering (NextGenRE) project, sponsored by the European Fig. 1. OPM building blocks: Object, Process, State, essence (shade),
Space Agency, provides a model-driven approach to affiliation (contour)
requirements engineering in space missions, which can also be
applied to complex systems in general [19]. The NextGenRE
approach tackles the challenge of integrating requirements with
existing knowledge, solutions and designs by using a semantic
wiki engine for (1) transforming requirements engineering into
a knowledge management problem, and (2) linking
requirements with design, i.e., problems with solutions.
Based on the reviewed literature, we conclude that two
primary practices must govern requirements engineering. The
first is requirements engineering process standardization, with
special focus on “how” in addition to “what”. The second
practice is exercising MBRE and integrating it with MBSE. The
first practice relates to the RE process, while the second one Fig. 2. OPM Structural Relations
relates to RE outcomes or deliverables. Therefore, a framework
capable of integrating both practices will be highly beneficial. In
this work, we apply OPM to achieve this goal.
III. OPM-BASED REQUIREMENTS ELICITATION
A. Object-Process Methodology (OPM)
The ISO-standardized Object-Process Methodology, OPM
(ISO-19450), is a holistic model-based systems engineering
(MBSE) paradigm for complex systems and processes, which
evolved over the last three decades [11], [12], [20]. OPM Fig. 3. OPM Procedural Relations
consists of a compact set of graphical-textual elements – Things
and Links. Process (ellipse), and Object (rectangle) are Things.
Objects can be stateful, i.e., have states. Process, Object and
state (rountangle), with various combinations of the inherent
attributes of Essence and Affiliation, are shown in Fig. 1.
Processes and objects may consist of lower-level processes and Object In-zooming: Object A Process In-zooming: process A
objects. Links express various relations between these things. consists of object B and exhibits consists of process B and exhibits
Structural links, shown in Fig. 2, support the modeling of static process C object C
system aspects. Procedural links, shown in Fig. 3, express
Fig. 4. Object and Process In-Zooming in OPM
procedural relations, control, and causalities.
OPM copes with complexity via detail-level decomposition, OPM is bimodal: in addition to the graphical representation,
as opposed to UML’s and SysML’s aspect-based decomposition OPM also has a formal textual representation, which allows for
into structure, behavior, state transitions, activities, time flow, automatically generating coherent textual specifications of
etc. The hierarchically-organized OPDs are derived from each OPDs in Object-Process Language, OPL – a subset of natural
other using several refinement-abstraction mechanisms: English [12], [21] that is based on context-free grammar.
(i) unfolding and folding of structural hierarchies of things,
OPM models can be constructed with the freely available
(ii) zooming into or out of the inner details of things (as shown
OPCAT1 software tool [22]. OPCAT provides a graphical user
in Fig. 4), (iii) state expressing (showing) and suppressing
interface (GUI) for analysts to create, manage, and share their
(hiding), and (iv) view creating – expressing additional
models. It supports most OPM concepts, and immediately

1
Downloadable for free from http://esml.iem.technion.ac.il/
validates model edits according to OPM syntax and rules. and generate another SRR Approval (as the red token along the
OPCAT also automatically generates OPL sentences in response result link indicates). Two System Versions were generated by
to graphical model edits, and provides whole-model or diagram- the Implementation process, which is about to be triggered again
level textual OPL specifications. OPCAT provides a built-in by the third SRR Approval.
qualitative simulation engine, which supports model validation,
verification, and testing, and is especially useful in visualizing
the execution of complex interactions. A screenshot of the
OPCAT GUI is shown in Fig. 5. OPCAT is about to be
succeeded by a cloud-based modeling studio called OPCloud.
A previous OPM model of the system development process
[23] also covered the Requirement Specifying phase, and
distinguished between problem defining and requirement
defining (but not between SHRs and SysReqs). Research on the
use of OPM for requirements engineering [24], [25] found OPM
to provide significant value in the requirements authoring phase,
i.e., in ensuring the formality and consistency of the
requirements. Assisting with stakeholder involvement is
specified as one of the roles of OPM in ISO-19450 [20]. OPM
was also recently listed as a state-of-the-art MBSE methodology
that can support MBRE [4].
B. An OPM Model of the Requirements Engineering Process
The systems engineering process and its subprocess of
requirements engineering can be analyzed with systems
thinking, i.e., referred to as a system in its own right. The first
use of OPM that we make in this study (see Fig. 5) is for
describing the Requirements Engineering process.
The analysis is based on the understanding that the
Stakeholder generates Stakeholder Requirements exogenously,
based on the perception of the Maturity of the Stakeholder
Fig. 5. OPCAT Screenshot, showing the Requirements Engineering system
Requirements Set. When the Maturity is sufficient, a Systems model, focusing on the in-zoomed Requirements Engineering process view.
Requirements Eliciting phase can take place, building or
refining the System Requirements Set, while taking care of the
Stakeholder Requirements Set Coverage. When Convergence
of the System Requirements Set is achieved, and when the
Coverage is satisfactory, a System Requirements Review (SRR)
can take place, generating SRR Approval, which triggers an
Implementation cycle that generates a new System Version.
The Requirements Engineering process is continuous and
iterative. It sustains the handling of one requirement at a time, if
necessary. It can run in parallel to Implementation, feed it with
revised SysReqs, and allow agile development, thereby relaxing
the Vee Model. It also ensures a buffer between stakeholder
requests and expectations on the one hand, and approved
SysReqs for implementation on the other hand. Maturity,
Coverage, and Convergence conditions for making progress in
the process are all in the sufficiency range, rather than complete,
since this is the practical state-of-affairs.
OPCAT’s animated simulation is illustrated in Fig. 6 as it
cyclically executes Requirements Engineering. When the screen
was captured, it had run for 48 times (the number 48 appears at
about 5 o’clock of the ellipse contour), and included 117 steps
(as indicated by the rightmost column of the life-span matrix
view on the lower part of the screen). It generated 48
Stakeholder Requirements, 19 System Requirements, and two
SRR Approvals (the numbers appear in the bottom-right corner
of each object). It is about to complete another System Fig. 6. OPCAT Screenshot during animated simulation of the Requirements
Requirements Review (SRR) (the subprocess that is highlighted) Engineering process.
 The numbers do not serve to estimate proportions, because
they are not based on a probabilistic scheme for state generation.
OPCAT simulation uses uniform distributions for generating
object states, to accelerate the state-space coverage. Hence, the
numbers reflect the possibility to go through the process in all
the various paths.
C. System Requirements Eliciting
In Fig. 7, we zoom into the System Requirements Eliciting
subprocess and elaborate on the activities that take place within
it. The process begins with Requirement Clarifying, which aims
to ensure the Systems Engineer’s understanding of the
Stakeholder’s intention. The next phase is Stakeholder
Requirement Classifying, which generates a classification of the
Requirement Coverage by Current Solution into covered,
uncovered-coverable, uncoverable, or undesired.
Fig. 7. In-zoomed view of the System Requirements Eliciting process.
A Stakeholder Requirement that is already covered means
the stakeholder is asking for something he or she already has
without being aware of it. In this case, in addition to clarifying
this to the stakeholder, there is only need for Coverage Updating,
i.e., defining a Stakeholder Requirement Coverage for the new
Stakeholder Requirement by the System Requirement that is
covered by the system’s feature that provides the coverage.
An uncoverable Stakeholder Requirement indicates that the
current solution must undergo significant architectural change to
accommodate the stakeholder’s request. Hence, new request-
covering System Requirements must be defined and allocated
to the system’s Architecture. The expected Form and Function
modification will be specified in a Design Change Request.
In both cases, in addition to adjusting or modifying System
Requirements, a model-based approach mandates the creation
of a new System Model Version. The model specifies the
Architecture, Form, and Function, as well as the Requirement
View, which provides a conceptualization of the System
Requirement in the contexts of the current state and future state
of the system. In addition, the Stakeholder Requirements,
Stakeholder Requirement Coverage by System Requirements,
and System Requirement Coverage by the Architecture are all
captured in the model. Hence, the modeling language must
accommodate this ontology, i.e., include notation for specifying
these concepts and constructs. This process model can work
with OPM, SysML (with Use Case and Requirements Diagram
[17]), or Simulink [26]. In the next section, we demonstrate
practicing this approach in OPM.
Finally, a Stakeholder Requirement can be undesired, i.e.,
the stakeholder is asking for something that we are not interested
in providing (such as interface to a competitor’s product, a
severe vulnerability that may harm the stakeholder, or a costly
modification). In this case, a Requirement Rejecting procedure
is needed, and an appropriately justified Stakeholder
Requirement Rejection Notice is issued.
The complete Requirements Engineering model is available
online at https://1drv.ms/f/s!AsN2SH2tvCOWjn3QNnhVhOyVaflz
for readers to explore and utilize. The model does not cover the
entire Systems Engineering or Requirements Management
processes. Rather, it focuses on structuring the transition from
SHRs to SysReqs and system architecture.
IV. EXAMPLE: ROBOTIC BAGGAGE LOADING SYSTEM
In this section, we present an example of our approach by
implementing it for designing a robotic baggage loading system
for an international airport. In a publicly-available call-for-
proposals (CfP) [27], the Civil Aviation Authority of Singapore
asked for solutions for the automation of baggage loading and
unloading process for narrow-body aircraft in Singapore
Changi Airport with minimal human intervention and oversight.
A. Stakeholder Requirements
The CfP constitutes a bona fide SHRD. This stakeholder
faces a manpower crunch, and must get by with less labor force.
Currently, checked-in baggage is conveyed to carousels, from
which airport workers manually lift bags and place them in
towed baggage trolleys. Each carousel serves up to five flights,
but can be assumed for this CfP to serve only one flight. The
baggage train is driven to the aircraft, where the baggage is
manually unloaded from the trolley and loaded onto the aircraft.
In this study, we focus on the first phase of the process,
baggage trolley loading. First, we must pay special attention to
the topic of the CfP, which explicitly uses the term automation,
clarifying that the expected solution must be based on automated
(as opposed to manually operated) components. Hence, this is
the first requirement (A) in the SHR set, listed in TABLE I.
The CfP states that workers near the carousel first scan a
card, which identifies the trolleys assigned for outbound flights.
They identify bags on the carousel for the particular trolley, lift
the bags from the carousel, scan the baggage tags with a hand-
held barcode scanner of the airport’s Baggage Reconciliation
System (BRS), and place them in the baggage trolley. The CfP stakeholder needs. The unfolded Stakeholder Requirement Set
states that this phase requires 2 men, who work for 3 hours, to OPD is shown in Fig. 8.
load approximately 120 bags per flight. The customer did not
explicitly specify the process to be performed, but the manual After the System Requirement Set is reviewed with the
process to be replaced. The current-state’s outcomes are hence customer and approved, it becomes the reference for the ABLS
implicit SHRs (requirements B through E). architecture, since SHRs are covered by the SysReqs, which
comply with all the best practices of requirements authoring.
In the CfP’s System Requirement and Specifications section, The next phase is specifying a system architecture and allocating
the stakeholder asks for solutions that achieve significant SysReqs to architectural features – form and function.
savings in manpower requirements (req. F) and satisfy various
requirements and specifications (requirements G through Q). TABLE II. SYSTEM REQUIREMENTS
# System Requirement (SysReq) Covered
TABLE I. STAKEHOLDER REQUIREMENTS SHRs
Stakeholder Requirement (SHR) 1. The ABLS shall work automatically – without A, F
continuous manual activation.
A. Automate the baggage trolley loading process 2. The ABLS shall require no more than 1 man hour per F
B. Identify the trolley’s assignment for an outbound flight flight (1/6 of the labor currently required per flight)
C. Lift bags from the carousel 3. The ABLS shall read current trolley tags and identify the B, R
D. Scan the barcode tags on the bags flight
E. Place the bags in the baggage trolley 4. The ABLS shall extract bags from the customer’s R, L, R
F. Achieve significant savings in manpower requirement existing carousels.
G. Handle minimum and maximum size and weight of bags 5. The ABLS shall read current and standard baggage tags D, R
H. Handle different baggage materials (e.g. plastic, leather, etc.) 6. The ABLS shall place bags in the customer’s existing E, R
I. Handle wet or dry condition of the bags trolleys.
J. Exemption from handling oversized baggage 7. The ABLS shall load bags at the customer-specified G
K. Load 120 bags within 30 minutes weight range.
L. Interface with existing carousel without modifying it 8. The ABLS shall load bags at the customer-specified size G
M. Handle baggage at the speed of 27 m/min range.
N. Fit into the baggage sorting area and maximum height of 2.4 m 9. The ABLS shall handle bags of all the customer- H
O. Provide sufficient space of at least 1 m around the existing BGS for specified materials.
maintenance access 10. The ABLS shall load bags regardless of whether they are I
P. Allow vehicle movement in the baggage sorting area dry or wet.
Q. Comply with the “Airside Operational Safety” (AOS) manual and 11. The ABLS shall avoid loading over-sized bags if such J
fire safety requirements. items are on the carousel.
R. Easy implementation, minimal modifications and disruptions, 12. The ABLS shall load up to 4 bags per minute (15 sec per K
maintenance, training, etc. bag)
13. The ABLS shall handle items arriving at up to 0.5 m/sec. M
14. The ABLS shall fit into a 2.4 m high box. N
B. System Requirements 15. The ABLS shall load trolleys at least 1 m away from the O
carousel.
In this example, all the SHRs were submitted in advance, and 16. The ABLS shall not disturb vehicle movement 3 m from P
no further iterations were intended. Nevertheless, some SHRs the carousel.
were changed or elaborated down the road, after the solution was 17. The ABLS shall comply with the safety regulations. Q
first introduced to the customer. We generated SysReqs to cover 18. The ABLS shall be easy to install, activate, and control. R
the SHRs, as the protocol dictates. Even though the customer
listed some requirements as SysReqs, they are still considered
SHRs. The proposed SysReqs for our Automated Baggage C. Covering System Requirements by a System Architecture
Loading System (ABLS) are listed in TABLE II. We are now able to define the system, its seed function,
We now turn to integrate the Requirements Engineering functional decomposition, structural decomposition, and
process into the ABLS model. Thus, defining the requirements allocation of function to form. The outcome is a unified
within the model, rather than specifying the solution, becomes structural-functional specification [28], which is also
the first step of the modeling process. First, we create a requirements-driven. The steps to be followed, along with the
Stakeholder Requirement Set container in the OPM model’s OPM specification patterns that implement them, and an
topmost diagram (SD-0), and unfold it. We then specify that the example or reference in the ABLS case, are specified in TABLE
Stakeholder Requirement Set consists of many possible III. The integrated view of the requirements-driven functionally
appearances of the Stakeholder Requirement type object. We and structurally decomposed ABLS is shown in Fig. 9.
then create a separate object for each actual requirement, which We allocate SysReqs as attributes of the system’s functional
is a specialization of Stakeholder Requirement. and structural building blocks. This approach facilitates later
The coverage of Stakeholder Requirements by System refinement of SysReqs into actual attributes. Allocating
Requirements is done in the unfolded Stakeholder Requirement SysReqs to functions is always preferable to the allocation to
Set OPD. OPM’s tagged structural link is used for specifying form, since it is less constraining for the design. For instance,
coverage of a Stakeholder Requirement by a System allocating SysReq#4 to Baggage Retrieving, rather than to
Requirement. The visual coverage immediately shows if any Actuator Subsystem, postpones possibly binding assumptions
SHR is not covered, or if any SysReq is not originated from about form characteristics to the design phase.
 The outcome after this procedure is a functional-structural
decomposition of the system with allocation of SysReqs to the
system’s form or function. This model must be elaborated to
include functional requirements assigned to functions, structural
requirements assigned to subsystems or components, and
operational scenario specification that captures the utilization of
system functionality by its enveloping system [29]. These
extensions are beyond the scope of the current paper.

Fig. 8. Unfolded view of ABLS SHRs coveage by SysReqs.

TABLE III. SYSTEM ARCHITECTURE SPECIFICATION
# Step (OPM specification pattern) ABLS Model
Elements
1. Define the prospective system’s seed- Baggage Trolley
function (process) Loading
2. Define the system (object) that provides Automated Baggage
the seed-function. Loading System
(ABLS)
3. Decompose the seed-function to a Trolley Identifying,
minimal set of system functionalities that Baggage Identifying,
Baggage Retrieving,
cover the SysReqs (aggregation- Trolley Loading.
participation between functional process
and its sub-functionality processes).
4. Allocate SysReqs to functionalities or to Transient phase on
the main system (exhibition- the way to Fig. 9.
characterization between functional
process and SysReq)
5. Decompose system functionalities to a Control Subsystem,
minimal set of sub-functionalities while Sensor Subsystem,
Actuator Subsystem.
decomposing the system into a minimal Sub-functionality –
set of subsystems that can cover the sub- Fig. 9.
functionalities (aggregation-
participation). Fig. 9. ABLS functional-structural decomposition with SysReq allocation to
6. Refine the allocation of SysReqs to sub- See Fig. 9. form (subsystem) and function (functionality/sub-functionality).
system or sub-functionality if fully The ABLS model, which includes the SHR coverage view
delegated to that level (replace exhibition-
characterization links)
(Fig. 8) and the SysReq-based architecture view (Fig. 9) is
a available on-line for the reader’s further review and analysis
(https://1drv.ms/u/s!AsN2SH2tvCOWjlZsB3H5RNRQcwfj).
 V. DISCUSSION AND CONCLUSION
Model-based requirements engineering (MBRE) is gaining
momentum as an approach for engineering requirements. In this
work, we have proposed an MBRE approach based on ISO
19450 OPM – Object-process Methodology, which formalizes
and streamlines the modeling of both the problem-facing
stakeholder requirements and the solution-, technically-oriented
system requirements.
OPM serves two purposes: First, it models the methodical
MBRE process of modeling the two requirements sets, the
coverage of the latter by the former, and the evolution of the
requirements. This model can become part of a model-based
requirements engineering protocol in the future. Second,
following this modeled MBRE method, we model the SHRs,
SysReqs, coverage, system architecture, assignment of form to
function, and related aspects. The real-life example of
automating a baggage handling system at Singapore
International Airport provides a proof-of-concept of the viability
of our MBRE approach.
In future work we plan to (1) carry out experiments to assess
the value added by using this approach compared with
traditional RE, (2) extend the framework to cover model-based
design of the solution to comply with the system and subsystem
requirements, and (3) incorporate this MBRE approach into the
upcoming OPCloud, the next-generation OPM software.
ACKNOWLEDGMENT
We thank Gordon Center for Systems Engineering at Technion
– Israel Institute of Technology, for funding this research. We
also thank the anonymous referees for their useful comments.
REFERENCES
[1] INCOSE, Systems Engineering Handbook, V. 3.2.2. INCOSE, 2011.
[2] C. Pacheco and I. Garcia, “A systematic literature review of stakeholder
identification methods in requirements elicitation,” J. Syst. Softw., vol.
85, no. 9, pp. 2171–2181, 2012.
[3] E. Hull, K. Jackson, and J. Dick, Requirements Engineering, Third Edit.
Springer, 2011.
[4] Y. Bijan, J. Yu, J. Stracener, and T. Woods, “Systems Requirements
Engineering—State of the Methodology,” Syst. Eng., vol. 16, no. 3,
2013.
[5] M. Fockel and J. Holtmann, “A Requirements Engineering Methodology
Combining Models and Controlled Natural Language,” MoDRE 2014,
pp. 67–76, 2014.
[6] J. Helming et al., “Towards a unified Requirements Modeling
Language,” in 2010 Fifth International Workshop on Requirements
Engineering Visualization, 2010, pp. 53–57.
[7] F. Schneider, H. Naughton, and B. Berenbach, “A modeling language to
support early lifecycle requirements modeling for systems engineering,”
Conf. Syst. Eng. Res. (CSER 2012), vol. 8, pp. 201–206, 2012.
[8] J. Holt, S. Perry, R. Payne, J. Bryans, S. Hallerstede, and F. O. Hansen,
“A Model-Based Approach for Requirements Engineering for Systems
of Systems,” in 7th International Conference on System of Systems
Engineering (SoSE), 2012, vol. 7, no. July, pp. 561–566.
[9] M. Adedjouma, H. Dubois, and F. Terrier, “Requirements exchange:
From specification documents to models,” in Proceedings - 2011 16th
IEEE International Conference on Engineering of Complex Computer
Systems, ICECCS 2011, 2011, pp. 350–354.
[10] M. dos S. Soares and J. Vrancken, “Model-driven user requirements
specification using SysML,” J. Softw., vol. 3, no. 6, pp. 57–68, 2008.
[11] D. Dori, Object-Process Methodology: A Holistic Systems Approach.
Berlin, Heidelberg: Springer-Verlag, 2002.
[12] D. Dori, Model-Based Systems Engineering with OPM and SysML. New
York: Springer, 2016.
[13] J. Kasser, “Seven systems engineering myths and the corresponding
realities,” in Systems Engineering Test and Evaluation Conference,
2010, pp. 1–13.
[14] F. Schneider and B. Berenbach, A Literature Survey on International
Standards for Systems Requirements Engineering, vol. 16. Elsevier B.V.,
2013, pp. 796–805.
[15] ISO/IEC/IEEE, ISO/IEC/IEEE 15288: Systems and software
engineering — System life cycle processes, vol. 2008. ISO/IEC/IEEE,
2008.
[16] R. Laleau, F. Semmak, A. Matoussi, D. Petit, A. Hammad, and B.
Tatibouet, “A first attempt to combine SysML requirements diagrams
and B,” Innov. Syst. Softw. Eng., vol. 6, no. 1, pp. 47–54, 2010.
[17] J. Holt, S. Perry, R. Payne, J. Bryans, S. Hallerstede, and F. O. Hansen,
“A Model-Based Approach for Requirements Engineering for Systems
of Systems,” IEEE Syst. J., vol. 9, no. 1, pp. 1–11, 2014.
[18] B. Berenbach, “A 25 year retrospective on model-driven requirements
engineering,” in 2012 Second IEEE International Workshop on Model-
Driven Requirements Engineering (MoDRE), 2012, pp. 87–91.
[19] J. Favaro, R. Schreiner, and X. Olive, “Next Generation Requirements
Engineering,” in INCOSE International Symposium, 2012, pp. 461–474.
[20] ISO/TC 184, ISO/PAS 19450 - Automation systems and integration —
Object-Process Methodology, no. 1. ISO, 2015.
[21] D. Dori, “Analysis and Representation of Computer Vision Systems By
the Object-Process Methodology,” IAPR Work. Mach. Vis. Appl., 1994.
[22] D. Dori, C. Linchevski, and R. Manor, “OPCAT – An Object-Process
CASE Tool for OPM-Based Conceptual Modelling,” in 1st International
Conference on Modelling and Management of Engineering Processes,
2010, pp. 1–30.
[23] D. Dori and I. Reinhartz-Berger, “An OPM-based metamodel of system
development process,” in Lecture Notes in Computer Science, vol. 2813,
Springer Berlin Heidelberg, 2003, pp. 105–117.
[24] A. Blekhman and D. Dori, “Model-Based Requirements Authoring -
Creating Explicit Specifications with OPM,” in 6th International
Conference on Systems Engineering, 2011.
[25] A. Blekhman, J. P. Wachs, and D. Dori, “Model-Based System
Specification with Tesperanto: Readable Text From Formal Graphics,”
IEEE Trans. Syst. Man, Cybern. Syst., 2015.
[26] M. P. E. Heimdahl, L. Duan, A. Murugesan, and S. Rayadurgam,
“Modeling and requirements on the physical side of cyber-physical
systems,” 2013 2nd Int. Work. Twin Peaks Requir. Archit. TwinPeaks
2013 - Proc., pp. 1–7, 2013.
[27] C. A. A. of Singapore, Aviation Challenge 1. Singapore, 2014.
[28] Y. Mordecai and D. Dori, “Agile modeling of an evolving ballistic
missile defense system with Object-Process Methodology,” in 9th
Annual IEEE International Systems Conference, SysCon 2015 -
Proceedings, 2015.
[29] Y. Mordecai and D. Dori, “Model-Based Operational-Functional
Unified Specification for Mission Systems,” in 10th Annual IEEE
International Systems Conference (SysCon), 2016.