“What’s in a name? That which we call a rose
By any other name would smell as sweet.”– William Shakespeare, Romeo and Juliet
“You say po-tay-toe, I say po-tah-toe……..You say to-may-toe, I say to-mah-toe…..
let’s call the whole thing off!”
– George and Ira Gershwin, Shall We Dance or Quit This Project?
Requirements come in many forms. For concepts slipp’ry ‘twixt our brains
Goals and visions, points of pain. Needs and wants, gaps versus norms
Approaches, scope and upside gains. Costs and plans, assumptions named
A business case, with risks in place. Analysis to gray cells whisked
Away in meetings, don’t explain. Don’t make us think – it’s HARD in rhyme
And only then transitions? — tsk!
Look and feel pushed to design. Test quality at rollout time
And if performance is not so keen? Don’t forget the root cause blame
Change requests, poor user training. So many words, what DO they mean?
– Marcos Ferrer, CBAP
Let’s use the BABOK 2.0 requirements definitions to decide what words mean (yay standards). BABOK recognizes 5 major requirements types:
- Business Requirements
- Stakeholder Requirements
- Solution Requirements Functional
- Solution Requirements Non-Functional (don’t tempt your users to agree here)
Transition Requirements
We’ll take a simple, yet frustrating example. An executive wants to organize all of the workers tasks around how much time it takes to do the task. The idea is to do more tasks by doing the quick ones first (don’t laugh – if you haven’t run into stuff like this you are a lucky BA, but may lack skill from lack of exposure).
What is wrong with this requirement? If your answer is “nothing”, you don’t have to read the rest. If you aren’t sure, keep reading. If you can articulate exactly what is wrong and why, you should be writing this blog.
Let’s break this requirement out into BABOK categories, across ALL the requirements types and levels.
Step one: What is the executive’s “requirement” in BABOK?
First and foremost, it is a “stakeholder” requirement, and requires some kind of analysis (thought) to make it into a “real” requirement. According to BABOK the “requirement” is “stated” and/or confirmed (“You really said that? – OK, got it”)
Step two: What kind of analysis?
We might consider breaking the statement down into more detail – what are the tasks and how long does each one take. This is the naïve analyst (naïve IT analyst) approach, and will lead to a failed implementation if not stopped immediately.
The business analyst approach is to consider the business requirement that is driving the stakeholder “requirement”. SO, what is the business requirement analysis that might help fix the stakeholder “requirement” (save it or build it – you are running out of time.
Maybe the business requirement is a vision: “Let’s do shortest tasks first so we can get more work done.”
NOPE – that doesn’t help – restating the stakeholder requirement as a vision leaves us where we were, and even BABOK says that “visions” are the least likely “requirements” to be ongoing / valid as stated.
Maybe the business requirement is a business need: “We need to do shortest tasks first in order to get more work done.”
ICK – again, restating the stakeholder requirement as a “business need” didn’t move the ball – we are still stuck with organizing tasks in an “overly simple” (to be kind) way OR getting into a fight with a stakeholder.
Maybe the business requirement is a capability gap: “We can’t get enough work done because we are not able to organize shortest tasks first.”
Phooey – this doesn’t help, because even though it is true (we are not able to figure out which tasks are shortest, and hence can’t do them first) it is not clear that filling this gap will result in a winning system.
Maybe the business requirement is a business solution approach, as in “Let’s get more work done by doing shortest tasks first”.
Hmmm… this might be better, if only because it shows that:
- We want to get more work done (or at least the executive does).
- We can use the approach of doing shortest tasks first.
NOW we have some analysis – we broke the stakeholder requirement into TWO parts – a business solution approach and another part. The other part – is it also a requirement?
BABOK offers solution scope business requirements, as in “The business solution shall get more work done.”
Nope – I have seen such requirements, and yet calling them “solution scope” is off.
BABOK offers business case requirements, as in “Organizing tasks to do shortest first will accomplish 10% more tasks in the same amount of time.”
This sounds like what the executive is imagining, but notice that the statement above is NOT a business case and hence is not a business case requirement. The statement is a “justification” statement with no evidence or analytical cost vs. benefit computation. It is, as stated, simply another stakeholder “requirement” – a statement of stakeholder thinking minus any serious attempt to prove feasibility or estimate payback.
To make this into a “business case” requirement would suggest making an actual business case, including feasibility (what are the shortest tasks – what happens if we try them first – what are the longest tasks, and their relation to the short ones?). I for one am in favor, and yet I know that if I insist on a business case it sounds like I am questioning the executive’s thinking, who (theoretically) is responsible for due diligence before writing checks for projects.
Again, NO GOOD, unless:
- We don’t like the executive and want to be mouthy (demand the business case and avoid the executive by getting fired or whatever)
- We intend to build whatever we think without discussing it and hence risking conflict
- We intend to build what the executive seems to have asked for (that’s right – when IT builds what you tell them to build it might mean that “you asked for it” and how words don’t mean what they mean, be trilingual! and what’s more that the IT team figures you deserved “it”.
- You are an IT genius even though you chose to go into “people work” like management, or sales and got B’s (C’s?) in math.
- IT doesn’t like you enough to do what is right even though you won’t listen
- IT knows from experience that if you see any deviation from your exact instructions you will pitch a fit, and they gave up trying years ago., and are prepared to
We are out of business requirements, and surely we don’t want “Let’s do shortest tasks first to get more work done” to be a Solution requirement (functional or “quality” non-functional) or a Transition requirement.
What is the answer? How do you present the stakeholder requirement to “Let’s organize the system around “shortest tasks” first in order to get more work done.” In such a way that it opens discussion instead of shutting down communication and trust with the (very excited at the brilliance of her idea) executive?
Answer in the comments below for a chance to write your own blog in this very space (yes, with editorial help) and have fun, fearless BA readers!
Don’t forget to leave your comments below.
