Requirements for a system come in a variety of forms: textual requirements, mockups, existing systems, use cases, user stories, and more.
requirements state what the system must do, and how it must behave or
react to runtime stimuli.
requirements are qualifications of the functional requirements or of
the overall product. A qualification of a functional requirement is an item
such as how fast the function must be performed, or how resilient it must be to
erroneous input. A qualification of the overall product is an item such as the
time to deploy the product or a limitation on operational costs.
Constraints. A constraint is a design decision
with zero degrees of freedom. That is, it’s a design decision
that’s already been made. Examples include the requirement to use a certain
programming language or to reuse a certain existing module, or a management
fiat to make your system service oriented. These choices are arguably in the purview of the
architect, but ex-ternal
factors (such as not being able to train the staff in a new language, or having
a business agreement with a software supplier, or pushing business goals of
service interoperability) have led those in power to dictate these design
What is the “response” of architecture
to each of these kinds of requirements?
requirements are satisfied by assigning an appropriate sequence of
responsibilities throughout the design.
2. Quality attribute requirements are satisfied by the various structures designed into the architecture, and the behaviors and interactions of the elements that populate those structures.
3. Constraints are satisfied by
accepting the design decision and reconciling it with other affected design