PPI SyEN 87

Dedicated to inspiring and improving the practice of systems engineering

brought to you by

Project Performance International (PPI)

Systems engineering training and consulting for project success

Welcome to the latest issue of PPI SyEN, PPI’s monthly publication filled with informative reading for the technical project professional. In this issue, as well as in tons of archived issues available free at www.ppi-int.com, you will find powerful ideas that may help you prosper in the highly competitive world of systems and product development.

Access a mix of news, quick tips, short reads and deep article content that will help you expand your professional skill set, keep up to date on events and activities of interest, and quite possibly unlock levels of project performance you’ve never before considered possible.

We hope that you find this newsletter to be informative and useful. As the leading provider of systems engineering training worldwide, PPI is passionate about improving project outcomes. Thousands of professionals in aerospace, medical, consumer and other major sectors subscribe to PPI SyEN, as do leading thinkers in academic, government and scientific organizations.

Our editors strive to bring you a diverse range of views and opinions each month, but please know that the views expressed in externally authored articles are those of the author(s), and are not necessarily those of PPI or its professional staff.

Have a topic you would like to learn more about, or possibly ideas you’d like to share with others? We’d love to hear from you! Just email us at syen@ppi-int.info

We would also love it if you shared this issue with others who may benefit, and we encourage you to join our active community on LinkedIn. If a colleague sent you this issue, you can easily receive future newsletters directly by signing-up using the form at www.ppi-int.com. 

Should you no longer wish to receive PPI SyEN for any reason, simply unsubscribe by clicking the link at the bottom of this email.

IN THIS EDITION

1. Quotations to Open On

Read More…

2. Feature Articles

2.1     A Requirement Evaluation Metric for Microsatellite Missions by Marcelo Essado

2.2    Requirements for the Business Aircraft of the Future by Ronaldo Gutierrez

Read More…

3. Additional Articles

3.1    Reuse in Requirement Management for Rail Projects by Aurangzeb Awal

3.2    INCOSE Americas Sector Activities by Tony Williams

Read More…

4. Systems Engineering News

4.1    Johns Hopkins Whiting School of Engineering’s Mapping Tool Tracks Coronavirus Outbreak in Real Time

4.2     The Coronavirus: What You Can Do to Help in Simple Terms

4.3     Message from INCOSE President Regarding COVID-19

4.4    IEEE Adopts New Diversity Statement

4.5    Mapping Potholes by Phone

4.6    Using Panarchy to Change a Complex System

4.7    MITRE (USA) Unveils Laboratory Focused on Autonomous Technology

4.8    How Can We Combat Climate Change?

4.9    Order of the Engineer Celebrates 50th Anniversary

4.10    Standards Development: ISO24641 Methods and Tools for Model-Based Systems

Read More…

5. Featured Organizations

5.1    MITRE

5.2    American Society of Agricultural and Biological Engineers

5.3    Caspian Engineers Society

Read More…

6. News on Software Tools Supporting Systems Engineering

6.1    The REUSE Company Maps out INCOSE 2019 Rules with SE Suites Metrics

6.2    New Web Interface for Requirements Management ALM Solution

6.3    Leverage Standardized Encryption and Licensing for Modelica Libraries

Read More…

7. Systems Engineering Publications

7.1    Diversity in Systems Engineering INSIGHT Available

7.2    Illuminating the world – the Choice of the Era to Rise above the Atmosphere

7.3    An Elegant Puzzle: Systems of Engineering Management

7.4    Personal Information Security & Systems Architecture: Techniques for Personally Identifiable Information Management in a Business

7.5    Visual Models for Software Requirements – Developer Best Practices

7.6    Software Requirements – Developer Best Practices (3rd Ed)

7.7    DevOps: A Software Architect’s Perspective

Read More…

8. Education and Academia

8.1    CIMdata and SMS ThinkTank Announce New Systems Modeling & Simulation Certificate Program

8.2    The Roux Institute of Northeastern University

Read More…

9. Some Systems Engineering-Relevant Websites

Read More…

10. Standards and Guides

10.1    ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering

10.2    The New International System of Units (SI): Quantum Metrology and Quantum Standards

10.3    The IEEE Software & Systems Engineering Standards Committee (S2ESC)

Read More…

11. Some Definitions to Close On

11.1    DevOps

11.2    Stakeholder

11.3    Multi-Factor Authentication (MFA)

Read More…

12. Conferences and Meetings

12.1    27th International Conference on Systems Engineering [25 – 27 August, 2020 – Las Vegas, NV (USA)]

Read More…

13. PPI and CTI News

Read More…

14. PPI and CTI Events

Read More…

15. Upcoming PPI Participation in Professional Conferences

Read More…

1. QUOTATIONS TO OPEN ON

“Of course, we want to be agile. That doesn’t mean proceeding in ignorance of what is already known!”

Robert John Halligan

I have no special talents. I am only passionately curious.”

Albert Einstein

With the right mindset, what is each of us capable of?”

Wim Hof

2. FEATURE ARTICLES

2.1 A Requirement Evaluation Metric for Microsatellite Missions

by

Marcelo Essado

EMSISTI Space Systems & Technology

Email: marcelo.essado@emsisti.com.br

Abstract

Available data demonstrates that defective requirements are a dominant cause of cost and schedule problems on space programs. This article presents results obtained from the study of a Requirement Evaluation Metric applied on a small technological microsatellite. The requirement evaluation metric is a structured methodology for measuring the quality of requirements, individually and collectively, by means of ten individual quality metrics. The paper describes the satellite mission, the Requirement Evaluation Metric used, and how it was applied. In addition, the requirements engineering process is shown in terms of the problem statement. The main contribution of this study is the establishment of a Requirement Evaluation Metric on a systematic approach to refine a critical satellite requirements operation for space applications, called Conformance and Fault Injection for Requirement Refinement (COFI-ref).

Copyright © 2020 by Marcelo Essado. All rights reserved.

1. Introduction

It is known that the software development process is conceptually an abstract form of model transformation. It starts from a stakeholder model requirements analysis and continues through the system design model11, 12. The success or failure of such transformation depends mainly on the initial model that captures the user needs. The same process occurs to acquire the user concerns for a space mission operation. Advanced satellite systems require new approaches not only in the area of the satellite itself but also in the field of operations2, 3, 4. This paper presents a Requirement Evaluation Metric applied in the early phases of a technological microsatellite requirements as part of the Verification and Validation (V&V) plan. The evaluation metric used, called Requirements Structural Model, was presented for the first time by Robert J. Halligan10. The goals of the Program are: (a) generation of technological innovations for the aerospace sector; (b) strengthening of national industry; (c) dissemination of knowledge; and (d) training of human resources. This task is performed through conceptualization, design, and development of small satellites and applied research related to the national interests. The COFI-ref (Conformance and Fault Injection for Requirement Refinement) approach is based on a testing methodology called COFI (Conformance and Fault Injection). As part of the ISVV (Independent Software Verification and Validation) process, the results with the application of the COFI methodology have surprised the mission management, because many errors were found1, 2. However, the errors were found only in the latter phases. Thus, a variation of COFI, the COFI-ref was co-developed by the author, to be applied in early phases of a technological microsatellite as part of the mission requirements refinement. With this opportunity, it was possible to demonstrate the effectiveness of the designer’s attention to incomplete, ambiguous, and incorrect requirements that occur during the software development process, and to operations definitions. Finally, the Requirement Evaluation Metric was applied during the COFI-ref in order to measure the requirement refinement provided by this approach.

2. Microsatellite Mission Concept

The System Engineering Team is responsible to produce the needed documents at the system-level, and through a formal review delivery, the respective documents to the V&V Team, as the starting point of the refinement process, part of the COFI-ref approach depicted later. The Document Requirements Definition (DRD) is the input for the refinement process.

The microsatellite mission is related to an environmental data collection system, and it can be applied to agriculture and animal creation control and monitoring. Figure 1 shows the concept of the space and ground segments.


