Sample Student Use Cases with some comments:



Sample Student Use Cases with some comments:

[pic]

|Use Case Number: |03 |

|Use Case Name: |Edit Member Account |

|Actor (s): |Buyer, Seller , Profile Database?? Need another actor above… |

|Maturity: |Focused |

|Summary: |This use case is started by a Buyer or a Seller. It provides the capability for one of these |

| |actors to edit their member profile. |

|Basic Course of Events: |Actor Action |System Response |

| | | |

| |1. This use case is started when a Buyer or | |

| |Seller elects to edit their member profile. | |

| |Perform S1-Login | |

| | |2. The System displays the |

| |3. The Actor updates their member profile. |Actor’s member profile and prompts the Actor to |

| | |update it. |

| | | |

| | | |

| | |4. The System validates the information entered |

| | |by the |

| | |Actor. |

| | |{Validate Information} |

| | | |

| |6. The Actor confirms that the information |5. The System prompts the Actor for |

| |is correct. |confirmation. |

| |{Profile Change} | |

| | | |

| | |7. The System updates the |

| |Move these down, if using the conversation |Actor’s member profile to the member repository |

| |format… |and informs the Actor that the information was |

| | |updated successfully. |

| |8. This use case concludes when the Actor | |

| |receives visual confirmation of the update. | |

|Alternate Paths: |A1 Change Member Profile |

| | |

| |At {Profile Change} the Member indicates that he/she entered incorrect information. |

| | |

| |The System immediately returns to the step 2. |

| | |

| | |

| | |

| | |

|Exception Paths: |E1 Handle Invalid Information |

| | |

| |At {Validate Information} if any fields are entered incorrectly. |

| | |

| |The System indicates the fields that were entered incorrectly and prompts the Buyer or Seller |

| |to make the necessary corrections. |

| | |

| |The flow of events is resumed at Basic Flow Step 2. |

|Extension Points: |{Change Profile }, {Validate Information} |

|Triggers: |The Buyer or Seller would like to edit their member profile. |

|Assumptions: |The Buyer or Seller is aware of the steps required to edit their member profile. |

|Preconditions: |The System is functioning properly. |

| |Actor already has a Profile stored in the Profile Database??? |

|Post Conditions: |The member profile was successfully updated to the member repository. Actor sent email to |

| |confirm changes? |

|Reference - Business Rules: |See Business Rules section: 2.3.1 and 2.3.5. |

|Reference - Risks: |See Risks List sections: 2.1 and 2.4. |

|Author (s): |Team3 |

|Date: |11-04-04 |

Good.

[pic]

|Use Case Number: |04 |

|Use Case Name: |Find Book |

|Actor (s): |Buyer, Potential Member, Seller Ah, another black hole. All comes ‘in’ and nothing out! Is |

| |there no Repository Database for books (or whatever you might call it?) Is there no Profile |

| |database?? |

|Maturity: |Focused |

|Summary: |This use case is started by a Buyer, Potential Member, or a Seller. It provides the capability |

| |for one of these Actors to determine the availability of a book from Where?? based on the |

| |course that the book is required for or by the instructor of the course. |

|Basic Course of Events: |Actor Action |System Response |

| | | |

| |1. This use case is started when a Buyer, | |

| |Potential Member, or Seller would like to | |

| |determine the availability of a certain book.| |

| | | |

| | | |

| | |2. The System displays two options to search on:|

| | |Search by Course |

| |3. The Actor selects a method to search by. |Search by Instructor |

| | | |

| |Same comments in general. | |

| |Move some of these down ‘to align’ | |

| |Major shortcoming – the databases. | |

| | | |

| |Good breakdown., | |

| |Ensure enough information is passed onto the | |

| |developers. | |

| | | |

| | | |

| | | |

| | | |

| | | |

| | |4. Whoa! Where is the system going to get this |

| | |information? You are not recognizing the need |

| | |for an interface for (let alone the database |

| | |itself) the repository. The System displays the |

| | |Actor’s selection and prompts the Actor to select|

| | |one of the following: |

| | |Course number |

| |5. The Actor makes their selection and |Instructor code |

| |proceeds with the search. | |

| |{Incorrect Search Category} | |

| | | |

| |Should be an exception? | |

| | | |

| | |6. The System displays the results of the query.|

| | |and where/what is queried? Where is the external|

| | |actor??? |

| |Move these guys down… |{Update Shopping Cart} |

| | | |

| |7. This use case ends when the Actor finds | |

| |the book which they were searching for. | |

| | |

| | |

|Alternate Paths: |Whoa! Left justify like the others! A1 Change Search Criteria |

| | |

| |At {Incorrect Search Category} the Actor indicates to the System that he/she does not wish to |

| |proceed with the current search category. |

| | |

| |The System does not notify the Actor and immediately returns to Basic Flow 4. |

| |A2 Add Book to Shopping Cart |

| | |

| |At {Update Shopping Cart} the Buyer indicates to the System to add the book his/her shopping |

| |cart. |

| | |

| |The System adds the book to the Buyer’s shopping cart and the use case ends. |

| |Why is your format now different???? |

|Exception Paths: |N/A |

|Extension Points: |{Incorrect Search Category}, {Update Shopping Cart} |

|Triggers: |A Buyer is looking for a book to purchase. |

| |A Potential Member needs to decide whether or not to signup for a membership. |

| |A Seller needs to determine if any other Sellers are selling the same book, and if they are, |

| |would like to view the price of the book. |

|Assumptions: |The Actor is aware of the steps required to search the System. |

|Preconditions: |The System is functioning properly. |

|Post Conditions: |The Actor found the book that they were looking for. |

|Reference - Business Rules: |See Business Rules section: 2.2. |

|Reference - Risks: |See Risks List sections: 2.1 and 2.4. |

|Author (s): |Team 3 |

|Date: |11-04-04 |

INCONSISTENT FORMAT WITH OTHER USE CASES!!!!!

FIX.

[pic]

|Use Case Number: |05 |

|Use Case Name: |Manage Book Description |

|Actor (s): |Seller NO DATABASE??? |

|Maturity: |Focused |

|Summary: |This use case is started by a Seller. It provides the capability for a Seller to add, edit |

| |or delete the description of a book FROM WHERE???? they PROFILE?? intend to sell or are |

| |currently selling. ARE YOU USING PAYPAL OR SOME KIND OF ACCOUNTING SYSTEM? |

|Basic Course of Events: |Actor Action |System Response |

| | | |

| |1. This use case is started when the |2. The System prompts the Seller to add, edit, |

| |Seller elects to add, edit, or delete a |or delete a book description. |

| |book description. | |

| |Perform S1-Login | |

| | | |

| |3. The Seller chooses to add, edit, or |4. Based on the Seller’s choice, the System |

| |delete a book description. |performs one of the following sub flows: |

| | |Perform S1 – Add Book |

| | |Description |

| | |Perform S2 – Edit Book |

| | |Description |

| | |Perform S3 – Delete Book |

| | |Description |

| | | |

| | |5. The System gives visual confirmation of the |

| | |newly updated book description. |

| | | |

| | |6. The System repeats steps 2 |

| |7. This use case concludes when the |– 4 until the Seller is satisfied with his/her |

| |Seller indicates they are finished |updated book description(s). |

| |managing their books and is redirected to | |

| |the main member page. | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download