Building Better Requirements with SysML

Whitepaper by Joseph D. Gaskell

02 Jan 2018
 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

Revision History

Revision Date Change Description/Rationale

- 2-Jan-19 Initial Release

Author: Joseph D Gaskell Page | 1 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

Table of Contents
1 Introduction ............................................................................................................................ 3
1.1 Purpose............................................................................................................................. 3
1.2 Scope ................................................................................................................................ 3
1.3 Approach .......................................................................................................................... 3
2 References .............................................................................................................................. 4
2.1 Referenced Material ........................................................................................................ 4
2.2 Abbreviations and Acronyms ........................................................................................... 4
2.3 Definition of Terms........................................................................................................... 4
3 Understanding Requirements Best Practices ......................................................................... 7
3.1 Purpose and Scope ........................................................................................................... 7
3.2 Eliciting Requirements ..................................................................................................... 7
3.2.1 Current Best Practices............................................................................................... 7
3.3 Building Requirements ..................................................................................................... 9
3.3.1 Current Best Practices............................................................................................... 9
4 Building Better Requirements Engineering with SysML ....................................................... 14
4.1 Purpose and Scope ......................................................................................................... 14
4.2 Improved Requirements Engineering with SysML ......................................................... 14
4.2.1 Well-Formed Requirement Statements.................................................................. 14
4.2.2 Improved Requirement Attributes ......................................................................... 15
4.3 Process for the Development of System Requirements ................................................ 19
4.3.1 Convert Stakeholder Requirements into Well-Formed System Requirement
Statements ............................................................................................................................ 19
4.3.2 Analyze System Requirements ............................................................................... 20
4.3.3 Represent System Requirements and Intent with SysML Elements ...................... 20
4.3.4 Capturing Design and Verification .......................................................................... 21
4.3.5 Formal Review of System Requirements ................................................................ 21

Author: Joseph D Gaskell Page | 2 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

1 Introduction
1.1 Purpose
It is an accepted fact in Systems Engineering (SE) that the quality of a system’s requirements
largely impacts how well the system will fully address the stakeholder’s concerns. Current SE
efforts place a heavy focus on developing and managing requirements properly, and though it is
known to be a value-added effort, requirements development and management is still arduous
and costly. Furthermore, the current methods for developing requirements requires that the SE
organization have a rigorous method for development in place and method for how to handle
requirements change without allowing creep.
SE, including requirements management, is also undergoing a paradigm shift as both the
community is beginning to incorporate the use of the Systems Modeling Language, SysML. This
paradigm shift not only demands that we adapt how requirements are managed, but also
provides the unique opportunity to improve how requirements are developed and managed
and, if done right, could potential reduce the time and cost associated with the management of
the requirements.
Therefore, the purpose of this document is to compile information gathered from various
sources to propose a better method for developing and maintaining requirements using SysML.

1.2 Scope
This document will specifically address requirements development and management standards
and best practices and how those can be incorporated using SysML. The goal is to provide an
initial plan for how requirements could be developed and managed with SysML but will likely
be improved upon as lessons are learned during implementation. Additionally, this document
will address potential features within SysML that could be used to better develop or manage
requirements.
However, this document will not cover the SysML language basics or any aspect that is not
associated with the development or maintenance of requirements. Nor does this document
attempt to cover any aspect of SE outside of requirements, though it will cover how the
requirements will be related to these aspects, i.e. how requirements are link to a verification or
physical architecture.

1.3 Approach
This document presents a compilation of existing guidance, standards and white papers with
the intent of explaining what a good requirement is, how requirements are developed with
traditional SE methods, and what could be done with SysML to improve those methods.
This compilation is followed with the author’s recommend plan for developing and maintaining
requirements using SysML to improve requirement rigor and potentialy reduce time and cost
for requirements management.

Author: Joseph D Gaskell Page | 3 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

2 References
2.1 Referenced Material
1. INCOSE Requirements Working Group Technical Paper, “Guide for Writing
Requirement”, INCOSE-TP-2010-006-01, Rev 1
2. AFIS MBSE Technical Committee Technical Paper, “Requirements and Architecture
within Modelling Context”, ISBN 978-2-900969-00-7, December 2016
3. IEEE International Standard, “Systems and software engineering-Life cycle processes-
Requirements engineering”, ISO/IEC/IEEE 29148, First Edition 2011-12-01
4. deLamre, Mike, INCOSE Infrastructure Working Group Pamphlet, “Managing
Requirements for Design”, INCOSE-PI-2015-003-1.0, Version 1.0
5. Friednethal, Stanford; Moore, Alan; Steiner, Rick Textbook, “A Practical Guide to
SysML”, ISBN 978-0-12-800202-5, 2015
6. Delligatti, Lenny Textbook, “SysML Distilled: A Brief Guide to the Systems Modeling
Language”, ISBN 978-0-32-192786-6
7. Wikipedia Page, “Model-Based Systems Engineering”,
https://en.wikipedia.org/wiki/Model-based_systems_engineering, accessed December
19, 2018.

2.2 Abbreviations and Acronyms

INCOSE International Council on Systems Engineering
SysML Systems Modeling Language
MBSE Model-Based Systems Engineering
SE Systems Engineering
SOI System-Of-Interest
CONOPS Concept of Operations
OMG Object Management Group
AFIS Association Francaise d’Ingenierie Systeme (French Association of Systems
Engineering)
IEEE Institute of Electrical and Electronics Engineers

2.3 Definition of Terms

Attribute
Inherent property or characteristic of an entity that can be distinguished quantitatively or
qualitatively by human or automated means. 3
Baseline
Specification or product that has been formally reviewed and agreed upon, that thereafter
serves as the basis for further development, and that can be changed only through formal
change control procedures. 3

Author: Joseph D Gaskell Page | 4 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

Concept of operations (CONOPS)

verbal and graphic statement, in broad outline, of an organization's assumptions or intent in
regard to an operation or series of operations. 3
Condition
Measurable qualitative or quantitative attribute that is stipulated for a requirement. 3
Constraint
Externally imposed limitation on system requirements, design, or implementation or on the
process used to develop or modify a system. 3
Customer
Organization or person that receives a product or service. 3
Derived requirement
Requirement deduced or inferred from the collection and organization of requirements into a
particular system configuration and solution. 3
Levels of abstraction
Organizational structure applied to a system to view objects at various and specific degrees of
detail. 1,3
MBSE (Model-Based Systems Engineering)
Systems engineering methodology that focuses on creating and exploiting domain models as
the primary means of information exchange between engineers, rather than on document-
based information exchange. 7
Operational scenario
Description of an imagined sequence of events that includes the interaction of the product or
service with its environment and users, as well as interaction among its product or service
components. 3
Operator
Entity that performs the operations of a system. 3
Requirement
Statement which translates or expresses a need and its associated constraints and conditions. 3
Requirement elicitation
Process through which the acquirer and the suppliers of a system discover, review, articulate,
understand, and document the requirements on the system and the life cycle processes. 3

Author: Joseph D Gaskell Page | 5 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

Requirements engineering
Interdisciplinary function that mediates between the domains of the acquirer and supplier to
establish and maintain the requirements to be met by the system, software or service of
interest. 3
Requirements management
Throughout the life cycle of a system, product, or service. 3
Stakeholder
Individual or organization having a right, share, claim, or interest in a system or in its possession
of characteristics that meet their needs and expectations. 3
System
A set of elements that interact with one another and can be viewed as a whole that interact
with its external environment to achieve an objective. 5
System Architecture
Fundamental concepts or properties of a system in its environment embodied in its elements,
relationships, and in the principles of its design and evolution. 2
System-Of-Interest
System whose life cycle is under consideration. 3
System Requirement Specification
Structured collection of the requirements (functions, performance, design constraints, and
attributes) of the system and its operational environments and external interfaces. 3
Traceability
Process used primarily to ensure the continuity and completeness in the refinement of the
need (specification and requirement set) in the solution. 2
Trade-off
Decision-making actions that select from various requirements and alternative solutions on the
basis of net benefit to the stakeholders. 3
User
Individual or group that benefits from a system during its utilization. 3
Validation
Confirmation, through the provision of objective evidence, that the requirements for a specific
intended use or application have been fulfilled. 3

Author: Joseph D Gaskell Page | 6 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

Verification
Confirmation, through the provision of objective evidence, that specified requirements have
been fulfilled. 3

3 Understanding Requirements Best Practices

3.1 Purpose and Scope
This section reviews the existing best practices for requirements engineering from several
sources. However, this section does not present any methodology or plan for improved
requirements engineering, that is covered in section 4.

3.2 Eliciting Requirements

3.2.1 Current Best Practices
The initial step in developing the requirements of a system is to elicit them from Stakeholders
and capture any requirements imposed on the system due to its interfaces with external
systems or analyzed maintenance/operational records.
The IEEE 29148 – requirements engineering standard3 outlines the process of eliciting
requirement into 2 steps;
1) “Identify the individual stakeholders or stakeholder classes who have a legitimate
interest in the system throughout its life cycle.”
2) “Elicit stakeholder requirements from the identified stakeholders.”
These steps are described in more detail in the following paragraphs.
3.2.1.1 Identifying System Stakeholders
The definition of a stakeholder is any individual or organization having a right, share, claim, or
interest in a system or in its possession of characteristics that meet their needs and
expectations. However, it is important to note that external systems that interact or interface
with the system-of-interest (SOI) may also impose requirements onto the SOI, and therefore
could be treated as a “virtual stakeholder.” Given the definition of what a stakeholder is, the
following describes a breakdown of how to not only identify all the stakeholders, but also have
a better picture of each stakeholder’s role in the development of the SOI and its requirements.
1) Identify: From the viewpoint of the SOI’s entire life-cycle, identify all individual and
organizational stakeholders. It is important to identify as many of the stakeholders as
possible to ensure a complete and unbiased view of the SOI and how it impacts external
systems.
2) Representation: Assess the list of stakeholders to ensure that each stakeholder will
have a presence, or at least representation within every impacted level of each
organization. By including every level of an organization that is impacted by the SOI, a

Author: Joseph D Gaskell Page | 7 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

more comprehensive understanding can be developed for the actual problem to be

solved.
3) Classify/Organize: Each stakeholder will have some role in either the development or
operation of the SOI. It is important to identify the role of each stakeholder and
understand which will impact the goals, strategy and operation. Clearly understanding
each stakeholder’s role will assist with making informed decisions whenever the design
solution has competing stakeholder interests.
4) Prioritize: The various levels to which each stakeholder should be assessed and used as
the method for determining the weight of each stakeholder’s concern. This prioritization
will be key in developing effective trade studies for design solutions and will assist with
better decision making.
3.2.1.2 Eliciting Stakeholder Requirements
The initial goal of eliciting stakeholder requirements is to understand and capture the needs,
wants, desires, expectations and perceived constraints for the SOI from stakeholder’s
perspectives. Though the stakeholders are the authoritative source for the SOI’s requirements,
it is likely that most will be unfamiliar with how to transform their expertise into well-formed
requirement statements.3 Therefore, it is important to document the justification and rationale
behind every stakeholder requirement. Additionally, critical aspects of the system, often
referred to as measures of performance, key performance parameters, or measures of
effectiveness, should be identified in order to measure and assess operational performance.
Requirement elicitation is an iterative activity and will likely take a variety of investigation
techniques to gather a full picture. Though any given individual activity may not include all
stakeholders, it is important to ensure that all stakeholders are involved in a few and that the
activities attempt to remain unbiased towards any one stakeholder by make sure at least a few
different stakeholders have representation at each activity. IEEE 29148 offers a few techniques
for eliciting requirements, including;

• Structured workshops with brainstorming

• Interviews, questionnaires
• Observation of environment or work patterns
• Technical documentation review
• Analysis of similar private and commercial systems
• Simulations, prototyping, modeling
Additionally, during each iteration or activity a list of common sources of requirements can be
used as a starting point to for identifying stakeholder requirements. An example list of common
sources follows;

• Goals and thresholds

• Mission
• Operational scenarios

Author: Joseph D Gaskell Page | 8 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

• Operational environment and context of use

• Operational Deployment
• Performance
• Effectiveness
• Operational life cycle
• Organizational environment
• User and operator characteristics3
• Safety and regulatory constraints
• Impacts from interacting/interfacing external systems
• Existing requirements on similar systems
Note: Definitions for most of these sources can be found in IEEE 29148.
All discovered stakeholder requirements should be compiled and distributed to all stakeholders
for review and input to ensure the intent of the system is being met.

3.3 Building Requirements

3.3.1 Current Best Practices
3.3.1.1 Interpreting Stakeholder Requirements to Define System
As stated in section 3.2.1.2, there will likely be a need to transform the initial elicited
requirements from stakeholders into well-formed requirement statements to ensure proper
requirement engineering practices are used. However, the SOI, and its boundaries, must be
defined so the system can be understood. Similar to writing requirements, defining the SOI will
be an iterative process with feedback from stakeholders. Therefore, it is recommended to begin
a draft definition of the SOI as early as possible, with the expectation that it will be updated as
requirements are elicited from stakeholders.
By developing a draft definition of the SOI early, it engages stakeholders early to understand
the design agent’s interpretation of the SOI. This allows more opportunity for stakeholders to
correct misunderstanding and will ultimately result in more accurate requirements to build the
system the user needs.
The following outline the major aspects of how the SOI can be defined.

• Define System Domains: The system domains refer to each of the specific conditions of
a given instance where the SOI is used. For instance, if the SOI is a knife, there could be
a domain related to self-defense and another for cutting food. Each domain may
interact with different other systems (i.e. an adversary or a cucumber) and may require
different functionality for each one (i.e. poisoned-tipped or sanitary).
Typically, a system’s domain is defined by outlining all other systems it will interact with,
and any known interfaces between the systems. The domain should also define the

Author: Joseph D Gaskell Page | 9 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

users of the SOI, its stakeholders and the environment the SOI will operate in when
applicable.
• Define Use Cases: The Use Cases of a system represent the highest level of abstraction
for defining the functionality of the SOI within a given domain in terms of how it is used
to achieve the goals of its various users. Use Cases can be derived from Mission
Scenarios, Operational Scenarios, or other interpretation of stakeholder needs. Use
Cases will also begin to define how the interfacing systems and the SOI will interact.
• Define Key Performance Parameters: Though it may go by many names the intent of
these Key Performance Parameters (KPPs) is to have specific parameters that are critical
to users or stakeholders in order to measure how well the design of the system is
meeting its goals. KPPs are typically associated with the first degree of functionality that
will achieve its mission. For example, assume a KPP of a missile is to travel above a
certain velocity to avoid detection. Though many parameters may impact speed (weight,
shape, etc.) the KPP is just the missile’s cruising velocity.
The KPP’s should be tied to the SOI and to which stakeholder requirement it is held to as
it is common to have competing KPPs and their priority will need to be weighed.
• Define System’s Constraints: These are the perceived high-level constraints placed on
the SOI for a specific domain. These are often simplified and defined in more detail as
the detailed design work occurs. An example of a high-level constraint could be the
intended location for the storage of the SOI may only allow object below a set weight to
be stored, this would put a constraint on the SOI in the form of a maximum weight.
The various definitions of the SOI can be document in the Concept of Operations (CONOPS)
document or any other document (or model) that is readily available to all of stakeholders.
It is important that the system is well defined before transforming the elicited stakeholder
requirements into requirement statements or there is a significant risk of misinterpreting
the intent of the system.
3.3.1.2 Constructing Well Formed Requirement Statements
Constructing well formed requirement statements can begin after the first iteration of eliciting
stakeholder requirements and should be revised with each iteration. The first step in
constructing the requirements is to analyze the complete set of requirements by identifying
and prioritizing the conflicting, missing, incomplete, ambiguous, inconsistent, incongruous or
unverifiable requirements. Negotiation of requirements among stakeholders may be necessary
to resolve conflicts between schedule, budget, or performance of the system. The results of
these negotiations must be documented as part of the requirement’s rationale.3 Note that
Table 1 includes characteristics of sets of requirements which help guide the analysis of the
requirement sets.

Once all the requirement set problems have been resolved, ensure that all stakeholders needs
and expectations for the requirements set have been addressed. If the set of requirements is
inline with stakeholder intent the requirements should then be recorded in a suitable form for

Author: Joseph D Gaskell Page | 10 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

requirements management.3 Table 1 and Table 2 provide guidance for writing proper singular
requirements.
Table 1: Characteristics of Well-Formed Requirements and Requirement Sets

Characteristics of Requirement Statements

Guide # Title Text
C1 Necessary Every requirement statement is necessary
C2 Implementation A requirement states what is required, not how the requirement
Independent is met
C3 Unambiguous A requirement statement lends itself to a single interpretation

C4 Complete A requirement statement is complete in and of itself

C5 Singular A requirement statement addresses a single thought

C6 Feasible A requirement statement expresses something that is inherently

feasible
C7 Verifiable A requirement statement is verifiable
C8 Correct A requirement statement is a correct expression of the
stakeholder expectation
C9 Conforming A requirement statement conforms to standards selected as
applicable to the organization
C10 Traceable The requirement is upwards traceable to specific documented
stakeholder statement(s) of need, higher tier requirement, or
other source (e.g., a trade or design study). The requirement is
also downwards traceable to the specific requirements in the
lower tier requirements specification or other system definition
artefacts. That is, all parent-child relationships for the
requirement are identified in tracing such that the requirement
traces to its source and implementation.
Characteristics of Sets of Requirements
C10 Complete A set of requirement statements represents a complete
definition of the stakeholder expectations
C11 Consistent A set of requirement statements represents a consistent
expression of the stakeholder expectations
C12 Feasible A set of requirement statements represents a feasible expression
of the stakeholder expectations
C13 Bounded A set of requirement statements is within a defined scope

C14 Structured A set of requirement statements is structured such that sub-sets

of related requirement statements can be identified.

Author: Joseph D Gaskell Page | 11 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

Table 2: Criteria for Requirement's Language

Requirement Language Criteria

Shall Requirements are mandatory binding provisions and use 'shall'.
Will Statements of fact, futurity, or a declaration of purpose are non-
mandatory, non-binding provisions and use 'will'. 'Will' can also be used to
establish context or limitations of use. However, 'will' can be construed as
legally binding, so it is best to avoid using it for requirements.
Should Preferences or goals are desired, non-mandatory, non-binding provisions
and use 'should'.
May Suggestions or allowances are non-mandatory, non-binding provisions and
use 'may'.
Must It is best to avoid using the term ‘must', due to potential misinterpretation
as a requirement.
are, is, was Non-requirements, such as descriptive text, use verbs such as ‘are', ‘is',
and ‘was'.
Positive Use positive statements and avoid negative requirements such as ‘shall
Statements not'.
Active Voice Use active voice: avoid using passive voice, such as 'shall be able to select'.

Condition Conditions are measurable qualitative or quantitative attributes that are

stipulated for a requirement. They
further qualify a requirement that is needed and provide attributes that
permit a requirement to be formulated and stated in a manner that can be
validated and verified. Conditions may limit the options open to a
designer. It is important to transform the stakeholder needs into
stakeholder requirements without imposing unnecessary bounds on the
solution space.
Subject

Action

Object

Constraint

Value

Author: Joseph D Gaskell Page | 12 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

Unbounded/ Superlatives (such as 'best', 'most')

Ambiguous Subjective language (such as 'user friendly', 'easy to use', 'cost effective')
(avoid) Vague pronouns (such as 'it', 'this', 'that')
Ambiguous adverbs and adjectives (such as 'almost always', 'significant',
'minimal')
Open-ended, non-verifiable terms (such as 'provide support', 'but not
limited to', 'as a minimum')
Comparative phrases (such as 'better than', 'higher quality')
Loopholes (such as 'if possible', 'as appropriate', 'as applicable')
Incomplete references (not specifying the reference with its date and
version number; not specifying just
the applicable parts of the reference to restrict verification work)
Negative statements (such as statements of system capability not to be
provided)

3.3.1.3 Linking Requirement Attributes

In order to better understand how the requirements impact the system and how changes to the
system may impact requirements it is important to document how the requirements are
related to the system and its components, both internal and external. These linkages are also
referred to as attributes of requirement statements. Table 3 provides a summary of the
attributes applied to requirements using the INCOSE Guide to Writing Requirements 1.
However, developing and maintaining the linkages/attributes of requirements in a document is
challenging and creates additional cost and time to do properly. Therefore, when relying purely
on documentation to capture the requirement attributes it is best practice to only identify the
high-risk requirements or those most likely to change and only maintain the linkages for those.
NOTE: Developing and maintaining the linkages for all requirements using SysML and an
appropriate modeling tool has the potential to gain all the benefits of linking requirements
properly and reduce the overall effort (and therefore cost) of maintaining them.
Table 3: Attributes of Requirement Statements

Attributes of requirements statements

Guide # Title Text
A1 Alignment with The satisfaction relationship between levels of requirements is
Need documented
A2 Alignment with The relationship between the requirements and the design is
Design documented
A3 Alignment with The relationship between requirements and verification
evidence artifacts is documented
A4 Priority A requirement statement possesses an indication of relative
priority

Author: Joseph D Gaskell Page | 13 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

4 Building Better Requirements Engineering with SysML

4.1 Purpose and Scope
The purpose of this section is to identify and provide guidance on how to use SysML to improve
how requirements are developed from elicited stakeholder requirements.
This section outlines what improvements can be made to requirements engineering using
SysML in detail using a 5W2H (Who, What, Why, Where, When, How, and How Many)
approach. This section also includes initial high-level procedures for developing requirements
using this improved approach.

4.2 Improved Requirements Engineering with SysML

SysML is a general-purpose modeling language that supports the analysis, specification, design,
verification, and validation of complex systems. By using a standardized language as the basis
for developing models, models are more understandable, and can be queried consistently.
Using SysML to model requirements and their attributes has the potential to greatly improve
requirements, the following are some benefits outlined in the “Requirements and Architecture
within Modeling Context” whitepaper from AFIS;

• Graphical and standard notation helps reflecting expectations in a concise and less
ambiguous way
• Problems can be viewed from controlled viewpoints, which can assist with developing
comprehensive requirements, and creating scoped sets of data similar data for
assessments
• Assist with measuring progress in capture
• Model brings a centralized definition for requirements where all characteristics and
attributes can be contained
• Improved granularity through structured development through the levels of abstraction.
The following sections provide detailed explanations of implementations for gaining these
benefits through modeling.
4.2.1 Well-Formed Requirement Statements
Ensuring that requirements are captured in well-formed statements is a cornerstone of
requirements engineering. The best practices outlined in section 3.3 still provide the best
guidance for writing well-formed requirements. SysML alone provides no way to develop better
written requirements. However, it may be possible to develop validation rules, perhaps based
on the rules outlined in the INCOSE Guide for Writing Requirements, that could assess the text
property of requirements and highlight those that may be violating a rule. This would likely be a
serious and costly effort and is outside the scope of this document.

Author: Joseph D Gaskell Page | 14 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

4.2.2 Improved Requirement Attributes

The following are recommended requirement attributes to be incorporated using SysML. Each
attribute is described using the 5W2H method which follows,

• Who: Who is ultimately responsible for the attribute

• What: A description of what the attribute is
• Why: An explanation of the importance and reasoning behind the attribute
• Where: All attributes are stored within the system model to develop a centralized
definition of the requirement
• When: Sections 4.3 outline a proposed process for developing requirements, therefore
this question will be skipped for the time being.
• How: How is the attribute captured using SysML
• How Many: The number of this attributes that may be applied to an individual
requirement
4.2.2.1 Name and Identification
• Who: Stakeholders
• What: A unique identification for each individual requirement (i.e. name and ID tag).
Once assigned the identification must be unique and never changed, even if the
identified requirement changes, nor reused, even if the identified requirement is
deleted.
• Why: Identification aid in requirements tracing, and allow requirements to be tracked,
searched and managed even within large sets of requirements.
• Where: Requirement name and ID are included properties of requirement elements
within SysML.
• How: Requirement identification can be managed within the element’s specification.
• How Many: Each requirement should have ONLY one name and one ID tag.
4.2.2.2 Rationale and Alignment with Need
• Who: Stakeholders
• What: The rationale provides the reason that the requirement is needed as well as
clarifying the intent.
• Why: Rationale supports trade studies, requirement prioritization and decision making
by clarifying the intent of the requirement.
• Where: Rationale can be captured in “rationale” elements, which are a stereotyped
extension of the comment element.
• How: These elements can be attached to whatever element they are rationalizing. In
this specific case, the rationale for a requirement statement should be attached to the
requirement element. However, it is also helpful to add rationale to clarify any
requirement relationship that needs extra explanation. For example, if a particular
requirement is only met by two components of the design functioning together, then it

Author: Joseph D Gaskell Page | 15 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

will have 2 satisfy relationships. This would be unusual and should include a rationale
element to clarify why these relations exist the way they do.
• How Many: Each requirement should have a rationale attached. Additionally, one
rationale element should be added to each element or relationship where extra
explanation is beneficial. Every element and relationship should have only one rationale,
but they should only be added if element or relationship needs additional explanation to
be fully understood.
4.2.2.3 Traceability
• Who: Requirements/Systems Engineer
• What: The requirement is upwards traceable to specific documented stakeholder
statement(s) of need, higher tier requirement, or other source (e.g., a trade or design
study). The requirement is also downwards traceable to the specific requirements in the
lower tier requirements specification or other system definition artefacts. That is, all
parent-child relationships for the requirement are identified in tracing such that the
requirement traces to its source and implementation.
• Why: Bi-directional traceability is a technique that can be used to:
o Improve the integrity and accuracy of all requirements, from the system level all
the way down to the lowest level system element;
o Allow tracking of the requirements development and allocation with related
measures such as requirements coverage, compliance, and complexity;
o Provide a means of documenting and reviewing the relationships between layers
of requirements that capture certain aspects of the design; and
o Support easier maintenance and change implementation of the system in the
future.3
• Where: Traceability can be captured using “Trace” and “DeriveReqt” relationships
between requirement elements. The trace information can also be viewed/maintained
within a requirement’s specification.
• How: Requirements traceability is captured using the Trace dependency relationship to
show which external requirements, documents or stakeholders motivated or imposed
the requirement on the system. Additionally, as the system requirements are
decomposed into design requirements, the DeriveReqt dependency relationship is used
to capture show and understand how the design will satisfy the system’s requirements.
• How Many: All system requirements will require a minimum of 1 Trace dependency
relationship to ensure requirements are needed, but many requirements may have
more than 1. Most systems requirements will have one or several DeriveReqt
dependency relationships, though some requirements may only be satisfied by the
whole system and will not decompose into design requirements (NOTE: the
requirement rationale should also include the reasoning if no DeriveReqt is used).

Author: Joseph D Gaskell Page | 16 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

4.2.2.4 Stakeholder Priority

• Who: Stakeholders
• What: An indication of relative priority.
• Why: To facilitate trading off requirements and balancing the impact of changes among
stakeholders. The priority is not intended to imply that some requirements are not
necessary, but it may indicate what requirements are candidates for the trade space
when decisions regarding alternatives are necessary.3
• Where: Though it is not native to the SysML language, it would be captured best as an
added property to the requirement element to appear in the element’s specification.
• How: Either use a numbered scheme (1-5) or Low to High as an indication, as long as it is
agreed upon and consistent across projects.
• How Many: Each requirement should have one priority value assigned to it.
4.2.2.5 Type
• Who: Requirements/Systems Engineer
• What: Classification representing requirement intent and/or kinds of properties they
represent
• Why: Assists with developing views/viewpoints in a model and grouping requirements
for analysis.
• Where: Classifying groups of elements can be done with applied stereotypes in the
element’s specification.
• How: A list of requirement types should be drafted. Each type should be fairly common
among requirements or at least add value for searching by that type. ISO/IEC/IEEE
29148 provides a list of examples of types, a few of them are listed below.
o Functional. Functional requirements describe the system or system element
functions or tasks to be performed.
o Performance. A requirement that defines the extent or how well, and under
what conditions, a function or task is to be performed. These are quantitative
requirements of system performance and are verifiable individually. Note that
there may be more than one performance requirement associated with a single
function, functional requirement, or task.
o Interface. Interface requirements are the definition of how the system is
required to interact with external systems (external interface), or how system
elements within the system, including human elements, interact with each other
(internal interface).
o Non-Functional. These specify requirements under which the system is required
to operate or exist or system properties. They define how a system is supposed
to be. Quality requirements and human factors requirements are examples of
this type.

Author: Joseph D Gaskell Page | 17 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

• How Many: A requirement may have no type or may have several types. However, each
requirement should be assessed to see which types, if any, apply.
4.2.2.6 Model Representation
• Who: System Modeler/System Engineer
• What: An attribute that shows how the intents of the requirement have been
incorporated within the system model. This is direct relationship between the
requirement and the element(s) that represent its intent.
• Why: In order to reach completeness, there is a need to ensure that all requirements
have been analyzed and considered in the modeling architecture.
• Where: This dependency relationship can be built within the element’s specification,
graphs or on an allocation matrix. Ultimately all of these will build the relationship the
same in the model.
• How: The specific relationship used to represent the connection between a requirement
and its model representation has some debate, but the general consensus is to use the
‘Refine’ dependency relationship as the intent is in line with this purpose and prevent
the development of unnecessary customization which can have costly impacts when
attempting to connect various models from different modeling organizations.
• How Many: Each requirement will need at least one modeling element (in addition to
the requirement element) to represent its intent. However, most requirements will have
1-3 elements that are directly responsible for representing its intent.
4.2.2.7 Alignment with Design
• Who: Design Agent
• What: The relationship between the requirements and the design is documented.
• Why: The way in which requirements flow down through the layers of abstraction
should reflect the design, and therefore the flow-down structure should be connected
to the design. The documentation of such relationships also aids analysis of the impact
on design of changing requirements. This relationship will also help during integration
and verification where proof that the system as designed and built meets the
requirements.1
• Where: This dependency relationship can also be built within the element’s
specification, graphs or on an allocation matrix. Ultimately all of these will build the
relationship the same in the model.
• How: The ‘Satisfy’ dependency relationship, part of the SysML standard, is included
specifically to capture a requirement’s alignment with design. The other end of the
relationship should be a block that represents a logical or physical implantation of the
design.
• How Many: Every requirement should have at least one block satisfying it. Occasionally
a requirement may need to be satisfied by two or three blocks, but these instances

Author: Joseph D Gaskell Page | 18 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

should have the rationale attached to the satisfy relationship that can explain the
reason the requirement can only be satisfied by multiple parts of the design.
4.2.2.8 Alignment with Evidence / Verification
• Who: Design Agent/Stakeholder(approval)
• What: The relationship between requirements and verification artifacts is documented
to trace individual requirements to those validation and verification artifacts that
provide evidence for the satisfaction of that requirement and, in turn, to the results of
the validation and verification actions.
• Why: The requirements set not only supports the design, but also drives the collection
of evidence needed to support assurance, conformance and acceptance. Evidence is
collected through the planning and execution of validation and verification methods,
such as analysis, inspection, demonstration and test. The relationship between
requirements and validation/verification artifacts should therefore be documented, so
that the adequacy, necessity and outcomes of the verification and validation activities
can be accessed. The documentation of such relationships also aids analysis of the
impact on verification and validation of changing requirements.1
• Where: This dependency relationship can also be built within the element’s
specification, graphs or on an allocation matrix. Ultimately all of these will build the
relationship the same in the model.
• How: The SysML ‘Verify’ Relationship can connect the artifacts or verification cases to
the individual requirements
• How Many: Every requirement should have at least one verify relationship. The
requirement can have as many verify relationships as needed to ensure the requirement
is fully verified, however rationale should be included if multiple verifications are
needed.

4.3 Process for the Development of System Requirements

This section provides a brief, mid-level overview of a draft process for the development of
system level requirements using the SysML attributes outlined in the previous section. These
steps assume that the stakeholder requirements have already been elicited and are ready to be
transformed into well-formed requirement statements.
4.3.1 Convert Stakeholder Requirements into Well-Formed System Requirement
Statements
Using the best practices for writing proper requirements, described in section 3.3.1.2, elicited
stakeholder requirements are converted in to requirement statements. Each of these
statements are given a name and unique ID, section 4.2.2.1, and entered into the system model
as a requirement element (NOTE: the requirement statement should be input to the ‘text’
property of the requirement element).

Author: Joseph D Gaskell Page | 19 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

In order to maintain an understanding the requirements intent and what influenced it, it is
important to capture the rationale of the requirement, section 4.2.2.2, as well modeling each
requirements ‘Trace’ relationship, section 4.2.2.3.
It is recommended to involve stakeholders through the process of developing the requirement
statements and their rationale. An informal review of the full set of requirement statements
can be conducted to ensure all stakeholders intents have been captured and agreed upon.
4.3.2 Analyze System Requirements
Once the full set of requirements has been developed and agreed upon, the requirements are
analyzed to determine their priority, category and overall impact on design. The design agent
should work with stakeholders to develop a prioritization for each of the requirements which
are the captured in the model, section 4.2.2.4. The design agent, especially the lead systems
engineer, should then work to apply the types to requirements where appropriate, section
4.2.2.5.
The requirements will also be assessed to define the system to be developed. Section 3.3.1.1
provides some guidance on how major aspects of the system can be defined. The system
description will also assist with the next step as many elements will be part of modeling the
requirement intent.
4.3.3 Represent System Requirements and Intent with SysML Elements
As the system is beginning to be defined, the relationships to how the requirements are
impacting that definition should be captured. This is best done using the refine relationship
between an added element and the requirement responsible for its addition, as outlined in
section 4.2.2.6. Additionally, Table 4 provides an example short list of the rationale for using
various elements for various requirement types.
Table 4: Example of Modeling Elements for Refining Requirement Intent

Requirement Source Element Rationale

Intent
Functional-flow Activity A requirement that imposes functionality that can
based be modeled as a set of procedural steps and or will
have flows between systems or sub-systems will
likely be modeled as an activity. However, activities
may be contained within a Use Case, in which case
a Use Case should be the translation source.
Physical Connector When requirement imposes a flow or interaction
connections and between two systems or subsystems, a connector
interactions can model these flows and interactions.
Functional- Interaction Interaction is a modeling term, and not to be
message exchange (Sequence confused with the requirement intent above. This
Diagram) element should be the translation source when the
requirement involves communication-based

Author: Joseph D Gaskell Page | 20 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

functionality, such as a computer system that will

function based on user input.
Interface Port (including Any form of interface, internal or external, required
description subtypes) of the system will have some type of port as the
source of the requirement translation.
Tables or multiple Requirement Though it is incorrect and should be fixed in the
requirements parent specification, if a table is being reference by
a requirement or the requirement has multiple
requirements within it, a translation relationship
can be used as a stop gap to cover recapture the
requirements appropriately. However, these
translation source requirements will need to be
developed the same as all others.
Functional-state State Machine If the requirement intends to impose a set of
dependent transitions or state-changes on a system, it should
be modeled as a state machine.
Functionality Goals Use Case Typically reserved for only the system level of a
model. When a requirement directly calls out a
high-level functional goal, especially when it directly
impacts a user, it should be captured in the model
with a use case.

4.3.4 Capturing Design and Verification

As the design of the system is being developed, traceability to the system’s requirements
should be captured using the ‘Satisfy’ relationship, section 4.2.2.7. It is important to ensure that
every requirement is being satisfied by the design and that every component of the design is
satisfying at least one requirement.
Since the design will need to be verified to ensure it does meet the systems requirements, early
planning for verification should also be linked to requirements using the ‘Verify’ relationship.
Any verification should include the component of the system that is satisfying the requirement
being verified.
4.3.5 Formal Review of System Requirements
A formal review of the system level requirements should occur once all previous attributes have
been fully constructed for all requirements. The intent of this formal review is to ensure that all
system level requirements are fully understood and have been assigned the appropriate
attributes to fully reflect their intent. The following should be reviewed and approved by all
stakeholders before continuing with the design solution.

• Ensure that all stakeholder concerns and needs have been addressed
• All requirement statements are well-formed and inline with the guidance provided in
the INCOSE Guide to Writing Requirements

Author: Joseph D Gaskell Page | 21 Distribution Statement TBD

 Building Better Requirements with SysML Doc Number: TBD
Revision: Draft

• Ensure the system context and use cases have been defined
• Each of the attributes, described in section 4.2.2, have been properly developed for
every requirement.

Author: Joseph D Gaskell Page | 22 Distribution Statement TBD