SADM 7/ed – CTTS CASE STUDY - Milestone 3: Solution
Page: 3-1
MILESTONE 3 – MODELING SYSTEM REQUIREMENTS
 Activity 1 – Use-Case Glossary
T
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.
A few notes on the use cases included in the glossary:
 MANUALLY RESOLVE SERVICE REQUEST was made a separate use case from
AUTOMATICALLY RESOLVE SERVICE REQUEST because the steps that each follow are very
different.
 An abstract use case called RESOLVE SERVICE REQUEST was added to encapsulate the
logic that actually marks a service request as resolved. This will be used by MANUALLY
RESOLVE SERVICE REQUEST and AUTOMATICALLY RESOLVE SERVICE REQUEST.
 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.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 7ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2007
SADM 7/ed – CTTS CASE STUDY - Milestone 3: Solution
Page: 3-2
Use-Case Glossary
Use-Case Name
Participating
Actors and Roles
Use-Case Description
Enter Service Request
This use case describes the event of creating a
new service request.
Enter Work Record
This use case describes the event of a technician
entering work done related to a service request,
including time to be used for time-and-billing.
This use case describes the event of a technician
entering a new component that has been added
to a PC or other kind of equipment.
This use case describes the event of checking in
new purchased components.
This use case describes the event of a technician
entering software configuration information.
This use case describes the event of entering a
new client.
This use case describes the event of viewing a list
of unresolved requests. A client can view only the
unresolved requests for that client. A technician
can view all of his or her unresolved requests.
Management will view all unresolved requests that
have been open for more than 72 hours. A
complete history of all the work done on a service
request can also be viewed.
This use case describes the event of marking an
unresolved service request as resolved.
This use case describes the event of
automatically marking a service request as
resolved.
This is an abstract use case that holds the
functionality for actually marking a service request
as resolved. It will be used by Manually Resolve
Service Request and by Automatically Resolve
Service Request.
This use case describes the event of viewing the
list of components installed in a piece of
equipment.
This use case describes the event of a technician
creating an equipment record for a client.
This use case describes the event of a technician
creating a new component type or editing an
existing one.
This use case describes the event of a technician
creating a new type of equipment or editing an
existing one.
This use case describes the event of a technician
viewing software configuration information.
Enter Component
Information
Check In Inventory
Enter Configuration
Information
Enter New Client
View Unresolved
Requests/History
Manually Resolve Service
Request
Automatically Resolve
Service Request
Resolve Service Request
View Installed Components
Enter New Equipment
Enter/Edit Component
Type
Enter/Edit Equip Type
View Software
Configuration Info
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 7ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Client
Technician
Receptionist/Bookkeeper
Technician
Technician
Receptionist/Bookkeeper
Technician
Receptionist/Bookkeeper
Client
Technician
Management
Technician
Time
Technician
Technician
Employee
Employee
Technician
Copyright Irwin/McGraw-Hill 2007
SADM 7/ed – CTTS CASE STUDY - Milestone 3: Solution
Page: 3-3
Activity 2 – Use-Case Model Diagram
T
his model should be constructed based on the use cases identified in Activity 1. The
selection of subsystems will vary depending on the assumptions of the student. Most
students should be able to correctly identify the Uses relationships shown below. In our
our solution a Uses relationship was established from VIEW UNRESOLVED REQUESTS to
to RESOLVE SERVICE REQUEST because the interview suggested that the user interface might
work that way.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 7ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2007
SADM 7/ed – CTTS CASE STUDY - Milestone 3: Solution
Page: 3-4
 Activity 3 – Fully-documented Use-Case Narrative
T
he narrative shown here is one possible answer. Students will need to make assumptions
about the sequence of events as well as numbering and other minor issues. Grade based
on the logic of the student’s approach to the problem and consistency of implementation.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 7ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2007
SADM 7/ed – CTTS CASE STUDY - Milestone 3: Solution
Page: 3-5
Customer Technology Tracking System
Author:__Anna Kelly
Use-Case Name:
Use-Case ID:
Priority:
Source:
Primary System
Actor:
Primary Business
Actor:
Other Participating
Actors:
Other Interested
Stakeholders:
Description:
Precondition:
Trigger:
Typical Course Of
Events:
Alternate Courses:
Date:__03/29/06_
View Unresolved Requests/History
CTTS-006
High
Requirement – MSS-R1.00
Client, Technician, Management
Use Case Type
Business Requirements 
Client
Client, Technician, Management
This use case describes the event of viewing a list of unresolved requests. A client can
view only the unresolved requests for that client. A technician can view all of his or her
unresolved requests. Management will view all unresolved requests that have been open
for more than 72 hours.
The user must have previously logged on so that the system can identify the user as a
particular client, technician, or management user.
The use case is initiated when the user selects this option from the user interface.
Actor Action
System Response
Step 1: This use case is initiated when
a user selects the option to view
unresolved requests.
Step 2: The system responds by displaying a
list of the unresolved request related to that
client or technician.
Step 3: The user may request to view
the detailed history for one of the
unresolved requests.
Step 4: The system displays detailed
information about the original request and all
work that has been done on it. This display will
include an option for returning to the original list.
Step 5: Technician or management
users may request to mark a request
as resolved.
Step 6: The system will verify that this user has
the right to mark a request as resolved and then
branch to use case MANUALLY RESOLVE SERVICE
REQUEST.
Alt Step 2a: If the user is management then the system displays all unresolved requests
that have been open for more than 72 hours.
Alt Step 2b: If there are no unresolved requests to display, the system will display an
appropriate message.
Conclusion:
Postcondition:
Business Rules:
Implementation
Constraints and
Specifications:
Assumptions:
Open Issues:
Alt Step 6: If the user does not have the right to mark a request as resolved. The system
will display an error message. Or the system may be designed so that the resolve request
is never given as an option to a user lacking that right.
This use case concludes when the user exits the unresolved request list screen
None
None
Web programming to be used so clients can have easy remote access.
None
1. Need to determine whether or not a client can mark a request as resolved.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 7ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2007