In the previous article of this series we explored the Requirements domain entities, i.e. the things we need to know about if we want to capture and manage our Requirements correctly and efficiently. These entities were:
- Stakeholders and Actors
- Business Goals
- Capabilities
- Features
In this article, we'll learn how these entities are related and how we can model them in a visual and intuitive manner.
Impact Mapping
Back in 2012, Gojko Adjiz defined the concept of Impact Maps, a technique that he evolved from UX-based effect-mapping methods, to improve communication, collaboration and interaction in teams and organisations. Impact Mapping allows us to explore, analyse the discover answers to the major questions we have when starting to build a system:
- Why are we doing it?
- Who will benefit from it?
- What do we need to do?
- How are we going to do it?
The answer to these questions help us discover the entities involved in our Requirements and Specification model
- Business Goals (Why)
- Stakeholders (Who)
- Capabilities (What)
- Features (How)
We can additionally discover and define Tasks, that is the units of work we need to do in order to build our system.
Example Impact Map
So, how do we get to create a well-defined Impact Map armed with only our client's wishes and desires (i.e. their raw requirements)? Read on to find out.
The D3 method
As System Builders we have requirements thrown at us from many directions: client representatives, project managers, product owners, business analysts and fellow developers, they all want something from our system. These requirements come in many shapes and forms: formal statements, conversational statements, user stories, flowcharts and other diagrams and many other forms. Our job is to analyse these requirements and model the relevant entities in an Impact Map. Let's see how we would go about this task:
Let's say our client has told us they want their system to notify users when a certain product they have bought previously goes on sale. They might have expressed this in a formal statement ("The system shall notify user who have previously bought laptops..."), as a user-story ("As a past buyer of a laptop, I want to be notified...") or simply in an over-the-phone verbal exchange. To analyse and model this, we shall use a simple method I call D3: Decomposition-Derivation-Discovery.
Decomposition
Decomposition is the breaking down of the requirement to determine how many and what kind of entities it represents (Business Goals, Capabilities, Features or Tasks). A good heuristic for doing this is looking at the verbs of the main clause i.e. "The system shall notify..", "I want to be notified...", etc.
By examining our sample requirement in this light, it becomes apparent that there is only one entity involved and it has to do with notifications. It could have been that there were more than one verbs in the main clause, in which case we'd be dealing with two entities, but luckily that's not the case in our example.
The next step is to decide which type of entity it is. Obviously the whole 'notifications' thing isn't a Business Goal or a simple Task, so it's either a Feature or a Capability. A Capability is a high-level, coarsely-grained ability the actors can leverage in order to achieve their Goals. It answers the question "What can the system do for the actor?" A Feature is a medium-to-low-level, fine-grained piece of functionality that the system provides to it's actors. It answers the question "How can the actor realise this Capability?"
Given that what we know about the requirements is an abstract wish to notify users under certain conditions, then it would be reasonable to assume that we are dealing with a system Capability. Let's give it an appropriate name and add it to our model:
Defining a Capability
Derivation
Derivation is the creation of other Requirement entities that our original entity depends on, or that are dependent on our entity. So far we have identified a Notification Capability for our system. As every Capability must exist to realise a Business Goal, we must ask ourselves what the Business Goal is in our case. It's best not to make assumptions at this point and converse with our client in order to understand what they want to achieve by offering this Capability. Remember that we can and must validate the Business Goal, according to the standards described here. Let's say that in our case our client wants to use this Capability to entice their customers to buy more stuff, thereby increasing the client's revenue. That's a perfectly valid Goal, so let's add it to our model.
Defining a Goal
Now let's look at the right side of our Impact Map. We haven't yet defined any Features for our Capability. Let's do so now. We simply need to answer the question "How can we Notify users of product sales?", or else "How can we deliver the Notifications Capability?" Two possible answers would be: 1) Email notifications and 2) In-app notifications. As usual, we need to check with our client that these Features are acceptable to them. Assuming that they are, let's go ahead and add them to our Impact Map.
Defining Features
Finally, let's get down to the nitty-gritty of it and create some Tasks for each of our Features. Tasks are pieces of work that need to be done in order to implement a Feature. Most often they will involve coding, but they may also be about writing documentation, setting up a CI/CD pipeline or anything else that needs to get done to get our Feature up and running.
Defining Tasks
And that concludes the Derivation phase. We started with a single requirement and now we have a fully-populated Impact Map. But we're not done yet.
Discovery
Often the most overlooked phase, Discovery is about discovering new Capabilities that our system may need. The Business Goal is a good starting point. Are there any other Capabilities our system could offer to help attain that Goal? In our example our client wants to entice users to buy more so we're offering the 'Notification of sales' Capability. Another Capability that would help towards this would perhaps be a 'Discount for bulk buying' Capability. This is something we could (and should) discuss with our client. After all, we are more than just code monkeys, we are System Builders who want to help our clients achieve their Goals.
Discovering other Capabilities
Naturally, once we add new system Capabilities we should go back to the Derivation phase and make sure we create some Features and Tasks for our new Capabilities.
Epilogue
So there you have it, we started with our client's raw requirements and used a structured approach to create a well-defined model of our Requirements and Specifications. There is one more step we need to go through before we can start coding away and this is to detail our Features. We'll do that by writing some Executable Specifications. More of that in the next article :)
Top comments (0)