An article titled Design and requirements? Pshaw! was published recently on Bridging The Gap. It discusses whether or not it is good practice to include ‘designs’ within a requirements document. I’ve seen this debate before, in various guises, and I’m always a little bemused and confused by it. And here’s the reason:
To me, it’s all design.
Now that’s going to take a little explaining, so bear with me.
Let’s start with a definition. According to Philippe Kruchten (in The Rational Unified Process, An Introduction):
“A requirement is a condition or capability to which a system must conform.”
BABOK® has a similar, albeit more rigorous, definition. Requirements, in what I think of as their ‘raw’ form, generally take the form of ‘the system shall…’, as in:
- The system shall allow the user to purchase products from the catalog
- The system shall allow a user to register their personal details
- The system shall allow the user to register multiple delivery addresses
- The system shall collect the following data for an address: House Name/Number (max 20 chars); Address Line 1 (max 40 chars); Address Line 2 etc.
- The system shall respond to user requests, on average, within 2 seconds
These are the sorts of statements you tend to get from stakeholders when you sit them down and interview them. Well, actually that’s a simplification. Usually the conversation goes something like this:
|Stakeholder:||“We’ll need to capture the user’s personal details”|
|Analyst:||“OK, like what?”|
|Stakeholder:||“Oh, you know – name, address, that sort of thing.”|
|Analyst:||“OK, so that’s first name and last name – what about middle name?”|
|Stakeholder:||“Erm, no, we don’t need their middle name. Wait – I’ve changed my mind. Let’s give them the option to include their middle name. My mother is very precious about hers.”|
|Analyst:||“And the address – is that just one address or could they have several?”|
|Stakeholder:||“Ah, yes, good point. They might want us to remember more than one delivery address.”|
|Analyst:||“And what data fields do you want for each address?”|
|Stakeholder:||“I’ll leave that up to you – choose something sensible, won’t you?”|
|Analyst:||“Naturally. Now, do you have a preference for what order we capture these details in?”|
|Stakeholder:||“Well I would have thought name first, then address. And maybe a little button to click if they want to add another address.”|
|Analyst:||“A button, you say?”|
|Stakeholder:||“Yeah, a button. And make it obvious. No, make it discrete – it doesn’t want to distract the user.”|
|Analyst:||“We could do it as a hyperlink if you like – that’s more subtle.”|
|Stakeholder:||“I like your thinking.”|
|Analyst:||“Of course you do.”|
At the end of this conversation, our analyst might write up the output of the exercise as a set of ‘the system shall…’ statements, and then maybe give each one a unique number for traceability. He would then report to his project manager that he has elicited the requirements for (some part of) the system.
He might then spend some time filling in some of the gaps, like exactly what an address looks like, and then tells his PM that he has elaborated or analysed the requirements.
Then he might show his elaborated requirements to the developers. These guys are smart, and therefore will invariably ask a number of awkward questions about things the analyst hasn’t thought of, usually starting with, “now what happens if…”, as in:
|Developer:||“Now, what happens if the user wants to delete an address, but they’ve already placed an order against that address?”|
|Analyst:||“Um, good point. Let’s say that they can only delete an address if they haven’t used it yet.”|
|Developer:||“What, so if they moved house 10 years ago they still can’t delete the old address?”|
|Analyst:||“That’s no good. Let’s say they can delete it as long as there are no active orders to that address.”|
|Developer:||“Ah yes, but what if they want to review an old order. We always display the address details on the Order Review page…”|
|Analyst:||“OK, let’s go for a ‘logical’ delete flag – don’t show it in the address book, but keep it on file for previous orders.”|
|Developer:||“I like your thinking.”|
|Analyst:||“I like your jumper.”|
Following this, our analyst spends some time updating the document and reports back to the PM that he has clarified the requirements.
So, in the analyst’s own language, he has elicited, elaborated and clarified the system requirements.
I would like to suggest that, in reality, what he has done is designed the system.
Just to be clear, I’m talking here about functional design, as opposed to technical design – the design of the user-visible aspects of the system, not its internal workings. But it is design nevertheless. What personal details to capture; what order to capture them in; what an address looks like; whether to have a button or a hyperlink. These are all design decisions – some made collaboratively (with a stakeholder or a developer); others made alone.
Now you might just say it’s merely a matter of terminology – requirements analysis versus functional design. But I think there’s more to it than that. I think there is also a difference in mindset, which manifests itself as follows:
- As a requirements analyst, I am unsure when I am finished because I am supposed to be defining the problem, not the solution. So do I include those wireframes or don’t I? Do I specify the types and sizes of those data fields or not? Are they part of the requirements, or are they part of the design?
- As a functional designer, I have no such uncertainty. I am designing the solution, with the help of the stakeholders and the developers. My scope includes all user-visible aspects of the system, large or small.
- As a requirements analyst, I do not take responsibility for the solution. I am but a messenger for my stakeholder. If the final solution doesn’t deliver the expected business benefit, it’s because the stakeholder told me to do the wrong thing.
- As a functional designer, I do take responsibility for the solution. My stakeholder tells me their business problem, and some ideas they have about how to solve it, but I work with them, and with the developers, to shape that vision into a working solution. If that solution doesn’t deliver the expected business benefit, I am fully invested in putting it right.
You could argue that there are some aspects of requirements capture that are not design. That very first meeting with the stakeholder, where they tell you their raw, unprocessed needs for the project – before you’ve had the chance to work them through. But if that’s all you’re going to capture – then you’re not a BA, you’re a scribe. As soon as you start probing, questioning, making the stakeholder think a little more about what they want – then you’re designing. And in any case, those ‘raw, unprocessed requirements’ are likely the result of a (sometimes subconscious) design process that the stakeholder has already gone through before even talking to you.
Here’s another way of looking at it. All business change tends to start from the statement of either a problem or an opportunity. So for example, your stakeholder might say, “Our call centre costs are too high – and by the way, most people are calling us to have their password reset.” They are stating a business problem. Now, as soon as they say, “I require customers to be able to reset their own passwords online,” they are designing a solution to that business problem. And if your stakeholder says, “We’re missing a trick here, we should be selling these books online, not just by post – what I need is an e-commerce solution,” then he’s stating a business opportunity, and he is already designing it.
As you can probably tell, I’m strongly in favour of the functional designer mindset. It encourages me to take responsibility for all user-visible aspects of the system, not just those that I (arbitrarily) classify as requirements.
Other issues I have seen with the requirements analyst mindset include:
- Incomplete requirements
- Lack of detail or rigour
- Use of the phrase “that’s a design issue” to fend off awkward questions from developers
I do think the mindset is shifting though. Use cases are a big help. I’m a big fan of use cases – their structure and language make it very clear that they are describing a design: “The user does X; the system does Y” etc. Also, check out these links:
- YouTube clip from “10 Years of Agile Manifesto” Conference – a discussion on business analysts versus designers.
- What a BA should know about the UX profession: Interview with Patrick Quattlebaum – how UX professionals approach design.
And yet I still hear BAs say: “Well, I’ve captured the requirements – as use cases – but I’m not doing the wire frames – that’s design!”
To me, it’s all design.