Filter
Top Products
178 Model Driven Systems Development with Rational Products
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 concerns—sometimes vague, amorphous, and likely contradictory.
We start with understanding the context of the system. From concerns, we derive
a set of black box systems requirements, both functional and nonfunctional.
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 black-box representation of the system has a set of functional requirements,
constraints on those functional requirements, and constraints on the system
itself.
Value
Operational
Availability
Throughput
Capacity
Reliability
Usability, human factors
Responsiveness
Functionality
Main concern Subordinate concern