Getting the Stains Out of Your Requirements

 

Having taken over a project, I find myself in the awesome position of needing to revise requirements with my customers that are pretty obviously in need of some spring cleaning.

Here are some tips for your own situations where you must "scrub the stains" out of a set of requirements, as opposed to dealing with change management on one specific requirement.

Make it Easy

We use DOORS to manage our requirements.  For me, step 1 is to export from DOORS to an excel file.  Getting these requirements into a format people are comfortable with is very important.

Next, I trim away the fields that don't really matter for what I'm trying to do, and then copy/paste the requirements into a blank Word document.  The reason for this will be come clear in a moment.

Track Changes, with Comments

I turn on the "tracking changes" option in Microsoft Word, and go to it.  Whenever a change is made, a comment accompanies it.  I speak to my audience, the customer, so they will easily be able to understand why I am proposing some changes.  In this case, I want to add clarity and also specify some functionality that has become known as a user need over time, but wasn't captured in the original requirements.

Review With The Team

I always like to review any requirement changes with my teams before proposing them to the customer.  This way, I can be sure I'm on the same page as my team members and there aren't any communication gaps about the needed functionality.

Many times, the understanding I've gained about new wants and needs comes directly from my team members, who are interacting with the customer and future users of the system.  It would be very bad if I had a misunderstanding on a particular requirement and ended up making that part of the baseline, when it's really describing the wrong thing.

Meet with Customer

Next I meet with the customer to ensure the changes I'm proposing make sense to them.  The comments I did earlier come in really handy, and the better they were, the easier this process is.  In my environment, I prefer to do this before having it come up at a Change Control Board (CCB) meeting as a change request.  I want the customer to be knowledgeable about the proposed changes and see the value in them before having to make a decision.

Change Control Board

The final step is to "make it official".  If you don't have a change control board in your project environment, you should set one up.  It doesn't have to be complicated, but it does require that everyone on the project understand that changes don't get made to the project baseline unless they are approved by the CCB.  

The customer and sponsor should be voting members, and in my environment the customer is the chair of the CCB.  That means they have the final word on whether a proposal will be approved or not.  If you are in a different contract environment, it may be a CCB internal to your own company/contract you are interacting with.

Like this? Share it!