Example Requirements Documentation
ClassicsCD Web Shop
Vision Statement
Introduction
1.1
Purpose of the Vision Requirements Document (VRD)
The purpose of this document is to collect, analyze and define high-level business requirements, user needs
and features of the ClassicsCD.com Web Shop (CLWS). This system is an application that is available on
the World Wide Web. ClassicsCD.com is intended to provide a new channel of sales for Classics, Inc., to
supplement the existing bricks-and-mortar retail operation.
Rapid growth in the Internet and e-business sectors caused the management team to consider selling
Classical CDs over the Internet. The initial version of the web site and its first revision were successful,
although opportunities for improvement did exist.
The ClassicsCD management staff looked at what they would need to do to expand and meet the
company’s growth targets.
ClassicsCD realized that in order to ensure the success of the new system, they would need to adopt
industry best practices, tools, and processes. They also realized that they would need to look at the entire
business as a whole and not just a single application.
1.2
Product Overview
ClassicsCD.com wants to integrate its Web shop with the corporation’s order processing and fulfillment
system. We envision a smaller scale supply-chain management system which ties the Web application,
along with all the stores, suppliers, and warehouses, together. This includes:
 A Home Shopping e-commerce system.
 A warehouse system
 An order processing system
User Description
1.3
User/Market Demographics
The owners of Classics Inc. are the owners of a chain of retail classical CD music stores. Due to
competition from Internet businesses and the difficulties associated with hiring in a booming economy, the
owners decided to sell Classical CDs over the Web. Their customers are the same people who previously
bought from their retail stores. The goal is to avoid the high costs associated with additional retail
properties.
To build customer loyalty, management has structured ClassicsCD.com as a membership club.
1.4
User Profiles
Visitor — Anyone who has access to a computer and Web browser can visit the ClassicsCD.com Web site.
Member — To purchase CDs at ClassicsCD.com, visitors must become members by providing identifying
and purchasing information such as name, address, and credit card number.
Back Office Administrator — This user is responsible for shipping the orders, verifying payment
information and providing customer service. They also update the Web site to include new selections and
remove old selections.
Administrator — This user maintains the security, queries, backups, and network topology of the system to
make sure that the system keeps running efficiently.
1.5
User Environment
This system is a web-based e-commerce site allowing customers to order ClassicsCD products over the
Internet.
1.6
Key User Needs
Users must be able to:
Find titles quickly and easily for purchase
Place an order quickly
Have their order accepted immediately
Check the status of orders that they have placed.
The Back Office Administrator needs an easy-to-use interface for system maintenance.
1.7
Alternatives and Competition
The alternative to developing this system in-house is to buy a commercially available product.
products on the market today are not customizable enough to support the needs of ClassicsCD.com.
The
Competition comes from Web merchants such as CDNow.com and Amazon.com, and from traditional CD
membership clubs such as Columbia House that now also provide Web ordering.
Product Overview
1.8
Product Perspective
The ClassicsCD.com Web Shop works with the most common web browsers, Netscape Navigator 4.0 or
later and Microsoft Internet Explorer 4.0 or later.
1.9
Product Position Statement
The ClassicsCD.com Web Shop will allow customers easy ordering of Classical CDs at competitive prices.
1.10
Summary of Capabilities
Customer Benefit
1.11
ONLINE CD SHOP
Supporting Features
Easy purchasing of CDs
Use of standard web browser
Competitive prices
Cost-saving benefits of not
requiring a large number of
employees
Access to CD reviews
Drill-down details page for each
CD selection
Large selection
Search mechanism allowing the
user to browse a large number of
titles
Customers do not need to
interact with ClassicsCD.com
employees to place an order
or check on order status
Ability to check on a previous
order and place new orders
Assumptions and Dependencies
ClassicsCD.com Web Shop will run on Internet Explorer and Netscape on all operating systems and
platforms that these browsers support.
Feature Attributes
1.12
Status
A feature’s status is set after negotiation and review by the project management team. Status tracks
progress during definition and implementation of the project.
Value
Proposed
Meaning
Describes features under discussion that have
not yet been reviewed and accepted by the
Product Definition Group (PDG). The PDG is a
working group with representatives from the
project team, product management and the user
or customer communities.
Approved
Incorporated
1.13
Describes capabilities that are deemed useful
and feasible and have been approved for
implementation by the PDG.
Describes features incorporated into the
product implementation at the end of a specific
iteration.
Priority
A feature’s priority is set by marketing, the product manager or the business analyst. The priority attribute
designates the relative importance of implementing a feature. This attribute is used in managing scope and
determining development priority.
Value
1.14
Meaning
Critical
The feature is essential. Failure to implement means the
system will not meet customer needs. All critical features
must be implemented in the release or the schedule will slip.
Important
The feature is important to the effectiveness and efficiency of
the system for most applications. The functionality cannot
easily be provided in some other way. Lack of inclusion of an
important feature may affect customer or user satisfaction, or
even revenue, but release will not be delayed due the absence
of such a feature.
Useful
Feature that is useful in less-typical applications, that will be
used less frequently, or for which reasonably efficient
workarounds can be achieved. No significant revenue or
customer satisfaction impact can be expected if such an item
is not included in a release.
Effort
The development team sets a feature’s effort level. Because some features require more time and resources
than others, estimating the number of team or person-weeks, lines of code required or function points, for
example, is the best way to gauge complexity and set expectations about what can and cannot be
accomplished in a given amount of time. This attribute is used in managing scope and determining
development priority.
1.15
Risk
A feature’s risk level is set by development team and is based on the probability the project will experience
undesirable events, such as cost overruns, schedule delays, or even cancellation. Most project managers
categorize risks as high, medium, and low, although finer gradations are possible. Risk can often be
assessed indirectly by measuring the uncertainty of the project team’s schedule estimate.
1.16
Stability
A feature’s stability is set by the analyst and development team, and is based on the probability that the
feature will change or that the team’s understanding of the feature will change. This attribute is used to help
establish development priorities and determine those items for which additional elicitation is the
appropriate next action.
1.17
Assigned To
A feature’s Assigned To attribute identifies the person on the project team who is responsible for delivering
the feature. On many projects, features are assigned to “feature teams” which are responsible for further
elicitation, writing the software requirements, and implementation.
1.18
Origin
The Origin attribute defines the source of a feature request. Possible values can include customer, tech
support, and development.
Product Features
1.19
ClassicsCD.com Web Shop
Secure Payment method.
Easy Browsing for available titles
Ability to check the status of an order
E-mail notification for customers when new titles are added that may be of interest to them.
Highly Scaleable to include many titles and effective searching through those titles.
Customer should be able to customize the web site
Customer should be able to register as a user for future purchases without needing to re-enter
personal information.
1.20
ClassicsCD Administration System
Ability to add/remove offerings.
Ability to check on customer orders.
Maintain customer information.
Generate reports
Other Product Requirements
1.21
Applicable Standards

