The following template can be used when building your product requirements. It will help you to develop an outline of what should be built by your engineers.
Ensure that you read the article, Creating product requirements, before using this template to understand the background of each section.
Sample product requirements template
|1. User persona1||Sally|
|2. Problem you are trying to solve2||When Sally makes bagels for breakfast, she has a difficult time cutting the slices evenly to fit into her toaster. This results in uneven toasting, and occasionally cut fingers when the knife slips during slicing.|
|3. Specific requirements3||Sally should be able to cut and toast her bagels without injury.Sally should be able to have evenly toasted bagels.|
|4. Technical requirements4||The product must be able to work with a standard North American power supply.|
|5. User stories5||Sally’s bagel is cut in half.Sally selects how dark she’d like to toast her bagel.Sally is notified that her bagel toasting is complete.|
|6. Dependencies6||An even toasting mechanism is required.|
1User persona: Refer to the user persona for whom you are building the solution.
2Problem you are trying to solve: Outline a scenario of the problem that the user is experiencing or the pain you are trying to solve. Do not try to solve the problem in this section.
3Specific requirements: These requirements will outline what the solution should achieve for the user.
This example clearly describes the “what, not how” guideline (for more information, read the article, Creating product requirements). It enables you to solve this solution in several ways (for example, purchase a bagel slicer, use a wide-slotted toaster, create pre-sliced bagels). By describing the problem as a problem, and not including a solution, you encourage the engineers to think creatively.
4Technical requirements: Technical requirements might be required as part of your overall requirements even though they may set certain design constraints for the engineering team (for example, browser support, power wattage). Try to keep these to a minimum.
5User stories: User stories should be put in the context of what the user should be able to do, not how the user can do it (for more information, read the article, Creating product requirements).
6Dependencies: Before they can start, many requirements may require or depend on the prior completion of another requirement. Outlining your dependencies is also key for the process of prioritizing your requirements.
Guidelines for good requirements
Good requirements should possess the following attributes:
- Attainable—they are realistic and practicable
- Complete—they do not require further explanation
- Concise—they must be easy to read, follow and understand
- Consistent—they do not contradict other requirements
- Design-free—they state what must be solved, and not how to solve the problem
- Necessary—without such requirements, the problem cannot be solved
- Unambiguous—they can only be interpreted in one way
Do not use the following words in your requirements, as they are difficult to interpret and their meanings will vary from person to person:
For more information on product requirements, refer to the other five articles in this series:
- Creating product requirements
- Validating product requirements
- Prioritizing product requirements
- Understanding the cost of product requirements
- Determining the product release
Date, C. J. (2000). What Not How: The Business Rules Approach to Application Development. Upper Saddle River, New Jersey: Addison-Wesley Professional.
Wiegers, K. (2003). Software Requirements (2nd ed.). Microsoft Press.
Wiegers, K. E. (2000). Karl Wiegers Describes 10 Requirements Traps to Avoid. Retrieved July 19, 2010, from http://www.processimpact.com/articles/reqtraps.html