Murray Cantor

Subscribe to Murray Cantor: eMailAlertsEmail Alerts
Get Murray Cantor: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

The Six Principles of Systems Engineering

IBM's Rational Rules Developed Over 10-Year Period

At the highest level of abstraction, we can view the system as a single entity (complex whole), or black box. However, to build a system, we must also be able to open the box, look inside, and see what set of interacting, interrelated, or interdependent elements make up the system. This is called the white box view. The primary task of systems (and software) engineering is to recursively move from black box to white box views, opening the system box, subsystem boxes, and sub-subsystem boxes until we ultimately determine the set of interacting and interdependent elements that can provide the system's desired results.

A close look at the INCOSE definition of systems engineering does not reveal a development methodology preference for realizing systems. Traditional requirements-driven methods, with their typically rigid and rigorously defined project tasks, milestones, resources, and schedules, seem to apply. However, as noted earlier, these methods were not designed with a focus on early risk mitigation, fluid requirements, or building systems for which the solution was initially indeterminate; or even at the limits of scientific or technical knowledge.

As we noted earlier, focusing primarily on the requirements and their functional allocation leads to early (and binding) decisions about technology and architecture, even if the architecture is not explicitly addressed. These early decisions can lead to undesirable results:

  • Delivery of systems that fail to meet key stakeholder needs.
  • Significant rework to address changing or misinterpreted requirements.
  • Expensive "heroics" in the final development stage (systems integration) to "rescue" runaway projects.
  • Worst of all, scrapping the system entirely, after heroic efforts fail.

To avoid such problems, we recommend shifting the focus from immediately allocating functional system requirements to preconceived implementation-level components -- for example, an existing software module or off-the-shelf hardware component -- toward more thorough analysis of an abstraction of the ultimate system.

Requirements analysis, allocation, and validation are clearly critical elements of this approach, but they are not the focus of system analysis and synthesis. The goal is to decompose the system structurally in a set of logical steps, following this process:

  1. Understand the workings of the system in its intended environment. Treating the system as a black box, identify environmental elements that interact with the system (the system actors) and the actual interactions and results (system use cases and resulting services). In RUP-SE modeling, this is system analysis at the context level.
  2. Decide how to initially partition the system into elements whose collaborations will provide the services satisfying the needs placed on the system at the context level. Recursively examine elements from both black box and white box perspectives until the key functional and supplementary requirements are satisfied by the interactions of the interdependent system elements. This is investigation at the analysis level in RUP-SE.
  3. Once the system architecture has been derived abstractly through this process of structural decomposition, the next step is to determine how system elements will be realized. This is a transformation from the abstract to the concrete, with the realization partitioned in some combination of hardware, software, firmware, data, and workers. RUP-SE calls this the design level of systems development.
  4. Finally, the system is constructed, tested, and prepared for release. The designs specified in the previous step are implemented (optimally in "release-ready" iterative stages as defined within the RUP and RUP-SE frameworks). This final stage of development is captured in RUP-SE's systems development modeling implementation level.
As we proceed down from level to level, requirements are more precisely allocated to system elements, uncertainty is progressively addressed and eliminated, and the system can be iteratively demonstrated and assessed. Each level of decomposition forces design decisions, providing ongoing synthesis, coupling of requirements and design specifications, and increasing system detail.

Although the steps above may appear to be sequential, and investigation at a lower, more detailed model level seems to require completing activities at higher levels, this is often not the case in practice, due to a range of factors. These factors are addressed by the next two principles of systems engineering.

Enable both separation and integration of concerns
A natural way to deal with system complexity is to intelligently partition the system into smaller, less complex pieces. The way in which to do this varies, but for similar types of systems, the partitioning tends to follow the same pattern. You might partition an automobile, for example, by grouping related functional components, such as chassis, drivetrain, interior, exterior, electronics/software, and steering/braking/suspension.

However, partitioning a system from only one perspective will not likely facilitate the allocation of all stakeholder needs. Systems engineering is not narrowly focused on building a system satisfying functional needs; rather, it must holistically treat the system in its intended environment as seen by operations, manufacturing, service, system actors, and other stakeholder groups. Performance, ease-of-use, aesthetics, reliability, compliance, and all other key constraints must be addressed. Examining a system from multiple perspectives while simultaneously trying to satisfy dozens of nonfunctional constraints might seem like a way to compound development complexity, not reduce it. Instead of dealing with one perspective with n constraints, the development team has to face m perspectives with n constraints. This is precisely the issue that the second system engineering principle addresses. It is not sufficient to merely partition a system to enable a separation of engineering concerns. The chosen systems engineering development methodology must also provide means for system re-integration. As mentioned earlier, a combination of existing RUP-SE framework elements and the new joint realization table (JRT) construct provide for both the separation and integration of key systems development engineering concerns. This framework is flexible and robust enough to support development activities across a wide range of industries and products. In practice, the framework is tailored to either a specific product or set of products. The process of tailoring the framework usually occurs early in the development cycle. In RUP, this would be near the end of the Inception Phase. The tailoring addresses two primary questions:

  1. Which engineering viewpoints must be addressed in system modeling and development? For a joint hardware/software system, this would include at least the logical, physical, and information viewpoints. In most cases, the geometric viewpoint would also apply.
  2. Which individual model views will be addressed and what artifacts will be developed for each view? For example, the Analysis Level Logical View captures the logical decomposition of the system. Here we begin opening the black box that is the system and determining the set of internal elements whose collaboration satisfies the demands actors place on the system, which were established in the Content Level Logical View. In our MDSD approach, this logical structure and its accompanying collaborations will be captured using Unified Modeling Language (UML) diagrams in the system model artifact. The product of the MDSD framework tailoring is the development case artifact, which will guide the development team toward tangible results. These results are represented as artifacts in the individual views as development progresses through iterative cycles of system definition, analysis, design, construction, and test.
Specifications flow up and down the architecture
In a perfect systems development environment, the processes outlined above to decompose a system structurally while enabling both separation and integration of concerns should naturally proceed in a top-down fashion. However, perfection is rare. Uncertainty, misunderstanding, miscommunication, change, technical shortfalls, and other factors all inhibit a top-down flow from context to analysis to design, and ultimately to implementation, from proceeding flawlessly. Acknowledging these inhibitors and addressing them as early as possible in the system development lifecycle is ultimately the key to success and a foundational principle of model-driven systems development. In reality, specifications flow up and down the architecture. In fact, specifications flow up, down, and sideways. Discoveries made in one view may very well radiate out to affect artifacts within other views on the same model level; they may also flow both up and down model levels within the same viewpoint. Is this an indication that the system's architecture was flawed in the first place? Not necessarily. For instance, discoveries made relatively early in the development cycle, while analyzing system or subsystem prototypes, can easily require significant modifications to the system architecture.

More Stories By Murray Cantor

Murray Cantor is a member of the IBM Rational CTO team, taking the lead for Governance and Systems. Cantor formerly lead the IBM Rational field services group, promoting and extending Rational best practices, and working closely with customers on innovative ways to build and deliver systems more efficiently.

More Stories By Gene Roose

Gene Roose is a senior systems engineering consultant for IBM Rational, concentrating on model-driven systems development methods. He assists clients with solution analysis and design, architectural derivation and validation, and overall project management.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.