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)

Processes and Tools for Planning a Program - 5

Critical Path Analysis – Critical path analysis needs further discussion because of issues that have emerged in modern complex projects. Modern software scheduling tools automatically determine and show the critical path for a project schedule. However, it is not good practice to just accept the first result for a complex project.

The simple example schedule discussed in the previous sections is a deterministic schedule; each task has a planned duration, a predecessor task and a successor task. Therefore there is a deterministic critical path. It should be obvious that the time estimate for each task has a probability associated with it. That is, there is some probability that the task will be completed in the time estimated. Therefore there is also a probability that an overall project will be completed in the time estimated by summing the times for the tasks on the critical path. Unfortunately project schedules are sometimes treated by project leaders, managers and customers as though the schedule is deterministic and any overrun in schedule is the result of poor management rather than the result of real world variation due to probabilistic time estimates.  Likewise the team management is given credit for excellent management should the project come in ahead of schedule due to the same variation phenomena.  Of course there is usually some truth in assigning credit or blame to the project leaders because they have numerous tools for managing a project in order to maintain schedule in spite of variations in the time to complete individual tasks. However, using probabilistic time estimates in PERT scheduling, or the alternative recommended in Glen B. Alleman’s blog cited in the section on developing schedules, gives both the project leaders and those overseeing the projects a much better feel for the likelihood that the project will complete by a certain date.

Probabilistic time estimates are achieved by estimating an optimistic time, a pessimistic time and a most likely time for completing each task.  The expected task duration is then defined as the mean of the distribution defined by the three estimates and is between the most likely and the pessimistic times for a beta distribution used in the standard probabilistic approach.  One might expect that the critical path is the sum of tasks with zero slack in the resulting network using expected durations. But since there is a variance for each task estimate there is also a variance for the critical path schedule and therefore a probability associated with completing the project by any number of days less or more than the expected total. Since all tasks have a time to completion variance there is also probability that some path other than the most probable critical path becomes the critical path. Thus to get the most accurate probabilistic estimate of overall schedule it is necessary to analyze all paths and the probability that the project will complete by a certain date is actually the probability that all paths will complete by that date. Alternately simulations considering all paths can be carried out. A shortcut to analyzing all paths may be useful for some projects.

Consider the example of projects for developing systems with hardware and embedded software. There are often several candidates for the critical path in the early part of such projects. This is in contrast to complex projects in the past without embedded software. In the past there was typically some long lead part or assembly that drove the overall schedule so that the critical path usually turned out to be driven by the design and procurement of this long lead item. Modern digital electronics enable systems with complex data acquisition and analysis. Such systems often have special purpose digital circuits with embedded software involved in the acquisition and processing of data. The digital circuit design is usually a relatively high risk task so the designers want to build and test breadboard circuits as soon as possible so that designs can be refined and risk reduced before integrating these circuits with the overall electronics. However, these circuits require embedded software for carrying out their intended functions. Systems engineering must develop specifications for both the digital hardware and for the software. If the scheduling is done in the usual way these tasks end up driving the overall schedule in unsatisfactory ways. Managers may become confused if they expect the usual long lead parts to be driving the critical path, not risk reduction tasks.

To get estimates for scheduling the digital electronics and software tasks so that the risk reduction tasks aren’t on the critical path it is necessary to get the digital designers, the software engineers and the systems engineers to sit down together and work out plans to make these tasks fit together and complete as early as possible. Even with the best efforts of the engineers the resulting schedules often end up with digital electronics, embedded software and some long lead parts all having paths with zero or near zero slack. This says that it’s not possible to accurately tell which will end up the true critical path because of the variance in the time for each path is larger than the difference in slack. A way to handle such scheduling problems is to calculate the expected duration of each of these potential critical paths. It’s not necessary to calculate the expected duration for all paths on such projects because it is highly likely that these few paths with near equal durations drive the critical path. Determining the expected duration for each of these few paths also helps convince managers that the scheduling is sound even if their assumed critical path turns out to be not the most likely critical path.

The situation described for complex systems having special purpose digital electronics and embedded software seems likely to occur in other types of complex projects. If an organization is using deterministic schedules and is faced with a project schedule that has several paths with zero or near zero slack it is recommended to use probabilistic time estimates and to calculate the expected duration for the several candidate critical paths. It likely isn’t necessary to expend the effort and cost to calculate the expected durations for all paths. If an organization uses probabilistic scheduling routinely then spend the effort to involve all the personnel on the tasks that are candidates for the critical path so that they reach an understanding of the relationships of each other’s tasks and explore approaches to workarounds that may shorten schedules as well as result in a better estimate of the true critical path.