Lately, I've been working on the Architect Boot Camp info site and trying to lay out some really basic architecture information and some more advanced stuff. It dawned on me that there might be some who don't understand the difference between system requirements and architectural requirements. If this is news to you - stick with me. If not, I won't waste your time - catch you later.
Architecture requirements are typically those you collect during the initial scoping and context setting sessions at the beginning of a project while you are collecting high level system requirements. You need to determine the business objectives for the system, and for the architecture specifically.
It is so important to ensure that the architecture is aligned with the business drivers and objectives for the project. The architect keeps his or her eye on knowing where VALUE WILL BE ACHIEVED. What are the stakeholder goals? Main criteria for success?.
Setting system context helps to measure scope and set the appropriate boundaries. The architect needs to understand what the system interface will be, and what factors will characterize the architecture. Getting a list of top-level and high-priority goals will assist in setting this scope. This list can be further expanded when moving towards the elaboration phase of the project, and further gather the functional requirements.
The infrastructure must be designed to support the services and functionality that users require. It must deliver the appropriate levels of performance, security, usability and flexibility. All are factors that must be considered at the very beginning during the structure design and concept building of the solution architecture.
If the product is being purchased, the solution or system architects must review the requirements in order to determine their relevance and completeness. Specifically - those relating to non-functional requirements - specifically in the areas of performance, volume, methods of doing transactions or using the system, whom will use the system, how they will use it, etc. require review by the architects.
The architect must also ensure that these architectural requirements align with the Enterprise Architecture view. There are standards that are set for an organization, and typical infrastructures and patterns that are acceptable. Knowing, studying, analyzing these considerations in advance make up the architecture requirement gathering efforts for the early stages of the project.
These requirements need to be included in the solution architecture documentation set, and potentially used for volume, stress, and usuability testing during prototyping stages if the technologies are new, or if the requirements are risky.
Pure business functionality are user and system requirements. These are typically gathered by the systems and business analysts. An overview of such requirements should be held with the architect to ensure that they don't become intermingled, but there are shades of grey when it comes to "which documentation set" they belong to. You are a smart individual - you'll figure it out.
For more on architecture how-to's, visit The Architect Boot Camp.
Happy Architecting!
