Greetings Earthling. Take me to your leader.

Not that old cliché again. Do you mean the CEO, the CIO, the CTO, the lead BA, the project manager, the programme manager, the product owner or the technical lead?

I was expecting a prime minister or a president. Who are all those people?

They all have some impact on the requirements for the project I am doing.

Requirements? What are requirements?

Requirements are what the solution has to do, and how it has to do it. Your spaceship has a requirement to be able to travel at the speed of 25,000 Km per hour so you could make the trip in say, 150 days, and it has to keep you comfortably alive during the voyage from Mars.

I made it in 100 days. But I hate how hard it was to understand the navigation system.

That’s the result of poor requirements work. There are also environmental requirements about how cold it would be along the trip, and the security requirements about who could use what controls, not to mention the legal requirements that would have told you your spaceship is illegally parked in the street. There are lots more. I use this Volere template to help me ask all the right questions.

Volere? What is Volere?

It’s a framework that lots of people use when discovering the requirements. I find it useful to have guidance without being constrained by a formal process. I like it a lot.

What’s different about it?

Firstly, it makes a distinction between the work and the solution. The work is the business that the organisation is doing, and the solution is the automation (or something else) that is intended to improve the work.

How can you know what solution will improve the work if you don’t know what the work is?

Exactly, so it’s important to have a clear understanding of the work and separate it from the technology of any solution you might be thinking of.

How do you do that?

I use this Brown Cow model that shows each viewpoint, and allows me to see at any stage exactly what I and my stakeholders need to see.

Brown Cow?

Yeah, I’ll explain why it’s called Brown Cow later. But what it shows is a separation of the technological view, the “How”, from the abstracted essence, the “What”. And then it further separates “Now” from the “Future”. It makes it really easy to see what you’re talking about, and makes it easier to communicate with the stakeholders.

I thought ‘essence’ meant a concentrate of a plant.

Yes, it can mean that, but here it means the core of the work as if you could see it without any kind of enabling technology. The underlying policy, if you will.

You Earthlings are so proud of your technology. Why do you want to see the work without its technology?

So that you can see that you are solving the right problem, and not just rushing into an attractive solution. Lot’s of projects fail because they build a good solution to the wrong problem.

Maybe that’s the problem we have on Mars. We just say what we want and it appears. Usually we get what we say we want but it turns out that’s not what we need. If we discovered our requirements like you Earthlings do, would that make things better for us?

Probably, but you have to make sure that you’re seeing the real problem and not just talking about a proposed solution.

We Martians have abstractOvision, you might call it X-Ray vision. We can see the underlying reason by looking at any solution.

That would be useful, but we earthlings have to build models so we can see the essence without its technology because it is much easier to see each view separately. It’s not that hard to do, but you have to think about it a little.

You earthlings talk about thinking a lot. For example, what’s ‘Systemic Thinking’? Is it similar to the way that we Martians think?

Possibly, or maybe it’s better. Systemic (or systems) thinking is when you look at the entirety of a business system to ensure that if you change one component, it does not disrupt another. Also, you might find that a beneficial change to one part of the system means you open up an opportunity in another part. It means that you look at the whole scope of the work.

How do you know that you have the whole scope?

That’s where Volere is particularly good. I build this context diagram that shows the work and how it fits into the world that surrounds it. This allows me to know exactly how big the work space is. Some of the problem areas are big.

Big? How do you deal with big problems?

Obviously I break them into smaller ones. I use business events as my way to partition the work.

Business events?

Yes, business events. These are things that happen outside the work and the work responds to them. If I look at one business event at a time, it means I am seeing the work as its customers outside see it. It’s a more natural way of partitioning.

What do you do when you have partitioned the work?

I study each partition and come to an agreement with the stakeholders on what we all want and need the work to be. Once we know that we can look for the optimal solution and write either product use case scenarios or story cards.

Story cards?

Yes, I write a story on a card like this: “As a bank customer I can project my discretionary balance so that I can see what I have left to spend this month.” This acts as a placeholder for the requirements that are developed in a conversation between the developers and the business analyst and some of the business stakeholders.

Or I could write the requirements using this snow card.

Snow card?

Yes, it’s a way of capturing the requirement so that you know why the requirement exists, and how to measure it so you can test it when the developer builds it. We call this a fit criterion.

How does a fit criterion work?

Suppose I’m building a smart card tap-in-tap-out system for urban transport, and I have a non-functional requirement, such as “The product shall be intuitive for new travellers to use.” I would ask for the Rationale, and let’s suppose that is “So that people do not hesitate to use it and block up the entry gates.” I would measure this—that is add the fit criterion—by saying “90% of first time travellers pass through the entry gate within 3 seconds from the point where they are one metre from the gate.” It’s a pretty important requirement, so it is worth the effort and expense of testing on a group of representative travellers.

You mentioned non-functional requirements. What are those?

Functional requirements are what the product has to do; the non-functional requirements specify how well it has to do them. For example, non-functional requirements cover things like look and feel, usability, operational, security and so on. There is a complete list in the Volere template. You can go online and see it.

I can see it without ‘online’, the X-Ray vision remember. And yes, the template looks like a very complete list of requirements types.

I find it very helpful—it means I can ask all the right questions, and for the stakeholders to know why I am asking all those questions. So it doesn’t matter if I am working on an agile or sequential project, I still have to find what the product has to do, and how it has to do it.

All those requirements sounds like a lot of information for an earthling to process. How do you keep track of it?

Volere includes this knowledge model—a language for talking about requirements. It shows all the information that you need to collect, and helps to break it down to smaller chunks and use for iterative development. There is also a book “Mastering the Requirements Process”. There’s a Kindle version.

Ah, I can see that ‘online’ too; very impressive. I shall take a copy back to Mars.

While you are ‘online’ you should check out www.aguarra.cz, they have training on this stuff, but I would get going if I were you. Your spaceship is about to get a parking ticket. By the way, why do you speak in italics?

 

About author: Suzanne Roberts – consultant, researcher and co-author of Mastering the Requirements Process, a guide for practitioners on finding requirements and writing them so that all stakeholders can understand them. The product of her research and experience is Volere, a requirements process, template and techniques for assessing requirements quality, and for specifying requirements.