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.