Task: Analyze Architectural Requirements |
Analyze the architecturally significant requirements and define an architecture candidate for the system based on experience gained from similar systems or in similar problem domains. Define the architecture patterns, key mechanisms, and, where applicable, modeling conventions for the system.
Disciplines: Analysis & Design
Purpose
To provide sufficient guidance and direction for the team to be able to perform analysis and design in consistent and coherent ways.
Relationships
Roles | Primary Performer: Architect | Additional Performers: Analyst Developer Project Manager Stakeholder Tester
Inputs | Mandatory: Glossary Use Case Model Vision | Optional: Architectural Proof-of-Concept Architecture Design Supporting Requirements Use Case
Outputs | Architecture Design
Main Description
This task focuses on defining a candidate architecture that will guide the development, testing, and operation of system. It relies on gathering experience gained in similar systems or problem domains to constrain and focus the architecture so that effort is not wasted in re-inventing architecture. The work in this task may also be informed by one or more Architectural Proof-of-Concept products from previous iterations.
Steps
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.
Key Considerations
This task is primarily beneficial when developing new and unprecedented systems. In systems where there is already a well-defined architecture, this task might be omitted, or at least performed very quickly as a review of the existing architecture. It is critical that this task is performed collaboratively with active involvement of other team members and project stakeholders, so that consensus and common understanding is reached. It is particularly vital for the architect to involve the developer(s) throughout this task. Remember that the architecture effort is about providing leadership and coordination of the technical work rather than putting in a solo performance.
More Information
Guidelines | Analyze the Architecture
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright