As the business analysis profession evolves we will get more consistency around our terminology. One of the phrases that is still used inconsistently is requirements management. Most experienced BAs use the phrase "requirements management" to mean the activity of "managing" the requirements. This includes tasks like deciding where requirements will be stored, how they will be documented, how they will be presented, how they will be maintained, who will update them, etc. This use of the phrase makes sense to me and I would like to endorse it. I also encourage organizations to maintain requirements after the project is complete and "manage" them over the life of the system/solution. Re-using requirements on future enhancement projects provides a huge productivity gain for business analysis work.
The problem that we have with this phrase is that CMM and other sources who have been around for many years were using the phrases "Requirements Management" to describe the activities around eliciting, analyzing and documenting requirements. Since CMM was well established and well known it will be difficult for us to change the meaning of this phrase. In more recent years CMMI-Dev has narrowed the definition of Requirements Management but many people do not seem to be aware of the newly updated definition.
Many of the vendors selling requirements tools are doing a better job of distinguishing between performing requirements definition and requirements management.
You can Google "Requirements Management" today and find many different definitions.
I am interested in your thoughts about the use of this phrase and/or others you think create confusion in our industry. How does your organization use the term Requirements Management? How difficult do you think it will be to change people's perceptions and move to a consistent meaning?
August 20th, 2008 at 3:50 pm
Barbara,
The role of Business Analyst was discussed on 7/29 on the IIBA blog (”BA Job Trends”). That term is also used inconsistently. Beyond the myriad specializations (IT BA, PM BA, etc.), I have seen BA job descriptions that sound more like Financial Analysts.” Per my comments on that thread:
“Some actual examples:
- ‘…making recommendations on product assortment, product placement, and promotions.’
- ‘Conduct analyses on…revenue trends and provide concrete suggestions on driving and maintaining yield…’”
August 20th, 2008 at 5:18 pm
It’s a good point about the difference about requirements definition and management. We recently did an industry survey on the State of Requirements Management to demystifying some of the trends, challenges and terminology, thought it might be relevant to this discussion, can download the .pdf of report here:
http://www.jamasoftware.com/requirements_management_report_download.htm
August 21st, 2008 at 7:06 am
I’m with you 100% Barbara.
August 29th, 2008 at 9:09 pm
Hi Barbara,
As “Requirements Management” has been coined in the context of CMM and later CMMI it seems to me the phrase you are looking for is “Scope Management”.
September 22nd, 2008 at 5:59 am
Bruce,
Thanks for your suggestion. But I see requirements management as very different from scope management. Scope management is focused on the scope of a project and as such ends when the project ends. Requirements management continues after the project ends because many requirements should be saved and re-used on future project. Keeping these requirements around (deciding where to keep them, what to call them and how to access them) is requirements management.
Barb