Template: Service Design & Transition Package
Version 1.1
This document is a template for creating a service design and transition package (SDTP).
Comments & usage guidance
- This template provides a generic structure to be applied for defining and documenting a service design and transition package, which can be useful in a situation where a service provider is planning to extend their service portfolio and to implement a new service.
- It can be used both to propose and evaluate services, as well as to plan the design, development and deployment of services that the provider has decided to create.
- The first section considers the conceptual design of a service, the need for it and broad way it will create value for a customer. This section can be used in order to assess the potential for creating a new service.
- The second section considers the service and technical design of the proposed new service. This details how it is built up out of service components and what technical elements and infrastructure it relies on.
- The third section considers deployment of the service, including service acceptance criteria and deployment plans.
-
For this template and its contents, the terminology (terms and definitions) according to FitS
M-0 applies.
Document control
|
Document Title |
Template: Service Design & Transition Package |
|
Document version |
1.1 |
|
Release date |
2015-07-29 |
Table of Contents
1.3 Service requirements analysis
2. Service and technical design
2.1.1 High-level service architecture
2.1.1.1 Enabling service components
2.1.1.2 Enhancing service components
2.1.1.3 Integration and dependencies
2.1.2 Technical service architecture
The following general information acts as a starting point for the design and transition of a new (or changed) service.
|
Service name |
A short descriptive name for the service, comprehensible to a customer
|
|
General / initial service description |
A short (few lines) description of the service, that is orientated toward customers and users.
|
|
(Potential) service customers and users |
Brief outline of who are the customers and users of this service. |
1.2 Business case
The following business case has been developed to support informed decision-making with respect to the extension or change of the service portfolio from a strategic perspective:
|
Part 1: The customer perspective
|
|||||
|
Status quo / current situation (baseline) |
Describe the situation without the new or changed service, including potential pain points the service is intended to resolve or unexploited opportunities for the customer(s).
|
||||
|
Expected customer and user benefits / value proposition |
Describe how the new or changed service alleviates specific user pains and/or supports its intended customer(s) to exploit new opportunities. |
||||
|
Part 2: The service provider perspective
|
|||||
|
|
Best case
|
Average case |
Worst case |
||
|
Demand assessment
|
|
|
|
||
|
Assumptions and constraints
|
|
|
|
||
|
Expected organisational impact on the service provider |
|
|
|
||
|
Expected resource and/or financial impact |
Expenses
|
|
|
|
|
|
Revenue
|
|
|
|
||
|
Risks
|
|
|
|
||
1.3 Service requirements analysis
Following, the results of the service requirements analysis are summarized:
|
Category |
Requirements
|
Weight |
|
Functional and technical service requirements
|
|
|
|
Availability, continuity and performance-related service requirements
|
|
|
|
Security and data protection-related service requirements
|
|
|
|
Usability-related service requirements
|
|
|
|
Organisational service requirements
|
|
|
Based on the service specification, the service architecture provides an overview of the key (logical) service components and their dependencies to help better understand the structure and logical as well as technical setup of the service.
2.1.1 High-level service architecture
2.1.1.1 Enabling service components
Insert a list of enabling service components, including a short description of each component and the function(s) it enables. Enabling components are required to make the base service operate.
2.1.1.2 Enhancing service components
Insert a list of enhancing service components, including a short description of each component and the function(s) it enhances. Enhancing components add additional functionality to a service but are not required for base operation.
2.1.1.3 Integration and dependencies
Insert a description and/or visualisation (figure) of the dependencies between the identified service components.
2.1.2 Technical service architecture
Describe the technical service architecture, taking into consideration the following perspectives :
- Environmental architecture
- Network infrastructure
- Hardware
- Software / applications
- Information
The service acceptance criteria are based on the results from the requirements analysis and listed in the following table:
|
Category |
Acceptance criteria
|
Critical? |
|
Functional and technical acceptance criteria
|
|
|
|
Availability, continuity and performance-related acceptance criteria
|
|
|
|
Security and data protection-related acceptance criteria
|
|
|
|
Usability-related acceptance criteria
|
|
|
|
Organisational acceptance criteria
|
|
|
Critical acceptance criteria according to the above table are regarded as show-stoppers. That means that if any of the critical acceptance criteria is not achieved, the deployment of the service to the live environment will be delayed.
|
Number of unachieved critical acceptance criteria preventing deployment |
1 or more |
|
Number of unachieved non-critical acceptance criteria preventing deployment |
Insert number |
Following the service transition plan for the new or changed service:
|
Phase |
Activities and timing
|
Responsibilities (RACI) |
Links / references to other documents |
|
Specification, negotiation and agreement
|
|
|
|
|
Development and procurement
|
|
|
|
|
Testing
|
|
|
|
|
Operation with early life support
|
|
|
|
|
Regular operation
|
|
|
|