Figure 1: Small Satellites for Environmental Data Collection, Agriculture, and Animal Creation Control and Monitoring (Source: http://sinda.crn.inpe.br/PCD/SITE/novo/site/index.php)

This section describes the part of the DRD that contextualizes the problem domain. The mission cycle comprehends the following phases:

  1. Assembly, Integration, and Test Phase (AITP);
  2. Launch Readiness Phase (LRP);
  3. Pre-launch Phase (PLP);
  4. Launch and Early Orbit Phase (LEOP);
  5. Commissioning Phase (CP);
  6. Operational Phase (OP); and
  7. Decommissioning Phase.

As part of the Mission Description Document the Microsatellite has 8 operational modes:

  1. Launch Mode;
  2. Survival Mode;
  3. Testing Mode;
  4. Alignment Mode;
  5. Payload Mode;
  6. Experimental Mode;
  7. Operational Mode; and
  8. Propulsion Mode.

Figure 2 shows the operational modes and the relationship with Mission Phases. For example, the Launch and Survival Modes is activated in Launch and Early Orbit Phase as well Testing Mode will be activated in the Commissioning Phase, and so on.


Figure 2: Operation Modes and Mission Phases activation

The Operation Modes are described below in order to better understand the requirement evaluation approach.

  • Launch Mode – During the launch, the s/c (spacecraft) stays in launch mode. It fulfills the launch provider requirements: there is no electric power supply for all subsystems and all mechanisms are securely locked.
  • Survival mode – After ejection, the s/c changes into the survival mode. In this mode, the attitude of the s/c and its spin rate is undefined. In this mode all payloads (operational and experimental) are turned off. In this mode the task of the s/c is to keep a positive energy budget over one orbit and to ensure its ability to communicate well. In the case of failure or malfunction that affects the whole s/c, it switches into the survival mode automatically, independent of the current mode.
  • Testing mode – From the survival mode, the s/c switches into the testing mode. This mode tests all the subsystems and payloads before passing the s/c to the customer. The testing mode provides all the functions of the survival mode, and in this mode the first telecom and data will be received. After this mode, the s/c can change to the alignment mode or the payload mode. Starting from this mode, it also can be decommissioned.
  • Alignment mode – The alignment mode is for de-tumbling the s/c and aligning it to specified orientations in the flight coordinate system. It is an intermediate mode from the Testing mode to the Payload mode, the Experimental mode, the Operational mode, or the Propulsion mode.
  • Operational mode – In this mode, the experimental payload is turned off and just the operational payload is working, in addition to the subsystems.
  • Propulsion mode – The Propulsion Subsystem is used for de-orbiting and therefore belongs to the Disposal Phase.
  • Payload mode – In this mode, achieved from Alignment mode by ground command, all satellite subsystems including the payload, but excluding the possible propulsion system, are in their final operating configuration. The mission technological data is being collected and transmitted to Earth during visible passes.
  • Experimental mode – In this mode, besides the subsystems, just the experimental payloads are working. This mode provides time to do experiments and to test, for example, the new onboard computer.

3. COFI-ref Approach

The COFI testing methodology1, 2, 14 consists of a systematic way to create test cases for reactive systems. The system to be tested is modeled in Mealy machines. In COFI the system behavior is partially represented in state models where transitions represent inputs and outputs of the interfaces. The main steps of the COFI-ref approach are:

  1. DRD Acquisition,
  2. Identification,
  3. State-Based Modeling, and
  4. Requirement Refinement.

For COFI Methodology the steps are Identification, State-Based Modeling, and Automatic Test Case Generation where steps 2 and 3 were reused on COFI-ref.

The DRD (Document Requirements Definition) is the input of the COFI-ref. In the first step, the team in charge of the system specification, prior to a project review, provides the DRD for the COFI-ref team. This is what we call “DRD Acquisition”. The second and third steps were extracted from the standard COFI methodology. The tasks involved in the second step, Identification, are:

  1. Identify the services that a user recognizes;
  2. Identify hardware faults that can occur (and that system shall resist);
  3. Identify the events (inputs) and reactions (outputs) of the system.

For step 3, we have to create partial models based on Finite State Machines. The tasks involved are to define, for each Service previously created:

  1. Normal Operation Mode;
  2. Specified Exception;
  3. Sneak Paths; and
  4. Fault Tolerant.

For the last step, the Requirement Refinement represents the refinement itself requiring the execution tasks:

  1. State Models analysis, based on its transitions;
  2. Question elaboration; and
  3. Requirements modification.

For details of the COFI-ref approach and results, see previous works13, 14.

4. Requirement Evaluation Metric

Requirements quality, in order to satisfy the user needs and system performance, should follow the same criteria no matter the area or description being written about. That is, the requirements must, in their expression, exhibit certain attributes as quality factors10, 13. Those quality factors can be classified and are defined as follows:

  1. Correctness: refers to an absence of errors in the statement of the requirement;
  2. Completeness: refers to the quality that the requirement contains all of the information that satisfies constraints and conditions to enable its implementation and verifying process;
  3. Consistency: requires that the requirement not be in conflict with any other, nor an element of its own structure;
  4. Clarity: requires that the requirement be readily available and understandable without semantic analysis;
  5. Non-ambiguity: requires that there is only one semantic interpretation of the requirement;
  6. Connectivity: refers to the property whereby all of the terms within other requirements are adequately linked in terms of words and definitions;
  7. Singularity: refers to the property that the requirement cannot sensibly be expressed as two or more requirements having different meanings, like verbs or objects;
  8. Testability: refers to the existence of a finite and objective process with which to verify that the requirement has been satisfied;
  9. Modifiability: requires that any change in the requirement can be made completely and consistently in order to obey the previous criteria; and
  10. Feasibility: requires that a requirement be able to be satisfied within natural physical phenomena and that it applies to the project.

The Requirement Evaluation Metric is based on those criteria, once it is possible to establish a measurement to characterize the quality and quantify the requirements. The metric is called Requirement Structural Model and it was developed by Robert J. Halligan10. Requirements are most commonly expressed as natural language statements, although graphical and formal mathematical requirements languages are widely used in many types of system modeling. The author indicates that for natural language types of expression, requirements quality metrics may be developed through the parsing of each requirement statement into the elements of a structural model of a template. Table 1 shows one example of our technological microsatellite mission system requirement parsed into the template. This procedure was used in all system requirements evaluated by the COFI-ref approach13.

Original Requirement:

Alignment mode –The alignment mode is for de-tumbling the spacecraft and aligning it to specified orientations in the flight coordinate system. It is an intermediate mode from the Testing mode to the Payload mode, the Experimental mode, the Operational mode, or the Propulsion mode.

Table 1 (A): Requirement Structural Template

Table 1 (B): Requirement Structural Template

The author says that a strong requirement shall have each applicable element of the requirement (presented in Table 1), and the requirement overall, satisfying each of the quality factors described earlier. This ideal provides a basis of the development of requirements quality metrics. The basis for the development of requirement quality metrics is defined below:

IRQ – Individual Requirement Quality

This metric is applicable for a single requirement and has to be numbered between 0 and 1, where 1 represents a ‘perfect’ requirement and 0 (zero) a totally defective one. The metric is developed through a classification and the parsed version of the requirement, following the following steps:

  1. To determine which of the possible seven elements of the structure are applicable and assigning value of 1 to each applicable element;
  2. To assess each element of the parsed requirement against the quality factor criteria, and scoring each applicable element as 1 (satisfactory) or 0 (unsatisfactory). An element may be unsatisfactory because it is missing, or because it is defective in some other way;
  3. To calculate the metric by dividing the sum of the applicable element values into the sum of the element scores.

IQF1 – IQF10 – Individual Quality Metrics

Ten individual quality factors correspond to the ten requirement quality factors as follows:

IQF1 – Correctness;

IQF2 – Completeness;

IQF3 – Consistency;

IQF4 – Clarity;

IQF5 – Non-Ambiguity;

IQF6 – Connectivity;

IQF7 – Singularity;

IQF8 – Testability;

IQF9 – Modifiability;

IQF10 – Feasibility.

These metrics assume, for an individual requirement a value on the unit interval [0,1] depending on whether the requirement overall has a defect of type 0 (zero) or not (1). The application of this metric follows the following steps:

  1. To classify the requirement statement according the eight elements presented in Table 1 earlier;
  2. To assign, for each of the elements identified on the previous step, 1 if the statement presents the element or 0 (zero) if not;
  3. To analyze each of elements identified against the ten quality factors and score the requirement to 1 if its correct and 0 (zero) if not;
  4. To evaluate each element identified on step (a) against the ten quality factors and score to 1 if it is satisfactory or 0 (zero) if not;
  5. To calculate the Individual Requirement Quality for each requirement dividing the sum of the elements with the sum of the score.

Requirements which have been omitted may be accounted for by estimating an omission ratio for each requirement that is present. The omission ratio is the number of new requirements that would be created if all possible areas of omission suggested by the requirement that is present were pursued to resolution. The omission ratio must be constructed such as to support aggregation of requirements having different omission ratios.

The quality metrics for a set of requirements correspond to, and are produced from, the individual metrics, as follows (for n requirements):

RQ – Requirements Quality


Equation (1)

QF1 – Correctness

Equation (2)

QF2 – Completeness

Equation (3)


Where:

  1. n is the total of requirements evaluated;
  2. QF2 can be negative, once take into account the omission ratio;
  3. QF3 to QF10 are derived as for QF1.

Table 2 illustrates the construction of the Requirement Structural Model based on parsing of the original requirement statement presented earlier.

Table 2 (A): Construction of Requirement Quality Metrics.

Table 2 (B): Construction of Requirement Quality Metrics.

The following section presents the results obtained applying the Requirement Structural Model to the technological Microsatellite system requirements.

5. Application of Requirement Quality Metrics

The Requirement Structural Model was applied to system requirements during the earlier phases of the Mission Requirements Definition. This procedure was used in a way to measure the quality of the COFI-ref refinement approach.

This section shows the results that were achieved applying the Requirement Structural Model to the Document Requirement Definition (DRD) version 1.0, and then to version 1.1, right after the COFI-ref approach.

Table 3 presents the results obtained by applying the Requirement Structural Model to each version of the DRD. The first and second columns are the quality factors acronym and its name. The third and fourth columns are the mean obtained for each version of the DRD calculated using Equation (1), derived above.

Table 3: Requirement Structural Model results

With these results we can deduce:

  1. That there is a considerable increase in the quality factors value between the DRD versions;
  2. The success of applying the Requirement Quality Metrics.

To better understand the results, a discussion of each quality factor is needed as follows:

QF1 – Correctness

This attribute evaluates the absence of errors in the statement of requirement, in terms of all quality factors and/or grammatical ones: that is, the DRD 1.0 shows that the set of requirements was incorrect while the new version, DRD 1.1, have a considerable improvement.

QF2 – Completeness

This attribute evaluates if the requirement satisfies all of the information to enable the condition of its implementation and verifying process. For DRD version 1.0, the negative value obtained has its origin in omission ratio. In other words, in this version of DRD there were some requirements that are not complete, generating a high score of omission ratio, which did not happen on DRD version 1.1.

QF3 – Consistency

This attribute evaluates if the requirement is not in conflict with any other, nor an element of its own structure. The result shows that COFI-ref approach was able to identify precisely the elements in the requirement statement.

QF4 – Clarity

This attribute evaluates if the requirement is understandable in terms of semantic analysis. The result shows that COF-ref approach could improve the requirement statement. This was possible once some of the DRD 1.0 requirements have been divided into smaller ones.

QF5 – Non-Ambiguity

This attribute evaluates if the requirement is only one semantic interpretation. The result shows that the increment of 0.3 was possible because of QF4, once one requirement statement on DRD 1.0 generates two or more requirements.

QF6 – Connectivity

This attribute evaluates if all terms within other requirements are adequately linked. The increased value of the result was possible because after COFI-ref approach, the requirements were better classified into the eight elements, as shown is Table 1.

QF7 – Singularity

This attribute evaluates the property of the requirement to be expressed in two or more requirements with different meanings. The increase in its value shows that the requirement statement can be more accurately classified into the eight elements, as shown is Table 1.

QF8 – Testability

This attribute evaluates if the requirement can be properly verified. This is a significant result, once the COFI-ref approach is part of a Verification & Validation technique. The value obtained on DRD 1.0 is higher than DRD 1.1 because of two factors: (a) new requirements were created in this last version, and (b) some expression like “to be defined” was elaborated.

QF9 – Modifiability

This attribute evaluates that requirement can be made completely and consistently, in accordance with the previous quality factor. The increase in value of DRD 1.1 was not higher because of the same factors presented on QF8.

QF10 – Feasibility

This attribute evaluates if the requirement is able to be satisfied within physical phenomena and applies to the project. The improvement on DRD 1.1 shows that this attribute is directly proportional to the understanding of the requirement in terms of all quality factors.

Figure 3 presents the evolution of system requirements between DRD versions. The negative value on DRD 1.0 was calculated using Equation (3), which considers the sum of omission ratio. Through this point of view, we can clearly conclude that DRD 1.1 remained in the unitary interval [0,1], showing that COFI-ref approach improves the quality of system requirements, according to the Requirement Structural Mode.


Figure 3: System Requirements evolution through Requirement Quality Metric used.

6. Conclusions

This article has provided the results obtained by applying a Requirement Evaluation Model to system requirements of a technological microsatellite.

It was shown that the Requirement Structural Model can be easily applied to evaluate requirements qualities; also, it can be extended to all phases of a system life-cycle. In addition, the COFI-ref approach has been successfully applied to refine requirements using formal language13. The refinement is based on the grammar of the language that it is applied. Many authors describe the refinement through some mathematical formalism. However, one of the COFI-ref approach concerns is hidden in the mathematical formalism and guarantees that these properties still be followed by the use of Finite State Machines.

The cost of implementing these metrics is suitable – according to Halligan10 a reasonable cost for implementing metrics is approximately two percent of the cost of the total requirements engineering effort.

The lessons learned indicate that the more the system analyst is trained to achieve additional effectiveness, the better the results obtained by COFI-ref. In other words, the analyst must have at least an intermediate knowledge concerning the approach and techniques such as formal methods, automata theory, analysis, and system development. Requirements management benefits substantially from the use of computer-based tools which facilitate, in particular, efficient text handling, rigorous requirements allocation, and the creation and maintenance of peer and parent-child relationships for requirements traceability purposes. Halligan10 has shown that metrics prove to be most easily calculated when a CASE environment is used for those other aspects of requirements management.

Acknowledgements

The author is grateful to the Brazilian Space Agency (AEB), Brazilian National Institute for Space Research (INPE), Dr. Ana Maria Ambrosio from INPE and EMSISTI Space Systems & Technology for their support.

References

1 Ambrosio, A. M.; Martins, E.; Vijaykumar, N.L.; de Carvalho, S.V. “A Conformance Testing Process for Space Applications Software Services.” JACIC – Aerospace Computing, Information, and Communication, Vol.3, N.4, pp.146-158. USA: American Institute of Aeronautics and Astronautics (AIAA), April 2006.

2 Ambrosio, A. M.; Mattiello-Francisco, M. F.; Martins E. “An Independent Software Verification and Validation Process for Space Applications.” In: CONFERENCE ON SPACE OPERATIONS 9. (SPACEOPS 2008), 2008, Hidelberg. Proceedings… 2008. p. 9. CD-ROM. (INPE-15303-PRE/10112).

3 Best Practices Working Group of the Space Operations and Support Technical Committee (SOSTC) of the American Institute of Aeronautics and Astronautics. “Satellite Mission Operations Best Practices.” AIAA Space Operations and Support Technical Committee (SOSTC). April, 2003

4 ECSS-E-10 Part 1B, Space Engineering – System Engineering – Part 1: Requirements and Process. 18 November 2004.

5 ECSS-E-40 Part 2B, Space Engineering – Software – Part 2: Document requirements definitions (DRDs). 31 March 2005.

6 ECSS-E-70 Part2A, Space Engineering – Ground systems and operations – Part 2: Document Requirements Definitions (DRDs), 2 April 2001.

7 ECSS-E-ST-70-11C, Space Engineering – Space segment operability. 31 July 2008.

8 ECSS-M-ST-10C, Space Project Management – Project Planning and implementation. Revision 1, 6 March 2009.

9 Essado, M, et. al. Montagem, Integração e Teste das Interfaces Eletrônicas de Controle e Comunicação de Dados de um Microssatélite Nacional. ISBN: SIGE (Simpósio de Aplicações Operacionais em Áreas de Defesa), 24 a 26 SET de 2019.

10 Halligan, R. “Requirements Metrics: The Basis of Informed Requirements Engineering Management.” In: COMPLEX SYSTEMS ENGINEERING AND ASSESSMENT TECHNOLOGY WORKSHOP, Proceedings of the Naval Surface Warfare Center, Dahlgren, Virginia, 1993.

11 IBM Corporation. “Get It Right the First Time: Writing Better Requirements.” 2008.

12 IEEE Std. 830-1998. “IEEE Recommended Practice for Software Requirements Specifications.” IEEE Computer Society, 1990.

13 Morais, M. H. E. Sistemas Espaciais: Refinamento de Requisitos em Missões de Satélites. Novas Edições Acadêmicas, 123 páginas, ISBN-10: 978-3639837841, Julho de 2015.

14 Morais, M. H. E, Ambrosio, A. M., “A new model-based approach for analysis and refinement of requirement specification to space operations”. SpaceOps 2010 Conference, 2010, Huntsville. SpaceOps 2010 Conference, 2010.

15 Pontes, R. P.; Morais, M. H. E.; Veras, P. C.; Ambrosio, A. M.; Villani E. “Model-based Refinement of Requirement Specification: A Comparison of two V&V Approaches.” COBEM, International Congress of Mechanical Engineering, November 15-20, 2009, Gramado, RS, Brazil.

About the Author

Marcelo Essado has been working with space systems more than 15 years. He is author of the book “Sistemas Espaciais: Refinamento de Requisitos em Missões de Satélites” ed. NEA, 132 pages, ISBN-13: 978-3639837841 (Space Systems: Requirement Refinement in Satellite Missions) and several technical and scientific papers. He has founded two startups, is director of EMSISTI Space Systems & Technology, and a member of the directory board of the Brazilian Civil Aerospace Association. He has served as a reviewer for the Brazilian Rocket and Satellite Universities Competition. Marcelo is a speaker, advisor, and educator with experience concerning space system engineering, artificial intelligence applied for decision driven, digital image processing and control, and business development. He also has been involved in developing social and educational projects.

2.2 Requirements for the Business Aircraft of the Future

by

Ronaldo Gutierrez

Independent Researcher

Email: ronaldo.gutierrez@mail.concordia.ca

The purpose of the article is to elicit a complete set of requirements for the business aircraft of the future. The complete set of requirements is vast, covering several aspects of the aircraft and its context. The article employs guidance from the international standard ISO/IEC/IEEE 29148:2018 to elicit the complete set of requirements. The complete set of requirements includes 57 stakeholder requirements and 101 system requirements. The complete set of requirements provides the foundation to: 1) facilitate the conversation in the systems engineering community concerning eliciting complete sets of requirements in the aerospace sector using traditional text-based requirements; 2) utilize the set of requirements to practice the attributes and characteristics of well-formed sets of requirements specified in the standard; and 3) use the set of requirements as a baseline to understand the scope of Model Based Systems Engineering (MBSE) in the elicitation of a complete set of requirements in the aerospace sector.

Editor’s Note: The standard referenced in this article is featured in the Standards section of this issue of PPI SyEN.

Copyright © 2020 by Ronaldo Gutierrez. All rights reserved.

1. Introduction

People have mobilized around the world since ancient civilizations. The United Nations Department of Economic and Social Affairs (2018) states that 55% of the world’s population lives in urban areas today, and the organization expects the proportion to increase to 68% by 2050. This trend has increased emissions, noise, and congestion in urban areas; thereby, reducing the quality of life or well-being of cities’ inhabitants. Sustainable mobility is a solution to alleviate the challenge of congestion, emissions, and noise in day-to-day transportation of people in the smart cities of the near future.

People have used land, air, and water means to move effectively and efficiently in and between cities. Thus, land, air, and water composed the whole mobility system. As the capacity of land and water transportation has become saturated, innovations in air mobility can decrease the stress of emissions, noise, and congestion. Studies in air mobility solutions suggest that a niche market of people (e.g., top management, other managers, and technical/sales/service staff) in each city is willing to travel quickly, safely, securely, sustainably, comfortably, and connectedly in their day-to-day journeys (National Business Aviation Association, 2014); so, they need a new kind of business aircraft. This business aircraft must fly safely, securely, and sustainably within smart cities and near airports in order to provide all the possible trips that the niche market needs to perform without interrupting its daily work and productivity.

The lack of runways inside cities leads to the adoption of vertical take-off and landing (VTOL) aircrafts using heliports or other landing pads (e.g., vertiports) as the preferred alternative to travel compared to traditional aircraft (Nichols & Dyment, 2019). In addition, an increased demand of flight for the next 10-20 years is forecast (Meredith, 2019). This demand puts at risk the ability to recruit pilots; thus, an autonomous unmanned aircraft is a feasible solution to enable air trips in cities. Connection with the environment improves the aircraft automation capability in order to assure the safe and pleasant trips of people. An electric power system reduces emission and noise in cities during the trips. Therefore, the business aircraft of the future is an e-VTOL vehicle that must fly safely, securely, and sustainably, within cities and near airports. For example, we can imagine the aircraft flying in the context of operation in Figure 1.

Wrong requirements lead to significant delays and cost overruns in megaprojects (Flyvbjerg, 2014), for example, imagine the development of the clean sheet design for the e-VTOL business aircraft of the future. Requirements engineering as a research area and a significant practice competency in systems engineering is maturing, but it is not easily accessible to entrants to the profession (Wheatcraft, 2019). To enable the participation of entrants and perhaps to foster their collaboration with matured systems engineers, this article elicits a complete set of requirements for the aircraft of the future; such a meaningful megaproject for 2020 and beyond that has called the attention of the International Civil Aviation Organization (ICAO) (2019a) and the National Research Council Canada (2019).

The article is organized as follows:

  • Section 2 defines the scope of the context of operation to elicit a complete set of requirements for the aircraft of the future.
  • Section 3 defines the meaning and context of the complete set of requirements.
  • Section 4 overviews the methodology to elicit set of complete requirements.
  • Section 5 employs the methodology to state the elicited complete set of requirements.
  • Section 6 briefly compares the employed methodology against others.
  • Section 7 summarizes and concludes the article.


Figure 1: Context of operation: smart city (ciena, 2019), airport (Joint Planning and Development Office, 2007), smart city near airport (Joint Planning and Development Office, 2010), and e-VTOL Nexus (Bell flight, 2019a).

2. Context of Operation

Figure 1 describes the context of operation for the aircraft. The major elements in the context of operation are the smart city, the smart airport, the path from the city to the airport or vice-versa, and the aircraft. The remainder of this section describes each element with the purpose of creating a background to understand the requirements. The context of operation is the source to elicit the complete set of requirements.

2.1 Smart Airports

The aircraft shall transport passengers and cargo from/to airports. Systems engineers need to understand the role and evolution of airports to define safety, security, and sustainability (S3). Airports are the nexus at which passengers transfer between air and surface modes of travel. As a system, an airport comprises the 3 sub-systems in Figure 2: urban access/egress, landside, and airside. Urban access/egress moves passengers and cargo to and from airports (bottom of Figure 2). Landside prepares passengers and cargo for air transportation (middle of Figure 2). Airside oversees the physical movement of aircraft at airports (top of Figure 2).


Figure 2: The airport system (MacKinnon, Sowden, Russell, and Stewart, 2004, p. 100)

The International Air Transport Association (IATA, 2015) has envisioned the airport of the future. The airport of the future brings together and coordinates in the airport space 10 areas: 1) airport infrastructure design, 2) security, 3) passenger, 4) cargo, 5) ground operations, 6) baggage, 7) financial systems, 8) information and technology, 9) safety and flight operations, and 10) environment.

A smart airport facilitates making a reality the airport of the future. As a result, a smart airport enables the 10 areas in the airport of the future. The smart airport intends to cover the entire airport space to provide a seamless end-to-end journey for passengers, baggage, cargo, and aircrafts (IATA, 2019). To achieve this goal, the initiative for a smart airport must work together with the principal organizations in Figure 3.

This article does not investigate any existing regulation concerning flying near an airport or a smart airport, but it does try to highlight the importance of such regulations. The article expresses the notion that the management of safety comes from the definition of risk areas. For example, bird strike accidents in the past have led regulators to define hazardous areas near airports in order to avoid the reoccurrence of the incidents. Lessons learned from this example can be extrapolated for safety relative to the context of new aircraft flying near smart airports. Flying near smart airports shall respect and interoperate with the initiatives in the 10 areas, while also ensuring safety in the air transportation system. Flying near smart airport is a necessary capability for the business aircraft of the future, as it enables the necessary flow of passengers and cargo between smart cities to conduct business.


Figure 3: Examples of organizations affected by the operation of a large airport (MacKinnon et al., 2004, p. 101)

2.2 Smart Cities

It is not possible to define S3 of a transportation system without understanding the role and evolution of cities. Cities are places where a large number of people live and work. In addition, cities are hubs of government, commerce, and transportation. At the turn of the year 2000, there were 371 cities with 1 million inhabitants or more worldwide. By 2018, the number of cities with at least 1 million inhabitants had grown to 548, and in 2030, a projected 706 cities will have at least 1 million residents. The biggest cities in the world are often called megacities. These cities have more than 10 million inhabitants. Globally, the number of megacities is projected to rise from 33 in 2018 to 43 in 2030. The data are summarized Figure 4.


Figure 4: World’s population by size class of settlement, 2018 and 2030 (United Nations, 2018)

The purpose of a city is to provide the infrastructure necessary for people to live and work. The transportation system, buildings & housing, public space & recreation, power, communications, natural environment (e.g., air, soil, and rivers), water, food, sewage/waste, and government (e.g., governance, police, hospitals, and other bodies) compose the infrastructure. The infrastructure embodies the anatomy of the city. The infrastructure shall provide the capacity to serve the needs of the forecasted growing population. Smart cities try to optimize the use of the infrastructure intelligently.

Smart cities are associated with the fourth industrial revolution trend (Schwab, 2016). The term smart refers to digitization, enabled by cutting-edge technologies. As a result, smart cities refer to highly digitized cities equipped with cutting-edge technologies. According to Schwarz-Herion (2020), the cutting-edge technologies for modern cities are: 1) algorithms, 2) artificial intelligence, 3) autonomous vehicles, 4) big data, 5) blockchain, 6) CCTV (closed-circuit television) surveillance, 7) cloud computing, 8) drones, 9) 5G, 10) the internet of things (IoT), 11) LED light bulbs, 12) robots, 13) sensors, 14) smart grid, 15) smart meters, and 16) wearable devices.

The cutting-edge technology in smart cities seeks to improve the well-being of people. The improvement must be evident in the 3 pillars that affect our day-to-day journeys. These pillars are 1) economy, 2) environment, and 3) society and culture. Smiciklas, Prokop, Stano, and Sang (2017) define specific key performance indicators for smart cities.

Smart cities have the interactions of the (IoT), robotics, and people. Today, there are more connected devices (aka IoT) in the world than people coming in infinite forms, such as smart building technologies intended to monitor and manage energy usage, and connected cars expected to anticipate and avoid collisions (World Economic Forum, 2018, p. 18). By 2020, the number of IoT devices is forecasted to exceed 20 billion, enabled by continued technological advances and the plummeting costs of computing, storage, and connectivity. The IoT provides the ability of being accessed and controlled remotely, but it also has vulnerability to cyberattacks and the potential for security breaches that could cause serious harm in the ecosystem. The S3 of the aircraft is also vulnerable to such attacks.

Flying within smart cities means becoming part of their transportation system. An aircraft as part of the transportation city shall provide mobility demands for people and cargo. As a result, the operations of the aircrafts flying in smart cities shall align with the purpose of the city. Defining the meaning of such alignment is part of requirements engineering, which should respect the 3 pillars: 1) economy, 2) environment, and 3) society and culture. This article does not intend to fully understand the alignment. However, the successful business aircraft of the future must satisfy the need to align with the purpose of the served cities as system engineers evolve the design process.

2.3 Business Aircraft of the Future

It is not possible to define S3 of a transportation system without understanding the role of business aviation, the evolution of aircrafts and their technologies, and the organizational abilities to create the aircrafts. A business aircraft supports the activities in the business aviation sector. The sector concerns transport passengers or goods as an aid to the conduct of their business (International Business Aviation Council, 2019). Business-aircraft operations offer businesses the convenience of flexible scheduling and access to small airports (MacKinnon et al., 2004, p. 90).

The business aircraft of the future is an e-VTOL vehicle, which stands for electrical vertical takeoff and landing. The electrical component can power the aircraft in full (all electric) or complement a hybrid electric propulsion system with other types of engines (e.g., gas turbine) to provide the operation of the aircraft (Hardeman, 2020). Different engine types have powered aircrafts during history of civil aviation. Aircraft power plants were exclusively internal-combustion piston engines until the 1930s (MacKinnon et al., 2004, p. 75). Piston engines are categorized by cylinder configurations into radial engines and horizontally opposed engines (MacKinnon et al., 2004, p. 78). During the 30s, gas-turbine engines were developed, offering greater power while being lighter, more efficient and requiring less maintenance than piston engines (MacKinnon et al., 2004, p. 75). Gas turbine engines are categorized into turbojets, turbofans, turboprops, and turboshafts (MacKinnon et al., 2004, p. 78). Economic and environmental pressures have influenced gas-turbine efficiency developments since these engines first entered commercial operations: 1) reducing fuel consumption and environmental impacts, 2) thrust-to-weight ratios, 3) durability (including ability to cope with foreign-object ingestion, 4) controlling engine-operating parameters, 5) reducing noise-emission levels, and 6) reducing exhaust emissions (MacKinnon et al., 2004, p. 80). The electrical power system in an e-VTOL aircraft is probably the next generation propulsion system for the aircrafts of the future. Thus, this explains why the business aircraft of the future is an e-VTOL.

An e-VTOL business aircraft supports the smart traffic initiative to meet the sustainable goals expected from the smart cities of the future (Schwarz-Herion, 2020). The world e-VTOL aircraft directory that started in 2016 lists more than 220 products classified as vectored thrust (86), lift + cruise (30), Wingless – multicopter – (52), hover bikes/personal flying devices (41), and electric rotorcraft (17). Table 1 expands the classes of e-VTOL aircrafts and defines the classes of e-VTOL aircrafts with respective examples.

According to ICAO (2019b), e-VTOL aircrafts will be in service during the period 2020-2025. ICAO defines that e-VTOL aircrafts are expected to have seat capacities from 1 to 5, MTOWs between 450 and 2200 kg, and projected flight ranges from 16 to 300 km. These aircrafts could also consider electrical and hybrid power systems technologies. According to ICAO, these technologies have been researched for general aviation/recreational aircrafts, traditional sized business and regional aircrafts, and large commercial aircrafts.

The e-VTOL aircraft connects to its environment. The meaning of a connected e-VTOL can be inferred from the definition of a connected vehicle. A connected vehicle is a vehicle capable of safe, interoperable networked wireless communication between other vehicles, the infrastructure, and passengers’ personal communication devices to enable crash prevention and safety, mobility, and environmental benefits (Turnbull et al., 2017, p. 49). Hence, a connected e-VTOL business aircraft is an aircraft capable of safe, interoperable networked wireless communication between other aircrafts, the infrastructure (e.g., satellites, the air traffic management system, aircraft health systems monitoring, and inflight passenger business experience), and passengers’ personal communication devices (e.g., laptops and cellphones) to enable crash prevention and safety, mobility, and environmental benefits. Aerospace industry leaders such as Airbus (2019), Boeing (García, 2015), Honeywell (2019), and Southwest Airlines (Peterson, N/A) have acknowledged the role of connectivity in the future aircraft.

Table 1: e-VTOL: classes, definitions, and examples, constructed from The Electric VTOL News™ (2019b)

Besides being connected to its environment, the e-VTOL aircraft must be autonomous to cope with the risk of pilot shortages. ICAO has defined an autonomous e-VTOL aircraft as an unmanned aircraft that does not allow pilot intervention in the management of the flight (National Research Council, 2014, p. 16). A fully autonomous aircraft would be able to operate independently within civil airspace, interacting with air traffic controllers and other pilots just as human pilots were on board and in command (National Research Council, 2014, p. 13). The National Research Council (NRC) indicates that an autonomous aircraft is the next evolution of current automatic systems such as autopilots and remotely piloted (non-autonomous) unmanned aircrafts. The electric VTOL News™ (2019a) lists 61 autonomous e-VTOL aircrafts.

An autonomous aircraft implies the ability of the system (often a machine) to perform tasks that involve dynamically executing a decision cycle in much the same fashion as a human (National Research Council, 2014, p. 14). The NRC suggests that there are different ways to represent the decision cycle, and the OODA loop is one of them. The loop stands for observe, orient, decide, and act. A description of actions in the loop are presented in Table 2. The loop can repeat several times in a second, for example 30 decision cycles per second. Interpreting the discussion by the NRC, autonomous aircrafts have the capability to accomplish a complete mission, which implies the autonomy of lower-level functions (e.g., using flight by wire control systems for stabilization and maneuvering the aircraft).

Table 2: OODA Loop: observe, orient, decide, and act, adapted from National Research Council (2014, p. 15)

A connected and autonomous aircraft integrates the capabilities of an autonomous vehicle and connectivity. The purpose of the integration is to make aviation safer, more secure, more sustainable, and easier to manage. This article does not provide the needed technologies and quantification of the previous capabilities, as systems engineers must evolve them as the design process evolves.

Global partnerships between organizations are at the core of bringing to life an autonomous and connected e-VTOL business aircraft. For instance, Bell Nexus is the result of engaging partners from across the globe, including Safran to build a hybrid-electric propulsion system; Thales to produce the flight control computers; Moog to make the actuation systems; EPS to innovate a battery system; and Garmin to provide the so-called nervous system to tie them all together (Bell flight, 2019b, p. 17). Rolls-Royce is looking for partnerships with airframers and electrical system providers to help commercialize its e-VTOL vehicle (Howard, 2018). Porsche and Boeing announced their joint exploration for the premium urban air mobility market (Vornehm, 2019). New competitors such as Larry Page – Google Cofounder – are also coming to make e-VTOL aircrafts a reality (Harris, 2018). As a result, creating the aircraft of the future is not the task of either traditional airframers, automotive manufacturers, or disruptive IT players; but rather the result of their potential collaboration to bring expertise from different actors.

The business aircraft of the future is the final element that conforms the context of operation to elicit a set of complete requirements. Section 3 defines the meaning of a complete set of requirements and its context.

3. Set of Complete Requirements

This section explains the meaning of the set of complete requirements and its context.

A complete set of requirements provides all of the stakeholders’ needs, and the associated constraints and conditions concerning the measurable qualitative or quantitative attribute that the system of interest (e.g., the aircraft of the future) must meet. When a system of interest satisfies a complete set of requirements, it means that all the stakeholders’ needs are met; therefore, a project is successful when it meets the needs and their associated elicited requirements.

The complete set of requirements for the aircraft of the future covers several entities and the relationships among them. These entities are stakeholders, smart airports, smart cities, the aircraft, and its life cycle. The stakeholders, smart airports, smart cities, and the aircraft were discussed in the previous section. The life cycle of the aircraft covers from conception to retirement. In particular, the concept stage, development, production, utilization, support (maintenance), and retirement define the life cycle of the aircraft. Given the entities, the complete set of requirements also includes the interactions between the entities. The interactions are defined by 10 classes: 1) Stakeholder – Stakeholder, 2) Stakeholder – Smart Airport, 3) Stakeholder – Smart City, 4) Stakeholder – Aircraft, 5) Stakeholder – Concept stage, 6) Stakeholder – Development, 7) Stakeholder – Production, 8) Stakeholder – Utilization, 9) Stakeholder – Support, and 10) Stakeholder – Retirement. The classes define the complete problem space to elicit the set of complete requirements for the aircraft of the future, starting from the most important view in any new product development project (stakeholders).

Now that the meaning of the set of complete requirements and its context has been introduced, the next question to answer is how to elicit the requirements. Section 4 presents the methodology to elicit a set of complete requirements, which answers the question how to elicit the requirements.

4. Methodology: ConOps, OpsCon, and Requirements

This article elicits a complete set of requirements following the guidance by the international standard ISO/IEC/IEEE 29148 (2018). Based on the interpretation of the standard, the methodology in Figure 5 is implemented in the article. According to Figure 5, a methodology to elicit the set of complete requirements shall consider the ConOps (i.e., Concept of Operations), the OpsCon (i.e., Operational Concept), and the requirements. They together provide confidence to organizations that their new products are the right solutions to satisfy the needs and expectations of the stakeholders.


Figure 5: High level methodology to elicit the set of complete requirements

Top management (leaders) in an organization create the ConOps (INCOSE, 2015, p. 51). A ConOps can be implicit in the strategic plan of an organization. ISO/IEC/IEEE (2018) associates the ConOps with the business or mission analysis process. Therefore, developing the ConOps leads to defining the business or mission opportunity, characterizing the solution space, and determining potential solutions that could address a problem or take advantage of an opportunity.

The OpsCon follows the development of the ConOps for the potential solution. ISO/IEC/IEEE 29148 (2018) associates the OpsCon to the stakeholders’ needs and requirements definition process. Hence, developing the OpsCon results in the definition of the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholders in a defined environment.

The elicitation of the set of complete requirements follows the development of the ConOps and the OpsCon. ISO/IEC/IEEE (2018) associates the elicitation of the set of complete requirements to the system requirements definition process. Thus, eliciting the set of complete requirements results in the transformation of the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user.

In synthesis, the activities in the previous three processes must be executed in order to elicit a complete set of requirements. Table 3 defines the activities for each process. ISO/IEC/IEEE (2018) provides further guidance about expected outcomes for each process and tasks for each activity.

Table 3: Detailed methodology to elicit the set of complete requirements: processes and activities constructed from (ISO/IEC/IEEE, 2018)

5. Set of Complete Requirements for the Business Aircraft of the Future

The purpose of this section is to elicit the set of complete requirements for the business aircraft of the future. To achieve this goal, the section introduces three outputs: 1) the developed ConOps, 2) the developed OpsCon, and 3) the elicited set of complete requirements. The remainder of the section provides each output.

5.1 The developed ConOps: business or mission analysis process

The developed ConOps addresses each activity for the business or mission analysis process in Table 3. Thus, the activities are expanded in the remaining of the section.

5.1.1 Prepare for business or mission analysis

Bringing to market a new e-VTOL business aircraft is a risky project with expected profitable products and services. The new aircraft must be more competitive than existing mobility solutions (e.g., helicopters, cars, public transportation and new solutions) in cities. In addition, the new aircraft must provide expected levels of safety, security, and sustainability for the envisioned smart cities of the future. The new aircraft must result in faster journeys and comfortable experiences than competing products within smart cities, from smart cities to smart airports, from smart airports to smart cities and near smart airports in order to delight its customers. The comfortable experiences arise from an easy autonomous flying (e.g., minimum training required), connection to all business support (e.g., internet, speakers, screens, drinks, goods compartment) during the journeys, and a quiet and a spacious high-end interior. Charging the aircraft must not interrupt the comfortable experiences. The saved time and comfort for customers shall translate to profit for the developing organizations and partners.

5.1.2 Define the problem or opportunity space

The aircraft shall be aesthetically appealing to customers driving luxurious (sport) cars (e.g., Bugatti Divo, Aston Martin Rapide A, Audi R8 performance series, Lamborghini Aventador series, Rolls-Royce Phantom, Bentley Mulsanne, BMW i8 Roadster, Tesla Roadster Founder Edition, Mercedes-Benz AMG One and Ferrari SF90 Stradale) affected by congestion and noisy helicopters in their day-to-day city journeys and trips from airports to cities or vice versa. The aircraft shall provide superior performances (e.g., range and speed), comfort for up to 4 passengers, cargo compartments, and faster journeys than these vehicles without compromising safety, security and sustainability in the transportation system.

The acquisition, operational, and maintenance costs of the aircraft should not be lower than luxurious cars but not higher than existing aircrafts. Potential investors expect the business aircraft of the future to yield the highest positive net present value (NPV) forecasted into a life cycle of 10 years, the highest return on investment (ROI) rate, the highest internal rate of return (IRR), the highest profitability index (PI) and the shortest payback period. In short, the business aircraft of the future must generate the greatest possible value to shareholders and investors using the latest technologies.

The aircraft must be electric and possess autonomous technologies to transport safely, securely, and sustainably the passengers and their cargo. The aircraft solution must consider the possibility of providing access to a priority flight path as a service. The systems engineering team must coordinate with regulators to create those services.

The systems engineering team must certify the aircraft faster than helicopters and traditional airplanes. The manufacture of the aircraft must compare to the cost and production timelines of luxurious cars. The aircraft shall enter into service by 2025, so manufacturing shall start by 2023. The aircraft must be maintained and charged without disrupting the daily operations of its customers longer than competing vehicles.

The aircraft shall be named The Disruptor. The Disruptor is the result of an explicit unnoticed combination between art, science, and technology. The Disruptor is all about providing pleasant emotions to the unique personalities of the customers. The form of The Disruptor arises after refining all the necessary functions to guarantee pleasant emotions to its customers. The Disruptor will embrace the principles of a circular economy (ICAO, 2019c, pp. 275-278) during its life and at retirement.

5.1.3 Characterize the solution space

The solution space of the aircraft must anticipate all the life cycle stages to be competitive. The stages include concept, development, production, utilization, support, and retirement. The systems engineering team must identify and consider all the stakeholders. The concept stage must prioritize all the stakeholders willing to share risk with experienced systems engineering execution and superior technological capabilities in autonomy and navigation, connectivity and interoperability, aerodynamics, materials, structure and fuselage, luxurious interiors and comfort, entertainment and business support, power systems (all-electric, electric and gas turbines, or other), electrical system, health management systems, manufacturing systems, certification, training services, and service infrastructures. The concept stage must define the selected partners, technologies, its design process and certification plan, a visual prototype of the e-VTOL business aircraft, and a simulated effective and efficient manufacturing system, operation, support, and retirement.

5.1.4 Evaluate alternative solution classes

The systems engineering team must provide evidence of the evaluation of multiple alternatives. The evaluation of each alternative must consider multiple criteria. Mandatory criteria are acquisition and operational costs, return on investment, safety, security, sustainability, range, speed, superior comfort, usability, saved time, manufacturability, and maintainability. Relevant stakeholders must agree and sign the approval of the evaluation method to rate each criterion, synthesize the evaluation process for each alternative and corresponding solution classes, and the decision-making process to choose a winning alternative. The evaluation of alternatives is applicable to all the life cycle stages.

5.1.5 Manage the business or mission analysis

The development of the ConOps or the business or mission analysis process implies iterations and recursions. As system engineers refine the concept stage, the descriptions in the previous sections can change. The activity of managing the business or mission analysis process demands that system engineers trace each refinement and change, and provide the key information items that they select as baselines as the result of the evaluation of alternatives. The iterations and recursions leading to refinements are beyond the scope of the article; however, readers interested in obtaining guidance in the activity can refer to the international standard (ISO/IEC/IEEE, 2018).

5.2 The developed OpsCon: stakeholder needs and requirements definition process

The developed OpsCon addresses each activity for the stakeholder needs and requirements definition process in Table 3. The activities are expanded in the remaining of the section.

5.2.1 Prepare for stakeholder needs and requirements definition

There are several stakeholders that have an interest in the e-VTOL business aircraft throughout its life cycle. System engineers can initiate the list of stakeholders by considering airport operators, airlines, users of the airport, and peripheral stakeholders, defined as principal organizations in Figure 3. System engineers can complete the list of stakeholders by considering other stakeholders discussed by Moir and Seabridge (2013, pp. 2, 8). The article doesn’t provide a complete list of stakeholders; nonetheless, it points out the great number of stakeholders that have an interest in the e-VTOL business aircraft. System engineers should establish the stakeholders’ intentions through consensus, so that the consented intentions become a common set of acceptable requirements. Methodologies and software tools record and manage this activity in order to validate that the aircraft satisfy the intention of the stakeholders.

5.2.2 Define stakeholder needs

The stakeholder needs for the e-VTOL business aircraft come from the context of use. The main context of use of the aircraft is flying within smart cities and near smart airports. System engineers associate other contexts of use to the life cycle stages that characterized the solution space. Passengers are the principal users in the main context of use of the aircraft. Through an app, passengers schedule a pick-up to the closest location. Passengers expect to embark the aircraft as quickly as getting on a competing vehicle. Passengers embark the aircraft at any time with any mood. Passengers complete the trip at the shortest possible time, but faster than any other vehicles. During the trip, passengers have a drink, listen to music, read, make a call, watch movies, transfer files, or just get relaxed in the aircraft. Passengers expect superior comfort, a pleasant trip to the destination, and to disembark the aircraft with a mood of joy and optimism. This is the journey of passengers travelling alone. The journey of passengers travelling with guests shall also be depicted. This is also the case for the journeys of the remaining stakeholders in their respective contexts of use. Complete needs come from all stakeholders and all contexts of use.

5.2.3 Develop the operational concept

System engineers need operational concepts for the concept, development, production, utilization, support, and retirement stages. Operational concepts provide scenarios for each stage and also for continuity between stages (e.g., from utilization to support and vice versa). Using the context of use as part of the utilization operational concept of the e-VTOL business aircraft, it all starts with the desire to transport a passenger and its cargo. Passengers who can use a smartphone, tablet or laptop, shall be able to schedule a flight and fly the aircraft anywhere in less than 30 minutes. Notoriously, system engineers can create a set of scenarios to understand the operation of the aircraft at four locations: the smart airport, from the smart airport to the smart city, in the smart city, and from the smart city to the airport. While flying in the locations (e.g., refer to Figure 1), passengers expect the aircraft to navigate and interoperate with any enabling system (e.g., air traffic control, telecommunication systems, regulations, other aircrafts, landing pads, connectivity services, and power grids). Several types of accidents could happen in the locations: customers’ injury through aircraft malfunction, collision with the ground, collision with an object, and general disintegration of the aircraft. An abrupt maneuver due to sensor failure or altered sensor readings is a type of aircraft malfunction that can injure customers. Loss of control, mechatronics failure, or the natural environment can cause a collision with the ground. Other objects in the air (e.g., aircrafts and birds) or other objects on the ground (e.g., other aircraft, people, and vehicles) can collide with the aircraft. Structure overload or fire/explosion in the electrical system can disintegrate the aircraft. Those accidents can occur when the aircraft serves its customers at the four locations. Accordingly, requirements must be written to mitigate the risk of the accidents such that passengers experience superior comfort and quicker rides compared to other vehicles in the industry, a pleasant trip to the destination, and disembarking with a mood of joy and optimism.

5.2.4 Transform stakeholder needs into stakeholder requirements

Stakeholder needs have been expressed since the business or mission analysis process. The needs are converted stakeholders’ requirements in this section. The stakeholder requirements are then allocated into a 10 classification of requirements. The employed classifications and allocated requirements are: Stakeholder – Stakeholder (10), Stakeholders – Smart Airport (3), Stakeholders – Smart Cities (4), Stakeholder – Aircraft (16), Stakeholder – Concept stage (4), Stakeholder – Development (5), Stakeholder – Production (5), Stakeholder – Utilization (6), Stakeholder – Support (3), and stakeholder – retirement (1). Each requirement in the classification is given a notation. The resulting stakeholder requirements are 57.

Stakeholder – Stakeholder (SS)

SS1 – Investors expect a profitable project, yielding the highest possible NPV in 10 years, ROI rate, IRR, PI, and the shortest payback period.

SS2 – Investors and acquirers expect that the acquisition and operational costs of the aircraft are lower than luxurious cars but not higher than existing aircrafts.

SS3 – Financial investors expect to provide capital & accept risk in order to gain a share of the expected profits.

SS4 – Knowledge, OEM, and supply chain investors expect to provide systems engineering execution experience, and superior technological capabilities in autonomy and navigation, connectivity and interoperability, aerodynamics, materials, structure and fuselage, luxurious interiors and comfort, entertainment and business support, power systems (all-electric, electric and gas turbines, or other), electrical systems, health management systems, manufacturing systems, certification, training services, and service infrastructures.

SS5 – Investors expect to create a team 1, conformed of business developers, systems engineers, and technical capabilities champions to lead the life cycle of the project.

SS6 – Investors and regulators expect the team to ensure that the aircraft and its technologies will satisfy all safety, security, and sustainability concerns from passengers, airport operators, airlines, users of the airport, city dwellers, investors, and others affected parties during the life of the aircraft.

SS7 – Investors expect that the team and regulators work together to provide access to a priority flight path as a service.

SS8 – Investors, the team, regulators and interested parties expect to agree and sign approval of the evaluation method to rate each criterion, synthesize the evaluation process for each alternative and corresponding solution classes, and the decision-making process to choose a winning alternative.

SS9 – Investors and related stakeholders expect the team to communicate to them the evaluation of multiple alternatives with respect to acquisition, operational, and maintenance costs, return on investment, safety, security, sustainability, range, speed, superior comfort, usability, saved time, manufacturability, and maintainability for all life cycle stages.

SS10 – Investors expect the team to employ methodologies and software tools to record and manage the establishment of stakeholders’ intentions into a common set of acceptable requirements, so that the validation that the aircraft satisfies the intentions of the stakeholders can be checked during the life cycle of the project.

Stakeholders – Smart Airport (SSA)

SSA1 – Passengers expect a pleasant and fast journey near smart airports, from smart airports to smart cities, and from smart cities to airports compared to rival solutions.

SSA2 – Passengers and its cargo expect to interoperate with smart airport space ten areas no less convenient than competing solutions when they are near the smart airport, leaving from the smart airport to the smart city, and arriving to the smart airport from the smart city.

SSA3 – Passengers, airport operators, airlines, users of the airport, city dwellers, investors, and others affected parties expect a safe, secure, and sustainable air transportation system to support the operations of the smart airports (see Figure 2).

Stakeholder – Smart City (SSC)

SSC1 – Passengers expect a pleasant and fast journey in smart cities, from smart cities to smart airports, and from smart airports to smart cities compared to rival solutions.

SSC2 – Passengers and its cargo expect to interoperate with the cutting-edge technologies of smart cities no less convenient than competing solutions when they are in the smart city, leaving from the smart city to the smart airport, and arriving to the smart city from the smart airport.

SSC3 – Passengers, city managers, airlines, city dwellers, investors, and others affected parties expect to comply with regulations for the serviced smart cities when the aircraft is in the smart city, leaving from the smart city to the smart airport, and arriving to the smart city from the smart airport.

SSC4 – Passengers, city managers, airlines, city dwellers, investors, and others affected parties expect a safe, secure, and sustainable transportation system to support the operations of the smart city: economy, environment, and society and culture.

Stakeholder – Aircraft (SA)

SA1 – Passengers, investors, the team, and the rest of affected stakeholders expect that the e-VTOL aircraft is autonomous, connected, safe, secure, and sustainable during all phases of flight (refer to Figure 6).

Figure 6: Phases of flight and their corresponding sub-phases, as interpreted from the U.S. Department of Transportation: Federal Aviation Administration (2012)

SA2 – Passengers expect the aircraft to have goods storage and seat capacity up to 4 passengers.

SA3 – Passengers expect a flight range from 16 to 300 km, to be further investigated depending on the locations to service.

SA4 – Passengers expect the aircraft to provide quicker journeys than competing vehicles.

SA5 – Passengers expect the aircraft to provide comfortable experiences during the phase of flight to delight customers.

SA6 – Passengers expect minimum training to fly the aircraft (e.g., a passenger who can use a smartphone, tablet or laptop, shall be able to fly the aircraft anywhere in less than 30 minutes).

SA7 – Regulators expect MTOW (maximum takeoff weight) between 450 and 2200 kg.

SA8 – Investors expect the team to propose an aircraft that is aesthetically appealing to potential customers driving luxurious (sport) cars (e.g., Bugatti Divo, Aston Martin Rapide A, Audi R8 performance series, Lamborghini Aventador series, Rolls-Royce Phantom, Bentley Mulsanne, BMW i8 Roadster, Tesla Roadster Founder Edition, Mercedes-Benz AMG One and Ferrari SF90 Stradale) affected by congestion and noisy helicopters in their day-to-day city journeys and trips from airports to cities or vice versa.

SA9 – Investors and the team expect the aircraft to bear the name The Disruptor.

