A Practical Guide to SysML: The Systems Modeling Language

Raytheon.

Part I

Introduction

Outline

Chapter 1 Systems Engineering Overview

Chapter 2 Model-Based Systems Engineering

Chapter 3 Getting Started with SysML

Chapter 4 An Automobile Example Using the SysML Basic Feature Set

Chapter 1

Systems Engineering Overview

Publisher Summary

This chapter introduces the systems engineering approach independent of modeling concepts to set the context for how SysML is used. Systems engineering is a multidisciplinary approach that is intended to transform a set of stakeholder needs into a balanced system solution that meets those needs. Systems engineering is a key practice to address complex and often technologically challenging problems. The systems engineering process includes activities to establish top-level goals that a system must support, specify system requirements, synthesize alternative system designs, evaluate the alternatives, allocate requirements to the components, integrate the components into the system, and verify that the system requirements are satisfied. It also includes essential planning and control processes needed to manage a technical effort. Multidisciplinary teams are an essential element of systems engineering to address the diverse stakeholder perspectives and technical domains to achieve a balanced system solution. The practice of systems engineering continues to evolve with an emphasis on dealing with systems as part of a larger whole. Systems engineering practices are becoming codified in various standards, which is essential to advancing and institutionalizing the practice across industry domains.

Chapter 1 introduces the systems engineering approach independent of modeling concepts to set the context for how SysML is used. It describes the motivation for systems engineering, introduces the systems engineering process, and then describes a simplified automobile design example to highlight how complexity is addressed by the process. This chapter also summarizes the role of standards, such as SysML, to help codify the practice of systems engineering.

The Object Management Group’s OMG SysML™ [1] is a general-purpose graphical modeling language for representing systems that may include combinations of hardware, software, data, people, facilities, and natural objects. SysML supports the practice of model-based systems engineering (MBSE) that is used to develop system solutions in response to complex and often technologically challenging problems.

This chapter introduces the systems engineering approach independent of modeling concepts to set the context for how SysML is used. It describes the motivation for systems engineering, introduces the systems engineering process, and then describes a simplified automobile design example to highlight how complexity is addressed by the process. This chapter also summarizes the role of standards, such as SysML, to help codify the practice of systems engineering.

The next three chapters in Part I introduce model-based systems engineering, and provide an overview of SysML, and a partial SysML model of the automobile design example introduced in this chapter.

1.1 Motivation for Systems Engineering

Whether it is an advanced military aircraft, a hybrid vehicle, a cell phone, or a distributed information system, today’s systems are expected to perform at levels undreamed of a generation ago. Competitive pressures demand that the systems leverage technological advances to provide continuously increasing capability at reduced costs and within shorter delivery cycles. The increased capability drives requirements for increased functionality, interoperability, performance, reliability, and smaller size.

The interconnectivity among systems also places increased demands on systems. Systems can no longer be treated as stand-alone, but behave as part of a larger whole that includes other systems as well as humans. Systems are expected to support many different uses as part of an interconnected system of systems (SoS). These uses drive evolving requirements that may not have been anticipated when the system was originally developed. An example is how the interconnectivity provided by email and smart phones impacts the requirements on our day-to-day activities. Clearly, email and the use of smart phones can result in unanticipated requirements on us, the users of these technologies, and affect who we communicate with, how often, and how we respond. The same is true for interconnected systems.

The practices to develop systems must support these increasing demands. Systems engineering is an approach that has been dominant in the aerospace and defense industry to provide system solutions to technologically challenging and mission-critical problems. The solutions often include hardware, software, data, people, and facilities. Systems engineering practices have continued to evolve to address the increasing complexity of today’s systems, which is not limited to aerospace and defense systems. As a result, the systems engineering approach has been gaining broader recognition and acceptance across other industries such as automotive, telecommunications, and medical equipment, to name a few.

1.2 The Systems Engineering Process

A system consists of a set of elements that interact with one another, and can be viewed as a whole that interacts with its external environment. Systems engineering is a multidisciplinary approach to develop balanced system solutions in response to diverse stakeholder needs. Systems engineering includes the application of both management and technical processes to achieve this balance and mitigate risks that can impact the success of the project. The systems engineering management process is applied to ensure that development cost, schedule, and technical performance objectives are met. Typical management activities include planning the technical effort, monitoring technical performance, managing risk, and controlling the system technical baseline. The systems engineering technical processes are applied to specify, design, and verify the system to be built. The practice of systems engineering is not static, but continues to evolve to deal with increasing demands.

