| This example is only intended to illustrate the organizational structure of the SRS. It is not intended to be an example of a complete SRS. For example, it has only one each of the actor, use case, class, method, and attribute description sections. If you want to see a complete SRS, use Google to find some examples. When I last looked I found a decent example at http://www.devdaily.com/ooaood/dd-example-requirements-specification.pdf. I also found an example in HTML at http://cohesion.chrysocome.net/documentation/srs/index.shtml?content4.html#AppUse%20Cases and a student example at http://www.itee.uq.edu.au/~csse3002/Assignments/T1D-csse3002.pdf. |
The purpose of this document is to define the requirements for the Video Rental System (VRS). The intended audience of this document includes the owner of the video store, the clerks of the video store, and the end users of the VRS. It is also intended to provide guidance to the requirements team, requirements analyst, design team, and other members of the developing organization.
The owner of a local video store wanted to create a new business plan where everything about renting a video (except the picking up and returning of videos) was done online. Therefore, the new VRS will allow the following functionality online: to search for videos, to become members, to rent videos, to modify membership information, and to pay overdue fees. The store personnel may use the VRS to process the rented or returned videos, to add or remove videos to/from his store's video inventory and to update video information. The VRS is intended to increase the owner's profit margin by increasing video sales with this unique business approach and by allowing him to reduce the staffing needed in his stores.
| Clerk | Personnel staff who is working in a video store |
| Customer | Anyone who interacts with the VRS with the potential of becoming a member. |
| Functional requirement | A service provided by the software system |
| Member | Anyone who registers with the VRS to acquire membership in the video store |
| Non-functional requirements | A constraint on the system or how the system is developed |
| Owner | The person with administrative power in the VRS |
| SRS | This Software Requirements Specification document |
| Timer | An event that causes an action to occur at a specified time |
| Video ID | Unique number given to each video unit |
| Statement | Printout showing an individual rental by a member. For each rented video, it displays the video ID, video name, and due date. It also shows rental charges. |
| VRS | Video Rental System (the system under development) |
Section 2 of the SRS describes the product in more detail. Section 3 provides a complete list of the functional requirements of the intended system. Section 4 provides the non-functional requirements. Section 5 shows the class diagram, and Section 6 the use case diagram. The appendices appear next.
The VRS is a web-based system. The system interfaces with two other systems, the owner’s email system, the video distributor’s video system, and the browsers used by VRS customers. The system provides a secure environment for all financial transactions and for the storing and retrieving of confidential member information.
The VRS allows customers to search the video inventory provided by this video store. To rent videos through the VRS, one must register as a member using the VRS. Upon becoming a member and logging into the VRS, the VRS provides the functionality for renting videos, modifying membership information, and paying overdue fines.
The clerks of the video store use VRS to process the return of rented videos. The owner of the video store uses VRS to add new videos into the system, remove videos from the system, and modify video information.
The VRS sends emails to members concerning video rentals. One day before a rented video is due to be returned, VRS emails the member a reminder of the due date for the video(s). For any overdue videos, VRS emails the member every 3rdday with overdue notices. At the 60-day limit for outstanding videos, VRS debits the member’s credit card with the appropriate charge and notifies the member of this charge.
The three main groups of VRS users are customers, members, and store personnel. A customer is anyone who is not a member. The customer can only search through the video inventory. The amount of product training needed for a customer is none since the level of technical expertise and educational background is unknown. The only skill needed by a customer is the ability to browse a website.
A member is someone who has registered with VRS. A member can rent videos and pay fees online. As with a customer, these activities require no product training since the level of technical expertise and educational background of a member is unknown. The only skill needed by a member is the ability to browse a website.
The store personnel are divided into two groups: the clerk-level personnel and owner-level personnel. Their educational level is unknown and both group needs little to no training.
This system provides web access for all customer and member functions. The user interface will be intuitive enough so that no training is required by customers, members, or store personnel. All online financial transactions and the storage of confidential member information will be done in a secure environment. Persistent storage for membership, rental, and video inventory information will be maintained.
No assumptions and dependencies affect this system at this time.
3.1 The system shall provide registration for customers to become members.
3.1.1 The system shall assign a member number and allows the member to select a password.
3.1.2 The system shall record membership information for future use.
3.2 The system shall allow the customer or member to search video information.
3.3 The system shall provide login security for renting videos and payments.
3.4 The system shall allow members to rent videos.
3.4.1 The system shall print rental notice for packaging of rented videos.
3.5 The system shall allow members to pay overdue fines.
3.6 The system shall allow members to modify membership information.
3.7 The system shall allow a clerk to process returned videos.
3.8 The system shall email due notices to members.
3.8.1 The system shall send due notices one day before due date.
3.8.2 The system shall send overdue notices every third day after the due date.
3.8.3 The system shall email a 60-day notice of charges for non-returned videos.
3.8.4 The system shall interface with the owner’s email software.
3.9 The system shall allow the owner to add new videos to the video inventory.
3.9.1 The system shall retrieve video information from the video distributor.
3.9.2 The system shall interface with the video distributors’ websites.
3.10 The system shall allow the owner to remove videos from the video inventory.
3.11 The system shall allow the owner to modify the video type.
4.1 The system shall provide web-access for all customer and membership functions.
4.2 The system shall provide persistent storage for membership, rental, and video inventory information.
4.3 The system shall provide an intuitive user interface that requires no training.
4.4 The system shall provide a secure environment for financial transactions and for the storage of confidential member information.
| Name | Member |
|---|---|
| Alternate Names | Borrower, renter |
Input Data
| Name of Use Case | Inputs to the System |
|---|---|
| Rent Videos | Video ID for each video to be rented; pickup location * |
| Pay | Payment method information * |
Output Data
| Name of Use Case | Outputs from the System |
|---|---|
| Rent Videos | Invoice, showing items rented, due dates, and amount charged; receipt for payment |
| Pay | Invoice, showing amount due; receipt for payment |
* Note: This example assumes that the owner has stores at more than one location, and that a customer may wish to enter the credit card information at the time of the rental, rather than having her/his credit card information kept in the store's database. These details go beyond what is said in the Vision Statement [1].
Description
| Customer who has been registered as a member. |
Comments
| Members are given a membership number and create their own password. Members must use these to access the listed use cases. |
| Name | Member |
|---|---|
| Description | An instance of the Member class is a customer that has registered with the VRS. |
| Name of Attribute | Data Type | Description |
|---|---|---|
| name | String | First and last name of member in format of Last, First |
| address | String | Mailing address; consists of street address or PO Box, city, state, and zip code |
| phoneNumber | String | Supplied by member |
| creditCard# | String | Credit card to which all charges made through this system are made |
| emailAddress | String | Supplied by member |
| username | String | Supplied by the system; alphanumeric characters |
| password | String | Supplied by the member; consists of any 8 characters |
| Method Signature | Description |
|---|---|
| ...incomplete... |
| Class Name | Type of Relationship | Comments |
|---|---|---|
| Rental | Association | |
| ...incomplete... |
| Name | phoneNumber |
|---|---|
| Class Name | Member |
| Alternate Name(s) | None |
| Type | String |
| Length | 12 |
| Output Format | NNN-NNN-NNNN where N is an digit |
| Default Value | Blank |
| Acceptable Values | NNN-NNN-NNNN where N is an digit |
| Source (where value comes from) | Member |
| Derivation Formula | None |
| Description | The member can supply a home or cell telephone number as part of the application process. |
| Comments | Supplied by the member on the membership application form. |
| Name | Become Member |
|---|---|
| ID | 1 |
| Requirement Number | 3.1 |
| Description | A customer registers to become a member, so that she/he can rent videos. |
| Primary Actor | Customer |
| Secondary Actor(s) | None |
| Pre-condition | Customer is not a current member. |
| Post-condition | Customer is known to the system as a Member, with a user name and password to use for future transactions with system. |
| Trigger | Member selects the “become a member” option. |
| 1 | System displays member information data entry form | 2 | Customer enters name, address, phone number, email address, credit card number, and expiration date of credit card. |
|---|---|
| 3 | System validates customer information, displays form for entry of username and password. |
| 4 | Customer enters userame and password for subsequent membership login. |
| 5 | System validates user name and password, and displays confirmation form. |
| 6 | Customer confirms membership information. |
| 7 | System emails membership confirmation to new member. |
| 3.a | Customer information is missing on application form:
| ||||||
|---|---|---|---|---|---|---|---|
| 3.b | Customer information is invalid:
| ||||||
| 5.a | User name or password is missing or invalid:
| ||||||
| 6.a | Customer indicates desire
to modify, rather than confirm:
|
| Name | Rent Videos |
|---|---|
| ID | 3 |
| Requirement Number | 3.4 |
| Description | A member uses the system to rent a video. |
| Primary Actor | Member |
| Secondary Actor(s) | Clerk |
| Pre-condition | Member has an active account. |
| Post-condition | Videos are rented to the member. Member's charge card is debited with rental amount. Video inventory modified to reflect videos rented. A statement showing the videos rented, the amount charged, and due date(s) is created and printed on a form at the specified store location, for delivery to the customer with the videos. |
| Trigger | Member selects the “rent video” option. |
| 1 | Member logs into the system (includes Log in). |
|---|---|
| 2 | Member browses the available videos (includes Browse). |
| 3 | Member adds video to the shopping cart. Steps 2 and 3 repeat until the member completes making selections. |
| 4 | Member requests to view shopping cart. |
| 5 | System displays shopping cart. |
| 6 | Member checks out contents of shopping cart (includes Check Out). |
| 7 | System prints statement on form at the specified store location (includes Print Statement). |
| 3.a | Member has overdue fees:
| ||||||
|---|---|---|---|---|---|---|---|
| 6.a | User modifies order, by editing fields of the shopping cart.
| ||||||
| 6.b | User decides to cancel order.
| ||||||
| 7.a | Checkout fails, e.g., because some videos not available at the selected
store location:
|
Note: These point values would be assigned by the project analyst, with input from other team members, based on experience. In this example, the points assigned to use cases and actors are purely illustrative. They may or may not be realistic. Please do not assume any judgments on the part of the instructor as to the actual difficulty of implementing these cases.
| Actor Name | Actor Type | Actor Points |
|---|---|---|
| Customer | User Interface | 3 |
| Member | User Interface | 3 |
| Distributor | Complex Interface | 2 |
| Clerk | User Interface | 3 |
| Timer | Simple Interface | 1 |
| Owner | User Interface | 3 |
| TOTAL | 15 |
| Use Case Name | Number of Transactions | Use Case Type | Use Case Points |
|---|---|---|---|
| Become Member | 10 | Complex | 15 |
| Browse | Average | 10 | |
| Rent Videos (incl. Select Videos and Check Out) | 11 | Complex | 15 |
| Print Statement | Complex | 15 | |
| Pay | Average | 10 | |
| Check In | 11 | Complex | 15 |
| Email Due Notice | Average | 10 | |
| Add Video | Complex | 15 | |
| Remove Video | Simple | 5 | |
| Modify Video Type | Average | 10 | |
| Due Notice (incl. 60-Day Notice) | Simple | 5 | |
| Modify Member Info | Average | 10 | |
| Login | Average | 10 | |
| TOTAL | 145 |
| scrn000 (Home Page) | scrn001 (Registration Screen) | scrn002 (Password Screen) | scrn003 (Confirmation Screen) | |
|---|---|---|---|---|
| scrn000 | Register | |||
| scrn001 | Cancel | Submit | ||
| scrn002 | Submit | |||
| scrn003 | Confirm | Modify |
| Use Case Name | Become Member |
| Use Case ID | 1 |
| Step # | Step Text | DataStored | Screens Needed | Reports Needed |
|---|---|---|---|---|
| 1 | System displays member information data entry form. | MembershipInfoScreen | ||
| 2 | Customer enters name, address, phone number, email address, credit card number, and expiration date of credit card. | MembershipInfoScreen | ||
| 3 | System validates membership info | |||
| 4 | Customer enters new user name and password for subsequent membership login. | UserNameAndPasswordScreen | ||
| 5 | System validates user name and password. | |||
| 6 | Customer confirms membership information. | Membership info | ConfirmationScreen | |
| 7 | System emails membership confirmation to new member. |
| Screen / Report ID | ID Type(I, O, I/O) | Screen/Report Name | Use Cases that Use this Screen/Report |
|---|---|---|---|
| scrn000 | I | Home Page | Become Member, Rent Videos |
| scrn001 | I,O | Registration Screen | Become Member |
| scrn002 | I | Password Screen | Become Member |
| scrn003 | O | Confirmation Screen | Become Member |
| scrn004 | I | Log In Screen | Rent Videos |
| ...more | ... | ... | ... |
($Id: vrsSRSExample.html,v 1.3 2010/09/19 22:30:54 baker Exp baker $)