6.1.3 REQUIREMENTS MANAGEMENT: CONTRASTING TRADITIONAL SYSTEMS AND SOFTWARE ENGINEERING METHODS

In traditional Systems Engineering, the Systems Engineer acts as the overall system creator. Primarily through stakeholder interaction, requirements analysis, and architectural design, the Systems Engineering shapes and influences the system solution through specifications, top-down design, and bottoms-up integration and test. With the large-scale introduction of commercial-off-the-shelf (COTS) components, the Systems Engineer acts more like a composer. The top-down requirements and design activities need to be adjusted to account for the bottoms-up constraints imposed by the COTS technology. The System Engineer shapes and influences COTS-based developments through requirements modifications and negotiations, along with simultaneous system design, integration, and test. This paper explores the changing role of the Systems Engineer in today's complex system of systems (SoS) environment. We will use the analogies of conductor and choreographer to describe the System Engineering leadership challenges that exist in a SoS environment. Similar to a conductor, we will look at the set of activities that ensure the elements in the SoS work together in harmony. Similar to a choreographer, we will look at the set of activities that ensure the expressive nature of each of the SoS elements is fully realized, while still conforming to its overall objectives. Using these analogies, we will draw some conclusions for the evolving Systems Engineering role in a SoS environment. We will also explore which of these activities emerge as dominant in situations both with and without a lead SoS integrator.

Completing its final development and early deployment on the Navy's multi-role aircraft, the F/A-18 E/F Super Hornet, the SHAred Reconnaissance Pod (SHARP) provides the war fighter with the latest digital tactical reconnaissance (TAC Recce) Electro-Optical/Infrared (EO/IR) sensor system. The SHARP program is an evolutionary acquisition that used a spiral development process across a prototype development phase tightly coupled into overlapping Engineering and Manufacturing Development (EMD) and Low Rate Initial Production (LRIP) phases. Under a tight budget environment with a highly compressed schedule, SHARP challenged traditional acquisition strategies and systems engineering (SE) processes. Adopting tailored state-of-the-art systems engineering process models allowd the SHARP program to overcome the technical knowledge transition challenges imposed by a compressed program schedule. The program's original goal was the deployment of digital TAC Recce mission capabilities to the fleet customer by summer of 2003. Hardware and software integration technical challenges resulted from requirements definition and analysis activities performed across a government-industry led Integrated Product Team (IPT) involving Navy engineering and test sites, Boeing, and RTSC-EPS (with its subcontracted hardware and government furnished equipment vendors). Requirements development from a bottoms-up approach was adopted using an electronic requirements capture environment to clarify and establish the SHARP EMD product baseline specifications as relevant technical data became available. Applying Earned-Value Management (EVM) against an Integrated Master Schedule (IMS) resulted in efficiently managing SE task assignments and product deliveries in a dynamically evolving customer requirements environment. Application of Six Sigma improvement methodologies resulted in the uncovering of root causes of errors in wiring interconnectivity drawings, pod manufacturing processes, and avionics requirements specifications. Utilizing the draft NAVAIR SE guideline handbook and the ANSI/EIA-632 standard: Processes for Engineering a System, a systems engineering tailored process approach was adopted for the accelerated SHARP EMD prgram. Tailoring SE processes in this accelerated product delivery environment provided unique opportunities to be technically creative in the establishment of a product performance baseline. This paper provides an historical overview of the systems engineering activities spanning the prototype phase through the EMD SHARP program phase, the performance requirement capture activities and refinement process challenges, and what SE process improvements can be applied to future SHARP-like programs adopting a compressed, evolutionary spiral development acquisition paradigm.

This study compares the types and quantities of knowledge that are captured by a model‐based systems engineering (MBSE) approach and a traditional architecting approach to measure the benefits of the MBSE approach in managing the complexity of a robotic space system. The MBSE approach was implemented with Cameo Systems Modeler using Systems Modeling Language (SysML) and applied to architecting an orbiting sample Capture and Orient Module (COM) system concept for a Capture, Containment, and Return System payload concept for potential Mars Sample Return. An architecture framework was established, covering system, subsystem, and assembly levels, along with structure, behavior, data, and requirements perspectives. The COM system architecture was captured in parallel using both the MBSE and non‐MBSE approaches in order to provide a side‐by‐side comparison of the approaches. The approaches were evaluated based on how well each represented the information content of the COM system architecture. A total of 4389 knowledge elements were classified using the Revised Bloom's Taxonomy knowledge dimension and used to quantitatively compare the two approaches. The MBSE approach more completely captured architectural knowledge than the non‐MBSE approach. Limitations to the SysML‐based MBSE approach were also identified, including its ability to fully represent certain high‐level conceptual, procedural, and metacognitive knowledge such as design principles, design approaches and rationales, risks, development strategies and rationales, organizational core competencies, and requirement verification methods. The overall results demonstrate the benefits of MBSE in managing the complexity of robotic space systems and strengthen the case for adopting MBSE within the systems engineering community.

