The Information Side of System Engineering
The Role of Information in System Engineering
As system engineers, we like to think that our jobs are to engineer at a system level, that is, we “enable the realization of successful systems” as INCOSE would say. In order to do this, we address customer needs, operations, performance, cost and schedule, training and support, and to a lesser degree, test, manufacturing and disposal. These are all very important areas to address if the system is to be successful. If the system is to meet user needs, a discipline that coordinates and integrates these other disciplines is essential, hence system engineering.
System engineering is not a discipline of design. We don’t design integrated circuits or printed circuit boards. We don’t solder components to PCBs. We don’t write production C++ or Java code. We don’t install blade servers into racks and connect them with a specific network topology. We don’t design mechanical parts to be machined on a Computerized Numerical Control (CNC) milling machine. We don’t really do the “fun” stuff in engineering.
Instead system engineers have their own tasks. We gather the user needs and wants, formalize them into requirements and create a requirements database. When in doubt about a user need, we perform trade studies to determine the best implementable option, and document that in a trade study report. We define the concepts of operation, system functions and logical architecture. We record all that in a set of specs and architecture documents, or better yet, in an MBSE database. We create mappings between all the entities we defined and try to document those linkages.
Show Me the Data
This is nowhere nearly a comprehensive list of what system engineer do, but there should be a pattern emerging. System engineers tend to create documents, databases, spreadsheets, relationships and all varieties of information. SE doesn’t produce deliverable system end-products; no software, no hardware, no electronics. Instead, system engineering produces intermediate products. System engineering gathers and synthesizes the information necessary to design and build a product to satisfy the customer. The individual disciplines actually build the product. System engineers answer the critical questions the other disciplines need to know up front to do their jobs right. System engineering is a discipline of gathering and synthesizing information then presenting it in such as way that it can be understood and used for communications both to the development disciplines and also to the customer. System engineering is a discipline of information and coordination.
Lately some educational institutions have issued degrees in system engineering, but in general we’re usually electrical or software engineers who transition into the field. Sometimes we are specialized analysts who can synthesize new technical information. Sadly, very few system engineers are skilled in information management. For example, how many system engineers know what a relational database is, or what fourth normal form is? Raise your hands!
I know many requirements engineers who cannot even use an important tool of their trade, DOORS, relying on others to perform input and export reports to Excel. Engineers can use tools like Excel, yet must rely on others to help them get a DOORS export. Heaven’s forbid they use Access or mySQL to manage information. Even fewer probably know how to use Microsoft Query to extract and cross reference information.
MBSE as Information Management
I believe MBSE is an industry attempt to do more information management for system engineering. MBSE attempts to capture system engineering information in a single model and database. Unfortunately MBSE stops well short of fulfilling its promise. In general MBSE models will address architectural, behavioral and structure information, but fail to address other aspects of system engineering information. Most MBSE tools, especially those based on SysML, cover a limited territory of information concepts. Often these tools address the end product itself, and not the full field of information concepts that system engineers deal with. Other tools are used to address other information, such as requirements, planning, testing, trade studies, simulations and visualization. Although these tools have their own models, seldom are the models well integrated.
The Map and the Territory
It should be obvious that there is a very large territory of information that system engineering covers. When communicating, we do so in the context of the map we’ve created for that information territory. This can be an issue if somebody in a different context doesn’t understand the map we use. If the map omits critical information for the other party, then the communication fails. If the map presents information in an unusable format, communication fails. If the terminology and concepts are incompatible, communication fails. MBSE might provide a limited map that uses common symbols, but much of the remainder of the map only exists in our heads, making it difficult to share.
How do you determine what information other people need? How do you anticipate their queries? How do you store and present information in a flexible manner? These are some of the issues that should be addressed to fulfill the information management needs of system engineering.
Do You Have an Information Management Problem?
Many organizations will dismiss this idea out of hand. “We’re doing just fine information-wise, thank you.” Perhaps your organization hasn’t fully examined the issue. How do you know you have an information management problem in your system engineering department? With a tip of the hat to Jeff Foxworthy, here are some real world clues you might have an information management problem.
If your engineers manipulate requirements in Excel and you have separate administrators who handle the DOORS database, you might have an information management problem.
If a requirement in DOORS has an attribute called “Proposed Change”, you might have an information management problem.
If your information is linked to your MBSE database solely via a text attribute called “Allocated CSCI”, you might have an information management problem.
If you don’t understand the difference between a configuration item and a component, you might have an information management problem.
And my personal favorite: If a requirement in DOORS has over 100 attributes, you definitely have an information management problem.