Example Requirements Documentation
ClassicsCD Web Shop
Vision Statement
Introduction
1.1Purpose 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.2Product 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.3User/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.4User 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.5User Environment
This system is a web-based e-commerce site allowing customers to order ClassicsCD products over the Internet.
1.6Key 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.7Alternatives and Competition
The alternative to developing this system in-house is to buy a commercially available product. The products on the market today are not customizable enough to support the needs of ClassicsCD.com.
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.8Product 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.9Product Position Statement
The ClassicsCD.com Web Shop will allow customers easy ordering of Classical CDs at competitive prices.
1.10Summary of Capabilities
OnLine CD Shop
Customer Benefit / Supporting FeaturesEasy 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
1.11 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.12Status
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 / MeaningProposed / 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 / Describes capabilities that are deemed useful and feasible and have been approved for implementation by the PDG.
Incorporated / Describes features incorporated into the product implementation at the end of a specific iteration.
1.13Priority
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 / MeaningCritical / 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.
1.14Effort
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.15Risk
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.16Stability
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.17Assigned 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.18Origin
The Origin attribute defines the source of a feature request. Possible values can include customer, tech support, and development.
Product Features
1.19FEAT1 ClassicsCD.com Web Shop
FEAT1.1 Secure Payment method.
FEAT1.2 Easy Browsing for available titles
FEAT1.3 Ability to check the status of an order
FEAT1.4 E-mail notification for customers when new titles are added that may be of interest to them.
FEAT1.5 Highly Scaleable to include many titles and effective searching through those titles.
FEAT1.6 Customer should be able to customize the web site
FEAT1.7 Customer should be able to register as a user for future purchases without needing to re-enter personal information.
1.20FEAT2 ClassicsCD Administration System
FEAT2.1 Ability to add/remove offerings.
FEAT2.2 Ability to check on customer orders.
FEAT2.3 Maintain customer information.
FEAT2.4 Generate reports
Other Product Requirements
1.21Applicable Standards
- FEAT25 ClassicsCD applications must comply with common web user interface such as Microsoft Internet Explorer and Netscape.
1.22System Requirements
- FEAT26 The web application will be supported on all operating systems that are supported by the chosen browsers.
Documentation Requirements
1.23Online Help
FEAT5 The web site will include an interactive guide to the web site in the form of online Help.
Use Case Diagram
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.24Purpose
Team members should add any terminology that they feel needs to be used with a high degree of clarity.
1.25Scope
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.26Administrator
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.27Club Member
The Club Member is described as someone who has a valid CustomerID and password on file with Classics Inc.
1.28Catalog
The catalog includes all CDs that are available for sale on the ClassicsCD.com Web site.
1.29CustomerID
The customerID is used to identify Club Members.
1.30Shopping Cart
The shopping cart is the generic term for the container of all items that have been selected for purchase.
1.31Visitor
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.32Purpose
This document details non-functional requirements that apply to the overall ClassicsCD.com projects.
1.33Scope
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.34Interface Ease of Use
SUPP1 The system shall follow standard interface guidelines.
SUPP2 The system shall be user friendly.
SUPP3 The software shall be able to run on Internet Explorer 4.0 and later and Netscape Navigator.
1.35Training
SUPP4 Training shall be developed for all modules.
Reliability
1.36Fault Tolerance
SUPP5 The system shall be able to operate in a fault tolerant manner 7 x 24.
SUPP6 The system shall be able to run Internet Explorer 4.0 and later and Netscape Navigator.
1.37Defects
SUPP7 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.38Response Time
SUPP8 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.39Coding Standards
SUPP9 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
UC7 Arrange Shipment
1.40Brief 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.41Basic Flow
UC7.1 Upon successful completion of the Checkout use case complete order information will be sent to the warehouse system.
UC7.2 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:
- UC7.2.1 Club member name
- UC7.2.2 Club member shipping address
- UC7.2.3 Club member phone number
- UC7.2.4 Product SKU number for each product ordered
- UC7.2.5 Club member ID
- UC7.2.6 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.42Alternate 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
UC4 Check order status
1.43Brief Description
UC4.1 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.44Basic 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
- UC4.5 To see the details of a specific order, the user clicks on an OrderID.
- UC4.6 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
UC4.7 The use case ends when the user begins the Browse Catalog use case, or leaves the ClassicsCD.com site.
1.45Alternative Flows
UC4.8 User enters an invalid CustomerID and/or Password
UC4.8.1 If the user enters an invalid CustomerID and/or password, the system displays a message indicating that the CustomerID/Password combination is not valid.
UC4.8.2 The user clicks the browser’s Back button to return to the CustomerID/Password entry page.
Special Requirements
None
Pre-Conditions
UC4.9 The user must have a valid CustomerID/Password combination
Post-Conditions
None
Extension Points
None
Use Case Specification: Shop for CD
UC2 Shop for CD
1.46Brief Description
UC2.1 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.47Basic Flow
Select a CD
UC2.2 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.
UC2.3 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
UC2.4 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
UC2.5 The user examines the contents of the shopping cart by clicking on the link text, Shopping Cart.
Proceed to Checkout
UC2.6 The use case ends when the user clicks the link text, Cashier, to complete the purchase.
1.48Alternative Flows
UC2.7 Remove item from cart
UC2.7.1 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
UC19 Here is text for a Parent or Root requirement.
UC19.1 Use this text to create a Child requirement.UC19.1.1
Use this text to create a Child requirement of the Child requirement directly above.
Pre-Conditions
UC2.8 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
UC1 Browse Catalog
1.49Brief Description
UC1.1 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.50Basic Flow
- UC1.2 The use case begins when the user displays the Classics CD homepage
- UC1.3 The system presents an option to browse the catalog of CDs
- UC1.4 The system also presents a recommended selection of the day.
- UC1.5 The user clicks the “catalog” link
- UC1.6 The system presents a list of all available CDs
- UC1.7 The user looks at the details of a CD by selecting the link to its title
- UC1.8 The system displays the following information:
- UC1.8.1 Picture of the cover
- UC1.8.2 CD title
- UC1.8.3 Performer and orchestra
- UC1.8.4 Review of the CD
- UC1.9 This flow terminates when the user goes back to the homepage, chooses another option, or closes the browser session.
UC1.10 Search by selected criteria
UC1.11 The user searches through the catalog of all available CDs by first selecting one of the following choices from a list.