Published by SHIFT Media IncOnline and in Printwww.shiftmediainc.comMail, Telephone and E-mailSHIFT Media Incorporated1521 Concord PikeSuite 301Wilmington, DE 19803USAPhone: +64 27 5772423info@shiftmediainc.org

© 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 info@shiftmediainc.org

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 ensurethat the information is accurate, the publisher can accept no responsibility for any errors or ommissions or for changes to the detailsgiven.

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

Contents1. Preface v

1.1 Acknowledgements v1.2 Audience v

2. Introduction vi

3. Perspectives–Frameworks & Requirements 13.1 Business Analysis: BABOK 13.2 IT Governance and audit: Cobit5 (Requirements Process Audit) 23.3 IT Service Management–ITIL (Service Design) 33.4 Software Engineering 33.5 Project Management 63.6 Enterprise Architecture 9

4. Requirements Register 12

5. Requirements for this book 145.1 Problem Statements 145.2 Requirements 155.3 Benefits 165.4 Final and Intermediate Outcomes 17

6. Requirements Management as a Process 186.1 Process Overview 186.2 Scalability 196.3 Sub-processes as perspectives 19

7. Integrated Requirements Process Flow 217.1 Top Level Process Diagram 217.2 Role: IRP Owner 237.3 Role: IRP Manager 247.4 Missing Role: Project Manager 257.5 Critical Success Factors (CSFs), Key Performance Indicators (KPIs and Metrics) 267.6 Responsible, Accountable, Consulted, Informed (RACI) – Top Level 277.7 Example of initial ‘raw’ requirement 287.8 IRP Sub-Process 1: Requirements Analysis 307.9 IRP Sub-Process 2: Requirements Elicitation 317.10 IRP Sub-Process 3: Requirements Organised 337.11 IRP Sub-Process 4: Strategy Approved – Service Chartered 357.12 IRP Sub-Process 5: Solution Designed 367.13 IRP Sub-Process 6: Service Transitioned 387.14 IRP Sub-Process 7: Service Sourced 407.15 IRP Sub-Process 8: Service Operated 417.16 IRP Sub-Process 9: Continual Service Improvement 427.17 IRP Sub-Process 10: Change Approval 43

8. Requirements Lifecycle 448.1 Need Identified 478.2 Service Strategy 478.3 Stakeholder Analysis 488.4 Elicitation 498.5 Logged: Requirement / Late Requirement 498.6 Categorised 508.7 Confirmed 518.8 Prioritised 518.9 Organised 518.10 Linked to Service Design Package (SDP) 528.11 Formal specification 53

8.12 Model 538.13 Assumptions & Constraints 538.14 Verified 548.15 Not Appropriate 548.16 Validated 548.17 Chartered 558.18 Solution Design 568.19 Solution Approved 568.20 Service Transition 578.21 Service Operation 578.22 Continual Service Improvement (CSI) 588.23 Service Improved 588.24 On-going CSI Requirement 598.25 Requirement Delivered 59

9. Governance Structure 609.1 Process Diagram Overview 609.2 Control Section 629.3 Action Section 749.4 Enablers Section 879.5 Sources of Requirements (inputs to the process) 909.6 Enterprise Analysis, Strategy & Governance 909.7 Stakeholder Analysis 909.8 Communications Plan 919.9 Requirements Design & Engineering 919.10 Readiness Assessment 929.11 Solution Definition & Selection 929.12 Solution Evaluation Report 939.13 Solution Delivery Review 93

10. Tool Requirements 9410.1 Communications Plan Workflow 9410.2 Risk Register 9410.3 Requirements Register and Repository 9510.4 Service Portfolio 9510.5 Service Design Package (SDP) 95

11. Bibliography 97

13. Appendix B – Links to COBIT5 10213.1 Goals & Metrics 102

14. Appendix C–An Example of a Code of Ethics 105

16. Glossary 109

T

1. Preface

1.1 Acknowledgementshe author would like to acknowledge the help of the reviewers. Particularly Steve P. Blais whokindly 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 toKirstie Magowan for her patient assistance with both the direction and structure of the book and itsediting. 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, BusinessAnalysts, Architects, Service Owners, Process Owners and vendors in both service management andbusiness 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

T

2. Introduction

‘The top five causes of troubled projects were:1. Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise2. Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning3. Schedules: Too tight, unrealistic, overly optimistic4. Planning: Based on insufficient data, missing items, insufficient details, poor estimates5. Risks: Unidentified or assumed, not managed.‘ 1.

his book is intended for business analysts and service management professionals who seek toprovide 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 oneIntegrated Requirements Process (IRP) reducing cost and risk to the organisation, while improvingthe 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 allrequirements, 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 abusiness requirement, albeit that the route may be indirect, and that both process and service insightare applied to business analysis to enable genuine alignment of applications to services and thus toboth service management and business processes. At present, few business analysts are aware of, orwork with, the IT service management processes.Requirements, and the process of refining them to produce good solutions, have been consideredmany times in the past. Practitioners of software engineering, project management, enterprisearchitecture, 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 mutualunderstanding or coordination of approach. It is important to remove confusion between the variousrelevant guidelines, frameworks and standards.Cobit5 (Control Objectives for Information and Related Technologies) is a framework of governanceand audit guidance produced by ISACA (Information Technology (IT) Management and ITGovernance) to assist auditors to ensure that organisations are achieving good IT governance. If thesuggestions 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 asuccessful audit of its requirements management and solutions development activities.The BABOK is a book produced by the IIBA (International Institute of Business Analysis) to provideguidance to business analysts on the gathering and analysis of requirements and the production ofsolutions (mainly software solutions) to satisfy those requirements. The book is written as a series ofinterlocking activities. Its emphasis on software means that it is weak in managing service, processand 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), thatdescribes the management of services, with the copyright owned by The Cabinet Office in the UK andmuch of the content provided by members of the itSMF®(IT Service Management Forum). Thelifecycle of a service, and the management of all parts of the service, are described from thedefinition of the service strategy, to the service design and then onwards to the service transition intothe live environment described in service operation. The vital aspect of the quality management ofservices across this lifecycle is described in the Continual Service Improvement (CSI) book, whichapplies across the whole lifecycle, as well as to services, processes, tools and architectures. ITILdoes 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-governedorganisation that has service management as an asset and the strategic capability to achieve businessresults 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’sthat an auditor can apply to these processes, it does not give the detail of how to achieve these inpractice that is found in the ITIL books. The BABOK gives considerably more practical detail of allthe activities that a business analyst will perform. It does not show how these activities align to theprocesses described by ITIL and Cobit5. It does not align to the provision of end-to-end services asunderstood by ITIL.This book is not an attempt to provide a unification of all the advice provided by these frameworks. Itis 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 aunified view of the requirements and solutions production process that incorporates all of theseframeworks. The aim of this publication is to provide this unified view. The requirements processcan be integrated with any of the frameworks or standards mentioned.The method used for this integration is to understand how requirements management works as anoverall process with solutions management. The excellent advice given in the various frameworks isused 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, theunderstanding of the importance of a centralised requirements register (or repository) linked to therisk register of the organisation and integrated with the service portfolio (and, quite likely, in largerorganisations, with the overall business investment portfolio) is relatively new. So an example of atemplate for a requirements register is provided that can be used as a starting point for developingsuch a tool.Some advances in social media, technology that post-date BABOK, and were emergent when ITIL2011 was produced, are also considered – in particular, the use of hash tags to facilitate thecategorisation of requirements.Governance, as a discipline, is the driver for all corporate action; therefore requirements must bedeveloped in line with governance. For this reason, the requirements process must be part of acorporate 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, internallyand externally, through a Cobit5-based audit process.1. Strategies for Project Recovery © 2011 Project Management Solutions, Inc.

T

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 lackof user input, incomplete requirements or changing requirements.’ THE STANDISH GROUP REPORT 1995 ‘The StandishGroup

he need to understand and define requirements clearly has existed for a long time – majorengineering 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 beenunderstood to be important to successful development, and this has led to the establishment of the roleof the business analyst. The BABOK model provides valuable insights into this role as defined by aset of software, application-based activities.The service management view of applications as part of a larger picture of services isnot part of the current perspective and the IRP does not attempt to replace it, but toenhance the current view by showing how that service view can be incorporated,along with the management and quality improvements from managing businessanalysis, as a process.This incorporates the activities from BABOK into the processes of ITIL and, by doing this, enablesthe alignment of BABOK and ITIL to the Cobit5 audit and governance requirements found in thesection ‘Build, Acquire and Implement’ – in particular, the two processes BAI01 (managerequirements definition) and BAI02 (manage solutions identification and build).Overall, the aim of the IRP is to allow business analysts, service management professionals and ITaudit 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 beinggoverned and managed effectively. The latest version of Cobit, Cobit5, has been structured along thelines of ITIL 2011 – Cobit5 includes more areas, such as development, than ITIL does; not everythingmaps to ITIL.Cobit5 recognises the importance of requirements and, indeed, recognises the importance of twoprocesses for managing requirements – though the specifics of implementing these as processes arenot within the scope of Cobit. The need to measure the compliance with requirements is alsospecifically 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 IRPgoes 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 Cobit5documentation, 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 thecore volume ‘Service Design’. This is described as requirements engineering and includes the mainactivities involved in defining requirements. ITIL does not treat requirements engineering as aprocess 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 aprocess structure and this, currently, is not part of service design. For the purposes of the IRP, theimportant sections mentioned in service design are included, but, in an ideal world, the processdescription included here would be retrofitted to both the service management lifecycle (not justservice design) and BABOK.

3.4 Software Engineering

Software engineering has been considered as a discipline for several decades, and many differentapproaches have been adopted to tackle the difficult matter of engineering something as apparentlyintangible as software.A few of the common approaches follow; what they have in common is that all recognise theimportance of understanding and managing requirements properly, but all take a different approach toachieving this. All also look at requirements from the point of view of a particular project, rather thancorporate wide.

3.4.1 Requirements Engineering

Requirements engineering examines the first stage of a software development process and splits itinto 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. Thedifference is that the IRP considers these as being in need of coordination and management across theenterprise, 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 asthe first stage, before software design.The engineering methods covered in SWEBOK are all practically useful and well tried in practicalsituations. They deal with software, primarily, rather than including the wider perspective of serviceprovision, which makes them secondary to service management or enterprise architecture. Treatingthem separately from service management or enterprise architecture distances them and increases therisk of poor communication through the proliferation of interfaces. The IRP unifies all these into oneprocess, 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 inthe 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 needfor requirements to be clear and ‘atomic’.Many software tools exist to provide templates and workflow based on these principles. Mostly, aswith the other approaches here, they do not include the service management perspective and do notunderstand requirements as corporate assets or the need for them to be managed through a centralregister 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! TheRQNG 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 thisgroup.The group has also produced a requirements management tool (www.pragnalysis.com) that includessoftware, templates and advice in the matter of clarifying and documenting requirements.

Importantly the approach emphasises the importance of precision, brevity, quality, consistency andflexibility in managing requirements – all of which are important.The emphasis is on helping the business analysis part of the job, without integrating servicemanagement 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 improvementprojects 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 aspart of the development cycle. It does have linkage to service delivery, as well as project delivery, soit is often used as an adjunct to service management.It considers many of the questions that the IRP addresses and provides excellent advice on dealingwith them.It does not advocate a requirements register and does not address the re-use of requirements orrecognise that requirements are not simply a development matter, but rather corporate assets that needto 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 isso 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 theimportance 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 laterequirements well. The method has its well-documented disadvantages as well. The emergence ofagile 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 seesthe 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 beforethe invention of the computer. The task of project management is to achieve the project goals throughleading the project, managing the resources (including people), and planning and organising theproject 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 thecase. The goals are vague and the project is described ambiguously. This happens so often thatproject 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 tooverlap with business analysis.What the IRP enables project managers to do is to start, as they should, at the planning stage, havingbeen given a clear description of the project requirements at the design stage. If there are additionalrequirements because of the nature of the project, these can be documented and addressed as part ofthe IRP, rather than, as is often the case, there being separate lists of requirements kept by the businessanalyst, the project manager, the development team and the technical team involved with thedeployment. This greatly increases the risk of error – which can be considerably reduced by havingone 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). Itdescribes all the stages of a project in considerable detail, along with templates that can be used todocument 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 inPRINCE2.The IRP can add considerable value to practitioners of PRINCE2 by managing the requirements andbuilding the business case before the real strengths of the framework come to bear at the projectplanning, 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 respectedand used method of project management.A project, as described by PMBOK, involves obtaining authorisation, establishing the scope, definingthe course of action and understanding the objectives and project specifications. The PMBOKdescribes a requirements management plan for the project. Unlike the IRP, this management ofrequirements 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 requirementspoorly 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 emphasisesadaptability and short-term delivery. The extreme approach expects activities and requirements to bechaotic. 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 requirementsto be taken into account.The IRP takes late arriving requirements as a necessary part of requirements management, just asXPM does. However, IRP does enable requirements to be properly documented – quickly. XPM canbe used, at much lower risk, knowing that, even though requirements have been assembled during theproject, they have been documented and analysed for risk, so they are traceable and can be re-usedfor 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 theprinciple 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 theacceptance of lean thinking. It emphasises continual improvement, measurement and qualitymanagement.Agile project management and software development are based on an iterative approach to evolvingsolutions. The understanding of requirements, and the development of their solutions, emerges as partof the collaboration between loosely defined cross-functional teams.As with XPM, this collaborative and innovative culture can achieve great results. The idea ofevolutionary project management reflects the way that many things in the past have actually beenachieved and is something of a reaction to the micromanagement that typifies the more formalwaterfall-type methods.The top-down management of traditional projects is part of the problem that is being reacted to. Thecommunication of requirements and possible solutions in an hierarchical organisation can be impededby 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 bemisunderstood.The IRP provides a central register of all requirements. As with social media networking, everybodycan contribute to the understanding, improvement and solution of requirements – as well as addingnew ones as and when these are required. So the documentation requirements of the more traditionalmethods 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 andimproving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution. Thescope of the EA includes the people, processes, information and technology of the enterprise, and their relationships to oneanother and to the external environment. Enterprise architects compose holistic solutions that address the businesschallenges 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 progresstoward the desired state’ © 2012 Gartner, Inc.