In traditional systems engineering (TSE) environments, and particularly in recent years, many are concerned about risk management. So much so that risks are identified early and often, and mitigation techniques are aggressively pursued. In contrast one does not hear as much about opportunity management. What about enterprise systems engineering (ESE) environments? Do traditional methods of handling risk and opportunity carry over, or should we be concerned about potential changes in the way we view the problem? Assuming there are new perspectives to bring to bear on this topic, what are they, and what principles might be discovered and applied to the enterprise to better deal with opportunity and risk? This paper offers some answers to these questions: • There is duality in treating risks and opportunities. • In ESE, be aggressive with opportunity and accepting of risk. • The greatest enterprise risk may be in not pursuing enterprise opportunities. Introduction In a recent book on opportunity management [Hillson, 2004] Hillson makes a rather convincing case that opportunities get “short shrift” in most programs. See, for example, Hillson’s comments (on pp. iii, vii, and xvi): “There is ... a systemic weakness in risk management as undertaken on most projects. The standard risk process is limited to dealing only with uncertainties that might have negative impact (threats). This means that risk management as currently practiced is failing to address around half of the potential uncertainties—the ones with positive impact (opportunities).” Furthermore, anecdotally, the author of this paper has noticed that many—if not most—risk and risk management documents, tools, processes, and websites, etc. do not even mention or discuss opportunities or opportunity management. Therefore, it seems to make sense to “appreciate” opportunity at the system scale. Hillson views an “opportunity” as the opposite of a “threat” and adopts the position that these two factors together constitute risk. But, he also provides extensive evidence of the viewpoint that treats opportunity as the opposite of risk. In the present author’s opinion, the latter view is more traditional and straightforward; though Hillson makes the case that the former is becoming more prevalent in academic and professional circles. Nonetheless, in this theoretical paper, opportunity is viewed as the opposite of risk. The author hypothesizes that in systems engineering at an enterprise scale the focus should be on opportunity, and that enterprise risk should be viewed more as something that threatens the pursuit of enterprise opportunities, as depicted in Fig. 1. Fig. 1 is meant to suggest that the importance of opportunity management should increase qualitatively as one proceeds from system, to System of Systems (SoS), to enterprise scales. This is partially based on the premise, supported by historical fact and ad hoc observations, that risk

This paper describes a theory that aims to provide the foundation for the “Discipline of Systems Engineering (DSE).” DSE is explicitly modeled on classical engineering disciplines such as electrical or mechanical engineering, in its use of formal models using physical and logical laws and properties to understand system design and performance. The DSE approach places great emphasis on defining a suite of models that can be used in a formal process to produce systems engineering products with far fewer errors than current, Traditional Systems Engineering. This paper will develop and elucidate a suite of proposed principles for DSE, as a starting point for the later description of the required models and DSE process.

Many of the current traditional system engineering (TSE) approaches for elicitation of requirements are insufficient when deployed in complex situations. TSE approach to requirement elicitation is based on assumption of stable environmental conditions. However, the elicitation of requirements for complex systems (i.e., interdependent critical infrastructures) requires innovative approaches that should go beyond technical aspects of a situation. Complex situations arise when multiple complex infrastructures interdependently interact to provide goods and services for public health and safety. The elicitation of requirements for such a system must consider the nature of system of interest, its environment and system observer. On this backdrop, this paper reviews complexity associated with attained requirements for complex infrastructures, failures and provides an overview of a proposed high-level framework for infrastructure requirement elicitation.

This paper explores the Systems Engineering structure, strategies and tools for real world scenarios involving work with accident response planning. A systems engineering approach must be taken by the technical teams to prepare for a successful response and design the technical systems in support of the operations. The scope of this project is focused on laying out the foundation of the systems engineering approach taken to help the teams develop an accident response strategy and identify new engineering designs in support of these operations for the black box systems. This Masters project involved several interdisciplinary teams & stakeholders. Identifying the proper tools to use was key to addressing the big picture needs of the multiple stakeholders. The integrated project work primarily took place over the course of eight weeks via integrated team meetings. Other work in support of this project was conducted off-line as needed by the project lead. Details on the prospective timeline, milestones, key dates and work scope can be referenced in this paper. Key systems engineering methodologies and tools used in support of this project included but is not limited to: Market Surveys and Interviews Project Charter Feasibility Study Swim Lane Diagram Knowledge Management Plan A full suite of tools and the details regarding the application of these tools and results of this study is provided in this report. SAND2020-1243227 Stevens Institute of Technology SYS800 Dulce Barrera 4 ACKNOWLEDGEMENTS Masters Project Advisor: Professor William Bill Robinson, Stevens Institute of Technology, SYS800 Special Problems in Systems Engineering, Six Sigma Master Black Belt, https://web.stevens.edu/facultyprofile/?id=1242

The Department of Defense continually looks at means to control the cost overruns, schedule slips and technical requirements creep so as to acquire high performing and highly complex weapons systems. This paper describes how the functions that comprise Program Integration would benefit by the proper application of Systems Engineering precepts. Program Integration requires the application of an interdisciplinary approach such as that which defines Systems Engineering. Many of the functions that define Program Integration, such as Risk Analysis, and Logistics support, already are considered Systems Engineering concepts or characteristics. The remaining Program Integration functions could likewise be incorporated under the overall Systems Engineering approach. The Air Force has struggled with getting the respective programs to transition to the Program Integration philosophy. Much of the issue relates to typical resource constraints. This paper addresses these implementation issues and makes recommendations centered on the use of Systems Engineering as the means to establish a fully functioning Program Integration effort that will result in highly-executing acquisition program offices that can execute their mission with a higher degree of success with respect to cost, schedule, and performance. Organizing such a function within an established engineering functional office are also be explored.

This paper considers the creation of Complex Engineered Systems (CESs) and the Systems Engineering approach by which they are designed. The changing nature of the challenges facing Systems Engineering is discussed, with particular focus on the increasing complexity of modern systems. It is argued that modern complexity poses a major challenge to our ability to achieve successful systems and that this complexity must be understood, predicted and measured if we are to engineer systems confidently. We acknowledge previous work which concluded that, in complex systems, failures (“accidents”) may be inevitable and unavoidable. To further explore potential tools for increasing our confidence in complex systems, we review research in the field of Complexity Theory to seek potentially useful approaches and measures and find ourselves particularly interested in the potential usefulness of relationships between the magnitudes of events and their frequency of occurrence. Complexity Theory is found to have characterized naturally occurring systems and to potentially be the source of profitable application to the systems engineering challenge, viz., the creation of complex engineered systems. We are left with the tentative conclusion that truly complex systems, with our present understanding of complex behavior, cannot be designed with a degree of confidence that is acceptable given our current expectations. We recommend that the discipline of systems engineering must investigate this issue as a matter of priority and urgency and seek to develop approaches to respond to the challenge. © 2003 Wiley Periodicals, Inc. Syst Eng 7: 25–34, 2004

Contributors

Societal and technological advancements along with lessons learned from previous projects and space programs resulted in the creation of the International Space Station (ISS). The ISS is an engineering marvel created by a collaboration of 16 International Partners (IP's), space agencies, contractors and sub-contractors whose primary purpose is to conduct research in space for benefit of mankind. However, currently, there are several major challenges relating to the management of the ISS such as budget, time, governance, and collaboration/competition which can hamper the evolution of the ISS and which can potentially lead to the failure of the system. The ISS still primarily relies on traditional systems engineering (SE) methodology which lacks the necessary flexibility to deal with the emergent challenges of the ISS system. This paper proposes applying SoSE to the ISS which we suggest can mitigate these issues and provide a framework for future space research and exploration.

This is an introduction to complex-system engineering (cSE). cSE is going to become the second branch of system engineering. It is still in its formative stages. All of cSE’s presently known ideas are briefly discussed. A familiarity with the first branch of system engineering, so called traditional system engineering (TSE), is assumed.

The high-performance nature of VISTA, the Visible & Infra-Red Survey Telescope for Astronomy, with its wide-field high-throughput f/1 optical design coupled with the multi-organisation, multi-disciplinary nature of the VISTA collaboration places significant demands on the project's Systems Engineering function. The project has relied heavily on a Systems Engineering approach, which has been vigorously applied throughout the conception, specification, and tendering stages of the project lifecycle, and is in place to be continued through the remaining phases of design & development, manufacture, assembly, commissioning, verification and acceptance. As the project matures from the Requirements/Design phase towards the Development and Manufacturing phase, the current status of the VISTA project is illustrated in terms of its Systems Engineering aspects, along with examples of how a formal Systems Engineering approach has resulted in benefits to the important project parameters of performance, cost and schedule. Key tools such as engineering budgets, configuration control procedures and the approach to risk management will be discussed in terms of their value to the project.

There is an increasing application of Systems Engineering in the Norwegian construction industry. This paper investigates the effects of a Systems Engineering approach on project management performance, prerequisites for success, and which elements contribute to effectiveness from a technical contractor perspective. First, we find a positive perception of Systems Engineering's effect on time, cost, and quality. Second, we provide and rank a list of 12 prerequisites for success. Third, we quantify the perceived importance of five elements of the systems engineering process. Finally, we find a disconnect between what seems to be essential processes and prerequisites and what gets done in practice. To improve Systems Engineering performance, we recommend improving Systems Engineering competence and capabilities, increasing the formality of requirements analysis and documentation, and front‐loading the effort and allocation of resources in projects.

Nowadays, in software, electronics and automotive industries, it takes 1.5–2 years for a new product to appear, although it takes 3 or even more years to develop new space instruments. The update of higher education system standards is even more conservative. It takes 10 or more years. Because of this, graduates come into the industry with outdated knowledge. Thus, the problem is to synchronize the processes of updating technologies that ensure the creation of innovative products with educational programs. It can be solved by changing the paradigm of products creation based on the synthesis of deep and interdisciplinary educational, scientific, innovative and production activities with the model-based systems engineering software and methodological tools.The existing model-based systems engineering (MBSE) Software (SW) tools based on the Systems Modelling Language (SysML) are complex and expensive. This chapter raises the question, “Is it possible to make use of MBSE SW and methodological tools available to a wide audience of users?” To answer this question, the following MBSE approaches and tools were researched: Quality Function Deployment (QFD), House of Quality (HoQ), and SysML. Consequently, five methodological tools were developed for application during space instruments design and development life cycle stages. Tools are based on SysML, QFD, HoQ improvements and synthesis, and expressed in theoretical and practical algorithms.The theoretical algorithm determines “What” (input and output data) and “How” (by using which systems engineering (including MBSE) tools are methodically analysed at the certain space instruments life cycle stage. The practical algorithm automates the development of SysML diagrams by using data structured in HoQ models and widely available SW. It reduces the time to develop and update SysML requirements diagrams from several days to some minutes and enables implementation of SysML SW by many users. Altogether, the obtained results constitute the software and methodological toolkit (SMT) called “improved Quality Function Deployment for improved House of Quality”.To disseminate the obtained results, educational materials were created and validated during lectures on systems engineering. Lectures were supplemented with seminars and practicum. Practicum was focused on the design and development (D&D) of nanosatellites in the MBSE paradigm as the single project. The results showed that the developed SMT makes it possible to implement the life cycle of the cyber-physical system in the MBSE paradigm in a cost-effective way and a short time—in 6 months, students developed, conducted synthesis and flight tests of CubeSat-format satellite prototype and prepared the project documentation. In addition, students were motivated to study science, technology, engineering and math disciplines, MBSE tools, and become transdisciplinary specialists.In addition, developed SysML requirements models were applied to examine the “Preliminary Design” product life cycle (PLC) stage of different space projects. Such application allowed quick assessment of project results, identifying non-compliance with requirements, conducting beforehand all necessary corrections and generating correct new product documentation. Taking into account the mentioned advantages of the obtained MBSE SMT, it can be concluded that its usage improves the quality and accuracy of current projects and speeds up the planning process of future analogue projects by up to 60%. Consequently, projects (their life cycle stages) can be realized faster by 5–10%.These results allow to recommend for all interested in the innovative D&D of systems to initiate: formation of educational programs based on the project approach and MBSE paradigm; preparation of MBSE materials for online and offline teaching of students and teachers; development of domestic widely available software for the development of integrated SysML models with HoQ models that assures synchronization with CAE/CAD/CAM systems; support these recommendations for the implementation of the above-mentioned research results at educational organizations of different levels. The future research is focused on the application of the developed MBSE methodological toolkit during design and development with numerical modelling and operation of several CubeSat satellites.KeywordsSystems engineeringMBSEParadigmMethodological toolkitSysMLQFDHoQ