Creating standard templates and a standard look-and-feel for your documents takes time, and without wide support for it, the effort may well fail. The most important question is why you believe templates are needed. You must be able to articulate the benefits people will get from using a new standard to reasonably expect them to change and comply. Typical legitimate reasons for requirements templates include:
- Saving business analysts' time by presenting information consistently across projects
- Spreading best practices for requirements documents by using a standard outline of major sections to illustrate what they should include
- Making it easier for all team members to do thorough reviews, because every project takes the same approach
- Making it easier to reuse or reference requirements documents later
Whatever the project's methodology or content, you need to choose appropriate tools for planning your requirements approach, and for creating the business requirements document and hardware or software requirements specifications. Consider the following tests for each template you'd like to create and get into use:
The litmus test: Will it fit the culture? Think about all the requirements documents you've seen in the past, and the ones you're using now. What is lacking? Why do you feel a new template is needed? Then think about the working culture of the people you want to adopt the template. Is there a template design or approach that best matches the organization's style? What's the right level of formality? Some templates are nothing more than an outline of sections any requirements document should have. Others are elaborately formatted documents with fields to fill in. Some cultures will like the latter, while others will feel totally constrained by it. Make sure the templates you consider match the tastes and style of the people who'll use them.
The usability test: How easy will it be to use? Check whether a template you're considering is truly user-friendly. How easy is it to navigate the template, understand what to do, and fill in the right information? Are helpful annotations needed to guide what gets put in each section? Does the template include reference and organizing aids, such as page numbers and a date/time stamp and revision information? Is there anything you're asking people to do in the template that will be seen as awkward, inefficient, or "make work"?
The rubber band test: Will it be flexible and scalable? Nothing is more frustrating than a tool that doesn't fit or adjust easily to different situations. If your organization cranks out requirements documents of similar size and detail for all projects, a one-size-fits-all template may work. But if you do projects of different size and scale, your tools and templates will need to be flexible. Consider adopting "small project" and "big project" versions, or let the team members disregard tools that don't fit their projects. Resistance to standardization often falls off dramatically once people see they truly do have options. Flexible templates allow people to get the benefits of the standard format and contents, while using something truly appropriate to their projects.
The decal test: Will it apply? Think of all the projects you've encountered in your organization. What types of projects were they? What types of requirements played a role? Building on that framework, what must your template(s) include to be clearly suitable for those various projects? One of the best ways to match your tools and templates to the business, organization, or project, is to begin with something that worked in the past. Adjust those previous templates for the added benefits you're looking to get , to avoid the perception that you're throwing out good existing approaches and starting from scratch.
The devil's-in-the-details test: How common will the details be? How much detail is there in the requirements documents currently in use? What outlines or structures do they follow? Is there already some commonality of content and flow, or are they all over the place? The answers will tell you how hard it may be to get more common requirements templates into use and how many templates you may need. Finally, consider the detail your template(s) will call for—will it be seen as appropriate and valuable, or going too far?
The priority test: Is it clear what matters most? Documentation gets a bad rap when people feel like they're being made to write down a lot of stuff for no good reason. When you're creating one or a few templates to apply to different projects, do those templates make it clear what information is most critical? A typical practice with templates is to include brief guidance on what sections are mandatory and why, and what sections might get less or no attention depending on the project type or size.
An effort to introduce new requirements templates is really a project itself. It therefore deserves attention to clearly defining business needs, communicating customer benefits, and ensuring the usability of your solution. Make sure to do that analysis yourself, involve people who will be asked to use the templates, and communicate clearly the goals of your template effort, all along the way.