Volere Requirements Specification Template

• • 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.

• 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

• • 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

• • 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.

• 5a. Relevant Facts
• 5b. Business Rules
• 5c. Assumptions

• 6a. The Current Situation
• 6b. The Context of the Work
• 6c. Work Partitioning
• 6d. Specifying a Business Use Case (BUC)

• 7a. Business Data Model
• 7b. Data Dictionary

• • 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)

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.

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

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

• • 11a. Ease of Use Requirements

Content

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.

Motivation

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

Examples

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.

 

Considerations

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.

Form

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

Content

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

Motivation

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

Examples

The product shall retain the buyer’s buying preferences.

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

Considerations

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

Content

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.)

Motivation

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.

Examples

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.

Considerations

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.

Content

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.

Motivation

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.

Examples

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.

Considerations

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

Content

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.

Motivation

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.

Considerations

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

Content

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

Motivation

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.

Examples

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.

Considerations

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.

• 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

• 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

• 14a. Maintenance Requirements
• 14b. Supportability Requirements
• 14c. Adaptability Requirements

• 15a. Access Requirements
• 15b. Integrity Requirements
• 15c. Privacy Requirements
• 15d. Audit Requirements
• 15e. Immunity Requirements

• 16a. Cultural Market Requirements
• 16b. Cultural Diversity and Inclusion Requirements

• 17a. Legal Compliance Requirements
• 17b. Standards Compliance Requirements

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

• 19a. Ready-Made Products
• 19b. Reusable Components
• 19c. Products That Can Be Copied

• 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

• 21a. Project Planning
• 21b. Planning of the Development Phases

• 22a. Requirements for Migration to the New Product
• 22b. Data That Has to Be Modified or Translated for the New System

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.

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.

• 25a. User Documentation Requirements
• 25b. Training Requirements

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.

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.