An integrated requirements process is needed to address issues with existing approaches. Requirements define strategic assets and competitive advantage, but current frameworks treat requirements as an afterthought. This leads to projects developing the wrong solutions and over 80% of errors occurring in the requirements phase. The document proposes an integrated requirements process (IRP) to ensure requirements are properly understood across organizational boundaries. Key benefits of the IRP include improved visibility, re-use, governance, and matching solutions to actual business needs rather than apparent needs of powerful stakeholders.

1. An integrated Requirements Process

2. An integrated Requirements Process
Why is a requirements process needed?
Requirements are Intellectual Property (IP), organisational strategic assets
Retail Banking
requirements define the business
solutions change [ goldsmith receipt -> cheque -> ATM -> Credit Card -> Mobile Payment ]
Competitive advantage is achieved by agile understanding of new requirements
Service Value is only delivered if you understand the requirements.
The Business Portfolio is determined and driven by requirements
Re-use of requirements allows development to be optimised.
2
Why are requirements important?
A process allows repeatability, reuse, reduction in waste & value delivery
Processes can be measured and improved
The Integrated Requirements Process (IRP) crosses many organisational
boundaries – each potentially corrupts understanding & value
An Integrated Requirements Register provides the service & defines the
process – preserving integrity & delivering solutions matched to value

3. An integrated Requirements Process

4. An integrated Requirements Process
Studies carried out into IT project failures tell a common story. Many of
the projects and unsatisfactory IT services suggest the following
conclusions:
o A large proportion of errors ( >80%) are introduced at the
requirements phase.
o Very few faults ( <10%) are introduced at design and development
– often developers develop things right, but not the right things.
o Most of the project time is allocated to the development and testing
phases of the project.
O <12% of the project time is allocated to requirements.
ITIL© 2011 ’Service Design’ Page 334 Section 5.1.4
Why are requirements needed?

5. An integrated Requirements Process
Not a process: as seen by existing frameworks
Not integrated into ITIL© service management lifecycle
utility/warranty disconnect
No re-use: The tracking of requirements across the organisation is not easy
No provision for late requirements
Solution driven: specifics are considered too early
before requirements are properly understood
impeding the development of radical solutions
Limited Scope: Requirements understood per project/App not across organisation
Poor Integration of:
Requirement analysis
Service Design
Solution development
-> duplication of effort, poor reuse, poor communication -> poor results
-> poor Customer Satisfaction
-> poor Value -> Business
Problems:

6. An integrated Requirements Process
IRP – Process Diagram BPMN – Top Level

7. An integrated Requirements Process
Process ownership defined ensuring accountability
Clear visibility of investment, progress and value delivery
Comply with Cobit5 requirements BAI2, BAI3 and MEA3
Transparent management of conflicting, duplicate and late requirements.
Greater visibility of requirements & corporate value -> effective investment decisions
All requirements are checked (during the validation phase) to ensure that they do not conflict
with corporate policy & strategy
-> ensuring good governance at an individual requirement level
Effort & cost applied to satisfying requirements
matched to actual business need
NOT apparent need ( loud & powerful stakeholders)
Benefits of an integrated process

8. An integrated Requirements Process
Requirements
Register -
Mock up
for iPad