|
Identify architectural goals
| Describe the goals of the architecture by examining the project Vision and product requirements, including architecturally significant use cases,
if available. Also, talk to the project Stakeholder
and Analyst. These goals will guide the approach you take to important architecture and
design decisions. |
Identify architectural constraints
Work with the analyst and stakeholder to identify any constraints on the solution (or opportunities) that are
inherent in the existing environment or organization. If available, examine the Supporting Requirements for any constraints that have already been
identified. Discuss any critical time and resource constraints with the Project Manager, as these will also need to be taken into account when arriving at your decisions. Discuss potential
constraints with the tester such as hooks for tests, and to identify architectural areas that may be difficult to test.
|
Survey, assess, and select available assets
Establish the availability of any existing software assets as suitable candidates for re-use. Make sure you consult
with others who have knowledge of existing assets, particularly the Developer(s) and other stakeholders outside the project team (such as production
support teams) in order to form a balanced view of the suitability of existing assets for re-use. Identifying reusable
assets could be done as a team brainstorming session.
|
Define approach for structuring the system
Define the layering strategy for the software architecture. As a minimum, decide on:
-
The number of layers.
-
Their names and purposes.
-
Their relationships to one another.
These decisions should be captured as specific, high level aspects of the Design,
providing scope and structure that will evolve into a more detailed description of the system.
|
Develop deployment overview
| Outline how the software will deploy over the nodes on the network. Work with stakeholders such as as network support and
deployment teams to ensure that the proposed approach is a good fit for the wider technical environment. |
Identify key abstractions
Identify the key abstractions that the system needs to handle. You can usually find these by looking for nouns that the
requirements emphasize or repeat, because they help identify what is important to the business. The Glossary is particularly useful for this. Work with the analyst and stakeholder
here, as they will have knowledge and materials that are relevant to this task. Work with the developer to identify key
abstractions internal to the system.
Key abstractions should be documented as elements of the design that will evolve into more specific elements of
the system as more detailed development work is performed.
|
Identify analysis mechanisms
Catalog the architectural mechanisms that are necessary to fulfil the requirements (see Architectural Mechanism). These will be expressed as Analysis Mechanisms at this point in the process, because there is only a relatively
small amount of detail required for each mechanism. Discuss the requirements (especially supplementary requirements)
that are being addressed in the mechanisms with the analysts and stakeholders to assure the requirements
are unambiguous and well understood.
If explicit traceability to requirements is needed, map each mechanism to one or more use cases. This will show how the
mechanisms address the requirements and assist in the setting priorities for development of the mechanisms.
|
Capture architectural decisions
Capture important decisions about the architecture for future reference.
|
|
