1. TYPE OF SERVICE REQUESTED:
Information Strategy Planning Existing Application Enhancement
Business Process Analysis and Redesign Existing Application Maintenance (problem fix)
New Application Development Not Sure
Other (please specify ___________________________________________________________________
BRIEF STATEMENT OF PROBLEM, OPPORTUNITY, OR DIRECTIVE (attach additional documentation as necessary)
Coastline Systems Consulting’s web programmer has identified their client technology tracking system and service requests
and records as being in need of process redesign and a new integrated application. The current system in place to keep track
of and update clients’ hardware and software configurations is not centralized and ineffective. This has led to inefficient use
of technician resources in the form of technicians frequently not having the proper information or equipment at client sites.
The current system for clients to submit service requests is inefficient and does not provide an effective way for technicians
to record actions taken in response to those requests.
BRIEF STATEMENT OF EXPECTED SOLUTION
We propose a system for storing and updating client hardware and software configurations. The system should be secure yet
accessible by technicians at any time and from any location. We envision a system where clients can directly submit service
requests,technicians can document work done, and all parties can view the history and status of those requests. We envision
a system capable of generating reports and statistics enabling management to continue to improve these areas.
ACTION (ISS Office Use Only)
Feasibility assessment approved Assigned to Nicholai Stevens _
Feasibility assessment waived Approved Budget $ _____________
Start Date ASAP Deadline 6 Months
Request delayed Backlogged until date: ______________
Request rejected Reason: ________________________________________________
Authorized Signatures:
_____________________________________ _________________________________________________
Project Executive Sponsor
Coastline Systems Consulting
Phone: 850-234-6789 Fax: 850-987-5432
DATE OF REQUEST SERVICE REQUESTED FOR DEPARTMENT(S)
01/17/2012 Client Services
SUBMITTED BY (key user contact) EXECUTIVE SPONSOR (funding authority)
Name Anna Kelly Name Peter Charles
Title Web Programmer Title President/analyst
Office DHQ Office DHQ
Phone 850-234-6789 Ext- 0001 Phone 850-234-6789 Ext- 0006
2. PROBLEM STATEMENT MATRIX
Brief Statements of Problem,
Opportunity, or Directive
Urgency Visibility
Annual
Benefits
Priority
or Rank
Proposed Solution
1. Current system for clients
submitting service requests
inefficient.
ASAP High
In the
thousands.
1
Process Analysis and
Redesign/ New Web
Application Development
2. Current system for recording
and tracking services
performed is inefficient.
ASAP High 3,000 – 5,000 1 New Development
3. There is no centralized
system for tracking client
systems configurations.
(hardware and software)
ASAP
Low
(approved
users
only)
4,000
minimum
1 New Development
4. Technician time is wasted
because of a lack of proper
information before initiating
service call.
6 Months Medium
4,000
minimum
2
After system is
developed technicians
will properly document
services.
5. Secure system access must
be available to technicians
from their homes or in the
field, but management does
NOT want system exposed
to the internet.
6 Months Low Unknown 1 VPN or data replication
6. Systems and processes
always have room for
improvement.
6 Months
-
Constant
Low Unknown 2
Generation of reports and
statistics
7. Management would like an
easy way for techs to track
installation of new hardware
components.
6 Months High Unknown 3 Barcode Scanners
8. Warranty information about
current and future hardware
components needs to be
stored available to clients
and technicians.
6 Months High Unknown 3
After system is
developed technicians
will properly document
hardware installations.
PROJECT: Client Technology Tracking
System
PROJECT MANAGER: Dr. Alex Lazo
CREATED BY: Nicholai Stevens LAST UPDATED BY: Nicholai Stevens
DATE CREATED: 01/15/2014 DATE LAST UPDATED: 01/18/2014
3. PROBLEMS, OPPORTUNITIES, OBJECTIVES AND CONSTRAINTS MATRIX
Project: Client Technology Tracking System Project Manager: Dr. Alex Lazo
Created by: Nicholai Stevens Last Updated by: Nicholai Stevens
Date Created: 1/25/2014 Date Last Updated: 1/26/2014
CAUSE AND EFFECT ANALYSIS SYSTEM IMPROVEMENT OBJECTIVES
Problem or Opportunity Causes and Effects System Objective System Constraint
1. Current systemfor clients
submitting service requests
inefficient.
2. System for tracking
services performed is
ineffective.
3. System for tracking client
hardware and software
configurations is
ineffective.
4. Systems and processes can
be observed and measured
to indicate areas where
improvements can be
made.
5. System should be
expandable to allow for
company growth.
1. Clients have to call in their
service requests
2. Technicians enter changes
by hand,and sometimes
updates are not entered at
all.
3. Technicians enter changes
by hand,and sometimes
updates are not entered at
all.
4. Technicians are sometimes
unprepared for service
calls.
5. Services performed may be
unnecessary
1. Reduce time receptionist
spends entering new
service requests by 80%
2. Increase services
performed tracking
accuracy to 95%.
3. Increase tracking of
client systems
configurations accuracy
to 98%.
4. Increase technician
efficiency by 30%
5. Produce accurate real
time information about
services and procedures.
6. Allow technicians to
access client information
remotely.
1. Services
request/tracking web
application must work
in all major web
browsers.
2. Out of office entries
may not be reflected in
central system
immediately.
3. System must be secure.
4. System should not be
on the internet.
5. System must be
compatible with
existing hardware and
software components.
System Requirements
Functional Requirements
1. Manage Client Configuration
1.1. Enter New/Existing and Update
1.1.1. Hardware
1.1.1.1. Computers
1.1.1.2. Printers/Scanners/Copiers
1.1.1.3. Servers
1.1.1.4. Etc.
1.1.2. Software/Systems
1.1.2.1 Operating Systems
1.1.2.2. Usernames/Passwords
1.1.2.3. IP/Web/E-mail Addresses
1.1.2.4. Etc.
4. 2. Manage Service Requests
2.1. Enter New Service Request
2.1.1. Client
2.1.2. Technicians
2.1.3. Receptionist
2.2. View Service Request Status/History
2.2.1. Client (Only their own)
2.2.2. Technicians
2.2.3. Receptionist
2.2.4. Management
2.3 Update/Close Service Requests
2.3.1. Technicians
2.3.2. System Auto after 10 Days
3. Generate Statistics and Reports
3.1. TBD
4. System Log-ins
4.1. Client Log-in
4.2. User Log-ins
4.2.1. Technician
4.2.2. Receptionist
4.2.3. Management
Non-Functional Requirements
1. Operational Requirements
1.1. The system will operate in the Windows environment
1.2. The system should automatically back up at the end of each business day
1.3. The system should be accessible by multiple users simultaneously
1.4. The service request function should be accessible through a web page application
1.4.1. New Request Entry
1.4.1.1. Can be performed by clients, technicians, and receptionist
1.4.2. Existing Request Status/History
1.5. Client configuration changes should be saved before exiting
1.6. Inventory Scanners should connect wirelessly
1.7. The system should be searchable
2. Performance requirements
2.1. Inventory Scanners should recognize items within 2 seconds
2.2. System Search results should display within 10 seconds
2.3. System Statistics and Reports should generate within 30 seconds
2.4. Client configuration updates should be reflected in the system within 5 seconds
2.5. New service requests should be placed in queue within 5 seconds
5. 3. Security Requirements
3.1. Client configuration information should not be on the internet
3.2. Clients should only have access to their own service requests
3.3. System Access
3.3.1. Log-in
3.3.1.1. Each client and user will have a unique username and password
3.3.1.2. Passwords should be changed every 90 days
3.3.2. Time-out
3.3.2.1. Clients/users will be logged out after 30 minutes of inactivity
3.3.3. Technician only functions
3.3.3.1. Add/Update client configuration information
3.3.3.2. Update/close/cancel service requests
4. Cultural and Political Requirements
4.1. No special cultural and political requirements are anticipated
6. Context Diagram
Manager
Receptionist
Technician
Client
ServiceRequest Inquiry
Statistics/Reports Request
Statistics/Reports
ServiceRequest Status/History
Enter Service
Request
UpdateClient
Hardware/software
Configuration
ServiceRequest
inquiry
ServiceRequest
Status/History
Submit Service
Request
Submit Service
Request
Enter Service
Request
ServiceRequest
inquiry
ServiceRequest
Status/History
Enter Service
Request
ServiceRequest
inquiry
ServiceRequest
Status/History
Enter New
Inventory
9. Client
Technician
Management
Display
Unresolved
Requests/
History
View ServiceHistory
Display Service Record
Request for
ServiceRecord
Technician
Manually
Resolve
Service
Request
Problem is Solved
Confirmation of Resloution
UpdateService
Record
Technician
Process
Work Record
Entry
Enter Work Record
Create/Update
Work Record
Time
(Resolution
Clock)
Auto Resolve
Service
Request
Counter Reaches Zero
UpdateWork Record
Service
Requests
Return Requested Record
Service
Requests
Service
Requests
Set Resolution Clock to 48 Hours
ClientE-Mail Inquiry
Inquiry Response
Service
Requests
10. Technician
Process New
Component
Installation
Install New Component
Confirm Installation
Add New Component
In Database
Technician
Process Request
for Software
Configuration
View Client Configuration
Display Requested Information
Request for
Configuration Info
Technician
Process New
Equipment
Installation
Install New Equipment
Confirm Installation
Add New Equipment
In Database
Reception/
Bookkeeping
Process
Incoming
Inventory
Check-In Inventory
Add to/Update
Inventory Database
Client
Components
Client
Equipment
Client
Configuration
Return Requested Record
Inventory
11. Technician
Process
Configuration
Update
Enter Configuration Info
Confirmation of Update
Update Configuration
In Database
Any
Employee
Enter/Edit
Equipment
Type(s)
Add/Change
Equipment Type
Update Equipment
in Database
Technician
Process
Request for
Component
Information
View Components
Display Requested Information
Request for
Component Information
Client
Configuration
Client
Components
Return Requested Record
Standard
Equipment
Any
Employee
Enter/Edit
Component
Type(s)
Add/Change
Component Type
Update Component
in Database
Standard
Components
12. Reception/
Bookkeeping
Process New
Customer
Add New Client
Add Client
to Database Clients
Confirm Information
Manager
Process
Request for
Statistics/
Reports
View Statistics/Reports
Display Requested Information
Request for
Statistics/Reports CTTS
Return Requested Reports
15. Primitive Diagram
Technician
Process New
Component
Installation
Enter
Component
Confirm Installation
Add/Update Component
Client
Components
Validate
Client
Client ID
Select/
Validate
Equipment
Select
Component
Clients
Client
Equipment
Standard
Components
Client
Display Equipment
Component
Valid Equipment
Check/Edit
Date/
Quantity
Equipment
Selection
Scan
Component
Enter
Installation
Details
Invalid Client
Invalid Equipment
Error
Message
Enter Component Information Event
16. Entity/Definition Matrix
ENTITY BUSINESS DEFINITION
Client A customer who has a contract for services.
Component Any Hardware item in inventory that can be installed in a system. i.e.
DVD drives, NICs, etc.
Configuration Information about a client’s system such as usernames/passwords, IP
addresses, etc.
Equipment Any device such as a printer, PC, router, hub, etc. that the company
ensures is operational and handles warranty issues for.
Service Request A request placed in the system by a client/technician, or receptionist to
address a malfunction or improper performance of some part of a system.
Work Record An individual record of services performed by a technician on a service
request.
17. Context Data Model
Work Record
Service Request
Software Configuration
Equipment
Client
Component
Enters
Has
Owns
Owns
Contains
Key Based Data Model
Work Record
Service Request
Software Configuration
Client Equipment
Client
Client Component
Standard EquipmentStandard Components
Enters
Has
Owns
Owns
WorkNumPK
BarcodeFKPK
ClientIDPK
ReqNumPK
EquipNumFKPK
Configuration IDPK
Contains
ClientIDFK
ClientIDFK
ReqNumFK
EquipNumPKBarcodePK
ClientIDFKPK ClientIDFKPK
Contains Contains
18. Fully Attributed Data Model (in 3NF)
Work Record
Service Request
Software Configuration
Client Equipment
Client
Client Component
Standard EquipmentStandard Components
Enters
Has
Owns
Owns
WorkNumPK
BarcodeFKPK
ClientIDPK
ReqNumPK
EquipNumFKPK
ConfigurationIDPK
Contains
ClientIDFK
ClientIDFK
ReqNumFK
EquipNumPKBarcodePK
ClientIDFKPK
ClientIDFKPK
Contains Contains
ClientName
ContactFirstName
ContactLastName
Email
State
ReportDate
ReportedBy
Address
City
Zip
Equipment
InfoValues
InfoName
FinishTime
StartTime
ResolutionDate
WorkDate
WorkDescription
TechInitials
Vendor
ModelNum
DatePurchased
Description
EquipType
EquipName
InServiceDate
ComponentType
DateRemoved
DateInstalled
Quantity
19. Use-Case Glossary
Use-Case
ID
Use Case Name Use-Case Description Participating Actors and Roles
CTTS-001
Enter Service
Request
This use-case describes the event of a client,
technician, manager, or receptionist entering a
service request in the online application.
Client
Technician
Management
Receptionist/bookkeeper
CTTS-002
View Unresolved
Requests/History
This use-case describes the event of a user viewing
unresolved service requests and their history. A
client has access to only their service requests,
technicians can view unresolved requests they are
part of, and management will review unresolved
requests open for more than 72 hours.
Client
Technician
Receptionist/bookkeeper
CTTS-003 Enter Work Record
This use-case describes the event of a technician
entering a work record pertaining to an active service
request.
Technician
CTTS-004
Manually Resolve
Service Request
This use-case describes the event of a technician
completing a service request and marking it
“Resolved.”
Technician
CTTS-005
Automatically
Resolve Service
Request
This use-case describes the event of a service request
being considered resolved after a certain amount of
time has elapsed between the initial request and
follow up email.
Time
CTTS-006
Enter Component
Information
This use-case describes the event of a technician
entering new, or updating existing client component
information.
Technician
CTTS-007 Enter New Equip
This use-case describes the event of a technician
entering new, or updating existing client equipment
information.
Technician
CTTS-008
View Software
Configuration Info
This use-case describes the event of a technician
retrieving existing client configuration information
from the database.
Technician
CTTS-009 Check In Inventory
This use-case describes the event of the
Receptionist/bookkeeper entering new inventory
items as they arrive in orders.
Receptionist/bookkeeper
CTTS-010
Enter Configuration
Information
This use-case describes the event of a technician
entering new, or updating existing client
configuration information.
Technician
CTTS-011
View Installed
Components
This use-case describes the event of a technician
retrieving existing client component information
from the database.
Technician
CTTS-012
Enter/Edit Equip
Type
This use-case describes the event of an employee
entering new, or editing existing standard equipment
information.
Any Employee
CTTS-013
Enter/Edit
Component Type
This use-case describes the event of an employee
entering new, or editing existing standard component
information.
Any Employee
CTTS-014 Enter New Client
This use-case describes the event of the
Receptionist/bookkeeper adding a new client to the
CTTS.
Receptionist/bookkeeper
20. Use-Case Model Diagram
Enter New
Client
Enter/Edit
Component Type
Enter/Edit
Equip Type
Enter New
Equipment
View
Component
Info
Enter
Component
Info
View
Configuration
Info
Enter
Configuration
info
Enter Service
Request
Enter Work
Record
View Unresolved
Request(s)
AutoManual
Resolve Request
Check In
Inventory
Client
Employee
Technician
Manager
Recept/Book
Time
* I highlighted the generalization relationships in yellow to help avoid confusion.
21. Fully-documented Use Case Narrative
CTTS
Author (s): Nicholai Stevens___ Date: _02/21/2014__
Version: ___1.0______
USE CASE NAME: View Unresolved Requests/History USE CASE TYPE
USE CASE ID: CTTS-002 Business Requirements:
PRIORITY: High System Analysis:
SOURCE: Management, Business Requirement
PRIMARY BUSINESS ACTOR Client
PRIMARY SYSTEM ACTOR Technician, Management, Client
OTHER PARTICIPATING
ACTORS:
Technician, Management, Client
OTHER INTERESTED
STAKEHOLDERS:
N/A
DESCRIPTION: This use-case describes the event of a user viewing unresolved service requests and their history. A
client has access to only their service requests,technicians can view unresolved requests they are
part of, and management will review unresolved requests open for more than 72 hours.
PRE-CONDITION: In order to execute this this use case the user must be logged in and verified.
TRIGGER: This use case is initiated when a user selects the “View Unresolved Requests” option from their
home screen in the online requests system.
TYPICAL COURSE OF
EVENTS:
Actor Action System Response
Step 1: A user selects the “View Unresolved
Requests” option from their home screen in the
online requests system.
Step 2: The systemdisplays a list of all requests
relevant to the userbased on their log-in
information that have not been marked resolved.
Step 3: The user selects the unresolved request
they wish to see additional details about.
Step 4: The systemdisplays the detail
concerning the unresolved request including the
original request information and any work
records pertaining to the request.
Step 5: The user may now review the
information and return to the previous screen
which initiates Step 2.
Step 6: When finished the user may close the
unresolved requests list and return to their home
page.
ALTERNATE COURSES: Alt Step 2: If no unresolved requests are available for that user the systemwill display the
appropriate message.
Alt Step 5a: If the useris a technician, he/she will have the option to add a new WorkRecord to the
request.If this is selected the systemwill launch use case CTTS-003. Upon completion the system
returns to Step 4.
Alt Step 5b: If the service request has been completed a technician or management can change the
status ofthe request to “resolved.” This will initiate use case CTTS-004. Once a request has been
marked resolved, the systemreturns to Step 2.
CONCLUSION: This use case successfully ends when the usercloses the “View Unresolved Requests” screen,and
returns to their home page.
POST-CONDITION: None
BUSINESS RULES None
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
This function will be carried out through a web based application. The information will be
stored in a database that will be updated and queried through the web application.
ASSUMPTIONS: None
OPEN ISSUES: None
22. Activity Diagram
Request to View
Unresolved Requests
Retrieve Relevant
Requests
Display Message
Display List
No Unresolved Requests
1 or More
Unresolved Request
Return to List
Tech/Manager:
Resolve Request
Techs: Add New
Work Order
Select Request to
View Details
Retrieve Details
Display Details
ш
Add Work Record
Activity
Update Record
Update List
Exit Unresolved
Request Page
23. System Sequence Diagram
User :System :Service Requests :Work Records
View Unresolved Requests
Retrieve Appropiate
Records
Return List/Message
Select Record for Details
Retrieve Details
Return Detail
Add Work Record
Relay New Work Record
UpdateService Request
Return Detail
Reslove Request
UpdateRequest status
Return Updated
List/Message
Exit
Display List/Message
Display Detail
Display Detail
Display List/Message
25. Candidate Matrix
Characteristics Candidate 1:
Desk.com Plus Plan
Candidate 2:
Kayako Case
Candidate 3:
Custom Build
Portion of System
Computerized
Brief description of that portion of
the systemthat would be
computerized in this candidate.
This package would be purchased
and customized to fulfill the
requirements of thecustomer
service request management
portion of thesystem.
Same as Candidate 1. This option requires an extension
application to be built from
scratch to fulfill therequirements
of the customer service request
management portion of the
system.
Benefits
Brief description of the business
benefits that would be realized for
this candidate.
Because this solution is purchased
the time frame for implementation
is very short. It also comes with
support services and is cloud
based which reduces processing
load.
Same as candidate 1.
Alternatively, this solution can be
purchased and downloaded to be
run directly from in-house
equipment for additional control
Because this is a customin-house
build, thesystemcan be designed
around current business practices
and no unnecessary functionality
will be included.
Servers and Workstations
A description of the servers and
workstations needed to support
this candidate.
Windows 7 class servers and
workstations
Same as Candidate 1. Same as Candidate 1.
Software Tools Needed
Software tools needed to design
and build the candidate (e. g.,
database management system,
emulators, operating systems,
languages, etc.). Not generally
applicable if applications software
packages are to be purchased.
N/A Package Solution Same as Candidate 1. Microsoft FrontPage, Visual C++,
Web browser of choice
Application Software
A description of the softwareto be
purchased, built, accessed, or
some combination of these
techniques.
Package Solution Same as Candidate 1. CustomSolution
Method of Data Processing
Generally some combination of:
on-line, batch, deferred batch,
remote batch, and real-time.
Online Online, Client/Server Same as Candidate 2
Output Devices and
Implications
A description of output devices
that would be used, special output
requirements, (e.g. network,
preprinted forms, etc.), and output
considerations (e.g., timing
constraints).
Various inkjet/laser printers Same as Candidate 1. Same as Candidate 1.
Input Devices and Implications
A description of Input methods to
be used, input devices (e.g.,
keyboard, mouse, etc.), special
input requirements, (e.g. new or
revised forms from which data
would be input), and input
considerations (e.g., timing of
actual inputs).
Keyboard and Mouse, Mobile
devices with app
Same as Candidate 1. Keyboard and Mouse
Storage Devices and
Implications
Brief description of what data
would be stored, what data would
be accessed from existing stores,
what storage media would be
used, how much storage capacity
would be needed, and how data
would be organized.
Client info, Request history stored
by service provider
Same as Candidate 1.
Or, if downloaded information
will be stored in relational SQL
server DBMS. 2TB capacity.
Same as Candidate 2.
26. Feasibility Matrix
Feasibility Criteria Wt. Candidate 1 Candidate 2 Candidate 3
Operational Feasibility
An assessment of how well the
solution meets theidentified
systemrequirements to solve the
problems and take advantage of
the opportunities envisioned for
the system.
15%
Solution fully supports
required functionality, but is
cloud based making access
to the systemcontingent on
internet connection.
Score: 90
Solution fully supports
required functionality
Score: 100
Solution fully supports
required functionality
Score: 100
Cultural/Political Feasibility
An assessment of how well the
solution will be accepted in a
given organizational climate.
15%
No foreseeable problems
Score: 100
No foreseeable problems
Score: 100
No foreseeable problems
Score: 100
Technical Feasibility
An assessment of the practicality
of the solution and theavailability
of technical resources and
expertise to implement and
maintain it.
20% Packaged solution is web
based and maintained by
provider. Only resources
required from staff are initial
set up/customization and
minor changes in thefuture.
Score: 95
Same as Candidate 1.
If program is run on in
house server one year of
support is provided and
then maintenance
responsibility will shift to
staff.
Score: 90
Custombuild can be
implemented and
maintained without issues
but this will take away
from other
responsibilities.
Score: 80
Economic Feasibility
An assessment of the cost-
effectiveness of a project or
solution.
Cost to develop:
Payback period (discounted):
Net present value:
Detailedcalculations:
30%
~ $4153
<1 year
$15,612
See Attached Documents
Score:85
~ $4153
<1 year
$15,612
See Attached Documents
Score:85
~$3740
<1 year
$20,115
See Attached Documents
Score:95
Schedule Feasibility
An assessment of how long the
solution will take to design and
implement.
10%
Less Than 2 months
Score: 95
Less Than 2 months
Score: 95
4-6 Months
Score: 85
Legal Feasibility
An assessment of how well the
solution can be implemented
within existing legal and
contractual obligations.
10% No foreseeable problems
Score: 100
No foreseeable problems
Score: 100
No foreseeable problems
Score: 100
Ranking: 100
%
92.5 93 93
28. Net Present Value
Desk.com
Cash Flow Description Year 0 Year 1 Year 2 Year 3 Total
Development Cost: ($4,153)
Operation &
Maintenance Cost:
$2,796 $3,000 $3,200
Discount Factor for 10% 1.000 .909 .826 .751
P.V. ofAnnual Costs: ($4,153) ($2,542) ($2,478) ($2,403)
T.P.V. of lifetime costs: ($11,576)
Benefits Derived: $0 $10,000 $11,000 $12,000
Discount Factor for 10% 1.000 .909 .826 .751
P.V. ofAnnual Benefits: $0 $9,090 $9,086 $9,012
T.P.V. of lifetime
benefits:
$27,188
NPV of this alternative: $15,612
Kayako Case
Cash Flow Description Year 0 Year 1 Year 2 Year 3 Total
Development Cost: ($4,153)
Operation &
Maintenance Cost:
$2,796 $3,000 $3,200
Discount Factor for 10% 1.000 .909 .826 .751
P.V. ofAnnual Costs: ($4,153) ($2,542) ($2,478) ($2,403)
T.P.V. of lifetime costs: ($11,576)
Benefits Derived: $0 $10,000 $11,000 $12,000
Discount Factor for 10% 1.000 .909 .826 .751
P.V. ofAnnual Benefits: $0 $9,090 $9,086 $9,012
T.P.V. of lifetime
benefits:
$27,188
NPV of this alternative: $15,612
Custom Build
Cash Flow Description Year 0 Year 1 Year 2 Year 3 Total
Development Cost: ($3,740)
Operation &
Maintenance Cost:
$1,200 $1,350 $1,500
Discount Factor for 10% 1.000 .909 .826 .751
P.V. ofAnnual Costs: ($3,740) ($1,091) ($1,115) ($1,127)
T.P.V. of lifetime costs: ($7,073)
Benefits Derived: $0 $10,000 $11,000 $12,000
Discount Factor for 10% 1.000 .909 .826 .751
P.V. ofAnnual Benefits: $0 $9,090 $9,086 $9,012
T.P.V. of lifetime
benefits:
$27,188
NPV of this alternative: $20,115
29. Clients
Destin:
Coastline
Consulting
Windows Server 2012
SQL/Server
Database Server
Windows Server 2012
With IIS
SQL/Server
Web Server
8
Windows 7 Pro
Clients
Any Client
with a Browser
Windows 7 Pro
And
IEor Firefox
100 MB/sec
TCP/IP Ethernet
Or
Wifi Access
Internet Explorer
or
Firefox
Browser
Middleware
100 MB/sec
TCP/IP Ethernet
Internet Explorer
or
Firefox
Network Architecture Physical DFD
31. Design Use Case Narrative
CTTS
Author (s): Nicholai Stevens Date: _04/08/2014__
Version: __1.1_________
USE CASE NAME: View Unresolved Requests/History USE CASE TYPE
USE CASE ID: CTTS-SDUC002 Business Requirements:
PRIORITY: High System Analysis:
SOURCE: Business Requirement
Analysis Use Case CTTS-002
System Design:
PRIMARY BUSINESS ACTOR Client
PRIMARY SYSTEM ACTOR Technician, Management, Client
OTHER PARTICIPATING
ACTORS:
Technician, Management, Client
OTHER INTERESTED
STAKEHOLDERS:
N/A
DESCRIPTION: This use-case describes the event of a user viewing unresolved service requests and their
associated history through the web application. A client has access to only their service
requests,technicians can view unresolved requests they are part of, and management will
review all unresolved requests and specifically request to view requests open for more than 72
hours.
PRE-CONDITION: In order to execute this this use case the user must be logged into the systemand window W002-
Service Requests, is displayed.
TRIGGER: This use case is initiated when a user clicks the [Unresolved Requests]button from the Service
Requests window in the online requests system.
TYPICAL COURSE Actor Action System Response
OF EVENTS: Step 1: The user clicks the [Unresolved
Requests]button.
Step 2: The systemdisplays window W004 -
Unresolved Requests, a list showing all
records relevant to the user based on their log-
in credentials that have not been marked
resolved. All records will be displayed on one
page.
If the list is longer than can be displayed in the
window a scroll bar will automatically appear.
Step 3: The user scrolls through the available
items using the scroll bar if necessary,and
then selects the unresolved request they wish
to examine more closely by clicking on it.
Step 4: The systemdisplays window W007-
Request Detail. This will showthe original
request information and any work records
associated with the request selected by the
user.
Step 5: When the user is finished reviewing
the request they can click the [OK] button in
the window or the [Back] button in their
browser to return to the Unresolved Requests
window.
Step 6: System returns to step 2.
Step 7: When the user is finished reviewing
the unresolved requests they can exit the
Unresolved Requests window by clicking the
[OK] button.
Step 8: The systemwill display window
W002- Service Requests.
ALTERNATE COURSES: Alt Step 2: If no unresolved requests are available for that user the systemwill display the pop-
up window W-001- No Results Found, which indicates that no records match their request.The
user then clicks the [OK] button and the systemreturns to the Service Requests window.
Alt Step 5a: If the useris a technician, he/she can add a new WorkRecord to the request.If the
[Add Work Order] button is clicked the systemwill launch use case CTTS-003 (Add work
Order). Upon completion the systemreturns to Step 4.
Alt Step 5b: If the service request has been completed a technician or management can change
the status ofthe request to “resolved.” If the [Resolve] button is clicked the systemwill update
the status ofthe request. Once a request has been marked resolved, the systemreturns to Step 2.
32. CONCLUSION: This use case successfully ends when the usercloses window W004 - Unresolved Requests, and
returns window W002- Service Requests.
POST-CONDITION: If work records were added or request status was changed,all copies of the record(s) will be
updated and Window W002- Service Requests, is displayed.
BUSINESS RULES The manager will have an additional [Delayed Requests]button that retrieves all
service requests that are more than three days old and are unresolved.
Clients will only have access to their own service request records.
Only technicians can enter work orders
A technician, management user, or the client can manually change a service request
status to “Resolved”
An automatic resolution systemis also being designed that will be integrated as well.
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
Use case must be available to clients and technicians 24/7.
Updates should occur immediately.
Frequency – It is estimated that the use case will be executed no more than 500 times a
day. It should support up to 30 concurrent users.
ASSUMPTIONS: The connection will be secure to ensure confidentiality.
OPEN ISSUES: None
Sequence Diagram
View Unresolved Requests/History
loop
User
<<interface>>
:Service Request
<<interface>>
:Unresolved Requests
<<interface>>
:Request Details
:Request History
Query
:ServiceRequest
<<controller>>
:View Requests
Click
"Unresolved
Requests"
getRequests(unresolved)
retrieveRecords
Unresolved Requests
Select specific record
getRequestHistory(requestNum)
Servicerequest details
Exit [OK]
retrieveRecord
Exit [OK]
x
x
x
x
34. State Machine Diagram
Service Request Lifecycle
Unresolved
Worked On
Resolved
Resolution Pending
Work Record
Entered
Auto Email
To Client
(48hrs)
Manual
Resolution
Request
Closed
No Response
(24hrs)
Client
Responds
Request Submitted
35. Testing
Before the testing begins, sample data should be input for multiple clients. Sample data should include multiple service requests
in varying states (resolved/unresolved) with varying numbers of related work records. Some should be more and some should be
less than 72 hours old.
Unit Tests
Test 1:Unresolved Requests list display test.
Description: This test will ensure that only the appropriate service request records are displayed when a user selects the
option to view unresolved requests from the web page home. This test should be performed for each class of user;
technician, client, and management.
Method: White-Box,Control structure (branch, condition)
Test 2: Request Detaildisplay test.
Description: This test will ensure that when the “view” link next to an unresolved service request is clicked, the
appropriate details concerning the original request and any related work records are retrieved displayed.
Method: White-Box,Control structure (condition, data flow)
Test 3: Request Resolution initiation test.
Description: This test will verify the functionality of the UI link “resolve” in the request_detail page. This test will also
cover the verification of user status when attempting to resolve a request.
Method: White-Box,Control structure (branch, condition)
Test 4: Manager Review of delayed requests test.
Description: This test will verify that only service requests which have not been resolved and are more than 72 hours
old are displayed when a manager user selects the option to view unresolved requests from the web page home.
Method: White-Box,Condition
Test 5: No unresolved requests test.
Description: This test will verify the appropriate message display when there are no unresolved requests to display.
Method: White-Box,Control structure (branch, condition)
Test 6: Unauthorized request resolution command test.
Description: This test will ensure that either an error message is displayed if the user is not authorized to resolve a
request, or that the “resolve” link is not available to users who are not authorized.
Method: White-Box,Condition
36. Program Tests
*Each of these tests will be performed through the ASP.NET web application written for this system.
Test 1: Method: Black-Box
Precondition- User logged-in and verified as a client. Client has one or more unresolved
requests.
Trigger- User selects the option to view unresolved requests from the web page home.
Conclusion- Userexits unresolved requests list page.
Post condition- N/A
Business Rules-N/A
In this test the user will select the option to view unresolved requests from the web page home. The system will then
display the Unresolved Request list along with a “view” hyperlink for each. This list should be specific to the client. The
user will then select an unresolved request to review further. The system should display all details concerning the
request and any associated work records. Because the user has been verified as a client they have the option to change
the status of the unresolved request to “resolved”. When the user selects the “resolve” link the Use case for manually
resolving service requests is initiated.
Test 2: Method: Black-Box
Precondition- User logged-in and verified as a Technician. Technician has one or more related unresolved requests.
Trigger- User selects the option to view unresolved requests from the web page home.
Conclusion- Userexits unresolved requests list page.
Post condition- N/A
Business Rules-N/A
In this test the user will select the option to view unresolved requests from the web page home. The system will then
display the Unresolved Request list along with a “view” hyperlink for each. This list should be specific to the technician;
however they should have an option to reviewother requests if necessary. The user will then select an unresolved
request to review further. The system should display all details concerning the request and any associated work records.
Because the user has been verified as a technician they have the option to change the status of the unresolved request to
“resolved”. When the user selects the “resolve” link the Use case for manually resolving service requests is initiated.
Test 3: Method: Black-Box
Precondition- User logged-in and verified as a Manager. There are one or more unresolved requests that have
been active for more than 72 hours.
Trigger- User selects the option to view unresolved requests from the web page home.
Conclusion- Userexits unresolved requests list page.
Post condition- N/A
Business Rules-N/A
In this test the user will select the option to view unresolved requests from the web page home. The system will then
display the Unresolved Request list along with a “view” hyperlink for each. This list should contain only those
unresolved requests that are more than 72 hours old; howeverthe manager should have an option to reviewother
requests if necessary. The user will then select an unresolved request to review further. The system should display all
details concerning the request and any associated work records. Because the user has been verified as a manager they
have the option to change the status of the unresolved request to “resolved”. When the user selects the “resolve” link the
Use case for manually resolving service requests is initiated.
37. *Each of these tests should be repeated with the precondition changed such that no unresolved requests meet the criteria for
being displayed. This should confirm the proper functionality of the appropriate messages.
* During these tests,the functionality of UI features such as scroll bars,button, and etc. should be confirmed as well.
Staff Assignments
Testing: Anna Kelly will be responsible for the majority of the unit and program testing and documentation. Her role as the
developer of this system makes her uniquely qualified to adequately test the functionality of the system. She may recruit
Dane Wagner (Web Server Administrator) to assist in the testing of the system’s ability to perform under stress.
Test Review: Because smalldetails can be missed when working closely with a system it is important to have someone other
than those who performed the tests review them. Peter Charles (president) is just as familiar with the expected
performance of the system and should be responsible for reviewing the test results.
Sign off: As the president of the company, Peter Charles is ultimately responsible for the final sign off.
Conversion Plan
Section I: Conversion Strategy
A. Overview of conversion strategies
Abrupt cut-over. In this method the old system is shut down and the new system is made operational on a
predetermined date. There are pros and cons to this approach. Financially, this approach is great because there
are no transition costs. Operationally however, there is the risk that a major issue was missed in testing and the
system, or parts of it, may fail.
Parallel conversion. In a parallel conversion the old system and the new one operate simultaneously for a
period of time. The pros and cons to this method are the inverse of the abrupt cut over. Since the old system is
still operational, if an unforeseen issue with the new system arises, business operations can still be performed.
However, there is the additional cost of having two systems running at once. This approach may not be
possible if the network cannot support both systems simultaneously. Once the conversion begins the old
system can be terminated all at once or a little at a time once the functionality of the new system has been
confirmed.
Location conversion. This method is used when there are multiple geographical locations implementing the
new system. Generally one location, often called the beta test site, implements the new system before the
others. This can be done with either the abrupt or parallel method. Once the entire system is operational and
approved the remaining sites can make an abrupt cut over. With this method the risk involved in the abrupt cut
over for the subsequent locations is greatly reduced because most of the issues will have been discovered at
the beta site.
Staged conversion. This method utilizes multiple versions of the new system. As each version of the system is
developed it is implemented. Any of the three previously discussed methods can be used to execute this
implementation.
B. Recommended conversion strategy for CTTS
I recommend the abrupt cut-over conversion strategy for implementing the CTTS. The current systems they
have in place are not very organized and very inefficient so maintaining them any longer than necessary is not
recommended. If there is a problem with the new system, going back to hand written methods temporarily will not be
difficult.
38. Section II: User Documentation
A: Sources for documentation
When creating a user manual much of the documentation created throughout the process can be used as
reference. Documents/diagrams such as; use cases narratives, activity diagrams, sequence diagrams, state machine
diagrams, etc.
B: Outline of a Proposed User manual
Introduction:
- Overview of new system
- Overview of new equipment
Getting Started:
- Adding/removing users (Coastline staff only)
- Logging in
- Setting/changing password
Internal Operations: (Coastline staff only)
- Inventory
- Input
- Equipment/components
- Add/update
- Client Configurations
- Enter/update
Service Requests:
- Add new
- Reviewing
- All
- Unresolved
- Responding
- Add Work Order (Coastline staff only)
- Resolution
-Manual
- Auto
Appendixes
- Glossary
- Diagrams
- References
C: Recommended Format for Manual (Hard copy vs. Online)
For the manuals I recommend having a comprehensive version online with one hard copy kept at the central
office. I also recommend and a one page (front and back) pamphlet to be provided to all users with quick reference
instructions for commonly used features.
D: Staff responsibilities
39. Anna Kelly will be responsible for developing the training materials for this system. Kathy Grey (receptionist)
will assist in editing the materials and Peter Charles will give the final approval before printing.
Section III: User Training
A: Review of training alternatives
One-on-One training. In this method an instructor goes over the system with each user individually.
This method is the most time consuming and expensive, but very effective.
Hands-on classroom style instructor-led training. In this approach up to 30 users can be walked
through the training while they perform the tasks on their computers. This method saves time and
money, and also gives the users some practice.
Seminar style group demonstration. In this method an instructor demonstrates how things are done
while the users watch and take notes.
Computer Based Training. In CBT users can learn at their own pace, via an interactive lesson.
Book-based self-paced training. In this approach users are given manuals and can complete workbook
lessons.
B: Recommended training plan for CTTS
Because the number of staff at Coastline is less than 10, a one day Hands-on classroom style instructor-led
training session is the best choice. Each staff member has participated in the development of the new system at some
level, so there should be an overall sense of familiarity. This is also a group of technically trained professionals so
their existing knowledge should make the training relatively easy.
For introducing the clients to the new system I recommend the computer based training. Creating an
instructional video that can be accessed online is the best way to distribute the information to their growing client
base. This also provides a resource that can be accessed before contacting customer service or outside of business
hours.
C: Staff responsibilities
Anna Kelly will organize and lead the user training. Kathy Grey will be responsible for printing and
distributing training materials. And. Peter Charles will provide the venue and refreshments for the training session.
Approaches to Technical Support
Technical support is an ongoing set of routine activities intended to provide users additional assistance
concerning issues with the day-to-day use of specific applications. In order to provide adequate support several tasks
should be performed. These tasks result in information that can be used to deliver effective technical support and a
more user friendly, bug free system. Some of these tasks include:
Observing the use of the system
Conducting user satisfaction surveys and meetings
Changing business procedures
Providing additional training when required
Logging enhancement ideas and requests
40. Technical Support recommendations for CTTS
For the CTTS system implemented at Coastline Consulting I think all of these activities should be used to
some degree. Observing the use of the system will provide insight into things like high volume times and who is using
the system. User satisfaction surveys should be sent out soon after the system is implemented. These can be used to
identify any additional changes that can be made to improve the system. Because this system will require new
business procedures for most of the activities performed by each employee, it is likely that more efficient ways to use
the system will be discovered over time. Additional training will need to be provided to new employees and clients as
the business continues to grow. Lastly all enhancement requests and ideas should be logged in the repository. By
keeping records of all these things there will be an excellent resource for requirements analysis in future iterations of
the system.
Coastline does have the option of outsourcing the tech support responsibilities, however since they are a small
company I think it should handled internally. That being said I do think that they should hire a new employee to
oversee the new system or to take over Anna Kelly’s role as a web developer so she can act as the system
administrator.
