Main concern | Subordinate concern |
|
|
|
|
|
|
|
| Availability | |
| Operational | Throughput | |
| Capacity | ||
|
| ||
|
| Reliability | |
Value |
|
|
|
Usability, human factors |
|
| |
|
|
| |
|
|
|
|
| Responsiveness |
|
|
|
|
|
|
| Functionality |
|
|
|
|
|
|
Each of these is worth discussing in detail; we will not, however, do so in this context.
Given this broader set of concerns, we need to transform them into requirements, and then transform the requirements into an architecture.
How do we do this? With MDSD.
How does MDSD fit in?
As we have discussed, MDSD consists of a set of transformations that progressively refine our knowledge, requirements, and design.
Following the MDSD process, we move from concerns to requirements to architecture. Hopefully this architecture allows us to provide value that can be measured against the cost and risk of producing it; a value that meets the concerns of the stakeholders.
We start with
Black box system requirements drive the architecture of the system. We find these requirements by understanding the system in its context, and by transforming concerns into requirements.
A
