Table of Contents

• 2.1. Define requirements
• 2.C Requirements traceability chains

Introduction

The purpose of requirements development is to translate the stakeholder and enabling-system view of desired capabilities (problem view) into a solution view that provides these capabilities.  A requirement is a „desired feature, property, or behavior of a system” [OMG.org/uml]. The link between the problem and solution view is established via requirements that are allocated to solution elements such as functions and components, i.e. it is documented that a solution intends to solve a problem. Whether or not the problem has been solved is determined via verification and validation activities that are covered by view 5. This allocation relationship establishes traceability between the problem and solution. In other words, if necessary, the requirements can be traced back from the functions and components of a system. This is important, as in some domains, especially for safety-critical applications, documented traceability is a legal requirement [Cleland-Huang et al., 2007].

Requirements Engineering

Requirements engineering is concerned with “the subset of systems engineering concerned with discovering, developing, tracing, analyzing, qualifying, communicating and managing requirements that define the system at successive levels of abstraction.” [Hull, Jackson, & Dick, 2011, p.8] Fig.1 shows common requirements engineering activities compiled from the literature. Requirements development is concerned with the elicitation, analysis, specification, and verification of requirements. By contrast, requirements management is concerned with establishing traceability and to implement changes if necessary.

Fig.1: Typical requirements engineering activities [adapted from Karl E. Wiegers 2000, Benoy R. Nair 2009]

An example for a requirements development process from the NASA Systems Engineering Handbook is shown in Fig.2 Note that the inputs to the process are similar to the outputs of the Operational Analysis view in arKItect SEA such as stakeholder requirements and use case scenarios (similar to Concept of Operations in NASA process), enabling systems (similar to enabling support strategies in NASA process). Furthermore, this step makes the transition from the problem view from the perspective of stakeholders and enabling systems to a technical perspective. Similarly, the INCOSE Handbook recommends that at "the beginning of the project, SE is concerned primarily with user requirements analysis - leading to the translation of user needs into basic functions and a quantifiable set of performance requirements that can be translated into design requirements." [Walden et al., 2015, p.63]

Fig.2: NASA Systems Engineering Handbook requirements requirements definition process [NASA, 2007, p.40]

In arKItect SEA view 2.1. "Define requirements" under 2 "System requirements management", we follow a similar transition from external requirements to system requirements as shown in Fig.3. Requirements are successively refined using the "refine" relationship. 

Fig.3: arKItect view 2.1. where requirements are defined and refined from external requirements to system requirements

Requirements

Requirements have been previously defined as „desired feature, property, or behavior of a system” [OMG.org/uml]. In other words, it is something to prescribe what a product must do, the required performance level, the conditions the system should to attain a given purpose. Numerous other definitions exist and some of these have been collected in the Box below. 

Box: Other requirements definitions

“It is either derived from stakeholder or user needs or stated in a contract, standard, specification, or other formally imposed document” [Bittner & Spence 2003].

A requirement is “a condition or capability to which a system must conform.” [Shuja & Krebs 2008]

“Requirements are…a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.” [Sommerville & Sawyer 1997]

"A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document." [IEEE, 2010]

In arKItect SEA, requirements are represented by a turquoise-colored rectangle, as shown in Fig.4 with the Name of the requirement at the top.  

Fig.4: Requirement in arKItect SEA

Requirement types

The system engineering literature defines several types of requirements, depending on the domain. However, most major references distinsuish between stakholder requirements and system requirements. Stakeholder requirements have been previously defined in the operational analysis step such as use cases. As the NASA Systems Engineering process in Fig.2 shows, the process includes the definiton of at least functional, behavioral, and performance requirements. The INCOSE and NASA Systems Engineering Handbook distinguish between the following types of requirements:

• Functional: "Functional requirements define what functions need to be done to accomplish the objectives." [NASA, 2007, p.42]

• Performance:"Performance requirements quantitatively define how well the system needs to perform the functions. ... Wherever possible, define the performance requirements in terms of (1) a threshold value (the minimum acceptable value needed for the system to carry out its mission) and (2) the baseline level of performance desired. Specifying performance in terms of thresholds and baseline requirements provides the system designers with trade space in which to investigate alternative designs." [NASA, 2007, p.43]

• Interface: Requirements that specify all interfaces of the system, including those to enabling systems.
• Environmental: Systems operate in different environments that are a source of requirements.
• Reliability: Reliability requirements define the probability that the system will operate in a given period of time and under specific operating conditions.
• Safety

arKItect SEA distinguishes between different requirements types. The requirement type can be selected in the "Properties --> Requirement type" section for each requirement. Table 1 shows the arKItect SEA requirement types and how far requirement types from the literature correspond to these. 

Table 1: Overview of arKItect SEA requirement types and their counterparts in the literature. 

Requirements commonly have a number of attributes such as their ID and a description. Table 2 provides an overview of the requirements attributes from arKItect SEA and major systems engineering references. It can be seen that most of the requirements attributes from the literature are covered by the arKItect SEA requirement attributes. 

Table 2: Requirements attributes from arKItect SEA and from the literature

Requirements Flowdown

Fig. 5 shows a typical requirements flowdown from the NASA SE Handbook. It starts with broad objectives and successively refines the requirements until they are at subsystem level and lower. This is similar to the refinement of requirements in SEA until sufficient requirements decomposition has been reached. Note that the flowdown is segmented into a "Customer" and "Implementing Organizations" section, which corresponds to the "external" and "systems" requirements distinction in arKItect SEA.

Fig.5: Requirements flowdown [NASA, 2007, p.46]

Define External Requirements

In the operational analysis step in view 1., the stakeholders, enabling systems, and the use cases for the system were defined. In the view 2.1., first, external requirements are defined inside stakeholders, enabling systems, and use cases. These external requirements are refined into system requirements in the second step.

In the LapTop example, Fig.6 shows how requirements were added to a Stakeholder called "User" via drag and drop from the Palette in view 2.1. 

Fig.6: Drag and drop requirements from the Palette into stakeholders, enabling systems, and use cases

An example for a stakeholder called "User" with three requirements is shown in Fig.7.

Fig.7: External requirements inside the Stakeholder "User"

These external requirements for the stakeholders, enabling systems, and use cases are refined into system requirements that are internal to the system.

Define System Requirements

After defining the external requirements and describing the environment of the system, we have to refine requirements. Indeed, requirements can be refined in sub-requirements to describe more precisely the needs and to detail to technical requirements.

Using the LapTop example, we will refine the external requirements that we have defined through the view 1.

Fig. 8 shows the expected result of this step in arKItect.

After defining the external requirements and describing the environment of the system, we have to refine requirements. Indeed, requirements can be refined in sub-requirements to describe more precisely the needs and to detail to technical requirements.

Using the LapTop example, we will refine the external requirements that we have defined through the view 1.

Figure 1 shows the expected result of this step in arKItect.

Figure 1. Define System Requirements view

You can then enter the system or enabling systems to see their requirements and sub-requirements, by double clicking on them or using the "expand" feature (right click/expand). Figure 2 shows the expanded form of the system.

Figure 2. Requirements and Sub-requirements in System

In the next sections, we explain the sub-view of the view 2 which allows to define and refine Requirements. There are two parts that explain how to define Requirements in two manners:

1. in a graphical view called Internal Block Diagram (IBD, below the toolbar, see figure 3),
2. in a tabular view (available through Project Tools icon in the toolbar, see figure 4).

Figure 3. Internal Block Diagram tab

Figure 4. Project Tools icon which gives access to Tabular Views

References