Volere Requirements Specification Template

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.

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

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.
2a. The Client
Client are basically referred to the people who are
associated with the retail store and aims at achieving
the goal.
The product is being developed based on the
requirement provided by the client. This will ensure
that proper service is provided to the client.
While developing a product it becomes necessary to
understand the external requirement so that it can be
developed properly. The sales department is basically
the client in this case.
2b. The Customer
The customer of retail management system is
associated with the product and aims of having an
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /13
Owners
Sales
Department
Production
Department
IT
Department

effective product. Sometimes the client and customer
are the same persons.
The customer is ultimately responsible for deciding
whether to buy or recommend the use of the product.
The correct requirements can be discovered only if you
understand the customer and his aspirations when it
comes to using your product.
A list of the decisions for which the customer will be
responsible.
You can also include a chart showing the review
checkpoints and itemizing what you will provide for the
customer as progress indicators for the project. This
might include a list of possible prototypes or
simulations that you will provide for the customer
during the progress of the project.
2c. Other Stakeholders
The roles and (if possible) names of other people and
organizations who are affected by the product, or
whose input is needed to build the product. These
stakeholders might work for your organization or
might be external.
Examples of stakeholders:
● Owner
● Customer
● Retail expert
● Sales department
● Users of a current system
● Marketing experts
● Management team
● Domain experts
● Usability experts
● Representatives of external associations
● accounting team
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /14

● Designers and developers
● Testers
● Systems engineers
● Software engineers
● Technology experts
● System designers
Failure to recognize stakeholders results in missing
requirements.
Stakeholder map:
2d. The Hands-On Users of the Product
The customers would be able to use the system for
ordering the clothes on the product.
2e. Personas
Persona…. As a customer he is going to access he
online store and details regarding the products. This
will ensure that they can have proper access over the
products. In addition to this he will be able to identify
the product details and the payment they needed to be
made.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /15
External
Executiv
e
Internal
Executiv
e
External
Operatio
ns
Internal
Operatio
ns
Owner
Sponsor
Management
Finance
Sales Team
Board of
Directors
Project
manager
Project team
Analyst
Staffs
Customers

Personas…. As a customer he will be able to access the
product details and will be able to order the products.
Personas…. As a sales manager he will be able to
check the packaging details and stock details
2f. Priorities Assigned to Users
● Key users: the key users of the system are the
management team and the customers.
● Secondary users: the backend office users.
● Unimportant users: this includes the staffs related
to faculty that aims at maintaining the system.
The percentage of the type of user is intended to assess
the amount of consideration given to each category of
user.
2g. User Participation
The regular customers would be provided with the
initial prototypes that would be able to provide
feedback on the developed prototype.
2h. Maintenance Users and Service Technicians
The maintenance users are the ones that would be able
to perform the maintenance services on the already
implemented website for the organization.
3. Constraints
This section describes constraints on the eventual design of
the product.
Constraints are global—they are factors that apply to the
entire product. The product must be built within the stated
constraints. Often you know about the constraints, or they
are mandated before the project gets under way. They are
probably determined by management and are worth
considering carefully—they restrict what you can do and so
shape the product. Constraints, like other types of
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /16

requirements have a description, rationale, and fit criterion,
and generally are written in the same format as functional
and non-functional requirements.
3a. Solution Constraints
The data storage would be one of the constraint of the
system. Each of the product in the system should be
having a specific identity that would be having the
description of the other factors in the product.
3b. Implementation Environment of the Current System
Content
The environment of the retail management system is
online. This is going to be developed on online platform
and will store all the details regarding product that are
stored within the organization. This will be accessed by
every customer and by the management team.
3c. Partner or Collaborative Applications
The project should be able to collaborate with the
local spreadsheets used by the organization and also
connect to the central data storage systems of the
organization.
3d. Off-the-Shelf Software
The software would be implemented in the sales
department and would be associated with the functions
of the sales department only.
3e. Anticipated Workplace Environment
The workplace would have a different environment to
that of the previous situation.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /17

3f. Schedule Constraints
The system would require around 3 months time to
develop the whole project.
3g. Partner or Collaborative Applications
Content
The system is a retail management system. These
includes product details, however the sales profit does
not affect product or the working of the retail
management system.
Motivation
The retail management system will help in overcoming
the problems and challenges faced with offline retail
system. This also includes managing the system
effectively so that it can manage the challenges.
3h. Enterprise Constraints
Content
The requirement includes an effective interphase that
will provide better support towards the system.
4. Naming Conventions and Terminology
It has been our experience that all projects have their own
unique vocabulary usually containing a variety of acronyms
and abbreviations. Failure to understand this project-
specific nomenclature correctly inevitably leads to
misunderstandings, hours of lost time, miscommunication
between team members, and ultimately poor-quality
specifications.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /18

4a. Glossary of All Terms, Including Acronyms, Used by
Stakeholders Involved in the Project
Content
Retail: the sale of goods to the public in relatively small
quantities for use or consumption rather than for
resale.
Management: the process of dealing with or controlling
things or people.
System: A system is a collection of elements or
components that are organized for a common purpose.
5. Relevant Facts and Assumptions
Relevant facts are 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.
5a. Relevant Facts
Content
The factors that will affect the online retail
management system are the development team, the
product details and the retail department.
5b. Business Rules
Content
The business rule that are follow includes proper use of
the online site, managing all the feedbacks processed
by customers and providing proper feedback.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /19

Motivation
Each customer should be provided with proper service
effectively and within 1 hour of time. The refunds
should be processed within 24 hours.
Form
The main business rule is to provide effective way of
managing the functions so that it can ensure proper
functioning. Moreover customer service needs to be
enhanced so that it can attract more customers.
5c. Assumptions
Content
It is expected that the system will provide a better
facility towards the customers and the retail
management system.
Considerations
The tool offers a better statement towards the facility.
It also ensures that retail management system will
provide a better facility towards the
6. The Scope of the Work
The scope of the work determines the boundaries of the
business area to be studied and outlines how it fits into its
environment. Once you understand the work and its
constraints, you can establish the scope of the product see
Section 8 of the template.
6a. The Current Situation
Content
The existing business process included managing the
stock and retail system offline.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /20

6b. The Context of the Work
Content
The boundary related to retail management system is
that it includes viewing the products by their customer,
selecting a certain product, providing customer
feedback and adding items to the cart.
Motivation
The developed site will allow the customer to view all
the products and will be able to select product as per
their need.
Considerations
The context diagram includes customer, goods and
supplier.
Form
The diagram will help in understanding the
requirements and will also ensure better development
of the project.
6c. Work Partitioning
Content
The events that are taking place within the system
includes:
Logging into the system
Selecting the product
Choosing the size
Adding the item to cart
Providing feedback
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /21

Motivation
The business event aims at providing ease of work
that will help at the time of using the website. The
developed website will help in choosing the
products.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /22

Considerations
The online site will provide the customer with proper
satisfaction and will ensure that the products are
selected properly.
Form
The main input for website includes logging in and
providing the customer details that includes name.
6d. Specifying a Business Use Case (BUC)
Content
The business use case for retail management system
will ensure that proper benefit is achieved. The BUC
will include different fragments.
Motivation
BUC will include retail management system
components. This components includes the information
regarding each product along with price.
Form
The activity diagram includes the main activity that are
checking the logging credentials and selecting the
products. After this the products are processed to the
cart.
7. Business Data Model and Data Dictionary
7a. Business Data Model
UML diagram
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /23

Considerations
ER diagram
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /24

Form
There are many different types of data models that you
can use to model the business data. The ones you are
most likely to come across are:
• UML class model
• Entity Relationship diagrams
7b. Data Dictionary
Content
The data dictionary specifies the content of:
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /25

 Classes/Things on the business data model
 Attributes of the classes
 Relationships between the classes
 Inputs and Outputs on all models
 Elements of data within the Inputs and Outputs
