Volere Requirements Specification Template

Extracts and Samples from the Template.
Edition 20
by James & Suzanne Robertson principals of the Atlantic Systems Guild

The Volere Requirements Specification Template has been downloaded in excess of 20,000 times. It has proved to be a valuable resource for organizations worldwide by saving significant time and money for their requirements activities. It does this by providing a rock-solid template and guide to writing appropriate requirements specifications.

What follows is an extract of the full template, intended to give you enough information to familiarize yourself with it, and to provide an overview of the contents of the complete template, which runs to 90 pages.

You can download the complete template upon payment of the usage fee. The fee includes the template (MS Word and PDF versions) and two worked examples of requirements specifications that use the template. The download also includes two Excel spreadsheets – the atomic requirements template stationery and an example of how this is used. The download also includes the Volere Requirements Knowledge Model.

Please note that when you click the ‘Buy Now’ button, you will be redirected to PayPal to make your payment. The payment is made to The Atlantic Systems Guild, you will receive a receipt from PayPal.

Once your payment has been accepted, you will be redirected back to the download page on this site. PLEASE DON’T CLICK, just allow the sequence to continue. Please do not leave the download page until your download is successful.  Please email me if you have any problems.

Proposed usage

Note that academic use is excepted from the payment system. Please see below.


A Volere redistribution licence is available for tools vendors and others who wish to include all or parts of the Volere Template Package in products that they sell. Please contact suzanne@systemsguild.net for details.

This template is intended for use as the foundation for your requirements specifications. The template provides for each of the requirements types appropriate for today’s business, scientific and software systems. It provides a checklist, structure and traceability for your requirements. Once you are in possession of the complete version, you can adapt it to your requirements gathering process and requirements tool. The template is tool independent, and has been successfully used with Yonix, Requisite, DOORS, Caliber RM, IRqA and other popular tools. Most tool vendors we speak with agree that this template can be adopted with their tool.

The template may not be sold, or used for commercial gain or purposes other than as a basis for a requirements specification. Please contact us if you have questions about your usage.

The Volere techniques are described in the book Mastering the Requirements Process by Suzanne Robertson and James Robertson.

Volere is the result of many years of practice, consulting, and research in requirements engineering. We have packaged our experience in the form of a generic requirements process, requirements training, requirements consultancy, requirements audits, a variety of downloadable guides, and this requirements template. We also provide requirements specification-writing services.

This extract shows the sub section headings of each of the main sections of the Volere template. This skeleton is intended to illustrate the content of the template. The complete template contains a further expansion of each of the sub sections including:The complete template contains a further expansion of each of the sub sections including:

  • Content
  • Motivation
  • Examples
  • Considerations
  • Form

We have given some expansions in this extract. Section 11—Usability Requirements shows the fully expanded contents.

The complete Volere Requirements Template contains 80 pages of checklists, examples and guidance. The complete template also comes with two examples of populated requirements templates illustrating the use of the Volere techniques, a copy of the Volere Requirements Knowledge Model and a spreadsheet for defining atomic requirements.

We encourage research and academic use of this template. Due to its popularity in universities and colleges, we do not charge genuine students and lecturers for the template. If you are a genuine educational user, please send an email saying how you intend to use the template. Be brief. Please note that your return email address must be a recognized educational domain such as .edu or ac.uk, etc, or a recognisable German or Scandinavian university. Open University students using Googlemail, please include your student number and course number.

Sample and contents of the template:

1. The Purpose of the Project
2. The Stakeholders
3. Mandated Constraints
4. Naming Conventions and Terminology
5. Relevant Facts and Assumptions
6. The Scope of the Work
7. Business Data Model and Data Dictionary
8. The Scope of the Product
9. Functional Requirements
10. Look and Feel Requirements
11. Usability and Humanity Requirements
12. Performance Requirements
13. Operational and Environmental Requirements
14. Maintainability and Support Requirements
15. Security Requirements
16. Cultural Requirements
17. Compliance Requirements
18. Open Issues
19. Off-the-Shelf Solutions
20. New Problems
21. Tasks
22. Migration to the New Product
23. Risks
24. Costs
25. User Documentation and Training
26. Waiting Room
27. Ideas for Solutions
1. The Purpose of the Project
    • 1a. The User Business or Background of the Project Effort
    • 1b. Goals of the Project

Any reasonable goal must be measurable. This is necessary if you are ever to test whether you have succeeded with the project. The measurement must quantify the advantage gained by the business through doing the project. If the project is worthwhile, there must be some solid business reason for doing it. For example, if the goal of the project is

We want to give immediate and complete response to customers who order our goods online.

you have to ask what advantage that goal brings to the organization. If immediate response will result in more satisfied customers, then the measurement must quantify that satisfaction. For example, you could measure the increase in repeat business (on the basis that a happy customer comes back for more), the increase in customer approval ratings from surveys, the increase in revenue from returning customers, and so on.

Ask whether your goal is a:

    • Service goal: This is measured by quantifying what it does for the customer
    • Revenue goal: quantify how much revenue or revenue growth over what period of time. Alternatively, a revenue goal could be quantified by market share.
    • Legal goal: this is not a quantification, but a way of knowing that the product conforms to a piece of legislation (this could be the law of the land or might be a standard of your industry or organization).

It is crucial to the rest of the development effort that the goal is firmly established, is reasonable, and is measured. It is usually the latter that makes the former possible.

2. The Stakeholders
  • 2a. The Client
  • 2b. The Customer
  • 2c. Other Stakeholders
  • 2d. The Hands-On Users of the Product
  • 2e. Personas
  • 2f. Priorities Assigned to Users
  • 2g. User Participation
  • 2h. Maintenance Users and Service Technicians
3. Mandated Constraints
    • 3a. Solution Constraints

This specifies constraints on the way that the problem must be solved. Describe the mandated technology or solution. You should also explain the reason for using the technology. The constraints are treated as a type of requirement.

  • 3b. Implementation Environment of the Current System
  • 3c. Partner or Collaborative Applications
  • 3d. Off-the-Shelf Software
  • 3e. Anticipated Workplace Environment
  • 3f. Schedule Constraints
  • 3g. Budget Constraints
  • 3h. Enterprise Constraints
4. Naming Conventions and Terminology
    • 4a. Glossary of All Terms, Including Acronyms, Used by Stakeholders involved in the Project

Names are very important. They invoke meanings that, if carefully defined, can save hours of explanations. Attention to names at this stage of the project helps to highlight misunderstandings. The glossary produced during requirements is used and extended throughout the project.

5. Relevant Facts and Assumptions
  • 5a. Relevant Facts
  • 5b. Business Rules
  • 5c. Assumptions
6. The Scope of the Work
  • 6a. The Current Situation
  • 6b. The Context of the Work
  • 6c. Work Partitioning
  • 6d. Specifying a Business Use Case (BUC)
7. Business Data Model and Data Dictionary
  • 7a. Business Data Model
  • 7b. Data Dictionary
8. The Scope of the Product
    • 8a. Product Boundary

A use case diagram identifies the boundaries between the users (actors) and the product you are about to build (this is sometimes called “the system”). You arrive at the product boundary by inspecting each business use case and determining, in conjunction with the appropriate stakeholders, which part of the business use case should be automated (or satisfied by some sort of product) and what part should be done by the user. This task must take into account the abilities of the actors (section 2), the constraints (section 3), the goals of the project (section 1), and your knowledge of both the work and the technology that can make the best contribution to the work.

The use case diagram shows the actors/users outside the product boundary (the rectangle). The product use cases (PUCs) are the ellipses inside the boundary. The numbers link each PUC back to the BUC that it came from (see section 6). The lines denote usage. Note that actors can be either automated or human.

For example:

Derive the PUCs by deciding where the product boundary should be for each business use case (BUC). These decisions are based on your knowledge of the work and the requirements constraints. Note that the PUCs that you come up with must be traceable back to the BUCs. The numbers on the PUC diagram correspond to the BUC numbers on the Business Event List (see section 6).

  • 8b. Product Use Case Table
  • 8c. Individual Product Use Cases (PUC’s)
