Software Requirements and the IIBA®
Words have meaning. They evoke feelings. So, what do you feel when you hear the word software requirements? If you cringed internally, you are probably as battle-weary as I am about trying to get the world to understand that software requirements should not be a cussword. (I recently worked with a SME who actually programmed her Outlook to move all emails containing the words “software requirements” 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 Software Requirements
One of the major shifts that the IIBA has caused in my thinking has to do with that ugly word, software requirements. Hitherto (forsooth, it has been a long time since I was able to use that word in a sentence) we at the BA-EXPERTS 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 software 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 software 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).
We are currently in the process of updating our Requirements Taxonomy with BABOK3® and will publish it as soon as it is available. We apologize for the inconvenience and appreciate your patience.
