One of my co-authors here on Bridging the Gap recently wrote an article titled Design and requirements? Pshaw!, discussing 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.
Requirements versus design - whose side are you on?
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.
|
By Tony Heap. Tony Heap is a freelance Business Analyst and Solution Architect based in the UK. Having worked on a variety of projects in both roles, he feels like he has a few experiences to share. He is particularly interested in agile approaches and how they apply to business analysis. View more blog posts by Tony Heap |
Related posts:
{ 53 comments… read them below or add one }
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.
Hi Bennett,
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’”.
Tony:
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 term so 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:
“Requirement:
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.
To all,
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..”
@Doug “Design? there is no Design, it’s all programming..”
Unless and until implementation takes place, nothing else matters.
It’s all implementation, I say
@Bennett Be careful. Implementation without design leads to bad solutions.
Here’s a funny example: http://www.businesspundit.com/wp-content/uploads/2009/05/howdoesthiswork.jpg
@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*.
Bennett, Aye, and then its all maintenance…
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. ” …
Abraham Lincoln
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.
Hi Everyone,
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?”
You see Tony, the fact that you generated so much discussion with your blog, ensures that you selected a worthwhile exercise.
The reason why ‘ its all design ‘ is not readily acceptable, is because there are other facets of the project team that will react to ensure the significance of their roles :
It’s all Cost Benefits – ensure that the right problem/project is being worked on
It’s all Requirements – ensure that all requirements are captured
It’s all Design – ensure that the best design is chosen
It’s all Programming – actual build from the above consumables
It’s all Testing – make sure what you build works
It’s all Implementation – unless you execute, none of the above matter
On the topic of kidding, here’s mine :
Kid : Daady, where do doctor’s go when they get sick ?
Dad : (after finding out) They go to another doctor
Kid : And where does that doctor go when he gets sick ?
Dad : They just go to another doctor, like I said.
Kid : And where does that doctor go when he gets sick ?
Dad : (firmly, hoping to end the conversation loop) They JUST GO TO ANOTHER DOCTOR
Kid : And where does that doctor go when he gets sick ?
Dad : I give up, Sigh
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!)
Tony,
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…
Problem
All perspectives: WHAT is the problem
Business Requirements
Business perspective: HOW to solve the problem
BA perspective: WHAT is the solution
Functional Requirements
BA perspective: HOW to define the solution
System Architect perspective: WHAT is the approach of the solution
Detailed Design
System Architect perspective: HOW to define the approach
Developer perspective: WHAT are the details of the approach
Development
Developer perspective: HOW to codify the approach
So, I agree with Tony.
Funny-I proabbly take on TOO much responsibility for whats delievered. I have ran into two siutaions
1. Current software is not documented but proceeding with new functionality I did not have enough information to really understand how it currently worked so the new implementation (signed off by business) fixed one problem and broke other problems it unraveled before my eyes. I felt bad but i was only there a week and did not know enough.
2. Resistance from developers..having me in their meetings, asking questions and challenging in my mind “sloppy” design and “Lazy” database modeling.
Hi Kai
Im my view, it’s *very* difficult trying to specify changes to an existing system that you know little about. I’ve been there quite a few times and, like you, I’ve made changes that have broken something else that we weren’t expecting. There are a couple of tricks I use to try to mitigate this risk:
1) Show the proposed changes to as many business and technical stakeholders as possible – including the developers, testers and operational support team. The more people you involve, the more likely you will unearth the “gotchas”.
2) Present your proposed design as visually as possible. If it’s a UI change, build a clickable prototype (e.g. in HTML, or using Axure or similar). The more realistic the prototype, the more engaged your audience and the more likely they will be to spot any issues.
3) Deliver changes in frequent increments (agile-style) – that way you can fix any side-effects in the next increment as “business as usual” rather than as a panic patch-fix.
The dynamic between the BA and the dev team is always an interesting one. I’m from a technical background, so I’m always tempted to stick my nose into the technical design, and I often have to remind myself to butt out!
It’s important to have a clear division of responsibility between the BA and the dev team – I see myself as responsible for anything that is externally visible, and the dev team are responsible for the “internals” (e.g. the physical database design). The dev team will rightly resist you if you try to *dictate* how they should do their bit. What I tend to do is give my opinions, explain my reasons (sometimes it’s just “gut feeling”) but then leave the dev team to make their own decisions. So long as the code is built as per the functional spec (including the non-functional requirements) then they have done their job.
That said, if the dev team is resisting having you in its meetings, that’s not very healthy for the project. When things are working well, the BA and dev team should be working very closely together. Maybe it’s worth trying to get to the bottom of where the resistance is coming from.
Tony-
I am going to work on the “Clickable” prototype. Will this require I have dreamweaver or some other Html tool? How much functionality should this prototype perform. I find that even if i show them the new UI there are things going on behind the scenes that no one will know until they start entering real data.
I think the resistance may come in because i ask too many questions and “why’s”. For example, the last meeting i was in they had 3 tables to store values, none of which were linked to the gui or had a relational link to any other tables. So of course they did not appreciate my challenging their design. So i will take your suggestion and butt out of the “under the hood” topics but its sooo hard being that I was a developer. Also i ask for technical database flow documents etc I get a lot of resistance so even today when QA ask about data states i refer them to the developer because i have no clue and there is nothing documented on the data flow.
Also Tony what is the role of QA/testers in these doscussions. I have invited them to meetings before and they seem to go back and forth on the implementation and to be “holdup” progress. Is it not my job to get the requirements and not to hav them constantly questioned by the testers?