9. Functional Requirements

Functional requirements are the fundamental or essential subject matter of the product. They describe what the product has to do or what processing actions it is to take.

  • 9a. Functional Requirements

Requirements Shell

Each atomic requirement is made up of a number of attributes. The requirements shell is a guide to writing each atomic functional (section 9) and non-functional requirements (sections 10-17). Here is an example of the content of the shell shown in graphic form. The shell can and should be automated.

10. Look and Feel Requirements

Nonfunctional requirements (sections 10-17) are the properties that the functions must have, such as performance and usability. Do not be deterred by the unfortunate type name (we use it because it is the most common way of referring to these types of requirements)—these requirements are as important as the functional requirements for the product’s success.

  • 10a. Appearance Requirements
  • 10b. Style Requirements
11. Usability and Humanity Requirements

This section is concerned with requirements that make the product usable and ergonomically acceptable to its hands-on users.

    • 11a. Ease of Use Requirements


This section describes your client’s aspirations for how easy it is for the intended users of the product to operate it. The product’s usability is derived from the abilities of the expected users of the product and the complexity of its functionality.

The usability requirements should cover properties such as these:

      • Efficiency of use: How quickly or accurately the user can use the product.
      • Ease of remembering: How much the casual user is expected to remember about using the product.
      • Error rates: For some products it is crucial that the user commits very few, or no, errors.
      • Overall satisfaction in using the product: This is especially important for commercial, interactive products that face a lot of competition. Web sites are a good example.
      • Feedback: How much feedback the user needs to feel confident that the product is actually accurately doing what the user expects. The necessary degree of feedback will be higher for some products (e.g., safety-critical products) than for others.


To guide the product’s designers toward building a product that meets the expectations of its eventual users.


The product shall be easy for 11-year-old children to use.

The product shall help the user to avoid making mistakes.

The product shall make the users want to use it.

The product shall be used by people with no training, and possibly no understanding of English.


Fit Criterion

These examples may seem simplistic, but they do express the intention of the client. To completely specify what is meant by the requirement, you must add a measurement against which it can be tested—that is, a fit criterion. Here are the fit criteria for the preceding examples:

Eighty percent of a test panel of 11-year-old children shall be able to successfully complete [list of tasks] within [specified time].

One month’s use of the product shall result in a total error rate of less than 1 percent.

An anonymous survey shall show that 75 percent of the intended users are regularly using the product after a three-week familiarization period.



Refer to section 3, Users of the Product, to ensure that you have considered the usability requirements from the perspective of all the different types of users.

It may be necessary to have special consulting sessions with your users and your client to determine whether any special usability considerations must be built into the product.

You could also consider consulting a usability laboratory experienced in testing the usability of products that have a project situation (sections 1—7 of this template) similar to yours.


The form that you use to capture and maintain your atomic requirements (functional, non-functional and constraint) depends on the tools that you have available to you. Volere snow cards are often a useful aid to help you in discovering requirements but, due to volume and need to be able to make changes, some kind of automated form is the best way to manage and maintain your atomic requirements.

Common forms for atomic requirements are:

      • A spreadsheet (a sample is included with this template)
      • A database provided with whatever requirements tool/s you have available. There is a wide variety of tools on the market, refer to http://www.volere.co.uk/tools for a list
      • An intranet set up by you to maintain and make accessible the atomic requirements and their attributes
      • A custom built database

Whatever form you use to record and maintain your requirements, it is important to be consistent with your numbering and terminology so that you can check for completeness and respond to change.


    • 11b. Personalization and Internationalization Requirements


This section describes the way in which the product can be altered or configured to take into account the user’s personal preferences or choice of language.

The personalization requirements should cover issues such as the following:

  • Languages, spelling preferences, and language idioms
  • Currencies, including the symbols and decimal conventions
  • Personal configuration options


To ensure that the product’s users do not have to struggle with, or meekly accept, the builder’s cultural conventions.


The product shall retain the buyer’s buying preferences.

The product shall allow the user to select a chosen language.


Consider the country and culture of the potential customers and users of your product. Any out-of-country users will welcome the opportunity to convert to their home spelling and expressions.

By allowing users to customize the way in which they use the product, you give them the opportunity to participate more closely with your organization as well as enjoy their own personal user experience.

You might also consider the configurability of the product. Configurability allows different users to have different functional variations of the product.

    • 11c. Learning Requirements


Requirements specifying how easy it should be to learn to use the product. This learning curve ranges from zero time for products intended for placement in the public domain (e.g., a parking meter or a web site) to a considerable amount of time for complex, highly technical products. (We know of one product where it was necessary for graduate engineers to spend 18 months in a training program before being qualified to use the product.)


To quantify the amount of time that your client feels is allowable before a user can successfully use the product. This requirement guides designers to understand how users will learn the product. For example, designers may build elaborate interactive help facilities into the product, or the product may be packaged with a tutorial. Alternatively, the product may have to be constructed so that all of its functionality is apparent upon first encountering it.


The product shall be easy for an engineer to learn.

A clerk shall be able to be productive within a short time.

The product shall be able to be used by members of the public who will receive no training before using it.

The product shall be used by engineers who will attend five weeks of training before using the product.

Fit Criterion

An engineer shall produce a [specified result] within [specified time] of beginning to use the product, without needing to use the manual.

After receiving [number of hours] training a clerk shall be able to produce [quantity of specified outputs] per [unit of time].

[Agreed percentage] of a test panel shall successfully complete [specified task] within [specified time limit].

The engineers shall achieve [agreed percentage] pass rate from the final examination of the training.


Refer to section 2d, Hands-on Users of the Product, to ensure that you have considered the ease of learning requirements from the perspective of all the different types of users.

    • 11d. Understandability and Politeness Requirements.

This section is concerned with discovering requirements related to concepts and metaphors that are familiar to the intended end users.


This specifies the requirement for the product to be understood by its users. While “usability” refers to ease of use, efficiency, and similar characteristics, “understandability” determines whether the users instinctively know what the product will do for them and how it fits into their view of the world. You can think of understandability as the product being polite to its users and not expecting them to know or learn things that have nothing to do with their business problem.


To avoid forcing users to learn terms and concepts that are part of the product’s internal construction and are not relevant to the users’ world. To make the product more comprehensible and thus more likely to be adopted by its intended users.


The product shall use symbols and words that are naturally understandable by the user community.

The product shall hide the details of its construction from the user.


Refer to section 2d, Hands-on Users of the Product, and consider the world from the point of view of each of the different types of users.

  • 11e. Accessibility Requirements


The requirements for how easy it should be for people with common disabilities to access the product. These disabilities might be related to physical disability or visual, hearing, cognitive, or other abilities.


In many countries it is required that some products be made available to the disabled. In any event, it is self-defeating to exclude this sizable community of potential customers.ExamplesThe product shall be usable by partially sighted users.The product shall conform to the Americans with Disabilities Act.


Some users have disabilities other than the commonly described ones. In addition, some partial disabilities are fairly common. A simple, and not very consequential, example is that approximately 20 percent of males are red-green colorblind.

  • 11f. Convenience Requirements


The requirements for things the product shall do to simplify tasks, and to expedite and make the user/customer’s work easier and smoother.


People have become more and more accustomed to convenience. Unless you provide as much convenience as possible, your users / customers will shun your product. Given the technology we have available, there are more and more opportunities for the products we build to do some of the work that the user/customer used to have to do himself. Products can also do new, convenient things for the customer – often things the customer would not have dreamed of asking for.


The product shall inform the customer of his bank balance every Monday morning using the secure communication channel of the customer’s choice.
The product shall identify the customer without the need for asking security questions. (e.g. using fingerprint or voice recognition software)
The product shall process payment for the taxi journey without the need for customer interaction.


Look at your stakeholder map and stakeholder analysis (2d. 2e.) and consider what would make the product more convenient for a person in that situation? What would it be like to be that person using the product? Often people will not mention convenience requirements because they do not know what is possible. But if the product is inconvenient that is when people complain.

