If you were to build a house, you would start by setting the requirements based on the features you want the house to have: size, number of rooms, flooring materials, etc. The next step would be to hire an architect to create a design that would capture your requirements, which would result in a house layout and things like floor plans, electrical schematics, etc. For an engineer building the house, although the requirements are important to understand the vision behind the project, the design specifications are what give the concrete details of what exactly is to be done, and therefore what matters the most from the perspective of the engineer (who maybe doesn't care that much about what you really want).
In the traditional software world, things are not very different. An architectural design specification is a technical document that describes how a software system is to be developed to achieve the goals described in the requirements. It's analogous to the house plans. It is the most crucial piece of documentation for the developers as it lays out what exactly is to be built down to the technical details. Traditionally, due to the high level of fine-grained details that go into the design, this stage of the development was very costly and time-consuming.
In the Agile world, requirements take the form of user stories, which, when refined to include the system design details, also encapsulate the specifications. User stories capture much more accurately, and with much less formality, what the real requirements and desired functionalities are. Although it may create room for gray areas and subjective interpretations, this user-centric approach usually leads to better end products. There's a reason one line of the Agile manifest reads, "Working software over comprehensive documentation," and it is because comprehensive documentation is not nearly as important as getting things right by listening to the users.
In this guide, we will explore how to reason about architectural design specifications in Agile.
Because in Agile practices the requirements are captured into user stories and formulated from the end user's perspective, the design efforts should be consistent with that perspective from the start. It is therefore important to adopt customer personas when designing the system to ensure that the system will deliver the expected value.
Making sense of the architectural design comes down to the following steps:
The FURPS+ acronym, devised by HP, represents a model for classifying the various attributes of software quality. Albeit somewhat dated, FURPS+ still stands as a very useful framework for software development even in Agile culture. It can be used as a way to elicit requirements from Agile user stories. The acronym stands for:
Except for the "F" part of the acronym, everything else relates to non-functional requirements, which is why a significant amount of time and effort should be dedicated to understanding them. Once again, the shared understanding is an important pre-requisite, as some of these qualities can only be properly captured into the design by assuming the user's perspective and empathizing with the user's concerns.
The '+' part of FURPS+, added as a revision to the original framework (FURPS), includes some of the technical and business constraints mentioned previously.
One final note about architectural design is that, as with everything else in Agile, it should not be written in stone and treated as a non-negotiable contract. The end product is the contract, and the design can evolve as many times as necessary to accommodate changes—be it technical changes, such as new constraints derived from a platform update for example, or just a change in perspective because someone realized a slightly better way of doing something to achieve the user's goals. Hence the importance of interpreting architectural design specifications through the broader perspective of a shared understanding and through the lenses of frameworks such as FURPS+ that include system qualities that are essential for building good software products.
Requirements and specifications in Agile are no longer the intimidating pieces of documentation that they used to be in the old days. And they're no longer one man's job either, but a team effort that is based on a shared understanding of the user's goals and on the collective wisdom of the team. They take the form of user stories, which assume the user's perspective and express real concerns as opposed to untested assumptions of what they are.
Understanding the requirements and design specifications are therefore not a skill to be practiced only by product owners, but by every member of an Agile team on an ongoing basis. Getting the design right will almost certainly pave the way for a successful product.
If you're feeling confident that your team has a shared understanding of user's goals and a general idea of the functional and non-functional requirements to aim for, check out this guide: Refine user stories and acceptance criteria with Agile.
You can also check out this related course, especially if you work with Microsoft Azure: Microsoft Azure Developer: Aligning Functional and Non-functional Requirements