6.3 Requirements Analysis

Requirements Analysis starts with the inputs defined in Section 6.2 of the previous post and analyzes the mission and associated environments to establish a Requirements Database.  Figure 6.4 in the second previous post shows that the Requirements Analysis Task is carried out iteratively with Functional Analysis/Allocation, with Technical Management and with Verification tasks. The NASA and IEEE handbooks define the subtasks of Requirements Analysis with flowcharts. The DoD SEF lists the 15 subtasks named in the IEEE flowchart and provides a description of each. Figure 6.5 below is a streamlined version of the IEEE flowchart; listing the 15 tasks using the IEEE and DoD SEF numbering. Several of the tasks are renamed to explicitly include analyzing the entire life cycle for environments, scenarios and modes rather than just those associated with the system in its operational mode. Task 13 is retitled from Technical Performance Measures (TPM) to broaden the scope to include TPMs, Key Performance Parameters (KPP) and any other metrics or Measures of Effectiveness (MOE) the team or customers believe are needed.

There are five types of requirements as defined in the DoD SEF:

•           Functional Requirements - The necessary task, action or activity that must be accomplished. Functional (what has to be done) requirements identified in requirements analysis will be used as the top level functions for functional analysis.

•           Performance Requirements - The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness.

•           Design Requirements - The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.

•           Derived Requirements - Requirements that are implied or transformed from higher-level requirement.

•           Allocated Requirements - A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements.

The 15 tasks are structured so that all necessary requirements of each type are identified and documented in the Requirements Database. Each requirement must be traceable back to the input documentation or to a mission need derived from analyzing mission needs to ensure that no extraneous requirements are added.

The requirements analysis process is presented as a sequential process. These steps typically overlap and work previously completed may need to be adjusted as the detailed knowledge of all the requirements becomes more fully understood. Tasks are grouped in Figure 6-5 because the tasks in a group don’t need to be done in any specific order and some can be done in parallel. Tasks 1 to 9 and 12 to 15 analyze the system as a single entity. Tasks 10 and 11 begin the decomposition of the system into logical functional components (task 10) and begin to allocate performance parameters to these components (task 11). Tasks 10 and 11 feed directly into the Functional Analysis/Allocation and Systems Analysis tasks and receives information back from these associated tasks as indicated in the figure.

Executing the 15 tasks involves making many decisions and defining many relationships. As the many decisions are made and relationships are examined, it is critical that they are documented and tracked to facilitate updating tasks as new information is available.

Attempting to do requirements analysis without the use of supporting methods and diagrams is like trying to do math without equations and special symbols. It is possible but much more difficult and leads to more mistakes. The methods and diagrams selected for discussion in the following sections are not meant to be the only possible choices or a complete set; rather those presented are selected because they illustrate an important part of systems thinking or offer alternatives to conventional approaches covered in standard handbooks.

A principle behind offering alternatives is that when there are two ways to do a systems engineering task or two ways to present the results it is often beneficial to use both ways. This is because one offers a self-check on the other and some reviewers are able to critique one way better than another when the work is presented to peer reviewers. Once something is complete in one format or by using one tool repeating it in another format or with another tool takes little more time than carefully reviewing the accuracy of the first way and is much better at catching errors.

Inputs and Outputs for Defining a System

The tools and processes used to define the system via the steps of requirements analysis, functional analysis, design synthesis and verification can be divided into those that treat the system as a single element, i.e. treat the relationships and interfaces between the system and its environment and other entities; and those that decompose the system into subsystems and treat the relationships and interfaces between the subsystems.  (Verification is treated in a subsequent chapter as a systems engineering task called Verifying the Technical Performance.) Think of Figure 6-4 in the previous post being the process for a system as a single entity and then think of this process being repeatedly applied to each decomposed element of the system hierarchy.

The INCOSE Handbook defines a system hierarchy as:

• System
• Element
• Subsystem
• Assembly
• Subassembly
• Component
• Part

In this material the INCOSE hierarchy is followed with one exception; the term element is left out of the hierarchy and is used for which ever level of the hierarchy is being considered. That is the term design element refers to the system, subsystem, assembly, subassembly, component or part being analyzed or designed.

As elements become less complex the systems engineering work for each loop becomes less and less but does not vanish. For example, the functional analysis needed for a fastener is rudimentary but it is necessary to think through, if not document,  whether the fastener is required to maintain stability of the parts it is holding in three dimensions, allow translation in one or two dimensions or rotation around its axis. This is one of the reasons it is troublesome to distinguish between systems engineers and design engineers. The design engineers must execute the processes defined in Figure 6-4 to some degree depending on the complexity of the element they are designing.

Although a key methodology for requirements analysis, Use Case analysis is treated only lightly in this chapter. It is covered in more detail in a separate chapter because it is particularly important for supporting model based approaches. Assessment and management of risk is such an important technical management process that it is also treated in a subsequent chapter, as is the trade study task of selecting the preferred design.

It is hoped that the complexity of treating systems engineering processes via a different set of tasks rather than the obvious choice defined by the DoD diagram shown in Figure 6-4 is offset by the benefits to the reader of having to think about systems engineering in more than one way and that this will encourage thinking that may lead to new and better methods that will be needed in the future as systems continue to become more and more complex.

6.2 Inputs and Outputs of the Systems Engineering Process

Before beginning to describe the methods and tools used to execute each block and loop in the systems engineering process as defined in Figure 6-4 it is helpful to define the inputs to the overall process and the desired outputs.  A partial list of inputs is provided in Figures 3-1 and 4.2 of the DoD SEF. These inputs are partitioned into the three categories: Inputs to be converted to Outputs, Controls and Enablers. A more complete list of inputs in these three categories plus a fourth category of Constraints Imposed by Internal Resources includes:

• Inputs to be Converted to Outputs:
• Customer Needs/Objectives/Requirements (Part of The Voice of the Customer)
• Missions
• Measures of Effectiveness (MOE)
• Sys. Eng. Output Documentation (Patterns and Templates), Models, Simulations from Prior Development Efforts and from Internal Investments
• Controls:
• Technology Base available from Strategic Partners, Teammates, Suppliers and from Internal Investments
• Requirements Applied Through Specifications and Standards
• Laws and Organizational Policies and Procedures
• Customer Imposed Constraints (Budgets, Schedules, Documentation & Reporting Requirements, Other)
• Integration & Test and Utilization Environments
• Product/Competitive Strategies
• Program Decision Requirements (How the customer will make decisions; including which requirements are most important to the customer.)
• Enablers:
• Decision and Requirements Data Bases from Prior Development Efforts
• Multi-disciplinary Product Development Teams
• Development Organization’s Domain Knowledge
• Constraints Imposed by Internal Resources
• Engineering and Production Skills Availability
• Production Process Availability and Maturity
• Integration,  Test and Production Facilities and Capital Budget

