Keep Track of Project Requirements With These Templates
written by: Matthew Craig
• edited by: Michele McDonough
• updated: 6/30/2011
Ever since the beginning of time, humans have been organizing projects, people and resources. Have all of these been perfect? Of course not. That's why evolution has created various requirement gathering techniques. Fancy templates haven't always been around. . .but now there's no excuse.
slide 1 of 6
The Right Tool for the Job
If you're looking for a "one size, fits all" requirement gathering template, this probably isn't the resource or you. But if you have some basic, complicated or somewhere in-between, project needs that need to be met -- keep reading.
No one should be satisfied with cost overruns, endless miscommunication, or client/vendor embarrassment. From software development to movie producing. . .all of the above issues fall in the territory of project management. However, too many companies accept the status quo of project responsibility. Sometimes a company will have 15 different authors of one requirements gathering template. Not when you have a clear basis to work from. This is where the following templates come in.
Yes, the information will be substantially different -- and your template will probably resemble nothing of the following. Yet, having a solid platform to work from is paramount for solid project managers.
Take a look at the following templates and see if they'll work for you. The documents range from simple (for basic projects) to complicated (for, well. . .in depth projects). Enjoy.
slide 2 of 6
1. Simple Project Requirements Template
This requirements gathering template (see download link below) is used by many technology services to kick off and properly manage the initial and continuing work flow of managers and employees. Let's break things down to see what kind of features it offers:
Assigned roles and responsibilities. As you see in the image, Page 3 jumps right into things by assigning roles and responsibilities from the beginning. There's nothing more important in project management then getting started on the right foot. This is one reason why a document of this caliber should be drafted by one author. That's not to recommend a lack of proper review and feedback. However, don't try and assign authority by committee when dealing with requirements gathering templates.
Rated and organized priorities. Pages 5-10 are where the meat is. Requirements. Page 5 lists the official requirements priority key:
High: The application cannot function properly without this requirement.
Medium: The efficiency of the application would be greatly improved by this requirement.
Low: This feature would be nice to have; it may consist of cosmetic changes, non-critical inquiries, or other non-critical updates.
Requirements flexibility. Pages 6-10 list specific requirements to the project: rated high, medium or low of course. Keep in mind most of the requirements are rated high and medium. Do notice one thing: they aren't listed from high to medium. . .yes, the majority of "high" requirements are at the top - but there is a "medium" thrown in towards the bottom. In terms of organization, the project manager should decide whether category or rating is more important. Plenty of space is available to list the requirements in detail. This template lists the order #, description and priority. Remember, this is a template. More features can be added or omitted.
Link to Template: Download here. On the download screen, please choose the SC_VINE_PRD.doc file.
Image credit(s): Appriss, http://www.appriss.com
slide 3 of 6
2. Intermediate Project Requirement sTemplate
All software project developers should immediately skip to this section. The reason why this requirements gathering template is listed as "intermediate" is primarily because of the detailed documentation and functions. As always, you can take this template, blend it up, re-organize and completely make it your own.
Software is one area where finding the right requirements gathering template, separate from standard programming documentation, is mandatory. Why? When you have more then one team working on design, programing and implementation, things can get out of control quick. And, besides the "out of control" tendency, internal departments (finance and accounting) and 3rd party vendors also like to know what is going on. Enough said. Let's take a look.
It's important not to buy into the "confusing makes it right," dogma. Just because no one outside of development can understand it, doesn't make it correct. Projects mean exactly that. Everyone is working.
Here's how this requirements gathering template can solve these issues.
Stable documentation. Again, this template is documentation heavy as you can see from the image. The first section makes it very clear what the objectives are: Introduction, Overall description (product perspective, product features, operating environment. . .) System features. . .etc.
Agreed upon requirements. Numbers 4 & 5 are critical to any project or requirements document: External Interface Requirements (4) and Other Non-Functional Requirements. Keyword here is requirements. Basically, the document opens with various project features and progresses into more critical aspects.
Uniform revisions. Take note of the Revision History section. . .as in the previous requirements gathering template. Any time a change is made by project managers or employees, this is clearly documented to maintain uniformity. Most of your time will be spent in the various requirements sections (as seen in the External Requirements image). Check out the filler text and see how each section will be useful.
Link to Template: Download here. Click on the "Software Requirements Specification Template" link under the bold "Requirements Engineering" heading.
Image credit(s): Process Impact, http://www.processimpact.com
slide 4 of 6
3. Advanced Project Requirements Template
Ready for the grand finale? Call it whatever you want. This requirements gathering template is one of a kind. Exact in nature—enough to make the novice's head spin. Ok, lets not trump things up too much. Just dig in and find out for yourself.
As you'll see, the examples in this document contain ideas for objectives, scopes, marketing plans and legal briefs. No reason to over explain, check out the details below.
Clear goals and requirements.The primary features of this advanced requirements gathering template rest in the "goals" and "requirements" section. As seen in the latest image, not only are there keyword sections (Major Milestones, Owner, Target Date), the language before the requirements table should not be overlooked: "A full detail project plan WILL be released once all preliminary planning documents have been completed and agreed upon." Yes, owners are established and tasks are delegated. But the document also commands everything to be nailed down before all details are released.
Defined roles and designations. Take a look at the second image. The planning (project) committee and the technical (action) committee are divided and stated for separate roles. This is crucial.
Clear revision history. Once again, its important to have a clear revision history when putting projects on paper. It's not that your executives, PMs or employees don't have the intelligence to send out a mass e-mail and "let everyone know about the changes." Life just doesn't happen this way. Make clear revisions. Document. Enforce. And, this requirements gathering template can help you do exactly that.
No matter what requirements gathering template you use, be sure and find one that fits your business model and company structure. All of these templates can be useful, regardless of the size of budget, company or project. The key is to find a template that encompasses order and controls cost overruns.
Never forget: If you failed to notice, there have been several recurring themes: responsibilities, requirements and revisions. These are the keys to a successful project and quality project document. All three will help you have a clearly defined task, make sure it's done in a timely manner and help put out "fires" since plan variations are bound to take place.