Start with a sample template: If you have built software requirements in the past, utilizing a pre-existing template is a great place to start. If this is the first time developing software requirements, there are numerous examples and templates that can be found online or through fellow technical writers or product managers, to facilitate the. Software Requirements Specification (SRS) Template. Items that are intended to stay in as part of your document are in. Bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project.
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.
1. Simple Project Requirements Template
Functional 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, https://www.appriss.com
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 doc
umentation, 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, https://www.processimpact.com
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 natur
e—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.
Link to Template:Download here.
Simple Software Requirements Template
Image credit(s): MS Forum, https://www.msforum.org
Summary
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.
References
- Appriss, https://www.appriss.com/scvine/Documents/SC_VINE_PRD.doc
- Process Impact, https://www.processimpact.com/process_assets/srs_template.doc
- MS Forum, https://www.msforum.org/interoperability/GMI_2006_PRD.pdf