Requirements Management Reality Check

Okay, so here’s the thing. In my 10 or so (hey, I’m trying to not reveal my age here) years of experience implementing software, I have been asked, “But don’t you have a template for requirements documentation?” more times than I can count.  Well, sure, I have templates, a standard operating procedure (SOP), and guidelines that provide a wealth of help with process and tips and “don’t forgets.”  Combined with a full quality management system (QMS), these artifacts provide the structured governance required for good, repeatable software quality assurance. But let’s take a quick reality check here. I have yet to work on a software project that was exactly like the last one.  Restricting the requirements-management effort of a project to assume the same approach of the project before, the project next to, or the project in front of them can bind the hands of the analysts working on the project.  We become boxed into a “but-we-must-do-it-this-way” so often that we have the potential to miss opportunities for efficiency, innovation, and sheer genius. So what good is a QMS for an analyst, then? Aren’t they supposed to help analysts?  They are, and even better: a flexible quality system can also empower an analyst!

So what does a flexible quality system mean, exactly?  From the analyst’s point of view, a flexible quality system gives us choices within a set of boundaries.  For example, while my SOP declares that I must manage requirements (boundary #1), it also prescribes that I first write a requirements management plan (RMP) (boundary #2).  Because I customize the RMP to meet the needs of my project, I have the flexibility to decide:

• The kind of requirements artifacts and requirements model we need (for example, use cases versus structured specifications, or both)
• The process we implement that results in those artifacts (for example, big requirements meetings for stakeholder analysis, one-on-one meetings, reverse engineer existing systems)
• The workflows we set up to facilitate the long-term management of those artifacts

This flexibility of being able to make project-specific choices about the requirements-management effort empowers analysts and connects them directly the success of the project.

Let’s be real though. This flexibility and empowerment can lead to chaos if the RMP isn’t controlled just like any other project document (boundary #3).  Keep in mind that while the RMP is developed by the analysis team (and usually by a strong analysis lead or requirements lead), its purpose is to provide clarity to the requirements management process for the entire project team.  Changes to the RMP will impact all of the disciplines of the team.  It is not a good idea to surprise the software quality assurance testing team by changing the requirements model mid-project without their input.

I know what you are thinking. “Hey, lady, I have barely been given enough time to write the requirements, let alone some other document that is just going to be stuck in some project binder and locked away never to be seen again!”  Okay, okay, I get it—and here are some things you might be able to do help empower your requirements management efforts:

1. Sketch out your requirements model and include how the requirements trace to each other (even if it just for you).

2. Sketch out the tasks you need to do (or need others to do) to elicit and document your requirements.

3. Sketch out the workflow to keep your requirements up to date through change management.

4. Take a deep breath. You are empowered and you have an RMP!