It is clear from the above that understanding requirements is essential to be able to define an effectiveenterprise architecture.

3.6.1 Service Orientated Architecture (SOA)

As the name describes, SOA designs an architecture based on inter-operating services. An SOAexercise 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 communicatewith 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 withrequirements in a similar way to SOA, which describes them as ‘requirement objects’. SOA relatesrequirement objects to platform objects – a design unit object is produced as a result of transforminga business requirement into a specific platform. The IRP does not concern itself only with codingrequirements for a software solution, so it tracks requirements more broadly but, once a requirementis defined for a particular development activity, it is, essentially, identical in the IRP and SOAdefinition.An SOA expert might use business activity monitoring (BAM) to understand how the businessoperates – thus gaining an insight into requirements. This is similar to the elicitation technique ofobservation, 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 servicearchitecture. This is not, though, the main focus of SOA; it has relied upon other parts of theorganisation, 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, itsmanagement of requirements is not among its strengths. Requirements are not managed in a consistentand 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 asa 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 inorder to build the architecture. The phases are:

1. Preliminary – framework and principles2. Architecture vision3. Business architecture4. Information system architecture5. Technology architecture6. Opportunities and solutions7. Migration planning8. Implementation governance9. Architecture change management

Togaf understands how central requirement management is to achieving all this. So much so that thetop-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 ofthe enterprise architecture engagement. However it makes it clear that the proper management ofrequirements is essential.The IRP described in this book would provide exactly the requirements management framework thatTogaf stipulates.

T

4. Requirements Register

he integrated requirements process (IRP) has been designed to use a requirements register as thecentral repository of all requirements, organisation-wide.

The main difference between a repository and a register is the level of workflow and organisationalauthority. A repository is a database, structured document, or other storage area. A register, though itwill use a repository as the technical means of maintaining the information, is part of organisationalgovernance. 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 notbe 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 particularproject or, in the case of ITIL, a service. Both ITIL and the BABOK speak of the re-use ofrequirements, which is important both to avoid losing important requirements and not to waste timere-discovering known requirements. Both of these are necessary for cost-effective requirementsmanagement.The problem is that, although re-use is mentioned as a desideratum, there is no explicit activity orprocess 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 aproject is part of a programme there is nobody responsible for its requirements re-use once theproject is complete – there is a general design requirement that, when a new project starts, thebusiness analyst checks to see if there are existing requirements that can be re-used. However there isno 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 datastructures that are difficult to manage and are error prone. The use of tags to categorise requirementsenables them to be easily linked. These tags link to other services, corporate initiatives, specific risksand other relevant matters. The links are intuitive, straightforward and flexible.People and organisations need to look at requirements from different perspectives. Tags can help inproviding this different perspective.Some discipline is required from users to ensure that tags are used effectively. If the tags are trackedand managed properly, the risk of confusion can be minimised. At a minimum, all tags should containtheir originator and the time they were created, to help clarify obscure tags. A list of existing, relevanttags is maintained to allow easy re-use of important tags.

T

5. Requirements for this book

his book is a book about requirements, so it is reasonable to ask what the requirements for thebook 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 suggestthe 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, butfrequently 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 differentsilos, with the best practice framework advice being good, in both cases, but suffering from a lack ofintegration. 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 poorresults and low customer satisfaction

• Development effort can be aligned to apparent demand from particular stakeholders ratherthan to actual business requirements, resulting in skewed priorities in the deployment ofcapabilities 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 intoeither 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 actuallyfollowed. 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, ratherthan 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 requirementlevel

• Full incorporation of requirements management in the service design, as well as thedevelopment 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 requirementseffectively.1’There are many components to a process. The process view enables the identification of all these components, this enables theestablishment 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 (definerequirements) and BAI3 (identify and build solutions); these are also covered as different activities inthe 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 seeprocesses 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, ormirrored, in the solution. Treating them in practice, as Cobit5 does, from an audit perspective, is notideal. For an auditor, there is value in understanding whether it is the management of requirements orthe production of solutions that are contributing to good governance.To a practitioner, whether a business analyst, developer, service manager or business manager, theimportant value is that the overall process (the IRP) delivers solutions that are well engineeredaccording to the requirements.More importantly, the unifying thread through the process is the requirement itself. The requirementmay apply across the organisation to many different applications and services. There is a hierarchy ofrequirements, with corporate-wide policy requirements translating, eventually, into very specificrequirements for a particular module or interface.For example:Governance -> Policy -> WarrantyA warranty requirement that ensures that working in parallel on redundant servers can work for allapplications, 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 withminimal cost.This, in turn, would be based on the governance requirement that the organisation has a cost-effectiveway 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 technicalrequirement should still be visible so that re-use in another project, application or service ispossible, 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 asolution.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, whichis 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 partof the overall process needs improvement. From that perspective, seeing the gathering of businessrules as a distinct activity is important.At the other end of the process, the sub-process of selecting the solution architecture that best fits allthe 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 ofobjectives, 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 riskThe 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 thisreason, before going into the detail of the various parts of the process, the workflow, in terms of thelifecycle of a requirement is covered.11. 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.

T

7. Integrated Requirements Process Flow

his chapter reviews the detail of the IRP process flow. First, the top-level view, and then each ofthe 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 alsoa 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 supplierexternal to the organisation may uncover an issue or make a suggestion that reveals itself as arequirement.

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 thepossibility of a completely new approach being taken. It is important that this first description islogged so that it can be analysed properly and, if of value to the business, eventually, addressed bybecoming part of a new solution, whether as a change to a business process or as a service to thebusiness or by some other means.All requirements are logged in the requirements register. This enables them to be tracked and, wherepossible, re-used in multiple projects, programmes, services or other solutions. Some may becomecorporate policy. Requirements are linked to the solutions that satisfy them, allowing all processesand 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 includesa refinement of the wording to make sure that it states precisely what is needed in terms that can beunderstood 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 elicitrequirements from stakeholders. This sub-process fleshes out the original idea with considered inputfrom customers, users and other stakeholders using a number of techniques, for example, elicitationworkshops, surveys, interviews, or questionnaires.The requirements are logged, analysed and gathered together to form a problem statement that is thenorganised with other requirements, such as company policy, legal obligations and so forth, andprepared as a business case. The business case is the tool used to explain the proposal and provideevidence for and against the proposal, such as benefits, risks, and opportunities, along with the costsinvolved. The business case, if approved, is planned, along with other strategic initiatives, and addedto the Service Portfolio.When the business decides to implement the proposal as a service, it approves the budget andallocates resources to it, moving the service to the status of ‘chartered’. Once chartered, the proposalwill be adopted within a defined time frame and cost. This creates a change proposal that is used todesign the solution.The design of the solution is captured in the service design package (SDP) that describes all aspectsof the service along with the requirements that it will satisfy. At this stage, the acceptance criteria aredefined, 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 thedevelopmental activities are complete and the solution has been tested thoroughly and verified againstthe requirements to ensure that it satisfies them, it is released and deployed as a service. The servicestarts 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 servicebecomes 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 tocategorise 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 majorchanges. Large changes will be planned and implemented by the transition phase and small changeswill be implemented directly by operations.

7.2 Role: IRP Owner7.2.1 Responsibilities

The IRP owner is accountable for the process meeting its objectives in the organisation. Thisinvolves defining, designing, communicating, implementing and then managing these processcomponents:

• 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 havecontrol of the IRP register and the service knowledge management system (SKMS) componentsrelevant to requirements. The IRP process owner must have the authority to manage requirements ascorporate assets.

7.3 Role: IRP Manager7.3.1 Responsibilities

The IRP manager is accountable for the operational management of the IRP. The IRP manager worksclosely 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 problemstatements

• Managing the organisation, communication and coordination of these problem statements, andtheir component requirements to produce business cases

• Sponsoring of business cases to senior management and the board to ensure that they areresponsibly rejected or adopted as chartered services

• Coordination of the design, transition, sourcing operation and improvement of services and therequirements they solve.

• ActivitiesActivities 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 ofearly 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 anaccident. It is quite possible that a project manager will be appointed to help with the planning stagesof the various projects that comprise the overall requirements life cycle. However, the role of theproject 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 managerwill elicit and refine requirements – this is not necessary at the project level because it will alreadyhave been done by the business analyst. Similarly, the business case for any project will bedeveloped, presented and approved by the appropriately responsible or accountable person beforethe 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 projectsucceeding, has taken it upon itself to assume these responsibilities when it ought not to be part of theproject 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 theIRP 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 requirementchanges at each stage. The form itself is a mock-up, or wire-frame, of how an application might bedesigned to provide company-wide access to the requirements register. The form is fully described inAppendix 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 fromthe financial director (FD), so, in terms of the IRP, this is a newly identified need. The first stage is tostart the requirements analysis. We can see already that this is a high value, high risk and high urgencyneed, with corporate impact. The FD has already allocated funds for the investigation phase soresources can be allocated.It is likely that this requirement has actually come from the IRP itself. The FD might have logged thisin the CSI Register and the IRP manager, working with the CSI manager and the change manager havedecided 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 financialsystem can be obtained from the requirements register, collated and checked with the customer to seewhich 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 majorconcerns and a clearer idea of the business drivers. This, in turn, will be used to plan therequirements elicitation phase.As a requirement, this is clearly raw. It is not a single, atomic, requirement. It mentions a number ofdifferent areas. It is also ambiguous as it is not clear what, exactly, is meant by ‘errors’ or what ‘moremodern’ means. However it does have the virtue of being exactly what the customer thinks at thisstage. It will be clarified with the customer, probably split into multiple sub-requirements andconnected to existing requirements and those that come from the first elicitation activities. Keeping allthis 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 havelinks to the risk register, the SDP, the CSI register and we have not defined the stakeholders andauthorisers. 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 requirementscan 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 inone. 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 IRPregister) 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 departmentto make sure that the requirements are correct. This is now ready to be assigned as a task. When thetask is complete, the requirements will be approved by the FD and by the IRP manager for inclusionwith 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, thestatus of those incidents and problems relative to resolution and the actual perception of the users andthe customer. Once these are understood, the need for upgrading the service can be understood, aswell as the amount of work required. This option, of repairing the current system, then, with theagreement of the service owner and FD, can be entered as a new requirement and be part of the nextstage of analysis. It will be considered with the other requirements in the drawing up of the problemstatement.

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 andre-write it as an unambiguous, atomic requirement of the exact need. The service owner can set up arequirements 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 toelicit requirements. Once the requirements have been gathered, they are properly specified, asunambiguous, clear, atomic requirements.Experienced business analysts may notice that the brainstorming method is not included; this isbecause recent psychological research has found this not to be an effective method of gettinginformation from teams. Instead the Delphi technique, which involves the gathering of requirementsfrom 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. Therequirements are then verified to ensure that they are effective. They are then used to produce awireframe, prototype, user story or other method to communicate the requirements back to thestakeholders.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 andagreed. This may not be a matter of complete consensus and any conflict between stakeholders isescalated 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 nowdiscussed with the FD to discover exactly what he had in mind for this requirement. A set ofinterview questions has been designed in advance to be sure to cover the requisite ground. Theinterview is documented afterwards. The requirements are put through another stage of requirementsanalysis to be sure that that they are clear, coherent and express what is needed without makingassumptions about a particular solution. These are then returned to the FD and IRP owner forapproval. Once the new requirements have been approved, they are developed into a problemstatement 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 beenmet for other services. The EPEAT green purchasing, BYOD policy and the capacity managementdemand statistics requirements are already part of existing solutions and that knowledge will be usedto ensure that the new financial service achieves these requirements. Considerable time, effort andcost will be saved by re-use of this work and the risk will be lower because of lessons learned fromthe existing deployment.The one new requirement, which is specifically for finance, ID: FD-ES1211-0001-2008-01, hasalready been used to produce the current solution – it only needs to be revised in light of the newversion of the IFRS. The FD has added a note that the existing solution does not deal adequately withIFRS 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 otherproblem statements, to build the business case:‘The accounting service does not comply with IFRS 2012, EPEAT, or BYOD and needs to providecustomer 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 businesscase is an important part of business decision making and must be right. Though there will be othertechnical 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 changemanager 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 manageris 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 abusiness case for the finance service. This business case has to establish the need, the benefits, thecost, 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 (eachof 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 involvedin completing the business case, particularly the financials. Service strategy will also make sure thatthe business case is within existing policy and delivers business value.The business relationship manager (BRM) makes the presentation to the board and, if the businesscase is rejected as incomplete, helps ensure that it is prepared properly for resubmission. Newrequirements 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. Somerequirements may be satisfied by other means, some may have to be rejected altogether. Thiscommunication process is handled by the IRP manager to make sure that a satisfactory plan is agreedfor all the requirements that made up the business case.Change management agrees the change proposal, making sure that it is funded properly, the risks havebeen assessed and resources and capabilities are adequate. This also makes sure that the milestoneswill 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 newservice 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. Inoption 2, the IRP manager will arrange for the investigation and improvement of the business case toproceed. In option 3, the IRP manager, with the approval of the change manager, will authorise themove of the proposal to the service design phase of the ITSM lifecycle. The final action from thissub-process will be the production of a change proposal for the solution design, linking the finalbusiness 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 serviceimprovement in the design process. This is well covered in the ITIL book Service Design so only thetop-level design components are shown. It is worth noting, however, that the ‘utility designed’ taskincorporates 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 requirementsin 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, withsupport 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 theappropriate time. In terms of business analysis, the solution, or possible solutions, to the requirementsof 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 transitionas a change request rather than a service with an SDP. A solution may be many things including achange 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 soughtfor existing requirements. Warranty requirements will be established and agreed with customers, inthe form of Service Level Requirements (SLRs) and the various requirements for successful servicetransition, service operation and service improvement will be defined – including checklists for thevarious sets of acceptance criteria. Where possible, previous work will be accessed in the SKMS orIRPR 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 maynot need to be reviewed with all stakeholders. The IRP manager will then authorise them to be addedto the project. If these new requirements have significant implications for the cost, delivery time oractual delivery of the service, this will be communicated with stakeholders and logged in the riskregister.When design is complete, the service design process and the IRP manager will authorise the releaseof 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 requirementscan occur at many stages of the service lifecycle; however, it is in service transition that they are mostlikely to do so. The IRP sub-process to deal with late requirements is included at this stage. A numberof 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 thatthe 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 aparticular organisation. The important characteristics of this process include:

1. All late requirements are logged2. Where necessary, they are logged in the risk register3. 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 itto a later phase is taken with the informed involvement of service transition – in particular, changecontrol – 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 theproduction 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, intoearly 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 againstthe agreed timeline. The IRP manager will make sure that any new risks, deviations from the plan, orrequirements that emerge at this stage, are understood, logged and handled appropriately. The IRPmanager will communicate with stakeholders, or escalate matters to the risk register, if any significantdelays, 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, thatany 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 atight control of the planning, development and delivery of the solution. It is quite likely that this willnot simply be a matter of internal development or external supply; there may be components of bothrequired 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. Thesourcing decision will be made based on corporate policy, supplier policy, the technical strength ofthe options available, the cost and benefit of the various routes, among other criteria. These decisionswill be made with assistance from strategy, design, transition, operations, development andmanagement. It is possible that a final decision will only be reached after a proof of concept or pilotdeployment.

7.14.1 Worked Example Stage 7

Usually this sub-process selects an appropriate way of sourcing a service. If the solution is not aservice 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 abusiness process to the relevant business unit manager.Services may be sourced from internal development, or they may be outsourced; for example, ascloud services, they may be bought as complete solutions or open-source solutions might bedeployed. 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 beoverseen by service transition or by the IRP manager. Both will require a clear project plan forappropriate delivery. This plan may be passed, with the SDP, directly to the development team, ormight form part of an invitation to tender (ITT), request for proposal (RFP) or similar contractualdocument 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 byservice 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 willbe identified as CSI improvements, often from incident management, users, customers, service levelmanagement 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 servicelevel 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 sidesare understood and resolved. The BRM works with the business to understand possible future needsand communicates these back to IT – the IRP manager works closely with the BRM to make sure thatthese 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 thebusiness 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 aprioritisation meeting according to schedule.

7.16.1 Worked Example Stage 9

The continual service improvement (CSI) process is either run as a programme, with periodicreviews of outstanding improvement requests, or is triggered by significant improvement proposalsthat require analysis, prioritisation and planned execution.Some recommended improvements might be radical enough to warrant being entered into the IRPR asnewly identified needs – triggering the whole IRP process again. This is the case with the followingworked 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 asrequests for change (RFCs).

7.17 IRP Sub-Process 10: Change Approval7.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 documentation2. Normal changes are approved, possibly with the help of the change advisory board (CAB).

Once approved, these will be authorised for implementation by service transition3. 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.

T

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, makingit the single biggest reason for project failure–bigger than bad technology, missed deadlines or change managementfiascos.’2The 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 lifecycleof a requirement. Specifically, it describes the different statuses that a requirement can have during its lifecycle. This is animportant part of managing the requirements themselves.

he process status diagram (Figure 13), shows the flow of a requirement through the IRP. Thepossible 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 mostrequirements will follow, and the possible ‘exception flow’ (yellow) that may be necessary inparticular situations.It is likely that there will be sub-statuses added to this overall flow for a particular organisation. Thisis normal. Business analysts, service management professionals and developers will all work withrequirements at particular stages, and will wish to track their progress with the requirements, as wellas the overall status. This detail is not included here, in order to keep the diagram simple and torecognise that the sub-statuses will need to be worked out in each organisation, to suit itsorganisational structure and working methods.This flow is the heart of the IRP. It is this process that enables a requirement to become anorganisational asset, as well as part of a particular deliverable, project plan, service design packageor developed operational solution.After the process status diagram, Figure 13, each top-level status in the process flow is describedbriefly. Some of these brief descriptions will need expansion into the actual workflow in a particulardepartment–for example the ’15. Validated’ status will require a description of the stakeholdersinvolved in the process, the policy for arriving at an agreed validation as well as any escalations orother decisions that need to be made.The whole process is, as with all service management processes, under the control of changemanagement. In a particular organisation, the process owner will have to work with the changemanager to establish how approvals, work orders and RFC’s will fit into this process–and this willneed 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 tocompletely new services, processes or other solutions, or result in being recognised asimportant 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 beconsidered along with other requirements.From the point of scalability, a requirement that arises, for example, from the demand managementprocess, could be dealt with entirely by the capacity manager through the change management processbut, being logged in the register, the related risks, costs, benefits, and other associated details, arevisible to a wider audience and might help address some other need when found in a search of theregister.The register is part of the service knowledge management system (SKMS), which provides the basisfor sound decision-making in a service management organisation. So these requirements provideorganisational and historical knowledge for future decisions, preventing re-invention, re-discoveryand rework.

8.2 Service Strategy

Requirements that appear to be new to the organisation and which might require novel solutions oraddress new market spaces need to be considered using the service strategy processes. Theseprocesses work with the business to identify what new initiatives ought to be fostered and which donot fit the current direction or policy.As with customer service level requirements (SLRs) some requirements might not be possible ordesirable 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 thatthey can be moved to officially logged requirements, or kept in the ‘need identified’ category, forfuture 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 beconsidered for adoption as changes in policy or direction. Where they conflict with current policy ordirection, and have no other redeeming features, requirements will be closed with appropriatefeedback given to the originator.These closed requests will continue to be tracked, in case other stakeholders express the samerequirements – 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 thedecisions 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 willbe. This analysis can be started from scratch or, in a service management environment, will probablystart 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 areidentified.The normal flow would be: A need is identified à service strategy approves this for furtherinvestigation à this becomes part of a tranche of related requirements.The tranche of related requirements is what the service portfolio would see as a prospective newservice, and it would then follow the service lifecycle. More requirements will be added through thelife of the service.

8.4 Elicitation

Once the stakeholders have been identified, a plan is produced that decides which methods will beused to elicit requirements from stakeholders, in order to gain a clearer understanding of what theidentified strategic initiative is likely to involve.This stage can take time and involve many meetings with stakeholders using surveys, face-to-faceindividual meetings, workshops or other methods to identify requirements from stakeholders for theparticular initiative. All requirements identified in this process need to be captured and logged evenif, later, some may be duplicates, merged with other requirements, or split because they cover a widerscope than just one requirement. It is, however, vital to record them, along with the originatingperson, 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 everythingduring elicitation. It may not be possible to log them directly, during an elicitation session, but theyshould 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 isimportant that they follow the same process, but are recognised as having higher risk. That is why thestatus 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 laterphase or raised to risk management to be considered in the larger change evaluation. This ensures thata properly informed management decision can be made on perhaps delaying the overall delivery of asolution 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 bemanaged appropriately. If, however, it transpires that for political reasons, habit, or some otherreason, some parts of the organisation, or individuals, frequently lodge important requirements late inthe process in the hope that they will avoid the usual scrutiny, this can be tackled properly as amanagement issue. This avoids the situation where these late requirements become an extra stressorto development often leading to delays that appear to be the fault of development or projectcoordination, 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 managementcommitment and a concerted education of stakeholders on the importance of timely provision ofrequirements. See the controls section.The requirements register tool provides workflow options to enable the escalation and resolution ofissues resulting from late requirements. See the tools section.

8.6 Categorised

Requirements have been entered into the appropriate categories. Mostly this will involve separatingutility (functional) from warranty (non-functional) requirements, understanding the utilityrequirements in terms of functionality supplied, constraints removed or both.This is also where some preliminary judgement can be made on the importance of requirements. Theycan 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 previouslymentioned, this is where tags (hash tags, for example) can be used to great advantage. If a particularset of requirements seems to form a natural grouping, this can be reflected by a tag which may besomething 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 caneither be added to categories or formalised as standard tags.Requirements need to be analysed from various perspectives, both to aid understanding them and touncover innovative approaches to solutions. Such perspectives can be captured at meetings betweenstakeholders and preserved quickly, and informally, as tags, which can be analysed in more detailafter those meetings.Without this technique, important insights can be lost in unformatted text notes or linked to categoriesthat 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-formedrequirements. The implications of the requirements for possible solutions are not yet understood; thisis mainly a mechanical clarification exercise, making sure that the language is clear and reflects whatthe originators have meant.Another perspective can be derived from a stakeholder meeting where non-stakeholders canchallenge 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 tomake 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 valueexpected 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 beanalysed more closely for value, and possibly escalated to risk management to establish if they areappropriate.

8.9 Organised

Requirements are organised into those that are wider organisation requirements (beyond the scope ofthe current engagement), those which may apply to quite separate processes or services, and thosethat 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 ismaintained.

8.9.2 Merged

This requirement has been found to be part of another requirement, so has been merged with it. Thisstage exists for practical reasons so that, if there are a large number of apparently connectedrequirements, they can be moved to this status first, and then analysed carefully to ensure that nosubtle differences are ignored when an apparent duplicate requirement is closed.The new, merged requirement contains reference to the constituent sub-requirements so that an audittrail 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 thisstatus, leaving only one authorised requirement. This stage exists for practical reasons, so that, ifthere are a large number of apparently duplicate requirements, they can be moved to duplicate statusfirst, and then analysed carefully to ensure that no subtle differences are ignored when an apparentduplicate is closed.The remaining requirement contains reference to the closed duplicate requirements, so that an audittrail is maintained.It is important to keep track of all duplicates – apart from the technical necessity of doing so. There isthe 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 itspriority 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 linkedto the SDP so that they can be documented as part of the service lifecycle. The SDP follows a servicethroughout its lifecycle and includes all relevant technical and business information, along withdesign, transition, and operational and improvement documentation.The SDP includes, particularly, transition and operational requirements that, though drawn up with thehelp of experts in transition and operation, are produced in the design stage, before the service movesto the transition stage.The requirements for plans and planning are also part of design; in particular they are part of theprocess 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 transitionplanning and support team.

8.11 Formal specification

The requirement is checked for consistency, clarity and ambiguity. It is re-stated, if necessary, informal 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, therequirement 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 therequirements, their interplay and to get some picture of possible solutions.AnalysedThe requirement has been analysed and confirmed to be unambiguous, to make both business andtechnical sense. An estimate has been made of the possible cost, risk and value to the business of thisrequirement. 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 wellas 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. Technicalexperts are found largely in the technical and application management teams, as described in ITILservice operation.What assumptions does the requirement imply? What constraints will the requirement put on possibleimplementation? This is likely to involve wider consultation, possibly including discussion with riskmanagement, to make certain that the solution will not be compromised by a poorly formed or poorlyunderstood requirement, or vice versa.

8.14 Verified

The requirement has been verified technically. This means that an appropriate person, possibly abusiness analyst, a developer, or a service management professional (probably for any medium orlarge 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 andaffordable technology – or a specific analysis of new technology that might be appropriate) and willadd 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 originatorof the requirement or to technical staff. Before moving to the state of verified, particularly for animportant, high risk or high cost set of requirements, it would be wise to instigate a small researchproject, probably involving capacity management, to explore the market for possible types ofsolution, 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. Thiscould be for many reasons. Importantly, the reason for the decision is listed in the requirement, alongwith the name of the decision maker and communicated to the originator. This makes sure thatrequirements are not simply discarded but, when they fail the validation process, are checked beforebeing closed.

8.16 Validated

The requirement has passed the validation process. This means that the person accountable for doingso has authorised the requirement as one that will be included in the business case, RFC or changeproposal.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 particularrequirements 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 ValidThe 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 withthe name of the decision maker and communicated to the originator. This makes sure that requirementsare 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 – themove to the ‘chartered’ status means that the solution has been approved. A budget exists so that, froma precise date in the near future, work can begin to plan the design process and bring together thedesign team. At this stage, key players, such as the process owner and the service owner, are broughton board and discussions are opened between the service design team, service transition and serviceoperation management to ensure that a holistic plan for design and deployment is developed. Toplevel service acceptance criteria can be set at this stage to guide all future design, development andtransition activities.

8.18 Solution Design

The requirement is currently with the solution design team. This means that that team will be makingsure 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 ofa wider consultation.Wider design consultations at this stage may involve a number of techniques – wire frames, UML (orother) use-case diagrams , user stories or similar to communicate with the originators of therequirements, as well as all other stakeholders. This is to ensure that affected parties understand theintended 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 therequirements of stakeholders.It is during this phase that further changes to requirements are to be expected. This is also where it isquite likely that new requirements will be uncovered. If these new requirements are deemed to beminor clarifications, they can be added. If, however, major changes to requirements emerge, these canbe logged in the ‘late requirements’ part of the process to recognise that there is an increased risk ofdelay to the project.The categorisation of requirements as ‘major’, ‘minor’ or similar will be based on the impact tobudget, 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 technicalstaff as well as development staff involving considerations of warranty, as well as utility, so thesecan 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 inwhich 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 forchange (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 therequirement will be linked to service acceptance criteria and checklists so that the testing, validationand change evaluation processes can take account of how well the transition is catering for eachrequirement. If any requirements are failing any of these, the requirements will be listed in the changeevaluation report so that the change manager can use the original requirement to make the decision asto 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 thelive environment, managed under service operation. Depending on the granularity of the incident andproblem 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 liveoperation can be monitored and those that appear not to be satisfying stakeholders can be suggestedfor 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, therequirement is likely to form part of a change review for the closing service or change. It is expectedthat 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 indeploying 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 willstill 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 designpackage (SDP) of which the requirement is part, undergoes an improvement during this cycle. Therequirement 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 importantthat 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 iseasy, without this, for a requirement to be missed and an intended improvement to cause things to getworse because the requirement is no longer met.

8.22.1 Superseded

This requirement has been superseded by another requirement. This may be because the requirementhas been understood more clearly and found to be part of another requirement that is better describedseparately, or it may have been part of a service that has been replaced with the requirementsuperseded by a new and different requirement. In either case, the superseded requirement willinclude a link to the requirement that has superseded it, along with an explanation of how this hascome about. It would normally be important to inform the originator of the requirement that this hashappened in case they come to the conclusion that their requirement has been simply closed and theirneeds 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 theparticular functionality to be removed from a process, service or solution, or might require an entireservice to be retired. Once everything associated with this service has been removed or retired, it canbe moved to the status ‘closed’. This status is important so that the fact that it is not required by anypart of the business can be validated, along with an understanding of whether this is permanent, orwhether 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. Itis important that a requirement stays in this state until the next CSI cycle so that work can be done tocheck that the service has, indeed, improved the stakeholder satisfaction. Once the organisation issatisfied 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 necessarilyoutstanding issues, but are requirements where the solution in place is not adequate to meet currentbusiness needs and will have to be improved at some time. When that happens, it is under the controlof the CSI prioritising process and, of course, change management. Being in this state gives thebusiness relationship manager the opportunity to discuss these with the business to decide if a higherurgency 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 toarchive even closed requirements, because it is possible that they may arise again and the informationas to how they were dealt with previously will be valuable to prevent unnecessary re-work or, ifcircumstances have changed, to show why the previously closed requirement was again worthconsidering.1. [Ibid.]

2. Christopher Lindquist, Fixing the Requirements Mess, CIO Magazine 15th November 2005

T

9. Governance Structure

his section analyses the IRP from a governance perspective. We have seen how the activity flowof 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 isdone and what resources and capabilities are needed. This is done to assess how to manage the IRPas a company-wide process.The process is considered as comprising the capabilities and resources required to enable itsoperation, the actions that take place and the controls that ensure that the process is managed andgoverned properly.All processes have a common structure. This structure is used to describe how the various parts ofthe 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, atthe top of the diagram, ensures that the process is governed and managed properly. The Activitysection, in the middle, describes the activities, procedures, and work instructions that enable theprocess to flow – these are the documented part of the process flow described above. The activitiesare 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 ofthe process are defined and communicated clearly and that the roles and responsibilities of all partiesinvolved are understood. The process diagram can be used as a guide to ensuring that all parts of theprocess 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 andprocess solutions that achieve the goals and objectives of the business by understanding therequirements of the business comprehensively and, dynamically, to track changing businessobjectives.General objectives include:

• Managing the lifecycle of all requirements in a consistent, cost-effective, traceable manneracross all business units, projects and services

• Ensuring that risks related to requirements are identified and tracked consistently andeffectively

• Providing a basis for continual improvement of the process and component sub-processes toreduce risk and making the solutions align with business priorities in a flexible and agilemanner

• 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 thenguide requirements through design, development and transition to high quality businesssolutions 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 thenumber 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 thegoals of the constituent sub-processes BAI01 (manage requirements definition) and BAI02 (managesolutions identification and build).The top-level process goals are:

• Business goals integrated into service solutions through well understood, well-defined andagreed 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 theultimate 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, theseprocesses 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 IRPcontrols solutions, services and processes. This enables the deployment of the process to beestablished as sound governance, as well as ensuring that senior management support for the processis sufficient to deal with teething problems, including resistance from individuals or parts of theorganisation.

9.2.5 Stakeholders

Stakeholders are best identified during the set-up of the IRP. If possible, it would work best if theyare 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 andall solutions used by the business. Pragmatically, the IRP should be introduced as a pilot for oneparticular service or business process and then extended, in a controlled manner, across the serviceportfolio 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 formanaging the process is, however, an important one, requiring an individual with goodcommunication 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 thepipeline to becoming operational and on to being retired. There is logic in the process managerreporting to the service portfolio manager role.The process manager role requires the same broad range of understanding as is required for thecapacity management role. If the organisation has a function that handles the service managementwarranty areas – as envisaged by the ITIL intermediate training ‘Planning, Protection andOptimisation’ (PPO), then the process manager (and possibly process owner) for this process couldbe 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 isadopted and works effectively in the domains it crosses: business -> business analysis -> servicemanagement à development. The overall process owner may well choose to appoint owners for thesubsidiary processes in each area or, adopting the Cobit5 division, for the requirements and solutionphases 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 mustbe defined in the corporate policy.The audit controls for a corporate asset include ensuring that there is a split between roles, forexample, between the person who is responsible for a task and the person who approves thecompletion of the task or who authorises the budget based on the output of the task. The IRP has beendesigned with this in mind but, when implemented in a particular organisation, it is a responsibility ofthe IRP process owner to ensure that all such audit controls are in place and documented in the policyand in the RACI matrices for the process.Any process, including the IRP, must be audited, both internally and externally, to ensure that itcomplies with corporate governance and operates as designed. The audit is likely to be carried outusing Cobit5, in particular, Cobit5’s BIA02 (manage requirements definition) and BIA03 (managesolutions identification and build) areas.

9.2.10 Control through Critical Success Factors9.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 requirementthat 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 isa measure that gives some indication of how well a particular CSF is being met. KPI’s define athreshold for when a failure of the CSF will have occurred. This can be used to define an alert beforesuch 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 forthe IRP. Each organisation ought to design CSFs, KPIs and other metrics in line with businessrequirements.

9.2.12 Customer Satisfaction and the Kano model

Customer satisfaction has previously been addressed in relation to product quality in design. Inparticular the Kano model, developed by Professor Noriaki Kano in the 1980’s, devised a qualityfunction 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 ofservice design (the part of the ITIL 2011 lifecycle that gives advice on the design and deployment ofprocesses). These metrics can be adapted from the metrics cited in Cobit5 or can be designed fromscratch.This process gives the lifecycle of a requirement. That is, it provides the status transitions thatrequirements pass through. When these are implemented, as part of the requirements register, theyenable the measurement of requirements metrics that can give the following type of information (theseare examples, rather than suggestions of ideal metrics):

• The ratio of metrics, verified vs. elicited, across the organisation or for a particular projectacross time. This gives a measure of progress.

• The ratio of logged requirements vs. late requirements for a particular project gives, overtime, a measure of how the discipline of logging requirements as early as possible is beingenforced. Initially there are likely to be a large number of late requirements, which, over aperiod will reduce as a proportion.

• The average time for a requirement to move from logged to closed, split by closingdisposition, this is a measure of solution development time as well as the operation of therequirements 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 enablevalue vs. cost to be calculated.

9.2.14 Key Performance Indicators9.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 IRPpolicy– 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 underthe 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 ischecked against the norm – if it is outside the norm, then an automatic action is taken to correct thesituation, 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 eachKPI 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 acceptablebusiness value. This is achieved by a number of methods, all of which involve some prioritisation ofrequirements according to business need, the urgency of the need and the impact of the need not beingmet being used to establish relative priorities. In development, this form of prioritisation has beenadopted 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 andurgent 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 urgencyand impact. Effectiveness can also be measured by surveys, interviews and satisfaction reports fromstakeholders.

9.2.18 Efficiency

Once effectiveness has been achieved in delivering a process or service, the cost of delivery, relativeto the value delivered, can be measured and those areas that cost the most to deliver (the leastefficient) can be improved by changing the process used or automating more of the process toimprove it.Metrics for efficiency can use the elapsed time between status changes as an overall measure as wellas the actual time spent by staff at each stage of the process. This is achieved best by measuring timespent automatically – for example, when a business analyst is working on a document checked out ofthe document management system (DMS), the actual time worked can be measured by the wordprocessor 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. Wherepossible, activity metrics should be related to the particular process, project or service being workedon but, if this is not possible, overall team activity can be measured and apportioned across the activerequirements to give some estimate of the time spent and, hence, the cost of the activity relative to thevalue 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 isdocumented 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 particularservice 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. Ameasure of the patterns of business activity from the business and customers can be seen by theimportance of particular requirements across the board, the number of incidents, problems orcomplaints related to the requirements not currently being met, or the value placed on therequirements by the business.This is a complex area and some thought is required to understand how to measure demand in aparticular organisation. This enables a check to be made on the effort, in terms of capability, time andother resources expended on particular projects, processes or services.At a more granular level, requirements match the importance to the business of the requestor orbeneficiary 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 thatdemand is not related to actual business need but to the organisation’s ability to be effective in makingits 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. Implementationmetrics are often based on the use of checklists to establish when particular acceptance criteria havebeen 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 apilot. The pilot for implementing the IRP should be designed to make sure that all parts of the processare involved, as well as a fair representation of stakeholders whilst, at the same time, making surethat 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 processbecomes generally adopted. This enables training in the process, documentation and tools to beimproved 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 isthat these are managed centrally. Ideally, creating a service design package for the IRP itself, keepingall 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, stepsmust be taken to ensure that it actually happens, and is targeted correctly at those who need it, whenthey 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 communicationsplans for all stakeholders at all stages of deployment, as well as a plan for exactly how the varioustools will integrate into the communications structure.With requirements management, this will go beyond simply communicating the process itself, how therequirements register works and the way in which the activities take place. The methods that theorganisation will use to communicate with stakeholders as part of requirements analysis will formpart of this documentation. The structure of UML diagrams, use-case diagrams, wire-framedemonstrations, user stories and the other techniques used in requirements definition, and welldescribed 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 ofthe various techniques. If, for example, an organisation finds that user stories are more effective atvalidating and generating requirements that match business needs than, for example, UML use-casediagrams, then the communications policy should be changed to train more people in the use of userstories as well as to update, and improve, the templates and advice given to make the use of thesemore 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 effectivelyduring the requirements process, so that a consistent and effective process can be shared and taught toeverybody. This is part of the service management strategy of having a service knowledgemanagement system that enables an organisation to make better decisions. In this case, the decisionswill 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. Whatwould conventionally be part of enterprise analysis will be kept here to be communicated to businessanalysts at the start of each cycle, and updated when it changes. This information would be acquiredthrough the business relationship management and service level management processes, as well asfrom 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 alignedto the goals outlined in Cobit5.

9.2.25.1 Corporate Governance

This part of governance involves making certain that corporate policy is translated into managementaction – in particular, by making certain that the process itself, as well as each requirement, ischecked 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 thebenefit of the company. The IRP ensures this by validating that each requirement is according tocorporate 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 operationalexcellence. It is part of, and drives, both SOA and Togaf architectural decisions. In part, the IRPassists with operational governance as it provides the means to track and measure exactly howstrategic 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 companyand producing the value required by the company stakeholders. This is ensured by the IRP because allrequirements are evaluated and validated against the corporate policy and, where appropriate, linkedto 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 corporatepolicy 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 thatcan 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 toproduce 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 arequirement 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 sourcesof 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 anddeployed service, or a service developed and deployed by a third party in response to a request forproposal (RFP).In either case, the end point of the process, a successful requirement, is the validated, workingsolution. 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 organisationexperiencing 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, therequirement will be raised in the CSI register to be addressed in the CSI improvement cycle. Thisgives 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 hasbeen properly designed for the organisation, according to corporate policy, with an appropriatecost/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 establishedby providing the correct level of usability for the stakeholders shown.The IRP keeps requirements in the requirements register for each stakeholder, as well as havingspecific requirements for particular solutions and services. This ensures that all stakeholders areidentified and linked to their requirements, and services. This holistic view is vital for effectivedelivery.The sources of requirement diagram (Figure 17 ) shows many possible sources for requirements andhow these requirements are captured in the IRP register and, when they become part of a solution, inthe SDP.

9.3.3 Triggers

To describe an activity, or set of activities, as a process, it is necessary for there to be specific inputsto the process. These inputs are referred to as triggers. A trigger is what gets a process started. Thespecific triggers for the IRP are:

• A new business requirement – it may become evident to the business that, because of a newdirection 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 innovationmight encourage new requirements to be developed directly

• Corporate strategy change, with a new strategy or strategic direction being a trigger forinnovative 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 isidentified as missing during a service level review. It could also be the result of a businessrelationship management discussion with the business, or from a business analyst as a result ofa discussion with users or customers

• Continual improvement – The ITIL continual improvement cycle will identify and prioritiseitems in the improvement register and schedule these for action. Some of these may include, oractually 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 couldenhance 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 otherinitiatives, that may be outside the scope of the current one

• Part of the requirements analysis or development cycle – it may become apparent asrequirements 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 ofrequirements. Requirements triggered in this way are dealt with by the alternative routethrough the process reserved for late requirements

• Merged requirements – often a number of requirements are elicited from different stakeholdersthat turn out to be different aspects of the same requirement. These can be merged into onerequirement that then becomes a new requirement. If this occurs late in the cycle, the laterequirements 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 requirementsroute.

9.3.4 Improvements

All processes can be improved. When deficiencies are identified these can be added to the continualimprovement register for consideration at the next improvement cycle. If approved, the improvementplan 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 qualityimprovement.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 areidentified, these can be prioritised and, where appropriate to business needs, acted upon to make theprocess or service more effective or more efficient when there is a business justification for doingso..The IRP will, at any time, have a number of improvements documented. These will be in thecorporate CSI register, but will also appear in the process documentation, showing their priority, costand, 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 organisationand 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 invalidating a requirement. The validation process uses the model, adapted for the organisation’sstakeholders, 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, userand 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 analystscall functionality. An invoicing system prints an invoice or sends it through e-mail, or presents awell-designed GUI to users. All this is evident and demonstrable in the final service and isdemonstrated to stakeholders during the ‘wire frame’, ‘story board’ or ‘use-case’ stage ofrequirements validation. It is an important part of the delivery of utility, but it is not the only part ofthe delivery.Many good solution developments fail to be excellent because they consider functionality to be theonly 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 aswarranty in service management) do not contribute to the functioning of the solution, when this is notthe 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 servicewas not there, not only would some other means have to be found to do what the business processrequires, but the business would have to spend time, money and use its assets to provide thisrequirement. 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 ispossible to keep your money at home. Not only does keeping large amounts of money at homeincrease your risk and the cost of your home security, but it erodes your peace of mind. You cannot becomfortable away from home for long because, in your absence, somebody might break in and youwould 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 abank 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 doesremove 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 andyour users well enough to know what constraints they have in doing business better. When you canidentify and understand those constraints, then you can provide services not just because they dosomething, but also because they enable your stakeholders to do more themselves. This veryimportant 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 itdoes it. The four aspects–availability, capacity, security and continuity–are recognised by ITIL.Warranty also depends on operability, supportability, maintainability, serviceability and the ability tomanage transitions.

9.3.7.1 Availability

Requirements must be established for the enterprise as a whole, as well as for specific plannedsolutions. To know what level of availability is appropriate–the higher the availability, the higher thecost–a trade-off is usually required. Design should make sure that an appropriate level can besupplied to the requirements, and that designs do not constrain the solution so that, if the businessrequires increased availability than originally planned, it does not require expensive re-design todeliver it.

9.3.7.2 Capacity

It is an important aspect of service management to balance the cost and risk of having either too muchor too little capacity to deliver a service. The design of a solution must include the ability to measurethe demand on the service so that capacity management can forecast future demand and takeappropriate 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 & needs9.3.7.3 Security

Service management concerns itself with security at the service level. Requirements managementneeds to concern itself with security with each requirement. The overall solution may be sound, but arequirement may weaken security in a subtle manner. To prevent this, all requirements, even laterequirements and highly technical requirements, must be analysed to make sure that any securityimplications 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 whichservices must be available and how they will be delivered. This may involve, for low priorityservices, 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 areunderstood in terms of their implication for continuity. It might seem, during the early stages ofdesigning a solution, that it will always be a low priority solution so it does not need to be designedfor 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 effectivecontinuity. If a requirement would make it impossible to recover a service or solution for some timeafter a disaster, it would be necessary to raise this requirement to the risk register, so that the servicecan be considered from that perspective, and a decision made on how to handle the requirement bothcost-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. Thebusiness 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 thecost of delivering the service, visible, so that high value/cost ratio services can be preserved asimportant assets and objects of further development investment, whilst low value/cost ratio servicescan 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. ITILsees 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 muchclearer to the business what is being achieved. The use of the term ‘non-functional requirements’ canbe confusing, seeming to be a statement that something negative requires investment. Warranty, on theother hand, has a positive association with risk-reduction that makes diagrams, such as thecontributors 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 riskaversion/appetite) availability, continuity, capacity and security. Crucially, this is associated with theend-to-end service, not just with the application, as tends to be the case with ‘non-functionalrequirements’.Utility, the way a service delivers value, is also recognised (as is warranty) as having twocomponents:

1. What it actually does–the technical workings of the service and the actual output of theapplication. This is how most technical people in IT generally understand the solution torequirements, particularly developers.

2. What it allows the business to do that it could not do previously. It removes constraints from abusiness or business unit that prevent it being effective. This is the way that the business, inparticular 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, warrantyand value, whilst also showing the different types and sources for utility requirements, making itexplicit that looking for requirements for a service is a superset of those for an application, as theserequirements involve suppliers, integration, as well as specific deliverables to enable the service tobe transitioned, operated, and supported. For effective delivery of value, it is vital that a service isunderstood in this wider context and that the requirements analysis is not simply limited to those forthe application.

9.3.8 Reporting

Whilst each solution will have its own reporting requirements, the IRP has some essential needs if itis 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 betweenorganisations, mainly because of a lack of clarity and a failure in communication. A process helpsenable clear communication. For example, the requirements register enables everybody involved withrequirements, 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 registeralso 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 seewhere the processes or sub-processes are breaking down in order to take action quickly. If, forexample, a large number of requirements emerge as late requirements, some few weeks before asolution is due to be transitioned into an operational service, then this presents a high risk to theorganisation. The reporting process must be designed so that this situation, or any similarly high-risksituation, 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 ofnot delaying the delivery of the solution, might seek to satisfy these requirements without properplanning 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 theresults of measurements made to the output of the process that are considered in both operationalmanagement 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 highpriority requirements, a metric or KPI is designed so that effective and timely measurement of theactual 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 thispublication.

9.3.10 Activities

The top-level description of the IRP describes the activities that take place in the process. Thesefollow the activities described in the BABOK, ITIL, and COBIT5. The activities fit into the processflow, 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 bebroken down into a set of procedures. Each can then be documented to describe how the work will bedone in more detail than simply the description of the activity. For each procedure, a RACI matrix canbe 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 workinstructions. They are used in training and when producing automated workflow. They are alsoimportant to ensure that, during design the activities and procedures are realistically described andwill work in practice. Producing work instructions is also a valuable method of uncovering specificdetailed 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 achievea successful process. These particular enablers will exist within the corporate culture and strategy. Astrongly innovative company will, for example, have many enabling characteristics, including beingquick 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 managementdrives the service management process of capacity management. Demand management develops anunderstanding of patterns of business activity.It would be wise to include demand and capacity management in the planning for the design anddeployment of a process, in order to gain an understanding of what level of resources is likely to berequired (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 resourcesfrom IT will include business analysts, service management professionals and developmentprofessionals. It will be necessary to have support to get time from other parts of the organisation, asrequired, 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 aftera 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 thefollowing 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 managementsystem (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. Inparticular, for the IRP, this would involve making sure that authorisations are automatic as areescalations 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 theprocess along with their specific activities and responsibilities, along with the authorities (inparticular the access rights to various stages of the requirements lifecycle).The Cobit5 guidance includes some useful RACI matrices for the two processes that it identifiesBAI2, BAI3. These are an excellent starting point for developing the specific RACI matrix for anorganisation deploying this process.

9.4.7 Knowledge

The SKMS is a key part of a service management organisation’s operation. The CSI register and riskregister are already likely to be linked to each other within the SKMS. From the point of view ofknowledge management, the new requirements register and process inputs and outputs will have to belinked into the SKMS. If there is not an existing SKMS, these registers will have to be developedtogether.It is likely that development will need to be included in discussions to ensure that the tools they usecan 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 purchasedfrom third parties, then a period of consultation with your main suppliers will be required to ensurethat 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 thatindividuals 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 forthe 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 ofrequirements themselves, the solution development process, as well as service managementprinciples. Before deploying this as a process, it would be important to produce a report outlining thecurrent 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 canbe established and a funded plan developed to address the plan by building the appropriatecapabilities.

9.5 Sources of Requirements (inputs to the

process)There are many sources of requirements. Stakeholder analysis is acknowledged as a vital part ofrequirements 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 theidentification, design, transition and operation of services. These are a rich and structured source ofguidance. These sources form interfaces to the requirements analysis process and also, over time, areliable, 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 vitalinput to the whole requirements process.

9.7 Stakeholder Analysis

Service strategy produces a service portfolio that links current and future business needs, in terms ofstrategic market spaces, to be addressed and the stakeholders involved with each of these. Thisstakeholder analysis can either be an analysis performed for the purpose of producing an IT strategyor can be part of a wider management of value programme that would produce a corporate investmentportfolio, with the service portfolio forming part of that (as described in the book Management ofValue).In either case, for each new initiative–a new service, a new application as part of a service, or theupgrade of an existing service–it is necessary to understand who the stakeholders are. It is importantto include them in the communications plan, so that the elicitation, analysis and verification of therequirements 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 theminformed, 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 inwireframe 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 communicationsplan, managed by a project manager or administrator to ensure that all planned communications takeplace.

9.9 Requirements Design & Engineering

The ITIL Service Design book describes methods of requirement engineering. Before businessanalysts produced the BABOK framework, requirements were designed and engineered in manydifferent circumstances, well before computers were invented, and requirements were collated andmanaged for physical engineering projects such as bridges or steamships.The IRP unites the advice given on managing the design, analysis and engineering of requirements inCobit5, ITIL and the BABOK in order to give one single process that manages the entire lifecycle ofall requirements, not just across single projects or programmes, but across the entire enterprise orcorporation.

9.9.1 Requirements Numbering

A numbering scheme must be developed as part of the IRP in order to ensure that requirements have aunique 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 thatrequirements are tracked beyond that, through the life of the solution or service that satisfies therequirements. 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 futureengagements.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 inAppendix A.

9.9.3 Analysing

The job of analysing requirements involves looking at the exact wording of the requirement to ensurethat it is clear to both the business and technical audiences. It also involves checking the requirementagainst 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 requirementsthat form the specification of the service is addressed by the solution. This is not simply testing thatthe solution functions as it should, but that it does what it has been designed to do. If any requirementis not met, it is included in the validation and evaluation report and, if significant, is raised to the riskregister.

9.10 Readiness Assessment

A readiness assessment examines the current capabilities of the organisation, in terms of the resourcesneeded to deploy and manage the solution, as well as the level of experience and training of both thebusiness 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 forthe solution once it becomes operational.

9.11 Solution Definition & Selection

Once all the requirements have been understood, organised, prioritised andauthorised, it is possible to build or purchase a solution.Some solutions may be new business processes, new hardware or even organisationalchange. Often, though, solutions will involve software development, and whatfollows 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 preferredmethodology to produce the software solution. If the solution is to be provided by a third-party, therequirements will form the core of the RFP with which vendors will need to comply for theirproposed solution to be considered.The particular methods used by development are beyond the scope of this book, but may involvewaterfall, agile, and scrum, among others.The Business CaseBusiness cases are prepared at several stages. Firstly, when a new solution or service is proposed tosatisfy a set of requirements, the business case provides the organisation with motivation to invest inanalysing the proposal. In terms of the service portfolio, this occurs at the ‘define’ phase of theservice lifecycle. The acceptance of the business case at this stage, allows the solution to be analysedand, 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 tojustify a project to build a new service.This enhancement of the business case includes the costs and risks involved, relativeto the business value anticipated from the solution, and is used by senior managementor the board of directors to decide whether to invest in making this service (or servicechange) a strategic addition to the service portfolio. The decision to invest, along withthe budget approval, moves the service to the status ‘chartered’.Useful templates for building a business case can be found in the PRINCE2 project managementframework documents.

9.12 Solution Evaluation Report

The solution evaluation report is the basis for the service delivery review. It is a summary of theprogress 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 thathas lessons that can be learned to improve future deliveries. The solution delivery reviewinvestigates 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.

V

10. Tool Requirements

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

arious technical tools are required to manage the lifecycle of requirements, services andapplications. 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 theform 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 beadequate 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 thatare 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 ImplementingService Management Tools provides comprehensive and valuable advice on selecting tools to fitrequirements.

10.1 Communications Plan Workflow

The communications plan is a workflow definition that indicates the type of communication that needsto be developed for each audience to achieve particular objectives at specific milestones. Aworkflow 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 allrisks 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 largeorganisation, a multi-tiered repository needs to be established so that risks can be identified andmanaged within the domain in which they present a threat (IT risks, for example, in the IT part of therisk 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 linkedto the main corporate risk register so that its implications can be considered and an appropriateresponse 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 thiswere 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 forthe 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 centrallocation. 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, itworks 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 Mess–CIO Magazine 1st Jan 2006 -Christopher Lindquist

11. Bibliography

Brooks, Peter (2006). Metrics for IT Service Management. Van Haren Publishing.ISBN: 10: 9077212698 ISBN: 13: 978-9077212691Brooks, Peter (2012). Metrics for IT Service Management: Designing for ITIL. VanHaren Publishing. ISBN: 9789087536480Cabinet Office (Great Britain) (2010). Management of Value. TSO (The StationeryOffice). ISBN: 9780113312764Cabinet Office (Great Britain) (2011). Managing Successful Programs. TSO (TheStationery Office). ISBN: 9780113313273Cabinet Office (Great Britain) (2002). Managing Successful Projects withPRINCE2, 3rd ed. TSO (The Stationery Office). ISBN: 13: 978-0113308910Cabinet Office (Great Britain) (2011). ITIL Continual Service Improvement. TSO(The Cabinet Office). ISBN: 9780113313082Cabinet Office (Great Britain) (2011). ITIL Service Design. TSO (The StationeryOffice). ISBN: 9780113313051Cabinet Office (Great Britain) (2011). ITIL Service Operation. TSO (The StationeryOffice). ISBN: 9780113313075Cabinet Office (Great Britain) (2011). ITIL Service Strategy. TSO (The StationeryOffice). ISBN: 9780113313044Cabinet Office (Great Britain) (2011). ITIL Service Transition. TSO (The StationeryOffice). ISBN: 9780113313068Cabinet Office (Great Britain) (2011). Management of Portfolios. TSO (TheStationery Office). ISBN: 9780113312948Cabinet Office (Great Britain) (2011). Management of Risk: Guidance forPractitioners, 3rd ed. TSO (The Stationery Office). ISBN: 9780113312740Falkowitz, 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 9780117069039International Institute of Business Analysis (2009). Brennan, K. (ed.) A Guide tothe Business Analysis Body of Knowledge® (BABOK® Guide). 2nd ed. IIBA. ISBN-10: 0981129218 ISBN-13: 978-0981129211ISACA (2012). COBIT5: Enabling Processes. ISACA. ISBN: 9781604202397

ISACA (2012). COBIT5: Implementation. ISACA. ISBN: 9781604202380

T

12. Appendix A–Requirements Register

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

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 theevaluation box (in red) showing that this is a high value requirement, with low cost and a high risk (inthis 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 clickingon the calendar would show the exact detail of the milestones. In the mock-up the calendar shows theyear 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 therequirement owner’s recent comments below it.Stakeholders can review the wireframe mock-up of how the application will work by clicking on thelink at the top left.

We can see that this requirement is being used by four separate development projects – three are partof the ITSM programme (adding an audit log to the risk register, the CSI repository and therequirements register [this application]). The fourth is a requirement to add the same function to thesales system. This shows part of the value of the unified register – re-use of one standardrequirement, 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 minormatters, to the project or programme risk register – clicking on the link will show which. Provisionwill need to be made in these registers to move risks depending on priority or in response toescalation requests)

• The RACI matrix for the requirement (the requirement owner is shown at the top, but all otherstakeholders, as well as detail of the planned activities will be shown in the RACI matrix – anumber of requirements are likely to share one RACI matrix)

• The SDP(s) for this requirement. In this particular case, we would expect to find thisrequirement linking to the SDP for the three ITSM services, as well as to the SDP for the salessystem

• The warranty requirements – when this becomes a live part of a solution, the warrantyrequirements will be part of the service level package, containing the SLAs for the service toparticular customers. At the moment, this defines the minimum service levels expected of thesolution, based on corporate criteria and particular SLRs for the four services

• The CSI register, which will contain links to proposed service improvements related to thisrequirement for an audit log

• The audit log itself. Since the requirement is for an audit log, we would expect that, at themoment, this is probably just a log file, which has been deemed not to be adequate – probablyfor 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 commenton 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 theyallow searching for requirements that are owned by J. Smith (for which J.Smith is ‘accountable’ inRACI 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 theapplication 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 withoutchanges 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 ofmisspelt hashtags).

T

13. Appendix B – Links to COBIT5

he IRP is designed to allow an organisation to meet its IT governance requirements, as defined inCOBIT5. 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 ReferenceGuide from ISACA on pages 129 and 133.When designing a specific implementation of the IRP, it is important to ensure that these broad auditobjectives, in terms of goals and metrics, are satisfied.The goals and metrics of these two processes are:

13.1 Goals & Metrics13.1.1 BAI02

Identify solutions and analyse requirements before acquisition or creation to ensure that they arealigned with enterprise strategic requirements covering business processes, applications, information,data, infrastructure and services. Co-ordinate with affected stakeholders the review of feasibleoptions including relative costs and benefits, risk analysis, and approval of requirements andproposed solutions.

Alignment of IT and business strategy.

Percentage of enterprise strategic goals and requirements supported by ITstrategic goals.Level of stakeholder satisfaction with scope of the planned portfolio ofprogrammes and services.Percentage of IT value drivers mapped to business value drivers

Delivery of IT services in line with business requirements.

Number of business disruptions due to IT service incidentsPercentage of business stakeholders satisfied that IT service deliverymeets agreed service levels.Percentage of users satisfied with the quality of IT service delivery.

Enablement and support of business processes by integratingapplications and technology into business processes.

Number of business processing incidents caused by technologyintegration errors.Number of business process changes that need to be delayed or reworkedbecause of technology integration issuesNumber of IT-enabled business programmes delayed or incurring additionalcost due to technology integration issues.Number of applications or critical infrastructures operating in silos and notintegrated.

Business functional and technical requirements reflect enterprise needsand expectations.

Percentage of requirements reworked due to misalignment with enterpriseneeds and expectationsLevel of stakeholder satisfaction with requirements.

The proposed solution satisfies business functional, technical andcompliance requirements. Percentage of requirements satisfied by proposed solution.

Risk associated with the requirements has been addressed in theproposed solution.

Number of incidents not identified as risks.Percentage of risks unsuccessfully mitigated.

Requirements and proposed solutions meet business case objectives(value expected and likely costs).

Percentage of business case objectives met by proposed solution.Percentage of stakeholders not approving solution in relation to businesscase.

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. Manageconfiguration, test preparation, testing, requirements management and maintenance of businessprocesses, applications, information/data, infrastructure and services.

Delivery of IT services in line with business requirements.

Number of business disruptions due to IT service incidents.Percentage of business stakeholders satisfied that IT servicedelivery meets agreed service levels.Percentage of users satisfied with the quality of IT servicedelivery.

The solution design, including relevant components, meets enterprise needs, alignswith standards and addresses all identified risk.

Number of reworked solution designs due to misalignmentwith requirements.Time taken to agree that design deliverable has metrequirements

The solution conforms to the design, is in accordance with organisational standards,and has appropriate control, security and auditability.

Number of solution exceptions to design noted during stagereviews.

The solution is of acceptable quality and has been successfully tested.Number of errors found during testing.Time and effort to complete tests.

Approved changes to requirements are correctly incorporated into the solution. Number of tracked approved changes that generate newerrors.

Maintenance activities successfully address business and technological needs. Number of demands for maintenance that go unsatisfied.

I

14. Appendix C–An Example of a Code ofEthics

SACA, the organisation that produces the Cobit guidance, has this as its ethical code of conduct formembers:

ISACA sets forth this Code of Professional Ethics to guide the professional andpersonal conduct ofmembers 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 andprocedures for the effective governance and management of enterprise information systemsand technology, including: audit, control, security and risk management.

2. Perform their duties with objectivity, due diligence and professional care, in accordance withprofessional standards.

3. Serve in the interest of stakeholders in a lawful manner, while maintaining high standards ofconduct and character, and not discrediting the profession or the Association.

4. Maintain the privacy and confidentiality of information obtained in the course of theiractivities unless disclosure is required by legal authority. Such information shall not be usedfor personal benefit or released to inappropriate parties.

5. Maintain competency in their respective fields and agree to undertake only those activitiesthey 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 factsknown to them.

7. Support the professional education of stakeholders in enhancing their understanding of thegovernance 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’sor certification holder’s conduct and, ultimately, in disciplinary measures.

T

15. Appendix D–Mapping BABOK to ITIL& IRP

he existing advice in both the BABOK and ITIL 2011 books is valuable, and valid; however, itcan 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 – ServiceStrategy, SD – Service Design, ST – Service Transition, SO – Service Operation, CSI – ContinualService Improvement.

Ref Activity Map to ITIL Map to IRP2 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

6.3 Specify and Model Requirements SD10. Formal Specification11. 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

acceptancecriteria

A collection of requirements (each acceptance criterion is a requirement, often one of warranty), often in the form of a checklist, thatdefine what shall be demonstrated to be part of a solution before it can formally be accepted.

accountablePart of a RACI (Responsible, Accountable, Consulted, Informed) matrix definition. It means the person or function that will beaccorded credit for success or blame for failure for the activity. This is a management accountability and does not necessarily involveactually doing the work.

activities The top level description of things that are to be done in a process. An activity is described by one or more procedures and theprocedure detail is contained in the work instructions.

agile A way of approaching development or project work with flexibility, designed to avoid the perception of bureaucracy seen in theconventional waterfall method.

approval The stage in the requirements lifecycle that indicates the official management sanction for a service.

architecture (ITIL Service Design) The structure of a system or IT service, including the relationships of components to each other and to theenvironment they are in. Architecture also includes the standards and guidelines that guide the design and evolution of the system.

assessment Inspection and analysis to check whether a standard or set of guidelines is being followed, that records are accurate, or thatefficiency and effectiveness targets are being met. See also audit.

asset(ITIL Service Strategy) Any resource or capability. The assets of a service provider include anything that could contribute to thedelivery 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.

assumptions The explicit statement of beliefs or understandings that, if not stated directly, can be dangerous because they may not be warrantedbeliefs or shared understandings.

audit logA central repository of events that are relevant to good governance. Such a repository is available to authorised audit staff toinvestigate to ensure proper policy and procedure is being followed. Audit logs need to be write-only and effectively secured againstunauthorised modification by anybody

audit trail The transaction records, kept in an audit log, that enables the component parts of a transaction, or series of transactions, to befollowed 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.

availability

(ITIL Service Design) Ability of an IT service or other configuration item to perform its agreed function when required. Availability isdetermined by reliability, maintainability, serviceability, performance and security. Availability is usually calculated as a percentage.This calculation is often based on agreed service time and downtime. It is best practice to calculate availability of an IT service usingmeasurements of the business output.

BABOK The Business Analyst Body of Knowledge, a book produced by the IIBA (International Institute of Business Analysis) to describethe activities involved in the job of Business Analysis.

benefits 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 ofaction, service, tool or process being deployed.

boardGenerally, in a commercial company, the Board of Directors of the company. This is the most senior decision making body in acompany and is accountable for setting the policy and strategy that will govern the companies activities. In a non-commercialcompany, this might be the trustees, the senate or other body that has a similar accountability for this.

BRM business relationship manager

budget 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 alsobudgeting; planning.

build(ITIL Service Transition) The activity of assembling a number of configuration items to create part of an IT service. The term is alsoused to refer to a release that is authorized for distribution ‰ÛÒ for example, server build or laptop build. See also configurationbaseline.

businessanalysis

The activity involved in understanding the requirements of a business, documenting them in a formal fashion and working withbusiness stakeholders to enable the development of applications or the deployment of services or other means to enable a solutionto the equirements to be provided according to business priorities far required value, cost and time of delivery and risk.

business case (ITIL Service Strategy) Justification for a significant item of expenditure. The business case includes information about costs,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.

businessgovernance 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’.

businessprocesses Processes that run in the business domain, such as invoicing, manufacturing, sales, marketing and so forth.

businessrelationshipmanagement

(ITIL Service Strategy) The process responsible for maintaining a positive relationship with customers. Business relationshipmanagement identifies customer needs and ensures that the service provider is able to meet these needs with an appropriatecatalogue of services. This process has strong links with service level management.

businessrequirements

Requirements for the efficient and effective operation of the business. A business requirement that is a matter of efficiency may notbe an essential need, but would still remain a ‘business requirement’

business risk A risk, in this sense, is something unexpected that could occur that would influence the business policy, strategy, tactics oroperation. A risk need not be a negative thing, but is something that should be taken account of for good governance.

business valueValue has to be defined for each business in terms of its policy, strategy and operating model. Something delivers value to thebusiness if it enables, maintains or enhances the business’ position financially, or in terms of market share, share price, reputation orany other relevant measure of a business benefit.

BYOD Bring Your Own Device the trend for employees to wish to use their own equipment, such as tablets or mobile ‘phones, for businessactivities.

Cabinet Office The organisation that, at the time of writing, owns the copyright of the best practice suite of publications, including ITIL, M_o_R,MoV

capability (ITIL Service Strategy) The ability of an organization, person, process, application, IT service or other configuration item to carry outan activity. Capabilities are intangible assets of an organization. See also resource.

capacity (ITIL Service Design) The maximum throughput that a configuration item or IT service can deliver. For some types of CI, capacity maybe the size or volume ‰ÛÒ for example, a disk drive.

catalogue A central repository, usually part of the SKMS (Service Knowledge Management System) that enables controlled access toinformation about business assets such as services, components, requirements.

categoryA named group of things that have something in common. Categories are used to group similar things together. For example, costtypes are used to group similar types of cost. Incident categories are used to group similar types of incident, while CI types are usedto group similar types of configuration item.

certification Issuing a certificate to confirm compliance to a standard. Certification includes a formal audit by an independent and accredited body.The term is also used to mean awarding a certificate to provide evidence that a person has achieved a qualification.

changemanagement

(ITIL Service Transition) The process responsible for controlling the lifecycle of all changes, enabling beneficial changes to be madewith 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

COBIT(ITIL Continual Service Improvement) Control OBjectives for Information and related Technology (COBIT) provides guidance andbest 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

communicationsplan

A plan forming part of a programme, project or other engagement that details what should be communicated to whom in which formatto 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.

constraints Limits to a possible solution space. Price, for example, limits solutions to those that are affordable because they are below a definedcorporate maximum. There can be many sorts of constraints, including legal, ethical, physical and technology options.

continualserviceimprovement

One of the core ITIL books

continuity 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 thecontinuity plan.

controlA means of managing a risk, ensuring that a business objective is achieved or that a process is followed. Examples of control includepolicies, procedures, roles, RAID, door locks etc. A control is sometimes called a countermeasure or safeguard. Control also means tomanage the utilization or behaviour of a configuration item, system or IT service.

control section The portion of the definition of a process that defines how the process will be subject to management control and thus can beaudited 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

costThe amount of money spent on a specific activity, IT service or business unit. Costs consist of real cost (money), notional cost (suchas people‰Ûªs time) and depreciation.

criteria The plural of ‘Criterion’, a list of tests that must be applied before something is judged acceptable. For example, a set of ‘acceptancecriteria’ for a new service will list, often as a checklist, what has to be in place before a service can be accepted

critical successfactors

Abbreviated to CSF. These are factors determined by the business for a service, project or programme that are essential for businesssuccess. If a CSF is not achieved, the business will fail. These are usually difficult to measure directly, so a number of KeyPerformance Indicators (KPIs) are developed as proxies for the measure itself.

CSF critical success factor

CSI register (ITIL Continual Service Improvement) A database or structured document used to record and manage improvement opportunitiesthroughout their lifecycle.

customerSomeone who buys goods or services. The customer of an IT service provider is the person or group who defines and agrees theservice level targets. The term is also sometimes used informally to mean user , for example, ‘This is a customer-focusedorganization.’

demandmanagement

(ITIL Service Design) (ITIL Service Strategy) The process responsible for understanding, anticipating and influencing customerdemand for services. Demand management works with capacity management to ensure that the service provider has sufficientcapacity to meet the required demand. At a strategic level, demand management can involve analysis of patterns of business activityand user profiles, while at a tactical level, it can involve the use of differential charging to encourage customers to use IT services atless busy times, or require short- term activities to respond to unexpected demand or the failure of a configuration item.

design (ITIL Service Design) An activity or process that identifies requirements and then defines a solution that is able to meet theserequirements. See also service design.

development(ITIL Service Design) The process responsible for creating or modifying an IT service or application ready for subsequent releaseand deployment. Development is also used to mean the role or function that carries out development work. This process is notdescribed in detail within the core ITIL publications.

early lifesupport

This is a process defined by ITIL in the Service Transition book. It ensures that a new service does not become operational until allthe 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

efficient Something achieves its goals with an optimal energy, effort and cost–measured by metrics that look at the processes used to achieveoutput

elicitationThis is the general term used for finding out what requirements there are. It can involve the use of many techniques, from surveys toone-to-one interviews along with many different workshop techniques. The aim is to uncover the genuine needs (requirements) ofthe organisation and distinguish these from things that are simply ‘nice to have’ or ‘wants’, rather than ‘needs’.

enterpriseanalysis

This is the first stage of Business Analysis identified by the BABOK, it is similar to the Service Strategy stage of ITIL and involvesunderstanding, in a holistic sense, the vision, goals and objectives of the organisation at a particular time. The ITIL Continual ServiceImprovement seven step process starts with doing a brief enterprise analysis.

enterprisearchitecture

A methodical description of how a business operates as an organisation, including the business processes, services and everythingthat supports them. ITIL Service Design recommends using TOGAF (The Open Group Architecture Framework) to build an enterprisearchitecture–in turn, TOGAF recommends something like the IRP (Integrated Requirements Process) with a requirements register tobe at the heart of the enterprise architecture.

error “(ITIL Service Operation) A design flaw or malfunction that causes a failure of one or more IT services or other configuration items. Amistake made by a person or a faulty process that impacts a configuration item is also an error.

evaluation

Evaluation is distinguished from testing because, rather than simply checking that a solution works, it checks that the solutionactually matches the original requirements. ITIL Service Transition includes a process called ‘Change Evaluation’ that allows a longer-term higher-level strategic view of a change to be taken to make sure that it makes good business sense. BABOK sees evaluation asincluding an element of continuous improvement.

extremeLike ‘agile’, ‘extreme’ is a term used to refer to different project or development methods than the traditional waterfall method. Theseinvolve the idea of rapid prototyping and dynamic development based on the discovery of requirements during design anddevelopment, rather than before.

framework

The underlying structor supporting an activity. ITIL is, for example, a framework that helps support a company wishing to develop anIT Service Management competency. It is distinguished from a ‘standard’ by not having a set of auditable requirements that can beused to determine if it has been implemented or not. A framework is much looser than a standard and aims to give generally usefulguidance.

function

“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:- An intended purpose of a configuration item, person, team, process or IT service. For example, one function of an email servicemay 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.”””

governance Ensures that policies and strategy are actually implemented, and that required processes are correctly followed. Governance includesdefining roles and responsibilities, measuring and reporting, and taking actions to resolve any issues identified.

hashtagsA hashtag is a means of marking a category of something. It’s known as a ‘hashtag’ because it is usually preceeded by the hashcharacter ‘#’. 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.

impact (ITIL Service Operation) (ITIL Service Transition) A measure of the effect of an incident, problem or change on business processes.Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.

incident (ITIL Service Operation) An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of aconfiguration 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 Processmanager The manager(s) responsible for ensuring that the IRP is deployed and managed from day to day according to business requirements

IRP processowner The person accountable for ensuring that the IRP operates and is measured according to its design requirements

IRP register The centralised repository that contains all corporate requirements, treated as assets, and links to the workflow tool(s) that enable theprocess to be operated and measured.

ISACAAs an independent, nonprofit, global association, ISACA engages in the development, adoption and use of globally accepted,industry-leading knowledge and practices for information systems and is responsible for the development of the IT audit guidancedescribed in Cobit.

ITIL

A set of best-practice publications for IT service management. Owned by the Cabinet Office (part of HM Government), ITIL givesguidance on the provision of quality IT services and the processes, functions and other capabilities needed to support them. TheITIL framework is based on a service lifecycle and consists of five lifecycle stages (service strategy, service design, service transition,service operation and continual service improvement), each of which has its own supporting publication. There is also a set ofcomplementary ITIL publications providing guidance specific to industry sectors, organization types, operating models andtechnology architectures. See www.itil-officialsite. com for more information.

ITSM IT service management

Kano The Kano model, named after its inventor, Professor Noriaki Kano, is a method for aligning customer satisfaction with productdevelopment.

keyperformanceindicator (KPI)

(ITIL Continual Service Improvement) (ITIL Service Design) A metric that is used to help manage an IT service, process, plan, projector other activity. Key performance indicators are used to measure the achievement of critical success factors. Many metrics may bemeasured, but only the most important of these are defined as key performance indicators and used to actively manage and report onthe process, IT service or activity. They should be selected to ensure that efficiency, effectiveness and cost effectiveness are allmanaged.

knowledgemanagement

(ITIL Service Transition) The process responsible for sharing perspectives, ideas, experience and information, and for ensuring thatthese are available in the right place and at the right time. The knowledge management process enables informed decisions, andimproves efficiency by reducing the need to rediscover knowledge. See also Data-to-Information-to-Knowledge- to-Wisdom; serviceknowledge management system.

KPI key performance indicator

laterequirements

requirements that arrive after the business case has been accepted. These requirements do not form part of the business case, somust be carefully documented and approved only as extensions to the business case once the value they bring has been understoodand the cost and risk of including them has been documented with mitigation to these risks agreed.

lifecyclerequirement

These are service requirements as identified by different stages of the ITIL lifecycle. For example, Transition Requirements are thoserequirements that concern processes in the ITIL Service Transition book, such as change, release, knowledge, change evaluation andso forth.

logged

managementrequirements

These are requirements that reflect management needs, either at an organisation level, or those needed to manage a particular serviceor application.

managementsystem

The framework of policy, processes, functions, standards, guidelines and tools that ensures an organization or part of an organizationcan achieve its objectives. This term is also used with a smaller scope to support a specific process or activity: for example, an eventmanagement system or risk management system. See also system.

metric (ITIL Continual Service Improvement) Something that is measured and reported to help manage a process, IT service or activity. Seealso key performance indicator.

mock-upThis is one way of communicating requirements back to stakeholders–the mock-up is a type of model that shows how a service couldappear when released. It helps stakeholders visualise how the service or applicaiton will work so they can make suggestions forimprovements. 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.

monitoring (ITIL Service Operation) Repeated observation of a configuration item, IT service or process to detect events and to ensure that thecurrent status is known.

organisation

requirements These are requirements that are specific to a particular organisation, or type of organisation.

pilot (ITIL Service Transition) A limited deployment of an IT service, a release or a process to the live environment. A pilot is used toreduce risk and to gain user feedback and acceptance. See also change evaluation; test.

plan A detailed proposal that describes the activities and resources needed to achieve an objective ‰ÛÒ for example, a plan to implementa 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

policy Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent andappropriate development and implementation of processes, standards, roles, activities, IT infrastructure etc.

policy andstrategy

Strategy is the long term plan the organisation has to achieve its goals, the policy of the organisation is the means by which it willachieve this strategy.

policyrequirements Requirements that stem directly from corporate, or enterprise, or IT, policy–required for good governance

portfolioA centralised, formal collection of items to be managed together. A portfolio is an investment decision instrument that allows differentthings to be compared in terms of their cost, return, urgency and impact in order to make investment decisions objective andtransparent. Examples are: Investment Portfolio, Project Portfolio, Service Portfolio, Application Portfolio

priority(ITIL Service Operation) (ITIL Service Transition) A category used to identify the relative importance of an incident, problem orchange. Priority is based on impact and urgency, and is used to identify required times for actions to be taken. For example, theservice level agreement may state that Priority 2 incidents must be resolved within 12 hours.

problem (ITIL Service Operation) A cause of one or more incidents. The cause is not usually known at the time a problem record is created,and the problem management process is responsible for further investigation.

problemstatements

A formal summary of the business ‘problem’ that a business case is intended to solve. This use of ‘problem’ is different from the ITILusage and does not mean an error, or something that has gone wrong. Rather, it means strategic business issue or top levelrequirement that requires a solution to deliver value to the business.

procedure A document containing steps that specify how to achieve an activity. Procedures are defined as part of processes. See also workinstruction.

processA structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns theminto defined outputs. It may include any of the roles, responsibilities, tools and management controls required to reliably deliver theoutputs. A process may define policies, standards, guidelines, activities and work instructions if they are needed.

processmanagere

A role responsible for the operational management of a process. The process manager’s responsibilities include planning andcoordination of all activities required to carry out, monitor and report on the process. There may be several process managers for oneprocess. For example, regional change managers or IT service continuity managers for each data centre. The process manager role isoften assigned to the person who carries out the process owner role, but the two roles may be separate in larger organizations.

process ownerThe person who is held accountable for ensuring that a process is fit for purpose. The process owner’ responsibilities includesponsorship, design, change management and continual improvement of the process and its metrics. This role can be assigned to thesame person who carries out the process manager role, but the two roles may be separate in larger organizations.

processrequirements

programme A number of projects and activities that are planned and managed together to achieve an overall set of related objectives and otheroutcomes.

project

A temporary organization, with people and other assets, that is required to achieve an objective or other outcome. Each project has alifecycle that typically includes initiation, planning, execution, and closure. Projects are usually managed using a formal methodologysuch as PRojects IN Controlled Environments (PRINCE2) or the Project Management Body of Knowledge (PMBOK). See alsocharter; project management office; project portfolio.

projectmanagement

The formal management of an identified project. Project management uses a number of frameworks, well known are PRINCE2 andPMBOK. The Project Manager is accountable for managing the life of a project from the sign-off of the Business Case until the finalacceptance sign-off by the customer. The responsibility of the Project Manager is to ensure that the project is completed within timeand budget to deliver the requirements as defined and agreed.

prototypeA working model of a solution produced to give an impression of how the service will appear when it has been developed fully. It isintended to help stakeholders, particularly customers and users, to spot potential design errors or to identify new, or previouslyunsatisfied, requirements.

published

qualityThe ability of a product, service or process to provide the intended value. For example, a hardware component can be considered tobe of high quality if it performs as expected and delivers the required reliability. Process quality also requires an ability to monitoreffectiveness and efficiency, and to improve them if necessary. See also quality management system.

RACI matrix A responsibility matrix used for identifying the owners of activities. The acronym stands for ‘Responsible’, ‘Accountable’,‘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 ITservice often includes recovering data to a known consistent state. After recovery, further steps may be needed before the IT servicecan 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.

repositoryA generic term for an information store. A repository might be a database, a document management system, a file system or someother electronic means of keeping together similar information. The word is usually used to avoid commitment to a particulartechnological implementation.

requirement (ITIL Service Design) A formal statement of what is needed – for example, a service level requirement, a project requirement or therequired deliverables for a process.

requirementsanalysis

The work done to refine requirements after the initial elicitation that involves removing or merging duplicates, splitting complexrequirements into simple ones and ensuring that they are stated clearly, unambiguously and consistently.

requirementselicitation

The stage of the integrated requirements process when stakeholders are asked, using various techniques, to assist by giving theirview of what requirements they will have for a proposed service, system, application, process or other solution.

requirementsengineering

A term given to the requirements process emphasising the need for rigour and an engineering-type approach to gathering andmanaging requirements.

requirementslifecycle

The stages that a requirement goes through from when it is first identified until it is finally embodied in a solution or ceases tobecome required by an organisation.

requirementsprocess The formal process governing the activities, controls and measures required to manage requirements

requirementsregister

A central repository of all requirements of an organisation, treated as organisational assets, so that they are controlled, secure,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.

responsibilityThe formal decision that a person or function will carry out a particular activity and be answerable for their work in the activity.Contrasted to ‘accountability’ that involves the party being answerable to ‘give account’ for the reasons for success or failure of anactivity, but not necessarily involved in doing the work required.

retired The final stage of a service before it is decommissioned. A retired service may still be used by one or more customers, but newcustomers or users are not encouraged as the service will shortly be decommissioned and replaced.

reuse An economic aim of Service Management and the Integrated Requirements Process is to provide good governance of corporateassets by, wherever pragmatically possible, re-using these assets or components of them.

reviewAn evaluation of a change, problem, process, project etc. Reviews are typically carried out at predefined points in the lifecycle, andespecially after closure. The purpose of a review is to ensure that all deliverables have been provided, and to identify opportunitiesfor improvement. See also change evaluation; post-implementation review.

RFC request for change

riskA possible event that could cause harm or loss, or affect the ability to achieve objectives. A risk is measured by the probability of athreat, the vulnerability of the asset to that threat, and the impact it would have if it occurred. Risk can also be defined as uncertaintyof 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.

roleA set of responsibilities, activities and authorities assigned to a person or team. A role is defined in a process or function. One personor team may have multiple roles ‰ÛÒ for example, the roles of configuration manager and change manager may be carried out by asingle person. Role is also used to describe the purpose of something or what it is used for.

scopeThe boundary or extent to which a process, procedure, certification, contract etc. applies. For example, the scope of changemanagement may include all live IT services and related configuration items; the scope of an ISO/IEC 20000 certificate may include allIT services delivered out of a named data centre.

SDP service design package

security See information security management.

serviceA means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costsand risks. The term ‰Û÷service‰Ûª is sometimes used as a synonym for core service, IT service or service package. See alsoutility; warranty.

service design

(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 supportedenvironments. Service design includes the following processes: design coordination, service catalogue management, service levelmanagement, 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 takeplace across multiple stages of the service lifecycle. See also design.

service designpackage

The set of documents that accompanies a service from its becoming ‘Chargered’ until it is decommissioned that describes all designaspects of the service. The SDP is attached to the Service Portfolio and links to the service itself, whilst also linking to those

requirements it satisfies.

service level Measured and reported achievement against one or more service level targets. The term is sometimes used informally to mean servicelevel target.

service lifecycleAn approach to IT service management that emphasizes the importance of coordination and control across the various functions,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.

servicemanagement A set of specialized organizational capabilities for providing value to customers in the form of services.

servicemanagementlifecycle

See service lifecycle.

serviceoperation

(ITIL Service Operation) A stage in the lifecycle of a service. Service operation coordinates and carries out the activities andprocesses required to deliver and manage services at agreed levels to business users and customers. Service operation also managesthe technology that is used to deliver and support services. Service operation includes the following processes: event management,incident management, request fulfilment, problem management, and access management. Service operation also includes thefollowing functions: service desk, technical management, IT operations management, and application management. Although theseprocesses and functions are associated with service operation, most processes and functions have activities that take place acrossmultiple stages of the service lifecycle. See also operation.

service owner(ITIL Service Strategy) A role responsible for managing one or more services throughout their entire lifecycle. Service owners areinstrumental in the development of service strategy and are responsible for the content of the service portfolio. See also businessrelationship management.

service portfolio(ITIL Service Strategy) The complete set of services that is managed by a service provider. The service portfolio is used to managethe 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.

service strategy

(ITIL Service Strategy) A stage in the lifecycle of a service. Service strategy defines the perspective, position, plans and patterns thata service provider needs to execute to meet an organization‰Ûªs business outcomes. Service strategy includes the followingprocesses: strategy management for IT services, service portfolio management, financial management for IT services, demandmanagement, and business relationship management. Although these processes are associated with service strategy, most processeshave activities that take place across multiple stages of the service lifecycle.

servicetransition

(ITIL Service Transition) A stage in the lifecycle of a service. Service transition ensures that new, modified or retired services meet theexpectations of the business as documented in the service strategy and service design stages of the lifecycle. Service transitionincludes the following processes: transition planning and support, change management, service asset and configurationmanagement, 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 multiplestages of the service lifecycle. See also transition.

SKMS service knowledge management system

SOA Service Orientated Architecture is an architectural approach that enables the loose integration of many different data sources intocoherent service views.

softwareengineering The term given to software development when approached as a computer aided software engineering (CASE) project

solution design The use of design techniques to develop an optimal solution from a set of requirements

sourced How a solution is obtained–it can be ‘sourced internally’, meaning it is developed internally, or ‘sourced’ externally meaning it isopen source or provided by a software vendor

specificationA formal definition of requirements. A specification may be used to define technical or operational requirements, and may be internalor external. Many public standards consist of a code of practice and a specification. The specification defines the standard againstwhich an organization can be audited.

stakeholder A person who has an interest in an organization, project, IT service etc. Stakeholders may be interested in the activities, targets,resources or deliverables. Stakeholders may include customers, partners, employees, shareholders, owners etc. See also RACI.

stakeholderanalysis

The second stage of business analysis (after Enterprise Analysis) in the conventional view, where the stakeholders for a particularproduct, application or service are identified and their role in the provision of requirements defined. This is similar to the work carriedout in ITIL Service Strategy.

status The name of a required field in many types of record. It shows the current stage in the lifecycle of the associated configuration item,incident, problem etc.

strategic (ITIL Service Strategy) The highest of three levels of planning and delivery (strategic, tactical, operational). Strategic activitiesinclude 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

system

“A number of related things that work together to achieve an overall objective. For example:A computer system including hardware, software and applicationsA management system, including the framework of policy, processes, functions, standards, guidelines and tools that are plannedand managed together – for example, a quality management systemA database management system or operating system that includes many software modules which are designed to perform a set ofrelated functions. “

TOGAF The Open Group Architecture Framework

trigger Every process has a trigger. This is the special input, or inputs, required to set off (trigger) the process. For example, an invoicingprocess 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

urgency(ITIL Service Design) (ITIL Service Transition) A measure of how long it will be until an incident, problem or change has a significantimpact on the business. For example, a high-impact incident may have low urgency if the impact will not affect the business until theend of the financial year. Impact and urgency are used to assign priority.

use-case

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 ModellingLanguage) or BPML 2.0 (Business Process Modelling Language) as formal representations or models of what a solution is going tolook like. Use-cases are used by business analysists and service designers as a means of bridging the communications gap betweendevelopers 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.

user story 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 understandingthe workflow and identifying missing components in an application or service.

users The stakeholders who will be using a service operationally, day to day. As opposed to the business customers who pay for anddetermine the sort of service that is required.

utility

(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 ‰Û÷fitfor purpose‰Ûª. The business value of an IT service is created by the combination of utility and warranty. See also servicevalidation and testing.

validation(ITIL Service Transition) An activity that ensures a new or changed IT service, process, plan or other deliverable meets the needs ofthe 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.

warranty

(ITIL Service Strategy) Assurance that a product or service will meet agreed requirements. This may be a formal agreement such as aservice level agreement or contract, or it may be a marketing message or brand image. Warranty refers to the ability of a service to beavailable when needed, to provide the required capacity, and to provide the required reliability in terms of continuity and security.Warranty can be summarized as ‰Û÷how the service is delivered‰Ûª, and can be used to determine whether a service is ‰Û÷fit foruse‰Ûª. The business value of an IT service is created by the combination of utility and warranty. See also service validation andtesting.

waterfall The term used to describe the conventional software development cycle, because the stages are often drawn in a set of connectedboxes remeniscent of a cascade or set of rapids

wireframe A non-working prototype of a solution that looks like the screens of an application and is used to check that stakeholders aresatisfied with how the solution will look in practice.

work instruction A document containing detailed instructions that specify exactly what steps to follow to carry out an activity. A work instructioncontains much more detail than a procedure and is only created if very detailed instructions are needed.

workinstructions

The most detailed level of documentation for a process. Typically work instructions are used to train new users, and contain thedetail of how the application is used, down to the use of fields on a screen..

workflow

The flow of work through a process. This usually refers to a repeatable process flow where the flow is aided by software (workflowsoftware) this can be as simple as using e-mail authorisation for important stages of a process to an application that handles all of thedata of a process and provides integrated facilities to allocate, authorise and measure work as it is performed by different people in anorganisation.

ContentsPreface

AcknowledgementsAudience

Introduction

Perspectives–Frameworks & RequirementsBusiness Analysis: BABOKIT Governance and audit: Cobit5 (Requirements Process Audit)IT Service Management–ITIL (Service Design)Software EngineeringProject ManagementEnterprise Architecture

Requirements Register

Requirements for this bookProblem StatementsRequirementsBenefitsFinal and Intermediate Outcomes

Requirements Management as a ProcessProcess OverviewScalabilitySub-processes as perspectives

Integrated Requirements Process FlowTop Level Process DiagramRole: IRP OwnerRole: IRP ManagerMissing Role: Project ManagerCritical Success Factors (CSFs), Key Performance Indicators (KPIs and Metrics)Responsible, Accountable, Consulted, Informed (RACI) – Top LevelExample of initial ‘raw’ requirementIRP Sub-Process 1: Requirements AnalysisIRP Sub-Process 2: Requirements ElicitationIRP Sub-Process 3: Requirements OrganisedIRP Sub-Process 4: Strategy Approved – Service CharteredIRP Sub-Process 5: Solution DesignedIRP Sub-Process 6: Service TransitionedIRP Sub-Process 7: Service SourcedIRP Sub-Process 8: Service OperatedIRP Sub-Process 9: Continual Service ImprovementIRP Sub-Process 10: Change Approval

Requirements LifecycleNeed IdentifiedService StrategyStakeholder AnalysisElicitationLogged: Requirement / Late RequirementCategorisedConfirmedPrioritisedOrganisedLinked to Service Design Package (SDP)Formal specificationModelAssumptions & ConstraintsVerifiedNot AppropriateValidatedCharteredSolution DesignSolution Approved

Service TransitionService OperationContinual Service Improvement (CSI)Service ImprovedOn-going CSI RequirementRequirement Delivered

Governance StructureProcess Diagram OverviewControl SectionAction SectionEnablers SectionSources of Requirements (inputs to the process)Enterprise Analysis, Strategy & GovernanceStakeholder AnalysisCommunications PlanRequirements Design & EngineeringReadiness AssessmentSolution Definition & SelectionSolution Evaluation ReportSolution Delivery Review

Tool RequirementsCommunications Plan WorkflowRisk RegisterRequirements Register and RepositoryService PortfolioService Design Package (SDP)

Bibliography

Appendix B – Links to COBIT5Goals & Metrics

Appendix C–An Example of a Code of Ethics

Glossary