Published by SHIFT Media Inc

Online and in Print

www.shiftmediainc.com
Mail, Telephone and E-mail
SHIFT Media Incorporated
1521 Concord Pike
Suite 301
Wilmington, DE 19803
USA
Phone: +64 27 5772423
[email protected]

© SHIFT Media Incorporated, 2013

All rights reserved. No part of this book may be reproduced without the permission of the publisher
Applications for reproduction should be made in writing to [email protected]
Published by SHIFT Media Incorporated
The information contained in this publication is believed to be correct at the time of manufacture. Whilst care has been taken to ensure
that the information is accurate, the publisher can accept no responsibility for any errors or ommissions or for changes to the details
given.
ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.
COBIT® is a Registered Trade Mark of ISACA
Cover image © zuzazuz - Fotolia.com
First published 2013
ISBN
Contents
1. Preface v
1.1 Acknowledgements v
1.2 Audience v
2. Introduction vi
3. Perspectives–Frameworks & Requirements 1
3.1 Business Analysis: BABOK 1
3.2 IT Governance and audit: Cobit5 (Requirements Process Audit) 2
3.3 IT Service Management–ITIL (Service Design) 3
3.4 Software Engineering 3
3.5 Project Management 6
3.6 Enterprise Architecture 9
4. Requirements Register 12
5. Requirements for this book 14
5.1 Problem Statements 14
5.2 Requirements 15
5.3 Benefits 16
5.4 Final and Intermediate Outcomes 17
6. Requirements Management as a Process 18
6.1 Process Overview 18
6.2 Scalability 19
6.3 Sub-processes as perspectives 19
7. Integrated Requirements Process Flow 21
7.1 Top Level Process Diagram 21
7.2 Role: IRP Owner 23
7.3 Role: IRP Manager 24
7.4 Missing Role: Project Manager 25
7.5 Critical Success Factors (CSFs), Key Performance Indicators (KPIs and Metrics) 26
7.6 Responsible, Accountable, Consulted, Informed (RACI) – Top Level 27
7.7 Example of initial ‘raw’ requirement 28
7.8 IRP Sub-Process 1: Requirements Analysis 30
7.9 IRP Sub-Process 2: Requirements Elicitation 31
7.10 IRP Sub-Process 3: Requirements Organised 33
7.11 IRP Sub-Process 4: Strategy Approved – Service Chartered 35
7.12 IRP Sub-Process 5: Solution Designed 36
7.13 IRP Sub-Process 6: Service Transitioned 38
7.14 IRP Sub-Process 7: Service Sourced 40
7.15 IRP Sub-Process 8: Service Operated 41
7.16 IRP Sub-Process 9: Continual Service Improvement 42
7.17 IRP Sub-Process 10: Change Approval 43
8. Requirements Lifecycle 44
8.1 Need Identified 47
8.2 Service Strategy 47
8.3 Stakeholder Analysis 48
8.4 Elicitation 49
8.5 Logged: Requirement / Late Requirement 49
8.6 Categorised 50
8.7 Confirmed 51
8.8 Prioritised 51
8.9 Organised 51
8.10 Linked to Service Design Package (SDP) 52
8.11 Formal specification 53
 8.12 Model 53
8.13 Assumptions & Constraints 53
8.14 Verified 54
8.15 Not Appropriate 54
8.16 Validated 54
8.17 Chartered 55
8.18 Solution Design 56
8.19 Solution Approved 56
8.20 Service Transition 57
8.21 Service Operation 57
8.22 Continual Service Improvement (CSI) 58
8.23 Service Improved 58
8.24 On-going CSI Requirement 59
8.25 Requirement Delivered 59
9. Governance Structure 60
9.1 Process Diagram Overview 60
9.2 Control Section 62
9.3 Action Section 74
9.4 Enablers Section 87
9.5 Sources of Requirements (inputs to the process) 90
9.6 Enterprise Analysis, Strategy & Governance 90
9.7 Stakeholder Analysis 90
9.8 Communications Plan 91
9.9 Requirements Design & Engineering 91
9.10 Readiness Assessment 92
9.11 Solution Definition & Selection 92
9.12 Solution Evaluation Report 93
9.13 Solution Delivery Review 93
10. Tool Requirements 94
10.1 Communications Plan Workflow 94
10.2 Risk Register 94
10.3 Requirements Register and Repository 95
10.4 Service Portfolio 95
10.5 Service Design Package (SDP) 95
11. Bibliography 97
13. Appendix B – Links to COBIT5 102
13.1 Goals & Metrics 102
14. Appendix C–An Example of a Code of Ethics 105
16. Glossary 109
 1. Preface

1.1
Acknowledgements
T he author would like to acknowledge the help of the reviewers. Particularly Steve P. Blais who
kindly gave me his comments on the first draft, helping me to ensure that it made sense to
business analysts as well as to service management professionals. I acknowledge my huge debt to
Kirstie Magowan for her patient assistance with both the direction and structure of the book and its
editing. I am also grateful to Verity for her patience during the writing process.
Sincere thanks go to the reviewers of this publication who gave so freely of their time and expertise:
• Tom Van Wint - Sita Waste Services
• Francis Gils - Capgemini
• Bart Van Cauter - Banonzo
• Rose Dyson
• Paul Bodie
• Dinsha Palkhiwala
• Katherine O’Callaghan, PhD - KOZADAR Consulting
• Annamarie Boddy
• Roland Geilen - CATTS - IT
• Annemie Couke - Agfa ICS
• Dianne Green - IBM Australia
• Jaqi Haworth - HDAA
• Chris Jones

1.2
Audience
Senior managers, consultants, practitioners, academics, tool designers, Project Managers, Business
Analysts, Architects, Service Owners, Process Owners and vendors in both service management and
business analysis fields.
This book will be useful to anybody working in:
• Business Analysis
• Enterprise Architecture
• IT Governance and Audit
• IT Service Management
• Project Management
• Software Engineering
 2. Introduction

‘The top five causes of troubled projects were:

1. Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise
2. Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning
3. Schedules: Too tight, unrealistic, overly optimistic
4. Planning: Based on insufficient data, missing items, insufficient details, poor estimates
5. Risks: Unidentified or assumed, not managed.‘ 1.

T his book is intended for business analysts and service management professionals who seek to
provide good governance. It provides guidance on incorporating best practice advice for the
gathering and analysis of requirements, and the subsequent design and delivery of solutions, under one
Integrated Requirements Process (IRP) reducing cost and risk to the organisation, while improving
the delivery of business value according to good governance.
It advocates the use of a centralised, corporate-wide IRP register (IRPR) based on a repository of all
requirements, treated as corporate assets and part of the service knowledge management system
(SKMS) used by IT service management (ITSM).
If business analysis is to succeed, it is vital that, ultimately, every part of a service can be traced to a
business requirement, albeit that the route may be indirect, and that both process and service insight
are applied to business analysis to enable genuine alignment of applications to services and thus to
both service management and business processes. At present, few business analysts are aware of, or
work with, the IT service management processes.
Requirements, and the process of refining them to produce good solutions, have been considered
many times in the past. Practitioners of software engineering, project management, enterprise
architecture, business analysis, IT governance and audit and IT service management, amongst others,
have produced recommendations for the management of requirements from their perspectives.
This has led to a plethora of similar, but often conflicting, approaches to requirements, with no mutual
understanding or coordination of approach. It is important to remove confusion between the various
relevant guidelines, frameworks and standards.
Cobit5 (Control Objectives for Information and Related Technologies) is a framework of governance
and audit guidance produced by ISACA (Information Technology (IT) Management and IT
Governance) to assist auditors to ensure that organisations are achieving good IT governance. If the
suggestions made in this book are followed, along with the guidance in ITIL and the BABOK
(Business Analyst Body of Knowledge), an organisation ought to be confident in achieving a
successful audit of its requirements management and solutions development activities.
The BABOK is a book produced by the IIBA (International Institute of Business Analysis) to provide
guidance to business analysts on the gathering and analysis of requirements and the production of
solutions (mainly software solutions) to satisfy those requirements. The book is written as a series of
interlocking activities. Its emphasis on software means that it is weak in managing service, process
and non-software requirements and solutions, in particular, warranty (non-functional requirements)
needs that are essential to risk and cost reduction as well as value optimisation.
ITIL® 2011 is a collection of five core books, published by TSO (The Stationery Office), that
describes the management of services, with the copyright owned by The Cabinet Office in the UK and
much of the content provided by members of the itSMF®(IT Service Management Forum). The
lifecycle of a service, and the management of all parts of the service, are described from the
definition of the service strategy, to the service design and then onwards to the service transition into
the live environment described in service operation. The vital aspect of the quality management of
services across this lifecycle is described in the Continual Service Improvement (CSI) book, which
applies across the whole lifecycle, as well as to services, processes, tools and architectures. ITIL
does not provide advice on software development nor, in detail, on business analysis.
The three sets of guidance cited all aim to produce the same ultimate result – a well-governed
organisation that has service management as an asset and the strategic capability to achieve business
results to well-defined requirements in the form of services.
Though Cobit5 gives excellent advice on the top-level processes along with the metrics and KPI’s
that an auditor can apply to these processes, it does not give the detail of how to achieve these in
practice that is found in the ITIL books. The BABOK gives considerably more practical detail of all
the activities that a business analyst will perform. It does not show how these activities align to the
processes described by ITIL and Cobit5. It does not align to the provision of end-to-end services as
understood by ITIL.
This book is not an attempt to provide a unification of all the advice provided by these frameworks. It
is not even clear if such unification would be possible or necessary.
As the list of problems and benefits for the IRP (Chapter 5) will demonstrate, there is a need for a
unified view of the requirements and solutions production process that incorporates all of these
frameworks. The aim of this publication is to provide this unified view. The requirements process
can be integrated with any of the frameworks or standards mentioned.
The method used for this integration is to understand how requirements management works as an
overall process with solutions management. The excellent advice given in the various frameworks is
used to ensure that the requirements process is, as far as possible, complete.
Though the need to track and understand requirements has been around for a very long time, the
understanding of the importance of a centralised requirements register (or repository) linked to the
risk register of the organisation and integrated with the service portfolio (and, quite likely, in larger
organisations, with the overall business investment portfolio) is relatively new. So an example of a
template for a requirements register is provided that can be used as a starting point for developing
such a tool.
Some advances in social media, technology that post-date BABOK, and were emergent when ITIL
2011 was produced, are also considered – in particular, the use of hash tags to facilitate the
categorisation of requirements.
Governance, as a discipline, is the driver for all corporate action; therefore requirements must be
developed in line with governance. For this reason, the requirements process must be part of a
corporate service management discipline. In particular, it must be driven by the business and service
portfolios, under change management, in line with the IT strategy and it must be auditable, internally
and externally, through a Cobit5-based audit process.
1. Strategies for Project Recovery © 2011 Project M anagement Solutions, Inc.
 3. Perspectives–Frameworks &
Requirements

Figure 1 The Problem–integrating perspectives from different disciplines

3.1
Business Analysis: BABOK
‘The Standish CHAOS Report, which surveyed 9,236 IT projects, found that the top three causes of project failure were lack
of user input, incomplete requirements or changing requirements.’ THE STANDISH GROUP REPORT 1995 ‘The Standish
Group

T he need to understand and define requirements clearly has existed for a long time – major
engineering projects had to work with requirements to build bridges, ocean liners, aircraft and
other things long before software was invented.
Software development, too, has a long history, subsequent to that, where requirements have been
understood to be important to successful development, and this has led to the establishment of the role
of the business analyst. The BABOK model provides valuable insights into this role as defined by a
set of software, application-based activities.
The service management view of applications as part of a larger picture of services is
not part of the current perspective and the IRP does not attempt to replace it, but to
enhance the current view by showing how that service view can be incorporated,
along with the management and quality improvements from managing business
analysis, as a process.
This incorporates the activities from BABOK into the processes of ITIL and, by doing this, enables
the alignment of BABOK and ITIL to the Cobit5 audit and governance requirements found in the
section ‘Build, Acquire and Implement’ – in particular, the two processes BAI01 (manage
requirements definition) and BAI02 (manage solutions identification and build).
Overall, the aim of the IRP is to allow business analysts, service management professionals and IT
audit and governance professionals to work together to produce a high quality of business value,
using well-governed, effective and efficient processes and services to achieve this value.

3.2
IT Governance and audit: Cobit5
(Requirements Process Audit)
Cobit provides guidance for auditors to enable them to ensure that an IT organisation is being
governed and managed effectively. The latest version of Cobit, Cobit5, has been structured along the
lines of ITIL 2011 – Cobit5 includes more areas, such as development, than ITIL does; not everything
maps to ITIL.
Cobit5 recognises the importance of requirements and, indeed, recognises the importance of two
processes for managing requirements – though the specifics of implementing these as processes are
not within the scope of Cobit. The need to measure the compliance with requirements is also
specifically recognised.
The relevant advice is:
• Build, Acquire and Implement:
– BAI02 – Define Requirements
– BAI03 – Identify & Build Solutions
• Measurement (Monitor, Evaluate, Assess):
– MEA03 – Monitor and Assess Compliance with External Requirements
In terms of meeting Cobit5 governance, the proper design, implementation and execution of an IRP
goes towards meeting the goals of evaluate, direct and monitor: :
• EDMI01 – Set and Maintain the Governance Framework
 • EDMI02 – Ensure Value Optimisation
• EDMI03 – Ensure Risk Optimisation
• EDMI04 – Ensure Resource Optimisation
• EDMI05 – Ensure Stakeholder Optimisation
The detail of these processes, in particular the process goals and metrics, is found in the Cobit5
documentation, available from ISACA, free for members.
In Appendix A, the goals and metrics for BAI02 and BAI03 are related to the IRP.

3.3
IT Service Management–ITIL (Service
Design)
ITIL recognises the importance of requirements in defining service solutions – this is covered in the
core volume ‘Service Design’. This is described as requirements engineering and includes the main
activities involved in defining requirements. ITIL does not treat requirements engineering as a
process and does not go into the detail that the BABOK covers.
It is important to recognise requirements as artefacts with a life cycle, which are governed by a
process structure and this, currently, is not part of service design. For the purposes of the IRP, the
important sections mentioned in service design are included, but, in an ideal world, the process
description included here would be retrofitted to both the service management lifecycle (not just
service design) and BABOK.

3.4
Software Engineering
Software engineering has been considered as a discipline for several decades, and many different
approaches have been adopted to tackle the difficult matter of engineering something as apparently
intangible as software.
A few of the common approaches follow; what they have in common is that all recognise the
importance of understanding and managing requirements properly, but all take a different approach to
achieving this. All also look at requirements from the point of view of a particular project, rather than
corporate wide.
3.4.1
Requirements Engineering
Requirements engineering examines the first stage of a software development process and splits it
into a number of steps:
• Requirements inception
• Requirements identification
 • Requirements analysis and negotiation
• Requirements specification
• System modelling
• Requirements validation
• Requirements management
These steps are subsumed into the BABOK and Service Design. They are also all part of the IRP. The
difference is that the IRP considers these as being in need of coordination and management across the
enterprise, not simply in one project.
3.4.2
Software Engineering Body of Knowledge (SWEBOK)
This is produced by the IEEE Computer Society. In the SWEBOK, software requirements are seen as
the first stage, before software design.
The engineering methods covered in SWEBOK are all practically useful and well tried in practical
situations. They deal with software, primarily, rather than including the wider perspective of service
provision, which makes them secondary to service management or enterprise architecture. Treating
them separately from service management or enterprise architecture distances them and increases the
risk of poor communication through the proliferation of interfaces. The IRP unifies all these into one
process, reducing this risk.
3.4.3
Volere
This is one of many approaches designed to help nail down requirements for software engineering.
The Volere site (www.volere.co.uk) provides templates, processes, books, consulting and training in
the method.
It is a fair commercial success, with regular conferences around the world. As with other approaches,
it understands the importance of stakeholder analysis, the prioritisation of requirements and the need
for requirements to be clear and ‘atomic’.
Many software tools exist to provide templates and workflow based on these principles. Mostly, as
with the other approaches here, they do not include the service management perspective and do not
understand requirements as corporate assets or the need for them to be managed through a central
register in order to enable re-use.
3.4.4
Requirements Networking Group (RQNG)
Another group studying requirements – showing again, what a widely shared concern this is! The
RQNG has built communications links between business analysts and developers. Many publications,
including very useful and informative white papers, have been published under the umbrella of this
group.
The group has also produced a requirements management tool (www.pragnalysis.com) that includes
software, templates and advice in the matter of clarifying and documenting requirements.
Importantly the approach emphasises the importance of precision, brevity, quality, consistency and
flexibility in managing requirements – all of which are important.
The emphasis is on helping the business analysis part of the job, without integrating service
management or recognising that requirements are corporate assets that need to be managed and re-
used across the organisation, not simply from project to project.
3.4.5
Carnegie Mellon Maturity Model Integration (CMMI)
CMMI has been adopted as a process improvement approach in many organisations across the world.
It includes first-rate assessment tools to enable maturity levels to be measured and improvement
projects planned and executed.
Requirements management is one of the topics that is analysed as part of the CMMI approach.
The reason CMMI is mentioned in this section is that it also considers requirements management as
part of the development cycle. It does have linkage to service delivery, as well as project delivery, so
it is often used as an adjunct to service management.
It considers many of the questions that the IRP addresses and provides excellent advice on dealing
with them.
It does not advocate a requirements register and does not address the re-use of requirements or
recognise that requirements are not simply a development matter, but rather corporate assets that need
to be managed as such.
3.4.6
Waterfall Method
The waterfall method is an extremely well tried and tested way of managing software projects. It is
so called because the cascade of steps to be followed is reminiscent of a waterfall.
As well as being well known, the method has the advantage of being clear and emphasising the
importance of understanding the requirements well and understanding them early.
The method, in its raw form, does not include the re-use of requirements and does not manage late
requirements well. The method has its well-documented disadvantages as well. The emergence of
agile and lean approaches testifies to the need many people have felt to replace this method.
The waterfall method fails particularly from the point of view of the IRP, because this method sees
the process of development as a single execution of a set of stages, rather than a longer term, wider-
scope evolution of efficient and effective services.

3.5
Project Management
The discipline of project management has a long history – projects have been managed long before
the invention of the computer. The task of project management is to achieve the project goals through
leading the project, managing the resources (including people), and planning and organising the
project so that its goals can be achieved within time and budget.
This requires that the project is well-described and the goals are understood. Often this is not the
case. The goals are vague and the project is described ambiguously. This happens so often that
project managers are used to having to start a project by establishing what these are. Consequently,
much of project management involves requirement management, which means that it appears to
overlap with business analysis.
What the IRP enables project managers to do is to start, as they should, at the planning stage, having
been given a clear description of the project requirements at the design stage. If there are additional
requirements because of the nature of the project, these can be documented and addressed as part of
the IRP, rather than, as is often the case, there being separate lists of requirements kept by the business
analyst, the project manager, the development team and the technical team involved with the
deployment. This greatly increases the risk of error – which can be considerably reduced by having
one central requirements register for the organisation as described by the IRP.
3.5.1
PRINCE2
PRINCE2 is published by TSO and owned by the Cabinet Office in the UK (that also owns ITIL). It
describes all the stages of a project in considerable detail, along with templates that can be used to
document the project and it has a certification programme for practitioners.
A PRINCE2 project expects to get only a project brief and to build this into a proper business case.
Though requirements management is an important need, but it is not addressed in much detail in
PRINCE2.
The IRP can add considerable value to practitioners of PRINCE2 by managing the requirements and
building the business case before the real strengths of the framework come to bear at the project
planning, monitoring, control and analysis stages.
3.5.2
Project Management Body of Knowledge (PMBOK)
PMBOK is produced by the Project Management Institute (www.pmi.org). It is a widely respected
and used method of project management.
A project, as described by PMBOK, involves obtaining authorisation, establishing the scope, defining
the course of action and understanding the objectives and project specifications. The PMBOK
describes a requirements management plan for the project. Unlike the IRP, this management of
requirements lasts only the life of the project, with reuse of the work done unlikely.
As with PRINCE2, this work is required if the project specification is vague and the requirements
poorly understood but, using the IRP, the project can start more effectively at the planning stage.
3.5.3
Extreme Project Management
Extreme project management (XPM) is usually concerned with software projects. It emphasises
adaptability and short-term delivery. The extreme approach expects activities and requirements to be
chaotic. XPM expects it to be difficult to control the project and emphasises uncertainty and self-
management.
One great advantage of Extreme is that it allows for requirements to change and for late requirements
to be taken into account.
The IRP takes late arriving requirements as a necessary part of requirements management, just as
XPM does. However, IRP does enable requirements to be properly documented – quickly. XPM can
be used, at much lower risk, knowing that, even though requirements have been assembled during the
project, they have been documented and analysed for risk, so they are traceable and can be re-used
for other projects.
3.5.4
Agile/Lean Project Management
Lean thinking has been applied to many areas, and has been very successful. It is based on the
principle of delivering a project with more value and less waste.
Lean thinking has evolved from Agile thinking, with heavy influence from quality management circles,
in particular the use of quality management circles at Ford and Toyota greatly influenced the
acceptance of lean thinking. It emphasises continual improvement, measurement and quality
management.
Agile project management and software development are based on an iterative approach to evolving
solutions. The understanding of requirements, and the development of their solutions, emerges as part
of the collaboration between loosely defined cross-functional teams.
As with XPM, this collaborative and innovative culture can achieve great results. The idea of
evolutionary project management reflects the way that many things in the past have actually been
achieved and is something of a reaction to the micromanagement that typifies the more formal
waterfall-type methods.
The top-down management of traditional projects is part of the problem that is being reacted to. The
communication of requirements and possible solutions in an hierarchical organisation can be impeded
by management layers, and many bottlenecks to smooth communication can lead to the risk of non-
communication –information that has to travel between many communication layers is likely to be
misunderstood.
The IRP provides a central register of all requirements. As with social media networking, everybody
can contribute to the understanding, improvement and solution of requirements – as well as adding
new ones as and when these are required. So the documentation requirements of the more traditional
methods are met as well as the Lean/Agile quick collaborative and inventive communication.

3.6
Enterprise Architecture
Gartner defines enterprise architecture as
‘the process of translating business vision and strategy into effective enterprise change by creating, communicating and
improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution. The
scope of the EA includes the people, processes, information and technology of the enterprise, and their relationships to one
another and to the external environment. Enterprise architects compose holistic solutions that address the business
challenges of the enterprise and support the governance needed to implement them. Enterprise architects use the EA process
 to discover the target state that the organisation wishes to invest in and then helps the organisation understand its progress
toward the desired state’ © 2012 Gartner, Inc.
It is clear from the above that understanding requirements is essential to be able to define an effective
enterprise architecture.
3.6.1
Service Orientated Architecture (SOA)
As the name describes, SOA designs an architecture based on inter-operating services. An SOA
exercise goes through a number of stages to define standard, interoperable and composable services.
‘Composable’ refers to a principle of design that enables self-contained services to communicate
with each other in an atomic way – that is, each request is unaffected by other requests.
SOA is based on a long and successful principle of data-driven design. The IRP deals with
requirements in a similar way to SOA, which describes them as ‘requirement objects’. SOA relates
requirement objects to platform objects – a design unit object is produced as a result of transforming
a business requirement into a specific platform. The IRP does not concern itself only with coding
requirements for a software solution, so it tracks requirements more broadly but, once a requirement
is defined for a particular development activity, it is, essentially, identical in the IRP and SOA
definition.
An SOA expert might use business activity monitoring (BAM) to understand how the business
operates – thus gaining an insight into requirements. This is similar to the elicitation technique of
observation, used by business analysts.
The SOA manifesto adopted at the 2nd International SOA Symposium requires:
• Business value over technical strategy
• Evolutionary refinement over pursuit of initial perfection
• Flexibility over optimization
• Intrinsic interoperability over custom integration
• Shared services over specific-purpose implementations
• Strategic goals over project-specific benefits
Understanding Business Requirements, and their priorities, is essential to achieving effective service
architecture. This is not, though, the main focus of SOA; it has relied upon other parts of the
organisation, such as business analysts, or has re-invented requirements management from scratch.
Though SOA has been popular and successful, bringing some vital order to deployments, its
management of requirements is not among its strengths. Requirements are not managed in a consistent
and focused manner.
3.6.2
The Open Group Architecture Framework (Togaf)
Togaf is a widely used framework for understanding enterprise architecture. It has been developed as
a standard by The Open Group (opengroup.org) over several years, currently being at revision 9.1.
It follows a well-described, multi-part process that goes through a nine-step, or phase, life cycle in
order to build the architecture. The phases are:
 1. Preliminary – framework and principles
2. Architecture vision
3. Business architecture
4. Information system architecture
5. Technology architecture
6. Opportunities and solutions
7. Migration planning
8. Implementation governance
9. Architecture change management
Togaf understands how central requirement management is to achieving all this. So much so that the
top-level diagram shows requirements as the hub of the wheel that supports all the above phases.
Togaf is agnostic about how requirements should be managed, leaving this open to the implementer of
the enterprise architecture engagement. However it makes it clear that the proper management of
requirements is essential.
The IRP described in this book would provide exactly the requirements management framework that
Togaf stipulates.
 4. Requirements Register

T he integrated requirements process (IRP) has been designed to use a requirements register as the
central repository of all requirements, organisation-wide.
The main difference between a repository and a register is the level of workflow and organisational
authority. A repository is a database, structured document, or other storage area. A register, though it
will use a repository as the technical means of maintaining the information, is part of organisational
governance. Items in a register are governed by a corporate policy that establishes the status,
lifecycle, approval workflow and authority as a corporate document.
An individual project manager may, for example, establish a repository for his team, but he would not
be in a position to claim that this is an official organisational register.
Both the BABOK and ITIL speak of a requirements repository, which is aligned to a particular
project or, in the case of ITIL, a service. Both ITIL and the BABOK speak of the re-use of
requirements, which is important both to avoid losing important requirements and not to waste time
re-discovering known requirements. Both of these are necessary for cost-effective requirements
management.
The problem is that, although re-use is mentioned as a desideratum, there is no explicit activity or
process tasked to achieve this. We know from the RACI (responsible, accountable, consulted,
informed) matrix process, which tells us that only tasks that have an individual identified as
‘accountable’ are likely to be completed successfully, on time and to budget.
This is a reasonable place to be when there is no overarching corporate-wide process; unless a
project is part of a programme there is nobody responsible for its requirements re-use once the
project is complete – there is a general design requirement that, when a new project starts, the
business analyst checks to see if there are existing requirements that can be re-used. However there is
no metric on how successful this is, and the method of recording metrics does not lend itself to re-use.
For these reasons, what is required for the IRP to be a corporate process, is a requirements register.
That is a centralised, authoritative, repository for all requirements of all programmes, projects,
processes and services, enabling proper management of the full requirements lifecycle.
Requirements need to be linked in a number of ways – something that can lead to complex data
structures that are difficult to manage and are error prone. The use of tags to categorise requirements
enables them to be easily linked. These tags link to other services, corporate initiatives, specific risks
and other relevant matters. The links are intuitive, straightforward and flexible.
People and organisations need to look at requirements from different perspectives. Tags can help in
providing this different perspective.
Some discipline is required from users to ensure that tags are used effectively. If the tags are tracked
and managed properly, the risk of confusion can be minimised. At a minimum, all tags should contain
their originator and the time they were created, to help clarify obscure tags. A list of existing, relevant
tags is maintained to allow easy re-use of important tags.
 5. Requirements for this book

T his book is a book about requirements, so it is reasonable to ask what the requirements for the
book itself are. The problem statements and requirements are, briefly:

5.1
Problem Statements
‘Studies carried out into IT project failures tell a common story. Many of the projects and unsatisfactory IT services suggest
the following conclusions:
A large proportion of errors (over 80%) are introduced at the requirements phase.
Very few faults (fewer than 10%) are introduced at design and development – developers are developing things right, but
frequently not developing the right things.
Most of the project time is allocated to the development and testing phases of the project.
Less than 12% of the project time is allocated to requirements.’ 1
The current situation for business analysis and service management is that they operate in different
silos, with the best practice framework advice being good, in both cases, but suffering from a lack of
integration. The detailed aspects of the problem are:
• Existing frameworks do not treat requirements management as a process
• Requirements management is not integrated into the service management lifecycle as described
in ITIL
• The requirements catalogue, as described to date, is limited in scope
• The re-use of requirements is not easy
• The tracking of requirements across the organisation is not easy
• There is no clear method for dealing with late requirements
• Critical success factors (CSFs), key performance indicators (KPIs) and metrics are not well
defined for the requirements process
• Solution specifics are considered too early, before requirements are properly understood,
impeding the development of radical solutions
• Requirements are re-discovered on a per project basis, rather than understood across the
service portfolio
• Solutions follow previous practice, rather than adapting to business need
• Solutions follow previous practice, rather than adapting to technological opportunity
• Solutions consider the product (the application and its development) at the cost of considering
the service holistically
• Solutions are not well adapted to operational and transitional requirements, because these are
considered too late and re-invented too often
• Requirement analysis, solution development and service design tend to be treated as separate
 activities, leading to duplication of effort, poor reuse, communication failure and thus poor
results and low customer satisfaction
• Development effort can be aligned to apparent demand from particular stakeholders rather
than to actual business requirements, resulting in skewed priorities in the deployment of
capabilities and resources to development.

5.2
Requirements
To address the above problems, it is useful to consider them as requirements for a new framework.
This book addresses this gap, based on these requirements. In future, these could be integrated into
either the BABOK guidance, or the ITIL service management guidance, or both.
The requirements for this book are as follows:
• Define the process(es) of requirements management
• Define the integration into the service management lifecycle
• Define requirements categories and statuses to enable:
– Reuse
– Tracking requirements
– Late requirements
– Splitting requirements
– Merging requirements
– Evaluating and validating requirements
– Driving solution design & selection
– Driving service design, transition, operation and improvement
• Define a template for requirements
• Define the requirements catalogue and related workflow
• Integrate requirements management, solution development and service design into one process
• Identify supporting tool requirements to enable the process
• Define measures – CSFs, KPIs and metrics for the IRP (IRP)
• Develop a RACI matrix prototype for the process
• Manage the demand for requirements to be met, according to actual business need.

5.3
Benefits
It is always wise to check that the requirements you are working to actually deliver tangible benefits.
In the case of a framework such as this, these benefits will only accrue when the advice is actually
followed. For the moment though, this book aims to produce the following benefits for those who
follow the advice contained in it:
• Process ownership defined, ensuring accountability
• Corporate requirements register established, ensuring:
– Governance through structured inclusion of policy requirements
– Cost-effectiveness through accountable re-use of requirements
– Ability to measure requirements lifecycle metrics
– Identification of process and organisational issues
– Auditable requirements management process
• Clear visibility of investment, progress and value delivery
• Link to continual service improvement (CSI), allowing service management capabilities to be
used to improve the requirements process, enabling better alignment to corporate vision,
strategy and direction as well as improving the delivery of corporate value
The effort and cost applied to satisfying requirements will be matched to actual business need, rather
than to apparent need, based on stakeholder ability to make their message heard by development.

5.4
Final and Intermediate Outcomes
• All requirements are checked during the validation phase, to ensure that they do not conflict
with corporate policy and strategy, ensuring good governance at an individual requirement
level
• Full incorporation of requirements management in the service design, as well as the
development phase
• Compliance with Cobit5 requirements BAI2, BAI3 and MEA3
• Consistent process across programmes, services and projects
• Integration of business analysis, service management, development and business
• Transparent management of conflicting, duplicate and late requirements
• Greater visibility of requirements and their value at a corporate level, enabling more effective
investment decisions and reducing the corporate pain felt by poor requirements management.
1 . ITIL V3 2011 ’Service Design’ Page 334 Section 5.1.4
 6. Requirements Management as a Process

6.1
Process Overview
‘The most important correlations for project success are to get good requirements and to manage those requirements
effectively.1’
There are many components to a process. The process view enables the identification of all these components, this enables the
establishment of a process that can be controlled and managed effectively, even when it crosses organisational boundaries –
though special care has to be taken to define such interfaces accurately and unambiguously.
As has been noted, Cobit5 recognises two distinct processes that need to be in place, BAI2 (define
requirements) and BAI3 (identify and build solutions); these are also covered as different activities in
the BABOK and dealt with separately in the ITIL book ‘Service Design’.
Treating something as a process adds value in a number of ways. It is possible and desirable to see
processes from different perspectives. Advice should be tailored to local requirements.
Requirements and solutions are different sides of the same coin. The requirements shall be echoed, or
mirrored, in the solution. Treating them in practice, as Cobit5 does, from an audit perspective, is not
ideal. For an auditor, there is value in understanding whether it is the management of requirements or
the production of solutions that are contributing to good governance.
To a practitioner, whether a business analyst, developer, service manager or business manager, the
important value is that the overall process (the IRP) delivers solutions that are well engineered
according to the requirements.
More importantly, the unifying thread through the process is the requirement itself. The requirement
may apply across the organisation to many different applications and services. There is a hierarchy of
requirements, with corporate-wide policy requirements translating, eventually, into very specific
requirements for a particular module or interface.
For example:
Governance -> Policy -> Warranty
A warranty requirement that ensures that working in parallel on redundant servers can work for all
applications, because they are designed to work on multiple servers.
If based on a policy requirement that any service could, if required, be made more resilient with
minimal cost.
This, in turn, would be based on the governance requirement that the organisation has a cost-effective
way of managing the risk of under capacity causing poor availability.

6.2
Scalability
Some requirements apply only to a module that forms part of a larger application. Such a technical
requirement should still be visible so that re-use in another project, application or service is
possible, and also to ensure that there is a centrally available audit trail.
Requirements are entities and, as such, move across organisational boundaries and form part of a
solution.
A requirement exists from when it is first considered as a possible solution to a business problem,
through its life, delivered as an active service, through to retirement and replacement.
This makes the proper tracking and understanding of the lifecycle of a requirement imperative, which
is the ultimate justification for treating it as one process.

6.3
Sub-processes as perspectives
When working on continual improvement, for example, it is desirable to understand exactly what part
of the overall process needs improvement. From that perspective, seeing the gathering of business
rules as a distinct activity is important.
At the other end of the process, the sub-process of selecting the solution architecture that best fits all
the organisation’s requirements is an equally important perspective.
Despite the value of these perspectives, if the IRP is not treated as one process, with one set of
objectives, there is a danger that:
• Requirements will be lost
• Solution focus will be different from requirements focus
• Solutions thinking will impede proper requirements gathering and analysis
• Different stakeholders will be considered by the different processes
• Business decisions will be made on limited knowledge because the full picture of all
organisational requirements is hidden – this is a serious business risk
The above disjunctions will produce less than optimal results.
Often the first thing that interests somebody looking at a process is its flow – the workflow. For this
reason, before going into the detail of the various parts of the process, the workflow, in terms of the
lifecycle of a requirement is covered.
1 1. June Verner, Karl Cox, Steven J. Bleistein, and N. Cerpa, ‘Requirements Engineering and Software Project Success: An Industrial Survey in Australia and the US’, Proceedings of the 9th Australian Workshop on Requirements
Engineering, December 2004, Adelaide, Australia, Winner of the Best Paper Award.
 7. Integrated Requirements Process Flow

T his chapter reviews the detail of the IRP process flow. First, the top-level view, and then each of
the ten sub-processes are considered. The relevant critical success factors (CSFs), the related
key performance indicators (KPIs) and, where relevant, possible metrics are described. There is also
a RACI matrix for the process level.
In the top-level view, the two new roles, specific to the IRP, are explained.

7.1
Top Level Process Diagram

Figure 2 Top Level Process Diagram

Every process has a trigger. In the case of the IRP, the trigger is the identification of a business need.
Any stakeholder, from a member of the board of directors, to an end user, customer or a supplier
external to the organisation may uncover an issue or make a suggestion that reveals itself as a
requirement.
The first presentation of a requirement may be rough or ‘raw’, in the sense that it might be vague,
ambiguous, couched in terms that only consider the current situation, rather than allowing for the
possibility of a completely new approach being taken. It is important that this first description is
logged so that it can be analysed properly and, if of value to the business, eventually, addressed by
becoming part of a new solution, whether as a change to a business process or as a service to the
business or by some other means.
All requirements are logged in the requirements register. This enables them to be tracked and, where
possible, re-used in multiple projects, programmes, services or other solutions. Some may become
corporate policy. Requirements are linked to the solutions that satisfy them, allowing all processes
and services to be understood in terms of the business benefit that they exist to provide.
Once logged, the requirement is analysed, along with any similar requirements. This analysis includes
a refinement of the wording to make sure that it states precisely what is needed in terms that can be
understood by both the business and the technical staff who will be involved in providing a solution.
When a significant requirement, or set of requirements, is identified, the business analyst may elicit
requirements from stakeholders. This sub-process fleshes out the original idea with considered input
from customers, users and other stakeholders using a number of techniques, for example, elicitation
workshops, surveys, interviews, or questionnaires.
The requirements are logged, analysed and gathered together to form a problem statement that is then
organised with other requirements, such as company policy, legal obligations and so forth, and
prepared as a business case. The business case is the tool used to explain the proposal and provide
evidence for and against the proposal, such as benefits, risks, and opportunities, along with the costs
involved. The business case, if approved, is planned, along with other strategic initiatives, and added
to the Service Portfolio.
When the business decides to implement the proposal as a service, it approves the budget and
allocates resources to it, moving the service to the status of ‘chartered’. Once chartered, the proposal
will be adopted within a defined time frame and cost. This creates a change proposal that is used to
design the solution.
The design of the solution is captured in the service design package (SDP) that describes all aspects
of the service along with the requirements that it will satisfy. At this stage, the acceptance criteria are
defined, in collaboration with all parties, including the business, transition and operation.
The SDP is passed to service transition that produces the plans to develop all aspects of the service.
If these plans include software development or acquisition, this activity is completed. Once all the
developmental activities are complete and the solution has been tested thoroughly and verified against
the requirements to ensure that it satisfies them, it is released and deployed as a service. The service
starts its live operation phase, often as a pilot, as part of the transition, known as early life support.
When the users, customers and operations have signed off all the acceptance criteria, the service
becomes fully live, under the control of operations.
During operations, deficiencies are uncovered or new opportunities for improvement are identified.
These are logged in the CSI register. Periodically, the CSI seven-step process analyses the register to
categorise and prioritise the improvements to be made. These are described in a request for change
(RFC) and there may be new requirements (restarting the IRP process), particularly if they are major
changes. Large changes will be planned and implemented by the transition phase and small changes
will be implemented directly by operations.

7.2
Role: IRP Owner
7.2.1
Responsibilities
The IRP owner is accountable for the process meeting its objectives in the organisation. This
involves defining, designing, communicating, implementing and then managing these process
components:
• Policy and strategy (based on corporate policy for good governance)
• Ensuring that the IRP delivers the needs of the business
• Documentation of goals, objectives, activities, procedures and work instructions
• Requirements for the process itself
• CSFs, KPIs and their norms, and metrics for the IRP
• The IRP register (IRPR)
• The IRP pilot
• Knowledge management requirements
• The capabilities required in the organisation
• Analysing relevant risk and logging risks in the corporate risk register
• Analysing value delivery
• Working to help the IRP manager achieve operational excellence
• Monitoring the process and acting on deviations from the norm
• Logging appropriate improvements in the CSI register
• Working with the IRP manager, the CSI manager to review, prioritise and then implement
improvements
• Reporting to stakeholders, including IT and business governance, business and IT management
and audit
7.2.2
Activities
Activities largely flow from the responsibilities listed above. The role activities are defining,
implementing, communicating, sponsoring, monitoring, correcting and improving the process.
7.2.3
Authorities
The IRP process owner must have sufficient seniority to be effective in sponsoring and
communicating the process throughout the organisation. The IRP process owner must also have
control of the IRP register and the service knowledge management system (SKMS) components
relevant to requirements. The IRP process owner must have the authority to manage requirements as
corporate assets.

7.3
Role: IRP Manager
7.3.1
Responsibilities
The IRP manager is accountable for the operational management of the IRP. The IRP manager works
closely with the IRP owner to ensure the smooth running of the process.
This involves:
• Ensuring that all requirements are actively managed appropriately
• Ensuring that activities within the IRP are carried out effectively and efficiently, including the
identification of needs, the elicitation, and analysis of requirements to produce problem
statements
• Managing the organisation, communication and coordination of these problem statements, and
their component requirements to produce business cases
• Sponsoring of business cases to senior management and the board to ensure that they are
responsibly rejected or adopted as chartered services
• Coordination of the design, transition, sourcing operation and improvement of services and the
requirements they solve.
• Activities
Activities carried out by the IRP manager include:
• Managing the monitoring and reporting required
• Managing resources allocated to the process
• Managing all activities within the process
• Collaborating with other process owners
• Collaborating with service owners
• Communicating with stakeholders, practitioners, and management
• Managing the requirements work of business analysts, service managers, development
managers, operational managers.
• Working closely with the change manager to ensure smooth interfaces between changes and
requirements
7.3.2
Authorities
The IRP manager must have sufficient seniority to be effective in the above activities. The IRP
manager must also have approval authority (albeit not sole approver) within the IRP for requirements,
problem statements, business cases, change proposals, SDP status changes, solution requests, end of
early life support sign-off, improvement proposals and relevant RFC’s.

7.4
Missing Role: Project Manager
The role that may be seen as missing from this discussion is that of project manager. This is not an
accident. It is quite possible that a project manager will be appointed to help with the planning stages
of the various projects that comprise the overall requirements life cycle. However, the role of the
project manager is to execute the projects that are justified, designed and planned elsewhere.
PRINCE2, for example, includes a number of project specification stages where a project manager
will elicit and refine requirements – this is not necessary at the project level because it will already
have been done by the business analyst. Similarly, the business case for any project will be
developed, presented and approved by the appropriately responsible or accountable person before
the project is funded and started.
This is not to devalue project management – an extremely important discipline. Historically,
organisations have not managed requirements well, nor have they produced adequate business cases,
particularly in IT, so project management, in order to reduce risk and improve the chance of a project
succeeding, has taken it upon itself to assume these responsibilities when it ought not to be part of the
project delivery phase.

7.5
Critical Success Factors (CSFs), Key
Performance Indicators (KPIs and Metrics)
These are essential to the process, but are considered later in this book in the controls section of the
IRP governance chapter.

7.6
Responsible, Accountable, Consulted,
Informed (RACI) – Top Level
Figure 3 RACI Matrices for IRP–Top Level

7.7
Example of initial ‘raw’ requirement
This example will be used as a practical guide, following the process to show how a requirement
changes at each stage. The form itself is a mock-up, or wire-frame, of how an application might be
designed to provide company-wide access to the requirements register. The form is fully described in
Appendix A.
This requirement will be followed through the steps of the IRP.
Figure 4 Example of initial requirement in mock-up

At this stage, an important requirement from the finance department has been captured. This is from
the financial director (FD), so, in terms of the IRP, this is a newly identified need. The first stage is to
start the requirements analysis. We can see already that this is a high value, high risk and high urgency
need, with corporate impact. The FD has already allocated funds for the investigation phase so
resources can be allocated.
It is likely that this requirement has actually come from the IRP itself. The FD might have logged this
in the CSI Register and the IRP manager, working with the CSI manager and the change manager have
decided that making this a ‘newly identified need’ is the best way to handle it.
Provisionally, John Smith has been made responsible for getting this requirement to the next stage.
The first step is to see if any re-use is possible. The existing requirements for the current financial
system can be obtained from the requirements register, collated and checked with the customer to see
which are still current, and which need modification or replacement. This will help start the
discussion and enable IT to understand the change in enterprise requirements.
The next step will be to have an informal chat with finance to get an understanding of its major
concerns and a clearer idea of the business drivers. This, in turn, will be used to plan the
requirements elicitation phase.
As a requirement, this is clearly raw. It is not a single, atomic, requirement. It mentions a number of
different areas. It is also ambiguous as it is not clear what, exactly, is meant by ‘errors’ or what ‘more
modern’ means. However it does have the virtue of being exactly what the customer thinks at this
stage. It will be clarified with the customer, probably split into multiple sub-requirements and
connected to existing requirements and those that come from the first elicitation activities. Keeping all
this in the register gives a clear picture of where the activity started and an audit trail.
The requirement is visible to the rest of finance and its stakeholders. At the moment it does not have
links to the risk register, the SDP, the CSI register and we have not defined the stakeholders and
authorisers. These will all be tasks for the requirements analysis phase.

7.8
IRP Sub-Process 1: Requirements Analysis

Figure 5 IRP Sub-Process 1: Requirements Analysis

New requirements are logged in the IRP register, as is the problem statement. Existing requirements
can be re-used, either as is, or as modified during the requirements elicitation process.
7.8.1
Worked Example stage 1
The initial requirement reads:
‘The accounting system must be fixed in line with new approvals policy and to reduce errors and to be more modern’ (ID: SM-
ES1211-0672-2011)
As has been observed, this is not clear; it is ambiguous and it is stating a number of requirements in
one. The first stage of analysis is to try to make it clearer.
Firstly by splitting it into three statements:
‘The accounting system must be brought into line with the new approvals policy’ (ID: SM-ES1211-0672-2011-A)
This requires an analysis of the current policy, the new policy and the current requirements (in the IRP
register) to see what requirements need to be changed and which new requirements need to be added.
When this work is complete, the adjusted requirements can be discussed with the finance department
to make sure that the requirements are correct. This is now ready to be assigned as a task. When the
task is complete, the requirements will be approved by the FD and by the IRP manager for inclusion
with the other requirements at the ‘IRP Sub-Process 3: Requirements Organised’ stage.
Task Assigned: Joe Black (finance business analyst)
‘The errors (incidents and problems) in the accounting system must be reduced’ (ID: SM-ES1211-
0672-2011-B)
The service owner must be consulted to establish exactly what incidents and problems exist, the
status of those incidents and problems relative to resolution and the actual perception of the users and
the customer. Once these are understood, the need for upgrading the service can be understood, as
well as the amount of work required. This option, of repairing the current system, then, with the
agreement of the service owner and FD, can be entered as a new requirement and be part of the next
stage of analysis. It will be considered with the other requirements in the drawing up of the problem
statement.
Task Assigned: Fred Jones (accounts service owner)
‘The accounting system must be modernised’ (ID: SM-ES1211-0672-2011-C)
It is not clear exactly what this means or why it is a business need. It is necessary to clarify this and
re-write it as an unambiguous, atomic requirement of the exact need. The service owner can set up a
requirements elicitation interview with the FD, including the IRP process manager.
Task Assigned: Fred Jones (accounts service owner)

7.9
IRP Sub-Process 2: Requirements Elicitation
Figure 6 IRP Sub-Process 2: Requirements Elicitation

The type of requirement and the type of organisation will determine the technique that works best to
elicit requirements. Once the requirements have been gathered, they are properly specified, as
unambiguous, clear, atomic requirements.
Experienced business analysts may notice that the brainstorming method is not included; this is
because recent psychological research has found this not to be an effective method of getting
information from teams. Instead the Delphi technique, which involves the gathering of requirements
from individuals first, and then prioritising and weighting them as a group exercise are suggested.
Part of this process is to ensure that all assumptions and constraints are understood and logged. The
requirements are then verified to ensure that they are effective. They are then used to produce a
wireframe, prototype, user story or other method to communicate the requirements back to the
stakeholders.
The verification step involves presenting the model to stakeholders and getting corrections,
improvement requests, more requirements that come to mind when the model is seen and ensuring,
possibly through repeating the cycle multiple times, that the requirements are clearly understood and
agreed. This may not be a matter of complete consensus and any conflict between stakeholders is
escalated to the IRP manager for resolution.
7.9.1
Worked Example Stage 2
The requirement ‘The accounting system must be modernised’ (ID: SM-ES1211-0672-2011-C) is now
discussed with the FD to discover exactly what he had in mind for this requirement. A set of
interview questions has been designed in advance to be sure to cover the requisite ground. The
interview is documented afterwards. The requirements are put through another stage of requirements
analysis to be sure that that they are clear, coherent and express what is needed without making
assumptions about a particular solution. These are then returned to the FD and IRP owner for
approval. Once the new requirements have been approved, they are developed into a problem
statement for the next stage.
The requirements now are:
• ‘The accounting service shall comply with IFRS’ (ID: FD-ES1211-0001-2008-01).
• ‘The accounting service shall comply with EPEAT green purchasing’ (ID: SM-ES1211-062-
2011-C1).
• ‘The accounting service shall comply with corporate the BYOD policy’ (ID: BY-PO3341-
000-2011-F4).
• ‘The accounting service shall provide customer demand statistics’ (ID: CM-DM2200-2009-
A5).
As can be seen, three of these requirements are in fact, existing requirements that have already been
met for other services. The EPEAT green purchasing, BYOD policy and the capacity management
demand statistics requirements are already part of existing solutions and that knowledge will be used
to ensure that the new financial service achieves these requirements. Considerable time, effort and
cost will be saved by re-use of this work and the risk will be lower because of lessons learned from
the existing deployment.
The one new requirement, which is specifically for finance, ID: FD-ES1211-0001-2008-01, has
already been used to produce the current solution – it only needs to be revised in light of the new
version of the IFRS. The FD has added a note that the existing solution does not deal adequately with
IFRS 2012 and has given IT an annotated copy of the guide that will be included as detailed sub-
requirements.
These four requirements are now grouped into the problem statement that will be used, with the other
problem statements, to build the business case:
‘The accounting service does not comply with IFRS 2012, EPEAT, or BYOD and needs to provide
customer demand statistics.’ (PS-ES1211-0672-2011-00)

7.10
IRP Sub-Process 3: Requirements Organised
Figure 7 IRP Sub-Process 3: Requirements Organised

This crucial sub-process takes some license with the BPMN in the interests of clarity. The business
case is an important part of business decision making and must be right. Though there will be other
technical contributions, and contributions from the stakeholders, it is essential that the service owner,
the business analyst, the IRP manager, the IT strategy process (finance, in particular) and the change
manager are involved in the production and approval process.
It is the IRP manager who is accountable for the delivery of the business case; hence, the IRP manager
is the crucial approval.
7.10.1
Worked Example Stage 3
This stage takes the relevant problem statements and their requirements and uses these to produce a
business case for the finance service. This business case has to establish the need, the benefits, the
cost, the risk and the possible solutions; a recommendation will be based on these.
The business case is based on the following problem statements, taken from the previous tasks (each
of these now has a set of agreed, more detailed and specific requirements):
‘The accounting system does not supply workflow consistent with BYOD’ (ID: PS-ES1211-0672-
2011-02)
‘The accounting system has an unacceptable impact on the productivity of the finance department’ (ID:
PS-ES1211-0672-2011-03)
‘The accounting service does not comply with IFRS 2012, EPEAT, or BYOD and needs to provide
customer demand statistics’ (PS-ES1211-0672-2011-00)

7.11
IRP Sub-Process 4: Strategy Approved –
Service Chartered

Figure 8 IRP Sub-Process 4: Strategy Approved–Service Chartered

The IRP manager is accountable for getting the business case approved. Service strategy is involved
in completing the business case, particularly the financials. Service strategy will also make sure that
the business case is within existing policy and delivers business value.
The business relationship manager (BRM) makes the presentation to the board and, if the business
case is rejected as incomplete, helps ensure that it is prepared properly for resubmission. New
requirements may arise at this stage and they are dealt with by the late requirement sub-process.
If the business case is rejected, all originators of requirements will have to be informed. Some
requirements may be satisfied by other means, some may have to be rejected altogether. This
communication process is handled by the IRP manager to make sure that a satisfactory plan is agreed
for all the requirements that made up the business case.
Change management agrees the change proposal, making sure that it is funded properly, the risks have
been assessed and resources and capabilities are adequate. This also makes sure that the milestones
will be in the change schedule.
7.11.1
Worked Example Stage 4
The IRP manager, or the service owner (if there is one – there will not be one for a completely new
service at this stage), presents the business case to the board.
There are three options the board can take:
 1. Reject or defer the proposal (service rejected or service definition rejected)
2. Accept the proposal as a good idea, and authorise investigation to establish the cost, risk,
value and solution options more clearly (service approved)
3. Authorise the proposal and approve a budget and start date for the project to build the solution
(service chartered).
In option 1, the originators of the requirements will be informed of the decision not to proceed. In
option 2, the IRP manager will arrange for the investigation and improvement of the business case to
proceed. In option 3, the IRP manager, with the approval of the change manager, will authorise the
move of the proposal to the service design phase of the ITSM lifecycle. The final action from this
sub-process will be the production of a change proposal for the solution design, linking the final
business case, the problem statements and the requirements.

7.12
IRP Sub-Process 5: Solution Designed

Figure 9 IRP Sub-Process 5: Solution Designed

Many other actors are involved in the design. Service design involves technical staff, users,
customers, developers, transition staff, operational staff, as well as service strategy and service
improvement in the design process. This is well covered in the ITIL book Service Design so only the
top-level design components are shown. It is worth noting, however, that the ‘utility designed’ task
incorporates service level management to set service level requirements for the solution.
The SDP is now officially part of the service portfolio and is linked to all its component requirements
in the IRP Register.
7.12.1
Worked Example Stage 5
On receipt of the approved change proposal the service (now in status: design) will be designed, with
support and coordination from the IRP manager. The IRP manager will use the design coordination
process to ensure that proper project planning is undertaken for the design to be produced in the
appropriate time. In terms of business analysis, the solution, or possible solutions, to the requirements
of the business case will be designed. This is usually, but not always, in the form of a service.
If the solution is not a service, or is a change to a service, then it will be handed to service transition
as a change request rather than a service with an SDP. A solution may be many things including a
change to a business process or even a corporate policy change.
During the design phase it is likely that new requirements will emerge or clarification will be sought
for existing requirements. Warranty requirements will be established and agreed with customers, in
the form of Service Level Requirements (SLRs) and the various requirements for successful service
transition, service operation and service improvement will be defined – including checklists for the
various sets of acceptance criteria. Where possible, previous work will be accessed in the SKMS or
IRPR and re-used.
The IRP manager will ensure that all requirements are captured and that they are properly analysed,
organised, communicated to the stakeholders. Where appropriate, purely technical requirements may
not need to be reviewed with all stakeholders. The IRP manager will then authorise them to be added
to the project. If these new requirements have significant implications for the cost, delivery time or
actual delivery of the service, this will be communicated with stakeholders and logged in the risk
register.
When design is complete, the service design process and the IRP manager will authorise the release
of the SDP to service transition.

7.13
IRP Sub-Process 6: Service Transitioned
Figure 10 IRP Sub-Process 6: Service Transitioned

The IRP Manager coordinates the movement of the service throughout its transition. Late requirements
can occur at many stages of the service lifecycle; however, it is in service transition that they are most
likely to do so. The IRP sub-process to deal with late requirements is included at this stage. A number
of the places where late requirements are likely to arise are included.
Service transition coordinates all this work under change control. The service acceptance criteria
(SAC) were designed at the service design stage and are now approved by operations as a sign that
the early life support process has ended satisfactorily.
7.13.1
Late Requirements sub-process
The IRP process owner will be responsible for designing this sub-process so that it works for a
particular organisation. The important characteristics of this process include:
1. All late requirements are logged
2. Where necessary, they are logged in the risk register
3. The scope, impact, benefits and value to the business are understood.
The decision on whether to approve the requirement for inclusion in the current phase or postpone it
to a later phase is taken with the informed involvement of service transition – in particular, change
control – to minimise impact on the business.
 7.13.2
Worked Example Stage 6
The transition planning and support process coordinates the building of a project plan, and the
production of a solution request to produce the solution as designed. When the final version is ready,
this process controls the test and verification of the service and its transition to a pilot service, into
early life support and, when approved by service operations, to an operational ‘live’ service.
During this phase, the IRP manager is kept informed of progress and monitors the transition against
the agreed timeline. The IRP manager will make sure that any new risks, deviations from the plan, or
requirements that emerge at this stage, are understood, logged and handled appropriately. The IRP
manager will communicate with stakeholders, or escalate matters to the risk register, if any significant
delays, cost over-runs, or deviations from the planned delivery are likely.
Once the pilot service is approved (by the change manager, the IRP manager, and the service owner)
the service starts moving towards live operation. These three roles ensure, through approvals, that
any risks are identified and resolved before they impact live operations.
This phase ends with the sign-off, by operations, of early life support.

7.14
IRP Sub-Process 7: Service Sourced

Figure 11 IRP Sub-Process 7: Service Sourced

The IRP manager, working with the service transition team, particularly change management, keeps a
tight control of the planning, development and delivery of the solution. It is quite likely that this will
not simply be a matter of internal development or external supply; there may be components of both
required to deliver a single solution.
From this perspective, the supply of a solution as licensed software, internally developed software,
open source software or out-sourced cloud-based delivery is the same, in terms of approvals. The
sourcing decision will be made based on corporate policy, supplier policy, the technical strength of
the options available, the cost and benefit of the various routes, among other criteria. These decisions
will be made with assistance from strategy, design, transition, operations, development and
management. It is possible that a final decision will only be reached after a proof of concept or pilot
deployment.
7.14.1
Worked Example Stage 7
Usually this sub-process selects an appropriate way of sourcing a service. If the solution is not a
service this process will, with the help of the IRP manager, establish how to implement the solution –
perhaps by escalating the request for a policy change to the board, or recommending a change to a
business process to the relevant business unit manager.
Services may be sourced from internal development, or they may be outsourced; for example, as
cloud services, they may be bought as complete solutions or open-source solutions might be
deployed. Often there is a mix of these options involved in sourcing a solution.
Depending on the mix, the development and delivery of the product part of the solution will be
overseen by service transition or by the IRP manager. Both will require a clear project plan for
appropriate delivery. This plan may be passed, with the SDP, directly to the development team, or
might form part of an invitation to tender (ITT), request for proposal (RFP) or similar contractual
document for an external supply of services.

7.15
IRP Sub-Process 8: Service Operated
Figure 12 IRP Sub-Process 8: Service Operated

Most communications from operations will come from operational support and will be handled by
service transition – change management in particular. The IRP manager needs to ensure that any new,
or altered, requirements are captured and handled appropriately.
Some requirements will be logged as change requests – often from problem management. Some will
be identified as CSI improvements, often from incident management, users, customers, service level
management or business relationship management.
7.15.1
Worked Example Stage 8
During live operation, the service owner is accountable for the delivery of the service and service
level management (SLM) for the levels of service delivered. The business relationship manager
(BRM) maintains the relationship between IT and the business, ensuring that concerns of both sides
are understood and resolved. The BRM works with the business to understand possible future needs
and communicates these back to IT – the IRP manager works closely with the BRM to make sure that
these new services are captured as new needs – the first step of the IRP.
All parties–operations, SLM, BRM and the IRP manager–use their understanding of both IT and the
business to propose improvements to operational services.

7.16
IRP Sub-Process 9: Continual Service
Improvement
Figure 13 IRP Sub-Process 9: Continual Service Improvement

The CSI process either responds to an urgent recommendation in the CSI register or schedules a
prioritisation meeting according to schedule.
7.16.1
Worked Example Stage 9
The continual service improvement (CSI) process is either run as a programme, with periodic
reviews of outstanding improvement requests, or is triggered by significant improvement proposals
that require analysis, prioritisation and planned execution.
Some recommended improvements might be radical enough to warrant being entered into the IRPR as
newly identified needs – triggering the whole IRP process again. This is the case with the following
worked example. The financial director entered the need as a means of achieving an improvement.
Smaller improvements will be forwarded, after prioritisation, to the change management process as
requests for change (RFCs).

7.17
IRP Sub-Process 10: Change Approval
7.17.1
Worked Example Stage 10
The change approval process deals with change proposals (covered earlier in this worked example
as part of the move to the design phase) and RFC’s. These are categorised into three types:
1. Minor changes are approved and operations authorised to make them, using appropriate
controls, authorisations and documentation
2. Normal changes are approved, possibly with the help of the change advisory board (CAB).
Once approved, these will be authorised for implementation by service transition
3. Major changes may require senior management or board authorisation and then may be handed
to the IRP manager to be dealt with in much the same way as problem statements.
 8. Requirements Lifecycle

‘Projects that had a central repository for requirements were more likely to succeed.’ 1
‘Analysts report that as many as 71% of software projects that fail do so because of poor requirements management, making
it the single biggest reason for project failure–bigger than bad technology, missed deadlines or change management
fiascos.’2
The process flow diagrams for the IRP have shown how the activities and tasks relate, as well as identify the roles involved.
Each requirement is a corporate asset and, as such, must be tracked through its lifecycle. This section deals with the lifecycle
of a requirement. Specifically, it describes the different statuses that a requirement can have during its lifecycle. This is an
important part of managing the requirements themselves.

T he process status diagram (Figure 13), shows the flow of a requirement through the IRP. The
possible status that a requirement can have at each stage of its lifecycle is shown, along with
valid transitions of status. The diagram distinguishes between the ‘normal flow’ (green) that most
requirements will follow, and the possible ‘exception flow’ (yellow) that may be necessary in
particular situations.
It is likely that there will be sub-statuses added to this overall flow for a particular organisation. This
is normal. Business analysts, service management professionals and developers will all work with
requirements at particular stages, and will wish to track their progress with the requirements, as well
as the overall status. This detail is not included here, in order to keep the diagram simple and to
recognise that the sub-statuses will need to be worked out in each organisation, to suit its
organisational structure and working methods.
This flow is the heart of the IRP. It is this process that enables a requirement to become an
organisational asset, as well as part of a particular deliverable, project plan, service design package
or developed operational solution.
After the process status diagram, Figure 13, each top-level status in the process flow is described
briefly. Some of these brief descriptions will need expansion into the actual workflow in a particular
department–for example the ’15. Validated’ status will require a description of the stakeholders
involved in the process, the policy for arriving at an agreed validation as well as any escalations or
other decisions that need to be made.
The whole process is, as with all service management processes, under the control of change
management. In a particular organisation, the process owner will have to work with the change
manager to establish how approvals, work orders and RFC’s will fit into this process–and this will
need to be enforced as part of the tool requirements.
Figure 14 Process Status–Lifecycle of a requirement

8.1
Need Identified
Needs may arise from the following, and other areas:
• Incidents
• Problems
• Change management
• Business relationship management
• Business requests
• Continual improvement initiatives
• Customer issues
• What is important is that the requirements are captured. It may be, initially, that they can be
logged in the requirements register as general requirements that can, later, either lead to
completely new services, processes or other solutions, or result in being recognised as
important and added to existing solutions or current development projects.
At this stage, a requirement will often be in a rough form, not clearly articulated and not, perhaps,
easily understood – as much as possible, though, it can be entered into the system, so it can be
considered along with other requirements.
From the point of scalability, a requirement that arises, for example, from the demand management
process, could be dealt with entirely by the capacity manager through the change management process
but, being logged in the register, the related risks, costs, benefits, and other associated details, are
visible to a wider audience and might help address some other need when found in a search of the
register.
The register is part of the service knowledge management system (SKMS), which provides the basis
for sound decision-making in a service management organisation. So these requirements provide
organisational and historical knowledge for future decisions, preventing re-invention, re-discovery
and rework.

8.2
Service Strategy
Requirements that appear to be new to the organisation and which might require novel solutions or
address new market spaces need to be considered using the service strategy processes. These
processes work with the business to identify what new initiatives ought to be fostered and which do
not fit the current direction or policy.
As with customer service level requirements (SLRs) some requirements might not be possible or
desirable at the moment. These can simply be kept in the register for future reference and use. This
enables frequent requests of this nature to be identified and re-prioritised.
Requirements in this status are actively considered as part of each service strategy meeting so that
they can be moved to officially logged requirements, or kept in the ‘need identified’ category, for
future consideration; alternately, they may be closed if really not appropriate, with an explanation.
Needs that identify gaps or issues with current policy or direction might be escalated to be
considered for adoption as changes in policy or direction. Where they conflict with current policy or
direction, and have no other redeeming features, requirements will be closed with appropriate
feedback given to the originator.
These closed requests will continue to be tracked, in case other stakeholders express the same
requirements – which might uncover a trend indicating poor communication of policy or, perhaps,
some other unfulfilled need.
Requests that are closed early, for any reason, need to be reviewed intermittently to ensure that the
decisions are well made, still valid and according to policy.

8.3
Stakeholder Analysis
Business analysis, when starting on a new engagement, needs to understand who the stakeholders will
be. This analysis can be started from scratch or, in a service management environment, will probably
start from the service strategy analysis of the market space affected.
Wherever the analysis is done it is important that all stakeholders affected by a new initiative are
identified.
The normal flow would be: A need is identified à service strategy approves this for further
investigation à this becomes part of a tranche of related requirements.
The tranche of related requirements is what the service portfolio would see as a prospective new
service, and it would then follow the service lifecycle. More requirements will be added through the
life of the service.

8.4
Elicitation
Once the stakeholders have been identified, a plan is produced that decides which methods will be
used to elicit requirements from stakeholders, in order to gain a clearer understanding of what the
identified strategic initiative is likely to involve.
This stage can take time and involve many meetings with stakeholders using surveys, face-to-face
individual meetings, workshops or other methods to identify requirements from stakeholders for the
particular initiative. All requirements identified in this process need to be captured and logged even
if, later, some may be duplicates, merged with other requirements, or split because they cover a wider
scope than just one requirement. It is, however, vital to record them, along with the originating
person, originating group along with date, time and contact information. All this is done to move a
requirement to the state of being ‘logged’.

8.5
Logged: Requirement / Late Requirement
The logging of requirements should take place as soon as possible in order to capture everything
during elicitation. It may not be possible to log them directly, during an elicitation session, but they
should be transferred to the requirements register as soon as possible.
Late requirements are a high-risk to the success of a solution, however they are inevitable. It is
important that they follow the same process, but are recognised as having higher risk. That is why the
status of ‘logged – as a late requirement’ is included. A fast-track approval can be followed but,
where appropriate, late requirements may be either left out of the current scope and marked for a later
phase or raised to risk management to be considered in the larger change evaluation. This ensures that
a properly informed management decision can be made on perhaps delaying the overall delivery of a
solution or leaving out a requirement that, because it is late, is overly onerous in terms of cost.
Importantly this makes the arrival of late requirements highly visible. Those that are inevitable can be
managed appropriately. If, however, it transpires that for political reasons, habit, or some other
reason, some parts of the organisation, or individuals, frequently lodge important requirements late in
the process in the hope that they will avoid the usual scrutiny, this can be tackled properly as a
management issue. This avoids the situation where these late requirements become an extra stressor
to development often leading to delays that appear to be the fault of development or project
coordination, when they are, in fact, related to poor collaboration habits in the organisation.
Problems in this area can be resolved by improved communication, more senior management
commitment and a concerted education of stakeholders on the importance of timely provision of
requirements. See the controls section.
The requirements register tool provides workflow options to enable the escalation and resolution of
issues resulting from late requirements. See the tools section.

8.6
Categorised
Requirements have been entered into the appropriate categories. Mostly this will involve separating
utility (functional) from warranty (non-functional) requirements, understanding the utility
requirements in terms of functionality supplied, constraints removed or both.
This is also where some preliminary judgement can be made on the importance of requirements. They
can be put into categories based on cost, value, risk, urgency and impact.
Whilst it is wise to agree a number of top-level categories, and some based on the areas previously
mentioned, this is where tags (hash tags, for example) can be used to great advantage. If a particular
set of requirements seems to form a natural grouping, this can be reflected by a tag which may be
something quite new and not considered when the top-level categories were defined. These tags can
be used to organise and categorise requirements and if new, popular tags are discovered, these can
either be added to categories or formalised as standard tags.
Requirements need to be analysed from various perspectives, both to aid understanding them and to
uncover innovative approaches to solutions. Such perspectives can be captured at meetings between
stakeholders and preserved quickly, and informally, as tags, which can be analysed in more detail
after those meetings.
Without this technique, important insights can be lost in unformatted text notes or linked to categories
that are not really appropriate; this can lead to a loss of the insight or suggestion.

8.7
Confirmed
The requirements are checked and a first attempt is made to produce unambiguous, well-formed
requirements. The implications of the requirements for possible solutions are not yet understood; this
is mainly a mechanical clarification exercise, making sure that the language is clear and reflects what
the originators have meant.
Another perspective can be derived from a stakeholder meeting where non-stakeholders can
challenge stakeholders. This is a tactic often used to stimulate innovation in an organisation.
Once they are clarified, it is best if any changed requirements can be confirmed with the originator to
make sure that the ‘clarification’ has not resulted in the actual need being distorted.

8.8
Prioritised
All the requirements gathered are examined for business impact and urgency, as well as the value
expected if they are implemented. This enables them to be prioritised according to business need,
taking into account risk and value.
If possible, at this stage cost is estimated, so that any particularly expensive requirements can be
analysed more closely for value, and possibly escalated to risk management to establish if they are
appropriate.

8.9
Organised
Requirements are organised into those that are wider organisation requirements (beyond the scope of
the current engagement), those which may apply to quite separate processes or services, and those
that should be grouped together for further analysis as part of this particular project or service.
8.9.1
Split
One requirement has been found to contain two, or more, separate requirements. This happens, quite
commonly, after an elicitation session.
It often turns out that, on analysis, more is meant by a stated requirement than originally met the eye.
The two, or more, new requirements are linked to the original requirement to ensure an audit trail is
maintained.
8.9.2
Merged
This requirement has been found to be part of another requirement, so has been merged with it. This
stage exists for practical reasons so that, if there are a large number of apparently connected
requirements, they can be moved to this status first, and then analysed carefully to ensure that no
subtle differences are ignored when an apparent duplicate requirement is closed.
The new, merged requirement contains reference to the constituent sub-requirements so that an audit
trail is maintained .
The previously separate requirement is closed – again to maintain an audit trail.
8.9.3
Duplicate
If the requirement duplicates another requirement, it will be closed, after having been moved to this
status, leaving only one authorised requirement. This stage exists for practical reasons, so that, if
there are a large number of apparently duplicate requirements, they can be moved to duplicate status
first, and then analysed carefully to ensure that no subtle differences are ignored when an apparent
duplicate is closed.
The remaining requirement contains reference to the closed duplicate requirements, so that an audit
trail is maintained.
It is important to keep track of all duplicates – apart from the technical necessity of doing so. There is
the important information when one requirement has arisen from a number of different stakeholders.
This may indicate that it is a more important requirement than it might have first appeared, so its
priority can be increased to reflect this.

8.10
Linked to Service Design Package (SDP)
The requirements that will be part of the planned service, service upgrade or improvement are linked
to the SDP so that they can be documented as part of the service lifecycle. The SDP follows a service
throughout its lifecycle and includes all relevant technical and business information, along with
design, transition, and operational and improvement documentation.
The SDP includes, particularly, transition and operational requirements that, though drawn up with the
help of experts in transition and operation, are produced in the design stage, before the service moves
to the transition stage.
The requirements for plans and planning are also part of design; in particular they are part of the
process design. The requirements for the release plan, for example, would be produced as part of the
design of the release and deployment management process that would be carried out by the transition
planning and support team.

8.11
Formal specification
The requirement is checked for consistency, clarity and ambiguity. It is re-stated, if necessary, in
formal terms and the record in the requirements register is checked to make sure that it is linked,
correctly, to all relevant projects, services, processes and areas. Once this stage is complete, the
requirement is sufficiently well understood to be modelled.

8.12
Model
The requirement, along with the other requirements for this project or solution, has been modelled,
according to policy. This might involve a number of techniques – rapid prototyping; wire framing,
use-case, user story, among others. These all enable different audiences to understand the
requirements, their interplay and to get some picture of possible solutions.
Analysed
The requirement has been analysed and confirmed to be unambiguous, to make both business and
technical sense. An estimate has been made of the possible cost, risk and value to the business of this
requirement. It is, in the jargon, now a ‘well-formed’ requirement.
All the agreed stakeholders, ensuring that this analysis is based on real-world understanding as well
as technical analysis, have approved the model produced in the previous step.

8.13
Assumptions & Constraints
The requirement has been examined by the relevant technical experts (developers, business analysts,
capacity, availability and others) to determine the implications it has for the solution. Technical
experts are found largely in the technical and application management teams, as described in ITIL
service operation.
What assumptions does the requirement imply? What constraints will the requirement put on possible
implementation? This is likely to involve wider consultation, possibly including discussion with risk
management, to make certain that the solution will not be compromised by a poorly formed or poorly
understood requirement, or vice versa.

8.14
Verified
The requirement has been verified technically. This means that an appropriate person, possibly a
business analyst, a developer, or a service management professional (probably for any medium or
large project, a team of these) has verified that this requirement makes sense, is properly understood,
can be met in accordance with current policy (which might require, for example, known current and
affordable technology – or a specific analysis of new technology that might be appropriate) and will
add value to the organisation at reasonable cost and risk from a technical point of view.
Technology moves very quickly and possible solutions may exist that are not known to the originator
of the requirement or to technical staff. Before moving to the state of verified, particularly for an
important, high risk or high cost set of requirements, it would be wise to instigate a small research
project, probably involving capacity management, to explore the market for possible types of
solution, or parts of a solution that are, perhaps, ‘outside the box’ of currently known technology.

8.15
Not Appropriate
The requirement has been deemed not to be appropriate by the requirements validation team. This
could be for many reasons. Importantly, the reason for the decision is listed in the requirement, along
with the name of the decision maker and communicated to the originator. This makes sure that
requirements are not simply discarded but, when they fail the validation process, are checked before
being closed.

8.16
Validated
The requirement has passed the validation process. This means that the person accountable for doing
so has authorised the requirement as one that will be included in the business case, RFC or change
proposal.
This means that the validation team has confirmed that the requirement is:
• Within corporate policy
• In accordance with corporate and IT strategy
• Appropriate in terms of cost and risk
• Able to deliver value to the stakeholder and, hence, to the business
• Quantified the cost, risk and value, from a business perspective, where possible.
The validation team, as part of the service design process may, at this stage, move particular
requirements to the ‘not valid’ status where they can be closed.
Typically, these two verifications are part of service design meetings. Requirements can be moved to
‘discard’, ‘close’ or ‘reject’ for reasons of efficiency and effectiveness.
Not Valid
The requirements validation team has deemed this particular requirement not to be valid. This could
be for many reasons. Importantly, the reason for the decision is listed in the requirement, along with
the name of the decision maker and communicated to the originator. This makes sure that requirements
are not simply discarded, but, when they fail the validation process, are checked before being closed.

8.17
Chartered
Having been presented with the final business case for the solution, the approving authority –
possibly the board of directors for a large project, or the CEO or CIO for a smaller project – the
move to the ‘chartered’ status means that the solution has been approved. A budget exists so that, from
a precise date in the near future, work can begin to plan the design process and bring together the
design team. At this stage, key players, such as the process owner and the service owner, are brought
on board and discussions are opened between the service design team, service transition and service
operation management to ensure that a holistic plan for design and deployment is developed. Top
level service acceptance criteria can be set at this stage to guide all future design, development and
transition activities.

8.18
Solution Design
The requirement is currently with the solution design team. This means that that team will be making
sure that any proposed design conforms, both in utility and warranty, to the requirement. It is possible,
at this stage, that the originator will be contacted for further clarification, either directly or as part of
a wider consultation.
Wider design consultations at this stage may involve a number of techniques – wire frames, UML (or
other) use-case diagrams , user stories or similar to communicate with the originators of the
requirements, as well as all other stakeholders. This is to ensure that affected parties understand the
intended nature of the solution and, possibly, through product demonstrations, pilots or proof-of-
concept demonstrations that the proposed solution, or potential solutions, will actually meet the
requirements of stakeholders.
It is during this phase that further changes to requirements are to be expected. This is also where it is
quite likely that new requirements will be uncovered. If these new requirements are deemed to be
minor clarifications, they can be added. If, however, major changes to requirements emerge, these can
be logged in the ‘late requirements’ part of the process to recognise that there is an increased risk of
delay to the project.
The categorisation of requirements as ‘major’, ‘minor’ or similar will be based on the impact to
budget, in terms of resources needed for planning, implementation and operation of this requirement.
The research to determine the correct category will be undertaken by the service design technical
staff as well as development staff involving considerations of warranty, as well as utility, so these
can properly be evaluated in relation to the value delivered.
 8.19
Solution Approved
The change manager has approved, or ensured that there is appropriate approval for, the solution in
which this requirement is met. The originator is contacted at this stage to be informed of the decision.
The originator might have more useful information to add that could help with the development,
transition and deployment of the solution.
The solution approval by the change manager will be the result of the change proposal, request for
change (RFC) or business case for the solution being approved.

8.20
Service Transition
The requirement forms part of a process or service undergoing transition. This means that the
requirement will be linked to service acceptance criteria and checklists so that the testing, validation
and change evaluation processes can take account of how well the transition is catering for each
requirement. If any requirements are failing any of these, the requirements will be listed in the change
evaluation report so that the change manager can use the original requirement to make the decision as
to how the issue will best be resolved.

8.21
Service Operation
The requirement forms part of one or more services, processes or other solutions that are part of the
live environment, managed under service operation. Depending on the granularity of the incident and
problem management categorisation systems, each requirement in this state can be linked to incidents,
problems, complaints or compliments related to its solution. This enables any requirements that are,
through their solution being inadequate, leading to such issues (or successes). Requirements in live
operation can be monitored and those that appear not to be satisfying stakeholders can be suggested
for improvement by listing them in the CSI register.
8.21.1
Completed
The solution has been deployed successfully to service operation. The service, project or process,
has now completed, so the requirement can be moved to the status ‘closed’. Before that, however, the
requirement is likely to form part of a change review for the closing service or change. It is expected
that this status will usually be limited to requirements for particular short-term projects.
8.21.2
On-going Design Requirement
The requirement has been integrated into a service, process or other solution, but has wider
applicability to future design decisions. It has, in effect, become a design criterion for future designs.
Since the requirements register is kept centrally and is available to everybody likely to be involved in
deploying a new solution, project or process, all requirements in this state will be considered and,
where appropriate, acted upon, so that future deployments of possibly quite different services will
still conform to this requirement.

8.22
Continual Service Improvement (CSI)
The requirement is currently part of a CSI improvement cycle. This means that the service design
package (SDP) of which the requirement is part, undergoes an improvement during this cycle. The
requirement can be monitored to ensure that the improvement does not affect it negatively but, rather,
if possible, delivers the requirement more effectively, efficiently or cost-effectively. It is important
that all affected requirements are linked to the SDP and are visible through the CSI register so that,
when decisions are made concerning the improvement plan, none of the requirements is ignored. It is
easy, without this, for a requirement to be missed and an intended improvement to cause things to get
worse because the requirement is no longer met.
8.22.1
Superseded
This requirement has been superseded by another requirement. This may be because the requirement
has been understood more clearly and found to be part of another requirement that is better described
separately, or it may have been part of a service that has been replaced with the requirement
superseded by a new and different requirement. In either case, the superseded requirement will
include a link to the requirement that has superseded it, along with an explanation of how this has
come about. It would normally be important to inform the originator of the requirement that this has
happened in case they come to the conclusion that their requirement has been simply closed and their
needs ignored.
8.22.2
No Longer a Business Requirement
The requirement has been agreed no longer to be required by the business. This may require the
particular functionality to be removed from a process, service or solution, or might require an entire
service to be retired. Once everything associated with this service has been removed or retired, it can
be moved to the status ‘closed’. This status is important so that the fact that it is not required by any
part of the business can be validated, along with an understanding of whether this is permanent, or
whether this may become an active requirement in the future.

8.23
Service Improved
This means that the CSI cycle has been completed and the solution to the requirement has been
improved, so the service should be providing a higher level of satisfaction to customers and users. It
is important that a requirement stays in this state until the next CSI cycle so that work can be done to
check that the service has, indeed, improved the stakeholder satisfaction. Once the organisation is
satisfied that it has, the requirement can be moved to ‘service operation’ to indicate that it has, again,
become part of standard operating procedures (SOP’s).

8.24
On-going CSI Requirement
Requirements in this state are in the CSI register at a relatively high priority. They are not necessarily
outstanding issues, but are requirements where the solution in place is not adequate to meet current
business needs and will have to be improved at some time. When that happens, it is under the control
of the CSI prioritising process and, of course, change management. Being in this state gives the
business relationship manager the opportunity to discuss these with the business to decide if a higher
urgency or impact is justified in order to make it more likely that the requirement will be met.

8.25
Requirement Delivered
This indicates that the requirement has been delivered successfully.
Closed (Feedback to Originator)
The requirement is no longer active but is archived, according to agreed policy. It is important to
archive even closed requirements, because it is possible that they may arise again and the information
as to how they were dealt with previously will be valuable to prevent unnecessary re-work or, if
circumstances have changed, to show why the previously closed requirement was again worth
considering.
1. [Ibid.]
2. Christopher Lindquist, Fixing the Requirements M ess, CIO M agazine 15th November 2005
 9. Governance Structure

T his section analyses the IRP from a governance perspective. We have seen how the activity flow
of the IRP works, and have seen the lifecycle of a requirement. Now it is necessary to see, from
the corporate governance and management point of view, how the IRP is controlled, what reporting is
done and what resources and capabilities are needed. This is done to assess how to manage the IRP
as a company-wide process.
The process is considered as comprising the capabilities and resources required to enable its
operation, the actions that take place and the controls that ensure that the process is managed and
governed properly.
All processes have a common structure. This structure is used to describe how the various parts of
the process relate to each other, by means of a generic process diagram.

9.1
Process Diagram Overview
A process consists of three main sections – control, activity, and capability. The Control section, at
the top of the diagram, ensures that the process is governed and managed properly. The Activity
section, in the middle, describes the activities, procedures, and work instructions that enable the
process to flow – these are the documented part of the process flow described above. The activities
are what take the defined input of the process and turn it into the defined output. Finally, at the bottom,
are the capabilities and resources needed to drive the process.
The Process Owner has the responsibility, when designing a process, to ensure that all three parts of
the process are defined and communicated clearly and that the roles and responsibilities of all parties
involved are understood. The process diagram can be used as a guide to ensuring that all parts of the
process have been addressed.
Figure 15 Process Diagram Abstract Process Model–Components of a Process

9.2
Control Section
Figure 16 Process Diagram–Control Section

9.2.1
Objectives
The purpose of the integrated requirement management process is to deliver service, product and
process solutions that achieve the goals and objectives of the business by understanding the
requirements of the business comprehensively and, dynamically, to track changing business
objectives.
General objectives include:
• Managing the lifecycle of all requirements in a consistent, cost-effective, traceable manner
across all business units, projects and services
• Ensuring that risks related to requirements are identified and tracked consistently and
effectively
• Providing a basis for continual improvement of the process and component sub-processes to
reduce risk and making the solutions align with business priorities in a flexible and agile
manner
• Enabling clear communication between stakeholders and service designers, developers,
transition staff and operational staff
• Managing requirements to enable strategic governance objectives
• Managing the requirements interfaces between stakeholders, business analysis, business
relationship management, and the other service management processes and functions
 • Enabling the development of organisational capabilities to elicit, analyse, evaluate, and then
guide requirements through design, development and transition to high quality business
solutions based on services
• Managing requirements appropriately according to business priority, cost, urgency and impact
• Ensure effective management of changes to requirements
• Ensuring that late requirements are adequately handled so that they do not impact adversely on
service delivery quality or timeframes more than necessary and, over time, managing the
number and impact of late requirements downwards
• Managing TCO, charge back and risk most effectively
• Overseeing all requirements holistically
• Ensuring requirements become corporate assets. The value of this IP will increase with reuse.
9.2.2
Goals
Many of the goals of the requirements process are documented in Cobit5, where they are made the
goals of the constituent sub-processes BAI01 (manage requirements definition) and BAI02 (manage
solutions identification and build).
The top-level process goals are:
• Business goals integrated into service solutions through well understood, well-defined and
agreed requirements
• Organisation-wide traceable requirements for all services and products
• Controlled solution development/procurement, based on requirements
• The IRP should produce requirements that are:
– Based in business policy and strategy
– Analysed from a corporate perspective
– Analysed from the perspective of a particular process, application or service
– Maintained as a corporate asset in the requirements register
– Linked, where appropriate, to risks, the service design package as well as to particular
projects
– Properly maintained with an adequate audit trail
– Managed through the change management process
– Well categorised and named so as to be easy to find if appropriate in other situations
– In the case, specifically, of a software solution, traceable from initial conception to specific
implementation in a solution – it should be possible for any piece of code to be linked, to the
ultimate requirement that led to its creation.
9.2.3
Requirements
These requirements, to avoid confusion, are the requirements for the IRP itself. For consistency and,
perhaps, to use this process as a pilot for the implementation of the requirements register, these
processes should also be refined for your organisation and included in the requirements register.
9.2.4
Policy
In order to succeed, the organisational governance policy must include the requirement that the IRP
controls solutions, services and processes. This enables the deployment of the process to be
established as sound governance, as well as ensuring that senior management support for the process
is sufficient to deal with teething problems, including resistance from individuals or parts of the
organisation.
9.2.5
Stakeholders
Stakeholders are best identified during the set-up of the IRP. If possible, it would work best if they
are identified and prioritised as part of an organisation-wide management of value (MoV)
programme.
9.2.6
Scope
The scope of the process must cover all business units, the entire service management lifecycle and
all solutions used by the business. Pragmatically, the IRP should be introduced as a pilot for one
particular service or business process and then extended, in a controlled manner, across the service
portfolio and to all business units and processes.
9.2.7
Process Manager
This role crosses a number of organisational boundaries; there will be a number of owners of sub-
processes in development, service management and business analysis. The overall responsibility for
managing the process is, however, an important one, requiring an individual with good
communication skills, technical and business, as well as an understanding of these three areas.
The uniting view is that of the service portfolio – requirements drive the move of services from the
pipeline to becoming operational and on to being retired. There is logic in the process manager
reporting to the service portfolio manager role.
The process manager role requires the same broad range of understanding as is required for the
capacity management role. If the organisation has a function that handles the service management
warranty areas – as envisaged by the ITIL intermediate training ‘Planning, Protection and
Optimisation’ (PPO), then the process manager (and possibly process owner) for this process could
be part of this function.
This role is discussed more fully in the IRP Flow chapter.
9.2.8
Process Owner
This role interacts with all of the service management processes and most of the business processes.
The role has a very broad scope. The owner of the overall process must ensure that the process is
adopted and works effectively in the domains it crosses: business -> business analysis -> service
management à development. The overall process owner may well choose to appoint owners for the
subsidiary processes in each area or, adopting the Cobit5 division, for the requirements and solution
phases of the process.
This role is discussed more fully in the IRP Flow chapter.
9.2.9
Audit as a Control
From the point of view of an auditor, a requirement (or as SOA would have it, a ‘requirement object’)
is a corporate asset. That is, it takes on the nature of any other corporate asset in that its controls must
be defined in the corporate policy.
The audit controls for a corporate asset include ensuring that there is a split between roles, for
example, between the person who is responsible for a task and the person who approves the
completion of the task or who authorises the budget based on the output of the task. The IRP has been
designed with this in mind but, when implemented in a particular organisation, it is a responsibility of
the IRP process owner to ensure that all such audit controls are in place and documented in the policy
and in the RACI matrices for the process.
Any process, including the IRP, must be audited, both internally and externally, to ensure that it
complies with corporate governance and operates as designed. The audit is likely to be carried out
using Cobit5, in particular, Cobit5’s BIA02 (manage requirements definition) and BIA03 (manage
solutions identification and build) areas.
9.2.10
Control through Critical Success Factors
9.2.11
For any activity, project or process it is vital to know what must be
achieved. A critical success factor (CSF) is a statement of a requirement
that is essential. If this requirement is not met, there is a business failure.
A CSF should be stated simply and clearly, in unambiguous terms, so that it can be easily understood.
Though it may be easy to understand a CSF, it may be very difficult to measure it and often, in fact,
impossible to do so. That is why CSFs are measured by key performance indicators (KPIs). A KPI is
a measure that gives some indication of how well a particular CSF is being met. KPI’s define a
threshold for when a failure of the CSF will have occurred. This can be used to define an alert before
such a failure to allow corrective action to be taken.
More CSFs, KPIs and metrics can be found in Cobit5 – the ones that follow are selected examples for
the IRP. Each organisation ought to design CSFs, KPIs and other metrics in line with business
requirements.
9.2.12
Customer Satisfaction and the Kano model
Customer satisfaction has previously been addressed in relation to product quality in design. In
particular the Kano model, developed by Professor Noriaki Kano in the 1980’s, devised a quality
function deployment (QFD) matrix that can be used to identify where a particular delivery sits in the
‘need fulfilment’ against ‘satisfaction’ axes. Possible results are ‘Basic Needs Met’, ‘Indifference’,
‘Performance’ and ‘Excitement’. The model uses five categories of customer preference: Attractive,
One-Dimensional, Must-Be, Indifferent, Reverse.
9.2.12.1
CSF examples for the IRP
• The business is satisfied that solutions resolve business problems as agreed
• Stakeholder and staff satisfaction with the process and solutions is high
• Business risk is reduced
• The IRP is organisation-wide
• All solutions (products, services and processes) are produced in accordance with the IRP
policy
• Late requirements do not hinder successful delivery of solutions
• The IRP delivers measurable business improvement
• Business analysis, service management and development work as a coordinated team under
the IRP.
9.2.13
Metrics
Metrics for this process need to be designed as part of process implementation, under the guidance of
service design (the part of the ITIL 2011 lifecycle that gives advice on the design and deployment of
processes). These metrics can be adapted from the metrics cited in Cobit5 or can be designed from
scratch.
This process gives the lifecycle of a requirement. That is, it provides the status transitions that
requirements pass through. When these are implemented, as part of the requirements register, they
enable the measurement of requirements metrics that can give the following type of information (these
are examples, rather than suggestions of ideal metrics):
• The ratio of metrics, verified vs. elicited, across the organisation or for a particular project
across time. This gives a measure of progress.
• The ratio of logged requirements vs. late requirements for a particular project gives, over
time, a measure of how the discipline of logging requirements as early as possible is being
enforced. Initially there are likely to be a large number of late requirements, which, over a
period will reduce as a proportion.
• The average time for a requirement to move from logged to closed, split by closing
disposition, this is a measure of solution development time as well as the operation of the
requirements analysis process itself.
• The mean cost of requirement – measured from requirement logged to requirement completed
 by service, business process or solution. This gives a measure, with fine granularity, to enable
value vs. cost to be calculated.
9.2.14
Key Performance Indicators
9.2.15
The Business is satisfied that solutions resolve business problems as
agreed
• Satisfaction measures improve over time
• Business representatives at validation reviews give high satisfaction scores
• Problems and incidents related to requirements decrease
• Stakeholder and staff satisfaction with the process and solutions is high
• Satisfaction measures improve over time
• Business risk is reduced
– Satisfaction of board risk committee
– No audit failures
• The IRP is organisation-wide
• #Projects approved but not registered in service portfolio (when 0, the system is working).
This refers to projects that are approved outside the centralised service portfolio process –
something that should not happen.
• All solutions (products, services and processes) are produced in accordance with the IRP
policy
– Internal audit
• Late requirements do not hinder successful delivery of solutions
– Graph project delay versus % late/on-time requirements
• The IRP delivers measurable business improvement
– Improvement of ratio of business value/requirement cost
• Business analysis, service management and development work as a coordinated team under
the IRP
– % Requirements linked to SDPs & CSI register
9.2.16
Norms
KPIs in particular, and other metrics, are measured against norms (‘norm’ is short for normal value).
This allows the KPI to be monitored by a control loop. That is, the value of the KPI at a given time is
checked against the norm – if it is outside the norm, then an automatic action is taken to correct the
situation, or an alert is sent to the responsible person to take appropriate action.
It can be difficult to know what the norm should be. If the norm is unknown, it is best to run the pilot,
measuring the relevant values for the KPIs and metrics, then set the norms based on the pilot values,
adjusted for differences in volume in the full implementation. Then, over time, adjust norms as each
KPI is understood better.
9.2.17
Effectiveness
The first aim of any process or service is that it is effective, that is, it delivers the minimal acceptable
business value. This is achieved by a number of methods, all of which involve some prioritisation of
requirements according to business need, the urgency of the need and the impact of the need not being
met being used to establish relative priorities. In development, this form of prioritisation has been
adopted by various techniques, such as ‘agile development’, ‘rapid prototyping’, and ‘scrum’.
Whilst speed of development is often emphasised, the crucial factor is that the most important and
urgent business needs are, as a minimum, satisfied at the pilot and first release stages.
Metrics can measure effectiveness by the percentage of requirements met by the solution, by urgency
and impact. Effectiveness can also be measured by surveys, interviews and satisfaction reports from
stakeholders.
9.2.18
Efficiency
Once effectiveness has been achieved in delivering a process or service, the cost of delivery, relative
to the value delivered, can be measured and those areas that cost the most to deliver (the least
efficient) can be improved by changing the process used or automating more of the process to
improve it.
Metrics for efficiency can use the elapsed time between status changes as an overall measure as well
as the actual time spent by staff at each stage of the process. This is achieved best by measuring time
spent automatically – for example, when a business analyst is working on a document checked out of
the document management system (DMS), the actual time worked can be measured by the word
processor or DMS. This is to be preferred over timesheets that are notorious for their inaccuracy.
9.2.19
Activity
Activity metrics measure each of the stages in the IRP or the activity of particular teams. Where
possible, activity metrics should be related to the particular process, project or service being worked
on but, if this is not possible, overall team activity can be measured and apportioned across the active
requirements to give some estimate of the time spent and, hence, the cost of the activity relative to the
value of the requirement to the business.
9.2.20
Demand
One of the important processes in ITIL service management is the demand management process. It is
documented in Service Strategy (ITIL) and managed alongside the capacity management process.
The aim of demand management is to understand the volume and nature of demand for a particular
service or process. In the case of the IRP, the measure is the cost of the requirements. Cost is a
measure of development time as well as resource cost per requesting department or project. A
measure of the patterns of business activity from the business and customers can be seen by the
importance of particular requirements across the board, the number of incidents, problems or
complaints related to the requirements not currently being met, or the value placed on the
requirements by the business.
This is a complex area and some thought is required to understand how to measure demand in a
particular organisation. This enables a check to be made on the effort, in terms of capability, time and
other resources expended on particular projects, processes or services.
At a more granular level, requirements match the importance to the business of the requestor or
beneficiary of the effort. That is, a measure can be made of cost vs. value.
One of the problems that organisations encounter when requirements are poorly managed is that
demand is not related to actual business need but to the organisation’s ability to be effective in making
its voice heard by IT – resulting in a skewed set of priorities in development.
9.2.21
Implementation
Implementation metrics fall into the service transition part of the ITIL service management lifecycle.
However, as with all metrics, they are designed as part of the service design effort. Implementation
metrics are often based on the use of checklists to establish when particular acceptance criteria have
been met, marking the end of each stage of the transition.
9.2.22
Pilot
It is recommended that, in order to reduce risk, processes and services are first implemented as a
pilot. The pilot for implementing the IRP should be designed to make sure that all parts of the process
are involved, as well as a fair representation of stakeholders whilst, at the same time, making sure
that the pilot does not cause negative impact on existing processes and services.
The aim of the pilot is to identify areas of weakness, so that these can be improved before the process
becomes generally adopted. This enables training in the process, documentation and tools to be
improved in order to be more effective in rolling out the process itself.
9.2.23
Documentation
The documents required for the process have been described in other sections. What is important is
that these are managed centrally. Ideally, creating a service design package for the IRP itself, keeping
all documentation within this package, should do this.
9.2.24
Communication
As with much of life, communication is vital to success. It is not enough to have good intentions, steps
must be taken to ensure that it actually happens, and is targeted correctly at those who need it, when
they need it, in a form that makes sense to them.
Part of the design of the pilot for the IRP should be the design of comprehensive communications
plans for all stakeholders at all stages of deployment, as well as a plan for exactly how the various
tools will integrate into the communications structure.
With requirements management, this will go beyond simply communicating the process itself, how the
requirements register works and the way in which the activities take place. The methods that the
organisation will use to communicate with stakeholders as part of requirements analysis will form
part of this documentation. The structure of UML diagrams, use-case diagrams, wire-frame
demonstrations, user stories and the other techniques used in requirements definition, and well
described in the BABOK, will be kept as models for the IRP.
Part of this is to ensure that the continual improvement cycle can have visibility of the effectiveness of
the various techniques. If, for example, an organisation finds that user stories are more effective at
validating and generating requirements that match business needs than, for example, UML use-case
diagrams, then the communications policy should be changed to train more people in the use of user
stories as well as to update, and improve, the templates and advice given to make the use of these
more effective. Of course, if it proved the other way around, the advice would be reversed!
The aim is to centralise and codify the organisation’s knowledge of how to communicate effectively
during the requirements process, so that a consistent and effective process can be shared and taught to
everybody. This is part of the service management strategy of having a service knowledge
management system that enables an organisation to make better decisions. In this case, the decisions
will affect the planning of the stages of elicitation, analysis and validation.
Understanding of the business itself, strategically, will form part of this information as well. What
would conventionally be part of enterprise analysis will be kept here to be communicated to business
analysts at the start of each cycle, and updated when it changes. This information would be acquired
through the business relationship management and service level management processes, as well as
from each business analyst’s contribution as a result of conversations with customers.
9.2.25
Governance
The IRP is linked to governance through it being designed according to corporate policy and aligned
to the goals outlined in Cobit5.
9.2.25.1
Corporate Governance
This part of governance involves making certain that corporate policy is translated into management
action – in particular, by making certain that the process itself, as well as each requirement, is
checked during the validation phase for its adherence to corporate policy.
9.2.25.2
Business Governance
Business governance ensures that the assets of the company, including finance, are being used for the
benefit of the company. The IRP ensures this by validating that each requirement is according to
corporate policy and is evaluated for its value/cost ratio.
 9.2.25.3
Sourcing Governance
Sourcing governance deals with the proper policies for deciding whether to build a solution or buy it.
It covers purchasing decisions including service procurement.
9.2.25.4
Operational Governance
Operational governance involves the strategic policy decisions necessary to achieve operational
excellence. It is part of, and drives, both SOA and Togaf architectural decisions. In part, the IRP
assists with operational governance as it provides the means to track and measure exactly how
strategic policy requirements drive the design, production, delivery and operation of services.
9.2.26
Risk/Value
The board of directors of a company is accountable for managing the risks accepted by the company
and producing the value required by the company stakeholders. This is ensured by the IRP because all
requirements are evaluated and validated against the corporate policy and, where appropriate, linked
to the risk register to ensure visibility to the board (usually to the board risk committee).
As well as the requirement that the IRP manages risk and produces value according to corporate
policy and guidelines, the process ensures that each requirement is evaluated for cost, risk and value,
embedding the corporate risk policy deep into all solutions, services and processes–something that
can be validated by periodic audits of the process using Cobit5.
9.2.27
Policy
When the IRP is adopted by an organisation, part of the planning and implementation process is to
produce a policy for the process itself. This policy will be based on corporate policy and guidelines,
as well as IT policy and guidelines. This policy will cover the specifics of, for example, when a
requirement should be listed on the risk register.

9.3
Action Section
Figure 17 Process Diagram–Activity Section

9.3.1
Input
The input to the IRP is described in detail in Chapter 10. The diagram below shows potential sources
of requirements in an organisation.
Figure 18 Input: Sources of Requirements

9.3.2
Output
The main output of the IRP is a satisfied requirement. This might be an internally developed and
deployed service, or a service developed and deployed by a third party in response to a request for
proposal (RFP).
In either case, the end point of the process, a successful requirement, is the validated, working
solution. The requirement will be linked to the solution.
Operationally, incidents and problems traditionally are linked to the relevant configuration item (CI).
This will be the component that caused the error, as well as the person(s) and organisation
experiencing it. Importantly, for the quick resolution of incidents using incident models and
workarounds, these are linked to the service.
The service is described by the SDP, which contains the requirements. Where appropriate, the
requirement will be raised in the CSI register to be addressed in the CSI improvement cycle. This
gives finer granularity than simply linking to the service, application or CI.
The aim of the IRP is not simply to produce a working solution, but to ensure that the solution has
been properly designed for the organisation, according to corporate policy, with an appropriate
cost/value ratio and risk profile. This is achieved, as the contributors to value diagram (figure 19
)indicates, by designing the requirements for both utility and warranty, both of which are established
by providing the correct level of usability for the stakeholders shown.
The IRP keeps requirements in the requirements register for each stakeholder, as well as having
specific requirements for particular solutions and services. This ensures that all stakeholders are
identified and linked to their requirements, and services. This holistic view is vital for effective
delivery.
The sources of requirement diagram (Figure 17 ) shows many possible sources for requirements and
how these requirements are captured in the IRP register and, when they become part of a solution, in
the SDP.
9.3.3
Triggers
To describe an activity, or set of activities, as a process, it is necessary for there to be specific inputs
to the process. These inputs are referred to as triggers. A trigger is what gets a process started. The
specific triggers for the IRP are:
• A new business requirement – it may become evident to the business that, because of a new
direction it has decided to take, or a change in its vision, strategic direction or business model,
a new service, or a change to the existing services, is required
• Corporate strategy might trigger the process. For example, a strategy of fostering innovation
might encourage new requirements to be developed directly
• Corporate strategy change, with a new strategy or strategic direction being a trigger for
innovative requirements development to satisfy it
• A change request – a request for change (RFC) may arise as a result of solving a problem,
dealing with an incident, handling an unusual customer or user request or a capability that is
identified as missing during a service level review. It could also be the result of a business
relationship management discussion with the business, or from a business analyst as a result of
a discussion with users or customers
• Continual improvement – The ITIL continual improvement cycle will identify and prioritise
items in the improvement register and schedule these for action. Some of these may include, or
actually be new requirements for existing processes or services that will trigger the IRP
• External technology or business pressure – a new technology might be identified that could
enhance the way business is done, or such a technology may be adopted by a competitor,
making it necessary to identify a service that can counter the advantage this provides for the
 competitor
• External legal, governance or obligations for fiduciary duty will impose particular
requirements on the business that may trigger the process
• Part of the elicitation process – discussing a new initiative with stakeholders in order to elicit
all requirements will trigger new requirements for the initiative itself, and possibly for other
initiatives, that may be outside the scope of the current one
• Part of the requirements analysis or development cycle – it may become apparent as
requirements are analysed in depth, when they are relayed back to stakeholders as a wire-
frame or similar visualisation device, or during the technical interpretation of requirements,
that some underlying requirement has been uncovered and must be added to the current list of
requirements. Requirements triggered in this way are dealt with by the alternative route
through the process reserved for late requirements
• Merged requirements – often a number of requirements are elicited from different stakeholders
that turn out to be different aspects of the same requirement. These can be merged into one
requirement that then becomes a new requirement. If this occurs late in the cycle, the late
requirements sub-process can also handle it
• Split requirements – a large requirement may be composed of a number of distinct sub-
requirements. This will mean that the requirement must be split into these constituent sub-
requirements and each of these managed separately, possibly through the late requirements
route.
9.3.4
Improvements
All processes can be improved. When deficiencies are identified these can be added to the continual
improvement register for consideration at the next improvement cycle. If approved, the improvement
plan is included as part of the process documentation so that the process can be improved as planned.
Improvements are acted upon in the spirit of the Deming plan-do-check-act cycle of quality
improvement.
The ITIL framework is designed to assist companies establish processes and services so that they are,
initially, adequate in effectiveness. Then, over time, as deficiencies or possible improvements are
identified, these can be prioritised and, where appropriate to business needs, acted upon to make the
process or service more effective or more efficient when there is a business justification for doing
so..
The IRP will, at any time, have a number of improvements documented. These will be in the
corporate CSI register, but will also appear in the process documentation, showing their priority, cost
and, if approved, when they will be delivered.
9.3.5
Value
The contributors to value diagram (Figure 19 ) indicates how value is created. For each organisation
and stakeholder it is necessary to understand the business value that a solution or service is designed
to deliver. This diagram provides a model for understanding this value, which must then be used in
validating a requirement. The validation process uses the model, adapted for the organisation’s
stakeholders, to establish the value each requirement will deliver and how it will do so.

Figure 19 Services Designed for Usability

9.3.6
Utility
Utility is the value that comes from using a service, solution or process. It is what the customer, user
and other concerned stakeholders obtain from the live solution, running during service operation.
 9.3.6.1
Functionality Added
Most people recognise that a solution or service does something. It delivers what business analysts
call functionality. An invoicing system prints an invoice or sends it through e-mail, or presents a
well-designed GUI to users. All this is evident and demonstrable in the final service and is
demonstrated to stakeholders during the ‘wire frame’, ‘story board’ or ‘use-case’ stage of
requirements validation. It is an important part of the delivery of utility, but it is not the only part of
the delivery.
Many good solution developments fail to be excellent because they consider functionality to be the
only part of utility. The conventional term for requirements that do not provide functionality is ‘non-
functional’ requirements–this is an unfortunate term as it suggests that these requirements (known as
warranty in service management) do not contribute to the functioning of the solution, when this is not
the case.
9.3.6.2
Constraints removed
The more subtle side of utility is what it allows the user, customer or stakeholder to do. If the service
was not there, not only would some other means have to be found to do what the business process
requires, but the business would have to spend time, money and use its assets to provide this
requirement. Thus, a solution provides utility by removing these constraints.
A simple example should help make this clear. It is not compulsory to have a bank account. It is
possible to keep your money at home. Not only does keeping large amounts of money at home
increase your risk and the cost of your home security, but it erodes your peace of mind. You cannot be
comfortable away from home for long because, in your absence, somebody might break in and you
would end up penniless. This anxiety means, for instance, that you cannot go on holiday and enjoy it.
Going on holiday and having a peaceful, relaxing time might seem a very long way from having a
bank account, but, because a bank account relieves you of the anxiety that your house may be burgled,
or that you have to take large amounts of cash on holiday with you, having a bank account does
remove a constraint that would otherwise prevent you from enjoying your holiday.
To understand this aspect of utility, it is necessary to understand the business of your customer and
your users well enough to know what constraints they have in doing business better. When you can
identify and understand those constraints, then you can provide services not just because they do
something, but also because they enable your stakeholders to do more themselves. This very
important and often extremely tangible; value is what good services should unlock.
9.3.7
Warranty
The warranty of a service covers how well it actually works, not what it does, but when and how it
does it. The four aspects–availability, capacity, security and continuity–are recognised by ITIL.
Warranty also depends on operability, supportability, maintainability, serviceability and the ability to
manage transitions.
 9.3.7.1
Availability
Requirements must be established for the enterprise as a whole, as well as for specific planned
solutions. To know what level of availability is appropriate–the higher the availability, the higher the
cost–a trade-off is usually required. Design should make sure that an appropriate level can be
supplied to the requirements, and that designs do not constrain the solution so that, if the business
requires increased availability than originally planned, it does not require expensive re-design to
deliver it.
9.3.7.2
Capacity
It is an important aspect of service management to balance the cost and risk of having either too much
or too little capacity to deliver a service. The design of a solution must include the ability to measure
the demand on the service so that capacity management can forecast future demand and take
appropriate steps to supply the correct level of capacity for the level of acceptable business risk.
Capacity management consists of three sub-processes:
Component capacity–performance and use of technology
• Service capacity–end-to-end performance & capacity
• Business capacity–future business plans & needs
9.3.7.3
Security
Service management concerns itself with security at the service level. Requirements management
needs to concern itself with security with each requirement. The overall solution may be sound, but a
requirement may weaken security in a subtle manner. To prevent this, all requirements, even late
requirements and highly technical requirements, must be analysed to make sure that any security
implications are within corporate and stakeholder risk parameters.
9.3.7.4
Continuity
In the event of a disaster, business continuity management will have set a policy that indicates which
services must be available and how they will be delivered. This may involve, for low priority
services, a recovery some time after the disaster or, for very important services, an instant recovery.
What is necessary in designing solutions for warranty is to ensure that all requirements are
understood in terms of their implication for continuity. It might seem, during the early stages of
designing a solution, that it will always be a low priority solution so it does not need to be designed
for quick and effective recovery after a disaster. This may change during the life of a service;
therefore, it is important that all requirements are considered for their implications to effective
continuity. If a requirement would make it impossible to recover a service or solution for some time
after a disaster, it would be necessary to raise this requirement to the risk register, so that the service
can be considered from that perspective, and a decision made on how to handle the requirement both
cost-effectively and with consideration to possible future contingency requirements.
Figure 20 Contributors to Value–Utility & Warranty

ITIL recognises that the aim of service management is to produce value for an organisation. The
business decisions an organisation makes as to which services it will deploy ought to be based on a
service portfolio that makes the ratio of the value a service delivers to the organisation, relative to the
cost of delivering the service, visible, so that high value/cost ratio services can be preserved as
important assets and objects of further development investment, whilst low value/cost ratio services
can be replaced, terminated, or improved to reduce their cost and increase their value to the business.
In order to do this, it is important to understand exactly what ‘value’ means to an organisation. ITIL
sees a service as valuable if it achieves two things:
It delivers the ‘utility’ required (in business analysis terms this equates to ‘functional requirements’)
1. It delivers the warranty required (in business analysis terms this equates to ‘non-functional’
requirements).
The understanding of value, in terms of the contributions of utility and warranty, makes it much
clearer to the business what is being achieved. The use of the term ‘non-functional requirements’ can
be confusing, seeming to be a statement that something negative requires investment. Warranty, on the
other hand, has a positive association with risk-reduction that makes diagrams, such as the
contributors to value diagram (Figure 19), easier for the business to understand.
Warranty is defined as consisting of the appropriate (in terms of cost and corporate risk
aversion/appetite) availability, continuity, capacity and security. Crucially, this is associated with the
end-to-end service, not just with the application, as tends to be the case with ‘non-functional
requirements’.
Utility, the way a service delivers value, is also recognised (as is warranty) as having two
components:
1. What it actually does–the technical workings of the service and the actual output of the
application. This is how most technical people in IT generally understand the solution to
requirements, particularly developers.
2. What it allows the business to do that it could not do previously. It removes constraints from a
business or business unit that prevent it being effective. This is the way that the business, in
particular the board of directors and financial staff, look at a service: ‘What, as a business,
will we be able to do better if we spend money on this?’
The contributors to value diagram (Figure 19 ) demonstrates the relationship between utility, warranty
and value, whilst also showing the different types and sources for utility requirements, making it
explicit that looking for requirements for a service is a superset of those for an application, as these
requirements involve suppliers, integration, as well as specific deliverables to enable the service to
be transitioned, operated, and supported. For effective delivery of value, it is vital that a service is
understood in this wider context and that the requirements analysis is not simply limited to those for
the application.
9.3.8
Reporting
Whilst each solution will have its own reporting requirements, the IRP has some essential needs if it
is going to be effective.
Requirements pass through a number of different parts of the organisation. This is one reason why
using the process model to manage them is so important. Things tend to fail at interfaces between
organisations, mainly because of a lack of clarity and a failure in communication. A process helps
enable clear communication. For example, the requirements register enables everybody involved with
requirements, from the business analyst, the developer, the administrator of the operational service,
among others to see the status of a requirement and understand its history. The requirements register
also enables the measurement of how well the overall process is running.
Reporting on the process, consequently, must allow the process owner and process manager to see
where the processes or sub-processes are breaking down in order to take action quickly. If, for
example, a large number of requirements emerge as late requirements, some few weeks before a
solution is due to be transitioned into an operational service, then this presents a high risk to the
organisation. The reporting process must be designed so that this situation, or any similarly high-risk
situation, can be identified automatically and escalation messages sent to the appropriate managers.
At that time, action can be taken to decide on the most effective response to the risk.
The danger is, without such reporting, individual developers or project managers, in the interests of
not delaying the delivery of the solution, might seek to satisfy these requirements without proper
planning and management of the risks or validation that the late requirements satisfy corporate policy.
This can lead to grave results for the organisation as a whole.
9.3.9
Feedback
The feedback arrow in the process diagram of the abstract process model (figure 14), indicates the
results of measurements made to the output of the process that are considered in both operational
management of the process and in making decisions on whether improvement is necessary.
The way feedback will be provided should be designed into the solution so that, particularly for high
priority requirements, a metric or KPI is designed so that effective and timely measurement of the
actual operational delivery of the requirement is taking place.
In the case of the IRP, the metrics to be measured are discussed in the metrics section of this
publication.
9.3.10
Activities
The top-level description of the IRP describes the activities that take place in the process. These
follow the activities described in the BABOK, ITIL, and COBIT5. The activities fit into the process
flow, which is fully described in chapter 7.
9.3.11
Procedures
The workflow from the process, as described, and modified for a particular organisation, can be
broken down into a set of procedures. Each can then be documented to describe how the work will be
done in more detail than simply the description of the activity. For each procedure, a RACI matrix can
be produced showing who is responsible, accountable, consulted and informed.
 9.3.12
Work Instructions
Each procedure needs to be broken down into the exact steps involved; these are the work
instructions. They are used in training and when producing automated workflow. They are also
important to ensure that, during design the activities and procedures are realistically described and
will work in practice. Producing work instructions is also a valuable method of uncovering specific
detailed requirements that any software tool used by the process will need to support.

9.4
Enablers Section
The enablers section diagram (Figure 21) illustrates the enablers recognised as necessary to achieve
a successful process. These particular enablers will exist within the corporate culture and strategy. A
strongly innovative company will, for example, have many enabling characteristics, including being
quick to supply the necessary resources to build new capabilities.
Figure 21 Process Diagram–Enablers Section

9.4.1
Capabilities
The main capabilities required for this process to run effectively will be in these areas:
• Business analysis
• Service management
• Development
9.4.2
Capacity
All processes consume resources according to the demand made upon them. Demand management
drives the service management process of capacity management. Demand management develops an
understanding of patterns of business activity.
It would be wise to include demand and capacity management in the planning for the design and
deployment of a process, in order to gain an understanding of what level of resources is likely to be
required (an important part of the development of the business plan for implementing a process),
including staff and technical resources.
9.4.3
Resources
For this process, staff resources will be needed from across the organisation. Dedicated resources
from IT will include business analysts, service management professionals and development
professionals. It will be necessary to have support to get time from other parts of the organisation, as
required, including customers, users, suppliers and other stakeholders.
 9.4.4
Tools
There is no need to have expensive integrated toolsets to get this process operating. However, if after
a full tool selection process has been followed, one does match all the requirements, including cost,
then it would be a sound choice.
The tools that are particularly important for this process are those that automate and relate the
following functions as part of the service knowledge management system (SKMS):
• Service portfolio (including the service catalogue)
• Service design package
• Requirements register (repository)
• Continual service improvement register (CSI register)
• Risk register
Also important are good links with the software development tool, the configuration management
system (CMS) and the service desk function – during all lifecycle phases.
9.4.5
Automation
Where possible, regular tasks should be automated to reduce errors and improve efficiency. In
particular, for the IRP, this would involve making sure that authorisations are automatic as are
escalations and the creation of an audit log of all status changes.
9.4.6
Roles
The RACI matrix for this process needs to created, showing which roles will be involved in the
process along with their specific activities and responsibilities, along with the authorities (in
particular the access rights to various stages of the requirements lifecycle).
The Cobit5 guidance includes some useful RACI matrices for the two processes that it identifies
BAI2, BAI3. These are an excellent starting point for developing the specific RACI matrix for an
organisation deploying this process.
9.4.7
Knowledge
The SKMS is a key part of a service management organisation’s operation. The CSI register and risk
register are already likely to be linked to each other within the SKMS. From the point of view of
knowledge management, the new requirements register and process inputs and outputs will have to be
linked into the SKMS. If there is not an existing SKMS, these registers will have to be developed
together.
It is likely that development will need to be included in discussions to ensure that the tools they use
can be integrated with the requirements register through the SKMS.
 9.4.8
Suppliers
All suppliers affected by this process must be considered. If most software or services are purchased
from third parties, then a period of consultation with your main suppliers will be required to ensure
that they understand the process as a whole and how they will be affected by its deployment.
This links to the ITIL Service Design process of supplier management.
9.4.9
Education & Training
Once the organisational readiness assessment is complete, training courses can be identified so that
individuals can be trained to the required skill levels in time for the deployment of the process.
Ideally, some tool could be used to perform this assessment, as it will be repeated for future services.
(There is a reference to a book in the bibliography that should help with tool selection ‘IT Tools for
the Business when the Business is IT: Selecting and Implementing Service Management Tools’.)
9.4.10
Organisational Readiness
The IRP crosses many organisational boundaries. It requires technical skills, an understanding of
requirements themselves, the solution development process, as well as service management
principles. Before deploying this as a process, it would be important to produce a report outlining the
current understanding of all these in the parts of the organisation that will be affected by the process.
The gap between the current situation and the requirements for the process to operate successfully can
be established and a funded plan developed to address the plan by building the appropriate
capabilities.

9.5
Sources of Requirements (inputs to the
process)
There are many sources of requirements. Stakeholder analysis is acknowledged as a vital part of
requirements analysis in the BABOK and it is important to identify all stakeholders.
The service management lifecycle identifies processes, functions and areas that are part of the
identification, design, transition and operation of services. These are a rich and structured source of
guidance. These sources form interfaces to the requirements analysis process and also, over time, a
reliable, tested repository of known requirements that can be re-used over many services.

9.6
Enterprise Analysis, Strategy & Governance
ITIL Service Strategy describes, in considerable detail, how to work with the business to produce a
service portfolio to satisfy the requirements of corporate governance, as well as corporate strategy.
This process of understanding is described in the BABOK as ‘Enterprise Analysis’ and is a vital
input to the whole requirements process.

9.7
Stakeholder Analysis
Service strategy produces a service portfolio that links current and future business needs, in terms of
strategic market spaces, to be addressed and the stakeholders involved with each of these. This
stakeholder analysis can either be an analysis performed for the purpose of producing an IT strategy
or can be part of a wider management of value programme that would produce a corporate investment
portfolio, with the service portfolio forming part of that (as described in the book Management of
Value).
In either case, for each new initiative–a new service, a new application as part of a service, or the
upgrade of an existing service–it is necessary to understand who the stakeholders are. It is important
to include them in the communications plan, so that the elicitation, analysis and verification of the
requirements for the initiative can be performed in terms that will satisfy the stakeholders.

9.8
Communications Plan
Each initiative will include many forms of communication, both to stakeholders to keep them
informed, and from stakeholders in the form of recommendations, the articulation of requirements,
objections, suggestions and the registering of levels of approval with proposed solutions as shown in
wireframe or other methods of mock-up, as well as with the final solution.
All of these types of communications need to be planned in the context of an overall communications
plan, managed by a project manager or administrator to ensure that all planned communications take
place.

9.9
Requirements Design & Engineering
The ITIL Service Design book describes methods of requirement engineering. Before business
analysts produced the BABOK framework, requirements were designed and engineered in many
different circumstances, well before computers were invented, and requirements were collated and
managed for physical engineering projects such as bridges or steamships.
The IRP unites the advice given on managing the design, analysis and engineering of requirements in
Cobit5, ITIL and the BABOK in order to give one single process that manages the entire lifecycle of
all requirements, not just across single projects or programmes, but across the entire enterprise or
corporation.
 9.9.1
Requirements Numbering
A numbering scheme must be developed as part of the IRP in order to ensure that requirements have a
unique ID that follows them through their lifecycle.
9.9.2
Requirements Tracking
All requirements must be tracked through the lifetime of the project. The IRP recommends that
requirements are tracked beyond that, through the life of the solution or service that satisfies the
requirements. For this reason, a requirements register is recommended that can keep all requirements,
including those that have been closed, so that they can be referred to and, possibly, re-used in future
engagements.
A mock-up of an application that would allow requirements to be entered, analysed, evaluated,
validated, authorised and then tracked through operations and continuous improvement is supplied in
Appendix A.
9.9.3
Analysing
The job of analysing requirements involves looking at the exact wording of the requirement to ensure
that it is clear to both the business and technical audiences. It also involves checking the requirement
against the relevant corporate policy and strategy to ensure that it is aligned with them and, ideally,
establishing that the requirement will, in fact, produce value for the business.
9.9.4
Validating
The validation stage of a proposed or actual solution involves checking that each of the requirements
that form the specification of the service is addressed by the solution. This is not simply testing that
the solution functions as it should, but that it does what it has been designed to do. If any requirement
is not met, it is included in the validation and evaluation report and, if significant, is raised to the risk
register.

9.10
Readiness Assessment
A readiness assessment examines the current capabilities of the organisation, in terms of the resources
needed to deploy and manage the solution, as well as the level of experience and training of both the
business and IT support staff.
From the readiness assessment, it is possible to perform a gap analysis to discover what skills,
resources and experience are required in order for the service to deliver the business value required.
A training plan and/or hiring plan can then be produced to ensure that the organisation is prepared for
the solution once it becomes operational.
 9.11
Solution Definition & Selection
Once all the requirements have been understood, organised, prioritised and
authorised, it is possible to build or purchase a solution.
Some solutions may be new business processes, new hardware or even organisational
change. Often, though, solutions will involve software development, and what
follows considers this option in more detail than non-software solutions.
If the solution is to be developed in-house, then the development team will use its preferred
methodology to produce the software solution. If the solution is to be provided by a third-party, the
requirements will form the core of the RFP with which vendors will need to comply for their
proposed solution to be considered.
The particular methods used by development are beyond the scope of this book, but may involve
waterfall, agile, and scrum, among others.
The Business Case
Business cases are prepared at several stages. Firstly, when a new solution or service is proposed to
satisfy a set of requirements, the business case provides the organisation with motivation to invest in
analysing the proposal. In terms of the service portfolio, this occurs at the ‘define’ phase of the
service lifecycle. The acceptance of the business case at this stage, allows the solution to be analysed
and, using the results of this analysis, approved (or not).
Once a proposal has been accepted, in ITIL terms, the SDP has moved to the status of
‘approved’ in the service portfolio; work is done to add detail to the business case to
justify a project to build a new service.
This enhancement of the business case includes the costs and risks involved, relative
to the business value anticipated from the solution, and is used by senior management
or the board of directors to decide whether to invest in making this service (or service
change) a strategic addition to the service portfolio. The decision to invest, along with
the budget approval, moves the service to the status ‘chartered’.
Useful templates for building a business case can be found in the PRINCE2 project management
framework documents.

9.12
Solution Evaluation Report
The solution evaluation report is the basis for the service delivery review. It is a summary of the
progress of the solution from design to operation. It contains recommendations for the review board.
 9.13
Solution Delivery Review
Reviews are designed to identify what went well that can be re-used, and what did not go well that
has lessons that can be learned to improve future deliveries. The solution delivery review
investigates the process from design to early life support; a good review will result in process,
technology and other changes and, quite likely, new requirements for future solutions and services.
 10. Tool Requirements

‘Required Thinking–As these cases show, requirements processes must change, and CIOs need to drive the charge. Fixing
your broken process probably won’t be easy or quick, so start now. ‘Today, survival depends on game changing–certainly for
IT it does,’’ P&G’s Sherman says. To change the development game, ‘IT is going to have to understand the intersections
between requirements and business processes.’ 1

V arious technical tools are required to manage the lifecycle of requirements, services and
applications. The method of tool selection is discussed in some detail in the ITIL 2011 book
Service Design and, as with any service provided to a customer, the delivery of a solution, in the
form of such a tool, should follow the same process of identifying and prioritising requirements,
before using them to define and develop, or select, an appropriate solution.
For a small organisation, shared directories, word processing and spread sheet documents may be
adequate tools for the purpose. For a very large organisation, a purpose built or software vendor-
supplied integrated tool may be more appropriate. This section briefly outlines the types of tool that
are likely to be required to achieve the objectives of the IRP.
The itSMF book IT Tools for the Business when the Business is IT: Selecting and Implementing
Service Management Tools provides comprehensive and valuable advice on selecting tools to fit
requirements.

10.1
Communications Plan Workflow
The communications plan is a workflow definition that indicates the type of communication that needs
to be developed for each audience to achieve particular objectives at specific milestones. A
workflow management tool can be an appropriate choice to facilitate this.

10.2
Risk Register
For good governance, an organisation needs to have a central, corporate risk register that contains all
risks that have been identified, the business impact that they may cause and appropriate responses to,
or mitigation of, the threat that they pose.
For a small organisation, this could be kept in a securely held, shared spreadsheet. For a large
organisation, a multi-tiered repository needs to be established so that risks can be identified and
managed within the domain in which they present a threat (IT risks, for example, in the IT part of the
risk register), with the option for risks to be reflected in, or escalated to, other domains, as necessary.
A serious IT risk, identified when gathering the requirements for a new service, may need to be linked
to the main corporate risk register so that its implications can be considered and an appropriate
response developed by the risk committee of the board of directors, rather than just by IT
management.

10.3
Requirements Register and Repository
Appendix A presents a mock-up of a possible iPad-based GUI for a requirements register. If this
were to be developed as a solution, it would need to be associated with a secure central repository
(probably mirrored to a remote location for continuity purposes) with appropriate access rights for
the various roles involved in managing requirements through their lifecycles.

10.4
Service Portfolio
The service portfolio is a repository that contains all the services of an organisation in a central
location. It has three parts;
The service pipeline listing services that are under investigation or planned for the future.
1. The service catalogue containing currently live services.
2. Retired services catalogue, containing services that are no longer being offered to new
customers.

10.5
Service Design Package (SDP)
All services are defined, in technical detail, by a living document, attached to the service portfolio,
called the service design package (SDP) that accompanies a service through its entire lifecycle.
The SDP can be as simple as a word-processing document but, since it links to many other areas, it
works better as an application-enabled object, such as a document in a document management system
(DMS), which allows for dynamic links to other documents.
The ITIL 2011 book, Service Design, provides a sample template for an SDP in Appendix A.
1. Fixing the Requirements M ess–CIO M agazine 1st Jan 2006 -Christopher Lindquist
 11. Bibliography

Brooks, Peter (2006). Metrics for IT Service Management. Van Haren Publishing.
ISBN: 10: 9077212698 ISBN: 13: 978-9077212691
Brooks, Peter (2012). Metrics for IT Service Management: Designing for ITIL. Van
Haren Publishing. ISBN: 9789087536480
Cabinet Office (Great Britain) (2010). Management of Value. TSO (The Stationery
Office). ISBN: 9780113312764
Cabinet Office (Great Britain) (2011). Managing Successful Programs. TSO (The
Stationery Office). ISBN: 9780113313273
Cabinet Office (Great Britain) (2002). Managing Successful Projects with
PRINCE2, 3rd ed. TSO (The Stationery Office). ISBN: 13: 978-0113308910
Cabinet Office (Great Britain) (2011). ITIL Continual Service Improvement. TSO
(The Cabinet Office). ISBN: 9780113313082
Cabinet Office (Great Britain) (2011). ITIL Service Design. TSO (The Stationery
Office). ISBN: 9780113313051
Cabinet Office (Great Britain) (2011). ITIL Service Operation. TSO (The Stationery
Office). ISBN: 9780113313075
Cabinet Office (Great Britain) (2011). ITIL Service Strategy. TSO (The Stationery
Office). ISBN: 9780113313044
Cabinet Office (Great Britain) (2011). ITIL Service Transition. TSO (The Stationery
Office). ISBN: 9780113313068
Cabinet Office (Great Britain) (2011). Management of Portfolios. TSO (The
Stationery Office). ISBN: 9780113312948
Cabinet Office (Great Britain) (2011). Management of Risk: Guidance for
Practitioners, 3rd ed. TSO (The Stationery Office). ISBN: 9780113312740
Falkowitz, Robert (2011). IT Tools for the Business when the Business is IT:
Selecting and Implementing Service Management Tools. TSO (The Stationery Office)
and itSMF International. ISBN 9780117069039
International Institute of Business Analysis (2009). Brennan, K. (ed.) A Guide to
the Business Analysis Body of Knowledge® (BABOK® Guide). 2nd ed. IIBA. ISBN-
10: 0981129218 ISBN-13: 978-0981129211
ISACA (2012). COBIT5: Enabling Processes. ISACA. ISBN: 9781604202397
ISACA (2012). COBIT5: Implementation. ISACA. ISBN: 9781604202380
 12. Appendix A–Requirements Register

Figure 22–Requirements Register (mock-up for iPad)

T he mock-up of a view of the requirements register is shown as an iPad application.

Figure 20 depicts one single requirement ‘Registers – Audit History’, with the requirement ID
SM-RQ-0345-20062012. This requirement has a high priority, 2; the reason for this can be seen in the
evaluation box (in red) showing that this is a high value requirement, with low cost and a high risk (in
this case a high risk of audit failure if it is not done), a high urgency and a corporate-wide impact.
The next two milestones are shown on the calendar. They are probably review meetings, but clicking
on the calendar would show the exact detail of the milestones. In the mock-up the calendar shows the
year as ‘2010’, but, of course, in the real system, this would be the current year.
The current text of the validated requirement is shown at in the green box in the middle, with the
requirement owner’s recent comments below it.
Stakeholders can review the wireframe mock-up of how the application will work by clicking on the
link at the top left.
We can see that this requirement is being used by four separate development projects – three are part
of the ITSM programme (adding an audit log to the risk register, the CSI repository and the
requirements register [this application]). The fourth is a requirement to add the same function to the
sales system. This shows part of the value of the unified register – re-use of one standard
requirement, and its solutions, in a number of different areas, without rework.
Links are shown to:
The risk register (these will link to the corporate risk register, the IT risk register, or, for minor
matters, to the project or programme risk register – clicking on the link will show which. Provision
will need to be made in these registers to move risks depending on priority or in response to
escalation requests)
• The RACI matrix for the requirement (the requirement owner is shown at the top, but all other
stakeholders, as well as detail of the planned activities will be shown in the RACI matrix – a
number of requirements are likely to share one RACI matrix)
• The SDP(s) for this requirement. In this particular case, we would expect to find this
requirement linking to the SDP for the three ITSM services, as well as to the SDP for the sales
system
• The warranty requirements – when this becomes a live part of a solution, the warranty
requirements will be part of the service level package, containing the SLAs for the service to
particular customers. At the moment, this defines the minimum service levels expected of the
solution, based on corporate criteria and particular SLRs for the four services
• The CSI register, which will contain links to proposed service improvements related to this
requirement for an audit log
• The audit log itself. Since the requirement is for an audit log, we would expect that, at the
moment, this is probably just a log file, which has been deemed not to be adequate – probably
for reasons of security as well as the difficulty of getting good metrics and CRM data from it.
On the right of the screen, links are shown to:
• CSFs and their related KPIs for this requirement
• Metrics that will be measured using the audit log
• Stakeholders for the requirement
• Authorisers of the requirement
• Related requirements – usually a group of requirements will be bundled together to form part
of a solution or solution update and this relationship will be shown here.
This organisation is using a twitter-like communication system that allows stakeholders to comment
on requirements – in this case, we can see recent tweets, linked to this requirement.
Finally, there is a list of hashtags that have been added to this requirement. It can be seen that they
allow searching for requirements that are owned by J. Smith (for which J.Smith is ‘accountable’ in
RACI terms), the elicitation event that led to the creation of this, and other, requirements, #ITSM-
Elicitation, and the fact that this is part of the overall #SKMS initiative as well. Anybody using the
application could click on one of these hashtags to get a list of requirements, and tweets, connected to
that hashtag. This allows an ad hoc grouping and search mechanism to be easily established without
changes to the structure of the register. These hashtags can be kept informal, or formalised,
periodically, so that they can be selected from a drop-down menu (thus avoiding the problem of
misspelt hashtags).
 13. Appendix B – Links to COBIT5

T he IRP is designed to allow an organisation to meet its IT governance requirements, as defined in

COBIT5. This relates to the two specific processes in the ‘build, acquire, implement’ section,
specifically, ‘BAI02’ and ‘BAI03’. The full details can be found in the COBIT5 Process Reference
Guide from ISACA on pages 129 and 133.
When designing a specific implementation of the IRP, it is important to ensure that these broad audit
objectives, in terms of goals and metrics, are satisfied.
The goals and metrics of these two processes are:

13.1
Goals & Metrics
13.1.1
BAI02
Identify solutions and analyse requirements before acquisition or creation to ensure that they are
aligned with enterprise strategic requirements covering business processes, applications, information,
data, infrastructure and services. Co-ordinate with affected stakeholders the review of feasible
options including relative costs and benefits, risk analysis, and approval of requirements and
proposed solutions.
Percentage of enterprise strategic goals and requirements supported by IT
strategic goals.
Alignment of IT and business strategy. Level of stakeholder satisfaction with scope of the planned portfolio of
programmes and services.
Percentage of IT value drivers mapped to business value drivers
Number of business disruptions due to IT service incidents
Percentage of business stakeholders satisfied that IT service delivery
Delivery of IT services in line with business requirements.
meets agreed service levels.
Percentage of users satisfied with the quality of IT service delivery.
Number of business processing incidents caused by technology
integration errors.
Number of business process changes that need to be delayed or reworked
Enablement and support of business processes by integrating because of technology integration issues
applications and technology into business processes. Number of IT-enabled business programmes delayed or incurring additional
cost due to technology integration issues.
Number of applications or critical infrastructures operating in silos and not
integrated.
Percentage of requirements reworked due to misalignment with enterprise
Business functional and technical requirements reflect enterprise needs needs and expectations
and expectations.
Level of stakeholder satisfaction with requirements.
The proposed solution satisfies business functional, technical and
Percentage of requirements satisfied by proposed solution.
compliance requirements.
Risk associated with the requirements has been addressed in the Number of incidents not identified as risks.
proposed solution. Percentage of risks unsuccessfully mitigated.
Requirements and proposed solutions meet business case objectives Percentage of business case objectives met by proposed solution.
(value expected and likely costs). Percentage of stakeholders not approving solution in relation to business
case.

13.1.2
BAI03
Establish and maintain identified solutions in line with enterprise requirements covering design,
development, and procurement/sourcing and partnering with suppliers/vendors. Manage
configuration, test preparation, testing, requirements management and maintenance of business
processes, applications, information/data, infrastructure and services.
Number of business disruptions due to IT service incidents.
Percentage of business stakeholders satisfied that IT service
Delivery of IT services in line with business requirements. delivery meets agreed service levels.
Percentage of users satisfied with the quality of IT service
delivery.
Number of reworked solution designs due to misalignment
The solution design, including relevant components, meets enterprise needs, aligns with requirements.
with standards and addresses all identified risk. Time taken to agree that design deliverable has met
requirements
The solution conforms to the design, is in accordance with organisational standards, Number of solution exceptions to design noted during stage
and has appropriate control, security and auditability. reviews.
Number of errors found during testing.
The solution is of acceptable quality and has been successfully tested.
Time and effort to complete tests.
Number of tracked approved changes that generate new
Approved changes to requirements are correctly incorporated into the solution.
errors.
Maintenance activities successfully address business and technological needs. Number of demands for maintenance that go unsatisfied.
 14. Appendix C–An Example of a Code of
Ethics

I SACA, the organisation that produces the Cobit guidance, has this as its ethical code of conduct for
members:
ISACA sets forth this Code of Professional Ethics to guide the professional andpersonal conduct of
members of the association and/or its certification olders.
Members and ISACA certification holders shall:
1. Support the implementation of, and encourage compliance with, appropriate standards and
procedures for the effective governance and management of enterprise information systems
and technology, including: audit, control, security and risk management.
2. Perform their duties with objectivity, due diligence and professional care, in accordance with
professional standards.
3. Serve in the interest of stakeholders in a lawful manner, while maintaining high standards of
conduct and character, and not discrediting the profession or the Association.
4. Maintain the privacy and confidentiality of information obtained in the course of their
activities unless disclosure is required by legal authority. Such information shall not be used
for personal benefit or released to inappropriate parties.
5. Maintain competency in their respective fields and agree to undertake only those activities
they can reasonably expect to complete with the necessary skills, knowledge and competence.
6. Inform appropriate parties of the results of work performed; revealing all significant facts
known to them.
7. Support the professional education of stakeholders in enhancing their understanding of the
governance and management of enterprise information systems and technology, including:
audit, control, security and risk management.
Failure to comply with this Code of Professional Ethics can result in an investigation into a member’s
or certification holder’s conduct and, ultimately, in disciplinary measures.
 15. Appendix D–Mapping BABOK to ITIL
& IRP

T he existing advice in both the BABOK and ITIL 2011 books is valuable, and valid; however, it
can be extended. So the chapter headings are useful to give numbered references to the activities
already documented in the BABOK. The ITIL references are to the lifecycle books – SS – Service
Strategy, SD – Service Design, ST – Service Transition, SO – Service Operation, CSI – Continual
Service Improvement.
Ref Activity Map to ITIL Map to IRP
2 Chapter 2: Business Analysis Planning & Monitoring
2.1 Plan Analysis Approach SS 2. Service Strategy
2.2 Conduct Stakeholder Analysis SS 3. Stakeholder Analysis
2.3 Plan Business Analysis Activities SD 9. Organised
2.4 Plan Business Analysis Communication SD 7. Confirmed
2.5 Plan Requirements Management SD 9. Organised
2.6 Manage Business Analysis Performance SD IRP Metrics
3 Chapter 3–Elicitation
3.1 Prepare for Elicitation SD 4. Elicitation
3.2 Conduct Elicitation Activity SD 4. Elicitation
3.3 Document Elicitation Results SD 4. Elicitation
3.4 Confirm Elicitation Results SD 7. Confirmed
4 Chapter 4 RM & Communication
4.1 Manage Solution Scope & Requirements SD 17. Solution Design
4.2 Manage Requirements Traceability ST 9. Organised
4.3 Maintain Requirements for Re-use ST 9. Organised
4.4 Prepare Requirements Package SD 10. Linked to SDP
4.5 Communicate Requirements SD 7. Confirmed
5 Chapter 5–Enterprise Analysis
5.1 Define Business Need SS 2. Service Strategy
5.2 Assess Capability Gaps SS 2. Service Strategy
5.3 Determine Solution Approach SD 17. Solution Design
5.4 Define Solution Scope SD 16. Chartered
5.5 Define Business Case SS 15. Validated
6 Chapter 6: Requirements Analysis
6.1 Prioritize Requirements SD 8. Prioritised
6.2 Organize Requirements SD 9. Organised
10. Formal Specification
6.3 Specify and Model Requirements SD
11. Model
6.4 Define Assumptions and Constraints SD 13. Assumptions & Constraints
6.5 Verify Requirements SD 14. Verified
6.6 Validate Requirements SD 15. Validated
7 Chapter 7–Solution Assessment and Validation
7.1 Assess Proposed Solution SD 18. Solution Approved
7.2 Allocate Requirements SD 9. Organised
7.3 Assess Organisational Readiness ST 17. Solution Design
7.4 Define Transition Requirements ST 17. Solution Design
7.5 Validate Solution ST 15. Validated
7.6 Evaluate Solution Performance ST (Change Evaluation) 19. Service Transition
8 Chapter 8–Underlying Competencies
8.1 Analytical Thinking and Problem Solving SS 19. Service Transition
8.2 Behavioural Characteristics SS 19. Service Transition
8.3 Business Knowledge SS 19. Service Transition
8.4 Communication Skills SS 19. Service Transition
8.5 Interaction Skills SS 19. Service Transition
8.6 Software Applications SS 19. Service Transition
 16. Glossary

acceptance A collection of requirements (each acceptance criterion is a requirement, often one of warranty), often in the form of a checklist, that
criteria define what shall be demonstrated to be part of a solution before it can formally be accepted.
Part of a RACI (Responsible, Accountable, Consulted, Informed) matrix definition. It means the person or function that will be
accountable accorded credit for success or blame for failure for the activity. This is a management accountability and does not necessarily involve
actually doing the work.
The top level description of things that are to be done in a process. An activity is described by one or more procedures and the
activities
procedure detail is contained in the work instructions.
A way of approaching development or project work with flexibility, designed to avoid the perception of bureaucracy seen in the
agile
conventional waterfall method.
approval The stage in the requirements lifecycle that indicates the official management sanction for a service.
(ITIL Service Design) The structure of a system or IT service, including the relationships of components to each other and to the
architecture
environment they are in. Architecture also includes the standards and guidelines that guide the design and evolution of the system.
Inspection and analysis to check whether a standard or set of guidelines is being followed, that records are accurate, or that
assessment
efficiency and effectiveness targets are being met. See also audit.
(ITIL Service Strategy) Any resource or capability. The assets of a service provider include anything that could contribute to the
asset delivery of a service. Assets can be one of the following types: management, organization, process, knowledge, people, information,
applications, infrastructure or financial capital. See also customer asset; service asset; strategic asset.
The explicit statement of beliefs or understandings that, if not stated directly, can be dangerous because they may not be warranted
assumptions
beliefs or shared understandings.
A central repository of events that are relevant to good governance. Such a repository is available to authorised audit staff to
audit log investigate to ensure proper policy and procedure is being followed. Audit logs need to be write-only and effectively secured against
unauthorised modification by anybody
The transaction records, kept in an audit log, that enables the component parts of a transaction, or series of transactions, to be
audit trail
followed by an auditor.
authorise To provide official, documented, sanction for a particular individual or team to have access to resources and to take specific action.
(ITIL Service Design) Ability of an IT service or other configuration item to perform its agreed function when required. Availability is
determined by reliability, maintainability, serviceability, performance and security. Availability is usually calculated as a percentage.
availability
This calculation is often based on agreed service time and downtime. It is best practice to calculate availability of an IT service using
measurements of the business output.
The Business Analyst Body of Knowledge, a book produced by the IIBA (International Institute of Business Analysis) to describe
BABOK
the activities involved in the job of Business Analysis.
Those things that accrue, or are intended to accrue in a way that delivers value to an organisation as a result of a proposed course of
benefits
action, service, tool or process being deployed.
Generally, in a commercial company, the Board of Directors of the company. This is the most senior decision making body in a
board company and is accountable for setting the policy and strategy that will govern the companies activities. In a non-commercial
company, this might be the trustees, the senate or other body that has a similar accountability for this.
BRM business relationship manager
A list of all the money an organization or business unit plans to receive, and plans to pay out, over a specified period of time. See also
budget
budgeting; planning.
(ITIL Service Transition) The activity of assembling a number of configuration items to create part of an IT service. The term is also
build used to refer to a release that is authorized for distribution ‰ÛÒ for example, server build or laptop build. See also configuration
baseline.
The activity involved in understanding the requirements of a business, documenting them in a formal fashion and working with
business
business stakeholders to enable the development of applications or the deployment of services or other means to enable a solution
analysis
to the equirements to be provided according to business priorities far required value, cost and time of delivery and risk.
(ITIL Service Strategy) Justification for a significant item of expenditure. The business case includes information about costs,
business case
benefits, options, issues, risks and possible problems. See also cost benefit analysis.
business goals The official, documented aims of the business. Those things that the business has documented its intention to achieve if possible.
business
governance The direction and control of the business
business need A requirement of the business that is essential to its future effectiveness. Not a ‘want’ or a ‘nice to have’.
business
Processes that run in the business domain, such as invoicing, manufacturing, sales, marketing and so forth.
processes
business (ITIL Service Strategy) The process responsible for maintaining a positive relationship with customers. Business relationship
relationship management identifies customer needs and ensures that the service provider is able to meet these needs with an appropriate
management catalogue of services. This process has strong links with service level management.
business Requirements for the efficient and effective operation of the business. A business requirement that is a matter of efficiency may not
requirements be an essential need, but would still remain a ‘business requirement’
A risk, in this sense, is something unexpected that could occur that would influence the business policy, strategy, tactics or
business risk
operation. A risk need not be a negative thing, but is something that should be taken account of for good governance.
Value has to be defined for each business in terms of its policy, strategy and operating model. Something delivers value to the
business value business if it enables, maintains or enhances the business’ position financially, or in terms of market share, share price, reputation or
any other relevant measure of a business benefit.
Bring Your Own Device the trend for employees to wish to use their own equipment, such as tablets or mobile ‘phones, for business
BYOD
activities.
The organisation that, at the time of writing, owns the copyright of the best practice suite of publications, including ITIL, M_o_R,
Cabinet Office
MoV
(ITIL Service Strategy) The ability of an organization, person, process, application, IT service or other configuration item to carry out
capability
an activity. Capabilities are intangible assets of an organization. See also resource.
(ITIL Service Design) The maximum throughput that a configuration item or IT service can deliver. For some types of CI, capacity may
capacity
be the size or volume ‰ÛÒ for example, a disk drive.
A central repository, usually part of the SKMS (Service Knowledge Management System) that enables controlled access to
catalogue
information about business assets such as services, components, requirements.
A named group of things that have something in common. Categories are used to group similar things together. For example, cost
category types are used to group similar types of cost. Incident categories are used to group similar types of incident, while CI types are used
to group similar types of configuration item.
Issuing a certificate to confirm compliance to a standard. Certification includes a formal audit by an independent and accredited body.
certification
The term is also used to mean awarding a certificate to provide evidence that a person has achieved a qualification.
change (ITIL Service Transition) The process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be made
management with minimum disruption to IT services.
chartered The status of a service when the board has authorised a budget, and starting date, for its implementation.
CMMI Capability Maturity Model Integration
(ITIL Continual Service Improvement) Control OBjectives for Information and related Technology (COBIT) provides guidance and
COBIT best practice for the management of IT processes. COBIT is published by ISACA in conjunction with the IT Governance Institute
(ITGI). See www.isaca.org for more information.
COBIT Control OBjectives for Information and related Technology
communications A plan forming part of a programme, project or other engagement that details what should be communicated to whom in which format
plan to achieve identified results.
compliance Ensuring that a standard or set of guidelines is followed, or that proper, consistent accounting or other practices are being employed.
Limits to a possible solution space. Price, for example, limits solutions to those that are affordable because they are below a defined
constraints
corporate maximum. There can be many sorts of constraints, including legal, ethical, physical and technology options.
continual
service One of the core ITIL books
improvement
The provision for a service or process in the event of a major event that enables it to continue at a level agreed by the business in the
continuity
continuity plan.
A means of managing a risk, ensuring that a business objective is achieved or that a process is followed. Examples of control include
control policies, procedures, roles, RAID, door locks etc. A control is sometimes called a countermeasure or safeguard. Control also means to
manage the utilization or behaviour of a configuration item, system or IT service.
The portion of the definition of a process that defines how the process will be subject to management control and thus can be
control section
audited as complying with company policy and good governance.
corporate risk The business risk, managed by the Board of Directors and usually documented in the Corporate Risk Register
The amount of money spent on a specific activity, IT service or business unit. Costs consist of real cost (money), notional cost (such
cost as people‰Ûªs time) and depreciation.
 The plural of ‘Criterion’, a list of tests that must be applied before something is judged acceptable. For example, a set of ‘acceptance
criteria
criteria’ for a new service will list, often as a checklist, what has to be in place before a service can be accepted
Abbreviated to CSF. These are factors determined by the business for a service, project or programme that are essential for business
critical success
success. If a CSF is not achieved, the business will fail. These are usually difficult to measure directly, so a number of Key
factors
Performance Indicators (KPIs) are developed as proxies for the measure itself.
CSF critical success factor
(ITIL Continual Service Improvement) A database or structured document used to record and manage improvement opportunities
CSI register
throughout their lifecycle.
Someone who buys goods or services. The customer of an IT service provider is the person or group who defines and agrees the
customer service level targets. The term is also sometimes used informally to mean user , for example, ‘This is a customer-focused
organization.’
(ITIL Service Design) (ITIL Service Strategy) The process responsible for understanding, anticipating and influencing customer
demand for services. Demand management works with capacity management to ensure that the service provider has sufficient
demand
capacity to meet the required demand. At a strategic level, demand management can involve analysis of patterns of business activity
management
and user profiles, while at a tactical level, it can involve the use of differential charging to encourage customers to use IT services at
less busy times, or require short- term activities to respond to unexpected demand or the failure of a configuration item.
(ITIL Service Design) An activity or process that identifies requirements and then defines a solution that is able to meet these
design
requirements. See also service design.
(ITIL Service Design) The process responsible for creating or modifying an IT service or application ready for subsequent release
development and deployment. Development is also used to mean the role or function that carries out development work. This process is not
described in detail within the core ITIL publications.
early life This is a process defined by ITIL in the Service Transition book. It ensures that a new service does not become operational until all
support the operational acceptance criteria have been signed off by having the first phase of the service operated by the transition team.
effective Something achieves its goals–measured by metrics that look at output
Something achieves its goals with an optimal energy, effort and cost–measured by metrics that look at the processes used to achieve
efficient
output
This is the general term used for finding out what requirements there are. It can involve the use of many techniques, from surveys to
elicitation one-to-one interviews along with many different workshop techniques. The aim is to uncover the genuine needs (requirements) of
the organisation and distinguish these from things that are simply ‘nice to have’ or ‘wants’, rather than ‘needs’.
This is the first stage of Business Analysis identified by the BABOK, it is similar to the Service Strategy stage of ITIL and involves
enterprise
understanding, in a holistic sense, the vision, goals and objectives of the organisation at a particular time. The ITIL Continual Service
analysis
Improvement seven step process starts with doing a brief enterprise analysis.
A methodical description of how a business operates as an organisation, including the business processes, services and everything
enterprise that supports them. ITIL Service Design recommends using TOGAF (The Open Group Architecture Framework) to build an enterprise
architecture architecture–in turn, TOGAF recommends something like the IRP (Integrated Requirements Process) with a requirements register to
be at the heart of the enterprise architecture.
“(ITIL Service Operation) A design flaw or malfunction that causes a failure of one or more IT services or other configuration items. A
error
mistake made by a person or a faulty process that impacts a configuration item is also an error.
Evaluation is distinguished from testing because, rather than simply checking that a solution works, it checks that the solution
actually matches the original requirements. ITIL Service Transition includes a process called ‘Change Evaluation’ that allows a longer-
evaluation
term higher-level strategic view of a change to be taken to make sure that it makes good business sense. BABOK sees evaluation as
including an element of continuous improvement.
Like ‘agile’, ‘extreme’ is a term used to refer to different project or development methods than the traditional waterfall method. These
extreme involve the idea of rapid prototyping and dynamic development based on the discovery of requirements during design and
development, rather than before.
The underlying structor supporting an activity. ITIL is, for example, a framework that helps support a company wishing to develop an
IT Service Management competency. It is distinguished from a ‘standard’ by not having a set of auditable requirements that can be
framework
used to determine if it has been implemented or not. A framework is much looser than a standard and aims to give generally useful
guidance.
“A team or group of people and the tools or other resources they use to carry out one or more processes or activities – for example,
the service desk. The term also has two other meanings:
function - An intended purpose of a configuration item, person, team, process or IT service. For example, one function of an email service
may be to store and forward outgoing mails, while the function of a business process may be to despatch goods to customers.
- To perform the intended purpose correctly, as in “”The computer is functioning.”””
Ensures that policies and strategy are actually implemented, and that required processes are correctly followed. Governance includes
governance
defining roles and responsibilities, measuring and reporting, and taking actions to resolve any issues identified.
A hashtag is a means of marking a category of something. It’s known as a ‘hashtag’ because it is usually preceeded by the hash
hashtags character ‘#’. These are used by twitter to organise messages, but can be generally used where a means of identifying a message is
 required that is very flexible and easily changed.

ID The identification of an asset–its name.

(ITIL Service Operation) (ITIL Service Transition) A measure of the effect of an incident, problem or change on business processes.
impact
Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.
(ITIL Service Operation) An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a
incident
configuration item that has not yet affected service is also an incident ‰ÛÒ for example, failure of one disk from a mirror set.
IRP The integrated requirements process–the subject of this book
IRP Process
The manager(s) responsible for ensuring that the IRP is deployed and managed from day to day according to business requirements
manager
IRP process
The person accountable for ensuring that the IRP operates and is measured according to its design requirements
owner
The centralised repository that contains all corporate requirements, treated as assets, and links to the workflow tool(s) that enable the
IRP register
process to be operated and measured.
As an independent, nonprofit, global association, ISACA engages in the development, adoption and use of globally accepted,
ISACA industry-leading knowledge and practices for information systems and is responsible for the development of the IT audit guidance
described in Cobit.
A set of best-practice publications for IT service management. Owned by the Cabinet Office (part of HM Government), ITIL gives
guidance on the provision of quality IT services and the processes, functions and other capabilities needed to support them. The
ITIL framework is based on a service lifecycle and consists of five lifecycle stages (service strategy, service design, service transition,
ITIL
service operation and continual service improvement), each of which has its own supporting publication. There is also a set of
complementary ITIL publications providing guidance specific to industry sectors, organization types, operating models and
technology architectures. See www.itil-officialsite. com for more information.
ITSM IT service management
The Kano model, named after its inventor, Professor Noriaki Kano, is a method for aligning customer satisfaction with product
Kano
development.
(ITIL Continual Service Improvement) (ITIL Service Design) A metric that is used to help manage an IT service, process, plan, project
key or other activity. Key performance indicators are used to measure the achievement of critical success factors. Many metrics may be
performance measured, but only the most important of these are defined as key performance indicators and used to actively manage and report on
indicator (KPI) the process, IT service or activity. They should be selected to ensure that efficiency, effectiveness and cost effectiveness are all
managed.
(ITIL Service Transition) The process responsible for sharing perspectives, ideas, experience and information, and for ensuring that
knowledge these are available in the right place and at the right time. The knowledge management process enables informed decisions, and
management improves efficiency by reducing the need to rediscover knowledge. See also Data-to-Information-to-Knowledge- to-Wisdom; service
knowledge management system.
KPI key performance indicator
requirements that arrive after the business case has been accepted. These requirements do not form part of the business case, so
late
must be carefully documented and approved only as extensions to the business case once the value they bring has been understood
requirements
and the cost and risk of including them has been documented with mitigation to these risks agreed.
These are service requirements as identified by different stages of the ITIL lifecycle. For example, Transition Requirements are those
lifecycle
requirements that concern processes in the ITIL Service Transition book, such as change, release, knowledge, change evaluation and
requirement
so forth.
logged
management These are requirements that reflect management needs, either at an organisation level, or those needed to manage a particular service
requirements or application.
The framework of policy, processes, functions, standards, guidelines and tools that ensures an organization or part of an organization
management
can achieve its objectives. This term is also used with a smaller scope to support a specific process or activity: for example, an event
system
management system or risk management system. See also system.
(ITIL Continual Service Improvement) Something that is measured and reported to help manage a process, IT service or activity. See
metric
also key performance indicator.
This is one way of communicating requirements back to stakeholders–the mock-up is a type of model that shows how a service could
mock-up appear when released. It helps stakeholders visualise how the service or applicaiton will work so they can make suggestions for
improvements. It also allows the developers to understand more clearly how stakeholders are understanding the requirements.
model A representation of a system, process, IT service, configuration item etc. that is used to help understand or predict future behaviour.
(ITIL Service Operation) Repeated observation of a configuration item, IT service or process to detect events and to ensure that the
monitoring
current status is known.
organisation
requirements These are requirements that are specific to a particular organisation, or type of organisation.

(ITIL Service Transition) A limited deployment of an IT service, a release or a process to the live environment. A pilot is used to
pilot
reduce risk and to gain user feedback and acceptance. See also change evaluation; test.
A detailed proposal that describes the activities and resources needed to achieve an objective ‰ÛÒ for example, a plan to implement
plan
a new IT service or process. ISO/IEC 20000 requires a plan for the management of each IT service management process.
PMBOK Project Management Body of Knowledge
Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent and
policy
appropriate development and implementation of processes, standards, roles, activities, IT infrastructure etc.
policy and Strategy is the long term plan the organisation has to achieve its goals, the policy of the organisation is the means by which it will
strategy achieve this strategy.
policy
Requirements that stem directly from corporate, or enterprise, or IT, policy–required for good governance
requirements
A centralised, formal collection of items to be managed together. A portfolio is an investment decision instrument that allows different
portfolio things to be compared in terms of their cost, return, urgency and impact in order to make investment decisions objective and
transparent. Examples are: Investment Portfolio, Project Portfolio, Service Portfolio, Application Portfolio
(ITIL Service Operation) (ITIL Service Transition) A category used to identify the relative importance of an incident, problem or
priority change. Priority is based on impact and urgency, and is used to identify required times for actions to be taken. For example, the
service level agreement may state that Priority 2 incidents must be resolved within 12 hours.
(ITIL Service Operation) A cause of one or more incidents. The cause is not usually known at the time a problem record is created,
problem
and the problem management process is responsible for further investigation.
A formal summary of the business ‘problem’ that a business case is intended to solve. This use of ‘problem’ is different from the ITIL
problem
usage and does not mean an error, or something that has gone wrong. Rather, it means strategic business issue or top level
statements
requirement that requires a solution to deliver value to the business.
A document containing steps that specify how to achieve an activity. Procedures are defined as part of processes. See also work
procedure
instruction.
A structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them
process into defined outputs. It may include any of the roles, responsibilities, tools and management controls required to reliably deliver the
outputs. A process may define policies, standards, guidelines, activities and work instructions if they are needed.
A role responsible for the operational management of a process. The process manager’s responsibilities include planning and
process coordination of all activities required to carry out, monitor and report on the process. There may be several process managers for one
managere process. For example, regional change managers or IT service continuity managers for each data centre. The process manager role is
often assigned to the person who carries out the process owner role, but the two roles may be separate in larger organizations.
The person who is held accountable for ensuring that a process is fit for purpose. The process owner’ responsibilities include
process owner sponsorship, design, change management and continual improvement of the process and its metrics. This role can be assigned to the
same person who carries out the process manager role, but the two roles may be separate in larger organizations.
process
requirements
A number of projects and activities that are planned and managed together to achieve an overall set of related objectives and other
programme
outcomes.
A temporary organization, with people and other assets, that is required to achieve an objective or other outcome. Each project has a
lifecycle that typically includes initiation, planning, execution, and closure. Projects are usually managed using a formal methodology
project
such as PRojects IN Controlled Environments (PRINCE2) or the Project Management Body of Knowledge (PMBOK). See also
charter; project management office; project portfolio.
The formal management of an identified project. Project management uses a number of frameworks, well known are PRINCE2 and
project PMBOK. The Project Manager is accountable for managing the life of a project from the sign-off of the Business Case until the final
management acceptance sign-off by the customer. The responsibility of the Project Manager is to ensure that the project is completed within time
and budget to deliver the requirements as defined and agreed.
A working model of a solution produced to give an impression of how the service will appear when it has been developed fully. It is
prototype intended to help stakeholders, particularly customers and users, to spot potential design errors or to identify new, or previously
unsatisfied, requirements.
published
The ability of a product, service or process to provide the intended value. For example, a hardware component can be considered to
quality be of high quality if it performs as expected and delivers the required reliability. Process quality also requires an ability to monitor
effectiveness and efficiency, and to improve them if necessary. See also quality management system.
A responsibility matrix used for identifying the owners of activities. The acronym stands for ‘Responsible’, ‘Accountable’,
RACI matrix
‘Consulted’ and ‘Informed’
recovery (ITIL Service Design) (ITIL Service Operation) Returning a configuration item or an IT service to a working state. Recovery of an IT
service often includes recovering data to a known consistent state. After recovery, further steps may be needed before the IT service
can be made available to the users (restoration).
register A centralised repository with a formal, auditable, process for managing the lifecycle, access and security of the contents.
A generic term for an information store. A repository might be a database, a document management system, a file system or some
repository other electronic means of keeping together similar information. The word is usually used to avoid commitment to a particular
technological implementation.
(ITIL Service Design) A formal statement of what is needed – for example, a service level requirement, a project requirement or the
requirement
required deliverables for a process.
requirements The work done to refine requirements after the initial elicitation that involves removing or merging duplicates, splitting complex
analysis requirements into simple ones and ensuring that they are stated clearly, unambiguously and consistently.
requirements The stage of the integrated requirements process when stakeholders are asked, using various techniques, to assist by giving their
elicitation view of what requirements they will have for a proposed service, system, application, process or other solution.
requirements A term given to the requirements process emphasising the need for rigour and an engineering-type approach to gathering and
engineering managing requirements.
requirements The stages that a requirement goes through from when it is first identified until it is finally embodied in a solution or ceases to
lifecycle become required by an organisation.
requirements
The formal process governing the activities, controls and measures required to manage requirements
process
requirements A central repository of all requirements of an organisation, treated as organisational assets, so that they are controlled, secure,
register auditable and available to those that need them.
resources Raw materials required to support a process or service–this can include money, hardware, software and people.
The formal decision that a person or function will carry out a particular activity and be answerable for their work in the activity.
responsibility Contrasted to ‘accountability’ that involves the party being answerable to ‘give account’ for the reasons for success or failure of an
activity, but not necessarily involved in doing the work required.
The final stage of a service before it is decommissioned. A retired service may still be used by one or more customers, but new
retired
customers or users are not encouraged as the service will shortly be decommissioned and replaced.
An economic aim of Service Management and the Integrated Requirements Process is to provide good governance of corporate
reuse
assets by, wherever pragmatically possible, re-using these assets or components of them.
An evaluation of a change, problem, process, project etc. Reviews are typically carried out at predefined points in the lifecycle, and
review especially after closure. The purpose of a review is to ensure that all deliverables have been provided, and to identify opportunities
for improvement. See also change evaluation; post-implementation review.
RFC request for change
A possible event that could cause harm or loss, or affect the ability to achieve objectives. A risk is measured by the probability of a
risk threat, the vulnerability of the asset to that threat, and the impact it would have if it occurred. Risk can also be defined as uncertainty
of outcome, and can be used in the context of measuring the probability of positive outcomes as well as negative outcomes.
risk register The centralised register of all recognised corporate risks along with agreed mitigation.
A set of responsibilities, activities and authorities assigned to a person or team. A role is defined in a process or function. One person
role or team may have multiple roles ‰ÛÒ for example, the roles of configuration manager and change manager may be carried out by a
single person. Role is also used to describe the purpose of something or what it is used for.
The boundary or extent to which a process, procedure, certification, contract etc. applies. For example, the scope of change
scope management may include all live IT services and related configuration items; the scope of an ISO/IEC 20000 certificate may include all
IT services delivered out of a named data centre.
SDP service design package
security See information security management.
A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs
service and risks. The term ‰Û÷service‰Ûª is sometimes used as a synonym for core service, IT service or service package. See also
utility; warranty.
(ITIL Service Design) A stage in the lifecycle of a service. Service design includes the design of the services, governing practices,
processes and policies required to realize the service provider’s strategy and to facilitate the introduction of services into supported
environments. Service design includes the following processes: design coordination, service catalogue management, service level
service design
management, availability management, capacity management, IT service continuity management, information security management,
and supplier management. Although these processes are associated with service design, most processes have activities that take
place across multiple stages of the service lifecycle. See also design.
The set of documents that accompanies a service from its becoming ‘Chargered’ until it is decommissioned that describes all design
service design aspects of the service. The SDP is attached to the Service Portfolio and links to the service itself, whilst also linking to those
package
 requirements it satisfies.
Measured and reported achievement against one or more service level targets. The term is sometimes used informally to mean service
service level
level target.
An approach to IT service management that emphasizes the importance of coordination and control across the various functions,
service lifecycle processes and systems necessary to manage the full lifecycle of IT services. The service lifecycle approach considers the strategy,
design, transition, operation and continual improvement of IT services. Also known as service management lifecycle.
service
A set of specialized organizational capabilities for providing value to customers in the form of services.
management
service
management See service lifecycle.
lifecycle
(ITIL Service Operation) A stage in the lifecycle of a service. Service operation coordinates and carries out the activities and
processes required to deliver and manage services at agreed levels to business users and customers. Service operation also manages
the technology that is used to deliver and support services. Service operation includes the following processes: event management,
service
incident management, request fulfilment, problem management, and access management. Service operation also includes the
operation
following functions: service desk, technical management, IT operations management, and application management. Although these
processes and functions are associated with service operation, most processes and functions have activities that take place across
multiple stages of the service lifecycle. See also operation.
(ITIL Service Strategy) A role responsible for managing one or more services throughout their entire lifecycle. Service owners are
service owner instrumental in the development of service strategy and are responsible for the content of the service portfolio. See also business
relationship management.
(ITIL Service Strategy) The complete set of services that is managed by a service provider. The service portfolio is used to manage
service portfolio the entire lifecycle of all services, and includes three categories: service pipeline (proposed or in development), service catalogue
(live or available for deployment), and retired services. See also customer agreement portfolio; service portfolio management.
service request A standard change that is provided to users by the Service Desk under the service request process.
(ITIL Service Strategy) A stage in the lifecycle of a service. Service strategy defines the perspective, position, plans and patterns that
a service provider needs to execute to meet an organization‰Ûªs business outcomes. Service strategy includes the following
service strategy processes: strategy management for IT services, service portfolio management, financial management for IT services, demand
management, and business relationship management. Although these processes are associated with service strategy, most processes
have activities that take place across multiple stages of the service lifecycle.
(ITIL Service Transition) A stage in the lifecycle of a service. Service transition ensures that new, modified or retired services meet the
expectations of the business as documented in the service strategy and service design stages of the lifecycle. Service transition
service includes the following processes: transition planning and support, change management, service asset and configuration
transition management, release and deployment management, service validation and testing, change evaluation, and knowledge management.
Although these processes are associated with service transition, most processes have activities that take place across multiple
stages of the service lifecycle. See also transition.
SKMS service knowledge management system
Service Orientated Architecture is an architectural approach that enables the loose integration of many different data sources into
SOA
coherent service views.
software
The term given to software development when approached as a computer aided software engineering (CASE) project
engineering
solution design The use of design techniques to develop an optimal solution from a set of requirements
How a solution is obtained–it can be ‘sourced internally’, meaning it is developed internally, or ‘sourced’ externally meaning it is
sourced
open source or provided by a software vendor
A formal definition of requirements. A specification may be used to define technical or operational requirements, and may be internal
specification or external. Many public standards consist of a code of practice and a specification. The specification defines the standard against
which an organization can be audited.
A person who has an interest in an organization, project, IT service etc. Stakeholders may be interested in the activities, targets,
stakeholder
resources or deliverables. Stakeholders may include customers, partners, employees, shareholders, owners etc. See also RACI.
The second stage of business analysis (after Enterprise Analysis) in the conventional view, where the stakeholders for a particular
stakeholder
product, application or service are identified and their role in the provision of requirements defined. This is similar to the work carried
analysis
out in ITIL Service Strategy.
The name of a required field in many types of record. It shows the current stage in the lifecycle of the associated configuration item,
status
incident, problem etc.
(ITIL Service Strategy) The highest of three levels of planning and delivery (strategic, tactical, operational). Strategic activities
strategic
include objective setting and long-term planning to achieve the overall vision.
strategy (ITIL Service Strategy) A strategic plan designed to achieve defined objectives.
SWEBOK The Guide to the Software Engineering Body of Knowledge–guidance produced by the IEEE Computer Society
“A number of related things that work together to achieve an overall objective. For example:
A computer system including hardware, software and applications
system A management system, including the framework of policy, processes, functions, standards, guidelines and tools that are planned
and managed together – for example, a quality management system
A database management system or operating system that includes many software modules which are designed to perform a set of
related functions. “
TOGAF The Open Group Architecture Framework
Every process has a trigger. This is the special input, or inputs, required to set off (trigger) the process. For example, an invoicing
trigger
process would need a purchase order to trigger it.
TSO The Stationary Office–the publisher of the ITIL and other best practice books in the UK
(ITIL Service Design) (ITIL Service Transition) A measure of how long it will be until an incident, problem or change has a significant
urgency impact on the business. For example, a high-impact incident may have low urgency if the impact will not affect the business until the
end of the financial year. Impact and urgency are used to assign priority.
A way of modelling a set of requirements as an interim, prototype of a solution. It consists of a set of interacting activities and actors.
Often represented graphically as a use-case diagram. These diagrams can be informal or, if represented by UML (Universal Modelling
Language) or BPML 2.0 (Business Process Modelling Language) as formal representations or models of what a solution is going to
use-case
look like. Use-cases are used by business analysists and service designers as a means of bridging the communications gap between
developers on the one hand, with requirements for precise definitions that can be coded into applications and, on the other,
customers and users who need to understand how the solution will work.
A user story is a description of how a process or service works from the perspective of a user. It is a powerful way of understanding
user story
the workflow and identifying missing components in an application or service.
The stakeholders who will be using a service operationally, day to day. As opposed to the business customers who pay for and
users
determine the sort of service that is required.
(ITIL Service Strategy) The functionality offered by a product or service to meet a particular need. Utility can be summarized as
‰Û÷what the service does‰Ûª, and can be used to determine whether a service is able to meet its required outcomes, or is ‰Û÷fit
utility
for purpose‰Ûª. The business value of an IT service is created by the combination of utility and warranty. See also service
validation and testing.
(ITIL Service Transition) An activity that ensures a new or changed IT service, process, plan or other deliverable meets the needs of
validation the business. Validation ensures that business requirements are met even though these may have changed since the original design.
See also acceptance; qualification; service validation and testing; verification.
verified The stage of testing where the solution is checked against the original requirements to ensure that it satisfies them.
(ITIL Service Strategy) Assurance that a product or service will meet agreed requirements. This may be a formal agreement such as a
service level agreement or contract, or it may be a marketing message or brand image. Warranty refers to the ability of a service to be
available when needed, to provide the required capacity, and to provide the required reliability in terms of continuity and security.
warranty
Warranty can be summarized as ‰Û÷how the service is delivered‰Ûª, and can be used to determine whether a service is ‰Û÷fit for
use‰Ûª. The business value of an IT service is created by the combination of utility and warranty. See also service validation and
testing.
The term used to describe the conventional software development cycle, because the stages are often drawn in a set of connected
waterfall
boxes remeniscent of a cascade or set of rapids
A non-working prototype of a solution that looks like the screens of an application and is used to check that stakeholders are
wireframe
satisfied with how the solution will look in practice.
A document containing detailed instructions that specify exactly what steps to follow to carry out an activity. A work instruction
work instruction
contains much more detail than a procedure and is only created if very detailed instructions are needed.
work The most detailed level of documentation for a process. Typically work instructions are used to train new users, and contain the
instructions detail of how the application is used, down to the use of fields on a screen..
The flow of work through a process. This usually refers to a repeatable process flow where the flow is aided by software (workflow
software) this can be as simple as using e-mail authorisation for important stages of a process to an application that handles all of the
workflow
data of a process and provides integrated facilities to allocate, authorise and measure work as it is performed by different people in an
organisation.

Contents
Preface
Acknowledgements
Audience
Introduction
Perspectives–Frameworks & Requirements
Business Analysis: BABOK
IT Governance and audit: Cobit5 (Requirements Process Audit)
IT Service Management–ITIL (Service Design)
Software Engineering
Project Management
Enterprise Architecture
Requirements Register
Requirements for this book
Problem Statements
Requirements
Benefits
Final and Intermediate Outcomes
Requirements Management as a Process
Process Overview
Scalability
Sub-processes as perspectives
Integrated Requirements Process Flow
Top Level Process Diagram
Role: IRP Owner
Role: IRP Manager
Missing Role: Project Manager
Critical Success Factors (CSFs), Key Performance Indicators (KPIs and Metrics)
Responsible, Accountable, Consulted, Informed (RACI) – Top Level
Example of initial ‘raw’ requirement
IRP Sub-Process 1: Requirements Analysis
IRP Sub-Process 2: Requirements Elicitation
IRP Sub-Process 3: Requirements Organised
IRP Sub-Process 4: Strategy Approved – Service Chartered
IRP Sub-Process 5: Solution Designed
IRP Sub-Process 6: Service Transitioned
IRP Sub-Process 7: Service Sourced
IRP Sub-Process 8: Service Operated
IRP Sub-Process 9: Continual Service Improvement
IRP Sub-Process 10: Change Approval
Requirements Lifecycle
Need Identified
Service Strategy
Stakeholder Analysis
Elicitation
Logged: Requirement / Late Requirement
Categorised
Confirmed
Prioritised
Organised
Linked to Service Design Package (SDP)
Formal specification
Model
Assumptions & Constraints
Verified
Not Appropriate
Validated
Chartered
Solution Design
Solution Approved
 Service Transition
Service Operation
Continual Service Improvement (CSI)
Service Improved
On-going CSI Requirement
Requirement Delivered
Governance Structure
Process Diagram Overview
Control Section
Action Section
Enablers Section
Sources of Requirements (inputs to the process)
Enterprise Analysis, Strategy & Governance
Stakeholder Analysis
Communications Plan
Requirements Design & Engineering
Readiness Assessment
Solution Definition & Selection
Solution Evaluation Report
Solution Delivery Review
Tool Requirements
Communications Plan Workflow
Risk Register
Requirements Register and Repository
Service Portfolio
Service Design Package (SDP)
Bibliography
Appendix B – Links to COBIT5
Goals & Metrics
Appendix C–An Example of a Code of Ethics
Glossary