Architecturally Significant Requirements - Gatheringapp/Project-management GitHub Wiki
Architectural Mechanisms are common solutions to common problems that can be used during development to minimize complexity. They represent key technical concepts that will be standardized across the solution. Architecture mechanisms facilitate the evolution of architecturally significant aspects of the system. They allow the team to maintain a cohesive architecture while enabling implementation details to be deferred until they really need to be made.
Architectural Mechanisms are used to satisfy architecturally significant requirements. Usually those are non-functional requirements such as performance and security issues. When fully described, Architectural Mechanisms show patterns of structure and behavior in the software. They form the basis of common software that will be consistently applied across the product being developed. They also form the basis for standardizing the way that the software works; therefore, they are an important element of the overall software architecture. The definition of architecture mechanisms also enable decisions on whether existing software components can be leveraged to provide the required behavior; or whether new software should be bought or built.
The value in defining architecture mechanisms is that they:
- Explicitly call out aspects of the solution mechanics that are common across the system. This helps you plan.
- Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces the workload.
- Promote the development of a consistent set of services. This makes the system easier to maintain.
Analysis
The purpose of this category is simply to identify the need for an Architectural Mechanism to be designed and implemented; and capture basic attributes for that mechanism.
Deciding whether a specific requirement is architecturally significant is often a matter of judgment. The selection of requirements that are considered "architecturally significant" is driven by several key factors:
- The benefit of the requirement to stakeholders: critical, important, or useful.
- The architectural impact of the requirement: none, extends, or modifies. There may be critical requirements that have little or no impact on the architecture and low-benefit requirements that have a big impact. Low-benefit requirements with big architectural impacts should be reviewed by the project manager for possible removal from the scope of the project.
- The risks to be mitigated: performance, availability of a product, and suitability of a component.
- The completion of the coverage of the architecture.
- Other tactical objectives or constraints, such as demonstration to the user, and so on.
Example
- The system must record every modification to customer records for audit purposes.
- The system must respond within 5 seconds.
- The system must deploy on Microsoft Windows XP and Linux.
- The system must encrypt all network traffic.
- The ATM system must dispense cash on demand to validated account holders with sufficient cleared funds.
Design
The purpose of this category is to guide precise product or technology selection. Deployability, modifiability and testability must be addressed in this step.
Some factors to consider:-
| Category | Type | Description |
|---|---|---|
| Usability | Accessibility | The ease with which different facets of the system are exercised. |
| Aesthetics | The aesthetic quality of the user interface. | |
| Consistency | The consistent use of mechanisms employed in the user interface. This applies both within the system, and with other systems. | |
| Reliability | Accuracy | The accuracy of any calculations performed. |
| Availability | The amount of system "up time." | |
| Recoverability | The elegance with which the system recovers from failure. | |
| Performance | Recovery time | The time to recover from a system failure. |
| Response time | The time for the system to provide a response. | |
| Shutdown time | The time for the system to shut down. | |
| Start-up time | The time for the system to start up. | |
| Throughput | The capacity of the system to support a given flow of information. | |
| Supportability | Adaptability | The ease with which the system is adapted to new environments. |
| Auditability | The ease with which the system provides audit trails of its execution. | |
| Compatibility | The compatibility of this system with previous versions of the system. | |
| Configurability | The ease with which the system is configured. | |
| Installability | The ease with which the system is installed. | |
| Localizability | The level to which the system supports multiple human languages | |
| Maintainability | The ease with which the system is maintained. | |
| Scalability | The ease with which the system can scale in terms of data volumes and users. | |
| Testability | The ease with which the system is tested. | |
| Implementation | Third-party components | Any constraints on the use and cost of third-party components. |
| Implementation languages | The implementation languages to be used. | |
| Platform support | The platforms that the system will support. | |
| Resource limits | Limits on the use of resources such as memory and hard disk space. | |
| Standards compliance | Any standards to which the system must conform. | |
| Interface | External systems | External systems with which this system must interface. |
| Interface formats | The format of any data passed between this system and external systems. |
Implementation
This specifies the exact implementation of each mechanism, it can be presented as a design pattern or example code.