A simplified view of the systems engineering technical processes is shown in Figure 1.1. The System Specification and Design process is used to specify the system requirements and allocate the component requirements to meet stakeholder needs. The components are then designed, implemented, and tested to ensure that they satisfy their requirements. The System Integration and Test process includes activities to integrate the components into the system and verify that the system requirements are satisfied. These processes are applied iteratively throughout the development of the system, with ongoing feedback between the different processes. In more complex applications, there are multiple levels of system decomposition beginning at an enterprise or SoS level. In those cases, variants of this process are applied recursively to each intermediate level of the design down to the level at which the components are purchased or built.

Figure 1.1 Simplified systems engineering technical processes.

The System Specification and Design process in Figure 1.1 includes the following activities to provide a balanced system solution that addresses the diverse stakeholders’ needs:

 Elicit and analyze stakeholder needs to understand the problem to be solved, the goals the system is intended to support, and the effectiveness measures needed to evaluate how well the system supports the goals

 Specify the required system functionality, interfaces, physical and performance characteristics, and other quality characteristics to support the goals and effectiveness measures

 Synthesize alternative system solutions by partitioning the system design into components that can satisfy the system requirements

 Perform trade-off analysis to evaluate and select a preferred solution that satisfies system requirements and provides the optimum balance to achieve the overall effectiveness measures

 Maintain traceability from the system goals to the system and component requirements and verification results to ensure that requirements and stakeholder needs are addressed

1.3 Typical Application of the Systems Engineering Process

The System Specification and Design process can be illustrated by applying this process to an automobile design. A multidisciplinary systems engineering team is responsible for executing this process. The participants and roles of a typical systems engineering team are discussed in Section 1.4.

The team must first identify the stakeholders and analyze their needs. Stakeholders include the purchaser of the car and the users of the car. In this example, the user includes the driver and the passengers. Each of their needs must be addressed. Stakeholder needs further depend on the particular market segment, such as a family car versus a sports car versus a utility vehicle. For this example, we assume the automobile is targeted toward a typical mid-career individual who uses the car for his or her daily transportation needs.

In addition, a key tenet of systems engineering is to address the needs of other stakeholders who may be impacted throughout the system life cycle, so additional stakeholders include the manufacturers that produce the automobile and those who maintain the automobile. Each of their concerns must be addressed to ensure a balanced life-cycle solution. Less obvious stakeholders are governments that express their needs via laws and regulations. Clearly, each stakeholder’s concern is not of equal importance to the development of the automobile, and therefore stakeholder concerns must be properly weighted. Analysis is performed to understand the needs of each stakeholder, and define relevant effectiveness measures with target values. The target values are used to bound the solution space, to evaluate the alternatives, and to discriminate the solution from competitor solutions. In this example, the effectiveness measures may relate to the primary goal for addressing the transportation needs such as performance, comfort, fuel economy, range between refills or recharge, safety, reliability, repair time, purchase cost, environmental impact, and other important but difficult to quantify measures such as aesthetic qualities.

The system requirements are specified to address stakeholder needs and associated effectiveness measures. This begins with a definition of the system boundary so that clear interfaces can be established between the system and external systems and users as shown in Figure 1.2. In this example, the driver and passengers (not shown) are external users who interact with the automobile. The gas pump and maintenance equipment (not shown) are examples of external systems that the vehicle interacts with. In addition, the vehicle interacts with the physical environment such as the road. All of these external systems, users, and the physical environment must be specified to clearly demarcate the system boundary and its associated interfaces.

Figure 1.2 Defining the system boundary.

The functional requirements for the automobile are specified by analyzing what the system must do to support its overall goals. This vehicle must perform functions related to accelerating, braking, and steering, and many additional functions to address driver and passenger needs. The functional analysis identifies the inputs and outputs for each function. As shown in the example in Figure 1.3, the functional requirement to accelerate the automobile requires an acceleration input from the driver and produces outputs that correspond to the automobile forces and the speedometer reading for the driver. The functional requirements analysis also includes specifying the sequence and ordering of the functions.

Figure 1.3 Specifying the functional requirements.

Functional requirements must also be evaluated to determine the required level of performance. As indicated in Figure 1.4, the automobile is required to accelerate from 0 to 60 miles per hour (mph) in less than 8 seconds under specified conditions. Similar performance requirements can be specified for stopping distance from 60 to 0 mph and for steering requirements such as the turning radius.

Figure 1.4 Automobile performance requirements.

Additional requirements are specified to address the concerns of each stakeholder. Example requirements include specifying riding comfort, fuel efficiency, reliability, maintainability, safety, and emissions. Physical characteristics, such as maximum vehicle weight, may be derived from the performance requirements, or maximum vehicle length may be dictated by other concerns such as standard parking space dimensions. The system requirements must be clearly traceable to stakeholder needs and validated to ensure that the requirements address their needs. The early and ongoing involvement of representative stakeholders in this process is critical to the success of the overall development effort.

System design involves identifying system components and specifying requirements for the components needed to satisfy system-level requirements. This may involve first developing a logical system design independent of the technology used, and then a physical system design that reflects specific technology selections. (Note: A logical design that is technology independent may include a component called a torque generator, and alternative physical designs that are technology dependent may include a combustion engine or an electric motor.) In the example shown in Figure 1.5, the system’s physical components include the Engine, Transmission, Differential, Chassis, Body, Brakes, and so on. This system includes a single level of decomposition from the system to component level. However, as indicated earlier, complex systems often include multiple levels of system decomposition.

Figure 1.5 Automobile system decomposes into its components.

Design constraints are often imposed on the solution. A common kind of constraint is to reuse a particular component. For example, there might be a requirement to reuse the engine from the inventory of existing engines. This constraint implies that no additional engine development is to be performed. Although design constraints are typically imposed to save time and money, sometimes analysis reveals that relaxing the constraint would be less expensive and faster. For example, if the engine is reused, expensive filtering equipment might be needed to satisfy newly imposed pollution regulations. On the other hand, the cost of a redesign to incorporate newer technology might be a less expensive alternative. Systems engineers should examine the rationale behind design constraints and inform stakeholders whether the analysis validates the assumptions behind the constraints.

The components are specified such that if their requirements are satisfied, the system requirements are also satisfied. The power subsystem shown in Figure 1.6 includes the Engine, Transmission, and Differential components, and must provide the power to accelerate the automobile. Similarly, the steering subsystem must control the direction of the vehicle, and the braking subsystem must decelerate the vehicle.

Figure 1.6 Interaction among components to achieve the functional and performance requirements.

The component performance and physical requirements are derived by performing engineering analysis to determine what is required from the components to satisfy the system requirements. As an example, an analysis is performed to derive the component requirements for engine horsepower, coefficient of drag of the body, and the weight of each component, to satisfy the system requirement for vehicle acceleration. Similarly, analysis must be performed to derive component requirements from the other system performance requirements related to fuel economy, fuel emissions, reliability, and cost. The requirements for ride comfort may require multiple analyses that address human factors considerations related to road vibration, acoustic noise propagation to the vehicle’s interior, space–volume analysis, and placement of displays and controls, to name a few.

The system design alternatives are evaluated to determine the preferred system solution that achieves a balanced design that addresses multiple competing requirements. In this example, the requirements to increase the acceleration and fuel economy represent competing requirements which are subject to trade-off analysis to achieve a balanced design. This may result in evaluating alternative engine design configurations, such as a 4-cylinder versus a 6-cylinder engine. The alternative designs are then evaluated based on criteria that are traceable to the system requirements and effectiveness measures. The preferred solution is validated with the stakeholders to ensure that it addresses their needs.

The component requirements are input to the Component Design, Implementation, and Test process from Figure 1.1. The component developers provide feedback to the systems engineering team to ensure that component requirements can be satisfied by their designs, or they may request that the component requirements be reallocated. This is an iterative process throughout development that is often required to achieve a balanced design solution.

The system test cases are also defined to verify the system satisfies its requirements. As part of the System Integration and Test process, the verified components are integrated into the system, and the system test cases are executed to verify the system requirements are satisfied.

As indicated in Figure 1.7, requirements traceability is maintained between the Stakeholder Needs, the System Requirements, and the Component Requirements to ensure design integrity. For this example, the system and component requirements, such as vehicle acceleration, vehicle weight, and engine horsepower, can be traced to the stakeholder needs associated with performance and fuel economy.

Figure 1.7 Stakeholder needs flow down to system and component requirements.

A systematic process to develop a balanced system solution that addresses diverse stakeholder needs becomes essential as system complexity increases. An effective application of systems engineering requires maintaining a broad system perspective that focuses on the overall system goals and the needs of each stakeholder, while at the same time maintaining attention to detail and rigor that will ensure the integrity of the system design. The expressiveness and level of precision of SysML is intended to enable this process.

1.4 Multidisciplinary Systems Engineering Team

To represent the broad set of stakeholder perspectives, systems engineering requires participation from many engineering and non-engineering disciplines. The participants must have an understanding of the end-user domain, such as the drivers of the car, and the domains that span the system life cycle such as manufacturing and maintenance. The participants must also have knowledge of the system’s technical domains such as the power and steering subsystems, and an understanding of the specialty engineering domains, such as reliability, safety, and human factors, to support the system design trade-offs. In addition, they must have sufficient participation from the component developers and testers to ensure the specifications are implementable and verifiable.

A multidisciplinary systems engineering team should include representation from each of these perspectives. The extent of participation depends on the complexity of the system and the knowledge of the team members. A systems engineering team on a small project may include a single systems engineer, who has broad knowledge of the domain and can work closely with the hardware and software development team and the test team. On the other hand, the development of a large system may involve a systems engineering team led by a systems engineering manager who plans and controls the systems engineering effort. This project may include tens or hundreds of systems engineers with varying expertise.

A typical multidisciplinary systems engineering team is shown in Figure 1.8. The Systems Engineering Management Team is responsible for the management activities related to planning and control of the technical effort. The Requirements Team analyzes stakeholder needs, develops the concept of operations, and specifies and validates the system requirements. The Architecture Team is responsible for synthesizing the system architecture by partitioning the system components, and defining their interactions and interconnections. This includes allocating the system requirements to the components that may include hardware and software specifications. The Systems Analysis Team is responsible for performing the engineering analysis on different aspects of the system, such as performance and physical characteristics, reliability, maintainability, and cost. The Integration and Test Team is responsible for developing test plans and procedures and conducting the tests to verify the requirements are satisfied. There are many different organizational structures to accomplish similar roles, and individuals may participate in different roles on different teams.

Figure 1.8 A typical multidisciplinary systems engineering team needed to represent diverse stakeholder perspectives.

1.5 Codifying Systems Engineering Practice through Standards

As mentioned earlier, systems engineering has become a dominant practice within the aerospace and defense industries to engineer complex, mission-critical systems that leverage advanced technology. These systems include land, sea, air, and space-based platforms; weapon systems; command, control, and communications systems; and logistics systems, to name a few. Due to the interconnected nature of systems, the emphasis for systems engineering has shifted to treat a system as part of a larger whole, which is sometimes referred to as a system of systems (SoS) or an enterprise.

The complexity of systems being developed in other industry sectors has dramatically increased due to the competitive demands and technological advances discussed earlier in this chapter. Specifically, many commercial products incorporate the latest processing and networking technology that have significant software content with substantially increased functionality, and are more interconnected with increasingly complex interfaces. The products are used in new ways, such as what occurred with the integration of cell phones with cameras, and the use of global positioning systems in automobiles that were not previously envisioned. Systems engineering is being applied to many other industries to help deal with this complexity. The need to establish standards for systems engineering concepts, terminology, processes, and methods has become increasingly important to advance and institutionalize the practice of systems engineering across industry sectors.

Systems engineering standards have evolved over the last several years. Figure 1.9 shows a partial taxonomy of standards that includes systems engineering process standards, architecture frameworks, methods, modeling standards, and data exchange standards. A comprehensive standards-based approach to systems engineering may implement at least one standard from each layer of this taxonomy.

Figure 1.9 A partial systems engineering standards taxonomy.

A primary emphasis for systems engineering standards has been on developing process standards that include EIA 632 [2], IEEE 1220 [3], and ISO 15288 [4]. These standards address broad industry needs and reflect the fundamental tenets of systems engineering that provide a foundation for establishing a systems engineering approach.

The systems engineering process standards share much in common with software engineering practices. Management practices for planning, as an example, are similar whether it is for complex software development or systems development. As a result, there has been significant emphasis in the standards community on aligning the systems and software standards where practical.

The systems engineering process defines what activities are performed, but does not generally give details on how they are performed. A systems engineering method describes how the activities are performed in terms of the types of artifacts that are produced and how they are developed. For example, an important systems engineering artifact is the concept of operations. As its name implies, the concept of operations defines what the system is intended to do from the user’s perspective. It depicts the interaction of the system with its external systems and users, but may not show any of the system’s internal operations. Different methods may use different techniques and representations for developing a concept of operations. The same is true for many other systems engineering artifacts.

Examples of systems engineering methods are identified in a Survey of Model-Based Systems Engineering Methods [5] and include Harmony [6, 7], the Object-Oriented Systems Engineering Method (OOSEM) [8], the Rational Unified Process for Systems Engineering (RUP SE) [9, 10], the State Analysis method [11], the Vitech Model-Based Systems Engineering Method [12], and the Object Process Method (OPM) [13]. Many organizations have internally developed processes and methods as well. The methods are not official industry standards, but de facto standards may emerge as they prove their value over time. Criteria for selecting a method include its ease of use, its ability to address the range of systems engineering concerns, and the level of tool support. The two example problems in Part III include the use of SysML with a functional analysis and allocation method and a scenario-driven method (OOSEM). SysML is intended to support many different systems engineering methods.

In addition to systems engineering process standards and methods, several standard frameworks have emerged to support system architecting. An architecture framework includes specific concepts, terminology, artifacts, and taxonomies for describing the architecture of a system. The Zachman Framework [14] was introduced in the 1980s to define enterprise architectures; it defines a standard set of stakeholder perspectives and a set of artifacts that address fundamental questions associated with each stakeholder group. The C4ISR framework [15] was introduced in 1996 to provide a framework for architecting information systems for the U.S. Department of Defense (DoD). The Department of Defense Architecture Framework (DoDAF) [16] evolved from the C4ISR framework to support architecting a SoS for the defense industry by defining the architecture’s operational, system, and technical views.

The United Kingdom introduced a variant of DoDAF called the Ministry of Defence Architecture Framework (MODAF) [17] that added the strategic and acquisition views. The IEEE 1471-2000 standard was approved in 2000 as a Recommended Practice for Architectural Description of Software-Intensive Systems [18]. This practice provides additional fundamental concepts, such as the concept of view and viewpoint that applies to both software and systems architecting, and has more recently been superseded by ISO/IEC 42010:2007 [19]. The Open Group Architecture Framework (TOGAF) [20] was originally approved in the 1990s as a method for developing architectures.

Modeling standards is another class of systems engineering standards that includes common modeling languages for describing systems. Behavioral models and functional flow diagrams have been de facto modeling standards for many years, and have been broadly used by the systems engineering community. The Integration Definition for Functional Modeling (IDEF0) [21] was issued by the National Institute of Standards and Technology in 1993. The OMG SysML specification was adopted in 2006 by the Object Management Group as a general-purpose graphical systems modeling language that extends the Unified Modeling Language (UML) and is the subject of this book. Several other extensions of UML have been developed for specific domains, such as the Unified Profile for DoDAF and MODAF (UPDM) [22] to describe system of systems and enterprise architectures that are compliant with DoDAF and MODAF requirements. The foundation for the UML-based modeling languages is the OMG Meta Object Facility (MOF) [23], which is a language that is used to specify other modeling languages. There are many other relevant system modeling standards such as Modelica [24], which is a simulation modeling language, and the High Level Architecture (HLA) [25] that is used to support the design and execution of distributed simulations, and MathML which defines a comprehensive language for describing mathematical equations.

Model and data interchange standards is a critical class of modeling standards that supports model and data exchange among tools. Within the OMG, the XML Metadata Interchange (XMI) specification [26] supports interchange of model data when using an MOF-based language such as UML, SysML, or another UML extension. XMI is summarized in Chapter 18, Section 18.4.2. Another data exchange standard for interchange of systems engineering data is ISO 10303 (AP233) [27], which is also briefly described in Chapter 18, Section 18.4.2.

Additional modeling standards from the Object Management Group relate to the Model Driven Architecture (MDA®) [28]. MDA includes a set of concepts that include creating both technology-independent and technology-dependent models. The MDA standards enable transformation between models represented in different modeling languages as described in the MDA Foundation Model [29]. The OMG Query View Transformation (QVT) [30] is a modeling standard that defines a mapping language to precisely specify language transformations. MDA encompasses OMG standards in both the Modeling and Interchange layers of Figure 1.9.

The development and evolution of these standards are all part of a trend toward a standards-based approach to the practice of systems engineering. Such an approach enables common training, tool interoperability, and reuse of system specification and design artifacts. It is expected that this trend will continue as systems engineering becomes prevalent across a broader range of industries.

1.6 Summary

Systems engineering is a multidisciplinary approach which is intended to transform a set of stakeholder needs into a balanced system solution that meets those needs. Systems engineering is a key practice to address complex and often technologically challenging problems. The systems engineering process includes activities to establish top-level goals that a system must support, specify system requirements, synthesize alternative system designs, evaluate the alternatives, allocate requirements to the components, integrate the components into the system, and verify that the system requirements are satisfied. It also includes essential planning and control processes needed to manage a technical effort.

Multidisciplinary teams are an essential element of systems engineering to address the diverse stakeholder perspectives and technical domains to achieve a balanced system solution. The practice of systems engineering continues to evolve with an emphasis on dealing with systems as part of a larger whole. Systems engineering practices are becoming codified in various standards, which is essential to advancing and institutionalizing the practice across industry domains.

1.7 Questions

1. What are some of the demands that drive system development?

2. What is the purpose of systems engineering?

3. What are the key activities in the system specification and design process?

4. Who are the typical stakeholders that span a system’s life cycle?

5. What are different types of requirements?

6. Why is it important to have a multidisciplinary systems engineering team?

7. What are some of the roles on a typical systems engineering team?

8. What role do standards play in systems engineering?

Chapter 2

Model-Based Systems Engineering

Publisher Summary

Model-based systems engineering (MBSE) applies systems modeling as part of the systems engineering process to support analysis, specification, design, and verification of the system being developed. A primary artifact of MBSE is a coherent model of the system being developed. This approach enhances specification and design quality, reuse of system specification and design artifacts, and communications among the development team. This chapter summarizes MBSE concepts to provide further context for SysML without emphasizing a specific modeling language, method, or tool. The emphasis for MBSE is to produce and control a coherent system model and use this model to specify and design the system. Modeling can support many purposes, such as to represent a system concept or specify system components. A good model meets its intended purpose, and the scope of the model should support its purpose within the resource constraints of the modeling effort. Quality attributes of a model, such as model consistency, understandability, and well-formedness, and the use of modeling conventions, can be used to assess the effectiveness of a model and to drive preferred modeling practices. MBSE metrics can be used to assess design quality, progress, and risk and support management in the development effort. MBSE is contrasted with the more traditional document-based approach to motivate the use of MBSE and highlight its benefits. Principles for effective modeling are also discussed.

Chapter 2 summarizes model-based systems engineering (MBSE) concepts to provide further context for SysML without emphasizing a specific modeling language, method, or tool. MBSE is contrasted with the more traditional document-based approach to motivate the use of MBSE and highlight its benefits. Principles for effective modeling are also discussed including a discussion on model-based metrics.

Model-based systems engineering (MBSE) applies systems modeling as part of the systems engineering process described in Chapter 1 to support analysis, specification, design, and verification of the system being developed. A primary artifact of MBSE is a coherent model of the system being developed. This approach enhances specification and design quality, reuse of system specification and design artifacts, and communications among the development team.

This chapter summarizes MBSE concepts to provide further context for SysML without emphasizing a specific modeling language, method, or tool. MBSE is contrasted with the more traditional document-based approach to motivate the use of MBSE and highlight its benefits. Principles for effective modeling are also discussed.

2.1 Contrasting the Document-Based and Model-Based Approach

The following sections contrast the document-based approach and the model-based approach to systems engineering.

2.1.1 Document-Based Systems Engineering Approach

Traditionally, large projects have employed a document-based systems engineering approach to perform the systems engineering activities referred to in Chapter 1, Section 1.2. This approach is characterized by the generation of textual specifications and design documents, in hard-copy or electronic file format, that are then exchanged between customers, users, developers, and testers. System requirements and design information are expressed in these documents and drawings. The systems engineering emphasis is placed on controlling the documentation and ensuring the documents and drawings are valid, complete, and consistent, and that the developed system complies with the documentation.

In the document-based approach, specifications for a particular system, its subsystems, and its hardware and software components are usually depicted in a hierarchical tree, called a specification tree. A systems engineering management plan (SEMP) documents how the systems engineering process is employed on the project, and how the engineering disciplines work together to develop the documentation needed to satisfy the requirements in the specification tree. Systems engineering activities are planned by estimating the time and effort required to generate documentation, and progress is then measured by the state of completion of the