When implementation decisions are made the technical
specifications for the interfaces should be added to the
dictionary.
Name Content
Goods goodsId+goodsName+goodsQuantity+goodsP
Suppli
er
suplierID+supplierName+supplierAddressqu
+orderId+amount
Retaile
r
retailerName+retailerAddress
Custo
mer
customerId+customerName+customerAddres
Mode
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /26

8. The Scope of the Product
8a. Product Boundary
Use Case Diagram
Product Scope Diagram
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /27

8b. Product Use Case Table
The product scope diagram is a useful summary of all
the interfaces between the product and other
automated systems, organizations and users. If there
are a manageable number of PUC’s – say less than
twenty – then the PUC diagram is useful as a graphical
way of summarizing the PUC’s relevant to the product.
But in practice we have found that a Product Use Case
Table is more useful because it can handle larger
numbers of PUCs and it precisely identifies the input
and output data that defines the boundary of each PUC.
Product Use Case (PUC) Summary Table
PU
C
No
PUC Name Actors/
Users
Input &
Output
1 Record
Weather
Station
Readings
Weather
Station
Weathe
r
Station
Readin
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /28

gs (in)
2 Record
Weather
Forecast
Highways
Departme
nt Clerk
District
Weathe
r
Forecas
t (in)
3 Record
Roads
Road
Engineeri
ng
Computer
Change
d Road
(in)
4 Record New
Weather
Station
Road
Engineeri
ng
Computer
New
Weathe
r
Station
(in)
5 Record
Changed
Weather
Station
Road
Engineeri
ng
Computer
Change
d
Weathe
r
Station
(in)
6 Identify
Faulty
Weather
Stations
Truck
Depot
Engineer
Failed
Weathe
r
Station
Alert
(out)
7 Record
Truck
Changes
Truck
Depot
Engineer
Truck
Change
(in)
8 Produce De-
icing
Schedule
Truck
Depot
Engineer
Thermal
Mapping
Database
De-
icing
Schedul
e (out)
Therma
l Maps
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /29

(in)
9 Record
Treated
Roads
Truck
Depot
Engineer
Treated
Road
(in)
10 Amend De-
icing
Schedule
Truck
Depot
Engineer
De-
icing
Schedul
e
Change
(in)
Amende
d De-
icing
Schedul
e (out)
11 Monitor
Untreated
Roads
Truck
Depot
Engineer
Roads
in
Danger
(out)
8c. Individual Product Use Cases
This is where you define the details about the
individual product use cases PUCs listed on your PUC
table. You can include a scenario or model, for each
product use case on your list. Also jot down your
design rationale for choosing this particular PUC, this
will save you and others a great deal of time if you
need to make changes later or explain the design to
someone else.
Form
• A text scenario
• A storyboard
• A low fi prototype
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /30

• A hi fi prototype
• A formal use case specification including exceptions
and alternatives
• A sequence diagram, activity diagram, dataflow
diagram, or any other type of model that is familiar to
your project group
• One or more stories
If you are working with stories then, instead of a PUC
you would write a functional story
You can assess how well you understand the PUC by
attempting to write its fit criterion. To do this ask
yourself: what would I test to assess whether the
product has carried out the intention of this PUC.
9. Functional Requirements
9a. Functional Requirements
Content
This is a specification for each atomic functional
requirement. As for all types of atomic requirements
(functional, non-functional, constraint), use the
requirements shell as a guide for which attributes
should be specified. A full explanation of the atomic
requirement and its attributes is included in this
template’s introductory material.
Motivation
To specify the detailed functional requirements to be
carried out by the product.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /31

Considerations
The use case for the online retail management
system are as below:
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /32
Requirement: 10
Description: All products are delivered on time
Rationale: To be able to give orders, view the
product, select the product and can provide
their address
Originator:<please fill>
Customer satisfaction: 5
Dissatisfaction: 2

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

Non-functional Requirements
10. Look and Feel Requirements
10a. Appearance Requirements
The products shall be attractive to all the customers
The product shall be delivered on time.
It is very much important to understand the requirements of the
customers.
10b. Style Requirements
Requirements that specify the style and the quality of
the product, which influences the way a potential
customer will see the product.
The appearance of the package must be attractive so
that the customers become satisfied. The package may
have some requirements as to its attractive colour and
name printed upon it.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /34
Requirement: 10
Description: Non-functional requirements
Rationale: Availability, flexibility and security
Originator:<please fill>
Customer satisfaction: 5
Dissatisfaction: 2

Motivation
All customers’ demands for a right time delivery of
products along with a proper quality of them. All
the functional requirements are to be satisfied.
The products must be authoritative.
Fit Criterion
After the first encounter with the products, about 70 per cent of the
customers shall agree they feel they can trust the product of the online retail
company.
11. Usability and Humanity Requirements
This section is concerned with requirements that make the
product usable and ergonomically acceptable to its hands-on
users.
11a. Ease of Use Requirements
The usability requirements should cover properties
such as these:
● Efficiency of use: The customers can order for the
products with an ease and gets delivered on time.
● Error rates: There must be no defects in the
products of the company and hence rate of error
must be low.
● Overall satisfaction in using the product: The
satisfaction level of the customers must be high.
● Feedback: Users must provide their feedbacks so
that if any improvements are needed can be
made.
11b. Personalization and Internationalization Requirements
The preferences of the customers as per their needs must be
available.
Any out of the country users must feel free in ordering any kinds of
products.
All details of the customers are to be taken and must be kept secure.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /35

11c. Learning Requirements
The website of the online retail company must be
attractive so that there is an increase in the
number of customers. All the functional
requirements are to be satisfied to a very high
level. Products must be delivered on time and the
quality of them must be good.
11d. Understandability and Politeness Requirements
Understandability is very much important as per
the orders are concerned. The products must be of
good quality and when they will be delivered, the
cover packet of the product must comprise of the
name of the customer and the specification of the
product along with the price.
11e. Accessibility Requirements
The products must be accessible for the customers
who ordered for it. There must be rare dispute
case in the delivery of any product
11f. Convenience Requirements
There must be options for both online payment as
well as home delivery.
12. Performance Requirements
12a. Speed and Latency Requirements
All the products must be delivered at a very small
interval of time. The maximum duration for long
distance delivery must be not more than 4days.
High speed delivery should be maintained by the
online retail company.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /36

12b. Safety-Critical Requirements
There must not be any kind of products belonging
to any kinds of fake brands. No products must be
of bad quality. All the personal information
provided by the customers must be kept secure by
the respective company.
12c. Precision or Accuracy Requirements
Accuracy, whether in the quality of any product or
for delivery time, must be maintained.
12d. Reliability and Availability Requirements
The service of the online retail company must be
such that the reliability level of the customers
increase to a huge extent.
12e. Robustness or Fault-Tolerance Requirements
Robustness must be maintained by managing in
any kinds of faulty cases. For example: Refund
must be done on time if any damaged product is
received by the customers.
12f. Capacity Requirements
Even if there is a presence of huge number of
customers, the company must try to manage their
service in such way that each and every customers
get satisfied by their service.
12g. Scalability or Extensibility Requirements
The scalability or rather the extensibility of the
company must be high for dealing with other
rivalries.
12h. Longevity Requirements
The longevity of the company can only be
maintained by the quality of the service.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /37

13. Operational and Environmental Requirements
13a. Expected Physical Environment
Products must be packaged properly and the
quality of the products delivered must be of good
quality.
13b. Wider Environment Requirements
The website must be accessible through all devices
including desktops, mobile phones and tablets.
13c. Release Requirements
There must be a release of new products on a
regular basis for attracting a large number of
customers each an d every day.
13d. Backwards Compatibility Requirements
If any kinds of backwardness are faced anytime,
the site must be capable of being compatible on
those situations.
14. Maintainability and Support Requirements
14a. Maintenance Requirements
Maintenance is considered as one of the most
essential requirements. The site must be secure
and prevent its customers from losing everything
by keeping a schedule for backup. All the
information must be updated.
14b. Supportability Requirements
The software must be capable of supporting its
customers with a variety of products and with the
high efficiency of its service.
14c. Adaptability Requirements
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /38