SA10 – Investors and the team expect that the aircraft has an explicit unnoticed combination between art, science, and technology.

SA11 – Investors and the team expect the aircraft to provide pleasant emotions to the unique personalities of the customers.

SA12 – Investors and the team expect that aircraft embrace the principles of a circular economy during its life.

SA13 – Passengers schedule the pick-ups by the aircraft to the closest locations through an app.

SA14 – Passengers expect to embark the aircraft as quickly as getting on a competing vehicle during the 24 hours of a day with any mood.

SA15 – Passengers expect to have drinks, listen to music, read, call, watch movies, transfer files, or just get relaxed in the aircraft during the trip.

SA16 – Passengers expect superior comfort, a pleasant trip to the destination, and to disembark the aircraft with a mood of joy and optimism, so that they use the trip to remember the unique and valuable person they are without any inconvenience.

Stakeholder – Concept stage (SC)

SC1 – Investors and the team expect that the form of the aircraft arises after refining all the necessary functions to guarantee pleasant emotions to its customers.

SC2 – Investors and the team expect superior technological capabilities in autonomy and navigation, connectivity and interoperability, aerodynamics, materials, structure and fuselage, luxurious interiors and comfort, entertainment and business support, power systems (all-electric, electric and gas turbines, or other), electrical system, health management systems, manufacturing systems, certification, training services, and service infrastructures compared to rival solutions.

SC3 – Investors and the team expect during the concept stage to define the selected partners, technologies, its design process and certification plan; and create a visual prototype of the e-VTOL business aircraft, and a simulated effective and efficient manufacturing system, operation, support, and retirement.

SC4 – Investors and the team expect that the aircraft follows the principles of the circular economy during the concept stage.

Stakeholder – Development (SD)

SD1 – Investors expect that the aircraft enters into service by 2025.

SD2 – Investors expect that the team and regulators certify the aircraft faster than helicopters and traditional airplanes.

SD3 – Investors and the team expect that the aircraft follows the principles of the circular economy during development.

SD4 – Regulators expect the team to evaluate the consequence on passengers of potential accidents (customer injury through aircraft malfunction, collision with the ground, collision with an object, and general disintegration of the aircraft) at four locations during the phases of flight: the smart airport, from the smart airport to the smart city, in the smart city, and from the smart city to the smart airport.

SD5 – Investors expect the team to mitigate the risk of accidents such that passengers experience superior comfort and quicker rides compared to rival vehicles, a pleasant trip to the destination, and disembark the aircraft with a mood of joy and optimism.

Stakeholder – Production (SP)

SP1 – Investors expect that manufacturing of the aircraft starts by 2023.

SP2 – Investors expect that manufacturing of the aircraft scales up by 2025 at the aircraft entry into service such that the planned NPV, ROI rate, IRR, PI, and the payback period are met.

SP3 – Investors and the team expect that manufacturing of the aircraft must compare to the cost and production timelines of luxurious cars.

SP4 – Investors and the team expect that manufacturing delivers certified aircrafts.

SP5 – Investors and the team expect that the aircraft follows the principles of the circular economy during production.

Stakeholder – Utilization (SU)

SU1 – Passengers expect the aircraft is available when demanded.

SU2 – Acquirers and investors expect that the aircraft charges without disrupting the daily operations of its customers longer than competing vehicles.

SU3 – Investors and the team expect that the aircraft follows the principles of the circular economy during utilization.

SU4 – Passengers expect the aircraft to navigate and interoperate with any enabling system (e.g., air traffic control, telecommunication systems, regulations, other aircrafts, landing pads, connectivity services, and power grids) at four locations during the phases of flight: the smart airport, from the smart airport to the smart city, in the smart city, and from the smart city to the airport.

SU5 – Passengers, regulators, and affected stakeholders expect that the aircraft fly safely, securely, and sustainably during the phases of flight in smart cities, from the smart cities to the smart airport, and from the smart airports to the smart cities.

SU6 – Acquirers and investors expect that the costs of utilizing the aircraft compare to the costs of operating rival vehicles.

Stakeholder – Support (SSu)

SSu1 – Acquirers and investors expect that the aircraft is maintained without disrupting the daily operations of its customers.

SSu2 – Acquirers and investors expect that the aircraft is maintained with similar costs as competing vehicles.

SSu3 – Investors and the team expect that the aircraft follows the principles of the circular economy during support.

Stakeholder – Retirement (SR)

SR1 – Investors and the team expect that the aircraft follows the principles of the circular economy during retirement.

5.2.5 Analyze stakeholder requirements

The analysis of stakeholder requirements is a significant activity in the requirements engineering activity. In particular, this activity intends to study the feasibility, affordability, and the proper composition of the set of requirements as suggested in the standard. System engineers need one more iteration to convert the stakeholder requirements into qualifiable and quantifiable requirements, employing units and ranges (tolerances) as needed to avoid ambiguity. If system engineers fail to do this activity right, there is high probability that the project will delay, exceed costs, or stop in the future. However, the activity is beyond the scope of the article. Readers seeking guidance about the activity can refer to the standard.

5.2.6 Manage the stakeholder needs and requirements definition

The activity “transform stakeholder needs into stakeholder requirements” contains the last version of stakeholder requirement. This activity intends to control changes in the last version of requirements as the project progresses. The article does not cover such changes as they arise when system engineers evolve the design process. Readers seeking guidance about the activity can refer to the standard.

5.3 The elicited set of complete requirements: system requirements definition process

The elicited set of complete requirements address each activity for the system requirements definition process in Table 3. Thus, the activities are expanded in the remaining of the section.

5.3.1 Prepare for system requirements definition

The aircraft and the enabling systems along life of the aircraft are the systems of interest in the article; and the customer, cargo, smart cities, and smart airports are its environment. The main function of the aircraft is to provide people and their cargo an autonomous, connected, safe, secure, and sustainable flight within smart cities and smart airports along the aircraft movements. The operation of the aircraft starts by picking-up customers and/or cargo. If the operation starts in a smart city, the aircraft shall be able to interact with the customer through an application to be ready for embarking the customer and/or cargo at the nearest/selected pick-up location.

Assuming that the aircraft is not at the pick-up location when called, it shall fly from its current location to the pick-up one. To achieve this movement, the aircraft shall be able to communicate with other aircrafts in the smart city, comply with air traffic control rules, and have a feasible fly plan that can execute autonomously, safely, securely, and sustainably. Before the movement starts, the aircraft shall conduct the sub-phases during the preflight phase. The aircraft shall be capable of receiving any service expectations from the customer and adapt accordingly, for example, provide the desire temperature, light intensity, music ready to listen, ability to operate and share business files, etc. At this point, customers assume that the aircraft is charged enough (if it is all electric), which implies that the aircraft is able to interface with its source of power at the needed charging speed and without stressing the power source. When the aircraft arrives at the pick-up location, it shall be able to fit in the landing pad and to comply with any applicable regulations (e.g., maximum weight). If the landing pads are shareable with other aircrafts, the aircraft shall have a priority reservation mechanism in order to avoid making the customer to wait. The aircraft shall be able to manage all the necessary information sharing with the air traffic control network to access its priority reservation service.

Once the aircraft arrives at a pick-up location, customers shall be capable of loading any shape of cargo (e.g., rounded, squared, soft, solid, etc.) in the aircraft while also complying with the regulations. Customers shall load the aircraft as fast as loading the compartments of a car. When the aircraft embarks the customer, it shall read its moods. The aircraft shall adapt all its interior components to provide a pleasant and comfortable trip to the customer, so that the customer feels joy and optimism at disembarking. If the needed adaptation of the interior components contradicts the selected settings by the customer, the aircraft shall suggest and explain to the customer the needed adaptations so that the customer can understand the rationale of the suggestion and have the opportunity to accept changes to the settings. At this point, the aircraft shall be capable of complying with all preflight regulations.

The aircraft shall perform autonomously the flight phases faster than any other competing vehicle, but it shall also comply with all regulations and be connected with other aircrafts. The aircraft shall comply with all regulations when flying within smart cities, from a smart city to a smart airport, and from a smart airport to a smart city. The aircraft shall be able to manage possible stops from the embarking location to the final destination. During the flight phase, customers change their moods, get relaxed, and receive any required service (e.g., transfer files or watching movies) at the same speed as at home or at office. If the disembarking pad is shareable, the aircraft shall manage autonomously the reservation such that customers do not wait.

At disembarking, the customer may opt to share the agenda from its phone, laptop, or other devices with the aircraft such that it can schedule intelligently charging of its battery and conduct any maintenance task in order to be always available to the customer. Customers expect the aircraft to comply with any regulations with the landing pad at disembarking and to ensure that it is adequate to the customer needs. The aircraft shall end its operation by executing autonomously the sub-phases of the postflight phase.

The team shall demonstrate that there are enabling systems capable of supporting the operations of the aircraft at its boundaries with the customer, cargo, smart cities, and smart airports during the phases of flight. The team shall identify the interfaces between the aircraft and each boundary during the phases of flight in order to support the operations of the aircraft. In addition, the team shall define the interface properties and constraints (mechanical, electrical, mass, thermal, data, and procedural flows) in the next iterations of the requirements engineering task. The next iteration implies to define the functions at each boundary (e.g., aircraft cargo, aircraft-customer, aircraft-smart airport, aircraft-smart city) and respective performance for each phase of flight, such that the expected behavior of the aircraft (i.e., to fly safely, securely, and sustainably; but also, the team shall express the meaning of faster than any competing vehicle) in qualitative and quantitative terms at each boundary and at a whole.

5.3.2 Define system requirements (SySR)

The main function of the aircraft is to provide people and their cargo an autonomous, connected, safe, secure, and sustainable flight within smart cities, from smart cites to smart airports, from smart airports to smart cities, and near smart airports. To achieve this function, this section discusses the technologies that conform the aircraft and life cycle stages of the aircraft.

To achieve the major function of the aircraft, a navigation system and an automated flight control system of the aircraft shall execute the OODA loop (see Table 2) to direct the aircraft as intended by its passengers and regulators. The automated flight control system shall also communicate with other aircrafts, traffic control, and any other enabling system to fly. The health monitoring systems and power management system of the aircraft shall also feed their statuses to the automated flight control system so that the aircraft is capable to predict and assure that it will perform safely, securely, and sustainably its trip for the needed range.

The landing gear of the aircraft shall permit landing and take-off from all the possible locations in the smart cities of interest and smart airports in the trips. The airframe and its materials of the aircraft shall guarantee that it will resist all the encountered weather conditions, payloads, and loads during the trips; but they also facilitate flying with the lowest possible energy.

The interior components of the aircraft shall remain quiet and stable during the phases of flight so that the passengers experience a similar comfort as competing vehicles. The interior components shall read the mood of the passenger beginning with the pre-flight phase if demanded, so that the interior of the aircraft adapts automatically to change the mood.

The electrical system shall power all the electronics (navigation systems, automated flight control system, telecommunication devices, business multimedia, HVAC systems, internal and external lights, etc.) in the aircraft, such that the aircraft can fly safely, securely, and sustainably; but it also services the expectations of the customer. A battery or any other sustainable source of energy system shall supply the power to the electrical system and create the aerodynamic forces needed to fly the aircraft safely, securely, and sustainably.

The supply chain and manufacturing systems shall deliver aircrafts as fast and not more expensively than competing vehicles. The supply chain, manufacturing systems, and service centers shall be ready to make the aircraft available as needed for the customers when it is in service. The maintenance of the aircraft shall be as quick and expensive as for competing vehicles. Training for the aircraft maintenance personal shall not exceed the cost and time as for competing vehicles. Agreements shall be in place to retire the aircraft in accordance with the principles of the circular economy.

The team shall save the design, its development, its manufacturing blueprint, maintenance plan, and operation records of the aircraft for the whole life of the aircraft and beyond. The team shall also justify the remaining storage time beyond the life of the aircraft by a cost-benefit analysis and comply with any regulation. The life cycle cost of the aircraft shall be lower than competing vehicles, such that the aircraft has the right acquisition, operation, insurance, financial, and maintenance costs for the target acquirers.

System requirements arise from the main function of the aircraft, and they align with the stakeholder requirements and the functional boundaries. The remainder of this section aligns them using the classification employed for stakeholder requirements. The employed stakeholder requirements classifications, the 57 elicited stakeholder requirements, and the 101 allocated system requirements 2 are listed below. Table 4 to 13 break down the 101 system requirements respect to each stakeholder requirements class.

Stakeholder – Stakeholder (SS)

The class Stakeholder – Stakeholder elicited 10 stakeholder requirements. For these requirements, 11 system requirements were allocated (refer to Table 4). The allocated system requirements are detailed below.

Table 4: Allocation of system requirements into stakeholder requirements: Stakeholder – Stakeholder

SS1 – Investors expect a profitable project, yielding the highest possible NPV in 10 years, ROI rate, IRR, PI, and the shortest payback period.

  • SS1 – SySR1 – The life cycle cost of the aircraft shall be lower than competing vehicles, such that the aircraft has the right acquisition, operation, insurance, financial, and maintenance costs for the target acquirers.

SS2 – Investors and acquirers expect that the acquisition and operational costs of the aircraft are lower than luxurious cars, but not higher than existing aircrafts.

  • SS2 – SySR1 – The same as requirement SS1 – SySR1.

SS3 – Financial investors expect to provide capital and accept risk in order to gain a share of the expected profits.

  • SS3 – SySR1 – The project shall deliver a variety of products (e.g., technology transfer to other industries), services (e.g., priority reservation mechanism), and systems (a differentiated aircraft) with de-risked revenues and profits.
    • See also requirement SS1 – SySR1.

SS4 – Knowledge, OEM, and supply chain investors expect to provide systems engineering execution experience, and superior technological capabilities in autonomy and navigation, connectivity and interoperability, aerodynamics, materials, structure and fuselage, luxurious interiors and comfort, entertainment and business support, power systems (all-electric, electric and gas turbines, or other), electrical systems, health management systems, manufacturing systems, certification, training services, and service infrastructures.

  • SS4 – SySR1 – Investors shall have systems engineering execution experience in aerospace or related industries.
    • Investors shall have experience with MBSE to apply formal modeling to support system requirements, design, analysis, verification, and validation activities in aerospace or related industries.
    • Investors shall have experience with traditional document-centric systems engineering in aerospace or related industries.
  • SS4 – SySR2 – Investors shall have superior technological capabilities compared to rival products (e.g., cars, helicopters, airplanes, spacecrafts, and boats) in autonomy and navigation, connectivity and interoperability, aerodynamics, materials, structure and fuselage, luxurious interiors and comfort, entertainment and business support, power systems (all-electric, electric and gas turbines, or other), electrical systems, health management systems, manufacturing systems, certification, training services, and service infrastructures.

SS5 – Investors expect to create a team, conformed of business developers, systems engineers, and technical capabilities champions to lead the life cycle of the project.

  • SS5 – SySR1 – Investors shall create a team, conformed of business developers, systems engineers, and technical capabilities champions to lead the life cycle of the project.

SS6 – Investors and regulators expect the team to ensure that the aircraft and its technologies will satisfy all safety, security, and sustainability concerns from passengers, airport operators, airlines, users of the airport, city dwellers, investors, and others affected parties during the life of the aircraft.

  • SS6 – SySR1 – The team shall plan integration, verification, and validation to ensure that the aircraft and its technologies will satisfy all safety, security, and sustainability concerns from passengers, airport operators, airlines, users of the airport, city dwellers, investors, and others affected parties during the life of the aircraft.

