It is a bit late for Earth Day but who knew the three R’s could apply to software requirements as well?  Creating requirements can be long and arduous work.  Depending on the features or functionality you are exploring, it could be tedious or fun.  Regardless, you are doing this for a business purpose.  What is the ultimate business purpose? Profit.  So it makes sense that if you are ensuring that the products being developed help drive profits, then you should also have business practices that maximize your business value.

So lets take up these three tenants (among others):

Reduce the scope to meet budgets and timelines.   Make sure all features and functionality are tied to priorities in some way.  Worst case is you guess what is high and low priority.  Best case you have the business objectives and KPIs tell you the value of each feature/functionality.  Now you can make a sound business case for which items need to be dropped for being out of scope, which need to be dropped to allow for higher priority items to get developed, and which items need to stay as they will be critical to project success.

Reuse templates and feature documentation.  Are you constantly writing login portal requirements?  Chances are most login portals will share a majority of functionality.  Keep a copy around and reuse it the next time.  Change the username requirements to work with emails instead of usernames.  Or change the password recovery to require a secret question instead of an account number and email.  Either way you most likely cut your work in half at least.  This applies in many areas: Shopping Carts, Reports, Searches, Mass Load/Edit/Deletes, etc.  No sense in recreating BRDs and SRSs from scratch.

Recycle out of scope documentation.  You just completed 20 hours of documentation for the system to be able to handle erroneous online orders and the process to get them back on track.  It just got cut.  Turns out that the budget ran out and this was the lowest priority.  Don’t throw it away.  Keep it around.  Put it in your out of scope repository and when you or someone else will finally have a chance to make it, they have all the work done except for some minor changes and updates.  Alternatively, you just got all of your documentation signed off and approved.  Make sure it is available to the next group who can use it as baseline for a future Gap Analysis or general features update.

I hope that many of us are already practicing some if not parts of these tenants.  Not only does it increase the value you are providing your organization, but it should make the job easier for you and your team.  Perhaps in the future we could explore the new opportunities offered by introducing ‘Stop, Drop, and Roll’ mentality to requirement gathering meetings for people who argue.