1.22
ClassicsCD applications must comply with common web user interface such as Microsoft Internet
Explorer and Netscape.
System Requirements

The web application will be supported on all operating systems that are supported by the chosen
browsers.
Documentation Requirements
1.23
Online Help
The web site will include an interactive guide to the web site in the form of online Help.
Use Case Diagram
Visitor
Browse Catalog
<<extend>>
ClubMember
<<extend>>
Shop for CD
Checkout
Check Order Status
<<extend>>
Arrange Shipment
Warehouse
System
Glossary
Introduction
This document is used to maintain terminology that must be used correctly in the context of the
ClassicsCD.com Web Shop project in order to assure proper communication among the team.
1.24
Purpose
Team members should add any terminology that they feel needs to be used with a high degree of clarity.
1.25
Scope
Terms within this document apply only to the ClassicsCD Web Shopping project and may or may not be
different from terminology used in other projects by Classics Inc.
Definitions
1.26
Administrator
An administrator is defined as an employee of Classics Inc who may be responsible for maintaining the
status of orders, modifying Club Member information among other activities.
1.27
Club Member
The Club Member is described as someone who has a valid CustomerID and password on file with Classics
Inc.
1.28
Catalog
The catalog includes all CDs that are available for sale on the ClassicsCD.com Web site.
1.29
CustomerID
The customerID is used to identify Club Members.
1.30
Shopping Cart
The shopping cart is the generic term for the container of all items that have been selected for purchase.
1.31
Visitor
A visitor is described as anyone who visits the ClassicsCD.com Web site. Club members could also be
considered visitors if they were just browsing the site and did not proceed to the Cashier page.
Supplementary Specification
Introduction
1.32
Purpose
This document details non-functional requirements that apply to the overall ClassicsCD.com projects.
1.33
Scope
This document applies to the ClassicsCD.com Web Shop.
Functionality
All functionality is specified in the use case specifications. See use case specifications for details.
Usability
This section includes all of those requirements that affect usability.
1.34
Interface Ease of Use
The system shall follow standard interface guidelines.
The system shall be user friendly.
The software shall be able to run on Internet Explorer 4.0 and later and Netscape Navigator.
1.35
Training
Training shall be developed for all modules.
Reliability
1.36
Fault Tolerance
The system shall be able to operate in a fault tolerant manner 7 x 24.
The system shall be able to run Internet Explorer 4.0 and later and Netscape Navigator.
1.37
Defects
The number of know defects in the delivered system shall be less than 50.
Performance
The performance characteristics of the system are all outlined in this section.
1.38
Response Time
The response time for any query shall be less than 10 seconds.
Supportability
This section indicates any requirements that will enhance the supportability or maintainability of the
ClassicsCD.com Web Shop system.
1.39
Coding Standards
The system shall be Internet Explorer 4.0 and later and Netscape Navigator compliant as stated in the
Microsoft Internet Explorer and Netscape Navigator compatibility requirements documents.
Use Case Specification: Arrange Shipment
Arrange Shipment
1.40
Brief Description
This use case is an extension of the Checkout use case and generates a report for the warehouse system.
The warehouse system is considered an actor in this use case scenario. The information generated by this
use case should be all of the necessary information needed to place the order and ship the product(s) to the
club member
Flow of Events
1.41
Basic Flow
Upon successful completion of the Checkout use case complete order information will be sent to the
warehouse system.
The Web shopping application sends information in the form of a report that can be parsed electronically
by the warehouse system. The report includes the following information:

