Release Information
| Project: |
PROJECT-NAME |
| Internal Release Number: |
X.Y.Z |
| Related Documents: |
LINKS-TO-RELEVANT-STANDARDS
LINKS-TO-OTHER-DOCUMENTS
|
TODO: Note any values that are common to all use cases here. This
helps keep the use cases themselves short. If any use case is an
exception, note its specific value to replace or add to the default.
Default Values of All Use Cases
| Direct Actors: |
User (default): end-user in any role
System: The system being built
|
| Stakeholders: |
User |
| Preconditions: |
User is logged in |
| Notes and Questions: |
Steps beginning with "see" indicate that
System has presented a new screen. |
TODO: For each use case listed in the
use case suite, create an HTML anchor
and heading with its unique ID, then fill in the rows of the table
to specify the use case in detail.
TIP: It is OK to simply list the names and summaries of several use
cases without actually writing them in detail. Fully specify the
most important use cases first, then come back to specify the less
important ones later.
UC-00: Configure the site
| Summary: |
The administrator navigates to the site configuration page and
uses it to change the behavior of the web application.
Specifically, the user-visible timezone is being set. |
| Priority: |
Essential |
| Use Frequency: |
Rarely |
| Direct Actors: |
Admin: Web-site administrator
|
| Main Success Scenario: |
- visit site configuration page
- see site configuration options
- enter timezone abbreviation for date displays
- submit form
- confirm changes
- see site configuration page again, with updated values
|
Alternative Scenario Extensions: |
- If the timezone abbreviation is incorrect, an error message
will be displayed and no changes will be made.
|
| Notes and Questions: |
- How will an administrator know the right timezone abbreviation?
He/she would only know it if he/she lives in that timezone. Maybe we could
provide a drop-down list of all choices. Each choice would need some
explanation.
|
UC-01: Register as a new user
| Summary: |
Users need to register themselves in this web application. |
| Priority: |
Essential |
| Use Frequency: |
Once per user |
| Preconditions: |
User is not logged in |
| Main Success Scenario: |
- visit login page
- choose "register" as new user
- enter identifying information: username, email, real name
- submit form
- See "thank you" screen showing address that email was sent to.
- read email
- log in using password from email message
|
Alternative Scenario Extensions: |
- If the username is taken, then the system will suggest an
available username based on the user's email address and/or real name.
|
| Notes and Questions: |
- If the user had a typo in his/her email address, he/she would
never get the password email. Hopefully, he/she will catch the
mistake when seeing the "thank you" screen.
- If the user had a typo in his/her email address, can he/she
still register that same username? No, it would be taken.
- What is our policy on recycling usernames that have never
logged in?
|
UC-02: Request new password
| Summary: |
If a user forgets his/her password, he/she can request that a new one be
sent. |
| Priority: |
Expected |
| Use Frequency: |
Rarely |
| Preconditions: |
User is not logged in |
| Main Success Scenario: |
- visit login screen
- choose "forgot password"
- see "forgotten password" page
- enter username
- submit form
- See "thank you" screen showing address that email was sent to.
- read email
- log in using password from email message
|
Alternative Scenario Extensions: |
- If the user no longer has the same email address, he/she must
contact technical support, or register a new account.
|
| Notes and Questions: |
- The email contains a new password. We do not keep
the plain-text of any passwords.
- Entering the username could be a difficult step if the user
has forgotten that also.
|
UC-03: Edit user profile
| Summary: |
Users can edit their own account preferences. |
| Priority: |
Expected |
| Use Frequency: |
Rarely |
| Main Success Scenario: |
- visit user profile page
- edit account information fields
- submit form
- see "thank you" screen
|
Alternative Scenario Extensions: |
- If the passwords do not match or any field is invalid, then show
error message and repeat editing and submit steps.
|
UC-10: Browse to product description
| Summary: |
Consumers can find products by drilling down from the store home
page. |
| Priority: |
Essential |
| Use Frequency: |
Always |
| Preconditions: |
User need not be logged in |
| Main Success Scenario: |
| User Intention |
System Response |
| visit store home page |
present store home page |
| choose department name |
present department home page |
| choose product category name |
present category product list |
| choose product name |
present product description |
|
Alternative Scenario Extensions: |
- One or two actions can be skipped if this is a featured product.
- One action can be skipped if this product is in a featured category.
|
| Notes and Questions: |
- The category product list may be sorted by price, name,
ACR, or sales rank.
- Note that products can be cross-listed in all relevant categories.
- Will a consumer always recognize the correct department and
category when he/she sees it?
|
UC-11: Put product in cart
| Summary: |
Consumers indicate an intent to purchase a product by putting it in
the shopping cart. The purchase is later confirmed during a checkout
use case. |
| Priority: |
Essential |
| Use Frequency: |
Often |
| Preconditions: |
User need not be logged in |
| Main Success Scenario: |
| User Intention |
System Response |
| visit product description page |
present product description |
| choose "add to cart" |
present cart contents page including selected product |
| choose "checkout" |
present checkout wizard |
|
Alternative Scenario Extensions: |
- If a quantity other than 1 is desired, then
- edit quantity on cart content page
- submit form
|
UC-12: Remove product from cart
| Summary: |
Consumers often remove items from the cart. Consumers who have
decided to make no purchase usually just abandon the session and
cart. Those consumers who proactively remove an item are usually
planning to replace it with another item, so we try to make it easy
to add something else without losing one's place. |
| Priority: |
Essential |
| Use Frequency: |
Often |
| Preconditions: |
User need not be logged in |
| Main Success Scenario: |
- visit any product page
- choose "view cart"
- see cart contents page
- edit quantity: set it to "0"
- submit form
- see updated cart contents screen
- choose "continue shopping"
- see preceding product page
|
UC-20: Create product record
| Summary: |
An administrator creates a product catalog entry. |
| Direct Actors: |
Admin: Web-site administrator
|
| Priority: |
Essential |
| Use Frequency: |
Often |
| Main Success Scenario: |
- visit administrative function menu
- choose "add product"
- see blank product record form
- enter product information: name, price, description, specs, etc.
- submit form
- see "thank you" page with product name, SKU, and price
|
Alternative Scenario Extensions: |
- If administrator wishes to quickly add another product, then
- choose "add another product"
- see blank product record form
- If administrator wishes to check entered information, then
- choose name of item
- see product description page with all entered product information
|
UC-21: Delete product record
| Summary: |
Products that are no longer sold are put into a "discontinued"
state. Later, they are automatically removed from the product
catalog. |
| Direct Actors: |
Admin: Web-site administrator
|
| Priority: |
Essential |
| Use Frequency: |
Often |
| Main Success Scenario: |
- visit product page
- choose "discontinue"
- see product discontinuation confirmation page
- edit date to mark as discontinued, if not today
- edit date to remove from catalog, if not today + 30 days
- submit form
- see "thank you" screen with product name, SKU, price, and dates
|
| Notes and Questions: |
- Should we allow any editing of products that are in the
"discontinued" state?
- Should this operation be reversible?
|
UC-22: Put product on sale
| Summary: |
Products can be put on sale at a special price for a limited
time. The sale can last until an end date or until inventory has
reached a target level. |
| Direct Actors: |
Manager: Store department manager
|
| Priority: |
Expected |
| Use Frequency: |
Often |
| Main Success Scenario: |
- visit product page
- choose "edit"
- see product editing page
- edit sale price
- edit date to end sale
- submit form
- see updated project page
|
Alternative Scenario Extensions: |
- If sale should end based on target inventory level, then
- edit target inventory level on product edit page
|
| Notes and Questions: |
- If both end date and target level are set, the sale
automatically ends when the first of those two criteria are met.
- Would we ever want to automatically put overstocked items on sale?
|
UC-30: USE CASE NAME
| Summary: |
1-3 SENTENCES |
| Priority: |
Essential | Expected | Desired | Optional |
| Use Frequency: |
Always | Often | Sometimes | Rarely | Once |
| Main Success Scenario: |
| User Intention |
System Response |
| visit STARTING-POINT |
present INITIAL-SCREEN |
| STEP |
RESPONSE |
| STEP |
RESPONSE |
| STEP |
present GOAL-WAS-ACHIEVED |
|
Alternative Scenario Extensions: |
- If CONDITION, then ALTERNATIVE STEPS.
- If CONDITION, then ALTERNATIVE STEPS.
|
| Notes and Questions: |
|
UC-31: USE CASE NAME
| Summary: |
1-3 SENTENCES |
| Priority: |
Essential | Expected | Desired | Optional |
| Use Frequency: |
Always | Often | Sometimes | Rarely | Once |
| Main Success Scenario: |
| User Intention |
System Response |
| visit STARTING-POINT |
present INITIAL-SCREEN |
| STEP |
RESPONSE |
| STEP |
RESPONSE |
| STEP |
present GOAL-WAS-ACHIEVED |
|
Alternative Scenario Extensions: |
- If CONDITION, then ALTERNATIVE STEPS.
- If CONDITION, then ALTERNATIVE STEPS.
|
| Notes and Questions: |
|
UC-40: USE CASE NAME
| Summary: |
1-3 SENTENCES |
| Priority: |
Essential | Expected | Desired | Optional |
| Use Frequency: |
Always | Often | Sometimes | Rarely | Once |
| Main Success Scenario: |
- visit STARTING-POINT
- STEP
- STEP
- see GOAL-WAS-ACHIEVED
|
Alternative Scenario Extensions: |
- If CONDITION, then ALTERNATIVE STEPS.
- If CONDITION, then ALTERNATIVE STEPS.
|
| Notes and Questions: |
|
UC-41: USE CASE NAME
| Summary: |
1-3 SENTENCES |
| Priority: |
Essential | Expected | Desired | Optional |
| Use Frequency: |
Always | Often | Sometimes | Rarely | Once |
| Main Success Scenario: |
- visit STARTING-POINT
- STEP
- STEP
- see GOAL-WAS-ACHIEVED
|
Alternative Scenario Extensions: |
- If CONDITION, then ALTERNATIVE STEPS.
- If CONDITION, then ALTERNATIVE STEPS.
|
| Notes and Questions: |
|
UC-42: USE CASE NAME
| Summary: |
1-3 SENTENCES |
| Priority: |
Essential | Expected | Desired | Optional |
| Use Frequency: |
Always | Often | Sometimes | Rarely | Once |
| Main Success Scenario: |
- visit STARTING-POINT
- STEP
- STEP
- see GOAL-WAS-ACHIEVED
|
Alternative Scenario Extensions: |
- If CONDITION, then ALTERNATIVE STEPS.
- If CONDITION, then ALTERNATIVE STEPS.
|
| Notes and Questions: |
|