SS7 – Investors expect that the team and regulators work together to provide access to a priority flight path as a service.

  • SS7 – SySR1 – The team and regulators shall work together to provide access to a priority flight path as a service.

SS8 – Investors, the team, regulators and interested parties expect to agree and sign approval of the evaluation method to rate each criterion, synthesize the evaluation process for each alternative and corresponding solution classes, and the decision-making process to choose a winning alternative.

  • SS8 – SySR1 – Investors, the team, regulators, and interested parties shall agree and sign approval of the evaluation method to rate each criterion, synthesize the evaluation process for each alternative and corresponding solution classes, and the decision-making process to choose a winning alternative.
    • Investors, the team, regulators and interested parties shall consider as alternatives the complete aircraft, specific technologies (e.g., power systems, aerodynamics, and automatic flight control system), development strategy, manufacturing systems, certification, supply chain, services (operation, maintenance, and retirement), insurance, marketing and acquisition business models, and financing mechanism.

SS9 – Investors and related stakeholders expect the team to inform them of the evaluation of multiple alternatives respect to acquisition, operational, and maintenance costs, return on investment, safety, security, sustainability, range, speed, superior comfort, usability, saved time, manufacturability, and maintainability for all life cycle stages.

  • SS9 – SySR1 – The team shall communicate the evaluation of multiple alternatives with respect to acquisition and operational costs, return on investment, safety, security, sustainability, range, speed, superior comfort, usability, saved time, manufacturability, and maintainability for all life cycle stages to the investors and related stakeholders.

SS10 – Investors expect the team to employ methodologies and software tools to record and manage the establishment of stakeholders’ intentions into a common set of acceptable requirements, so that the aircraft satisfies the intentions of the stakeholders and can be checked during the life cycle of the project.

  • SS10 – SySR1 – The team shall employ methodologies and software tools to record and manage the establishment of stakeholders’ intentions into a common set of acceptable requirements, so that the validation that the aircraft satisfies the intentions of the stakeholders can be checked during the life cycle of the project.
    • See also requirement SS4 – SySR1.

Stakeholders – Smart Airport (SSA)

The class Stakeholder – Smart Airport elicited 3 stakeholder requirements. For these requirements, four system requirements were allocated (refer to Table 5). The allocated system requirements are detailed below.

Table 5: Allocation of system requirements into stakeholder requirements: Stakeholders – Smart Airport

SSA1 – Passengers expect a pleasant and fast journey near smart airports, from smart airports to smart cities, and from smart cities to airports compared to rival solutions.

  • SSA1 – SysR1 – The aircraft shall comply with any demand from infrastructures and regulations in order to apply priority reservation mechanisms for landing pads near smart airports, from smart airports to smart cities, and from smart cities to smart airports, so that landing and taking-off do not delay the trip times and the journey is faster than compared rival solutions.
  • SSA1 – SysR2 – The aircraft shall comply with any agreements from the team and regulators in order to use a priority flight path as a service, if requested by customers, when flying near smart airports, from smart airports to smart cities, and from smart cities to airports; so that the journey is faster than compared rival solutions.

SSA2 – Passengers and its cargo expect to interoperate with the smart airport space 10 areas no less convenient than competing solutions when they are near the smart airport, leaving from the smart airport to the smart city, and arriving to the smart airport from the smart city.

  • SSA2 – SysR1 – The aircraft or its enabling systems shall enable the passengers and cargo to clear any regulation respect to the smart airport space 10 areas (refer to Section 2.1) in order to avoid delays in entering, staying, and leaving the smart airport proximity; so that the journey is faster than compared rival solutions.

SSA3 – Passengers, airport operators, airlines, users of the airport, city dwellers, investors, and others affected parties expect a safe, secure, and sustainable air transportation system to support the operations of the smart airports (e.g., Figure 2).

  • SSA3 – SysR1 – The team shall demonstrate along the life cycle of the aircraft (i.e., concept stage, development, production, utilization, support, and retirement) to potential passengers, airport operators, airlines, users of the airport, city dwellers, investors, and others affected parties that the aircraft flies safely, securely, and sustainably in order to comply with all directives of a sustainable air transportation system in the operations of the smart aircraft.

Stakeholder – Smart City (SSC)

The class Stakeholder – Smart City elicited four stakeholder requirements. For these requirements, six system requirements were allocated (refer to Table 6). The allocated system requirements are detailed below.

Table 6: Allocation of system requirements into stakeholder requirements: Stakeholders – Smart City

SSC1 – Passengers expect a pleasant and fast journey in smart cities, from smart cities to smart airports, and from smart airports to smart cities compared to rival solutions.

  • SSC1 – SysR1 – The aircraft shall comply with any demand from infrastructures and regulations in order to apply priority reservation mechanisms for landing pads in smart cities, from smart airports to smart cities, and from smart cities to smart airports, so that landing and taking-off do not delay the trip times and the journey is faster than compared rival solutions.
  • SSC1 – SysR2 – The aircraft shall comply with any agreements from the team and regulators in order to use a priority flight path as a service, if requested by customers, when flying in smart cities, from smart airports to smart cities, and from smart cities to airports; so that the journey is faster than compared rival solutions.

SSC2 – Passengers and its cargo expect to interoperate with the cutting-edge technologies of smart cities no less convenient than competing solutions when they are in the smart city, leaving from the smart city to the smart airport, and arriving to the smart city from the smart airport.

  • SSC2 – SysR1 – The aircraft or its enabling systems shall enable the passengers and cargo to interoperate with cutting-edge technologies in smart cities (refer to Section 2.2) in order to avoid delays; so that the journey is faster than compared rival solutions.
  • SSC2 – SysR2 – The aircraft or its enabling systems shall enable the passengers and cargo to interoperate with cutting-edge technologies in smart cities (refer to Section 2.2) and provide a pleasant experience in the trip no less convenient than competing solutions.

SSC3 – Passengers, city managers, airlines, city dwellers, investors, and others affected parties expect to comply with regulations for the serviced smart cities when the aircraft is in the smart city, leaving from the smart city to the smart airport, and arriving to the smart city from the smart airport.

  • SSC3 – SysR1 – The team shall demonstrate along the life cycle of the aircraft (i.e., concept stage, development, production, utilization, support, and retirement) to potential passengers, city managers, airlines, city dwellers, investors, and others affected parties that the aircraft complies with regulations for the serviced smart cities so that the aircraft flies safely, securely, and sustainably in the smart city, leaving from the smart city to the smart airport, and arriving to the smart city from the smart airport.

SSC4 – Passengers, city managers, airlines, city dwellers, investors, and others affected parties expect a safe, secure, and sustainable transportation system to support the operations of the smart city: economy, environment, and society and culture.

  • SSC4 – SysR1 – The team shall demonstrate along the life cycle of the aircraft (i.e., concept stage, development, production, utilization, support, and retirement) to potential passengers, city managers, airlines, city dwellers, investors, and others affected parties that the aircraft flies safely, securely, and sustainably in order to comply with all directives of a sustainable transportation system to support the operations of the smart city: economy, environment, and society and culture.

Stakeholder – Aircraft (SA)

The class Stakeholder – Aircraft elicited eight stakeholder requirements. For these requirements, 29 system requirements were allocated (refer to Table 7). The allocated system requirements are detailed below.

Table 7: Allocation of system requirements into stakeholder requirements: Stakeholders – Aircraft

SA1 – Passengers, investors, the team, and the rest of affected stakeholders expect that the e-VTOL aircraft is autonomous, connected, safe, secure, and sustainable during all phases of flight (refer to Figure 6).

  • SA1 – SysR1 – The aircraft shall be able to communicate with other aircrafts in the smart city, from the smart city to the smart airport, and from the smart airport to the smart city during the phases of flight, comply with air traffic control rules, and have a feasible fly plan that can execute autonomously, safely, securely, and sustainably.
  • SA1 – SysR2 – The aircraft shall conduct the sub-phases during the preflight phase before the flight phase starts.
  • SA1 – SysR3 – The aircraft shall conduct the sub-phases during the flight phase before the post-flight phase starts.
  • SA1 – SysR4 – The aircraft shall conduct the sub-phases during the postflight phase after completing the flight phase and customers do no longer request the aircraft for service.

SA2 – Passengers expect the aircraft to have goods storage and seat capacity up to 4 passengers.

  • SA2 – SysR1 – The aircraft shall be capable of loading any shape of cargo (e.g., rounded, squared, soft, solid, etc.) at the pick-up locations, while it also complies with applicable regulations.
  • SA2 – SysR2 – The aircraft shall provide seat capacity up to 4 passengers.

SA3 – Passengers expect a flight range from 16 to 300 km, to be further investigated depending on the locations to service.

  • SA3 – SySR1 – The aircraft shall have enough electrical energy or an alternative energy source to fly safely, securely, and sustainably a flight range from 16 to 300 km.

SA4 – Passengers expect the aircraft to provide quicker journeys than competing vehicles.

  • SA4 – SySR1 – The aircraft shall fly autonomously from its current location to the pick-up one when called and it is not at the pick-up location.
  • SA4 – SySR2 – Passengers shall load the aircraft as fast as loading the compartments (e.g., the trunk) of a car.
  • SA4 – SySR3 – The aircraft shall perform autonomously all the flight phases faster than any other competing vehicle, but it shall also comply with all regulations and be connected with other aircrafts.
  • SA4 – SySR4 – The aircraft shall manage autonomously a priority reservation mechanism such that customers do not wait at embarking, flying, and disembarking.

SA5 – Passengers expect the aircraft to provide comfortable experiences during the phase of flight to delight customers.

  • SA5 – SysR1 – The aircraft shall be capable of receiving any service expectations from the customer and adapt accordingly, for example, provide the desire temperature, light intensity, music ready to listen, ability to operate and share business files, etc.

SA6 – Passengers expect minimum training to fly the aircraft (e.g., a passenger who can use a smartphone, tablet or laptop, shall be able to be trained to fly the aircraft anywhere in less than 30 minutes).

  • SA6 – SysR1 – The team shall demonstrate to potential passengers that it takes less than 30 minutes to train a person who can use a smartphone, tablet, or laptop to fly safely the aircraft to anywhere.

SA7 – Regulators expect MTOW (maximum takeoff weight) between 450 and 2200 kg.

  • SA7 – SySR1 – The aircraft shall comply with any applicable regulations (e.g., MTOW) at pick-up locations.

SA8 – Investors expect the team to propose an aircraft that is aesthetically appealing to potential customers driving luxurious (sport) cars (e.g., Bugatti Divo, Aston Martin Rapide A, Audi R8 performance series, Lamborghini Aventador series, Rolls-Royce Phantom, Bentley Mulsanne, BMW i8 Roadster, Tesla Roadster Founder Edition, Mercedes-Benz AMG One and Ferrari SF90 Stradale) affected by congestion and noisy helicopters in their day-to-day city journeys and trips from airports to cities or vice versa.

  • SA8 – SySR1 – The team shall propose and demonstrate that the aircraft is aesthetically appealing to potential customers driving luxurious (sport) cars (e.g., Bugatti Divo, Aston Martin Rapide A, Audi R8 performance series, Lamborghini Aventador series, Rolls-Royce Phantom, Bentley Mulsanne, BMW i8 Roadster, Tesla Roadster Founder Edition, Mercedes-Benz AMG One and Ferrari SF90 Stradale) affected by congestion and noisy helicopters in their day-to-day city journeys and trips from airports to cities or vice versa.

SA9 – Investors and the team expect the aircraft to bear the name The Disruptor.

  • SA9 – SySR1 – The aircraft shall bear the name The Disruptor.

SA10 – Investors and the team expect that the aircraft has an explicit unnoticed combination between art, science, and technology.

  • SA10 – SySR1 – The team shall demonstrate to investors that the aircraft combines art, science, and technology.

SA11 – Investors and the team expect the aircraft to provide pleasant emotions to the unique personalities of the customers.

  • SA11 – SySR1 – The team shall demonstrate to investors that aircraft provide pleasant emotions to the unique personalities of the customers (e.g., passengers, regulators, maintainers, and disposers).

SA12 – Investors and the team expect that aircraft embrace the principles of a circular economy during its life.

  • SA12 – SySR1 – The team shall demonstrate to investors that the aircraft embrace the principles of a circular economy during its life (concept stage, development, production, utilization, maintenance, and retirement).

SA13 – Passengers through an app schedule the pick-ups by the aircraft to the closest locations.

  • SA13 – SySR1 – The aircraft shall be able to interact with the customer through an application to be ready for embarking the customer and/or cargo at the nearest/selected pick-up location.

SA14 – Passengers expect to embark the aircraft as quickly as getting on a competing vehicle during the 24 hours of a day with any mood.

  • SA14 – SySR1 – The aircraft shall be available at demand during the 24 hours of a day.
  • SA14 – SySR2 – The team shall demonstrate that aircraft can be embarked as quickly as getting on a competing vehicle at any time of the day.
  • SA14 – SySR3 – The aircraft shall read and adapt to all possible passengers’ moods at embarking.

SA15 – Passengers expect to have drinks, listen to music, read, call, watch movies, transfer files, or just get relaxed in the aircraft during the trip.

  • SA15 – SySR1 – Passengers expect to change the aircraft’s moods, get relaxed, and receive any required service (e.g., transfer files or watching movies) at the same speed as at home or office during the flight phase.

SA16 – Passengers expect superior comfort, a pleasant trip to the destination, and to disembark the aircraft with a mood of joy and optimism.

  • SA16 – SySR1 – The aircraft (e.g., a face-recognition system, and an intelligent behavior detection system) shall identify the mood of customers while scheduling a trip or embarking the aircraft.
  • SA16 – SySR2 – The interior components of the aircraft shall read the mood of the passenger while scheduling a trip or embarking, so that the interior of the aircraft adapts automatically to change any initial mood into a mood of joy and optimism at disembarking with the ultimate goal of reminding a passenger the unique valuable person s/he is without any inconvenience.
  • SA16 – SySR3 – The aircraft shall allow the customer to control the desire settings for the interior component.
  • SA16 – SySR4 – The aircraft shall suggest and explain to the customer the ideal interior component settings when they contradict with the selected ones by the customer, so that the customer can understand the rationale of the suggestion and s/he accepts to change the settings to obtain a pleasant and comfortable trip that guarantees a disembarking mood of joy and optimism.
  • SA16 – SySR4 – The interior components of the aircraft shall remain quiet and stable during the phases of flight so that the passengers experience more pleasant and comfortable trips than competing vehicles.
  • SA16 – SySR5 – The aircraft shall be able to manage possible stops from the embarking location to the final destination.

Stakeholder – Concept stage (SC)

The class Stakeholder – Concept stage elicited four stakeholder requirements. For these requirements, seven system requirements were allocated (refer to Table 8). The allocated system requirements are detailed below.

Table 8: Allocation of system requirements into stakeholder requirements: Stakeholders – Concept stage

SC1 – Investors and the team expect that the form of the aircraft arises after refining all the necessary functions to guarantee pleasant emotions to its customers.

  • SC1 – SySR1 – The team shall demonstrate to investors that the form of the aircraft arose after refining all the necessary functions to guarantee pleasant emotions to its customers during the phases of flight within smart cities, from smart cities to smart airports, from smart airports to smart cities, and near smart airports.

SC2 – Investors and the team expect superior technological capabilities in autonomy and navigation, connectivity and interoperability, aerodynamics, materials, structure and fuselage, luxurious interiors and comfort, entertainment and business support, power systems (all-electric, electric and gas turbines, or other), electrical system, health management systems, manufacturing systems, certification, training services, and service infrastructures compared to rival solutions.

  • SC2 – SySR1 – The team shall demonstrate to investors that the aircraft provides superior but feasible technological capabilities in autonomy and navigation, connectivity and interoperability, aerodynamics, materials, structure and fuselage, luxurious interiors and comfort, entertainment and business support, power systems (all-electric, electric and gas turbines, or other), electrical system, health management systems, manufacturing systems, certification, training services, and service infrastructures compared to rival solutions.

SC3 – Investors and the team expect during the concept stage to define the selected partners, technologies, its design process and certification plan; and create a visual prototype of the e-VTOL business aircraft, and a simulated effective and efficient manufacturing system, operation, support, and retirement.

  • SC3 – SySR1 – The team shall save the design, its development, its manufacturing blueprint, certification plan and verification methods, maintenance plan, and operation records of the aircraft for the whole life of the aircraft and beyond. The team shall also justify the remaining storage time beyond the life of the aircraft by a cost-benefit analysis and comply with any regulation.
  • SC3 – SySR2 – The team and investors shall define the selected partners, the technologies, and the design process and certification plan for the e-VTOL business aircraft during the concept stage.
  • SC3 – SySR3 – The team shall demonstrate to investors a visual prototype of the e-VTOL business aircraft, and a simulated effective and efficient manufacturing system, operation, support, and retirement.

SC4 – Investors and the team expect that the aircraft follows the principles of the circular economy during the concept stage.

  • SC4 – SySR1 – The team shall demonstrate to investors that the aircraft embrace the principles of the circular economy during the concept stage.
  • SC4 – SySR2 – The concept stage of the aircraft shall comply with agreements applying the principles of the circular economy, developed in consensus by investors, team, regulators, and affected stakeholders.

Stakeholder – Development (SD)

The class Stakeholder – Development elicited five stakeholder requirements. For these requirements, eight system requirements were allocated (refer to Table 9). The allocated system requirements are detailed below.

Table 9: Allocation of system requirements into stakeholder requirements: Stakeholders – Development

SD1 – Investors expect that the aircraft enters into service by 2025.

  • SD1 – SySR1 – The team shall demonstrate to investors a de-risked plan to assure that the aircraft enters into service by 2025.
  • SD1 – SySR2 – The aircraft shall enter into service by 2025.
    • See also SP1 – SysR1

SD2 – Investors expect that the team and regulators certify the aircraft faster than helicopters and traditional airplanes.

  • SD2 – SySR1 – The team shall work together with investors and regulators to create a certification plan for the aircraft in order to assure the entry into service by 2025.
    • The certification plan shall ensure compliance with applicable regulations and applicable safety, security, and sustainability requirements.
    • The certification plan shall assure faster certification than helicopters and traditional airplanes.

SD3 – Investors and the team expect that the aircraft follows the principles of the circular economy during development.

  • SD3 – SySR1 – The team shall demonstrate to investors that the aircraft embrace the principles of the circular economy during the development.
  • SD3 – SySR2 – The development of the aircraft shall comply with agreements applying the principles of the circular economy, developed in consensus by investors, team, regulators, and affected stakeholders.

SD4 – Regulators expect the team to evaluate the consequences on passengers of potential accidents (customer injury through aircraft malfunction, collision with the ground, collision with an object, and general disintegration of the aircraft) at four locations during the phases of flight: the smart airport, from the smart airport to the smart city, in the smart city, and from the smart city to the smart airport.

  • SD4 – SySR1 – The team shall demonstrate to regulators the evaluation of consequences on passengers of potential accidents (customer injury through aircraft malfunction, collision with the ground, collision with an object, and general disintegration of the aircraft) at four locations during the phases of flight: the smart airport, from the smart airport to the smart city, in the smart city, and from the smart city to the smart airport.

SD5 – Investors expect the team to mitigate the risk of accidents such that passengers experience superior comfort and quicker rides compared to rival vehicles, a pleasant trip to the destination, and disembark the aircraft with a mood of joy and optimism.

  • SD5 – SySR1 – The team shall define all the possible risks of accidents.
    • The team shall include as one part of all the possible risks of accidents all the recorded incidents for helicopters and airplanes.
    • The team shall obtain approval from regulators and investors about all the defined possible risks of accidents.
  • SD5 – SySR2 – The team shall demonstrate that passengers experience superior comfort and quicker rides compared to other rival vehicles, a pleasant trip to the destination, and disembark the aircraft with a mood of joy and optimism under the present of all the defined risks in SD5 – SySR1.

Stakeholder – Production (SP)

The class Stakeholder – Production elicited five stakeholder requirements. For these requirements, nine system requirements were allocated (refer to Table 10). The allocated system requirements are detailed below.

Table 10: Allocation of system requirements into stakeholder requirements: Stakeholders – Production

SP1 – Investors expect that manufacturing of the aircraft starts by 2023.

  • SP1 – SySR1 – The team shall demonstrate to investors a de-risked plan to assure that manufacturing of the aircrafts starts by 2023, so that the expected entry into service by 2025 is achieved.
    • Manufacturing by 2023 implies readiness of the production system and supply chain to fabricate aircrafts (one or more) for certification purposes.
  • SP1 – SySR2 – The first aircraft shall enter manufacturing by 2023.

SP2 – Investors expect that manufacturing of the aircraft scales up by 2025 at the aircraft entry into service such that the planned NPV, ROI rate, IRR, PI, and the payback period are met.

  • SP2 – SySR1 – The team shall demonstrate to investors a de-risked plan to assure that manufacturing of the aircrafts scales up by 2025 at the aircraft entry into service such that the planned NPV, ROI rate, IRR, PI, and the payback period are met.

SP3 – Investors and the team expect that manufacturing the aircraft must compare to the cost and production timelines of luxurious cars.

  • SP3 – SySR1 – The supply chain and manufacturing systems shall deliver aircrafts as fast and not more expensive than competing vehicles.

SP4 – Investors, regulators, and the team expect that manufacturing delivers certified aircrafts.

  • SP3 – SySR1 – The team shall certify the production system with regulators.
  • SP3 – SySR2 – The team shall comply with the certified production system each time during manufacturing.
  • SP3 – SySR3 – The team shall record the compliance evidence each time during manufacturing.

SP5 – Investors and the team expect that the aircraft follows the principles of the circular economy during production.

  • SP4 – SySR1 – The team shall demonstrate to investors that the aircraft embrace the principles of the circular economy during production.
  • SP4 – SySR2 – The production of the aircraft shall comply with agreements applying the principles of the circular economy, developed in consensus by investors, team, regulators, and affected stakeholders.

Stakeholder – Utilization (SU)

The class Stakeholder – Utilization elicited six stakeholder requirements. For these requirements, 18 system requirements were allocated (refer to Table 11). The allocated system requirements are detailed below.

Table 11: Allocation of system requirements into stakeholder requirements: Stakeholders – Utilization

SU1 – Passengers expect the aircraft is available when demanded.

  • SU1 – SySR1 – The aircraft shall have priority in a reservation mechanism in order to avoid making the customer wait when the landing pads at the pick-up, intermediate, and destination locations are shareable with other aircrafts.
  • SU2 – SySR2 – The aircraft can read the passengers’ agenda from its phone, laptop, or other devices while scheduling the trip, embarking, flying, and disembarking such that the aircraft can schedule intelligently charging its battery and conduct any maintenance task in order to be always available to the customer.

SU2 – Acquirers and investors expect that the aircraft charges without disrupting the daily operations of its customers longer than competing vehicles.

  • SU2 – SySR1 – The aircraft shall be able to interface with its source of power at the needed charging or fueling speed and without stressing the power source.

SU3 – Investors and the team expect that the aircraft follows the principles of the circular economy during utilization.

  • SU3 – SySR1 – The team shall demonstrate to investors that the aircraft embrace the principles of the circular economy during utilization.
  • SU3 – SySR2 – The utilization of the aircraft shall comply with agreements applying the principles of the circular economy, developed in consensus by investors, team, regulators, and affected stakeholders.

SU4 – Passengers expect the aircraft to navigate and interoperate with any enabling system (e.g., air traffic control, telecommunication systems, regulations, other aircrafts, landing pads, connectivity services, and power grids) at 4 locations during the phases of flight: the smart airport, from the smart airport to the smart city, in the smart city, and from the smart city to the airport.

  • SU4 – SySR1 – A navigation system and an automated flight control system of the aircraft shall execute the OODA loop, see Table 2, to direct the aircraft as intended by its passengers and regulators.
  • SU4 – SySR2 – The automated flight control system of the aircraft shall communicate with other aircrafts, air traffic control, and any other enabling system to fly safely, securely, and sustainably.
  • SU4 – SySR3 – The landing gear of the aircraft shall permit to land and take-off from all the possible locations in the smart cities of interest and smart airports in the trips.
  • SU4 – SySR4 – The aircraft shall be able to manage all the necessary information sharing with the air traffic control network to access its priority reservation service during the phases of flight.
  • SU4 – SySR5 – The aircraft shall comply with any regulation and its information sharing needs during the phase of flight within smart cities, from a smart city to a smart airport, and from a smart airport to a smart city.
  • SU4 – SySR6 – The team shall demonstrate that there are enabling systems capable to support the operations of the aircraft at its boundaries with the customer, cargo, smart cities, and smart airports during the phases of flight.
  • SU4 – SySR7 – The team shall identify the interfaces between the aircraft and each boundary during the phases of flight to support the operations of the aircraft.
  • The team shall define the interfaces properties and constraints (mechanical, electrical, mass, thermal, data, and procedural flows).

SU5 – Passengers, regulators, and affected stakeholders expect that the aircraft fly safely, securely, and sustainably during the phases of flight in smart cities, from smart cities to smart airport, and from smart airports to smart cities.

  • SU5 – SySR1 – A battery or any other sustainable source of energy system shall supply the power to the electrical system and create the aerodynamic forces needed to fly safely, securely, and sustainably the aircraft.
  • SU5 – SySR2 – The electrical system shall power all the electronics (navigation systems, automated flight control system, telecommunication devices, business multimedia, HVAC systems, internal and external lights, etc.) in the aircraft, such that the aircraft can fly safely, securely, and sustainably; but it also services the expectations of the customer.
  • SU5 – SySR3 – The airframe and its materials of the aircraft shall guarantee that it will resist all the encounter weather conditions, payloads, and loads during the trips; but they also facilitate to fly with the lowest possible energy.
  • SU5 – SySR4 – The health monitoring system and power management system of the aircraft shall also feed their statuses to the automated flight control system, so that the aircraft is capable to predict and assure that it will perform safely, securely, and sustainably its trip for the needed range.
  • SU5 – SySR5 – The aircraft shall be capable of complying with all preflight, flight, and post flight regulations when flying within smart cities, from a smart city to a smart airport, and from a smart airport to a smart city.

SU6 – Acquirers and investors expect that the costs of utilizing the aircraft compares to the costs of operating rival vehicles.

  • SU6 – SysR1 – The team shall demonstrate to investors and acquirers that the cost to utilize the aircraft does not exceed the cost of operating competing vehicles.

Stakeholder – Support (SSu)

The class Stakeholder – Support elicited three stakeholder requirements. For these requirements, seven system requirements were allocated (refer to Table 12). The allocated system requirements are detailed below.

Table 12: Allocation of system requirements into stakeholder requirements: Stakeholders – Support

SSu1 – Acquirers and investors expect that the aircraft is maintained without disrupting the daily operations of its customers.

  • SSu1 – SySR 1 – The maintenance of the aircraft shall be as quick and cost the same as for competing vehicles.
  • SSu1 – SySR 2 – The supply chain, manufacturing systems, and service centers shall be ready to make the aircraft available as needed for the customers when it is in service.
  • SSu3 – SySR 3 – The team shall demonstrate to regulators and investigators that the aircraft is certifiable after each maintenance if needed.

SSu2 – Acquirers and investors expect that the aircraft is maintained with similar costs as competing vehicles.

  • SSu2 – SySR 1 – Training for the aircraft maintenance personal shall not exceed the cost and time as for competing vehicles.
  • SSu2 – SySR 2 – The team shall demonstrate to investors and acquirers that the cost to maintain the aircraft does not exceed the cost of maintaining competing vehicles.

SSu3 – Investors and the team expect that the aircraft follows the principles of the circular economy during support.

  • SSu3 – SySR1 – The team shall demonstrate to investors that the aircraft embrace the principles of the circular economy during support.
  • SSu3 – SySR2 – The support of the aircraft shall comply with agreements applying the principles of the circular economy, developed in consensus by investors, team, regulators, and affected stakeholders.

Stakeholder – Retirement (SR)

The class Stakeholder – Retirement elicited one stakeholder requirement. For this requirement, two system requirements were allocated (refer to Table 13). The allocated system requirements are detailed below.

Table 13: Allocation of system requirements into stakeholder requirements: Stakeholders – Retirement

SR1 – Investors and the team expect that the aircraft follows the principles of the circular economy during retirement.

  • SR1 – SySR1 – The team shall demonstrate to investors that the aircraft embrace the principles of the circular economy during retirement.
  • SR2 – SySR1 – The retirement of the aircraft shall comply with agreements applying the principles of the circular economy, developed in consensus by investors, team, regulators, and affected stakeholders.

5.3.3 Analyze system requirements

The analysis of system requirements is a significant activity in the requirements engineering activity. In particular, this activity intends to study the feasibility, affordability and the proper composition of the set of requirements as suggested in the standard. System engineers need one more iteration to convert the system requirements into qualifiable and quantifiable requirements, employing units and ranges (tolerances) as needed to avoid ambiguity. If system engineers fail to do this activity properly, there is a high probability that the project will delay, exceed costs, or stop in the future. However, the activity is beyond the scope of the article. Readers seeking guidance about the activity can refer to the standard.

5.3.4 Manage system requirements

The activity “define system requirements (SySR)” contains the last version of system requirements in the article. This activity intends to control changes in the last version of requirements as the project progresses. The article does not cover such changes as they arise when system engineers evolve the design process. Readers seeking guidance about the activity can refer to the standard.

6. Comparison with other methodologies

The article employed text-based requirements. The reality of projects has proven that text-based requirements are the most effective form of communication among stakeholders. Text-based requirements offer several advantages compared to model-centric requirements. Such advantages are: facilitating communication with non-technical readers (e.g., lawyers, marketing, acquirers, administrators), power of expression of both functional and non-functional requirements, accessibility respect to software tools, definition of requirements attributes, creation of contracts, and system verification and validation (Wheatcraft, 2019).

Future work in the subject plans to use MBSE to model the set of complete requirements. This work will help to understand how text-based requirements and MBSE complement each other. In addition, the work will discover some limitations of MBSE in eliciting a complete set of requirements. Researchers can use the limitations to track the efforts and expected updates in SysML v2 (Systems Modeling Language) planned to support MBSE (Towers, 2020). Arcadia and Capella (Bonnet, Voirin, & Navas, 2019) are an alternative for comparing and understanding the limitations.

7. Summary and Conclusions

This article has presented the elicitation of a complete set of requirements for the business aircraft of the future. The complete set of requirements is vast, encompassing stakeholders, the aircraft, its enabling systems, the context of operation, and the life cycle of the aircraft. The article followed guidance from the international standard ISO/IEC/IEEE 29148:(2018) to elicit the complete set of requirements.

The complete set of requirements consists of 57 stakeholder requirements and their associated 101 system requirements. Both types of requirements were classified into 10 classes respectively: Stakeholder – Stakeholder (10, 11) 3, Stakeholder – Smart Airport (3, 4), Stakeholder – Smart City (4, 6), Stakeholder – Aircraft (16, 29), Stakeholder – Concept stage (4, 7), Stakeholder – Development (5, 8), Stakeholder – Production (5, 9), Stakeholder – Utilization (6, 18), Stakeholder – Support (3, 7), and Stakeholder – Retirement (1, 2). The classes assure that the article considered the complete problem space to system engineer the aircraft of the future; thus, it guarantees that the set of requirements is complete.

The complete set of requirements provides the foundation to: 1) facilitate the conversation in the systems engineering community concerning eliciting complete sets of requirements in the aerospace sector using traditional text-based requirements; 2) utilize the set of requirements to practice the attributes and characteristics of well-formed set of requirements specified in the standard; and 3) use the set of requirements as a baseline to understand the scope of MBSE in the elicitation of complete set of requirements in the aerospace sector.

List of Acronyms and Abbreviations Used in this Paper

Acronym        Explanation

ConOps        Concept of Operations

e-VTOL         Electrical Vertical Take-Off and Landing

HVAC            Heating, Ventilation, and Air Conditioning

IATA              International Air Transport Association

ICAO            International Civil Aviation Organization

INCOSE       International Council on Systems Engineering

MBSE           Model-based Systems Engineering

OODA           Observe, Orient, Decide, and Act

OpsCon        Operational Concept

S3                 Safety, Security and Sustainability

SysML          Systems Modeling Language

SA                Stakeholder – Aircraft

SC                Stakeholder – Concept Stage

SD                Stakeholder – Development

SP                Stakeholder – Production

SR                Stakeholder – Retirement

SS                Stakeholder – Stakeholder

SSA              Stakeholder – Smart Airport

SSC              Stakeholder – Smart City

SSu              Stakeholder – Support

SU                Stakeholder – Utilization

SySR            System requirements

Acknowledgements

My thanks go to Dr. Ralph Young for his encouragement to write this article. Without his encouragement, the ideas in the article would have not been written.

References

Airbus. (2019). Connectivity: Connecting to the digital world anywhere. Retrieved from https://www.airbus.com/innovation/future-technology/connectivity.html

Bell flight. (2019a). Bell Nexus. Retrieved from https://www.bellflight.com/products/bell-nexus

Bell flight. (2019b). Special report: on-demand mobility and tomorrow’s smart cities. Retrieved from https://www.verticalcentury.com/182847-special-report-on-demand-mobility-and-tomorrow-s-smart-cities

Bonnet, S., Voirin, J.-L., & Navas, J. (2019). Augmenting Requirements with Models to Improve the Articulation between System Engineering Levels and Optimize V&V Practices. Systems Engineering Newsletter, 83. Retrieved from https://www.ppi-int.com/ppisyen83/#featurearticle

ciena. (2019). How does a smart city get smarter? Retrieved from https://media.ciena.com/documents/CN_CorpAdaptNetwork_InfoIllustration_R5.2.pdf

Flyvbjerg, B. (2014). What You Should Know About Megaprojects and Why: An Overview. Project Management Journal, 45(2), 6-19. doi:10.1002/pmj.21409

García, J. (2015, 21-23 April 2015). Broadband connected aircraft security. Paper presented at the 2015 Integrated Communication, Navigation and Surveillance Conference (ICNS).

Hardeman, A. B. (2020). Sustainable Alternative Air Transport Technologies. In T. Walker, A. S. Bergantino, N. Sprung-Much, & L. Loiacono (Eds.), Sustainable Aviation: Greening the Flight Path (pp. 277-306). Cham: Springer International Publishing.

Harris, M. (2018). Larry Page is quietly amassing a ‘flying car’ empire. The Verge. Retrieved from https://www.theverge.com/2018/7/19/17586878/larry-page-flying-car-opener-kitty-hawk-cora

Honeywell. (2019). Honeywell Connected Aircraft. Retrieved from https://aerospace.honeywell.com/en/pages/honeywell-connected-aircraft

Howard, C. (2018). Rolls-Royce to work with airframe manufacturers, seek partners for EVTOL project. Retrieved from https://www.sae.org/news/2018/07/rolls-royce-to-work-with-airframe-manufacturers-seek-partners-for-evtol-project

IATA. (2015). Airport of the future. Retrieved from https://www.iata.org/whatwedo/ops-infra/airport-infrastructure/Documents/AoF_brochure_02.pdf

IATA. (2019). NEXTT: Let’s build the journey of the future. Retrieved from https://nextt.iata.org/en_GB/

ICAO. (2019a). DRONE ENABLE, ICAO’s Third Unmanned Aircraft Systems Industry Symposium (DRONE ENABLE/3) 12 – 14 November 2019 Retrieved from https://www.icao.int/Meetings/DRONEENABLE3/Pages/default.aspx?utm_medium=social&utm_source=linkedin&utm_campaign=events2019&utm_content=droneenable2019

ICAO. (2019b). Electric and Hybrid Aircraft Platform for Innovation (E-HAPI) Retrieved from https://www.icao.int/environmental-protection/Pages/electric-aircraft.aspx

ICAO. (2019c). ICAO 2019 Environmental Report: destination green – the next chapter. Retrieved from https://www.icao.int/environmental-protection/Documents/ICAO-ENV-Report2019-F1-WEB%20(1).pdf

INCOSE. (2015). Systems engineering handbook: a guide for system life cycle processes and activities (D. Walden, G. Roedler, K. Forsberg, R. D. Hamelin, & T. Shortell Eds. 4th ed.): Wiley.

International Business Aviation Council. (2019). IBAC Definitions of Business Aviation. Retrieved from https://www.ibac.org/about-ibac/ibac-definitions-of-business-aviation/

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. Switzerland.

Joint Planning and Development Office. (2007). Concept of operations for the next generation air transportation system: version 2.0. Retrieved from https://apps.dtic.mil/dtic/tr/fulltext/u2/a496134.pdf

Joint Planning and Development Office. (2010). Concept of Operations for the Next Generation Air Transportation System: Version 3.0. Retrieved from https://www.hsdl.org/?view&did=747519

MacKinnon, B., Sowden, R., Russell, K., & Stewart, D. (2004). Sharing the skies: an aviation industry guide to the management of wildlife hazards. Retrieved from https://www.tc.gc.ca/Publications/en/tp13549/pdf/hr/tp13549e.pdf

Meredith, S. (2019). Boeing CEO says a global pilot shortage is ‘one of the biggest challenges’ facing the airline industry. CNBC. Retrieved from https://www.cnbc.com/2019/06/17/boeing-ceo-says-global-pilot-shortage-is-one-of-the-biggest-challenges.html

Moir, I., & Seabridge, A. (2013). Design and development of aircraft systems (2nd ed.): John Wiley & Sons.

National Business Aviation Association. (2014). Business aviation fact book. Retrieved from https://nbaa.org/wp-content/uploads/2018/01/business-aviation-fact-book.pdf

National Research Council. (2014). Autonomy Research for Civil Aviation: Toward a New Era of Flight. Washington, DC: The National Academies Press.

National Research Council Canada. (2019). Integrated Autonomous Mobility (IAM) Initiative. Retrieved from http://caric.aero/wp-content/uploads/2019/08/Technology-focus-for-NRCs-IAM-initiative.pdf

Nichols, M., & Dyment, M. (2019). Business aviation embraces electric flight: how urban air mobility creates enterprise value. Retrieved from https://nbaa.org/wp-content/uploads/aircraft-operations/uas/NEXA-Study-2019-Business-Aviation-Embraces-Electric-Flight.pdf

Peterson, T. (N/A). What does a “connected” aircraft really mean? Retrieved from https://www.iata.org/whatwedo/Documents/1445_Todd_Peterson_Connected%20meaning.pdf

Schwab, K. (2016). The Fourth Industrial Revolution: what it means, how to respond. Retrieved from https://www.weforum.org/agenda/2016/01/the-fourth-industrial-revolution-what-it-means-and-how-to-respond/

Schwarz-Herion, O. (2020). The Role of Smart Cities for the Realization of the Sustainable Development Goals. In A. Omran & O. Schwarz-Herion (Eds.), Sustaining our Environment for Better Future: Challenges and Opportunities (pp. 209-257). Singapore: Springer Singapore.

Smiciklas, J., Prokop, G., Stano, P., & Sang, Z. (2017). Collection Methodology for Key Performance Indicators for Smart Sustainable Cities. Retrieved from https://www.unece.org/fileadmin/DAM/hlm/documents/Publications/U4SSC-CollectionMethodologyforKPIfoSSC-2017.pdf

The electric VTOL News™. (2019a). Autonomous. Retrieved from https://evtol.news/autonomous/

The Electric VTOL News™. (2019b). eVTOL Aircraft Directory. Retrieved from https://evtol.news/aircraft/

Towers, J. (2020). The MBSE Horizon: Advances and Challenges over the Next Few Years. Systems Engineering Newsletter, 85. Retrieved from https://www.ppi-int.com/ppisyen85/#featurearticle

Turnbull, K., Cherrington, L., Elgart, Z., Zmud, J., Baker, T., Hudson, J., & Wagner, J. (2017). Automated and connected vehicle (AV/CV) test bed to improved transit, bicycle, and pedestrian safety: technical report. Retrieved from https://static.tti.tamu.edu/tti.tamu.edu/documents/0-6875-1.pdf

U.S. Department of Transportation: Federal Aviation Administration. (2012). Helicopter Instructor’s Handbook. Retrieved from https://www.faa.gov/regulations_policies/handbooks_manuals/aviation/media/faa-h-8083-4.pdf

United Nations, Department of Economic and Social Affairs, Population Division. (2018). The World’s Cities in 2018. Retrieved from https://www.un.org/en/events/citiesday/assets/pdf/the_worlds_cities_in_2018_data_booklet.pdf

United Nations Department of Economic and Social Affairs. (2018). 2018 Revision of World Urbanization Prospects. Retrieved from https://www.un.org/development/desa/publications/2018-revision-of-world-urbanization-prospects.html

Vornehm, N. (2019). Porsche and Boeing to Partner on Premium Urban Air Mobility Market [Press release]. Retrieved from https://newsroom.porsche.com/en/2019/company/porsche-boeing-collaboration-premium-urban-air-mobility-18880.html

Wheatcraft, L. (2019). The Role of Requirements in an MBSE World. Systems Engineering Newsletter, 80. Retrieved from https://www.ppi-int.com/ppisyen80-article2/

World Economic Forum. (2018). Centre for the Fourth Industrial Revolution Network. Retrieved from http://www3.weforum.org/docs/WEF_C4IR_Network_2018.pdf

About the Author

Ronaldo Gutierrez gained his PhD degree in Information and Systems Engineering from the Concordia Institute at Concordia University, Montreal, QC, Canada. During his academic research, Ronaldo investigated the big picture of new aircraft development projects, healthcare decision support systems, and semi-automated methods to support quality management tasks for drainage systems in new land development projects. Before studying at Concordia University, Ronaldo worked as import coordinator and shipments inspector for an agency representing the operations of Hapag-Lloyd and Maruba container shipping companies in Nicaragua. His experience and academic research awakened his interest in systems engineering, especially in using ontologies to support the execution of systems engineering activities. Ronaldo has been a member of INCOSE since 2017.

3. ADDITIONAL ARTICLES

3.1 Reuse in Requirement Management for Rail Projects

by

Aurangzeb Awal

Transport for London

Email: AurangzebAwal@tfl.gov.uk

Abstract

In both large rail and small rail projects, there are many elements of the design that are repeatable or similar. Reuse therefore becomes an opportunity to implement efficiencies based on how requirements are managed and developed. This article explores requirement reuse and how requirements can be made reusable to provide efficiency in developing requirement specifications.

Copyright © 2020 by Transport for London. All rights reserved.

Introduction

ISO/IEC/IEEE 15288 states that the purpose of the stakeholder needs and requirements definition process is to define the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholders in a defined environment. [1]

Successful projects depend on meeting the needs of stakeholders throughout the engineering lifecycle. This involves determining appropriate stakeholders, eliciting their needs, and transforming these needs into requirements. In the requirement definition process, if stakeholder needs and requirements appear to be like other projects with respect to the system and context, then the opportunity for requirement reuse exists. The same requirements developed on one project can be reused on a new project.

In the rail industry, to improve efficiencies on new projects, organizations can perform stakeholder knowledge elicitation and lessons learned from previous projects; also, there may be various organizational mechanisms in place to support this. Can we learn to do better requirement reuse?

Reuse against working from scratch

Requirement reuse has several advantages:

  • Project cost savings – if work can be done once, there is no sense in using time and effort doing it again on a new project. Reduced rework naturally leads to lower development costs and also less frustration.
  • Productivity and delivery – Since requirements do not need to be developed from scratch, this leads to higher team productivity, a smaller learning curve, less defects, and faster delivery.
  • Requirement quality and coverage – As one iterates requirements derived from other projects over time, one can ensure that the requirements are perfected and considered correctly. This also facilitates consistency in requirements specifications.

However, depending on the project, it may be more appropriate to start a project from scratch, because blind requirement reuse may bring its own risks including:

  • Lack of appreciation of stakeholder requirements.
  • Lack of innovation in design.
  • Higher project costs, redesign and rework.
  • Longer delivery.

Project size, complexity, interfaces, and risks are all factors that need to be considered when approaching a new project and considering its potential for requirement reuse. The necessary analysis needs to take place to determine the appropriateness of a reused requirement as opposed to a new requirement.

Learning lessons from software engineering

In the software industry there are several papers [2] [3] [4] written on requirements and software reuse and it is a recent addition to the book “Software Requirements” by Karl E Wiegers and Joy Beatty [5]. Reuse in software projects is a means to improve productivity, quality, and consistency, where the software code and other software components can have reuse potential. And there are many lessons that can be learned and adapted to rail and potentially other industries.

In software, a simple way to reuse a requirement may be to copy and paste it from an existing requirement specification. A more complex way may be reusing an entire functional component from requirements through design, code, and test. But applying reuse isn’t easy, as risks lie both with reusing existing items and by creating items with good reuse potential [5]. Creating high-quality reusable requirements can take more effort than to write requirements you intend to use only on the current project.

One study found that despite the benefits of requirement reuse, only about half of the organizations surveyed were practicing requirements reuse, primarily due to the poor quality of existing requirements. Citing that unstructured, incomplete, outdated existing requirements made it difficult to reuse requirements going forward [6]. To be effective at reuse requires that an organization establish the infrastructure and processes to make requirements reusable for fu