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.
A well reasoned argument, but one I still disagree with. The term ‘design’ is pretty fixed in the minds of most people and tough to play with. I do requirements discovery all the time without any expectation of design, they are used to evaluate software packages or enhancement of existing systems that are already designed.
In any case, should generate a good discussion, let’s see where it goes.
It’s not all design.
They have to be thought of as being separate, because requirements is the WHAT, whereas design is the HOW and need to be referred to accordingly.
Having said that, it should be collaborative and iterative, whereby one phase (analysis) flows into the other (design) and possibly loops back again.
There are some requirement issues that are only unearthed during design which then have to be referred back to analysis. (no different from some issues unearthed in Development or QA that have to be referred back stream)
@Bennett This is exactly where things go wrong. If HOWs are considered WHATs and WITH WHATs are considered HOWs by stakeholders. It gets really confusing when one stakeholder considers it a HOW and another one a WHAT. This is usually the case when standard frameworks are chosen which needs to be extended for specific use. Often it ends like ‘but I already paid for this why does the developer need to work on it’ and I reply : ‘no you just paid for the WHAT not the HOW’ or for the ‘HOW and not the WITH WHAT’. In the end it is just expectation management and communication brokerage. In my role as architect I am collecting all those and try to put them in the correct box. It is the same ‘game’ for software -, solution -, as for enterprise architecture issues. And I have to say, for some people their world and perception about the IT industry will collapse and the magic of it is gone and they have landed back on earth again.
I wonder how many people here agree with this part?
“As a requirements analyst, I am unsure when I am finished because I am supposed to be defining the problem, not the solution. ”
Tony, do you?
In my last post (http://www.bridging-the-gap.com/help-a-ba-how-do-i-get-stakeholders-to-focus-on-business-requirements/) I touched this subject. To quote the BABOK, “solution requirements describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are developed and defined through requirements analysis.”
I have never worked with a “requirements analyst” who only defined the problem, leaving the solution for another analyst to define, and would be curious if you or any reader here has this experience.
Adriana, I agree with you on this. I’ve always been part of defining the solution.
I suppose we could take the opposing view too and say “it’s all requirements.”
At the end of the day, I think the requirements-design debate comes down to how we use the terms and how we define roles instead of how we solve problems. So we always get muddied because the terms are used inconsistently and the roles are rarely consistent across organizations.
‘I’ve always been part of defining the solution.’
Funny enough that is the reason why I named my own consulting firm, just that ‘part of the solution’.
I find Adriana’s question interesting. I agree with Laura’s response.
The whole “what vs. how” debate is a little silly. Most of us do what Tony calls “functional design” everyday.
There is a TV show in Canada on HGTV (I think) that my spouse watches (which means I see it too!) that is called Love It or List It. A couple/family with an existing house that has problems meet with a renovator and a real estate agent and give them a set of requirements (that term is used), and both the renovator and the agent try to meet those requirements. The renovator renovates, and the agent find listings and at the end, the family sees both and is asked “Do you want to Love It (the renovations)? or List it (sell and buy one of the listings)?
This to me is a great example of what Requirements are, and what the solutions could be. One solution involved design (for the renovations) and the other did not.
Now, I am actually not a fan of using analogies when discussing software (beware Dilbert’s Analogy Police!), but this one just says it all for me.
@Laura: I’m glad to hear you share my view on this, specially considering the amount of thought you’ve given to the BA role during the past few years, and creating your online courses!
@David: I would hope that at least in IT projects people don’t wait until the “renovation” is completed to ask the stakeholders if they want to Love It or List It ;-).
Adriana… actually, the house owners get to come in and see what’s happening, complain about it, and get told things like “we found mold, that takes $10k out of the budget to fix, so no second bathroom”… so I am liking this analogy even better
Thanks everyone for your comments so far. I thought this might be a contentious topic, and it’s clear that there are plenty of different opinions.
The main point of my article was really about the roles & responsibilities of a BA.
My view is that as a BA delivering an IT system, I should be responsible and accountable for every *user-visible* aspect of the system I am delivering to my business stakeholders, right down to the finest details.
I might sub-contract some of the finer detailed design out, especially if it’s specialised UX design (I’m no graphic designer). But I would still remain responsible and accountable for all of it.
So I think I am in agreement with Adriana and Laura on that point, but not, perhaps, with David.
But, to answer Adriana’s question, I *have* experienced BAs who don’t have that view of their role. They define their role as capturing “the requirements” and not being responsible for “the design”. In the comments on Adriana’s last article, Michelle Swoboda commented that she is fighting with this very issue in her current role – the tension between the “business analysts” and the “functional analysts”. Only today we were having a discussion on the very same topic within my current organisation – there have been arguments between the “analyst” and the “designer” and who should make the final decision.
And my view is that the tension arises because they are trying to draw a distinction between “requirements” and “design” that doesn’t really exist. Try as you might, I bet you cannot give me a universal definition of where “requirements” end and where “design” starts. As Chris (I think) points out – one man’s WHAT (requirement) is another man’s HOW (design).
It’s the same thing with “business requirements” and “solution requirements” too – where’s the dividing line between the two? You can say “the business requirements are high level and the solution requirements are more detailed”, but I’m not sure that helps.
I much prefer to split things down into three (hierarchical) levels, as put very well by Chris Britton in “IT Architectures and Middleware”:
1) Business process design
2) System functional design (the “user visible” bits of the system)
3) System technical design (the internal workings of the system)
The benefit of this model is that it’s easy to draw a clear distinction about where each one starts and ends. As a BA I am involved in (1), responsible for (2), and not responsible for (3).
David’s Love It or List It example is an interesting one too. As Adriana says, as the homeowner, would you really want to state your “requirements” (design constraints) and then have no involvement in the “design” (next level of detail)? That’s asking for trouble, just like an analyst taking no responsibility for the “design” is asking for trouble.
Finally, although this is not really a debate about terminology, I think Laura is dead right that the terminology confuses people. As I mention in the article, my view is that as soon as you start talking about how you want to change your business, you are already in “solution” space – either designing a business process or designing a system – they are all just different levels of design.
It’s *all* design.
Well, there is an old Asian saying that goes “The beginning of all wisdom is to call things by their right names.” i.e the debate really *is* about terminology, ” a rose by any other name is still a rose”. About the first thing I start to create in requirements discovery is a glossary, agreement on terminology is crucial to communication in any human activity.
I believe that this will end with people agreeing to disagree, which is all we can do short of submitting the debate to a Standards Body… but I still don’t see the value, and lots of opportunity for problems to arise. I always say “if it’s working for you, fine, go for it”, but this a path I can’t follow.
Kudo’s to Tony for bringing this issue for discussion.
A WHAT cannot be a HOW within the BA / IT domain.
It may be within the user / business domain.
However, we should insulate the user community from all such distinctions, because if we cannot agree on certain principles, imagine how confusing it would be to drag a user into the discussion. So, we accept their WHAT’s, HOW’s and WHAT IF’s… just suck it all in using their everyday language.
Then, within the BA / IT domain, do the differentiation. WHAT is required is not the same as HOW that requirement is going to be fulfilled – a terminology issue within the BA / IT community.
I am with you on that, so long as you’re consistent with what is a WHAT and what is a HOW.
So if a WHAT is always a statement of *user-visible* system behaviour and a HOW is always a statement of internal (technical) implementation of the behaviour, then that’s fine with me.
But I’ve seen examples where the HOW is also a user-visible behaviour, just at a more detailed level.
For example, I don’t like:
WHAT I need is a way to select the user’s gender
HOW I will do this is using a drop-down
Because the HOW is really just another level of detail on the user-visible design.
What I prefer is:
WHAT I need is a way to select the user’s gender.
WHAT this will be is a drop-down selection with “”, “Male” and “Female” as the options, in that order, and with “” as the default, and the validation is they must select “Male” or “Female”.
HOW I will do this is using the HTML tag, with the values populated from a database table called… and so on.
As a BA I am responsible for all the WHATs but none of the HOWs.
I could not agree more strongly with Tony.
The idea of distinguishing between WHATs and HOWs is a powerful and very useful one. In my opinion it is also a harmful one when people don’t realise it’s a gross simplification that simply cannot fully reflect reality. Every HOW is also a WHAT. Every WHAT is also a HOW.
The analysis and design process is inherently cyclical, whether people acknowledge it or not. We cannot fully understand a problem until we have designed a solution for it. The solution is part of the design problem.
A business analyst can’t achieve anything very useful simply by “analysing”, i.e dissecting and labelling things that already exist. They must also synthesize. Synthesis is a synonym for design. Requirements are not just “out there” waiting to be picked off the tree and analysed. By the very nature of human activity systems, the agreeing and developing of requirements has to be an interactive and unending process.
This is exactly what the traditional “software development lifecycle”, aka waterfall, fails to recognise, which is why agile methods have become so popular despite their flaws.
Any team that is set up on the basis of some people dealing with WHATs and some people doing HOWs, or any process that is set up on that basis, is in danger of wasting a lot of energy and ending up with a suboptimal product. I would suggest that this is exactly the difference between Tony’s “requirements analyst” and “functional designer” approaches.
“Try as you might, I bet you cannot give me a universal definition of where “requirements” end and where “design” starts.”
I think we are all in agreement on this. Similar to the “what” vs. “how” — plenty of good authors have made it clear that “someone’s ‘what’ is someone else’s ‘how'”.
I also noticed that we probably are using different mental models as we discuss this topic here.
When you say, “But, to answer Adriana’s question, I *have* experienced BAs who don’t have that view of their role. They define their role as capturing “the requirements” and not being responsible for “the design”. ”
Sure, I know lots of BAs in the situation you describe, but that’s not what I was talking about. See, to me, the BA capturing the requirements, is defining the *solution* (not designing it, but defining it in the sense of documenting a future state = solution, without going beyond the requirements and designing said solution).
In other words, when a BA documents a capability (requirement), to me he/she is defining the solution (not the problem), and this is why I don’t agree with this statement:
“As a requirements analyst, I am unsure when I am finished because I am supposed to be defining the problem, not the solution. ”
It looks like we’re violently agreeing with one another Adriana
Probably we have having a terminology debate here, but I still want to press a point with you, as follows. When you say that you are defining the solution, not designing it – when you are sitting with your stakeholders, collaboratively agreeing what functions the system requires, you are (in my opinion) engaged in a design activity. Not technical system design, for sure, but you are (at some level) designing the solution to a business problem – the “what” for another man’s “how” – and some of that is functional system design. So maybe the business problem is “I want to sell our widgets on the web” and your solution is a e-commerce website with search, browse and checkout functions. The fact that you selected to include those functions is a design for a solution to the problem of how to sell widgets on the web. And even “I want to sell our widgets on the web” is a solution to the problem “I want to sell more of our widgets, how can I do that?”. My view is that any level of solutionising involves some element of design, be it system technical design, system functional design or business process design.
In terms of mental models, I much prefer the designer mental model because it reminds me that I am actively doing (functional or business process) design. If my mental model is that I am “capturing” the solution, that implies I am not playing an active part in formulating the solution, and then I am merely a scribe.
Hope that makes sense.
@Tony : ” WHAT I need is a way to select the user’s gender ”
Here is a requirement, a WHAT. Let’s think about this for a minute. We need a solution, a HOW to fulfill this requirement. Hmmm !
Now, the user may present a solution – a drop down box.
They may call it a WHAT (e.g. WHAT I NEED is a drop down box ).
Is this the best solution ? Let’s say, for the sake of argument, that it’s a fast-paced environment where data entry is being done rushed and someone enters ‘ ANTHONY ‘ on to the system and quickly drops down the gender box and mistakenly selects FEMALE. Problem.
What I’m suggesting is that you take a WHAT and come up with some HOW’s to satisfy that, e.g.
1. Drop down box
2. If a salutation field is required, such as MR, MS etc, then have the system use that to populate the gender field
3. If you have a database of first names or an app, then a name ANTHONY will populate the gender field as MALE, ADRIANA as FEMALE etc
This is why I say you separate the requirement (WHAT) from the solution(HOW). For every requirement, there is more than one solution that can be listed and from which, one is selected.
Now, many users suggest solutions and there’s nothing wrong with that, in fact anyone can suggest solutions – these are not to be discouraged.
But the minute you merge the WHAT and the HOW, then you’re possibly missing out on some better solutions.
I do agree with you Bennett. But the point is that the WHAT in this case “the need to capture gender” is also the HOW of another man’s WHAT (e.g. “I need the system to only prescribe maternity drugs to women”). If every WHAT is also a HOW then…it’s all HOW i.e. it’s all design, at one level or another.
Nice article, Tony. This is a discussion that never seems to end.
You are right, that depending on your role, and depending on the maturity of the project, the WHAT and the HOW change meaning.
But should you really hide the HOW when you’re figuring out the WHAT?
I was just working on a project where we went back and forth between a few HOWs to solve the problem..it turned out the WHAT was willing to change in favor of a HOW that gave some additional benefits; some lesser priority WHATs were agreed to be removed.
I suggest that, as a BA, you understand as much of all WHATs and HOWs of the system as you can. Don’t throw your requirements over the wall. Collaborate, collaborate, collaborate. A set of requirements or design elements is not a substitute for communication.
I have always learned from some wise people : all things are negotiable except requirements, they are uhh… required. With all things I mean : business principles, design principles, setting project boundaries, budget etc. etc. etc. If you would follow this route of logic : requirements do not equal design. Or at least : design does not equal requirements…. Some people would /try to put their principles above requirements though. And this is not strictly reserved to the BA domain, we are getting in the politics arena here, wars have started about these things…. Interesting stuff…..
From the BABOK:
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.”
(Laura — no wonder you say you’ve always been part of defining the solution
Tony, what an insightful and valuable post!
Too often the IS team rushes to design the solution before the requirements have even been written. They already have the way they want to go in their minds.
Currently I am working on a new project and the title of the project is misleading because this relays to the busines that we have already chosen one of Oracle’s solutions. We really need to rename to project – this is the fourth run at it.
If we do our job as BAs, then the other roles that we play that follow, should allow the process to work and the business to get most of what they ask for. If we could just hold IS back for a bit – understanding of course that they have their best intentions in place.
@Tony: LOL, it does look like we’re violently agreeing with one another :-).
Yes, I think there is a difference in terminology. I’m an electrical engineer, and when you say “collaboratively agreeing what functions the system requires, you are (in my opinion) engaged in a design activity”, that doesn’t align with the models of problem domain / solution domain I’m used to.
But now that I understand your viewpoint, in which solution = design, it’s easier for me to interpret what you are saying, so thanks for clarifying :-).
Question – is there only one How for a What?
There could be multiple HOWs for a WHAT. As BAs, we need to give multiple HOWs, or solutions, for each WHAT. The Business Process owner should also do the same for their business processes, and the developer/architect should do the the same for their system design.
If you look at the 3 level of deliverables that Tony mentioned above:
1) Business process design
2) System functional design (the “user visible” bits of the system)
3) System technical design (the internal workings of the system)
In #1, the business problem is the WHAT, there should be multiple business processes tho choose from as the HOW to solve those problems. One business process design is the output as the decided HOW, and that is the Business Process Design.
In #2, based on the business process design (the new WHAT), there could multiple system function solutions (the new HOW). As BAs, we are responsible for getting agreement on the right HOW for the system function design.
In #3, based on the system function design (the new WHAT), there could be multiple system technical solutions.
Determining the HOW is really an engineering/problem solving process. Lay out possible solutions, including pro/cons, then make the best decision for the users, system, time, cost, business benefit, ability to enhance in the future, etc. This is not always done on paper, but it needs to be done so that the best solution is selected at each level.
Thanks, Nick.. it was a bit of a leading question.
Think of a “what” that has been around for a long time, like Withdraw Money from my Bank Account.
When I wore a younger man’s clothes, I had to go to the bank on my lunch hour, and line up to get cash from a teller. Obviously, there a few more ways (“hows”) to do it now.
This is a “what” that has existed for centuries, and I feel confident will continue to exist for many more. However, I expect I will soon be able to go to an ATM without a debit card, and get cash using voice and or retinal recognition.
I would further suggest that the basic business process is the same in all cases, the answer to the question “what needs to be done? Customer has to be allowed to withdraw money”. Process is:
– Customer asks Bank for an amount of money to be taken from Customer’s Bank Account
– Bank checks if Bank Account has enough money in it
– Happy Path – Bank Account has enough money, so Bank gives Customer the money they asked for (no more, no less)
– Alternate Path – Bank Account does not have enough money, so Bank tells Customer “Sorry, not enough money in your Account to give you the amount you asked for”
That’s the business process, no difference in the past, current, or future. Obviously this was done for a long time with no computer system (remember you bank books, old people like me?).
So, that is, always has been, and always will be the one and only “what”. Please don’t tell me that is design, and I believe it is confusing and a disservice to others if you say that is design.
After that, call anything you do “Fred” if you want, but I suspect you might be concerned if someone comes along and says “Design? there is no Design, it’s all programming..”
@David, In your example, the Business Process is a *design* of the business problem. You just solved the WHAT of “As a Bank Account Holder, I need to take money out of my account so that I can have my money in the form of cash.” It may be a simple design/solution, but there are alternate HOWs.
Another business process design could be:
– Customer asks Bank for money (same as your first step.
– Bank gives money requested (what? money without verifying? it’s still a HOW. As a matter of fact, it’s still how checks work.)
– Banks verifies that there is enough money in the account.
– Alternate Path, Bank finds that there is not enough money in the account. Bank charges customer $25. Bank demands money back from customer.
It’s not a very good solution, but it’s still another HOW.
So it still is all about *design*.
Well Nick, you are nothing if not persistent…
It’s not the same. My example is actually the bank’s process, while yours is the customer’s process. But a typical bank customer does not have a process and their own system for doing banking (excluding B2B and other unique cases), so their perspective is moot. And of course the step to verify the availability of money during a withdrawal is not in the customer’s perspective. Do you always make sure there is enough money in your account when you make a withdrawal at the atm.? What if the bank always gave you the money, and then charged you the $25 later without warning? That’s a “what” I would be complaining about… or be off to Rio with a few million before anyone noticed.
A ‘check or ‘cheque’ (in the great white north) is a different process, a different “what”. It exists for a customer to give money to others, using it to give yourself money is a variation on that process. But it doesn’t matter who gets the money, because as you say, when a bank receives the check, it again verifies that the amount is equal or less than what is in the account. The ramifications of not having the money are much greater in this case (not just a terse message). The check bounces , in Canada you get charged that fee, but I believe in the USA that you could be charged with a felony. (Unless of course you are also paying your bank for an over-draft protection service).
Two different “whats”. I think if I tried to tell a banking business client of mine that they are two designs of the same thing, they would at least laugh me out of the room, if not send me packing.
Again, you yourself can think about this any way you want in your own mental model or process. But saying others should see it the same way when it contradicts the prevailing language and practice is just a cause for un-needed confusion, especially for our business clients. IT still has such a crappy reputation with the business that looking confused isn’t going to help.
Hey, it’s great to have a strong belief but not to the point of delusion. I myself have the strong belief that the job title “Business Analyst” is about the worst one we could have come up with as an industry, but that’s what it is, so I got used to it.
However, if in five years or so, we actually are all saying it is all *design*, I will gladly concur, even buy you a drink or something… but then we may be saying it is all *implementation* … cheers for now.
@David Wright I seem to have touched a sore button.
My example was a business process. There was no mention of systems, just 3 actors, the bank, the customer, and the bank account.
But in your response, I see you are bringing in more requirements and more of the WHAT I need to implement in the business process.
I would hope the banking business client would applaud you for giving such thought to the business process that you would come up with more than 1 solution. Yes, there is a BEST solution, but the customer should know that there are other solutions. If it were up to me, I would give the customer each solution, tell them the pros/cons of each, and ask them to choose between those solutions. Always make sure to recommend one solution.
Perhaps IT is considered crappy because the don’t communicate what they do well with the customer. Besides an un-trusting relationship, The worse relationship you can have is a silent one.
Understand all the WHATs by interviewing the proper stakeholders, come back with a few HOWs, recommend a solution, and let the customer choose the best one for them.
“How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn’t make it a leg. ” …
David, on just the note of terminology, I think Tony’s definition of design is taking hold in circles outside BA or specifically IT. User Experience (UX), for example, captures the essence of their work as design, even though as BAs we’d consider much of it to be business requirements (even before solution requirements!). We have Patrick Quattlebaum’s interview here as an example of what’s happening outside of our profession, in which he calls this “big D Design”: http://www.bridging-the-gap.com/what-a-ba-should-know-about-the-ux-profession-interview-with-patrick-quattlebaum/
Laura, yes, ‘Design’ is a wide-ranging concept, and I do not presume to offer any similarly wide-ranging opinion on fields outside my experience. I am just still not sold on the applying those disciplines to what we do in IS/IT.
I know my posts so far can make me look like old man waving his cane, decrying the new ideas of young upstarts. It is just as a Requirements Consultant ( no conflict there! ), I see the value of a clear Requirements approach for all my clients, that getting business people to really focus on What before How raises their success rate… It reminds me of when Scott Ambler said BAs better learn to code because Business Analysis was becoming extinct. Just gets me going, I guess…
David, I and agree on the value of a clear requirements approach. Any time I get involved in a project that doesn’t use this approach, things don’t go very well, so I’m sticking to the “old school” until I see something that works better :-).
My next article (being published on Aug. 10) will touch this subject again, and I look forward seeing your comments there as well (as well as Tony’s and everyone else in this thread).
I think Tony’s main point was accountability.
Be accountable for your decisions/solutions/designs/requirements…whatever you want to call them.
Be accountable, take responsibility, and own your deliverables.
Thanks again for all your comments. I’ve been sitting back, watching them all and letting you all have your say. It’s clear that there are several different views out there, both on terminology and also in terms of “mental models” of the requirements/design process.
What’s also clear is that the terminology does get in the way of the underlying debate on roles & responsibilities – some of us have been violently agreeing with one another because we use different terminology for the same things.
I’m glad I’ve found at least a few people who agree with my own mental model, I would hate to have been ostracized from the BA community after such a short blogging career
And I’m completely with everyone who says you need to understand the “WHAT” before you present a number of options for “HOW” from which you can collaboratively agree which one is best with your business stakeholder and engineering team.
But I like to keep in mind that my stakeholder’s “WHAT” is also usually the “HOW” for some higher “WHAT” – and I always like to go back to the root business problem via a series of “WHYs”.
I sometimes think that children would make good BAs because of their habit of constantly questioning everything, as in:
Child: “Daaaad… Why do I have to go to school?”
Me: “Because you need to learn stuff.”
Child: “But why do I need to learn stuff?”
Me: “Because you need to be clever.”
Child: “But why do I need to be clever?”
Me: “So you can get a job when you’re older.”
Child: “But why will I need a job?”
Me: “To earn some money.”
Child: “Buy why do I need money?”
Me: “To buy food so you won’t die of starvation.”
Child: “Hmm. Now I understand. But I think I have a better solution to the underlying business problem here. If you continue to buy me food for the rest of your life, and then leave me all your money when you die, then I should be good for food pretty much for all time. On which basis, I think I can afford to have the day off school, don’t you?”
Hi Adriana –
I agree with you.
How is What is How is What – it is a continuum. I wrote a paper on this very topic in 2009 to help my client at that time understand this issue a bit more.
This is available at http://www.writingusecases.com/wordpress/index.php/archive/tips-for-bas-new-paper-what-are-requirements/
What is important is your agreement with your stakeholders. I have worked with many, many companies throughout the world on software project development (IT and otherwise). Where the rubber meets the road, the important thing is to be clear with my stakeholders what needs to be done and who will do it, rather than what is it called.
Requirements is one of those slippery things that means different things to different people, so clarifying it is important to avoid basing a project (or a contractual obligation) on unstated assumptions.
See my paper as an example of something you might create for your stakeholders to clarify this particular issue: http://www.writingusecases.com/wordpress/index.php/archive/tips-for-bas-new-paper-what-are-requirements/
Geri Schneider Winters
Great discussions. The separation between capturing requirements and designing sometimes does feel forced and awkward. I believe this is why proponents of Agile focus on Business Analysis competencies and not a formal role. The value delivered to the client can be much greater if you have one person that is able to perform business analysis and design and testing and coding.
My understanding if that the current BABOK does not have competencies related to design skills. This may be one area that may need to be reviewed to see if some competencies should be added if this is a situation Business Analysts typically are doing and everyone agrees this provides the most value.
I know for me, the maximum value I get from Business Analysts is when they design solutions (both business and technical) and are not just capturing what the client has said.
OK, I had dropped out of this conversation, but:
” the maximum value I get from Business Analysts is when they …. are not just capturing what the client has said.”
If that is what you think is all that is necessary to discover complete and correct requirements, then I would not want to be your client, I suspect they may getting nice solutions that don’t do what the client actually needs. (Rational is putting out stats today about how much re-work is necessary in s/w efforts, it was 50% or more…. betcha I know the reason.)
I don’t really care about the job title, and if anyone can do it all, power to them, but that does not mean any part of it “all” is any less important.
OK, I am gone again…
Thanks David, I think some of the context of my statement may have been lost with the ‘…’
The statement was:
“the maximum value I get from Business Analysts is when they design solutions (both business and technical) and are not just capturing what the client has said.”
My current company believes that relationship between design and requirements are so integral that we do not usually have ‘pure’ Business Analysts. Rather we have Application Architects that capture the requirements, help to design the business process and application, and we deliver working code in two weeks iterations as working code is really the only way to ultimately confirm requirements. I would hazard a guess that the projects with a lot of rework are projects that haven’t been delivered iteratively.
But I have heard previous BA’s mention that they just write down what the client has told them about their needs and requirements. The comment was intended to show that I believe BA’s have much more to offer than that. I believe that BA’s need to perform design to deliver complete and accurate Requirements.
I also believe that using documents as the sole and primary way to confirm understanding of client needs and requirements is sub-optimal.
Just found out this interesting post (http://searchsoftwarequality.techtarget.com/news/1515961/Are-visualizations-the-answer-to-gathering-requirements) that “confirms” the ideas that were raised in this impressive conversation
“I believe that BA’s need to perform design to deliver complete and accurate Requirements”… surprise, I don’t. And it is not some fixed dogma, it’s just that I do it all the time for my clients, who keep asking me back to do it again.
And the process I use is not to just write down what the client says, there is no value added to that, they could do it themselves. So I just wanted to emphasize that doing so is not effective requirements discovery, and anyone who says that is what they do is indeed just a stenographer (not to belittle Stenographers! they should get these gigs!)
Now, I am not going to say your process is wrong, no way. I always say if something is working for you, power to you. I like the job title of Application Architect you use, I think it concisely communicates what those people do.
So for me, the idea of “business analyst just writes down what client says and that is the requirements” is just omething I have to rail about whenever I see it. (Others be warned!)
Thanks for referencing my interview with Laura in your post. Identifying and synthesizing business objectives, goals, and requirements with user needs and behaviors AND with bits and bytes, zeroes and ones is all design.
It takes many disciplines to create the possibility for valuable and desirable (and human) experiences through technical solutions. The best development processes are not development processes; they are design processes in which a product or service is created and evolved to create sustainable value for all stakeholders. Every step along the way is a design decision, whether it be technical design, business process design, UI design, content design… and then iteratively improving it as the abstract becomes tangible.
I do encourage BAs to embrace partnering with other disciplines, especially user experience professionals trained in psychology, human computer interaction, information design, etc. And I do encourage the BA community to make their requirements session more interactive, to visualize requirements early and often, and to embrace an iterative design process in which requirements are informed and evolve based on putting concepts and prototypes in front end users early in the process.
But I digress… great post and keep up the good fight
Did not read all the later posts, so perhaps this was already stated, but it’s a matter of perspective…
All perspectives: WHAT is the problem
Business perspective: HOW to solve the problem
BA perspective: WHAT is the solution
BA perspective: HOW to define the solution
System Architect perspective: WHAT is the approach of the solution
System Architect perspective: HOW to define the approach
Developer perspective: WHAT are the details of the approach
Developer perspective: HOW to codify the approach
So, I agree with Tony.
“Try as you might, I bet you cannot give me a universal definition of where “requirements” end and where “design” starts.”
What’s the bet? There is a way. It’s related to something else you said: “…they are trying to draw a distinction between “requirements” and “design” that doesn’t really exist.”
This entire debate is directly related to the Paradox of Value (http://en.wikipedia.org/wiki/Paradox_of_value) for several reasons. From Wikipedia, “The paradox of value (also known as the diamond–water paradox) is the apparent contradiction that, although water is on the whole more useful, in terms of survival, than diamonds, diamonds command a higher price in the market.”
First, requirements and designs are both ways of representing potential value, so problems with defining what value is are automatically problems with designs and requirements. Specifically, both are ways to improve understanding of the potential value of a thing, but
* requirements focus more on the need – the problem, opportunity, or constraint;
* designs focus more on the solution – working toward something that solves the need.
Value can only be realized through a solution: a map isn’t the same as travel, though it can be used to design a trip; a picture of a chair isn’t much good for sitting on.
Second, the problem with the Paradox of Value is the same kind of problem we face with Requirements vs Designs. The problem space is missing at least one necessary element, which means no valid solution can be proposed. We end up spinning our wheels. For an example, take this old riddle:
A father and his son are in a car crash. The father is killed instantly. The son is seriously injured and is taken to the hospital. He is rushed to the operating room. The surgeon comes in, looks at the patient on the operating table, and says, “I can’t operate on this boy. He’s my son.” How can this be?
To solve the problem, you need to increase the size of the problem space – to include female surgeons.
With the Paradox of Value and the debate between Requirements and Designs, the real problem is that the question doesn’t have a valid answer unless we factor in an additional bit of information. In this case the missing information is that the value of a thing lies in is the importance of that thing _to a stakeholder_, _in a context_. Diamonds can certainly be more important than water – for some people, under certain circumstances. For example, during a wedding proposal, a diamond may be much more important than water. During a drought the water may be much more important than a diamond. During a flood, water has a significant – perhaps fatal – negative value.
The Paradox of Value isn’t a paradox at all. To solve it, just add people. (Marginal Utility is a freakishly complex way of trying to do this.)
The universal definition of where “requirements” end and “designs” start is the point at which a stakeholder shifts focus from understanding the need, to focus on understanding the ways that need can be solved. These can happen simultaneously. They can be in sequence, starting with need or starting with solution.
One consequence of this definition is that a single statement can represent one stakeholder’s needs, and another stakeholder’s solution. In other words, one person’s requirements are another person’s designs.
Requirements and designs are very strongly related, but they’re not the same. To understand the difference, just add people.
I have to admit I still prefer to think of the whole process as a series of cascading designs, at increasing levels of detail. This encourages everyone involved to have a “designer” mindset. Here’s another reason I just thought of as to why this might be a good idea.
I am a Level 3 analyst. I have a level 2 requirement X, and I have three alternative level 3 designs: A, B and C. Design C is an absolute peach – loads cheaper to build and with a bunch of additional benefits to boot. But it doesn’t quite meet the requirement X. Because I think of X as a (must-have) requirement, I reject design C.
I am a Level 3 analyst. I have a level 2 *design* X, and I have three alternative level 3 designs: A, B and C. Design C is an absolute peach – loads cheaper to build and with a bunch of additional benefits to boot. It would be viable but only with a small change to the level 2 design X.
Because I consider X to be a “design” (i.e. one possible solution to some higher level problem), and not a fixed-in-concrete requirement, I recognise that there might be some leeway to alter X slightly, and I feel it’s worth pushing for design C.
Now, you could argue this is just a terminology debate, but (as I mention in the article), to me it’s more about the “designer” mindset of the participants in the process.
While proof-read this post before hitting ‘Submit’, I realized that it is pretty intense language. This is written from the perspective of a debate – where the motion before us is “It’s all design.” Tony argues for the motion; I argue against it, and make the counter-claim that design and requirement are the same thing from different points of view. Your position is provocative, interesting, and useful to consider. I have learned from reading, analyzing, and attempting to rebut the arguments.
I have been careful to tackle the topic and not the debater – but wanted to make my motivation and approach crystal clear before we square off behind our lecterns, and let the arguments fly.
Thanks for sparking this debate.
There is a lot to be learned from this argument. It embeds many assumptions or declarations about value, the way stakeholders behave, and the professional responsibilities of competent business analysts. As presented, the argument is vivid, evocative, and familiar – but it is not logically valid. It does not support the proposition “It’s all design.” It does support the argument that incompetent business analysts are bad at their jobs. This has my full support, but it’s a red herring (http://en.wikipedia.org/wiki/Red_herring). These scenarios also imply that requirements are somehow fixed and immutable where designs are flexible and dynamic. This is a false claim that misrepresents the opposing or alternate positions. Many people take the position that requirements and designs are distinct elements, for example. There may be people who argue that requirements are a list of non-negotiable demands, but this is not the way the term is used. (http://en.wikipedia.org/wiki/Straw_man)
The major distinction between Scenario 1 (which I think of as “Requirements Are Bad” or RAB), and Scenario 2 (Design Is Good, or DIG) is that an explicit value has been assigned to the desrequignirements in DIG, but not in RAB. Restating the scenarios with IDs for traceability:
I am a Level 3 analyst. I have a level 2 requirement X (L2-X), and I have three alternative level 3 designs: L3-A, L3-B and L3-C. L3-C is an absolute peach – loads cheaper to build and with a bunch of additional benefits to boot. But it doesn’t quite meet the L2-X. Because I think of L2-X as a (must-have) requirement, I reject design L3-C.
I am a Level 3 analyst. I have a level 2 design X (L2-X), and I have three alternative level 3 designs: L3-A, L3-B and L3-C. L3-C is an absolute peach – loads cheaper to build and with a bunch of additional benefits to boot. It would be viable but only with a small change to the L2-X. Because I consider L2-X to be a “design” (i.e. one possible solution to some higher level problem), and not a fixed-in-concrete requirement, I recognise that there might be some leeway to alter L2-X slightly, and I feel it’s worth pushing for L3-C.
So what is the priority of the desreq L2-X? Is it necessary or not?
If L2-X is necessary, the entire change has no value without this element, and should be scrapped immediately if this component is not possible. (It may not be sufficient.) If L2-X has minor value, the change loses some value without this element, but is still worthwhile.
In other words, the scenarios don’t really say anything about the validity of the words ‘requirement’ and ‘design’, but they do question the competence of the BA. If L2-X is necessary, the RAB BA is competent and the DIG BA is incompetent. If L2-X is not necessary, the RAB BA is incompetent, and the DIG BA is competent. For example:
L2-X: Keep astronauts alive while in low earth orbit for at least 5 days.
L3-C: The spacecraft does have an air supply or air scrubber.
While it’s a lot cheaper to run spacecraft without air – that’s why we have unmanned spacecraft, such as satellites and the Curiosity rover on Mars, L3C can not meet the L2X desreq. Our BA is performing his or her professional duty to reject it.
If L2-X is not Necessary, L2-X and L3-C are both options that our BA should consider. The BA should analyze the implications of not fulfilling L2-X, and the pros and cons of L3-A, L3-B, and L3-C. The BA should also facilitate the decision to fulfil or not fulfil L2-X. For example:
L2-X: Keep healthy while in low earth orbit for at least 5 days.
L3-C: The spacecraft does not have the ability to spin to produce the appearance of gravity.
The task of assigning value to desreqs is usually called prioritization. Many business analysts (and other change agents) do this quite poorly. Often this is not their fault; most prioritization techniques are inadequate to the task. They are:
a) applied at the wrong level of detail,
b) a conflation of value assignment, build options, and feasibility assessment,
d) overly complex,
e) any or all of the above.
Combine this with the fact that humans are terrible at making this kind of decision and we end up with a set of common practices that are ineffective at best and destructive at worst. (Check out Thinking Fast and Slow for a great introduction to the many deficits of human thought, and our blindness to those deficits.)
In conclusion, I can certainly see scenarios where it is expedient to pick a term and stick with it – but this does not mean that there is any particular benefit to using ‘design’ over using ‘requirement’.
Julian, your comment deserves its own blog post! I’m offering to host it at my WordPress installation, where lots of people will get to see it via RSS feed, email subscription, Twitter following, or shot out from LinkedIn group owners. Never had a guest post before but you can be the exception ;-).
Tony, I feel like with your example you are now making a case for using the word “requirement”:
“Because I think of X as a (must-have) requirement, I reject design C.”
“Because I consider X to be a “design” (i.e. one possible solution to some higher level problem), and not a fixed-in-concrete requirement, I recognise that there might be some leeway to alter X slightly, and I feel it’s worth pushing for design C.”
You just described why I feel the division between requirement and design is so important in my projects. By not allowing that any “possible solution” is included in my functional spec requirement, only “must-haves”, I make it easier for future decisions to be made and different designs to be considered and proposed.
If I called everything “design”, then things would get more confusing for the solution team. Is this “design” a must have, or just one of the possibilities? Much more complicated to tell without using words to differentiate the two.
Thanks, Adriana. I’ll be posting versions of these (and other work) to the IIBA BABOK Guide blog (http://community.iiba.org/BABOK3) in the next few weeks. I’d be happy to guest-post for you, too. You can drop me an email (julian dot sammy at IIBA.org) and we can chat.
Great comment Julian – a very well-stated argument. You’re right, my “extra reason” doesn’t hold water under your analysis – really it’s about how well the “requirements” are prioritised and how good the level 3 analyst (who might be a BA or maybe a tech designer) is at their job.
And sadly I have clouded my own issue too. My main article was supposed to be focussed on the BA as the writer/creator of “requirements”, not the receiver of them!
What I am challenging/fighting is the mindset of “I’m a BA, all I do is *capture* the requirements”. Or perhaps, from the “designer”: “You’re a BA, just capture the requirements and I’ll do the design”.
As has been said many times, requirements aren’t just out there to be captured.
Pingback: Requirement is what we have to do to achieve an objective « Business Analysis Resources
Tony, I’m linking to this article from my new one:
“Tony Heap would like to do away with the term “requirements” and use the word “design” instead. I don’t see a problem with this approach, as long as you make sure everybody is on the same page with your terminology, and you are not making the mistake of skipping the conversation about ‘what needs to be done’ to jump too early into assumptions about ‘how’ the application will work.”
Pingback: My definition of requirements, now with comments from Karl Wiegers « Business Analysis & Product Management
For anyone that’s interested, I have written a follow-up article: There’s No Such Thing as a Requirement.
Thanks for your comment about my recent BA Times article ‘We are all designers now‘, and the link through to your site.
It’s great to find someone with a like mind. As you might guess, I agree wholeheartedly that there is a continuum from requirements through design to solution and out the other end to benefits realised. I call this the golden thread, and is what traceability is all about.
I think it is fair to make a distinction between a requirement and a design, in the same way there is a distinction between analysing something and designing something. The first is more about taking in and thinking, the second is about how we enact the results of that thinking.
Therefore, while we can distinguish between those two concepts or activities, it doesn’t make sense to say that design is not fundamental to the role of a business analysis practitioner.
Pingback: Comparing Software Design with Building Design | its-all-design.com
What does business want? A solution to their problem.
When I gather and document requirements I’m a scribe – not what the business wants (low value add)
When I analyse the requirements I gain insight – not what the business wants (low value add)
When I use the insight I have gained I can propose a solution – what the business wants (high value add)
As a BA I must be able to gather requirements, analyse the requirements to gain insight and then propose a solution to be a value add for the business. To propose the solution I have to do a functional design as Tony says the part the business uses to interact with the system and the information produced to manage the business.
The trick for me as a BA is not to jump to conclusions, i.e. stay in the “what” mode long enough to gain the insight required to go into functional design mode, the conceptual “how” mode. That said while in the “what” mode because of past experience in the “how” mode I know to ask certain “what” questions because I’m going to need the answers in the “how” mode.
So I agree you have to keep the “what” and “how” separated but you are only as valuable in how well you combine the two into the solution required to solve the business problem. Of course in most cases there is a hoop or gate between the two – business approval. Business must ensure that you understand the problem before allowing you to continue to the “how”. In the same way there is a gate between functional design and implementation design.
Hello and thank you all for the interesting conversation,
I try to offer slightly different perspective: I do plastic products, mechanical design and engineering. Some product design organizations work exactly like described above: somebody makes a list of requirements (WHAT) and somebody else tries to figure out HOW to do that in reality. To my experience a new version of an existing product can be made following this method, but it does not very often lead to anything new since the specification limits the possibilities so efficiently.
I prefer a method where we start from the EXPECTATIONS of the customer/end-user. We might not know them exactly and they can’t really tell us either. We just need to figure those out. So we make a good guess and do a very quick and cheap physical model to work as a helping tool in the conversation. Based on feedback we dump the whole idea, part of it or modify it forward… keeping the laws of physics and manufacturing technology in mind. Very often new solutions accidently appear through practical working. After some (usually many) iterative cycles, we end up with a prototype that kind of includes both WHAT and HOW.
I hope somebody got something out of this.
I’m going to stick my neck out here and support Tony by saying that in the IT industry far to much emphasis is put on requirements at the expense of design (analysis vs synthesis). In the ISEB book on business analysis (UK), there are plenty of chapters on requirements but scant mention of the design process that leads to an outcome that the customer wants. Design seems to be a piecemeal and ad-hoc activity that is almost peripheral to delivery. Without having an effective design process I find it hard to see how a successful delivery can be anything other than luck. I would willingly (and have done) trade a BA for a creative and innovative individual who can lead a design process which includes enough needs work to support the design of something truly useful.