A Requirement by Any Other Name
What’s in a word?
Words have meaning. They evoke feelings. So, what do you feel when you hear the word “requirement”? If you cringed internally, you are probably as battle-weary as I am about trying to get the world to understand that “requirement” should not be a cussword. (I recently worked with a SME who actually programmed her Outlook to move all emails containing the word “requirement” to her “Junk Mail” folder. OK, I found out that she did it as a joke, but I think she was really trying to make a statement). Is there hope for those of us who still believe in analysis? Let’s take a look at the state of the practice.
As many (or all) of you already know (or now will), the International Institute of Business Analysis (IIBA®) released version 2.0 of its Business Analysis Book of Knowledge® (BABOK®) earlier this year. As a big fan of any organization whose goal is to reduce the chaos and suggest a common vocabulary for this emerging discipline, I unequivocally support this action. I have taught business analysis since before it was called business analysis. I salute those who have taken it upon themselves to create a group willing to take a stand on what business analysis is and why we do what we do. Kudos and applause.
Repositioning Requirements
One of the major shifts that the IIBA has caused in my thinking has to do with that ugly word, requirements. Hitherto (forsooth, it has been a long time since I was able to use that word in a sentence) we at the Requirements Solutions Group have been espousing the difference between business requirements and technical requirements (a.k.a.: system specs). We publish and distribute a free requirements taxonomy which lists the various types of requirements duly separated into those two major domains. The paper has been very well received. I have occasionally encountered students in my classes who had actually read the paper and were applying it even before the class.
With the release of the BABOK® version 2.0, the IIBA® defines four domains of requirements which business analysts need to gather (or, in their terminology, elicit):
- Business requirements are high-level goals and objectives that cause projects to be initiated;
- Stakeholder requirements are conditions defined by specific groups and individuals within the project that must be met for the project to succeed;
- Solution requirements are technology-bordering (not crossing!) conditions that have to be met given that your application will involve technology; and
- Transition requirements define criteria for getting from where you are (the ASIS) to where you want to be (the TOBE).
How does this breakdown compare with ours? These four requirement domains are a stratification of the "Requirement Kingdom" (to stick with the terminology associated with the biology taxonomy), so to be proper (and we must be proper, by all means!), we shall endeavor to “go with the flow” and create a mash-up (what a great 21st century concept!) of taxonomies.
The “Old Way”
Domain |
Business Requirements | Technical Specifications | |
| Functional (Doing) |
01 Processes / Procedures (Manual) | 51 Modules / Programs (Automated) | |
| Informational (Knowing) |
11 Knowledge 12 Information 13 Business Rules 14 Business Data Entities 15 Data Elements 16 Help facilities 17 Data Constraints |
61 Data structures |
|
| Behavioral (Performing) |
Quantitative (Objective) |
21 Urgency 22 Frequency 23 Volumes 24 Accuracy |
71 Size 72 Precision 73 Response Time 74 Update Time |
| Qualitative (Subjective) |
31 Usability 32 Trainability 33 Flexibility 34 Availability |
81 Maintainability |
|
| Environmental (Constraining) |
41 Distribution (Organization) 42 Location 43 Security 44 Legal 45 Cultural |
91 Interfaces (Interaction) 92 Standards 93 Infrastructure 94 Methodology 95 Technology |
|
The “Up and Coming”
Domain |
Classes |
Technical Specifications (Not in the business analyst’s jurisdiction) |
|
Business |
Goals and Objectives |
N/A |
|
| Stakeholder | 11 Knowledge 12 Information 13 Business Rules 17 Data Constraints 41 Distribution (Organization) 42 Location 43 Security 44 Legal 45 Cultural |
|
|
| Solution | Functional | 01 Processes / Procedures (Manual) |
51 Modules / Programs (Automated) |
| Non-Functional | 21 Urgency 22 Frequency 23 Volumes 24 Accuracy 31 Usability 32 Trainability 33 Flexibility 34 Availability |
71 Size 72 Precision 73 Response Time 74 Update Time 81 Maintainability 82 Reliability 83 Portability 84 Scalability |
|
| Transition | ??? | 92 Standards 93 Infrastructure 94 Methodology 95 Technology |
|
Call for Help
If you would like to participate in this “grand experiment”, Please email me, Tom.Hathaway@reqsol.com with your suggestions. If you are adding a new class of requirements, beyond the name, it would be great if you would provide a definition, a description, and an example of what you really mean. If you would like to know what I mean, you can click on any of the groups listed in the tables above to see an example. We will acknowledge and publish accepted contributions in a future edition of the Noiseletter..The idividual with the most submissions will also receive FREE access to all three of our self-paced modules in the series "How to Write Business Requirements for IT Projects". Let the great ideas roll.
Author: Tom Hathaway
Managing Partner
Requirements Solutions Group, LLC
Editor’s Note: New Business Analyst/CBAP®) Self-Evaluation
Are you ready for the CBAP® (Certified Business Analysis Professional®)? The CBAP® is a certification test developed by the International Institute of Business Analysts (IIBA®). Passing the CBAP® is a feather in your cap and it can also open closed doors. Our free self-evaluation lets you see how your current skill levels compare to the levels needed to pass the CBAP®. Even if you do not intend on becoming certified, the evaluation shows you what techniques business analysts in today’s business environment need to have. For those of you who have taken our test in the past, this is a brand new version. You must enter your contact data to be able to see your personal evaluation. We will not share your information with third parties without your express permission.
Dan Myers
Managing Partner
Requirements Solutions Group, LLC.
(866) 584-2075