The Requirements Food Chain

by Suzanne Robertson

March 2015

This is the tenth in a series that explains the thinking behind the Volere requirements techniques. Previous and future articles explore the application of these techniques in your environment. This article illustrates how the requirements travel through an organisation and beyond, and how different people are interested in or affected by them, but each for different reasons.

By Suzanne Robertson & James Robertson

From Go to Whoa
Christopher 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. To achieve this, 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 Christopher’s requirements are quite fuzzy – he might know (or might think he knows) what he wants, but so far he has said it in a way that is not precise enough to achieve the desired outcome.
Jerome asks Christopher many questions and shows him pictures and samples to help him focus on the details. Do you want single or double-breasted? Will it be hot or outside at your daughter’s wedding, or inside in air conditioning? Will it be a daytime wedding or at night? 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 his questions and sketches ideas whenever he thinks it might clarify things for Christopher. When Jerome thinks he has a reasonable statement of the tailoring project, he calls on Rupert the tailor.
Jerome has made an understandable interpretation of Christopher’s requirements. Now Rupert reviews the requirements and uses his experience to suggest alternative designs of suits that both fit Christopher’s requirements, and take maximum advantage of the constraints. Jerome discusses the tailor’s recommendations with Christopher and helps him to make a final choice of the material and style. He also ensures that he has accurately recorded Christopher’s measurements.
When production begins, Rupert the tailor assigns tasks (cut the suit fabric, cut the lining, make the sleeves, make the trousers...and so on) to his tailoring team; and so the suit is gradually made. The happiest outcome is that the suit is a perfect fit for Christopher, and that he is happy with the design, the fabric and value for money. An even happier outcome is that he is confident that he will look his absolute best when he gives the speech at his daughter’s wedding.
A Simple Food Chain
The requirements travelled all the way through the story of the wedding suit. They started when Christopher decided he needed something new to wear to the wedding. They became more precise as Jerome asked questions and specified some of the details; became even more precise when Rupert the tailor provided specific choices; and finally as precise as they could be when Rupert provided details of the individual specifications for each piece of the suit. At points along the food chain, new requirements details were originated and/or consumed by different people for different reasons.
Figure 1 shows the chain where a requirement travels from its origin to its eventual solution. As it travels, the requirement is fed and watered –additional details, translations and modifications are made – until it is eventually input to the development of a solution. The feeding and watering is usually done by different people in different roles, each bringing their own particular skills and interest to the requirement.

Originators and Consumers
The requirements food chain, populated by originators and consumers, is a way of mapping different stakeholders’ interests and responsibilities as the requirements are brought to maturity. A requirement is not a simple sentence; it is a composite of diverse attributes, and each of these 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 and how much importance to assign the tests. In other words the developers and the testers are Consumers of the rationale, each for a different reason.
A consumer of one attribute might also be an originator of other attributes. The business stakeholder might originate the statement of intent, “The product shall . . .” and this in turn is consumed by the business analyst who then originates the rationale. Both of these originators might then read (consume) these attributes and originate the fit criterion, the measure of the requirement to make it testable. Naturally enough, the tester will become a consumer of the fit criterion.
It is important that consumers respect the attributes that others have originated. They must not distort or pervert or omit any attributes as they add to and refine the requirement. The requirement must remain semantically intact as it progresses along the food chain.

A More Realistic Food Chain
The food chain is not exactly linear as we previously portrayed it in Figure 1. Figure 2 is a more realistic view of how a requirement matures as it goes 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.
Everyone in the food chain is focused on his own different role-influenced reasons for being interested in the requirement. This means that sometimes there will be conflict between the aspirations of different stakeholders, leading to revisions and iterations, instead of a steady progression to the end result. However, such is the nature of requirements, and it points to the need for collaboration between the parties, and how the requirement is the vehicle for bringing together disparate viewpoints. Just as humans pick up new experiences and influences that change and alter them as they move from childhood to maturity, the requirement goes through various formative stages before it is ready to bring about to the ultimate, optimal solution.
The Role of the Business Analyst
Somehow or other every project needs a way to avoid pollution of the requirements food chain by stubborn vested interests. This means that somebody must be responsible for the traceability of the requirements from embryo to solution. This is one of the reasons for employing business analysts.
Clearly, a business analyst cannot possibly have all of the specialised role-related skills that exist along the requirements food chain. Instead the BA is the person who recognises each specialty and ensures that the intention of the requirement is accurately communicated to each of them along the food chain. Our organisations are growing both in size and geographical complexity along with the ever-changing combinations of technology. The resulting complexity of the communications mean that a BA needs to have a mixture of technological and sociological skills.
Here we think of the business analyst as someone who guides the requirements as they move in the food chain. It is the business analyst who, by virtue of his or her detached position, is best placed to ensure that the real meaning of the requirement is brought out and preserved by the contributions of the participants in the food chain. It is the business analyst who is ultimately responsible for the requirement reaching a full, and correct, maturity. Then, and only then, can the developers build exactly the product needed by the business.