In this meaning, system engineering consists of understanding as much as possible the stakeholder concerns, capturing those concerns into a consistent set of requirements, and then specifying a set of system components (hardware, software, worker instructions) that, when integrated meet the requirements. These stakeholder concerns are usually broader than those than can be met by hardware or software alone, for example, total cost of ownership, or mean time to recovery. System engineering requires the ability to address a very wide set of concerns with an elegant system design.
MDSD is meant to provide the means to achieve this elegant design.
Systems concerns
As is clear from INCOSE's definition, there is a wide variety of concerns that must be met to ensure the success of a system.
It is useful to make a distinction between concerns and requirements. Briefly:
Concerns are issues that matter to the stakeholders.
Requirements are a transformation of the concerns into a specification that can serve as a basis for architecting the system.
Let us briefly consider concerns. As stated above, there are many of them, and different kinds of them. Consider these items as a starting set (to be added to, or merged with the set implied in INCOSE's definition), as shown in Table
Table
Main concern | Subordinate concern |
|
| |
|
|
|
| |
| Security | Data integrity | ||
Domain concerns |
|
|
| |
Safety | Physical | |||
| ||||
| Predators [?] | |||
|
| |||
|
|
|
| |
| Development |
|
| |
|
|
|
| |
|
| Serviceability (patches, repairs, | ||
|
|
| hot swap | |
Cost concerns | Fielding | Operating (see also Operational) | ||
|
| Maintainability, extensibility | ||
|
| Training, adoption | ||
|
|
|
| |
| Retirement/Disposal |
|
| |
|
|
|
|
Chapter 8. Conclusion 177
