If you ever wondered….
- What is System Engineering…Who Are System Engineers?
- Where do System Engineers Come From?
- What is a System?
- What are the Basic Components of a System?
- Examples of Systems
- System Engineering Process
- System Engineering Requirements
What is System Engineering…Who are Systems Engineers?
System Engineering is a discipline that is responsible for the overall realization of the System/Product/Solution. System Engineering works with the customer to identify their needs (requirements) and develop an understanding of the customer’s planned concept of operations (ConOPS). System Engineers oversee the realization of a system design in it’s entirety architecting a design solution that takes into account the Environment, Inputs/Outputs, Laws, Regulations, Standards and User ConOPS transforming them into a system design that provides the customer with the desired capabilities.
Where do System Engineers Come From?
System Engineers start off as Software, Electrical or Mechanical Engineers (…to keep this list short) becoming experts in their field and growing an understanding of a customer’s needs and developing a feel for design solutions.
What is a System?
“A System is set of elements, components or systems working together for a common purpose”
The following make up the basic components of a system that affect how a system performs. Most times these basic components become Functional or Performance requirements (design constraints) levied on the System Design.
Basic System Components
- Environment
- Inputs
- User
- Laws, Regulations & Standards
- Outputs
Internally a System is comprised of one or more
- Elements
- Subsystems
- Systems (Yes, Other Systems)
- Process (An interaction between the Elements, Subsystems and Systems)
Examples of Systems
Simple System
System of Systems
In a System of Systems (SoS), the common interfaces, standards, codes and design guidance is decomposed and passed down as common design (requirements) specifications to each of the member Systems. The common design and common interface results in a SoS that is greater than the some of its parts. In the example Utility Power SoS above, the Utility Power SoS creates a new Power System with attributes of “redundancy” and “demand response” that each of the individual systems did not have before.
As is true of any System, the capabilities of a System of Systems is greater than the sum of the capabilities of each of the Elements, Components or Systems that make up the System.
System Engineering Process
“Systems engineering is an iterative process of top‐down synthesis, development, and operation of a real‐world system that satisfies, in a near optimal manner, the full range of requirements for the system.” (Eisner, Howard, Essentials of Project and Systems Engineering Management).
The System Engineering Process can be viewed in many ways (e.g. Waterfall, Spiral, “V”, and Iterative). Each of these processes have a different flow but they all have the same basic steps. The basic steps of the System Engineering process were presented by Terry Bahill and Bruce Gissing in 1998 in the form of the acronym SIMILAR:
- State the Problem—Identify Customer, understand their needs, establish need for change, discovering requirements and defining system functions
- Investigate alternatives—based on performance, cost and risk
- Model the system—clarifies requirements, reveals bottlenecks and fragmented activities, reduces cost and exposes duplicate efforts
- Integrate—Integration means designing interfaces and bringing system elements together to work as a whole. This requires extensive communication and coordination.
- Launch the system—running the system and producing outputs; making the system do what it was intended to do
- Assess performance—using evaluation criteria, technical performance measures. If you cannot measure it, you cannot control it. If you cannot control it, you cannot improve it.
- Re-evaluation—should be a continual and iterative process with many parallel loops
The SIMILAR model for Systems Engineering does not necessarily imply that the tasks are performed in a linear sequential fashion. Process functions can be performed concurrently and often iteratively as the design matures and knowledge on the Objective System/Product/Process is cultivated.
Basic View of the System Engineering Process: SIMILAR Model
Source and further reading on the SIMILAR process:
Bahill, A. T. and Gissing, B., Re-evaluating systems engineering concepts using systems thinking, IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, 28(4), 516-527, 1998.
V Model of System Engineering Process
The “V” model for Systems Engineering was first developed in the 1980s. As with the SE Process SIMILAR model, The SE Process “V” depicted does not necessarily imply that the tasks are performed in a linear sequential fashion. Process functions can be performed concurrently and often iteratively as the design matures and knowledge on the Objective System/Product/Process is cultivated.
System Engineering Requirements
- System Engineering Requirements are defined by Systems Engineers.
- A requirement define WHAT a System is supposed to do.
- System Engineering Requirements are a collection of requirements that describe what a System is supposed to do by function and performance in order to fulfill the needs of the stakeholders.
Requirements Syntax
There are few recommended ways to write a requirement. If you adhere to the following recommendation for requirements syntax you will find writing requirements a lot easier.
As developed by Marvin et al., The Easy Approach to Requirements Syntax
- Basic Requirement:
The {System} SHALL {response} - Event->Result:
WHEN {event occurs} the {System} SHALL {response} - State->Result:
WHILE {System State}, the {System} SHALL {response} - Unwanted Behavior:
IF {unwanted condition or event},
THEN the {System} SHALL {response} - Optional Feature:
WHERE {System option}, the {System} SHALL {response}
Negative Requirements
When defining Requirements, avoid using negative or SHALL NOT requirements. Remember: “A system SHALL NOT do far more than the system is actually capable of doing!”
- Use negative specification primarily for emphasis, in prohibition of potentially hazardous actions. Then state the safety case in the rationale for the requirement
- Use negative specification primarily for emphasis, in prohibition of potentially hazardous actions. Then state the safety case in the rationale for the requirement
- Substitute shall enable for shall not prohibit, shall prohibit in place of shall not allow, and so on
- Avoid double negatives completely
- Use shall allow instead of shall not prevent, for example
- Arithmetic limits are appropriate
- Shall not exceed
- Shall not be less than
Range Requirements
Avoid specific, one-point values when defining requirements. Use ranges (minimum of, more than, less than, maximum of, within, etc.) to accommodate appropriate interpretation. Using a single point value may cause arguments if the system is tested at that exact value only, or if a test appears to be successful from an intent perspective, but does not meet the exact value stated in the system requirement.
- Example: The system shall process a minimum of 100 transactions/sec
- Example: The system shall be operable up to and including 30,000 ft
- Example: The system shall operate in temperatures ranging from 5 degrees Celsius up to and including 35 degrees Celsius