Figure 5-2 Achieving requirements reuse requires comprehensive requirements analysis.
Tuesday, November 30, 2010
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.
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.
Tuesday, November 23, 2010
“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.
Tuesday, November 16, 2010
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.
Monday, November 8, 2010
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.
Tuesday, November 2, 2010
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 (DOORSTM), or an equivalent tool is used the document tree can be a template for defining the database. For example, if DOORSTM is used each box on the Document Tree represents a formal module (data set) in the DOORSTM database. Arrows between the boxes identify important relationships (DOORSTM links) between DOORSTM 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 DOORSTM 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.