This list does not include two items from Figure 4-2 of the DoD SEF. Maintenance Concept and Other Life-Cycle Function Planning is assumed here to be included in Customer Needs/Objectives/Requirements. System Analysis and Control is viewed here as part of the Systems Engineering Process rather than an enabler.

The list includes items contained in documentation supplied by the customer and items that are related to the organization’s capabilities. The inputs are usually incomplete in that there are requirements that are necessary but not initially known. These requirements must be derived during the systems engineering work. It is not unusual for the customer’s statement of needs, objectives and requirements to be incomplete, ambiguous or even contradictory when examined in detail.

As discussed in chapter 1 sometimes customers expect the development organization to complete the development of the input requirements, working closely with the customer, as part of the system development. Also, sometimes customers specify mission level requirements so that considerable systems analysis is needed to define system requirements that will satisfy the mission needs. Any constraints imposed by the enterprise’s product/competitive strategies and internal resources that impact the product design should be identified and documented in the IMP during the project planning. Finally, note that some of the items on the list are easily defined, e.g. specifications and the internal constraints listed, and some are not, e.g. the organization’s domain knowledge (Domain knowledge is the detailed knowledge of the customer’s mission and of the systems used to satisfy this mission).

The outputs of the systems engineering process are dependent on the level of the system hierarchy and include:

·         Baseline Design (System Specification, ICD, Functional Diagrams, & Physical Diagrams)

·         System Design Database

o   Requirements database

o   System Design Document (SDD) that captures Baseline Design Diagrams and:

§  Updated Information Architecture and Document Tree

§  Various diagrams, tables and matrices used to analyze, derive and verify requirements (e.g. context diagrams, Concept of Operation/Use Case diagrams and QFD tables)

§  TPMs, KPPs, MOEs for Baseline Design

§  Design Verification Plans

§  Failure Analysis Database

o   Configuration Management Database

o   Decision Database

o   Data Dictionary

·         Updated Pattern &Template Database

·         Expanded/Refined Models & Simulations

·         Updated Risk Register

·         Refined Technology Base Knowledge, including Updates to Qualified Supplier Capabilities

·         Updates to Manufacturing, System Integration and Test Process/Facility Plans

Some of the outputs are new documentation, some are updates to existing documentation/databases, some are updates or new data for organizations supporting the engineering team and some is captured only in the skills and domain knowledge of the development team. Comparing the list of inputs and outputs for the systems engineering process begins to reveal the breadth and depth of work and the thousands upon thousands of decisions being made in the systems engineering work. Without the use of modern methods and tools this work can be time consuming, expensive and error prone. Shortchanging this work often causes product design problems that are far more costly than thorough systems engineering and does not build the capabilities of the enterprise for future product developments.

The system design process is fundamentally a requirements analysis process even though it is divided into the tasks shown in Figure 6-4. The output requirements are expressed in three different ways or from three different perspectives as defined in the DoD SEF. These different perspectives are called the Operational, Functional and Physical views:

·         The Operational view describes the operational behavior of the system; how it does its job, how well and under what conditions.

·         The Functional view describes what the system must do to achieve the required operational behavior.

·         The Physical view describes how the system is constructed and how it interfaces with other systems and system operators.

The collection of documentation, diagrams, etc. developed under the Requirements Analysis task constitutes the Operational view. Similarly the products resulting from the Functional Analysis and Allocation task are the Functional view and the products resulting from the Design Synthesis task are the Physical view. Readers are referred to Chapter 4 of the DoD SEF for a listing of information that might typically be included in each view. Our emphasis here is on the rational for the systems engineering tasks and describing methods and tools useful in these tasks rather than trying to exhaustively list every task and every output.

Processes and Tools for Defining a System

6.0 Introduction - In Chapter 3 the product development cycle was defined in the simplest possible terms as “define, design, build, test and produce”. Four systems engineering tasks were defined to be carried out over the development cycle although there is not a one to one correspondence between the five steps in the development cycle and the four systems engineering tasks. Chapter 4 discussed processes and tools for the first systems engineering task, Plan the Program. This chapter addresses the second systems engineering task, Define the System. Chapters 8 and 9 address the remaining two tasks, Selecting the Preferred Design and Verifying the Technical Performance. After some introductory material this chapter and chapters 8 and 9 cover the systems engineering process as  described  in Figure 3-1 of the DoD SEF handbook. Because of the four task approach being followed in this text the flow does not follow the DoD systems engineering process step by step. However, this text follows the DoD nomenclature as much as possible and adds some useful tools. It is hoped that the reader studies both this text and the DoD SEF handbook and that, by studying the process in two different ways, gains deeper insight into systems engineering.

6.1 Overview of System Development and System Engineering Processes

System  development is a complex process and there are almost as many diagrams defining this process as there are handbooks of systems engineering. Before showing diagrams illustrating the Define the System task it is helpful to examine some of the more popular diagrams. Rather than repeat the detailed diagrams, which are available in the referenced handbooks, simplified diagrams are presented here that just show the approach to defining the development process or the systems engineering portion of the development process. The reader should always keep in mind the five fundamental steps of define, design, build, test and produce to keep oriented when examining these diagrams.

6.1.1System Development Diagrams - Perhaps the most popular diagram historically is the “VEE” diagram, which is shown in the NASA Systems Engineering Handbook SP610S of June 1995 and attributed to Kevin Forsberg and Harold Mooz, A Commitment to Success, Proceedings of the first annual meeting of the National Council for Systems Engineering and the 12th annual meeting of the American Society for Engineering Management, Chattanooga, TN, 20-23 October 1991. The VEE diagram describes the overall development process as a downward flow of decomposition and definition, connected to an upward flow of integration and verification as shown in the simplified diagram in Figure 6-1. The decomposition and definition starts at the top left with the “requirements analysis” task and ends with a tested system at the top right. This diagram is appealing because it illustrates both the “flow down” and “flow up” aspects and the sequential progress of the overall process with a rightward flow suggesting time or schedule. The time flow enables listing sequential tasks or design reviews along each leg of the V.

Figure 6-1 A VEE diagram illustrates tasks in two of the main activities of system development.

The 2007 version of the NASA handbook replaces the VEE with a more detailed diagram that adds the technical management and control aspects of the development process and changes some of the nomenclature. A simplified version of this diagram is shown in Figure 6-2. Although the 2007 diagram lacks some of the ascetic appeal of the VEE diagram it is more representative of the complexity of the overall process. This diagram also substitutes the more abstract descriptions  “system design processes” and “product realization processes” for the more descriptive and simple terms “decomposition and definition” and “integration and verification” used in the VEE diagram. This tendency to abstract the processes for completeness at the expense of clarity is a primary reason to keep coming back to the simplest terms of define, design, build, test and produce.

6.1.2 System Engineering Process Diagrams - The IEEE 1220-1998 and DoD handbooks focus on the system design part of the overall development process and provide more detail on this part. A simplified version of the IEEE system engineering process diagram is

Figure 6-2 The system development process as defined in the NASA Systems Engineering Handbook SP-2007-6105 Rev 1, Dec 2007 includes the technical management processes.

shown in Figure 6-3.  This diagram more explicitly brings in the important trade studies and assessment activities that are necessary for achieving a good system design and lumps the technical control processes into one box labeled Control.

Finally, the DoD handbook illustrates the system engineering process with a diagram that includes the important iterative nature of system design. A modified version of the DoD diagram that includes the technical management processes from the NASA diagram is shown in Figure 6-4. It also explicitly includes trade studies as in the IEEE diagram.

The DoD diagram more explicitly represents the iterative rather than sequential nature of systems design. One aspect of design that isn’t obvious in these standard diagrams is the option for design synthesis being either top down, bottoms up, or a combination of top down and bottoms up. An example of the bottoms up design approach is designing a new car model by choosing from sets of available engines, transmissions, suspension systems and other major subsystems. Many of the requirements analysis, trade studies and assessments involved in top down design are still needed to ensure a balanced design and verify the design but the overall development process is streamlined by having proven subsystems available for the class of system being developed. An experienced systems engineer can interpret the loops in the DoD diagram as allowing for starting a process at any point on a loop but this isn’t apparent to the novice. The remaining discussion in this chapter treats the system design processes as top down for convenience but should not be interpreted as endorsing only a top down design approach.

Figure 6-3 A simplified version of the IEEE 1220 diagram defining the systems engineering process illustrating the three types of trade studies and analysis central to systems design.

Figure 6-4 A Combination of the NASA and DoD diagrams of the systems engineering process includes the technical management processes, the three verification processes and illustrates the iterative nature of requirements analysis, design synthesis.

By now the reader should have concluded that the system design process is sufficiently complicated that it isn’t easily defined in any one diagram. Similarly, systems are sufficiently complicated that many diagrams are needed to adequately define them. It isn’t wise to attempt to define a fixed list of diagrams and documents needed to define systems either because the complexity of a system and the maturity of the development team usually determine what diagrams are necessary.

Getting Started with Pattern Based Systems Engineering

 Developing Patterns and Templates - An enterprise that sets out to develop patterns for the diagrams, documents and models used in their product lines has several possible approaches. One is to assign a team of highly experienced systems engineers to develop the patterns for a family of systems from scratch. This is an effective approach but it can be an expensive approach, even if experienced consultants are used to facilitate the process. However, it does achieve the desired patterns in a few weeks or months so that the patterns are available for near term design efforts. Often the expense is justified because having the patterns provides a competitive advantage over enterprises not used PBSE by significantly reducing the cost of the systems engineering portion of developing new products. If the experienced engineers are waiting for a new job to start then they can work on developing patterns at no additional cost to the enterprise.

A second approach is to save copies of the diagrams from a previous design effort and treat the copies as draft patterns. The diagrams for a current design effort are developed in two steps. First, all new items are added to the draft pattern diagram and none of the items in the draft pattern are deleted even if they don’t apply to the current design. The resulting diagrams and models are saved as revised draft patterns. Second, the revised draft patterns are edited to delete items that don’t apply to the new design effort. These diagrams and models are saved as the working documentation for the new design effort. This approach can take considerable time to develop patterns that are complete but it has the advantage of being nearly cost free.

Of course it is possible to combine the two approaches by initiating the second approach and then assigning experienced engineers that are temporarily between jobs to continuing the development of patterns. In all three approaches it is critical to thoroughly peer review the resulting patterns in order to have confidence that the patterns evolve to become complete and accurate.

Specific examples of models that should become patterns are presented in the following chapters as part of the description of the tasks systems engineers perform in carrying out the systems engineering process. This is a somewhat awkward way to present PBSE but it avoids having to present two versions of all of the models used in the systems engineering process. In some cases two or more methods are described for the same task; the intent is that the different methods can be used to verify the accuracy of work. Also individual engineers may have preferences for diagrams over matrices or vice versa. All methods should be considered candidates for patterns. Finally, in the version of PBSE presented here we include templates for text documentation as part of PBSE so that we extend the definition of PBSE beyond pure MBSE. We do this because many customers require text documents for items such as specifications, and because some documentation e.g. plans and data dictionaries are done in text documents. Using templates speeds the production of text documents and improves their accuracy just as using patterns speeds the production of labeled graphical models and improves their accuracy.

Candidate Models and Documents for Patterns – Listed here are example models and documents that are candidates for developing patterns and templates that support PBSE. Some are planning documents previously describes, some are described in subsequent chapters and some are outside of the scope of systems engineering. Not all apply to every type of system development but many do and not all possible candidates are listed.  It is suggested that readers consider how to develop plans discussed in previous postings as templates. As systems engineering models and documents are described in the following chapters consider how these items can be developed as patterns for their specific organizations and systems.

Pattern Diagrams for a Family of Products:

• Parameter Diagrams at System and Key Subsystem Levels
• Context (or Domain) Diagram
• Logical Architecture Diagram
• Modes Diagram
• Sub Modes Diagrams
• Functional Flow Block Diagrams at Top and Second Level
• N-Squared Interface Diagram
• System Block Diagram
• Control Electronics Block Diagram (For products have digital processors and/or digital controllers)

Document Templates for Family of Products:

• Integrated Management Plan and SEMP
• Information Architecture (Document tree)
• System Specification
• Interface Control Document
• Mapping and Transition Matrices
• Top Level Quality Control/Mission Assurance Document
• Subordinate Quality Control/Mission Assurance Plans
• Design Description Document
• Typically Used Electronics Sub Systems Specifications
• Any Subsystems likely in most Products in Family
• Dictionary of Definitions

Consider what fraction of the total cost of a system development is involved in developing the models and documents listed. The cost likely varies with the type of system and organization but suppose it’s ten percent. If using patterns and templates saves half the time and cost, a very conservative estimate based on the authors’ experience, then the use of PBSE gives an organization a five percent cost advantage over its competition. If an organization doesn’t adopt PBSE and its competitors do then the organization is likely to be at least at a five percent cost disadvantage. In today’s global competitive environment cost advantages translate directly into bottom line profits or into increased market share with even greater contributions to the bottom line profits. Thus there is a high return on the investment necessary to develop and manage a pattern and template database.

Requirements Reuse and Decision Management

Our objective for PBSE is to achieve reuse of more than diagrams, documents and models; these items are part of defining requirements and reuse of requirements is also an objective. Decisions are a central part of the requirements analysis process and reuse of decisions facilitates reusing requirements. Reuse saves time and money but it is not achieved for free. Requirements and decisions must be managed properly in order to achieve reuse. Understanding the importance of decisions in requirements analysis is helped by examining requirements analysis via the diagram in Figure 5-1. The ideas presented here are reexamined in the next chapter but this preview is provided that helps explains why so much attention is paid to the details of requirements analysis in the next chapter.

Figure 5-1 Decisions are an essential part of requirements analysis.

It is important to recognize that the value in reusable decisions is for more than facilitating the reuse of a previously used requirement or to facilitate reuse on a subsequent system development. Decisions are reusable during the life cycle of products. Problems can arise in system test or in production whose resolution requires understanding the rational for the design decisions. Potential design changes may be considered for cost savings or due to obsolete or unavailable components. In all of these cases if the rational for design decisions is not readily available and trusted then systems engineering work has to be repeated. Thus the extra cost incurred in making decisions reusable is more than recovered through savings from both reuse and from avoidance of rework.

The process of making decisions involves defining criteria, developing alternatives, conducting trades among the alternatives using a formal or informal trade study process that considers other input data to the requirements analysis process, e.g. technology readiness levels and supplier capabilities, and selecting the best alternative for the defined criteria. The NASA Systems Engineering Handbook has extensive discussion of decision analysis that is well worth reading. Two useful tools included in the NASA description are the decision matrix and an outline for a decision report. A decision matrix is a useful tool for making decisions based on weighted criteria.

Requirements from customers or market analysis drive criteria that are used by systems engineers in making decisions about system requirements. The resulting system requirements drive criteria for making decisions about lower level requirements. In describing requirements analysis verbs such as allocate, flow down, and estimate are used but all of these are fundamentally a decision making process as shown in Figure 5-1.

Figure 5-1 shows how closely requirements and decisions are connected and therefore why the desire for both reusable decisions and reusable requirements. If requirements are reusable time is saved but if the related decisions are reusable then design attributes, risks and issues driven by the decisions are understood. If the decisions are reusable then it is likely that the designs attributes are reusable; risks created by the decisions are likely to have been mitigated in previous work and issues created are likely to be known and resolved.

Achieving reusable requirements and decisions involves additional work but work that pays dividends both during the system life cycle and in future developments. Figure 5-2 shows that requirements traceability is the foundation of sound requirements analysis but traceability alone is not sufficient for either sound systems engineering practice or for achieving reusability. The attributes of requirements resulting from a robust requirements analysis process that leads to control and then to reusability are indicated in the figure.

 Figure 5-2 Achieving requirements reuse requires comprehensive requirements analysis.

Similarly achieving reuse of decisions also requires a comprehensive process as shown in Figure 5-3. The use of the pyramid format in the figures is meant to indicate that there are benefits from the doing the additional work necessary to move up the pyramid. It will be helpful for the reader to review these two figures after reading the sections on requirements analysis in chapter 6.

Figure 5-3 Planning and analysis is necessary to achieve reuse of decisions made in requirements analysis.

The close connection between requirements management and decision management suggests the two can be integrated into a common process called data management. Data management is facilitated if the tool used for requirements management has the capability for including decision modules or links to technical memos, as do some modern requirements management tools. If simple tools like spreadsheets are used for requirements management for small systems then inset links to technical memos that capture the decision rationale and supporting data associated with requirements. Properly capturing decision rationale and supporting data helps eliminate rework and facilitates reuse of requirements analysis work. The outline for a decision report described in the NASA Systems Engineering Handbook is a good guideline for properly documenting decisions and making decisions reusable.

Introduction to Pattern Based Systems Engineering

“Each Problem that I solved became a rule which served afterwards to solve other problems” - René Descartes

Reusable Systems Engineering Products – Descartes’ experience is not unique. Experienced engineers typically examine new problems to see if solutions they have used for past problems can be applied or adapted to the new problem. When past solutions can be used for new problems it both shortens the time it takes to reach a solution and increases the confidence the engineer has in the solution. Confidence is increased because the past solution has been found sound or discarded. Often the quality of a solution based on a past solution is superior to a totally new solution because the past solution has been refined with testing and use. Pattern Based Systems Engineering (PBSE) is a methodology of developing and exploiting past solutions for new systems engineering tasks in a standard way that allows systems engineers to reuse and share past solutions. This has an additional advantage; inexperienced engineers benefit from the work of more experienced peers and are able to work at the quality levels of more experienced engineers.

Most systems engineering work involves design elements that belong to families of design elements that design teams have experience with from executing previous development programs. The objective of Pattern Based System Engineering (PBSE) is to exploit this experience to minimize system engineering effort and design errors by reusing past systems engineering work much like hardware and software designs are reused. In fact, hardware and software are not reusable unless the systems engineering, particularly the requirements and decision rational behind the designs, is reusable.

Think about how experienced engineers work. When starting a new task the first thing they do is look for similarities to tasks they have previously performed. Then they refer to reports and design documentation from their previous work to guide the new work. For example, if a diagram exists from a design element of the same family as the current design element it is much faster, and results in fewer errors, to edit the diagram from the previous effort than to construct a new diagram.

Now consider if the example diagram to be edited represented not just a specific member of the family but the entire family. This means that it contains all the possible parameters relating to the family. This complete diagram is called a pattern diagram. The editing job for a pattern diagram consists of deleting those portions of the pattern diagram that don’t apply to the current design element. This can be done quickly and there is little chance of not considering any parameter since all are contained in the pattern diagram. The only possible mistakes are deleting items that shouldn’t be deleted or leaving items that should be deleted; assuming that all possible items are indeed in the pattern diagram.

Note how easy it is to peer review the resulting diagram. The peer reviewers compare the pattern and edited diagrams to see if they agree with each deletion and each item not deleted. Thus having a pattern diagram dramatically shortens the time to develop a diagram for a new design effort and it reduces the chances of errors in the resulting new diagram. Experience shows that all top level diagrams can be developed from patterns in a few hours for a moderately complex system instead of the several weeks it takes to develop these diagrams starting from scratch.

Thus PBSE is largely a model based approach that produces the desired models in a fraction of the time it takes to develop models from scratch or edit similar models from previous work and it achieves higher quality models. Think of Patterns as reusable models. However, PBSE is not entirely model based; prose documents are a part of PBSE, particularly requirements and data dictionaries containing definitions of functions. Reusability is facilitated with prose documents by structuring them as templates organized to maximize the connectivity to other documents and models and thereby minimize the editing necessary for new system documents.

Readers familiar with the Yourdan systems method may see similarities to PBSE and be concerned that PBSE is subject to some of the problems of the early version of the Yourdan methods. PBSE is fundamentally different in that the patterns aren’t based on a physical model and are not inherently subject to having unnecessary items in a design.

It is important to note that the title to this chapter is “Introduction to Pattern Based Systems Engineering”. The objective is to introduce PBSE in a way that inspires readers to both try it and to do further reading. This book does not present systems science; rather it presents pragmatic systems engineering methods and tools the authors have found useful in their work. It isn’t that we don’t believe systems science is worthwhile, it’s that we are working systems engineers and managers of systems engineering work and don’t claim expertise in systems science. It also means that we are not trying to present a comprehensive introduction to or history of all systems engineering methods; rather we present what has proven to be effective in our work. We reference work of systems scientists and highly recommend that readers of this book dig further into methods by studying the works of well-known systems scientists.

After reading this chapter readers interested in adopting PBSE methods should study papers by William Schindel of ICTT Systems Sciences. Start with “Pattern-Based Systems Engineering: An Extension of Model-Based SE” available on the web. Especially recommended is “Requirements Statements Are Transfer Functions: An Insight from Model-Based Systems Engineering”, by W.D. Schindel, ICTT, Inc., and System Sciences, LLC. Presented at the 15th Annual International Symposium, INCOSE 2005, 10-14 July 2005. The implementation of PBSE presented here differs in details from Schindel’s because of what we have found that works well for us and our organizations. Schindel’s version of PBSE may work better than the version presented here for other organizations so we recommend readers study both. Experienced systems engineers may develop implementations that differ from both that presented here and in Schindel’s work that may work better for their organizations and their work.

Note particularly Schindel’s use of logical subsystem architectures for allocating requirements. Logical subsystems are analogous to the logical interfaces used to characterize inputs and outputs for systems before the physical architecture is defined. Some find this a preferable approach over traditional functional analysis and some experienced with traditional methods prefer just doing functional analysis. For example, consider constraint requirements like mass and volume. It can be confusing for inexperienced systems engineers to allocate such constraint requirements to functions since functions have no mass or volume. However, allocating mass or volume to a logical subsystem seems intuitively more appropriate.

In this work we choose to present traditional requirements allocation to functions. This approach requires less change for systems engineering organizations and in the authors’ experience does not detract from the intrinsic value of developing and using patterns.

Processes and Tools for Planning a Program - 9

Supplier Relationships - Today’s systems almost always involve suppliers for items varying from commodity parts to critical subsystems. Managing suppliers, particularly those supplying critical components or subsystems, is a major project activity and usually involves engineers as well as project management and sometimes enterprise management. It is sometimes ok to leave the management of non-critical commodity items to procurement personnel but critical items must involve engineers and project managers.

There are several ways to involve suppliers including strategic alliances, partnering relationships or simply contact by project or procurement personnel. Strategic alliances are for a longer term than one project; partnering relationships may be for one project or for a longer term as well. It is not the intent of this work to describe the business reasons for selecting an approach to involving suppliers but to describe why and how supplier relations should be part of project planning.

The success of modern methods like concurrent product and process development depends on involving suppliers early in the project so that the team has benefit of the supplier’s capabilities in making design decisions. The objective should be to develop qualified suppliers, not just suppliers whose product data sheets offer desirable features. This means it is necessary to evaluate a supplier’s technology, product quality and reliability, manufacturing and quality assurance processes and cost competitiveness. It is not unusual to find that a supplier has the desired product with the best technologies, but is lacking in key manufacturing or quality assurance processes. This can be an opportunity for a strategic alliance or partnering relationship in which process development help is offered to the supplier in return for exclusive or preferential access to the supplier’s product or technology. Thus finding and qualifying key suppliers must be an ongoing process because there just isn’t sufficient time once a development program is underway. Postponing or ignoring the need to qualify suppliers ahead of time usually results in having to send engineers to the supplier to resolve a crisis caused by failure to deliver on time or with the required quality. It’s much more expensive to fix supplier problems when the problems are holding up an entire project than it is to qualify the supplier before the project starts or at least before the supplier begins manufacturing the required items or implementing planned services.

Having prequalified suppliers helps reduce the number and the size of the documents related to suppliers that are commonly called source control documents (SCD’s). An example explains this best. One manager on a schedule critical project with a dozen suppliers found that by accepting the supplier’s quality assurance processes the size of the SCD’s were reduced from typically 50 pages to typically 10 pages; a fivefold reduction in effort for this documentation task. This manager also found that requiring the engineering team to design to their supplier’s standard part specifications eliminated the need for special SCD’s for these parts and resulted in a factor of six reduction in SCD’s needed for this example project. Thus the combination of accepting the supplier’s quality assurance processes and designing to standard part specifications reduced the number of pages of SCD’s by a factor of 30 for this example. It may not be advisable to completely eliminate SCD’s for all standard parts but engineers should consider limited SCD’s for standard parts, e.g. a specification sheet plus selected critical requirements necessary to protect against changes by suppliers that could cause problems.

Assuming some type of partnering relationships are arranged with key suppliers it is necessary to recognize that these relationships require formal management. There should be documented agreements, specified points of contact and periodic reviews of the relationships. Engineers and engineering managers should regularly visit suppliers of critical components that are involved in such relationships.

It is always desirable to have multiple sources available for procured items, however, when the cost of properly qualifying a supplier and the costs of not qualifying suppliers are taken into consideration experience shows that one or at most two suppliers are all that can be afforded. Project managers must recognize that there is no shortcut. The cost of qualifying key suppliers is necessary and will be absorbed, either as preplanned at affordable cost or unplanned at a much higher cost.

Finally, if possible, buy and test new critical parts before and/or during concept selection. This provides designers critical information that isn’t available in a supplier’s data and specification sheets. Having this data available during the design work avoids the redesign necessary when it is discovered during subsystem testing or in systems integration that the parts don’t really perform exactly as the data sheets implied. This means that critical part decisions are made before design work begins or even before systems engineering is complete. The reason that this is possible is the reality that products and systems are typically designed around the use of critical parts that represent new technological capabilities or are state-of-the-art leaders. In a modern process like Integrated Product Development (IPD) the design engineers are involved from day one and can identify such critical parts at the initiation of projects. 

Processes and Tools for Planning a Program - 8

Modeling and Simulation Plan - Modeling and simulation should be an integral part of the development of complex systems. The DoD SEF handbook defines a model as a physical, mathematical, or logical representation of something and a simulation as the implementation of a model over time. The DoD SEF has an excellent discussion of modeling and simulation so there is no need to discuss it in detail here. But it is important to stress developing a modeling and simulation plan as part of the overall project planning process.

It can take considerable time to create or tailor models and simulations to a projects needs and to validate their performance. The robustness of requirements analysis, the first step in systems engineering after planning a project, is dependent on the quality of models and simulations available to aid in flowing down requirements to system functions. Thus it’s important to plan the modeling and simulations as early as possible. Decisions must be made up front on the scope of intended modeling and simulation so that work won’t be wasted on models or simulations that won’t be used. The following list can serve to aid in identifying potentially needed models and simulations:

·         System and subsystem performance analysis (typically using models initially)

·         System and subsystem trade studies

·         Design analyses

·         System performance simulation

·         Subsystem test support (hardware in loop testing)

·         System integration support

·         System test support

·         Support of integration and test with customer systems (If system is part of a larger system)

·         Support to training and/or logistics

·         Trouble shooting during the systems operational life

In general, the use of validated models and simulations is highly cost effective because of improving system performance and quality and reducing testing requirements. A case in point is the aerodynamic analysis that has dramatically reduced the cost formally associated with extensive wind tunnel testing of aircraft. Also, in some cases modeling or simulation is the only way to validate performance. An example is a system that supplies measurements that are input to a software algorithm developed by a customer or another supplier and the customer specifies system performance on the basis of the output of the algorithm. If the algorithm isn’t available to the system developer then modeling or simulation is the only way the customer’s performance specification can be verified.

Models and simulations are so important to the development of complex systems that an enterprise’s modeling and simulation capabilities have become competitive discriminators and therefore warrant investment like other potentially discriminating technologies. Some enterprises specialize in modeling and simulations that apply to many complex systems and thrive by being teammates or subcontractors on development programs. Examples include various phenomenologies like environmental backgrounds and atmospheric propagation for electromagnetic radiation that are involved in the development of modern optical and radio frequency sensors. 

Processes and Tools for Planning a Program- 7

System Design Document (SDD) - The SDD is intended to capture an overview of the system design. It should be generated in parallel with the system design work and serve as a concise data source for new personnel coming on to a project at any time during the life cycle and as a reference document for future designs. The SDD should include a summary of top level requirements, but is not the source of requirements information, and it should include the project information architecture.

The SDD captures all system level design diagrams, provides a description of each mode, defines the operational scenarios, includes key use cases, includes a complete functional description to at least the second level and includes a complete description of the physical architecture.

If the enterprise has a mature information system that is designed to archive design data such that links are preserved then the SDD can include links to more detailed design analysis and design documentation; if not then it probably isn’t worthwhile to include such links.

The SDD is not defined as part of the integrated design data packages by the DoD, NASA or IEEE handbooks. However, think of the SDD as the introduction and summary section of the total data package. Just as a good technical report or proposal needs an introduction and summary an integrated design data package needs a SDD to orient users, especially on their first visits to the data package and before they begin contributing to the product design effort. The SDD is also the primary reference for future development of similar products. Trying to wade through the design data of a prior product development without having a SDD to introduce and summarize the design is a formidable task that is avoided if a SDD is available as a roadmap to the design.

Information Architecture - Design of a modern complex system results in generating a large number of specifications, documents, drawings, plans etc. A drawing tree, or a specification tree and drawing tree, may have sufficed to describe the relationships and traceability of design documentation for simple products of the past but these simple trees are no longer sufficient.  It is critical to develop and maintain a data management system as part of an overall configuration management process so that data integrity is maintained and any desired data is easily retrievable. Part of planning a program is defining how this data base is to be configured for the system or product being developed. Unfortunately there seems to be no agreement on what name to give to the complex data base needed today. In this work the term Data Management Repository (DMR) is used for the data base that includes all the documentation associated with the product development. How this DMR database is structured and how traceability is defined is called the information architecture. A key element of the information architecture is the document tree, which is an expansion of the traditional specification tree that includes specifications, plans and key technical reports.

If a modern object oriented data management tool like Telelogic’s Dynamic Object Oriented Requirements System (DOORS^TM), or an equivalent tool is used the document tree can be a template for defining the database. For example, if DOORS^TM is used each box on the Document Tree represents a formal module (data set) in the DOORS^TM database.  Arrows between the boxes identify important relationships (DOORS^TM links) between DOORS^TM formal objects.  These links represent the requirements and decision traceability when complete and they facilitate change management and impact assessment. A Link Module is created in DOORS^TM for each different relationship type captured in the Document Tree. These link modules can include requirements, verification, decision and change with each having a different color on the tree diagram to make traceability easy. An example of a simple document tree for a hypothetical system called AB is shown in Figure 4-5 with only requirements links and verification links shown.

