What Are ’Good’ Business Requirements?
Many of our students have asked us to give them examples of ’good’ business requirements. Some of the braver have even asked for ’bad’ business requirements for comparison. Presumably the bravest by far are those who have presented us with samples of their business requirements and requested an evaluation of the ’quality’ of the requirements. After much hair pulling, brain thrashing, and pouring ashes on our heads, we have decided to approach this topic head-on (don’t even get me started with that ad!). Since the topic is, however rather humungous (i.e., too big to consider in a single post), we have decided to break it down.
Just to give y’all an idea of the magnitude of this undertaking, consider that we have identified 18 different categories and subcategories of business requirements and an equivalent number for technical specifications. Ergo, our plan is to give you a couple of high-level recommendations in this initial article on the topic and then follow it up with an article each issue or so. (All right, so that’s a CYA — as in Cover Your Anatomy — statement, OK? It means that we are going to address this august issue in a series of articles starting right about now and continuing now and then until we are done and not one issue earlier.)
’Good‘, Albeit Young and Immature Requirements
First off, we need to point out that the ’goodness’ of a business requirement depends on where it is in its evolution. For convenience’s sake, we divide the requirements determination process into three major stages, ’Capturing’, ’Clarifying’, and ’Confirming’.
During the first stage, ’Capturing’, it is all about getting the requirement any which way you can — through interviewing, observation, analysis, blue-skying, brainstorming, brainwashing, butt-kicking, or whatever-works-for-you.This phase is primarily based on the theory that requirements exist ’in the wild’, but until they have been captured, they are of little value.
In this formative stage of its life, a ’good’ business requirement is a statement that:
- starts with the words ’I (or We, or Our Department, or My people, or a specific role) need (or don’t need or want or don’t want or should or should not or will or will not)’;
- names a single component/feature/behavior/state that whoever has the authority in the business community to make the decision decides is an outcome of the project worth funding;
- focuses on the business outcome, not the technology to be used; and
- can be traced back to the individual with the authority to ’own’ and ’fund’ this requirement.
A couple of fine (IONSHO — in our not-so-humble opinion) examples:
- Sales needs to be able to see which contracts will be expiring within the upcoming 90 days.
- I want the system to automatically calculate sales taxes based on relevant sales tax laws.
- The website visitor won’t need to click more than once to get to the order page from any other page on the site.
- We need to be able to respond to a code red incident anywhere on the planet within 24 hours.
Simran,
Not sure what you are asking. Modifying is impossible without a lot of background information. If these are business requirements, I would maintain 1, 2, 4, and 5 are all too detailed. Thew work as solution level requiremetns. # is IMHO a constraint. Is that what you are looking for?
Thanks,
Tom Hathaway
Hi, Can someone help me in modifying these requirements?
1. The system shall validate and accept credit cards and cashier’s checks
2. The system shall record all mouse clicks that are very fast
3. The user must have Adobe Acrobat installed
4. All applicants have been or will be given a personal identification number (PIN)
5. The system shall record the name, address, city, and state of all insurance applicants in SQL Server.
David,
Again, great question which shows your command of business analysis best practices! I agree totally that the requirements we define as BA’s should be the what, not the how and that screen mockups are design artifacts. Including the design artifacts is much more an acknowledgement of reality as the vast majority of organizations with which I work want to see wire-frames, prototypes, screen layouts, and sometimes even report design in their requirements document. I do not consider it to be best practice, but recognize that reality generally wins. It is uncommon for an organization in the US to have solution designers and prototypers (in my opinion a best practice) so the BA’s are tasked with those responsibilities as well. My recommendation is to keep design components out of the “Requirements Documment” and publish them in a “Design Specification” document.
Thanks again,
Tom Hathaway
Hi again Tom,
Many thanks for your prompt reply and clarifying the difference between business and functional requirements. I watched your knowledge knugget which was very useful (thanks) and have a further question if that’s OK (?) :
My analysis process is normally to analyse the business domain, identify the use cases, write functional (and non func) requirements (which are strictly the ‘what’ – no ‘solutionising’ at this point) then write a functional spec (which then defines the ‘how’ i.e. the solution). IT then take this and code from it.
Now, when you describe the BABOK ‘solution’ requirements (made up of functional and non functional requirements) you mention these should cover ‘functions and qualities’ that the solution must encompass. However, in the transcript you mention that the solution requirements can be made up of several components, including screen mock ups. So are we saying that the solution requirements now can also include elements of the solution ? i.e. if we are including screen mock ups, then it is clear that a GUI will be used to satisfy some of the requirements. I was always told that requirements are the what, not the how.
Many thanks in advance,
David.
David,
Great questions! If you view our KnowledgeKnugget(tm) What Are Requirements, you will see that I now consider “Business Requirements” to be the high-level goals and objectives of the project that will benefit the organization (or target group) as a whole”. This is in line with the IIBA® definition. Functional Requirements (aka Functional Solution Requirements) and their relatives Non-Functional Solution Requirements are decidedly a lower level of detail that the solution providers (aka developers or vendors) need to ensure that they deliver what the customer (aka business community) wants. I express this much more eloquently in our just published video course “Exposing Functional and Non-Functional Requirements“, which is available on Udemy.com, Coggno.com, and OpenSesame.com. (By the way, this is so new that we are still in the process of adding it to our website.)
Regarding the Requirements Taxonomy that you cite, I fundamentally still stand by what is in that document but it is due for an update to incorporate current terminology. That task is currently on my (unfortunately rather lengthy) task list to tackle as soon as I finish all tasks that have a higher priority.
Thank you very much for the insightful questions and for visiting our website.
Tom Hathaway
Hi Tom,
I always considered functional requirements to be the business requirements (which is in line with your requirements taxonomy paper). And I’d put the functional requirements in a BRD.
However, recently I’ve been asked to write a business requirements doc where the contents are more along the lines of business objectives/desires i.e. higher level than quite specific functional requirements.
And some BA websites do differentiate between ‘business’ and ‘functional’ requirements.
What are your thoughts on this and do you know the business requirements I mention by some other description and if so, where do they fit into the overall analysis process ?
Many thanks!
Farhad,
Thank you very much for your comments and I agree that your suggestions represent improvements over the original.
Tom Hathawy
In my opinion (far from being humble) I think the samples can be perfected by the following changes (examples);
1.Sales Operations Team [Be specific on role/department] needs to be able to see which contracts will be expiring within the upcoming 90 days.
2.Account Manager [Too much vagueness in using ‘I’] want the system to automatically calculate sales taxes based on relevant sales tax laws.
3.The website user [Using the word ‘Visitor’ too broad] in won’t need to click more than once to get to the order page from any other page on the site.
4.Incident Management Team [Too much vagueness in using ‘We’ Be specific to clarity] need to be able to respond to a code red incident anywhere on the planet within 24 hours.