When venturing into a new project (assuming you are responsible for the solution design) you’ll generally be handed a requirements document by a business analyst or other business user. This document will include a collection of paragraphs detailing what the solution should do in certain scenario’s and contexts (with some sort of MoSCoW priorities indicator next to each requirement).
It’s now your job to turn those requirements into a set of architectural views, tie those views together and create a solution architecture document. Go!
Ok, let’s back up a bit and break down what exactly you’re looking at here. For an architect, the most important part of the requirements are those that will drive your initial architectural decisions. These are the non functional requirements and these determine certain qualities the resulting system must have.
Let’s look at what you might expect when dealing with requirements.
Functional requirements detail the expected behaviour of the system. It describes WHAT a system should do. It may include one or more User Stories, a paragraph that describes what the user wants and usually written by the user. This avoids developers going off and writing code that doesn’t do what the user wanted. Functional requirements also include Use Cases which are similar to User Stories as it also describes the interactions between the user and the system but at a more granular level. Use Cases also generally include the rationale (the reasons / logical basis for the case), the applicable users, any preconditions that must be in place for the interaction and any post-conditions.
As the name suggests, these are not concerned with the functional aspects of the system (the behaviour) but rather the operation and evolution of the system over time. They place constrains on HOW the system will do what the functional requirements specify. They detail the systems operational quality attributes (the qualities the system must exhibit). These desired quality attributes are major drivers in the architectural decisions that will follow.
The quality attributes are many, so here’s just a few of them, including a short description :
- Accessibility – How accessible the system is to as many people as possible.
- Availability – The probability the system will work when required. High availability says that a system will have a high probability of being available.
- Backup – The strategy for ensuring that the system can be recovered from a backup
- Capacity (current and forecast) – The maximum possible capability of a system at a single point in time. Including, concurrency (parallel processing of requests / user interactions), load (determined via load tests).
- Deployability (think provisioning), how you can deploy or un-deploy software in order to have flexible provisioning.
- Modifiability – Understand how changes to architectural elements may cause a ripple effect when changes. Isolate elements that may change (refer to the 3 types of change in ‘why solution architecture is important‘).
- Performance – What are the important resources in a system (e.g. cpu / memory) and what is the demand on those resources? Has the impact of access to shared resources been considered?
- Re-usability – What are the element couplings? Can they be removed and re-used elsewhere without causing the system to topple over?
- Scalability – Will the system scale? Localize the use of resources to facilitate the introduction of higher capacity replacements.
- Security – Manage inter-element communication. What elements can control what other elements?
- Throughput – The amount a system can handle over a fixed period of time (e.g. total capacity over an hour).
- Vendor lock in avoidance (using open standards and not being completely reliant on any vendor software, e.g. oracle)
So, feeling better about requirements? Good, now go work up an architecture and have it on my desk by Tuesday.