12. Performance Requirements
  • 12a. Speed and Latency Requirements
  • 12b. Safety-Critical Requirements
  • 12c. Precision or Accuracy Requirements
  • 12d. Reliability and Availability Requirements
  • 12e. Robustness or Fault-Tolerance Requirements
  • 12f. Capacity Requirements
  • 12g. Scalability or Extensibility Requirements
  • 12h. Longevity Requirements
13. Operational and Environmental Requirements
  • 13a. Expected Physical Environment
  • 13.b. Wider Environment Requirements
  • 13c. Requirements for Interfacing with Adjacent Systems
  • 13d. Productization Requirements
  • 13e. Release Requirements
  • 13f. Backwards Compatibility Requirements
14. Maintainability and Support Requirements
  • 14a. Maintenance Requirements
  • 14b. Supportability Requirements
  • 14c. Adaptability Requirements
15. Security Requirements
  • 15a. Access Requirements
  • 15b. Integrity Requirements
  • 15c. Privacy Requirements
  • 15d. Audit Requirements
  • 15e. Immunity Requirements
16. Cultural Requirements
  • 16a. Cultural Market Requirements
  • 16b. Cultural Diversity and Inclusion Requirements
17. Compliance Requirements
  • 17a. Legal Compliance Requirements
  • 17b. Standards Compliance Requirements
18. Open Issues

A statement of factors that are uncertain and might make significant difference to the product.

19. Off-the-Shelf Solutions
  • 19a. Ready-Made Products
  • 19b. Reusable Components
  • 19c. Products That Can Be Copied
20. New Problems
  • 20a. Effects on the Current Environment
  • 20b. Effects on the Installed Systems
  • 20c. Potential User Problems
  • 20d. Limitations in the Anticipated Implementation Environment That May Inhibit the New Product
  • 20e. Follow-Up Problems
21. Tasks
  • 21a. Project Planning
  • 21b. Planning of the Development Phases
22. Migration to the New Product
  • 22a. Requirements for Migration to the New Product
  • 22b. Data That Has to Be Modified or Translated for the New System
23. Risks

This section of the specification contains a list of the most likely and the most serious risks for your project. For each risk, include the probability of it becoming a problem and any contingency plans.

24. Costs

The other cost of requirements is the amount of money or effort that you have to spend building them into a product. Once the requirements specification is complete, you can use one of the estimating methods to assess the cost, expressing the result as a monetary amount or time to build.

25. User Documentation and Training
  • 25a. User Documentation Requirements
  • 25b. Training Requirements
26. Waiting Room

The requirements-gathering process often throws up requirements that are beyond the sophistication of, or time allowed for, the current release of the product. This section holds these requirements in waiting. The intention is to avoid stifling the creativity of your users and clients, by using a repository to retain future requirements. You are also managing expectations by making it clear that you take these requirements seriously, although they will not be part of the agreed-upon product.

Many people use the waiting room as a way of planning future versions of the product. Each requirement in the waiting room is tagged with its intended version number. As a requirement progresses closer to implementation, then you can spend more time on it and add details such as the cost and benefit attached to that requirement.

You might also prioritize the contents of your waiting room. “Low-hanging fruit”—requirements that provide a high benefit at a low cost of implementation—are the highest-ranking candidates for the next release. You would also give a high waiting room rank to requirements for which there is a pent-up demand.

27. Ideas for Solutions

When you gather requirements, you focus on finding out what the real requirements are and try to avoid coming up with solutions. However, when creative people start to think about a problem, they always generate ideas about potential solutions. This section of the template is a place to put those ideas so that you do not forget them and so that you can separate them from the real business requirements.

For the complete template there is a usage fee of US $55 for single project use, and US $250 for unlimited use in your organization. Payment to the Atlantic Systems Guild is made through Paypal, who will send you a receipt. Credit and debit cards are accepted.
Once your payment has been accepted, you will be redirected back to the download page on this Volere site. Please don’t click, just allow this sequence to continue, and do not leave the download page until you are certain your download is successful

Proposed usage