Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 1 of 6

BMC Software Consulting Services Fermilab Computing Division Fermilab Incident Management Business Process Requirements

Client: Fermilab Date : 01/28/2009 Version : 1.0

GENERAL This document establishes the Incident Management (IM) Business Description Requirements This procedure provides the necessary steps and details for the Service Purpose Manager Consultant to acquire and determine the business requirements for a customer seeking to implement Incident Management

Applicable to Incident Management ISO20000 Project

Supersedes N/A

Document Incident Manager Owner Org Computing Division Owner

Revision Date 01-28-2009

© 2009 Plexent Proprietary Information Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 2 of 6

VERSION HISTORY

Version Date Author(s) Change Summary 1.0 1/28/2009 David Whitten – Initial Document Plexent LLP

BUSINESS PROCESS REQUIREMENTS

© 2009 Plexent Proprietary Information Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 3 of 6

Business requirements describe the tasks the users must be able to accomplish with the process. Business requirements reflect business processes and are generally written in the format verb + object. The preferred format is the MoSCoW ranking system for determining the process requirements for the customer.

MoSCoW Ranking [Key = M, S, C, W] M: Must have for launch (Critical). S: Should have but not critical for launch, (but critical for roll out or some part of it is). C: Could have. W: Won’t have (yet). How to use this form: Discuss with the client the current processes and map the current processes to the eight steps within the itDNA elements within this document. Once mapped, determine in conjunction with the client, which items must be included in the new process (M), which ones should be included (S), determine if the process could have the item (C) and determine if there are items that they currently perform that won’t be in the new process (W).

Fill out the table below with the Incident Management requirements under their respective process areas and then prioritize the requirements based on how important to the customer they are.

© 2009 Plexent Proprietary Information Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 4 of 6

INCIDENT MANAGEMENT BUSINESS PROCESS REQUIREMENTS Item # Business Owner MoSCoW Priority Requirement Ranking (1=Highest 5 = Lowest) 1.0 Incident Incident Detection Manager 1.1 Ability to receive Service Desk M 1 incident Analyst information manually 1.2 Ability to receive Incident C 3 incident Manager information automatically 1.3 Store data Incident M 2 received from Manager Incident gathering

2.0 Incident Incident Classification Manager 2.1 Assign a Service Desk M 1 category to an Analyst incident 2.2 Align categories Incident M 2 to Change and Manager Problem Management 2.3 Searchable Incident M 2 incident records Manager 2.4 Capable of Incident M 1 associating Manager incidents using a Parent/child relationship

© 2009 Plexent Proprietary Information Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 5 of 6

INCIDENT MANAGEMENT BUSINESS PROCESS REQUIREMENTS Item # Business Owner MoSCoW Priority Requirement Ranking (1=Highest 5 = Lowest) 2.5 Ability to Incident M 1 determine Manager urgency, priority, and criticality of an incident 2.6 Service Desk Service Desk M 2 Analyst can Analyst begin critical incident management if necessary 2.7 Provide ability to Incident M 2 appropriately Manager assess the impact of the incident 3.0 Initial Incident Support 3.1 Provide means Incident M 2 for the Service Manager Desk Analyst to quickly resolve an incident 3.2 Capable of Incident S 1 assigning a Manager priority to the incident 3.3 Provide updates Service Desk S 2 to the client/end Analyst user 4.0 Incident investigation and diagnostics

© 2009 Plexent Proprietary Information Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 6 of 6

INCIDENT MANAGEMENT BUSINESS PROCESS REQUIREMENTS Item # Business Owner MoSCoW Priority Requirement Ranking (1=Highest 5 = Lowest) 4.1 Ability to assign Service Desk M 1 incident tickets to Analyst the appropriate team 4.2 Ability to re- Service Desk M 1 assign tickets as Analyst necessary 4.3 Capable of Service Desk M 2 including other Analyst team members, consultants, support groups and contractors as needed 4.4 Allow for 3rd party Incident S 2 support within Manager the process 4.5 Provide a Incident M 2 resolution loop Manager with the ability to document the resolution 4.6 Suspension of Service Desk S 1 the service clock Analyst is required for adherence to Service Level Agreements 5.0 Incident Resolution

© 2009 Plexent Proprietary Information Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 7 of 6

INCIDENT MANAGEMENT BUSINESS PROCESS REQUIREMENTS Item # Business Owner MoSCoW Priority Requirement Ranking (1=Highest 5 = Lowest) 5.1 Provide Service Desk M 1 continued Analyst communication with the client/end-user and continue informing them of the status of the incident and resolution 5.2 Process Incident C 3 integration with Manager Change Management and the ability implement a change 5.3 Ability to stop the Service Desk C 3 resolution of the Analyst incident if there is no known solution 5.4 Procedure to Service Desk M 1 update the Analyst incident and track solution within the incident process 5.5 Service Desk Service Desk M 1 validate service Analyst is restored

© 2009 Plexent Proprietary Information Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 8 of 6

INCIDENT MANAGEMENT BUSINESS PROCESS REQUIREMENTS Item # Business Owner MoSCoW Priority Requirement Ranking (1=Highest 5 = Lowest) 5.6 Service Desk Service Desk M 1 validate the Analyst incident priority, category, urgency prior to closing the incident 6.0 Incident Restoration 6.1 Ability to identify Service Desk M 2 the recovery Analyst solution 6.2 Maintain Incident M 1 communication Manager with the client of the potential solutions 6.3 Integrate with the Incident C 3 Change Process Manager for the resolution of the incident 6.4 Ability to stop the Service Desk S 3 resolution Analyst process 7.0 Incident Closure 7.1 Capable of Service Desk M 2 identifying Analyst criticality of the ticket during incident closure 7.2 Ability to verify Service Desk M 1 restoration of the Analyst incident

© 2009 Plexent Proprietary Information Fermi National Laboratory CUSTOMER REQUIREMENTS DOCUMENTATION Revision Date 01/28/2009 Version 1.0 ONLY THE ONLINE SYSTEM HAS THE CURRENT VERSION. VERIFY COPY AGAINST THE ONLINE SYSTEM BEFORE USE. Page Page 9 of 6

INCIDENT MANAGEMENT BUSINESS PROCESS REQUIREMENTS Item # Business Owner MoSCoW Priority Requirement Ranking (1=Highest 5 = Lowest) 7.3 Service desk Service Desk M 2 communicates Analyst resolution to the customer 7.4 Verification of Service Desk M 1 the incident Analyst details as they relate to the configured item and the impacted service, the process allows for the updating of the incident 8.0 Incident Ownership, Monitoring and Tracking 8.1 Maintain the Service Desk M 1 ability to monitor Analyst active incidents 8.2 Ability to perform Incident M 1 hierarchical Manager escalation 8.3 Ability to perform Incident M 1 functional Manager escalation 8.4 Provide ability to Incident C 2 communicate to Manager clients or end- user community as needed

© 2009 Plexent Proprietary Information