INCOSE Systems Engineering Handbook Research Articles

The ISO‐15288 technical processes, system maturity, and conceptual gaps

AbstractISO 15288 and the INCOSE Systems Engineering Handbook define technical (and other) processes but do not really explain why we need all of them. This paper formalizes the technical processes specifically in terms of the changes in maturity that each enacts and why these particular changes are necessary. This in turn clarifies the need for each process and places the processes on a sound philosophical footing.

The Drone System II: Availability Performance Analysis and Modeling

AbstractThis paper is the second of two papers that together provide an example of how to use the systems engineering processes outlined in the INCOSE Systems Engineering Handbook and ISO/IEC/IEEE 15288:2015 to develop a SysML system architecture from a user's statement of need and then to develop a mathematical system model for system reliability, availability, and maintainability that may be used to perform system design and cost‐effectiveness trade‐off analyses. This paper focuses on the development of an analytic Markov model that may be used to determine the operational availability that results from alternative designs for the drone system described in the first paper and the use of this model to perform a design performance analysis and a design trade‐off analysis. It also compares the results of this analytic stochastic model to a simple deterministic model.

The Drone System I: Context‐Level Architecture

AbstractThis paper is the first of two papers that together provide an example of how to use the systems engineering processes outlined in the INCOSE Systems Engineering Handbook and ISO/IEC/IEEE 15288:2015 to develop a SysML system architecture from a user's statement of need and then to develop a mathematical system model for system reliability, availability, and maintainability that may be used to perform system design and cost‐effectiveness trade‐off analyses. This paper focuses on the development of a SysML architecture for a drone system that provides surveillance and delivery services.

Value Engineering as a Specialty for Systems Engineering: Exploring Opportunities

ABSTRACTValue Engineering is a so‐called specialty engineering activity within Systems Engineering according to the INCOSE Systems Engineering Handbook [INCOSE, 2015], but what makes Value Engineering a ‘specialty,’ and what can it offer Systems Engineers? In this article three Value Engineering concepts are described, which are the pillars of Value Engineering: 1) the definition of value, 2) the use of multi‐disciplinary workshops, and 3) the application of function diagramming with the FAST method. Each of these concepts is explained and ideas are put forward how to incorporate them in more commonly used Systems Engineering processes. Our findings show that Systems Engineering and Value Engineering are not mutually exclusive, but offer outstanding concepts to improve designers’ goals. With this article, we hope to inspire the Systems Engineering and Value Engineering communities to further explore and experiment together.

I Don't Need Requirements – I Know What I'm Doing! Usability as a Critical Human Factor in Requirements Management

AbstractThe INCOSE Systems Engineering Handbook Version 4.0 lists the word “process” 1,597 times, yet the word “people” only 65 times. This paper argues that human aspect (people) considerations are similarly underrepresented in requirements management (RM), and that RM focuses mainly on processes and products (tools). This is also reflected in the ISO/IEC/IEEE 29148:2011 abstract that refers to “provisions for the processes and products related to the engineering of requirements …”. The paper makes the case that due to the lack of human aspect considerations many requirements specifications do not meet the definition of usability, where requirement specification users can achieve their objectives with effectiveness, efficiency, and satisfaction.The consumer behavior theory suggests that if (requirements specifications) consumption is made too difficult, then consumers will want to move on to things they actually find satisfying (e.g. design, implementation, testing). By providing requirements specifications that are not readily usable to consumers, an additional processing burden is placed on them, and consumers might succumb to the temptation to cut the requirements analysis phase short. Combined with overconfidence, this may result in requirements consumers to move on, stating: “I have done this before. I don't need requirements. I know what I'm doing!”. This paper will identify the underlying root cause, and propose a method to introduce usability into the requirements management process, making the process more practical and convenient for the requirements consumer, and as a result, achieve better project performance.

Leveraging tradeoff, bridging the gap among disciplines

AbstractThe systems analysis process builds on decisions rooted in results from quantitative tradeoff studies. A consensus on its activities is widely shared and documented by norms and handbooks: ISO/IEC/IEEE 15288:2015, INCOSE Systems engineering handbook.2015 and NASA handbook.2007. Nonetheless, the development of methodologies supporting traceability between the systems analysis process and the other systems engineering processes is still an open area of research, especially within the framework of model‐based approaches. As a result, documents justifying architecture choices are still produced by consolidating data manually; and what is more, data evolution is also verified manually. Such time‐consuming tasks have no real added value but are potential sources of error. Tooling the capitalization of the tradeoff data—including the rationales based on parameter values and their evolutions from project milestone to project milestone—would significantly facilitate the production and integrity of the documentation of architecture justification. This article reports on the results of our research in this direction.

Overview of an Emerging Standard on Architecture Processes – ISO/IEC 42020

AbstractA new, emerging standard on architecture practices is under development as ISO/IEC 42020. This paper provides an overview of the key concepts in this standard and the rationale for these ideas. The standard defines six architecture‐related processes: governance, management, conceptualization, evaluation, elaboration, and enablement. These are comprised of 37 activities, having five to eight tasks specified for each activity. It is expected that these processes will be incorporated into the next version of INCOSE's Systems Engineering Handbook and in the Guide to the Systems Engineering Body of Knowledge. This standard can be used as a foundation for organizational training and guidebooks on architecture management and development.

Defensibility: Legal Liabilities of Acts and Omissions in the Practice of Systems Engineering

AbstractSystems Engineers assigned to projects spend a majority of their time on technical and technical management processes. In order to produce balanced system solutions, systems engineers rely on specialty engineering activities (informally known as the “ilities” because many of them end in “ilty”) to trade performance requirements with non‐functional requirements (also known as quality attributes). The INCOSE Systems Engineering Handbook Fourth Edition (INCOSE, 2015) lists 14 “ilities” including affordability, reliability, and usability.This paper introduces defensibility, an additional “ility” that attempts to balance the legal aspects of the system and its development effort. Professional legal liabilities stem from two primary sources: acts and omissions. Breaches of acts arise when an activity has been done, but it was done poorly or an improper action was taken based on the situation. Breaches of omissions arise when an activity was not done that should have reasonably been done under the circumstances. This paper explores both of these liabilities in the context of systems engineering and provides practical advice on how individuals and companies can better protect themselves. This paper is an attempt to show practitioners how defensibility may play a role in their designs and how they may be drawn into the adjudicatory process around disputes over their work or the work of others.

The Path to Version 0.75 of the Proposed INCOSE Systems Engineering Competency Framework

AbstractThis paper describes the efforts and results so far to evolve the INCOSE Competency Framework to the next stage: Version 0.75. This paper describes how the proposed framework has been aligned with a number of other frameworks, competency models, bodies of knowledge and initiatives. These include but are not limited to the DoD's Better Buying Power 3.0 Implementation Plan, the Defense Acquisition University Competency Model, the US Navy's Systems Engineering Competency Career Model, the new INCOSE Systems Engineering Handbook Fourth Edition and the Systems Engineering Professional Certification Program. This paper also describes current efforts to develop an initial draft Role Definition Guide that will describe the typical roles that systems engineers may assume. The paper concludes by exploring all the remaining coordination activities and other actions required to successfully develop and publish Version 0.75 and eventually Version 1.0.

Finding Common Ground: Shared Benefits of the PMI PMBOK and the INCOSE Systems Engineering Handbook

AbstractThe evidence for the need to have further collaboration between systems engineering (SE) and project management (PM) is all around us: in the rampant overruns in our technology projects, in the increased internal organizational friction, in the clinging to archaic technologies for fear of what may come next. This paper investigates two leading guides for these organizations: the INCOSE Systems Engineering Handbook (SE) Handbook and the Project Management Body of Knowledge (PMBOK). Research indicates three areas for collaboration that might benefit integrating the two: defining tasks, integrated risk management, and stakeholder management.

Architecture Definition ‐‐ A New Process in the ISO International Systems Engineering Standard

AbstractThe ISO international standard on systems engineering practices has lacked a process for architecture definition that was separate from the process for system design definition. It had a process called architectural design, which was not deemed to properly cover the full purpose and scope of architecture definition. There were a number of reasons why architecture and design needed to be separated into different processes in the standard. This paper provides the reasons for this approach and describes the new Architecture Definition process in the updated standard that was published in 2015. It is expected that this process will be incorporated into the next version of INCOSE's Systems Engineering Handbook and in the Guide to the Systems Engineering Body of Knowledge.

Iterative and Participative Axiomatic Design Process in complex mechanical assemblies: case study on fusion engineering

The present paper proposes a structured Product Development Lifecycle (PDL) model to deal with the concept design stage of complex assemblies. The proposed method provides a systematic approach to design, aimed to improve requirements management, project management and communication among stakeholders as well as to avoid project failures reducing project development time. This research also provides suggestions and recommendations for utilizing different analysis, synthesis and assessment methodologies along with the proposed approach. The process developed, named Iterative and Participative Axiomatic Design Process (IPADeP), is consistent with ISO/IEC 15288:2008 – “Systems and software engineering”, and INCOSE Systems engineering handbook. It is an iterative and incremental design process, participative and requirements driven, based on the theory of Axiomatic Product Development Lifecycle (APDL). IPADeP provides a systematic methodology in which, starting from a set of experts’ assumptions, a number of conceptual solutions are generated, analysed and evaluated. Based on the results obtained, new iterations can be performed for each level of decomposition while product requirements are refined. In this paper, we applied IPADeP to the initial phase of conceptual design activities for DEMO divertor-to-vacuum vessel locking system in order to propose new innovative solutions.

7.4.2 Systems Engineering for Software Intensive Projects Using Agile Methods

Abstract“Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems” as defined in the INCOSE Systems Engineering handbook. When software development teams apply agile software methodologies such as scrum, test driven development and continuous integration (collectively referred to as “Agile software development” hereafter); there are challenges in coordination with traditional systems engineering efforts. This paper, developed by the INCOSE Agile Systems Engineering Working Group, proposes methods for cross‐functional teams that include Systems and Software Engineers working on customer “pull” projects to produce software products. This paper defines a proposed Agile SE Framework that aligns with agile software development methodology, and describes the role of the Systems Engineer in this context. It presents an iterative approach to the aspects of development (requirements, design, etc.) that are relevant to systems engineering practice. This approach delivers frequent releasable products that result in the ability to absorb changes in mission requirements through collaboration between systems engineers and software engineers. The Agile SE Framework defines a way to scale agile from individual agile software teams with a few members to large projects that require a planned architecture and coordinated efforts.

The Buck Stops Here: Systems Engineering Is Responsible for System Security

Who is responsible for systems security? As shown in figure 1, the acquirer (Acq) thinks it is the supplier, the supplier (Sup) delegates that responsibility to systems engineering, who pass it on to system security engineering (SSE), who meet requirements originating with the acquirer. This arrangement results in a finger-pointing circle when security fails. New revisions to the INCOSE Systems Engineering Handbook are integrating responsibility for system security into the systems engineering processes. Placing responsibility on systems engineering is only a first step. A second step requires mutual engagement between systems engineering and security engineering, an engagement that can only be enabled by systems engineering. Systems engineers and program or project managers will be expected to engage effectively throughout the systems engineering processes and activities—beginning with requirements analysis and the concept of operations, and proceeding through the full lifecycle of development, operations, and disposal. The theme articles in this issue of INSIGHT focus on the nature and problems of effective security engineering engagement in critical systems engineering processes. In the end, the acquirer and the supplier must also engage, in a shared responsibility that recognizes and deals with an unpredictable future of security threats. But that is another story, one that cannot be effective until systems and security engineering engagement is achieved.

9.4.1 Synergies between INCOSE SE Handbook, CMMI and DO‐178B

AbstractOne of the biggest challenges in multi‐normative organizations, in the field of industrial areas like aerospace and defense, is to make all technical regulations compatible. A huge amount of effort is spent by these organizations to maintain their accreditations periodically. Although each standard has its own purpose and appraisal procedure, it seems to be useful to know about the commonalities among norms, as well as extracting best practices from the application of its requirements to the accomplishment of the others. Particularly the INCOSE Systems Engineering Handbook can be considered as general lifecycle framework for systems, the Capability Maturity Model for Integration (CMMI) is a reference model to assess the process efficiency and RTCA DO‐178B can be used as basis for software certification. In literature very few contributions can be found to explain how these standards interrelate and how they can work together to achieve more efficient organizations. This experience paper aims to shed some light on the common aspects of these three standards applicable for the production of on‐board software. The combination proposal included in this paper is the result of the experience of the author in the application of these standards (and others) in the military avionics domain. Conclusions could be useful for their application to other domains or even for future potential combined accreditations.

10.3.1 The Development of Systems Engineering International Standards and Support Tools for Very Small Enterprises

AbstractIndustry recognizes that there are very small organizations that develop parts which contain software components. These organizations, those with up to 25 people, are very important to the world‐wide economy, and the parts they develop are often integrated into products made by larger enterprises. Failure to deliver a quality product on time and within budget threatens the competitiveness of both organizations. One way to mitigate these risks is for all the suppliers in a product chain put in place proven engineering practices. Many international standards have been developed to capture such proven engineering practices. However, these standards were not written for very small development organizations and are consequently difficult to apply in such settings. An ISO Working Group has been established to address these difficulties. The working group developed standards and technical reports, ISO/IEC 29110, which were published in 2011 for organizations developing software. In 2009 an INCOSE working group was established to evaluate the possibility of developing a standard, using the ISO/IEC 29110 standard as a baseline and the ISO/IEC 15288 as the framework, for organizations developing systems. At the 2011 INCOSE International Workshop, a group of systems engineers reviewed the ISO/IEC 29110 software standard and proposed modifications to meet their needs. One constraint was to develop a document which will allow an organization developing systems with software components to be able to use the actual set of ISO/IEC 29110 standards as well as the proposed systems engineering standards. The future systems engineering standard is targeted at VSEs which do not have experience or expertise in tailoring ISO/IEC 15288. A draft document has been developed and reviewed. Recently, an ISO working group has been mandated to develop the ISO standard for very small organizations developing systems. The INCOSE Systems Engineering Handbook is used as the main reference for the development of a set of systems engineering deployment packages. A deployment package is a set of artefacts developed to facilitate the implementation of a set of practices of a standard in a very small organization.

4.4.2 INCOSE Systems Engineering Handbook v3.2: Improving the Process for SE Practitioners

AbstractThe INCOSE Systems Engineering Handbook is the official INCOSE reference document for understanding systems engineering (SE) methods and conducting SE activities. Over the years, the Handbook has evolved to accommodate advances in the SE discipline and now serves as the basis for the Certified Systems Engineering Professional (CSEP) exam. Due to its evolution, the Handbook had become somewhat disjointed in its treatment and presentation of SE topics and was not aligned with the latest version of International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 15288:2008, Systems and Software Engineering. As a result, numerous inconsistencies were identified that could confuse practitioners and directly impact the probability of success in passing the CSEP exam. Further, INCOSE leadership had previously submitted v3.1 of the Handbook to ISO/IEC for consideration as a Technical Report, but was told that the Handbook would have to be updated to conform with the terminology and structure of new ISO/IEC15288:2008, Systems and software engineering, prior to being considered.The revised INCOSE Systems Engineering Handbook v3.2 aligns with the structure and principles of ISO/IEC 15288:2008 and presents the generic SE life‐cycle process steps in their entirety, without duplication or redundancy, in a single location within the text. As such, the revised Handbook v3.2 serves as a comprehensive instructional and reference manual for effectively understanding SE processes and conducting SE and better serves certification candidates preparing for the CSEP exam.

6.4.0 System Engineering Management Plan (SEMP): DOES ONE SIZE FIT ALL?

AbstractOne of the managerial and professional tools of the systems engineers in a project is the Systems Engineering Management Plan (SEMP). According to the INCOSE Systems Engineering Handbook, the SEMP is the top‐level plan for managing the Systems Engineering effort. The SEMP defines how the project will be organized, structured, and conducted and how the total engineering process will be controlled to provide a system that meets stakeholder requirements. The Handbook guides projects to tailor the SEMP to fit project, customer, or company standards.There are several procedures and templates for the SEMP. But in many organizations, companies and projects we find SEMPs that are not tailored for the project needs and goals and are not presenting specific and effective SE efforts to cope with the real project risks. It appears that many organizations believe that one SEMP size fits all projects, and work effectively from that belief. This panel will discuss the application and tailoring of the SEMP to different domains; how to make it effective. In particular, the panel will consider the following questions and dilemmas: How is the SEMP different than the actual planning? What are the special characteristics of a SEMP for developing: Complex Systems? Systems with high Technology Uncertainty? Systems with high Novelty and Innovation? Systems at a fast pace, or for Agile development? How to integrate effectively the SEMP into the project and system development planning and execution? How to integrate effectively the SEMP into evolutionary processes? How to deal with the most important requirement‐time? Can an effective SEMP contribute to the success of the project?

The INCOSE Systems Engineering Handbook and the Project Management Body of Knowledge

INSIGHTVolume 11, Issue 3 p. 40-41 Forum The INCOSE Systems Engineering Handbook and the Project Management Body of Knowledge Kent Gladstone, Kent Gladstone kent.gladstone@incose.org Search for more papers by this author Kent Gladstone, Kent Gladstone kent.gladstone@incose.org Search for more papers by this author First published: 23 June 2015 https://doi.org/10.1002/inst.200811340AboutPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat No abstract is available for this article. Volume11, Issue3July 2008Pages 40-41 RelatedInformation

3.4.1 Systems Engineering Project: Zero Population Growth by 2020

AbstractThe scientific conclusion as to the primary cause of global warming is human beings. Human use of fossil fuels causes carbon dioxide emissions and the resultant green house effect. To avoid the fast approaching point of global melt down will require halting the population growth. No amount of technological advances to clean emissions will preclude the accumulation of gases in our atmosphere without stabilizing the population causing these emissions. The United Nations (UN) estimate for world population by 2050 is 10.5 billion, a prediction of doom. The current world population is 6.7 billion, if growth slows down to 7.5 billion by 2050 global warming may stabilize. The consequences of global warming are evident today, such as melting of the polar caps, resultant floods and rising coastal waters. To stabilize the situation and avoid disaster something must be done. Imagine you are the Systems Engineer selected to propose the ‘Zero Population Growth by 2020’ project. First you pick up your INCOSE Systems Engineering Handbook and then what would you do?