The site must be able to run on all kinds of
devices, making it accessible for all. These devices
may be a desktop, tablet or any cellphone.
15. Security Requirements
15a. Access Requirements
The site must be accessible fully by the Admin
only. Others have their individual login id and
password for progressing with the service.
15b. Integrity Requirements
A centralised database is maintained in the cloud
and this is updated timely.
15c. Privacy Requirements
All the personal information of the customers
which are stored are kept secure.
15d. Audit Requirements
A review of the site must be done annually and
improvements are to be made if any are needed.
16. Cultural Requirements
16a. Cultural Requirements
The site must comprise of a large number of
products irrespective of any caste or religion.
17. Compliance Requirements
17a. Legal Compliance Requirements
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /39

Starting an online websites needs to provide legal
documentation and the contracts for the business. VAT
registration is required for starting a proprietary
transaction that is based that online website. The
opinion of the lawyer is to be taken that the product
does not break any laws. There are no other copyright
or other intellectual property that are to be protected.
There are no pending legislations.
17b. Standards Compliance Requirements
Aims to manage the quality of the webpage. The
insurance standards should be met. The company has
code of practice and watchdogs for meeting the
standards.
Project Issues
The online payment portal is not there.
18. Open Issues
There is no scope for the online payment. The resolution is
to make way for the online payment.
Solutions
The solution is that the mode of payment is cash on delivery
(COD).
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /40

19a. Ready-Made Products
The product can be used but the pattern and print
cannot be copied from others.
19b. Reusable Components
Content
Description of the candidate components, either
bought from outside or built by your company, which
could be used by this project. List libraries that could
be a source of components.
Motivation
Reuse rather than reinvention.
19c. Products That Can Be Copied
The online payment portal can be bought from some
other online shopping site and reuse it rather than
creating one.
20. New Problems
20a. Effects on the Current Environment
The software should not disobey any legal terms and
conditions. The online payment portal need to be
implemented.
20b. Effects on the Installed Systems
The new system will allow the customers to view the
products from their homes and order the products.
20c. Potential User Problems
The main problem that is faced by the user is the
online payment. It is not present.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /41

20d. Limitations in the Anticipated Implementation
Environment That May Inhibit the New Product
The potential problems with the implemented system is
that it does not have online payment method.
20e. Follow-Up Problems
Content
Identification of situations that we might not be able to
cope with. The demand for the product will be done
which was not available before.
21. Tasks
The product design is made, the design is implemented, if
there are any problems they are sorted by buying the
solutions.
21a. Project Planning
In this part the project is planned, that how the project
will be implemented
21b. Planning of the Development Phases
This part will consist of the steps taken for the
development of the project.
22. Migration to the New Product
The implementation of this new product should be done so
that the customers can view the products from their home.
22a. Requirements for Migration to the New Product
The implemented system should be well maintained
and allow the user to access the system easily.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /42

22b. Data That Has to Be Modified or Translated for the New
Product
The products should be available online for the
customers to view.
23. Risks
The main risk for the system are fake reviews for the sites,
lack of full cost disclosure and counterfeit goods.
24. Costs
The average cost for the development of the webpage is
$10000.
25. User Documentation and Training
The user is trained on a personal level, therefore the
utilization of the system can be trained to the user in a more
effective and faster manner.
‘25a. User Documentation Requirements
The URD can help to plan the timetable, cost,
milestones and testing. The explicit nature of the URD
allows the user to show it to various stakeholders to
make sure all required features are defined.
25b. Training Requirements
The training of the user is the most important factor
when the deployment of the new technology is done
26. Waiting Room
The online payment portal of the website will be present in
the waiting room.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /43

27. Ideas for Solutions
The best idea for the problem to be solved in that the
solution can be bought from some other online
shopping site and can be implemented on the system.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /44