Volere Requirements Specification Template

Feb 27, 2019 Libor Buš news share

We are introducing Volere Requirements Specification Template to be used as a basis for discovering and communicating requirements of today’s software systems.

Volere

Volere is the result of many years of practice, consulting, and research in requirements engineering and business analysis of Atlantic Systems Guild Ltd. The Volere web site contains articles about the Volere techniques, experiences of Volere users and case studies, and other information useful to requirements practitioners.

Mastering the Requirements Process—Third Edition Book by by Suzanne and James Robertson

The Volere requirements process is described in the excellent book Mastering the Requirements Process by Suzanne and James Robertson.

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 the Volere web site. In-house courses are run on request.

Video course Requirements: the Masterclass on the Volere requirements process is also available.

Volere Project Template

Let us explain in this section the content and structure of Volere Requirements Specification Template (edition 18/2016).

Requirements Types

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.

Testing Requirements

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 Scope (SCOPE), Project Requirements (REQS), Project Issues (ISSUES) and Naming Conventions and Definitions (DEFS), organized into the following sections:

Project Scope

The Purpose of the Project: This section deals with the fundamental reason your client asked you to build a new product. That is, it describes the business problem the client faces and explains how the product is intended to solve the problem.
Stakeholders: This section describes the stakeholders—the people who have an interest in the product. It is worth your while to spend enough time to accurately determine and describe these people as the penalty for not knowing who they are can be very high.
Relevant Facts and Assumptions: This section describes external factors that have an effect on the product but are not covered by other sections in the requirements template. They are not necessarily translated into requirements but might be. Relevant facts alert the developers to conditions and factors that have a bearing on the requirements.
The Scope of the Work: This section determines the boundaries of the business area to be studied and outlines how it fits into its environment.
Business Data Model: This section provides specification of the essential subject matter, business objects, entities, and classes that are germane to the the work that you are investigating. It might take the form of a first-cut class model, an entity-relationship model, or any other kind of data model.
The Scope of the Product: This section describes the scope of the product by means of detailed Product Use Cases.

Project Requirements

Constraints: This section describes constraints on the eventual design of the product.
Functional Requirements: This is a specification for each atomic functional requirement.
Non-functional Requirements: This section describes the non-functional requirements.

Project Issues

Open Issues: Issues that have been raised and do not yet have a conclusion.
Off-the-Shelf Solutions: This section looks at available solutions and summarizes their applicability to the requirements.
New Problems
Tasks: This section highlights the effort required to build the product, the steps needed to buy a solution, the amount of effort to modify and install a ready-made solution, and so on.
Migration to the New Product: This section of the specification is where you identify the tasks necessary for the period of transition to the new product. This section is input to the project planning process.
Risks: This section of the specification contains a list of the most likely and the most serious risks for your project.
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.
User Documentation and Training: This section specifies the user documentation that will be produced as part of the product-building effort. This is not the documentation itself, but a description of what must be produced.
Waiting Room: The waiting room holds requirements that will not, for one reason or another, be part of the initial release of the product.
Ideas for Solutions: Ideas for solutions are obviously not requirements, but it is impossible when gathering requirements not to get ideas for how they might be implemented. You can record each one faithfully in this area, and then hand them over, along with the requirements, to your designer.

Naming Conventions and Definitions

Glossary: A glossary containing the meanings of all names, acronyms, and abbreviations used by the stakeholders. Select names carefully to avoid giving a different, unintended meaning.
Data Dictionary: As you start to defining detailed atomic requirements you define the data inputs and outputs in this formal dictionary.

Template Instructions

ReqView displays instructions for each template section in the Attributes pane on the right:

Instructions for the Volere requirements specification template in ReqView

For each section, the Content, Motivation, Considerations, Examples and Form provide the template user with some guidance for writing each type of requirement.

Requirements Shell

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:

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.

Traceability Configuration

We propose to set up traceability according to the following diagram:

Traceability links in the Volere requirements specification template

Satisfaction Links lead from downstream constraints or requirements to upstream business events, business or product use cases.
Reference Links lead from issues to related business events, business or product use cases, constraints or requirements.
Conflict Links lead from constraints or requirements to conflicting constraints or requirements.
Dependency Links lead from dependent constraints or requirements to related constraints or requirements.

License

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

Volere Example Project

We have adapted a partial example project illustrating how you could use Volere to specify the requirements for a product that controls library loans.