Club member name

Club member shipping address

Club member phone number

Product SKU number for each product ordered

Club member ID

Quantity of each product ordered
The warehouse system responds with the estimated shipping date for the product(s) in the user’s shopping
cart.
1.42
Alternate Flows
 Inventory not available
In the case that some, or the entire inventory is not available, the warehouse system provides a message to
the web page stating that the item(s) is (are) out of stock.
Special Requirements
None
Pre-Conditions
A club member must order at least one item and proceed to the Cashier page to complete the checkout
process.
Post-Conditions
None
Extension Points
Arrange Shipment is an extension of the Checkout use case
Use Case Specification: Check Order Status
Check order status
1.43
Brief Description
Registered ClassicsCD.com members can view the status of their order(s) by entering their CustomerID
and Password. They can then read a summary of their orders. From the summary, users can display
details of any order, including what was ordered and the amount. charged for the order.
Flow of Events
1.44
Basic Flow
Request Order Status
 The use case shall start when the user clicks the text, Orders, to check on the status of a
previous order.
Enter CustomerID and Password
 The system shall display a page on which the user enters his or her CustomerID and
Password.
Show Existing Orders
 The system shall display a list of all orders placed by this user; the system sorts the list in
ascending order by the order number.
View Order Details
 To see the details of a specific order, the user clicks on an OrderID.
 On the Order Details page, the user clicks a Title to see details of a particular item. The
item details include:
 Picture of the cover
 CD Title
 Price
 Performer and Orchestra
 Review of the CD
