System Requirements Engineering

A SysML Supported Requirements Engineering Method

Jean-Yves Bron

• Publisher: Wiley-ISTE
• Year: 2020
• Print ISBN: 9781786305947
• eBook ISBN: 9781119751540
• Edition: 1
• Topic: Technology & Engineering
• Subtopic: Electrical Engineering & Telecommunications
• Index: Technology & Engineering

The book deals with requirements engineering in the context of System Engineering. He proposes a method to guide this activity engineering. The method is supported by the SysML modeling language. A first chapter aims to present the context and the associated definitions, to position the requirements engineering in the processes system engineering, to define the modeling and its contributions, and to make the link with the management of IS projects. The second chapter is devoted to the proposed method for implementing the requirements engineering subprocesses. Each of the 8 activities the component is first described before specifying how the SysML language can be exploited to achieve it effectively. Proposal for a book Please fill out the questionnaire below and send it back to Chantal Menascé: [email protected] The 3rd chapter is an application of the method to define the needs of the stakeholders of a system. The example is built on the basis of the RobAFIS'2018 competition. The 4th chapter continues the application of the method in the continuity of the IS processes to define the requirements of the same system. The appendices present at the same time a toolbox to realize the engineering of the requirements but also the complete results of engineering in Chapters 3 and 4.

PART 1
Requirements Engineering

1
The Requirements Engineering Process

Requirements engineering is a field that is widely addressed in systems engineering. As the latter are becoming increasingly complex, requirements engineering has become essential, even taking on important contractual aspects. The purpose of this chapter is to present the context and associated definitions and to position requirements engineering in systems engineering processes [ROB 13]. The modeling and its contributions are then presented. Finally, its connection with project management is discussed.

1.1. Background and main definitions

Our focus is on systems engineering, as defined under ISO 15288:

“An interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution and to support that solution throughout its life.” [ISO 15a]

This is true regardless of the nature of this system, as long as it is a “combination of interacting elements organized to achieve one or more stated purposes”, as specified in the main systems engineering standards such as ISO 15288 [ISO 15a] and ISO 29110 [ISO 18a]. In addition, we will use, as in these repositories, the paradigm of “system thinking” as opposed to a Cartesian method of problem solving. The main advantages can be given as follows:

• – consider the system as a whole;
• – consider the entire life cycle of the system [ISO 19];
• – identify the interrelationships among the parts that compose it and also with the system environment.

The predominant role of requirements engineering in system acquisition or development has made it essential to limit errors in this phase. Indeed, missing or not clearly formulated requirements (which are imprecise, ambiguous, etc.) are also problems that must be avoided. Systematic approaches, such as the method we propose in Chapter 2, make it possible to be more exhaustive, more rigorous, and ultimately to better satisfy the client.

Before going any further, it seems essential to define the very notion of requirement in the context of systems engineering. One of the most complete definitions is probably the one found in ISO 24765 [ISO 17b], which summarizes different sources into the following four points:

1. A statement that translates or expresses a need and its associated constraints and conditions – ISO 29148 [ISO 18b].
2. A condition or capability that must be met or possessed by a system, system component, product, or service to satisfy an agreement, standard, specification, or other formally imposed documents – IEEE 730 [IEE 14].
3. A provision that contains criteria to be fulfilled – ISO 14143 [ISO 07].
4. A condition or capability that must be present in a product, service, or result to satisfy a contract or other formally imposed specification – Project Management Body of Knowledge IEEE 1490 [IEE 11].

ISO 24765 also defines the following requirements types: design requirements, functional requirements, implementation requirements, interface requirements, performance requirements and physical requirements.

It may be noted that point 1 of this definition is the one included in the reference standard for systems engineering, ISO 15288 [ISO 15a].

For its part, in its reference book “Discovering and Understanding System Engineering”, AFIS [AFI 98], a member of INCOSE [INC 90], gives a more detailed but similar definition:

“A requirement prescribes a property that is deemed necessary to obtain. Its statement can be a function, ability, characteristic or limitation that a system, product or process must satisfy.” [AFI 12a]

The value of the requirement is linked to the quality of its drafting or even its formalization. Quality criteria must be verified to ensure the relevance of the requirements. Various examples are available (ISO 29148, ISO 29110, AFIS, etc.), often referred to as SMART (Specific Measurable Achievable Relevant Traceable):

• – Specific:
  • - Only one subject dealt with at a time, precision, rigor.
  • - Unambiguous: only one possible interpretation.
  • - Pure prescription: it concerns the “what” and not the “how”.
• – Measurable:
  • - Verifiable, validable: methods exist to verify or validate it.
• – Achievable:
  • - Feasible: with the state of the art, on the envisaged horizon.
  • - Realistic: with the constraints of the project (deadline, cost, quality).
• – Relevant:
  • - Consistency: no incompatible requirements.
  • - Completeness: exhaustiveness without more/problem addressed.
• – Traceable:
  • - Identified.
  • - Referenced: origin, document, realization.

Each of these criteria has a different scope depending on the stakeholders involved. This is particularly the case when checking how realistic a requirement is, whether or not designers and directors are already involved in the analysis.

As mentioned above, another element needs to be defined as it plays a key role in the development of requirements: that of s...

Table of contents

• Cover
• Table of Contents
• Foreword
• Preface
• PART 1: Requirements Engineering
• PART 2: Case Study, Application of the Method
• References
• Index
• End User License Agreement