Comments on: Requirements As the Main Focus of Business Analyst Work

By: 2wtx Mastering Business Analysis » Blog Archive » Beyond “requirements elicitation”

Wed, 02 Dec 2009 15:43:53 +0000

[…] her last article for Bridging the Gap, Adriana Beal explained why she don’t see any benefit in moving beyond the […]

By: Nathan Caswell

Nathan Caswell — Fri, 20 Nov 2009 18:27:58 +0000

The point of bringing up the imperative definitions wasn’t to debate them per say, but to point out that many people take imperative statements as the definition of ‘requirement’ rather than the broader IIBA one.

That said, disagree with your casual approach. Also disagree with the assertion that the average IEEE member will pick one at random. The origin of the crisp definitions is a long history of confusion, particularly around the term ‘will’. The standard says, “lets pick some words, agree on a common definition, and be done with it”. It is the BA responsibility to understand the imperatives, elicit the appropriate one from the business and explain to the developers (who really should understand them as well. It a BA can’t understand 8 terms, the basic sub set of “shall, may, shall not” works pretty well.

By: Adriana Beal

Adriana Beal — Fri, 20 Nov 2009 17:26:12 +0000

Steve, I agree that opting for simplicity and focusing on “solving business problems” as the key responsibility of business analysts are very good references to keep in mind when discussing the BA role.

By the way, I hate to find the words “may” or “should” in requirement statements, and never use them!

Thank you for continuing to contribute to the discussion.

By: steve blais

steve blais — Fri, 20 Nov 2009 14:49:32 +0000

And on topic –
lists of duties and responsibilities and activities of the business analyst go on forever. My list, taken from the mouths of business analysts and from dozens of corporate and other organizational documents such as Business Analyst Guidelines, How to be a Business Analyst at —, The Business Analyst Guidebook for —, and so forth, extends now to eight pages, and it is just a list with no explanations. That’s about 300 activities business analysts perform as part of their every day jobs at various companies. This runs the gamut from “scheduling meetings for executives” to “writing acceptance test scenarios for users to run” to “preparing UML documents” to “preparing RFPS (requests for proposals)” to “contribute to enterprise architecture” to “Make sense out of chaos”.
What it all comes down to is one and only one real task and responsibility: solve the business problem. All the tasks and activities are subordinate to that. And, if the task the business analyst is assigned cannot be linked to the eventual solution of a business problem, then one of two factors exist: the business analyst is not doing their real job, or she isn’t a business analyst. No, only kidding about the last. The point is to keep it simple. The more focus you as a business analyst have on solving business problems, the more success you will have doing so, and the more value you will have to your organization.

By: steve blais

steve blais — Fri, 20 Nov 2009 14:37:55 +0000

This probably should be a separate track, but I’m not sure how to do that, so…
Nathan got into the ISO and IEEE definitions of the “imperatives” (as IEEE calls them – I think the reference is 809, while the BABOK mentions them in 1.6, page 204).
While there is value in clarifying, at least for the record, the differences between the various imperatives, I question the value of actually using the different options. Considering that ambiguity is one of the major contributors to misunderstood and misapplied requirements, employing multiple ways of expressing an imperative, even in an effort to reduce ambiguity, only exacerbates the problem. IEEE defines eight different imperatives. I suggest you ignore the options. Why? Because it is unlikely either the business stakeholders who approve the requirements or the solution team who craft the software will understand the fine differences in meaning behind each imperative, nor are they likely to have a copy of the IEEE, ISO, or BABOK standard beside them as they review the requirements. With eight possibilities there is an 87.5% chance that the author will pick the wrong imperative, and an equal chance that either of the reviewers of the requirements will interpret the imperative incorrectly. The odds are too great for mistakes.
Of course one could always put the IEEE or ISO definitions of the imperatives into the requirements document glossary, but I wonder how may of the readers of this blog would consult a glossary upon encountering the word ‘may’ or ‘shall’ just to be sure you understand the right meaning?
I opt for simplicity. Pick one imperative and stick with it. Choose “will”, “shall”, “must” or write the requirements with present tense action verbs, and use the same imperative for all requirements. Avoid the use of verbs of volition such as “may” or “should” because of the inherent ambiguity built into the verb.