The BABOK and Requirements Reuse

One of the first things I learned as a BA was how to write requirements. I still remember the subject of my first two business requirements documents (using card payments for the purchase of extended warranties and using card payments for the purchase of out of warranty service) and I could probably recreate them today, nearly word for word, over nine years later.

Yet, in those same 9 years, not one time outside of that project have I ever needed to reuse those requirements. Despite having worked on an absurd number of projects over the years in similar and vastly different organizations and teams, the need for those requirements have just never come back up again. Even at the company where I did that first project, those requirements haven’t once been used again.

A former development manager I used to work with was regularly heard preaching to his developers about the importance of code reuse, yet in all the time I worked with him, I never saw him or heard him speak of actually doing it himself. From what I've read in the blogosphere, it seems as if I’m not alone in thinking that code reuse is not as important as it sounds like it should be.

Its this focus on code reuse that I think has shifted over into the realm of the BA, possibly inappropriately, and reusing requirements. Yes, requirements can be reused, and if you come across a project where they can, great! In my 9+ years, this hasn’t happened even once, even on projects that were very similar. Am I the outlier, the one guy in the industry who has had the spectacular fortune (or maybe misfortune) to never have been able to reuse requirements?

Understand what I mean by reusing requirements. I reuse lots of information and business knowledge from project to project. In fact, I spent a good amount of time earlier today explaining to a different team in my company the business rules and implementation logic of a set of functionality that my team implemented nearly 2 years ago. Why didn’t I just give them the requirements documents? Simple, they were not actually reusable.

The requirements for the project my team did 2 years ago were actually written 4 years ago and were written back when my segmentation of requirement types was a lot more fluid (read that as ‘poor’). I mixed implementation details with requirements. Shame on me! Yet, if you read a lot of requirement documents, this is what you find. Yes, these are probably poor requirements documents and NEVER would I write its kind again, yet its all I have from that project and its something that is meaningless to a team now implementing similar functionality in a different business area.

When I think about the problem of reuse, I figure that someone has to know a solution, or at least a better technique than what I know. I’ve heard every requirements management vendor under the sun promise such, but have yet to see one really deliver on that promise. Requirements are almost always tied with some project and not specific to the business.

If vendors can’t get it right, what about the IIBA? Grab the BABOK and look in the techniques section for Requirements Reuse. What’s that you see? Its empty? Look back at the prior few chapters and then forward at the next few chapters. None of them have a section without at least a couple techniques, yet requirements reuse is strangely blank. Why is this?

I’m not picking on the BABOK (I like it quite a bit actually, being a CBAP), but I’m using it as an example that even the most authoritative guide to business analysis can’t provide any information on how to actually do this. Requirements reuse, just like code reuse, is hard and very possibly not worth our while.

The BABOK even talks about this when it says to “Identify requirements that are candidates for long-term usage by the organization.” If you won’t be using it again, and regularly, you might as well not bother. While well-formed requirements should be reusable, the amount of time, care and effort required to write reusable requirements could be better spent doing additional elicitation, analysis or validation.

So what about you? Do you regularly develop requirements with reuse in mind? Do you have a technique that the BABOK v3 should include? Let us know in the comments.