This blog talks about requirements in the context of architecture design – including their importance and some bare minimum needs.
If you have read ISO42010, the ISO standard for architecture description, you will realize how important requirements are. They are how we define the needs of our different stakeholders.
Similarly, if you are using TOGAF, you will see requirements management right in the middle of TOGAF ADM. Generally speaking i tend to think we can manage requirements at different levels, depending on the context of what we need to do, and who we are doing it with.
High Level Requirements with Management
- Who needs to get value from this?
- What is it that we need?
- What value does that bring?
…In taking that approach in a more discursive meeting you have to be very careful – i find its really easy to get into long meetings where you discuss whats needed, but loose track of what the value is that’s brought.
Defining the next level of detail – Capturing requirements
The user stories are great for talking with management, but they are not really enough to be actionable by themselves. We need to refine our requirements into something that is actionable, and clear for anyone working with a design. Its not unusual in a big project to have many high level meetings, and have many stakeholders that need to get value – at this point we need something we can practically work with in design. I need to capture requirements in one place- be it Confluence, Excel, or in a formal modelling or database tool. If its not in one place, its very easy to lose requirements.
There are many things you can ask for but again speaking of minimums to look at as part of an initial architecture definition phase:
- What is the source of the requirement? Who did it come from? A specific team, person, project or role?
- What is the destination of the requirement? Is this a requirement coming towards us, or is it a requirement we will need another team to manage? For example if we have a website, the database back end may be run by a completely different team, which we may have the requirement for.
- What is the actual requirement? The definition of the requirement – it should be as clearly stated as possible and not ambiguous – someone is going to have to validate the requirement has been met. Saying “we need a fast database” is subjective – saying “we need 5000IOPS from the database storage” is a lot better defined – and significantly reduces the risk of miscommunication
- What is the rationale of the requirement? The reason behind the requirement – It can be simply stated such as “ISO27k Compliance”, “Customer requirement”, “Needed to by the quality team”. Its very often skipped, but is very important because requirements are read by many people from many teams, not all with the same understanding of things. Solutions & Requirements can live for years and its easy to forget why you do something. If you come back to an architecture design with a need to change it later you will be thankful for this – it saves you having to spend countless hours understanding why we do things.
- What is the priority of the requirement? Commonly I use MoSCoW for this (Must Have, Should Have, Could have, Won’t have). In any given release some things are more important than others.
- How do I identify requirements? Its worth mentioning that requirement IDs are a good idea to identify right from the start because the exact wording of a requirement is sometimes refined and its easier to speak of specific IDs in general.
Not describing any of the things above will only leave issues later.
Managing requirements once they are defined
During an architecture design project we need to work with each of the requirements, to ensure that they are met – and to show how. Requirements Realization is a whole topic by itself. I spoke about this in my blog Assessing solution requirements – There’s a whole lot more i would like to say on it should I get the time; some of the things i say in that blog are covered in here, but the focus is different. – but the basic things we need to capture are:
- How the requirement is realized – is it by a specific tool, a specific business process, a specific automation? This is one of those things that are often discussed in meetings, but then sometimes not captured in design – if you ever came back to a project after a year and tried to figure out why someone had made a technology because you want to change something, you may feel pain if this isn’t done. It can lead to huge investigations and many meetings with people which in some cases i have seen thousands of hours being burned. In the absolute worse case you may actually lose this information entirely because people have lost of forgotten.
- The status of the requirement – different requirements can be in different states – the basic statuses of requirements i would say are – Proposed, In Progress, Implemented, Verified, Deleted, Differed, Rejected.
- Who’s working with the requirement – on a big project with more than one architect its good to name which architect is being responsible for managing the requirement and ensuring its properly realized (if need be).
- Activity Log against the requirement – sometimes the whole architecture design process will have a work log and in there you can show what is needed – but sometimes is better to have a log of activities against each requirement – nothing big, just date, whats happened, and who has done it. this way you can keep track of things in a complex project.
Summing it up….
As i said, these are really minimums – I have seen many variations on the above, but have found if you haven’t considered the things I have written about above there is almost certainly going to be an overhead. at some point of time someone will have to run meetings, or investigations to find out what or why something is a certain way, or someone may do something stupid simply because they are not aware of the relevance of a specific piece of architecture. Without properly defining requirements we simply cannot ensure a technical design is fit for purpose.
There are lots of things to consider. but properly managing requirements will radically improve both quality in architecture, and success in project management.