Home     Content    

System Engineering

Introduction

Engineering is not about finding the best solution, it is about finding a good solution. An engineer that seeks the best solution will be working on a single project an entire lifetime and will never succeed.

Building successful systems requires planning. To support planning, a process for development must be defined and enforced. The process must be encouraged by management at all levels. The system / software development process must be understood and followed by all disciplines involved with developing systems and applications because the process is a chain with many links, and breaking a single link may result in budget overruns and / or failure of a product or project.

Although I have helped organizations achieve CMM SEI level 4, the recognition was not my major goal. My major goal was to be instrumental in developing and implementing a process that would help us produce quality products on an achievable schedule. The certification for the organization was just a bonus.

I am very fortunate that my early years in software engineering were with projects that had processes in place. Admittedly, the processes have evolved over my career, but any process is better than random system development. Due to my early experience with the development process, I was able to take over projects that were not meeting their deliveries, and gotten them back on track simply by putting a process in place by getting management support to enforce it.

The software / system development process consists of many sub-processes. System engineering is the first step in the process when building a system or even a simple application requiring a computer. It is important to have the right team developing the system requirements, since if the requirements are wrong, a lot of time is spent building the wrong system. Part of the process is defining the goals of the system requirements development team.

In any responsible shop, system development is layered. Each layer in the development process relies on the previous layer. At the top of the layer may be a Statement Of Work (SOW), a request for proposal, an internal wish list, or a desire for a new product. This top level document may have different titles depending on the size of the project. Once the decision is made to build the system, a System Specification document is written. This document is normally a very high level document and does not contain many technical details of the system. This document is the communication between customer, management and the top level engineers. It contains enough detail that all parties understand what the system is going to do. Once agreement is reached on the system, the system engineering team will begin the requirements definition process.

System Engineering Team

The system engineering team should consist of system engineers, hardware engineers, software engineers, test engineers, and a few members in training. It is important to have one of the more experienced engineers in charge, since an arbitrator and decision maker is required.

The contributions of each team member varies. There are several artifacts resulting from the system engineering process.

System Engineering Artifacts

Some of the artifacts resulting from the system engineering process are: Depending on the system being built, the artifacts may vary. It is just as important to identify what is not included and why as it is to identify all the requirements that are included in the system. If future requirements are known, but are not going to be implemented during this development effort, they should be made available as notes in a separate document. By making future requirements known early, it will help the next activity in the system development process be more effective by not designing future enhancements out.

System Specification

The system specification document describes the system and gives a high-level view of what functionality the system will provide. This is the document that provides the overview of the integrated system. The system specification is the guide that will allow the derivation of the hardware, software and test requirements. If the system will be receiving data from external systems, or if it is to provide data to external system, the data is described or referenced in the system specification.

Hardware Requirements

The hardware requirements describe the functionality that any special hardware provides. My role in hardware requirements for new hardware is limited to requesting status words and special commands to access the status. I may also request the order or grouping of status bits to make implementation more efficient.

Software Requirements

The software requirements document describes the functionality that the software must provide. On early projects, I have used a tailored 2167-A, but prefer a tailored IEEE Software Requirements Specification guideline. I am happy to see that the DOD has dropped 2167-A and is moving to the universal IEEE standards. While software requirements specifications may vary, a good SRS has the following characteristics:

In addition to all the characteristics, the software requirements must reference the system specification where applicable. Rather than starting a new system requirements from a blank page, I prefer to start with a template and fill in the blanks.

Test Requirements

The test requirements document specifies the types of testing that is to be performed. Test requirements may vary depending on the application. A mission critical application, or an application that involves human life should have more stringent test requirements than a game. The test requirements determine the quality of the system.

Interface specification

The interface specification document contains the data that describes how the software and hardware communicate. Although the names may vary, it contains but is not limited to:

Engineering Notes

Engineering notes are not a deliverable document, but are a collection of documents that track all decisions made on the project. It is the engineering notes that describe the things not included and why, the problems encountered and how they were solved, explanations of why a schedule slipped etc. If these notes can be collected and categorized, they are very useful for planning the next system.

Schedule

No plan is complete without a schedule. In large systems, a good schedule will identify when each piece of the system must be available. The critical paths will be identified, and man-power loading can be planned.

Risks Identified

With technology comes risks. Risks are not bad, but they must be identified well in advance.

Risk Reduction Plan

Once risks are identified, a plan is needed to minimize the risks. To have a risk identified, but no plan on how to minimize the risk is a formula for disaster. With every risk, there is a cost, sometimes, when the risk is too great, and we have no way to minimize the risk, a decision must be made whether to proceed or not. With some risks, we can find new paths that will avoid the risk.

Experience and Common Sense

Our schools fall short of producing good engineers. I was very fortunate that early in my career, I had the opportunity to work with some excellent engineers who believed in sharing knowledge and saw some potential in me. I can tell many stories about my experience and how it helped, but not here. What I learned from my experience is important. If our schools teach anything, a good engineer learns how to learn. Companies that have mentor programs for entry and/or incoming engineers have better teams. I have learned more by mentoring entry level engineers than I ever could have in our universities.