Architectural Needs. As in many branches of engineering, our
method begins with understanding the problem and its constraints
including the requirements, program cost and schedule demands;
i.e., the concerns of the various stakeholders. Our understanding
of these is distilled into three products, developed with the client,
and ideally “owned” by the client, which capture both the specific
requirements for the system, and also the general direction and
intent of the client.
For the large command and control and information systems we
typically deal with, there are one or more requirements specification
documents, often running into hundreds or even thousands of
pages. Even when well-written, these formal requirements documents
have proven to be too difficult to use effectively to derive
and analyze system architectures. We analyze these requirements
into a set of architectural needs, which capture the general requirements,
without unnecessary detail. For a recent information system
architecture, we distilled thousands of requirements from several
sources into 138 architectural needs. These needs are maintained
in a data base to preserve traceability of our architectural decisions
back to the full set of formal requirements.
In addition to the “abstracted requirements” reflected by our
needs analysis, we prepare two other statements with the client.
First, a statement of goals reflects the client’s evaluation criteria
– how the client will evaluate whether the system is a success.
Goals include meeting the needs, as well as preferences and desires
which do not occur as requirements. Second, we define a vision
statement. Whereas the goals specify what is to be achieved in the
current system, the vision statement attempts to look into the future
of the system in terms of anticipated missions and new opportunities.
It indicates the client’s long-term direction for the system,
including both the current system under development and a view of
its evolution and eventual replacement.
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
| File | MIME type | Size (KB) | Language | Download | |
|---|---|---|---|---|---|
| Paper-Architectural Metaphor hilliard-rice-schwarm96.pdf | application/pdf | 53.45 KB | English | DOWNLOAD! |
Provides definitions
Abstract
Over the history of systems engineering, there have been numerous attempts to establish the foundations of that field on other disciplines. In this paper, we explore a new approach, founding systems engineering on an architectural metaphor. This approach is based upon our work of the past five years to establish a discipline of systems architecture. We outline the key principles of our approach and discuss their relevance to the broader field of systems engineering.