This section describes our adaptation of Volere Requirements Specification Template (edition 18/2016) to be used as a basis for discovering and communicating requirements of today’s software systems and demonstrates its application on an example Library Loans Project.
Volere is the result of many years of practice, consulting, and research in requirements engineering and business analysis of Atlantic Systems Guild Ltd. For more information and links to useful resources see References.
For ease of use, we have found it convenient to think of requirements as belonging to a type. There are two reasons for the type: as an aid to discovering the requirements and to be able to group the requirements that are relevant to a specific expert specialty. Sometimes you might find it necessary to assign more than one type to a requirement.
Functional Requirements are the fundamental or essential subject matter of the product. They describe what the product has to do, the rules that it has to carry out or what processing actions it must take.
Non-functional Requirements are the properties that the functions must have, such as performance and usability. Do not be deterred by the unfortunate name for this kind of requirements, they are as important as the functional requirements for the product’s success.
Constraints impose restrictions on the chosen solution. These restrictions might apply to the whole project, for example: budget, time, skills. Other constraints relate to the technology to be used like: the product 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 that must be conformed with and cannot be changed.
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 knowledge as input to help to manage a project.
The Volere philosophy is to 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.
Our adaptation of the Volere template consists of four documents — Project Needs (NEEDS), Project Requirements (REQS), Project Issues (ISSUES) and Naming Conventions and Definitions (DEFS), organized into the following sections:
If you create a new project from the Volere Template (see Requirements Projects > Set up Projects > Create Projects) then the application displays detailed guidance about Content, Motivation, Considerations, Examples and Form of each selected section in the Instructions pane:
The requirements shell is a guide to writing each atomic requirement. The components of the shell (also called a “snow card”) are identified below. An atomic requirement is made up of the following collection of attributes:
|Id||id||Unique identifier within the document|
|Heading||heading||Short name of the document section or the requirement|
|Text||text||Intent of the requirement|
|Type||type||Type of the document object (Section, Information, Functional Requirement, Constraint, &dots;)|
|Rationale||rationale||Explanation why the requirement is important and how it contributes to the product's purpose|
|Originator||originator||Name of the person who raised the requirement in the first instance, or the person to whom it can be attributed|
|Fit Criterion||fitCriterion||Quantified goal the solution has to meet (acceptance criterion)|
|Customer Satisfaction||satisfaction||Degree of stakeholder happiness if this requirement is successfully implemented scaling from 1 (uninterested) to 5 (extremely pleased)|
|Customer Dissatisfaction||dissatisfaction||Measure of stakeholder unhappiness if this requirement is not part of the final product scaling from 1 (hardly matters) to 5 (extremely displeased)|
|Priority||priority||Decision on the importance of the requirement's implementation relative to the whole project|
|Supporting Materials||materials||References to other material that is important to the requirement|
You might decide to add some additional attributes to provide traceability necessary for your environment. For example: products that implement this requirement, version of the software that implements this requirement, departments who are interested in this requirement, etc. There are others but do not capriciously add attributes unless they really help you: every attribute you add needs to be maintained.
We propose to set up traceability according to the following diagram:
Check Volere Library Loans Requirements Specification Example illustrating how you could use Volere to specify the requirements for a product that controls library loans.
The Volere template may not be sold, or used for commercial gain or purposes other than as a basis for a requirements specification without prior written permission. The template may be modified or copied and used for your requirements work, provided you include the copyright notice in any document that uses any part of this template.
We acknowledge that this page uses material from the Volere Requirements Specification Template.
Copyright © 1995 – 2019 the Atlantic Systems Guild Limited.