12 April 2011

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.


  1. Ted, It is a big challenge. I am working with some guys right now on trying to develop an approach.

    There are some specific impediments;

    Where are requirements located? What is the context they are written in? What do you do with poor quality requirements? What are the standards for requirements notation?

    I suspect that the challenge is in the loose structure of requirements - not just blending implementation stuff, but the business and system domains.

    A business requirement operates in a business context, which may be reasonably stable, or may not be.

    Security requirements for example, are likely to be stable-ish and independent of market factors, but requirement for generating a mail list may be very time specific, may be specific to a particular business unit and my have no reuse facility.

    This is a good post because it's prompted me think through the challenges from a different angle.

    Maybe you need to set a goal and put in some standards and tools, and then iterate toward where you have a meta-set of business requirements which model the enterprise as a whole.

    Maybe we need to look to enterprise architecture.

    Maybe we should be focusing on system requirements first and get that sorted before we move up-line to business requirements.

    Definitely a big challenge.

    But the reward seems viable, so it's potentially worth experimenting and incrementing our way there.

  2. The entire concept of writing for reuse sounds great. I write/diagram this information once and then anyone can use it in the future. The assumption is that 1) the information is useful in its original form and 2) its not more effective to do the work a second (or third or fourth, etc) time than it is to write for reuse the first time.

    Given that requirements are nothing more than a way to transfer meaningful business information in a form that is accessible to all stakeholders, if the stakeholders change, would not be possible for the requirements (or at least their written/diagramed form) change as well? Even if we assume that requirements meanings can be reused from project to project, if the people change, will the format of the requirements not change anyway?

    If we were dealing with robots, or at least humans who do not change nearly as often as we do, then i could see a larger case for requirements reuse as the duration of their written/drawn form would last much longer.

    I want to see requirements reused as I see there is great value in this happening, but I don't know if the rapid change that our societies are facing really match up with reusing requirements at this time. Maybe in the future, if the change of pace slows again, then reuse would become more viable. As for now, I just don't see it.

  3. The company for which I work believes whole-heartedly in reusing requirements. For us, it is easy to do, since we are an ERP vendor with a very large product. Between supporting our existing software and annual regulatory updates that need to be applied each year, many of the requirements remain the same. Of course, we continue to add requirements as we add functionality, and some requirements will become obsolete, as our industry's needs change.

    Our process involves including requirements as a set of artifacts in our overall product model. The product is modeled in UML, and each requirement is an individual object. (The requirement object is an extension of the UML symbol set in the tool we use: Enterprise Architect, by Sparx Systems.) When we take on a project, we export all the pertinent requirements into a project model, add or update as necessary, and then trace them through the development life cycle. Requirements are marked proposed, approved, implemented, validated and then delivered as they move through the SDLC. Once delivered, we move them back into the product model for use once again.

    Fundamentally, the business process of our industry (higher education) doesn't change much, though the technology we use to improve it evolves rapidly. Registering for a class, for instance, hasn't changed much over time, but as user interfaces -- and student expectations -- evolve, so do the requirements to support the business process.

    Thanks for an interesting post -- we were just discussing this in the office today in our weekly business analysis professional development meeting.

  4. Sheryl, that's an awesome point. Having never been on an ERP project (although I've fed data into lots of different ERP systems), that one had not occurred to me, despite having been a consultant at one time. I was doing CRM projects, and while it was packaged software, every client I went to had vastly different ways to 'take a call'. Many were just terminology differences, but it was quite surprising to me how many really had crazy differences (by crazy, i mean, 'not useful').

    Back to your point, if you are doing regular projects with the same software with multiple clients that have nearly identical business requirements, then I definitely could see reuse here. When you reuse, do your clients know you are reusing? Is this a selling point for your services? I personally like when a vendor can bring me information they've used elsewhere, partially because I know they probably understand what I'm talking about!

  5. Anonymous4:47 am

    Thank you guys. I'm on the way to write my Bachelor Thesis about Requirements Management, especially re-use of requirements over different projects. I found almost nothing in the literature and was quite disappointed. Now, after reading your blogs I know why! It's not only a big challenge for me, it's obviously a big challenge for every enterprise and nobody knows how really to deal with...

    Emanuel Fl├╝ck