This is the tenth in a series that explains the thinking behind the Volere [1] requirements techniques—previous and future articles explore aspects of applying these techniques in your environment. This article illustrates how the requirements travel all the way through an organisation – and beyond - and how everyone is interested in/affected by them but all for different reasons.
From Go to Whoa
Christophe wants to buy a new suit to wear to his daughter’s wedding. He wants a dark blue suit with a waistcoat – and he wants it to make him look as elegant as possible. He wants the suit to be tailored especially for him. He goes to a men’s wear shop in Jermyn Street in London and tells Jerome, the salesman, what he wants. At this stage Christophe’s requirements are quite fuzzy – he might know (or think he knows) what he wants, but what he says is wide open to interpretation.
Jerome asks Christophe many questions and shows him pictures and samples to help him focus on the details: single or double breasted? Will you be wearing the suit in cool or hot temperatures? Which of these colours of blue appeals most? What is your budget? What will your wife be wearing? What is the date of the wedding? Which of these styles of trousers do you prefer? Jerome writes down the answers to the questions and sketches ideas when he thinks that adds clarification. When Jerome thinks he has a reasonable statement of the scope of the tailoring project, he calls on Rupert the tailor.
Rupert reviews the requirements that Jerome has captured and considers them in light of the possible solutions. Providing Jerome has made an understandable interpretation of Christophe’s requirements then Rupert can apply his experience to suggest the alternative suits that fit the requirements and take maximum advantage of the constraints. Jerome discusses the tailor’s recommendations with Christophe and helps him to make a final choice of the material and style and he makes sure that he has accurately recorded Christophe’s measurements.
Rupert the tailor then assigns tasks (cut material, cut lining, make sleeves, make trousers...and so on) to his tailoring team and the suit is gradually made. The happiest outcome is that the suit fits Christophe perfectly and he is very happy with the design, fabric and value for money. He is confident that he will cut a fine figure when he gives the speech at his daughter’s wedding.
A Simple Food Chain
The requirements traveled all the way through the story of the wedding suit. They started when Christophe decided he needed something new to wear to the wedding, became more precise as Jerome asked questions and specified some of the details, became more precise when Rupert the tailor provided specific choices and finally provided details of the individual specifications for each piece of the suit. At various points along the food chain new requirements details were originated and/or consumed by different people for different reasons.
Figure 1: A simplistic view of the requirements food chain
Figure 1 shows the chain a requirement travels from its origin all the way to its eventual solution. During its travels, the requirement is fed and watered with additional details and translations until it is eventually input to the development of a solution. The feeding and watering could be done by the same person in a single stream (this is the simplistic view shown in this picture) but that is very rare.
Normally in our worlds there are many different people iteratively involved in each stage of this food chain.
Originators and Consumers
The idea of a requirements food chain populated by originators and consumers is a way of mapping different stakeholders’ interests and responsibilities as the requirements travel along the chain. Every element on each one of the requirements is relevant to different people for different reasons. For example, one of the attributes of an atomic requirement is the Rationale – this describes why this requirement is important. Let’s suppose that, in your organisation, it is the responsibility of the Business Analyst to ensure that the rationale is recorded. So we can say that the Business Analyst is the Originator of the Rationale. Further along the requirements food chain the Developers use the rationale as input to their design decisions. And the Testers use the rationale as guidance in designing tests. In other words the developers and the testers are Consumers of the rationale, each for a different reason.
A consumer of one element might also be an originator of other elements. As we said, the developer is a consumer of the rationale. When he makes a decision about the solution then he is an originator of the solution for the requirement’s implementation.
The consumer should not change/lose the original understanding of the requirement or the food chain will be broken and it will be impossible to do iterative development and make changes to the requirements.
A More Realistic Food Chain
Figure 2 is a more realistic view of the food chain that a requirement follows from its embryonic state to its solution. This picture includes the feedback loops and the changes and additions to the requirement made by various originators as it travels along the food chain.
Figure 2: A more realistic view of the requirements food chain
Everyone in the food chain is focused on his own different role-influenced reasons for being interested in the requirement. And every time the requirement passes from one person to another there is a risk that someone might make a change, omission, addition, translation... that leads to the loss of the cognitive thread of the requirement. When this happens, the solution to the adult requirement bears little relationship to the original embryo. Everyone is doing a good job within his/her role silo but the connections between the problem and solution are often lost along the way.
The Role of the Business Analyst
Somehow or other every project needs a way to avoid this pollution of the requirements food chain. And that means that somebody needs to be responsible for the traceability of the requirements from embryo to solution. This is why we have Business Analysts.
Clearly, a Business Analyst cannot possibly have all of the specialized role-related skills that exist along the requirements food chain. Instead the BA is the person who recognizes each specialty and ensures that the intention of the requirement is accurately communicated along the food chain. Our organisations are growing both in size and geographical complexity, the combinations of technology that we use change all the time. The resulting complexity of the communications mean that a BA needs to have a mixture of technological and sociological skills.
We need to think about Business Analysis as a socio-technical profession.
More information is available:
- http://www.volere.co.uk
- in three books written by James Robertson & Suzanne Robertson, the most relevant to this article is Mastering the Requirements Process – third edition.
- in Volere seminars and consulting
- on the Volere Requirements Linked In group http://www.linkedin.com/e/vgh/2491512/
Author: Suzanne Robertson and James Robertson, The Atlantic Systems Guild
Suzanne Robertson and James Robertson are principals and founders of The Atlantic Systems Guild http://www.systemsguild.com and joint originators of the Volere requirements process, template, checklists and techniques http://www.volere.co.uk
You can contact them at [email protected] [email protected]
1. Volere is the Italian verb – to wish or to want