Guidance for Engineers

Successful complex systems require bringing specialties together. This makes the SEBoK useful to engineers with backgrounds in biomedical, civil, electronics, chemical, civil, materials, mechanical, software, and many other specialties.

Studying the SEBoK enables engineers from disciplines other than systems engineering to:

• see why good systems engineering practice must involve multiple disciplines
• appreciate a broader view of systems beyond their specialties
• understand how their contributions fit into the larger systems picture
• prepare to solve more difficult and encompassing problems

In many cases, engineers who study systems engineering as a supplement to their non-SE specialities find their professional value enhanced when they put the new knowledge into practice.

Use of Topics

For engineers from non-SE backgrounds, each part of the SEBoK contributes something to the experience of learning about systems engineering:

• Part 1 provides an overview that is essential for all SEBoK readers
• Part 2 highlights the areas of systems knowledge most strongly relevant to systems engineering, providing a foundation for the theory and practice of systems engineering as explained in Parts 3, 4 and 5
• Part 3 includes the knowledge areas of Life Cycle Models, System Definition, System Realization, and System Deployment and Use, all highly important to the engineer approaching study of SE from another discipline
  • Also in Part 3, Systems Engineering Management includes such relevant topics as risk management, measurement, configuration management, and quality management
• Part 4 identifies the SE activities for each of three kinds of engineered systems, namely product, service, enterprise, and systems of systems engineering
  • For an engineer involved in development or modification of a system of one of these types, the primary references and glossary terms — not just the content — for that type of system are essential reading
• Part 5, and especially Organizing Teams to Perform Systems Engineering, explains how systems and other types of engineers fit into the larger picture of enabling individuals and teams to perform systems engineering activities, and how SEs fit into the larger picture of systems engineering organizational strategies
• Part 6, especially Systems Engineering and Project Management, are naturally of prime importance to engineers from non-SE backgrounds
  • Also in Part 6, the Systems Engineering and Software Engineering knowledge area is obviously of interest to software engineers, as is Systems Engineering and Specialty Engineering to individuals involved in specialty disciplines
• Part 7 illustrates how systems engineering practices, principles, and concepts are applied in real settings

While any given example in Part 7 may be most relevant for engineers with experience in kind of system it describes, all of the examples usefully and concretely show the role of systems engineering in projects and programs.

Engineers may be tempted to skip over knowledge areas or topics which sound more like management than engineering stories, for example Part 3 or Part 5. This temptation should be resisted, because these topics are actually about how SE manages or coordinates efforts of other disciplines, not management in a bureaucratic sense.

Finally, the extensive lists of references throughout the SEBoK provide a basis for further readings.

Vignette: Software Engineer

Jose Wilks is an entrepreneurial software engineer wanting to learn more about systems engineering principles applied to embedded systems for advanced document identification and verification. He wants to implement best practices in developing highly secure systems for real-time image processing and forensic verification of documents. His company's technology runs on proprietary tablet computers for portable and fixed locations. It provides a rapid, secure and cost effective solution for verifying the authenticity of identity, travel and financial documents.

He is already knowledgeable about computer hardware engineering, interfaces at the lowest level with software, and their tradeoffs in embedded devices. His company has experience developing research prototypes, but without the stringent security requirements for actual field usage linked to government identification databases. His sales have only been a few individual experimental units, which have fared well in limited testing, but he wants to expand into markets for government agencies, law enforcement departments and the private sector. New constraints and challenges abound to make headway into those diverse markets.

With 20 years of technical and management experience on software projects he already is familiar with concepts in the SWEBoK. So he starts skimming SEBoK 1.0 Introduction and the Scope and Context of the SEBoK to get an overview of the SEBoK contents. Most of the parts have nuggets of knowledge with pointers to help his enterprise operate at an expanded level, as described below.

Part 3: SE and Management has some new concepts that may work. Reading Life Cycle Models he identifies some extra system-level V&V gates to incorporate in their processes with references for implementation details. He is enlightened about system-wide procedures beyond software V&V, and where to find testing and regulation standards used by various government entities. These processes will ensure conformity to the regulations on top of traditional software testing and expedite being approved for use.

Though he has a proven system concept, somehow he has to convince potential buyers on the financial benefits of his system while also assuring that all security criteria are satisfied. He needs to better understand the needs of the stakeholders including users, corporate/government purchasers, regulatory agencies and start using their terminology in expressing system requirements and benefits. This leads him directly to Stakeholder Needs and Requirements. His company will need to quantify the expected ROI for investing in his products.

System Realization is important to understand the broader V&V concerns. Reliability measures on his system performance will need to be demonstrated. He wasn't aware of standard models and measures for system reliability, so he will now ask his staff to develop tests to quantify important attributes. A form of Model-Based Systems Engineering (MBSE) may also be useful for modeling reliability and the system adherence to regulations. They will check the references for more details.

In Systems Engineering Management he recognizes new CM and IM procedures need to be adopted for federal database controls and integrity. Systems Engineering Standards provides important references that will be used for process definition and test case development.

Studying Part 5: Enabling Systems Engineering, he realizes it is critically important to have the right people for a new systems engineering culture. He should probably hire a systems engineer or two to expand his current engineering department expertise.

The topic of Security Engineering in Part 6: Related Disciplines stands out. There he finds references for further study in this burgeoning area. In Part 7: Systems Engineering Implementation Examples, he identifies the FBI Virtual Case File System Case Study being relevant to avoid pitfalls experienced in a application related to private data concerns.

Jose is now better prepared to adapt his processes for new system lifecycles and environments. He can quantify the business case to potential clients for his technology innovations, the initial morass of agencies and regulations is now finite, he can make inroads into new markets, and simultaneously strengthen his staff for the long term enterprise.

Vignette: Mechanical Engineer

Cindy Glass is a mechanical engineer with experience in the petroleum industry, primarily working with large oil extraction equipment in the field. Now she is tasked to help manage the development of new offshore oil platforms with robotic technology, computer networks and broader systems considerations. This calls for incorporating systems engineering principles from day one.

Some of the drilling operations will be done remotely with unmanned underwater vehicles (UUVs). Safety has always been a major concern but now cyber security also is. Environmentalist hackers, opposing nations or others may try to cause havoc by taking control of the remote vehicles and other operations. Unfortunately she is completely new to software system implementation. Cindy realizes there are many more dimensions of system constraints and engineering disciplines to deal with.

Previously she implemented minor design changes in existing equipment with automation and safety guidelines already in place. Now she is dealing with the earliest stages of the platform lifecycle starting from scratch. She already understands mechanical tradeoffs between different types of rigs and drilling materials, but now has to incorporate system security and new environmental constraints in her system analysis. System Realization gives her references for system design with many ilities.

The project lifecycle will require concurrent engineering of platform sub-components while evaluating technology opportunities, understanding the needs of all stakeholders inside and outside the company, and progressing through increasingly detailed prototypes, working slices of software, system specifications, designs, plans, business cases, security and safety analyses of the platform architecture and its operations.

Part 3: SE and Management also describes how her management activities will have to be rigorous and consider the interfaces between the engineering specialties. The section on Planning gives her detailed advice for starting out. The full project plan will call for a broad set of integrated management and technical plans. Conception through Operations will have to involve all the disciplines.

Since she is new to working on software projects and with software engineers, she reads The Nature of Software and Ten Things a Systems Engineer Needs to Know about Software Engineering. She also knows now about the SWEBoK for references on software engineering. She needs some guidance on managing a software team and studies Ten Things a Systems Engineer Needs to Know about Managing a Software Team.

It is clear that Systems Engineering and Software Engineering will be particularly intertwined. Among other things she is reminded to include security specialists at both the software level and the systems level from the beginning.

Cindy now appreciates the broader range of system constraints and thus engineering disciplines she needs to work with. The references in the SEBoK will be consulted throughout the architecting, design, development and deployment of the new platforms.

Summary

The SEBoK provides insights and guidance concerning systems engineering principles for other kinds of engineers and related technical disciplines. These engineers will benefit from the knowledge areas highlighted in this use case. The SEBoK gives pointers to major references for other engineers to become more interdisciplinary and consider additional aspects in their job. Thus they become more valuable to their employers and society.

References

Works Cited

Abran, A., J. W. Moore, P. Bourque, R. Dupuis, and L. L. Tripp. 2004. SWEBOK: Guide to the Software Engineering Body of Knowledge, 2004 version. Los Alamitos, CA, USA and Tokyo, Japan: IEEE Computer Society Press.

Primary References

None.

Additional References

None.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus