Defining Requirements for an Incident Management System: A Case Study

1
Defining Requirements for an Incident Management
System A Case Study

• Marko Jäntti
• Department of Computer Science
• University of Kuopio
• marko.jantti_at_uku.fi

2
Agenda

• Introduction
• Research Question Methods
• Defining Requirements for the Incident Management
  System
• Analysis
• Conclusion

3
Introduction

• An incident management process is performed by
  the service desk.
• The service desk records each incident in the
  incident management system.
• IT Infrastructure Library (ITIL) service
  management framework describes how to build a
  service desk and an incident management process
• An incident is an unplanned interruption to an
  IT service or reduction in the quality of an IT
  service

Software Failures
Service Requests
Incidents
Hardware Failures
4
Introduction

• Incident management is a very tool-oriented
  process.
• Service desk workers use various applications
  while searching solutions to the incidents
• The core system is always an incident management
  system that consists of incident records,
  escalation rules, customer / user information, CI
  information etc.
• Our contribution in this paper was to
• examine what types of requirements should be
  taken account in establishing an incident
  management system
• provide information about the questions that were
  raised during the requirement specification
  process

5
Research Question Methods

• Research question what types of requirements
  should be taken account in building an incident
  management system?
• Research methods A case study action research
• Case organization the IS department of Kuopio
  University hospital in Finland.
• ISO 20 000 service management standard as a goal
• Incident management (IM) is one of the required
  processes in ISO 20 000 -gt resulted in an IM tool
  development project
• Multiple data collection methods
• participative observation (process improvement
  meetings and tool specification meetings),
  interviews/discussions, access to documents

6
Defining requirements for the incident management
system

• Requirements specification meeting I an overview
  of the tool specification project
• What is the relation of incidents and problems
  and requests for change? -gt separate records
• How should the tool handle requests that are
  related to administrative tasks? -gt categorized
  as service requests
• Is customer information hierarchical information?
  -gt yes
• How requests for change differ from service
  requests and incidents? -gt Use an RFC e.g. when a
  change in program code is needed

Incident Hardware/Software failures Service
requests
Problem
RFC
Known error
7
Defining requirements for the incident management
system

• Requirements specification meeting II incident
  classification
• Can several incidents be closed at the same time?
• Who is responsible for closing an incident?
• When is it possible to close an incident?
• What types of attributes should be included in
  the incident record?
• Is it possible that an incident causes several
  request for changes?
• When do we need to open a problem record?

8
A use case diagram of the IM system
9
Analysis

• Lessons learnt from requirements specification
  meetings regarding the IM system
• Each IT service management process manager should
  participate in the incident management tool
  specification
• Enough time should be reserved for generating a
  complete set of incident/problem categories
• Incident, problem and request for change records
  should be separate record in the incident
  management system.
• The incident management system should contain
  self service desk modules
• The priority of the incidents and problem should
  be based on impact and urgency

10
Conclusion

• This study aimed to answer the research question
  what types of requirements should be taken
  account in building an incident management
  system?
• Functional reqs Submit request, Check the
  request status, Create request, Assign request,
  Update request, Relate request, Configure
  settings, Create reports, Maintain knowledge
  base, Maintain workflow, and Maintain registers.
• Besides incidents, the system should handle
  service requests, problems and requests for
  change.
• Data requirements 23 incident attributes were
  identified.
• Further work is needed is needed to investigate
  the design, deployment and the introduction of IM
  systems.

11
Thank you!!

• Any questions or comments?
• Email marko.jantti_at_uku.fi