Volere Requirements Specification Template: A Detailed Analysis Report

This document provides a comprehensive analysis of the Volere Requirements Specification Template, a widely recognized framework for defining and managing software requirements. The report delves into the template's structure, covering key sections such as the purpose of the project, stakeholders, constraints, naming conventions, scope, business data models, product scope, functional and non-functional requirements, operational and environmental requirements, maintainability, security, cultural, and compliance requirements. It examines the importance of testing, the atomic requirements shell, and project-related issues. Furthermore, it highlights the template's application in various project contexts, emphasizing the identification of business problems, stakeholder needs, and the specification of both functional and non-functional requirements. The analysis underscores the template's role in facilitating clear communication, fostering collaboration, and ultimately contributing to the success of software development projects. The document also explores the template's practical application through illustrative examples and guidance, enabling users to effectively leverage the template for their requirements work. The report concludes with a discussion of project issues, solutions, risks, and costs, providing a holistic understanding of the requirements engineering process.

Volere
Requirements
Specification Template
Edition 18—2016
by James Robertson & Suzanne Robertson
principals of the Atlantic Systems Guild
The Volere Requirements Specification Template is intended for use
as a basis for discovering and communicating your requirements. The
template provides sections for each of the requirements types
appropriate to today's software systems. You may download the
template from the Volere site and adapt it to your requirements
process and requirements tool. The template is process independent
and can be used by Agile, Traditional, and Outsourced projects. The
template can be used with Requisite, DOORS, Caliber RM, IRqA,
Yonix and any other automated tools you are using see
http://www.volere.co.uk/tools.htm
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
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 – 2016 the
Atlantic Systems Guild Limited.

Volere....................................................................................................................6
Requirements Types...........................................................................................7
Testing Requirements.........................................................................................7
Atomic Requirements Shell................................................................................8
1. The Purpose of the Project...........................................................................10
1a. The User Business or Background of the Project Effort.........................................10
1b. Goals of the Project................................................................................................10
2. The Stakeholders...........................................................................................11
2a. The Client............................................................................................................... 11
2b. The Customer.........................................................................................................12
2c. Other Stakeholders.................................................................................................12
2d. The Hands-On Users of the Product.......................................................................14
2e. Personas................................................................................................................. 14
2f. Priorities Assigned to Users.....................................................................................14
2g. User Participation....................................................................................................15
2h. Maintenance Users and Service Technicians.........................................................15
3. Constraints.....................................................................................................15
3a. Solution Constraints................................................................................................15
3b. Implementation Environment of the Current System..............................................15
3c. Partner or Collaborative Applications......................................................................16
3d. Off-the-Shelf Software............................................................................................16
3e. Anticipated Workplace Environment.......................................................................16
3f. Schedule Constraints...............................................................................................16
3g. Partner or Collaborative Applications......................................................................16
3h. Enterprise Constraints............................................................................................16
4. Naming Conventions and Terminology......................................................17
4a. Glossary of All Terms, Including Acronyms, Used by Stakeholders Involved in the
Project........................................................................................................................... 17
5. Relevant Facts and Assumptions................................................................17
5a. Relevant Facts........................................................................................................17
5b. Business Rules.......................................................................................................17
5c. Assumptions............................................................................................................18
6. The Scope of the Work..................................................................................18
6a. The Current Situation..............................................................................................18
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /2

6b. The Context of the Work.........................................................................................18
6c. Work Partitioning.....................................................................................................19
6d. Specifying a Business Use Case (BUC).................................................................20
7. Business Data Model and Data Dictionary.................................................20
7a. Business Data Model..............................................................................................20
7b. Data Dictionary.......................................................................................................22
8. The Scope of the Product.............................................................................24
8a. Product Boundary...................................................................................................24
8b. Product Use Case Table.........................................................................................25
8c. Individual Product Use Cases.................................................................................27
9. Functional Requirements............................................................................27
9a. Functional Requirements........................................................................................27
Non-functional Requirements..........................................................................30
10. Look and Feel Requirements.....................................................................30
10a. Appearance Requirements...................................................................................30
10b. Style Requirements...............................................................................................30
11. Usability and Humanity Requirements.....................................................31
11a. Ease of Use Requirements...................................................................................31
11b. Personalization and Internationalization Requirements........................................31
11c. Learning Requirements.........................................................................................32
11d. Understandability and Politeness Requirements..................................................32
11e. Accessibility Requirements...................................................................................32
11f. Convenience Requirements...................................................................................32
12. Performance Requirements........................................................................32
12a. Speed and Latency Requirements.......................................................................32
12b. Safety-Critical Requirements................................................................................32
12c. Precision or Accuracy Requirements....................................................................33
12d. Reliability and Availability Requirements..............................................................33
12e. Robustness or Fault-Tolerance Requirements.....................................................33
12f. Capacity Requirements..........................................................................................33
12g. Scalability or Extensibility Requirements..............................................................33
12h. Longevity Requirements.......................................................................................33
13. Operational and Environmental Requirements........................................33
13a. Expected Physical Environment...........................................................................33
13b. Wider Environment Requirements........................................................................33
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /3

13c. Release Requirements..........................................................................................34
13d. Backwards Compatibility Requirements................................................................34
14. Maintainability and Support Requirements..............................................34
14a. Maintenance Requirements..................................................................................34
14b. Supportability Requirements.................................................................................34
14c. Adaptability Requirements....................................................................................34
15. Security Requirements................................................................................34
15a. Access Requirements...........................................................................................34
15b. Integrity Requirements..........................................................................................35
15c. Privacy Requirements...........................................................................................35
15d. Audit Requirements..............................................................................................35
16. Cultural Requirements................................................................................35
16a. Cultural Requirements..........................................................................................35
17. Compliance Requirements.........................................................................35
17a. Legal Compliance Requirements..........................................................................35
17b. Standards Compliance Requirements..................................................................36
Project Issues.....................................................................................................36
18. Open Issues.................................................................................................36
Solutions.............................................................................................................36
19a. Ready-Made Products..........................................................................................36
19b. Reusable Components.........................................................................................36
19c. Products That Can Be Copied..............................................................................36
20. New Problems..............................................................................................37
20a. Effects on the Current Environment......................................................................37
20b. Effects on the Installed Systems...........................................................................37
20c. Potential User Problems.......................................................................................37
20d. Limitations in the Anticipated Implementation Environment That May Inhibit the
New Product.................................................................................................................37
20e. Follow-Up Problems..............................................................................................37
21. Tasks.............................................................................................................37
21a. Project Planning....................................................................................................37
21b. Planning of the Development Phases...................................................................38
22. Migration to the New Product....................................................................38
22a. Requirements for Migration to the New Product...................................................38
22b. Data That Has to Be Modified or Translated for the New Product........................38
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /4

23. Risks..............................................................................................................38
24. Costs.............................................................................................................38
25. User Documentation and Training............................................................38
‘25a. User Documentation Requirements.....................................................................38
25b. Training Requirements..........................................................................................39
26. Waiting Room...............................................................................................39
27. Ideas for Solutions.........................................................................................39
The Volere Requirements Knowledge Model (included with the
download of this template) shows the formal structure of the template
and the cross-references between the components in the above table
of contents.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /5

Volere
Volere is the result of many years of practice, consulting, and
research in requirements engineering and business analysis. 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 articles, a
requirements knowledge model and this requirements template. We
also provide requirements specification-writing services.
The first edition of the Volere Requirements Specification Template
was released in 1995. Since then, organizations from all over the
world have saved time and money by using the template as the basis
for discovering, organizing, and communicating their requirements.
The Volere web site www.volere.co.uk contains articles about the
Volere techniques, experiences of Volere users and case studies,
requirements tools, and other information useful to requirements
practitioners.
The Volere requirements process is described in the book Mastering
the Requirements Process—Third Edition by Suzanne Robertson and
James Robertson, Addison-Wesley, 2012. ISBN 0-321-81574-2
Kindle and Safari editions are also available.
For more about managing requirements see Requirements Led
Project Management by Suzanne Robertson and James Robertson,
Addison-Wesley, 2005. ISBN 0-321-65904-X
Updates to this template and instructions for downloading are
available at http://www.volere.co.uk
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 www.volere.co.uk.
In-house courses are run on request.
Video course on the Volere requirements process: Requirements
the Masterclass is available at
http://www.informit.com/store/requirements-the-masterclass-
livelessons-traditional-9780134189758
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /6

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
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /7

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.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /8

Atomic 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 this 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.
This requirements shell can, and should, be automated. When you
download the template you will also find an Excel spreadsheet
implementation of the snow card. You can also implement it using
whatever requirements tool/s you have available.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /9

Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /10

The following discusses and provides examples for each of the
sections of the Volere Requirements Specification Template. For each
section, the Content, Motivation, Considerations, Examples and
Form provide the template user with some guidance for writing each
type of requirement. When you download the template you will also
find a Template Skeleton that you might find convenient to use as the
basis for producing a document.
1. The Purpose of the Project
The first section of the template 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.
1a. The User Business or Background of the Project Effort
The aim of this project is to develop a website for retail store.
This will help in achieving better benefits. The website for Retail
management will include gaining proper control over all of the
business processes and activities that has the capability to
helps customers. This will ensure that the customer gets
desired products and better service experiences. It is important
for the website to have proper e commerce site along with
analytics software.
The aim behind developing a retail management system is to
ensure better processing of the products. This will provide better
inventory management and will manage the stocks efficiently.
The main reason behind development of online retail
management system is that in offline store it becomes difficult to
manage the inventory and sales part. Moreover dealing with the
customer also becomes difficult with the implementation of this
online retail.
The website for retail management system will ensure
managing all the functions effectively. This will also ensure
better inventory management. Retail management system will
also ensure providing details on current item stock and identify
additional stock required to smoothly operate the business.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /11

1b. Goals of the Project
The main advantage of the developed system is that it will
ensure management of the stocks efficiently. The customer
service will also get improved. The retail store will be able to
manage their tasks efficiently and due to online site it will
become easy to reach maximum number of peoples.
The aim is to provide a better service towards the customer.
The system will ensure effective way of managing the inventory
stock.
The system will also manage the waste that are created by
offline retail section.
The goal is to achieve maximum benefit towards the retail store.
Moreover it is also necessary to provide better customer
services. The goal of this project is a service goal as it aims at
providing better services towards the customer. In addition to
this the goal is also identified as revenue goal as it is concerned
with the amount of revenue earned over years.
Purpose: the aim behind investing on online retail management
system is that it will draw huge profit towards the retail business.
This will also attract maximum number of customers.
Advantage: the benefit is that it will provide easy access
towards the customer.
Measurement: this is measured as an important factor for
improving the buisnes.
The chosen standard for retail strategic management is
Extended Enterprise Modelling Language EEML. This ensures
identifying each component of retails efficiently.
2. The 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.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /12