Processing your Requirements Document

This post originally appeared on BetterProjects.net on June 14, 2010.

One of my very first posts about being a BA was about how much I hate the tools BAs have to work with in our jobs. One astute commenter pointed out that most of the tools I mentioned were not really BA tools at all, but general purpose tools that BAs ended up using. This general tool approach often occurs because of a lack of funds for specialized tools or an ignorance that better tools even exist.

Given these limits on tool selection, I’d like to take a few minutes to give the BAs out there who lack specialized tools a few quick ideas on ways they can use a word processing application to be more productive in creating and managing requirements.

Hopefully, your organization has a predefined requirements management template of some kind for you to use. If they don’t I highly recommend asking if you can form a group of analysts to create a standard one for use across all projects and business areas.

Templates are great for many reasons, but the one I want to talk about speed. If you have a set template, you know the minimum amount of information you need to get to your first review. It is as simple as filling in the different sections with the appropriate material. You don’t need to spend time trying to figure out what different artifacts you could or should include, as a properly created template tells you what you need. Starting with a totally blank document each time is analogous to recreating the wheel.

Use Styles. They’re the little labels like ‘Header 1’, 'Header 2’ and 'Normal’ that are found in the toolbar, usually above the document itself. These are fantastic time savers as you can create new styles and apply them to different areas of your document for additional emphasis.

The other great thing about styles is how the Headers tie in with your Table of Contents. By correctly using a style, your table of contents builds itself for you when you tell the application to include one in your document. Creating and maintaining a table of contents by hand, especially in a very long document, can be a nightmare.

A word of caution though, especially if you’re using a template. Make sure that you only create as many styles as you need. Having too many styles can make using them as unwieldy as doing multiple format updates manually. Make sure your template is stripped of all unnecessary formatting prior to its initial distribution.

Auto text is a feature which I find interesting, but don’t personally find a lot of use for in my particular role. The idea of auto text is that if you find yourself constantly typing out a long string of terms or some unwieldy proper name, you can create a short set of keystrokes that the word processor will automatically change into the phrase. If for some reason my organization regularly has discussions about 'Very Extended Three Letter Acronym’, then I could create an auto text rule so that whenever I typed 'VETLA’, it would automatically be replaced by the full text.

This is especially useful if your organization has a lot of specific 'jargon’ or acronyms that are unique to themselves. Consider this to be nothing more than an automated Find and Replace function. Be careful about what acronyms you set up as any time you use them they will always expand. Word processors are not smart enough to understand if you really want to use the acronym this time or if the acronym also has a common usage that does not mean the same thing as your organization specific usage.

One thing that I find is regularly overlooked is document properties. Any document you create on your regularly used PC probably has your name listed as the author of the document. However, if you take a document created by someone else and replace all the content with your information, the document properties will still show the person who originally created the document as the author. I’ve worked on projects before where the author field in document properties was a person I had never heard of and the company they worked for wasn’t affiliated with my organization in any way.

There are lots of different properties in documents that could be helpful if you take a look through the list. Title, Subject, Author, Manager, Company, Category, Keywords, Comments, Hyperlink, the list goes on and on and on.

My last suggestion is the one that comes with the largest disclaimer of all my comments. Track changes can be very useful, but even more than a decade of enhancements, most word processors still do not do this very well. Track changes can do an acceptable job of showing what textual changes were made and by whom. Where the function often fails is in attempting to track changes to tables, inserted objects and textual formatting.

Even if you use the tool sparingly, it isn’t used often enough in most organizations to be in the common repertoire of most knowledge workers. If you choose to show the final version including changes, you will likely need to explain to some of your reviewers how to read through the changes that have been made to the document.

If you decide to track changes, make sure that most of your internal revisions occur with the functions turned off, or that you increment the revision number and accept all changes before doing another round of reviews. This keeps the document from being overly cluttered and distracting from the actual content.

Those are my suggestions for how to get the most out of a requirements document created with a word processing application. Do you have any suggestions I didn’t cover which you teach others? Let us know in the comments.