Use Case Completion
The use case ends when the user begins the Browse Catalog use case, or leaves the
ClassicsCD.com site.
1.45
Alternative Flows
User enters an invalid CustomerID and/or Password
If the user enters an invalid CustomerID and/or password, the system displays a
message indicating that the CustomerID/Password combination is not valid.
The user clicks the browser’s Back button to return to the CustomerID/Password entry
page.
Special Requirements
None
Pre-Conditions
The user must have a valid CustomerID/Password combination
Post-Conditions
None
Extension Points
None
Use Case Specification: Shop for CD
Shop for CD
1.46
Brief Description
The user can select and purchase CDs from ClassicsCD
This use case is an extension of the Browse Catalog use case.
Flow of Events
1.47
Basic Flow
Select a CD
The use case starts when the user indicates the desire to buy one or more items by clicking on the
shopping cart icon next to the items.
Items may be added to the shopping cart from the catalog page or any detailed view page.
To place more than 1 of an item in the shopping cart, the user clicks the shopping cart icon for that
item multiple times.
Place Item On List
Each time the user clicks on an item’s shopping cart icon, the system places that item on an
internally-maintained list. The system does not give the user any visual feedback.
View Shopping Cart
The user examines the contents of the shopping cart by clicking on the link text, Shopping Cart.
Proceed to Checkout
The use case ends when the user clicks the link text, Cashier, to complete the purchase.
1.48
Alternative Flows
Remove item from cart
On the shopping cart view page, the user may remove an item from the cart by choosing the
Remove from Cart link next to each selection in the cart.
Special Requirements
None
Here is text for a Parent or Root requirement .
Use this text to create a Child requirement.
Use this text to create a Child requirement of the Child requirement directly above.
Pre-Conditions
The user is in the catalog view or the detailed view when the use case starts.
Post-Conditions
None
Extension Points
This use case is an extension of the Browse for CD use case.
Use Case Specification: Browse Catalog
Browse Catalog
1.49
Brief Description
The user can browse for available CDs and filter the results by composer, composition, and performer
Additional information related to the basic and alternative flows is contained in the activity and sequence
diagrams in the ClassicsCDWorld Rose model.
Flow of Events
1.50
Basic Flow








The use case begins when the user displays the Classics CD homepage
The system presents an option to browse the catalog of CDs
The system also presents a recommended selection of the day.
The user clicks the “catalog” link
The system presents a list of all available CDs
The user looks at the details of a CD by selecting the link to its title
The system displays the following information:
 Picture of the cover
 CD title
 Performer and orchestra
 Review of the CD
This flow terminates when the user goes back to the homepage, chooses another option, or
closes the browser session.
 Search by selected criteria
The user searches through the catalog of all available CDs by first selecting one of the following choices
from a list.
 Composer
 Composition
 Performer
The user enters text into a search field then clicks the Search button.
The system displays a list of CDs that meet the user’s search criteria
Special Requirements
None
Pre-Conditions
This use case must be initiated from the ClassicsCD homepage .
Post-Conditions
None
Extension Points
The Shop for CD use case is an extension of this use case.
Use Case Specification: Checkout
Checkout
1.51
Brief Description
Valid ClassicsCD members have the option to purchase CDs that they have added to their shopping cart.
Flow of Events
1.52
Basic Flow
The user proceeds to the Cashier
The use case starts when the user selects Cashier from the catalog, detailed view, or the shopping cart.
The system requests information to identify the user and the user provides that information.
 The system prompts the user to enter the following information:

Customer ID

Password
The system displays a summary of the current order.
 The system displays a summary of items in the shopping cart, including the following details from
the user’s membership records:

Shipping address

The last four digits of the member’s credit card

An estimate of when Classics will ship the product.

The total amount that Classics will charge to the member’s credit card.
The user verifies his or her e-mail address.
 The system prompts the user to confirm their e-mail address.
The user completes the order.
 The user clicks a button to complete the order.
The system confirms the order.
 The system displays a confirmation that the order has been placed and provides an order number
for future reference.
With the order completed, the user visits the catalog or leaves the ClassicsCD.com site.
 The use case ends when the user leaves the order confirmation page.
1.53
Alternative Flows

No order placed
The user could return to the home page, leave the ClassicsCD.com site, or end their
browser session.

Empty cart
If the user’s shopping cart is empty, the system displays a message indicating that user has
not selected any items to purchase. The use case ends.
Special Requirements
None
Pre-Conditions
User must already be a valid member of ClassicsCD.com with a CustomerID and Password.
User must have added at least one item to the shopping cart .
Post-Conditions
None
Extension Points
None