What Is Systems Engineering?

   

According to the International Council on Systems Engineering [INCOSE 2003]:

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

  • Operations

  • Performance

  • Test

  • Manufacturing

  • Cost and Schedule

  • Training and Support

  • Disposal

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

Phew. That's a long one. Clearly, we won't be providing a comprehensive discussion of systems engineering in this book. However, from the definition provided, we can apply systems engineering as a problem analysis technique , one that we can use in certain circumstances to understand the problems our applications are intended to solve. (For more on systems engineering, see Rechtin and Maier [1997].)

In this context, systems engineering helps us understand the requirements that are going to be imposed on any software applications that run within the solution system . In other words, we'll apply systems engineering as a problem analysis technique to help us understand the requirements for our software applications, whether they run on an embedded microprocessor or a Linux server within the context of a worldwide telecommunications system.

Pragmatic Principles of Systems Engineering

Systems engineering provides eight pragmatic principles.

If we choose to view systems engineering as a problem analysis technique, the specific steps, or at least the basic principles of the discipline, should provide us with the process we need to apply to use systems engineering to analyze the problem in our requirements context. The INCOSE Systems Engineering Practices working group [INCOSE 1993] defined a basic set of eight systems engineering principles.

  1. Know the problem, know the customer, and know the consumer.

  2. Use effectiveness criteria based on needs to make the system decisions.

  3. Establish and manage requirements.

  4. Identify and assess alternatives so as to converge on a solution.

  5. Verify and validate requirements and solution performance.

  6. Maintain the integrity of the system.

  7. Use an articulated and documented process.

  8. Manage against a plan.

This list identifies some pragmatic systems engineering principles. In fact, however, a subset of the systems engineering discipline is based on another process, the successive decomposition of complex systems into simpler ones.

The Composition and Decomposition of Complex Systems

With this process a complex problem, the system (Figure 7-1), is decomposed into smaller problems ”subsystems (Figure 7-2). Each subsystem can be reasoned about, successfully designed and manufactured, and then integrated to produce the solution system. The engineering disciplines that support the approach to system decomposition are implied in the attributes of the preceding definition, such as understanding the operational characteristics, manufacturability, testability, and so on.

Figure 7-1. A system in its environment

graphics/07fig01.gif

Figure 7-2. A system composed of two subsystems

graphics/07fig02.gif

This decomposition (or successive refinement) process proceeds until the systems engineer achieves the right results, as provided by quantitative measures that are specific to that particular systems engineering domain. In most cases, the subsystems defined in the initial composition are themselves further decomposed into subsubsystems, with the result appearing as in Figure 7-3.

Figure 7-3. A system composed of two subsystems, one of which contains two subsubsystems

graphics/07fig03.gif

In the most complex systems, this process continues until a large number of subsystems are developed. (The F22 fighter aircraft, for example, is said to be composed of 152 such subsystems.)

The systems engineer knows that the job is done and is "right" when the following conditions are met.

  • Distribution and partitioning of functionality are optimized to achieve the overall functionality of the system with minimal costs and maximum flexibility.

  • Each subsystem can be defined, designed, and built by a small, or at least modest- sized , team.

  • Each subsystem can be manufactured within the physical constraints and technologies of the available manufacturing processes.

  • Each subsystem can be reliably tested as a subsystem, subject to the availability of suitable fixtures and harnesses that simulate the interfaces to the other system.

  • Appropriate deference is given to the physical domain ”the size , weight, location, and distribution of the subsystems ”that has been optimized in the overall system context.

   


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
EAN: N/A
Year: 2003
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net