Analyzing Project Requirements with Volere Specification Template

This document provides a detailed overview of the Volere Requirements Specification Template, a tool designed for discovering and communicating project requirements. It outlines the template's structure, which includes sections for various requirement types relevant to modern software systems. The template is process-independent, suitable for Agile, Traditional, and Outsourced projects, and compatible with various automated tools. The document covers key areas such as project purpose, stakeholders, constraints, naming conventions, relevant facts and assumptions, scope of work and product, functional and non-functional requirements, and project issues. It emphasizes the importance of testable requirements with fit criteria and includes a requirements shell for writing atomic requirements. The template serves as a basis for effectively organizing and communicating project needs, improving project management, and ensuring better alignment with stakeholder expectations. Desklib offers a wide range of study resources, including similar reports and solved assignments to support students in their academic endeavors.

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

Video course on the Volere requirements process:
Requirements the Masterclass is available at
http://www.informit.com/store/requirements-the-
masterclass-livelessons-traditional-9780134189758
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
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /7

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

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