The Importance of Requirements

The title of this post isn’t what it appears. This isn’t going to be a post about how managing requirements is a non-negotiable element of successful software development projects. Although, I am of the mind that there is still plenty of writing, talking and doing to be done around that topic.

No, this post is about a different aspect of the importance of requirements. It is about the importance of each single line-item requirement that is captured during a project. The background on this is that the question was raised (here) about whether requirements should be deleted from the repository if they are deemed to be out of scope or otherwise not relevant to the project.

My response is “No.” And here’s why.

Software requirements efforts are rife with information. Key responsibilities of the Requirements Manager are to capture, document, categorize, organize, evaluate, disseminate, facilitate review and manage change for that information. All of that information. Once a requirement is expressed it is in someone’s mind as being “a part of” the project. Whether it comes from a vision or scope document that was part of the preliminary project formation steps, one-on-one end-user interviews, or even a comment some executive makes in an offhanded way in a meeting that might not even have been specifically about requirements, the requirement is out there and for successful projects must be managed.

Now this is not to say that a Requirements Manager should be responsible for being in on every single communication exchange that occurs around the project and capture all of the data. This isn’t reasonable. But it still doesn’t dismiss the fact that requirements come from unconventional and informal sources in addition to the planned sources and exercises. So anyway, I mentioned these examples of how requirements are expressed to illustrate that every requirement has a source. And my experience has shown that the source of that requirement is INVESTED in that requirement. I have heard “pride of ownership” applied to this dynamic, with the implication that this somehow inappropriately involves personal ego, and that may be the case, but I also think it involves people simply doing their jobs by representing the interests of the group to which they report or the tasks that they perform.

So given that I know my source is invested in their requirements. I want to be able to show them that same requirement at the end of the project and be able to tell them the story of what happened to it. If it made it into the final product, I want to be able to show them the final requirements artifact that was delivered to development and testing. And I want to be able to show them where in the final app it was realized and show them the cases that were applied to test its functionality.

If the requirement did not make it into the final app, I still want to be able to show that invested source when it’s status changed from “In” to “Out” and be able to provide them some context for the reasons. I want to be able to answer the question was this just an abandoned requirement or one that just didn’t make it into the current release but will be considered for a future release. I want to be able to tell the source what reasoning was used to take it out of the current release. I should have that reasoning documented with the requirement so I don’t have to remember it.

And to be able to report any of these things to my requirement source, I have to have that requirement and all of its attributes documented, not deleted.