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

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 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.
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /13
Owners
Sales
Department
Production
Department
IT
Department

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
● Designers and developers
● Testers
● Systems engineers
● Software engineers
● Technology experts
● System designers
Failure to recognize stakeholders results in missing
requirements.
Stakeholder map:
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /14

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

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

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

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

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

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.
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 /20

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 /21

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 /22

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

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:
 Classes/Things on the business data model
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /24

 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+goodsPrice
Supplier suplierID+supplierName+supplierAddressquantityOr
Retailer retailerName+retailerAddress
Customer customerId+customerName+customerAddress+paym
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /25

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

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
PUC
No
PUC Name Actors/Users Input &
Output
1 Record
Weather
Station
Readings
Weather
Station
Weather
Station
Readings
(in)
2 Record
Weather
Forecast
Highways
Department
Clerk
District
Weather
Forecast
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /27

(in)
3 Record
Roads
Road
Engineering
Computer
Changed
Road (in)
4 Record New
Weather
Station
Road
Engineering
Computer
New
Weather
Station
(in)
5 Record
Changed
Weather
Station
Road
Engineering
Computer
Changed
Weather
Station
(in)
6 Identify
Faulty
Weather
Stations
Truck Depot
Engineer
Failed
Weather
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
Schedule
(out)
Thermal
Maps (in)
9 Record
Treated
Roads
Truck Depot
Engineer
Treated
Road (in)
10 Amend De-
icing
Schedule
Truck Depot
Engineer
De-icing
Schedule
Change
(in)
Amended
De-icing
Schedule
(out)
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /28

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

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 /30
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

Considerations
The use case for the online retail management system are
as below:
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /31

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 /32
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 /33

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

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.
13. Operational and Environmental Requirements
13a. Expected Physical Environment
Copyright © the Atlantic Systems Guild Limited
Volere Template V18 /35

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

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

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

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

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

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.
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 /41