Skip to content

Ctts Case Study Milestone 29

CTTS Author (s): Class Date: _3/29/2010 Version: __________ USE CASE NAME: View unresolved request/ history USE CASE TYPE USE CASE ID: Business Requirements:  PRIORITY: High SOURCE: Requirement PRIMARY BUSINESS ACTOR: Client OTHER PARTICIPATING ACTORS: • Technicians • Management OTHER INTERESTED STAKEHOLDERS: • DESCRIPTION: This use-case describes the event of allowing the technicians to view all unresolved requests. Management can view all unresolved requests that are open 72 hours or more. Clients can view their own service request/history. PRE-CONDITION: User must have previously logged on so that the system can identify technicians, management and clients. TRIGGER: A use case is initiated when the user selects the user interface. TYPICAL COURSE Actor Action System Response OF EVENTS: Step 1 : Using this use case is initiated when a user selects the option to view unresolved requests. Step 2

CTTS CASE STUDY - Milestone 3: Solution Page: 3-1 MILESTONE 3 – MODELING SYSTEM REQUIREMENTS  Activity 1 – Use-Case Glossary he following use cases and their descriptions and actors can be determined from the interview. Some students may identify other use cases based on standard maintenance functions. These are not incorrect, but have been left out of the glossary for the sake of simplicity. We have chosen to focus only on the use cases that will be most used. T A few notes on the use cases included in the glossary:  M ANUALLY R ESOLVE S ERVICE R EQUEST was made a separate use case from A UTOMATICALLY R ESOLVE S ERVICE R EQUEST because the steps that each follow are very different.  An abstract use case called R ESOLVE S ERVICE R EQUEST was added to encapsulate the logic that actually marks a service request as resolved. This will be used by M ANUALLY R ESOLVE S ERVICE R EQUEST and A UTOMATICALLY R ESOLVE S ERVICE R EQUEST .  From the interview we could easily add another abstract use case for logon. But since every other use case would use logon, this was left out solely to keep the use case diagram that follows from becoming messy.  An Employee role was added for two use cases that could be accessed by any employee.