Requirements Specification Template

[Pages:62]Volere

Requirements Specification Template

Edition 13--August 2007

by James & Suzanne Robertson principals of the Atlantic Systems Guild

The Volere Requirements Specification Template is intended for use as a basis for your requirements specifications. The template provides sections for each of the requirements types appropriate to today's software systems. You may download a pdf version from the Volere site and adapt it to your requirements gathering process and requirements tool. The Volere site also has a Word RTF version. The template can be used with Requisite, DOORS, Caliber RM, IRqA and other popular tools.

The template may not be sold, or used for commercial gain or purposes other as a basis for a requirements specification without prior written permission. We encourage you to see the donation notice. The Template may be modified or copied and used for your requirements work, provided you include the following copyright notice in any document that uses any part of this template:

We acknowledge that this document uses material from the Volere Requirements Specification Template, copyright ? 1995 ? 2007 the Atlantic Systems Guild Limited.

Contents

Project Drivers 1. The Purpose of the Project 2. The Client, the Customer, and Other Stakeholders 3. Users of the Product

Project Constraints 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions

Functional Requirements 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements

Nonfunctional 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 and Political Requirements 17. Legal Requirements

Project Issues 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

Copyright ? the Atlantic Systems Guild Limited

Volere Template /2

Fair Use and Donating

The first edition of the Volere Requirements Specification Template was released in 1995. Since then, organizations from all over the world (see experiences of Volere users at volere.co.uk) have saved time and money by using the template as the basis for discovering, organizing, and communicating their requirements.

Please be aware this template is copyright ? The Atlantic Systems Guild Limited, and is intended to form the basis of your requirements specification. It may not be sold or used for commercial gain or other purposes without prior written permission. Please include the copyright notice in all uses.

Updates to this template are posted on our web sites at and volere.co.uk.

The Volere requirements process is described in the book Mastering the Requirements Process--Second Edition by Suzanne Robertson and James Robertson, Addison-Wesley, 2006. ISBN 0-321-41949-9

You may download the template, try it and decide whether or not it's right for your project. If you use it, we ask that you make a donation for each project using it -- Euro 40, USD50, GBP30 AUD70 or the equivalent -- to entitle your project to continue using the template. Academic institutions and students are exempt from this arrangement, but by no means discouraged from donating. Your donations pay for improving and upgrading the template.

You can make a donation by sending a cheque (or check if you prefer) to:

The Atlantic Systems Guild Limited 11 St Mary's Terrace London W2 1SU United Kingdom

or in the United States to:

The Atlantic Systems Guild Inc. 353 West 12th Street New York NY 10014 United States

Copyright ? the Atlantic Systems Guild Limited

Volere Template /3

Volere

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.

Public seminars on Volere are run on a regular basis in Europe, the United States, Australia, and New Zealand. For a schedule of courses, refer to .

Requirements Types

For ease of use, we have found it convenient to think of requirements as belonging to a type. 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.

Nonfunctional requirements 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.

Project constraints are restrictions on the product due to the budget or the time available to build the product.

Design constraints impose restrictions on how the product must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.

Project drivers are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders--each for different reasons.

Project issues define the conditions under which the project will be done. Our reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.

Copyright ? the Atlantic Systems Guild Limited

Volere Template /4

Testing Requirements

Start testing requirements as soon as you start writing them. You make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.

Requirements Shell

The requirements shell is a guide to writing each atomic requirement. The components of the shell (also called a "snow card") are discussed fully below. This shell can, and should, be automated.

Copyright ? the Atlantic Systems Guild Limited

Volere Template /5

1. The Purpose of the Project

1a. The User Business or Background of the Project Effort Content

A short description of the business being done, its context, and the situation that triggered the development effort. It should also describe the work that the user intends to do with the delivered product.

Motivation

Without this statement, the project lacks justification and direction. Considerations

You should consider whether the user problem is serious, and whether and why it needs to be solved.

1b. Goals of the Project

Content

This boils down to one sentence, or at most a few sentences, that say why we want this product. Here is where you state the real reason the product is being developed.

Motivation

There is a danger that this purpose may get lost along the way. As the development effort heats up, and as the customer and developers discover more about what is possible, the system could potentially wander away from the original goals as it undergoes construction. This is a bad thing unless there is some deliberate act by the client to change the goals. It may be necessary to appoint a person to be custodian of the goals, but it is probably sufficient to make the goals public and periodically remind the developers of them. It should be mandatory to acknowledge the goals at every review session.

Examples

We want to give immediate and complete response to customers who order our goods over the telephone.

We want to be able to forecast the weather.

Measurement

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

Copyright ? the Atlantic Systems Guild Limited

Volere Template /6

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 over the telephone.

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. 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 Client, the Customer, and Other Stakeholders

2a. The Client Content This item gives the name of the client. It is permissible to have several names, but having more than three negates the point. Motivation The client has the final say on acceptance of the product, and thus must be satisfied with the product as delivered. You can think of the client as the person who makes the investment in the product. Where the product is being developed for in-house consumption, the roles of the client and the customer are often filled by the same person. If you cannot find a name for your client, then perhaps you should not be building the product. Considerations Sometimes, when building a package or a product for external users, the client is the marketing department. In this case, a person from the marketing department must be named as the client.

Copyright ? the Atlantic Systems Guild Limited

Volere Template /7

2b. The Customer

Content

The person intended to buy the product. In the case of in-house development, the client and the customer are often the same person. In the case of development of a mass-market product, this section contains a description of the kind of person who is likely to buy the product.

Motivation

The customer is ultimately responsible for deciding whether to buy the product from the client. The correct requirements can be gathered only if you understand the customer and his aspirations when it comes to using your product.

2c. Other Stakeholders Content The roles and (if possible) names of other people and organizations who are affected by the product, or whose input is needed to build the product. Examples of stakeholders: Sponsor Testers Business analysts Technology experts System designers Marketing experts Legal experts Domain experts Usability experts Representatives of external associations

For a complete checklist, download the stakeholder analysis template at volere.co.uk.

For each type of stakeholder, provide the following information: Stakeholder identification (some combination of role/job title, person name, and organization name) Knowledge needed by the project

Copyright ? the Atlantic Systems Guild Limited

Volere Template /8

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download