Figure 4-5 A simplified document tree for a hypothetical system called AB showing requirements links and verification links.

The SEMP outline given in a previous posting includes a specification tree and a list of other documents. It is recommended that these two items be replaced by the document tree.

Processes and Tools for Planning a Program - 6

Systems Engineering Management Plan (SEMP) - NASA’s Systems Engineering Handbook has concise definitions for the IMP and SEMP that are summarized here. The IMP, described above, defines how the project will be managed to achieve its goals and objectives within defined programmatic constraints. The Systems Engineering Management Plan (SEMP) is the subordinate document that defines to all project participants how the project will be technically managed within the constraints established by the IMP. The SEMP communicates to all participants how they must respond to pre-established management practices.

Note that the SEMP relates the planned systems engineering work to pre-established practices. This means, that like the IMP, the SEMP does not have to define from scratch how the project will be technically managed; it just has to define what standard practices will be used and any deviations from standard practices. Therefore, again like the IMP, the SEMP should not be a monster sized document that no one will ever read. There is a good discussion of SEMPs in NASA’s Systems Engineering Handbook. A concern with the NASA discussion is that it may lead teams to develop SEMPs that are much too detailed and therefore much too time consuming and expensive to prepare. The same concern exists with the discussion of the SEMP in IEEE Std. 1220. An outline for a SEMP that addresses these concerns was developed by Eric Honour of Honourcode, Inc. of Pensacola, FL in 2003.

A copy of Eric Honour’s outline is presented here with his permission. The only significant change made to is to strongly recommend that we recognize that today project documentation is almost always maintained in electronic format accessible via an enterprise’s intranet. Therefore one key to high quality documentation is achieving the “best” balance between copying material from one document to another and hyper linking between documents. An excess of hyper linking makes reading more tedious but excessive duplication also makes reading tedious for those that have already read other documents. A prescription for the “best” balance is not recommended here since it depends on the documentation particular to a specific organization. Authors of project planning documents should use their best judgment for achieving a good balance.

The following is Eric Honour’s outline in italics with the author’s comments in normal type:

 The topics and outline provide comprehensive coverage. Each topic should be considered in the planning for a program, and then reviewed at the beginning of each subsequent phase. Some topics may only receive cursory consideration in early phases, with later expansion. (E.g. Producibility Analysis, System Implementation Transition)

The SEMP should contain only those processes and plans that are unique to the program.

Initial creation of a SEMP should require between 2-5 working days. Expansion of the SEMP to full planning later may take 2-4 weeks. Revision effort during later phases varies from 2 days to 3 weeks.

A complete SEMP may be as few as 5 pages, or as many as 50.

 Annotated Outline

1.0 INTRODUCTION (Note that this section and section 1.1 should be identical to that in the IMP and copied from the IMP.

1.1 Overview

Identify the system and this document in one sentence. Use a sentence or two to summarize the purpose of this plan.

1.2 System Description

Describe the system, using text and/or figures as appropriate. This identical system description can be used in all plans created for this program. (E. g. define the design architecture using hardware and software trees.)

2.0 REFERENCED DOCUMENTS (Here is an example where the IMP should link to this List.)

List all documents that are specifically referenced within this document. Provide document number (including revision letter) and name in the format: ANSI/EIA-632 Processes for Engineering a System

3.0 TECHNICAL PROGRAM PLANNING AND CONTROL

3.1 Task Descriptions

3.1.1 Definition of Work

Define the technical work that must be performed under the contract. Show the contract work breakdown structure (CWBS), and describe the scope of each technical work package. Indicate the flow down of CDRL items to work packages (can be shown on the CWBS).

3.1.2 Subcontractor Work Effort

Define the work efforts to be performed by subcontractors or teammates under the contract. Identify the CWBS work packages containing this effort.

3.1.3 Schedule

      Show the program schedule. Identify development phases and major milestones. Show a task       network of task dependencies, with critical path. (I would copy the one page Master schedule   from the IMP and link to the detail schedule or IMS)

3.2 Organization

3.2.1 Technical Organization

Show a diagram of the technical project organization. Also include diagrams of the related program organization and functional organizations. In creating this diagram, consider the principles of concurrent engineering.  (Here is another opportunity for the IMP to link to more detailed information in the SEMP.)

3.2.2 Technical Functions

Provide a textual description of the responsibilities of each person in the technical project organization. Cross-reference responsibilities to the CWBS. Include subcontractor personnel, and include subcontractor monitoring responsibilities. (Section 4.3 of NASA’s System Engineering Handbook has an excellent and concise discussion of tying the lowest level of the CWBS to the responsible engineer or manager.)

3.2.3 Program Interfaces

Define the formal and informal technical interfaces to others. Consider customer and internal technical interface meetings, interface control working groups, and standards committees. Define how to control the interfaces - authority and responsibility.

3.3 Technical Control (Don’t forget the instruction in the beginning to include only things that are unique to the project. Don’t describe standard processes. Just note any tailoring specific to the project.)

3.3.1 Requirements Management

Describe the plans to manage technical issues on the program. Identify technical project meetings, issues tracking lists, issue resolution methods, and resolution authority.

3.3.2 Technical Issues Management

Describe the plans to manage technical issues on the program. Identify technical project meetings, issues tracking lists, issue resolution methods, and resolution authority.

3.3.3 Risk Management

Describe the plans to manage and mitigate technical risks on the program. Identify risk levels, threshold criteria and decision authority. Identify methods to identify risk, analyze risk and track risks. (Make the detailed Risk Management Plan a separate document and provide an overview here with links to the detailed plan. The reason is that the Risk Management Plan is a very active document that needs to be updated much more often than a SEMP as risks are mitigated and new risks are identified.)

3.3.4 Interface Control

Describe the plans to control interfaces within the system and between the system and other systems. Identify the interfaces to be controlled.

3.3.5 Configuration Control

Describe the plans to control baseline configuration of the system design. If a separate Configuration Management Plan exists, refer to it.

 3.3.6 Document Control

Describe the plans to control the documents on the program. Consider master documents, copies, and distribution. Include documents created by the program team and those received from external sources. (The plans should include an “Information Architecture” diagram. Include the diagram in this section along with the descriptions recommended.)

3.4 Performance Control

3.4.1 TPM Process

Define the process to gather and calculate Technical Performance Measures (TPM). Define the frequency of measurement. Define the methods to disseminate the results, including management visibility.

3.4.2 Technical Performance Measures

Define the TPMs to be calculated. Define the raw data required and sources. Define the calculation methods for each TPM.

3.5 Program and Design Reviews

3.5.1 Review Process

Define the process to be followed for program and design reviews.

3.5.2 Review Schedule

Show a schedule for the specific program and design reviews to be used. Describe the purpose and content of each review. (The reviews should be on the Master schedule. Only describe them here if the project is deviating from the organization’s standard processes for reviews. If the reviews are tailored project leaders should distribute copies of the tailored checklists ahead of preparation for each review; otherwise workers are likely to refer to standard documentation for reviews rather than to dig instructions out of the SEMP.)

4.0 SYSTEM ENGINEERING PROCESS

4.1 Process Description

In the subsections that follow, describe the program-unique processes in each phase. Use standards as a reference, and do not restate the processes therein. Consider each activity in each phase. Specifically address the automated tools that will be used and their interconnection.

4.1.1 Operational Definition

4.1.2 Requirements Definition

4.1.3 System Architecting

4.1.4 Preliminary Component Design

4.1.5 Detailed Component Design

4.1.6 Prototype Manufacture

4.1.7 System Integration

4.1.8 System Verification

4.1.9 System Validation

4.1.10 Operation and Maintenance

4.2 Related Processes

4.2.1 Electronics

Define the specific electronic engineering development processes to be used. Define the types of system engineering support required.

4.2.2 Software

Define the specific software development processes to be used. Define the types of system engineering support required.

4.2.3 Mechanical

Define the specific mechanical engineering development processes to be used. Define the types of system engineering support required.

4.2.4 Process Development

Describe the methods by which program processes will be monitored and improved. Consider the impact on systems engineering and other processes.

4.3 Trade Studies

4.3.1 Trade Study Process

Describe the process to be used in performing trade studies. Consider trade matrix formats, depth of analysis, and types of information. Describe how to handle multi-dimensional interdependencies.

4.3.2 Trade Study Tasks

Identify the major system trade studies to be performed. Indicate the issues and constraints, including interdependencies. (I highly recommend an N-Squared diagram be included here or linked to. See previous posts on N-Squared diagrams.)

4.4 Requirements Allocation

Describe the unique processes to be used to allocate requirements to system components. Use standards as a reference, and do not restate the processes therein.

4.5 Design Optimization/Effectiveness

4.5.1 Analysis Methods and Tools

Describe the mathematical, simulation, and/or prototyping methods to be used to optimize the design and measure its effectiveness. Define how these methods will be used to impact the design, in which phases. Identify the specific tools to be used. Describe how to handle multi-dimensional interdependencies.

4.5.2 Design Analyses

Identify the specific analyses, simulations, and/or prototypes that will be developed. Identify when each analysis will be performed, and by which personnel. Identify the issues and constraints on each, including interdependencies. Identify the results anticipated from each. Include technical and cost analyses. Consider the following possible types of analysis:

􀁹 Performance Analysis (Throughput, Latency, Dynamic Range, Bandwidth, Memory, etc.)

􀁹 Logistic Support Analysis

􀁹 Life Cycle Cost

􀁹 Design to Cost

􀁹 Design for Manufacturability

􀁹 Design for Test

􀁹 Producibility

4.6 Documentation (Additional recommendations for defining documentation are given below in the section titled Information Architecture.)

4.6.1 Specification Tree

Show a hierarchical diagram of the specifications that will be created for the system and its elements. Identify the type of each specification. Indicate which specifications are internal and which must be delivered. (Replace the specification tree with a document tree for a more complete description.)

4.6.2 Other Documents

List other documents that will be created. Indicate which documents are internal and which must be delivered.

4.6.3 Document Generation Methods

Describe the methods to be used to generate documents. Identify the specific tools, and their required interconnections. Describe the review and sign-off process.

5.0 ENGINEERING SPECIALTY INTEGRATION

5.1 Control of Engineering Specialties

Describe the integration and coordination of the various engineering specialties in each system engineering phase. Indicate how system engineering controls achieve the best mix of technical/performance values. Where the specialty programs overlap, define the responsibilities and authorities of each.

5.2 Integrated Logistics Support Plan

Summarize the approach to Integrated Logistic Support (ILS). Refer to a separate ILS Plan, if available. Consider the aspects of Logistic Support Analysis, Provisioning, and Training. Indicate the information needed by ILS and its source and time of need. Indicate the expected results and when.

5.3 Reliability/Maintainability/Availability Plan

Summarize the approach to Reliability/Maintainability/ Availability (RMA) analysis and control. Refer to a separate RMA Plan or plans, if available. Indicate the information needed by RMA and its source and time of need. Indicate the expected results and when.

5.4 Safety Plan

Summarize the approach to safety analysis and control. Refer to a separate Safety Plan, if available. Indicate the information needed by safety engineers and its source and time of need. Indicate the expected results and when.

5.5 Human Factors Engineering Plan

Summarize the approach to human factors analysis and control. Refer to a separate HFE Plan, if available. Indicate the information needed by human factors engineers and its source and time of need. Indicate the expected results and when.

5.6 Security Plan

Summarize the approach to security analysis and control. Refer to a separate Security Plan, if available. Indicate the information needed by security engineers and its source and time of need. Indicate the expected results and when.

5.7 Electromagnetic Effects Plan

Summarize the approach to electromagnetic effects analysis and control. Consider EMI, EMC, and TEMPEST as appropriate. Refer to a separate plan, if available. Indicate the information needed by electromagnetic effects engineers and its source and time of need. Indicate the expected results and when.

5.8 Value Engineering Plan

Summarize the approach to value engineering analysis and control. Refer to a separate plan, if available. Indicate the information needed by value engineers and its source and time of need. Indicate the expected results and when.

5. X (Other Plans)

(Describe other applicable specialty plans and programs such as: Test & Evaluation Master Plan; Quality Assurance; Nuclear Survivability; and Parts Control)