Scribd
Upload
463 views

Use Case Description Example

The document describes a "Record Contact" use case for a relationship database. The use case allows a user to enter or modify information about a contact, by providing identifying details, contact date, staff involved, remarks, status, subjects, type and method of contact. The system then stores the updated contact information.

Uploaded by

patwolohan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
463 views

Use Case Description Example

The document describes a "Record Contact" use case for a relationship database. The use case allows a user to enter or modify information about a contact, by providing identifying details, contact date, staff involved, remarks, status, subjects, type and method of contact. The system then stores the updated contact information.

Uploaded by

patwolohan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Use Case Description Example Relationship Database Use Case Name: Iteration: Summary: Basic Course of Events:

Record contact Filled The user enters or changes information about a contact with a potential organizational donor, subscriber, marketing partner, etc. 1. The user indicates that information about a contact is to be entered 2. The system allows the user to: a. Provide identifying information for the person or organization involved in the contact (the non-staff participant) b. Exit the use case 3. The system: a. displays information from pre-existing records in the system about contacts with persons by staff members, etc. b. allows the user to: i. select one of the existing records for modification ii. indicate that a new record is to be entered iii. indicate that a different set of identifying information should be entered iv. exit the use case 4. The system prompts the user for: a. Contact date (default current date) b. Staff member involved in contact (pick list or similar, not free text, default current user?) c. Remarks (free text) d. Completion status (completed, planned, etc.) e. Contact subjects (might include grant, donation, marketing partnership, magazine criticism, etc.) f. Type (subscriber feedback, marketing, etc) g. Contact method (email, conversation) If the contact was a letter, the system will prompt the user for i. The body of the message ii. The type of letter (email, surface mail, etc.) If the method is conversation, the system will prompt the user for i. Description of conversation ii. Method (telephone, meeting, conference call, etc.) iii. Participants The system also prompts the user to indicate what action to take with the information displayed/altered by the user: h. Delete the displayed record i. Save to database j. start anew for this contact, discard changes k. select a different person/organization for use, discard changes 5. If the user has selected save in step 4, the system displays the information entered and prompts the user to indicate when they are finished viewing that information 6. The system stores the information and returns the user to step 2 1. At step 3, if the user selects different set of identifying information, the system returns the user to step 2 2. At step 4, if the user selects start anew, the system returns them to step 4, displaying the information originally present on the record before step 4, or to a blank screen in the case where a new record is being entered. 3. At step 4, if the user selects select a different record, the system discards any changes made by user and returns the user to step 2 1. At step 3, if no records matching the information provided by the user at step 2 are pre-existing, the user is still presented with the standard step 3 display,

Alternative Paths:

Exception Paths:

UCD02 Record Contact

P. 2 of 3.

but with a clear indication that no matching records were found.

Extension Points: Trigger: Assumptions:

1. 1. 1. 2. 3.

The user has appropriate privileges for working with contact information Any classification codes, etc. to be applied to this record have already been entered into the system. Information identifying the person or organization involved in the contact has already been entered into the system before this use case is started. Information modifications entered by the user are appropriately stored in the system.

Preconditions: Postconditions: Related Business Rules: Author: Date:

1. 1.

L.Bednar Facade 8/1/2003

Notes 1. The usual mechanism for the user to exit the use case is to select exit at step 2.

UCD02 Record Contact

P. 3 of 3.

Information Item Descriptions


Use Case Name A very short phrase describing the interaction of an actor (person, program, system, etc) with the system. Should begin with an active verb. Iteration Relates to the four stages through which a use case typically progresses faade use cases entered primarily with summary information as placeholders, with no strongly focused cross-checks or similar analysis completed filled preliminary description completed, some cross-checking with other described use cases to eliminate duplicates, etc. focused use cases analyzed, prioritized to differentiate essential from nonessential user interactions with the system, common elements identified finished. user interface requirements and nonfunctional requirements are added, and use cases documentation is packaged for the system design effort Summary A short paragraph (1-2 sentences) explaining the interaction. Basic Course of Events A numbered outline of the usual course of the interaction. A normal interaction without errors, malfunctions or mishaps should be represented. If several different courses are possible, the most commonly occurring should be described. Alternative Paths Outlines of less common courses of interaction. These should represent normal interactions without errors, malfunctions, or mishaps. Exception Paths - Outline of alternative courses of interactions in case of errors, malfunctions, or mishaps. Extension Points Shows the steps in a related use case that includes the use of the interaction described here. Trigger Description of the event or circumstance that causes the start of the use. Assumptions Description of any conditions assumed to be true, but which might not be true. Preconditions List of things that must be true before this interaction can occur. Postconditions List of things that are expected to be true after the interaction. Related Business Rules Business rules are the written and unwritten rules that dictate how a company runs its business. This section documents or refers to business rules that relate to this interaction. Author The name of the individual entering information into the use case description. Date The date of modification for the use case description.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy