Archive for the ‘ Test Driven Development ’ Category

An Introduction To Volere

This article provides a short description of the Volere requirements specification template. Volere is a well defined structure and process for capturing requirements; Volere offers a detailed guide for each stage of the process. This article is intended to be a first step into Volere not a complete description nor does it attempt to detail each step of the process. There are some much better resources describing the full process including:

The Work

The central concept behind the Volere process is that of work. Essentially the work is the business activity of the product’s customer. The product that is being specified will perform part of this work. To understand the work the context of the work – how the work relates to the outside world – must be understood. Volere suggests the use of a context diagram which shows the work in the centre and everything that affects the work on the outside and arrows showing flows of information between each outside element and the work. Once the customer’s work is understood, the product’s work can be identified and agreed with the customer. The product’s work is obviously subject to constraints such as development time and budget, technological feasibility and the customer’s appetite for risk. Agreeing the product’s work and constraints with the customer prevents the requirement gathering process from elaborating a wish list and takes the first step towards specifying a product.

Use Cases

The information flows between the outside world and the customer’s work are business events. Some of the events will be happen at regular times, e.g. a phone bill arrives and requires paying, others will be triggered by an external actor doing something, for example placing an order on line. Each event becomes a business use case. By examining the business use cases, product use cases can be derived based on the product work and constraints.

Use cases are used to partition the product’s work. Each use case can be analysed with the help of that use case’s stakeholders, the work understood, required data defined and requirements written.

The Process

The Volere process consists of five main stages:

  • project blastoff
  • trawl for requirements
  • write the requirements
  • quality gateway
  • review the specification

The process is not strictly linear: each stage can feed into other stages, the only exception being the project blastoff which starts the process. Each stage emphasises stakeholder involvement and the quality of requirements. The process is iterative: once captured a requirement is not set in stone rather it is considered alongside other requirements for consistency, fit, completeness and viability within the constraints of the project. The major stages of the process are described below.

Project Blastoff

The objective of the blastoff meeting is to agree the intent of the project, it’s scope, risks and constraints with stakeholders and clients. The outputs are project goals, work context model, identified stakeholders, likely developers (external, internal, skills needed), system events, preliminary use cases and scenarios and a system terminology reference. Probably the two most important results of the blastoff are establishing the scope of the product’s work and any constraints. A common constraint on many projects is time: there is little point spending twelve months trawling for requirements if one constraint is that the product itself must hit the market within six months.

Knowledge Trawl

The purpose of this stage is to ‘learn the work’. Some of the ways in which work knowledge can be gathered is to learn about the problem domain, look for requirements from similar projects than can be reused find and read documentation, run creativity workshops, interview users, prototype requirements and run use case workshops. Depending on the size and complexity of the projects not all methods will have to be used. The trawl should add more details to the scenarios and use cases. Non functional and usability as well as functional requirements should be surfaced by the trawl and a business data model and dictionary should be begun.

Write the requirements

The completed requirements specification should contain the purpose of the project; details of the clients, customers, users and stakeholders of the product; constraints; functional requirements including the scope of the work, the scope of the product, the atomic functional requirements, a business data dictionary and a business data model; non functional requirements including look and feels, usability, performance, security and maintainability requirements; project issues including risks, off the shelf solutions, user documentation and training, estimated costs and solution ideas.

Each requirement should be documented using the Volere requirement shell. The requirement should have a unique reference; a specified type (e.g. look and feel, usability, constraint, functional; the template contains the complete list); a use case reference; a description; a rationale; the originator; fit criteria; a measure of customer satisfaction and dissatisfaction; priority and a history of when the requirement was raised, changed and passed through the quality gateway.

Each requirement should be described unambiguously in language that is as easily understood by a developer as by a user or project manager. As well as a description of the requirement there should be a rationale which explains why the requirement is needed and the value the requirement adds to the overall specification. The requirement’s fit criterion explains how the requirement can be tested; the criterion is the unambiguous goal that the requirement has to meet using precise terms and numbers or a measurement. The Volere specification describes the criterion as the requirement – the requirement’s description is just an easier to understand paraphrasing of the criterion. As well as each atomic requirement having a fit criterion, Volere suggests that the project purpose has a fit criterion.

Customer satisfaction and dissatisfaction measures are a way of prioritising each requirement. The customer satisfaction measure scores the requirement based on how satisfied the customer will be if the requirement is part of the final product. Similarly the dissatisfaction measure is a score of how dissatisfied the customer will be if the requirement is not in the final product. Clearly requirements which score low on this measure should be given a high priority for development. The rationale behind using these two measures rather than the ubiquitous “must have, should have, could have” (MuSCo) rating is that asking people their level of satisfaction often yields more information.

Quality gateway

The purpose of the quality gateway is to review each requirement before it gets added to the requirements specification ensuring only complete, high quality, requirements are included within the specification. The first stage of the gateway is to check that each requirement is complete. That is the Volere requirements shell is completely filled in. The shells specifies that a requirement should have

  • An identifier
  • A use case reference
  • A name
  • A description
  • A rationale
  • A fit criterion specified in unambiguous numerical measures
  • A customer satisfaction measure
  • A customer dissatisfaction measurement
  • A priority
  • The name of the originator
  • The requirement’s history

The first thing to be checked is that the requirements is consistent within the defined scope of the product’s work and that the requirement is feasible within the product constraints. Obviously if a requirement is not within the product scope or is not feasible it has no place in the requirements specification.

The fit criterion is the essence of the requirement. By specifying the fit criterion as a numerical measure it can be tested – there is no room for interpretation; if your development team is half way around the world speaking a different language with no domain knowledge the team will still know exactly what needs to be developed.

The dissatisfaction and satisfaction measures specify the value of the requirement. This is often used to decide the release in which a requirement is included. Requirements with a low dissatisfaction are often considered as gold plating: nice to haves but no one really minds if the requirement is not included in the final product.

The gateway checks that consistent terminology is used for all requirements. Clearly if ambiguous language is used the final product will be ambiguous.

Ensuring traceability is significant part of the quality review. The review checks that the requirement is linked to a use case so that the part of the product’s work being specified is traceable and the requirement has a unique identifier to aid traceability of development and testing to individual requirements.

Review specification

The specification review considers the requirements as a whole. As each individual requirement has been through a quality gate only high quality requirements are included in the specification. Therefore reviewing the specification is primarily concerned with identifying missing use cases and use case missing requirements. One method for identifying missing use cases and requirements is to use a low fidelity prototype the product or walk through the product’s functionality with customers and users – it soon becomes apparent if any use cases have been missed.

Reviewing the data used by the product can help to uncover missing use cases. Consider the CRUD – create, read, update and delete – life cycle of data: if there are use cases to update data but no use cases to create the data then it is likely that there are some use cases remaining to be discovered.

As this is the first point all the requirements get considered part of the review should look for conflicting requirements and attempt to resolve any conflicts with the customers.


This document is a very short overview of the Volere process. Indeed, this document is actually shorter than the Volere requirements template. The intention of this document is to give a flavour of the process, as a short cut so that parts of the Volere can used within existing projects.