Using Corporate Requirement Templates
And not Go Crazy
Lately, I was forced to endure some required SDLC training in my corporate day job (insert barfing emoticon here). Yes, once again "big brother" is requiring the use of some all-encompassing, miracle SDLC approach, templates included. In truth, there is nothing new here and nothing to be terrified about. This really goes with the territory when you work in IT for large company. As much as it may suck, you will probably waste more energy complaining about it than it is worth. Instead of complaining about it, I would encourage you to figure out how to bend the rules so you can do things the most efficient way, without wasting hours going against the grain.
Corporate templates are not all bad. In truth, they often help create some consistency and reinforce a lot of the best practices in the world of software requirements. But, their drawback is that they can encourage a more limited approach to your analysis. It is very easy for an analyst to make his or her focus completing all the boxes and blanks of a template, instead of it being on documenting all inclusive and fully exhaustive requirements. Put another way, the template becomes a crutch and could prevent the analysts from asking questions beyond what the template asks. Still it can be wonderful not to have definitely modify the rim with every project.
Still, my own point of view is that there is the right tool for the job (check out the templates Page for some of my favorites). For example, there are different techniques to document requirements for a data warehouse vs. an online bank. With standard corporate templates the tendency is create a template that is one sized fits all. Many of the sections are not going to be relevant to your specific project. My advice, keep the documents template (FRD or FRS or Powerful Specifications or Fred or whatever calls it) and removed the sections or headings that are not appropriate for your project. Then add what is really necessary to do the job. The document police will likely never notice, and the people who will actually have to comprehend your requirements won't care if you included what they really need.
Now, before you gut your mandated templates and such, just a few ideas on the items that is almost always needed:
1. Have Traceability Make sure that you can illustrate how each functional need aligns to a business need.
2. Be All-inclusive and fully-exhaustive This is a topic that is suitable of its own post and an a great number of variety of group discussion. But, the point is as a software or business professional you need to be a software professional. Do not take one-line requirements from the business as is. Make the effort to discover what is missing, and ensure that all the information and initially undocumented scenarios get captured. Usually this is where typical corporate template fails. Ok that wraps up this article, good luck to everyone in fighting the power!