About the lack of good analysis in some IT projects and a suggestion for a business requirements framework

1. Business Requirements
About the current state of business analysis &
A suggestion for a Business Requirements Framework
29/03/2016 (C) Heinz Tonn 1

2. 29/03/2016 (C) Heinz Tonn 2
Observation 
 Problem & Consequences
• Nowadays many IT projects are agreed as fixed-price-contracts.
• For these projects it is assumed that the project scope is fully
understood at the time contracts are signed.
• As a result the analysis phase is shortened if not dropped altogether.
• The necessary analysis work, which should be performed by well-
trained business analysts, is assumed to have taken place by sales
staff or is offloaded to IT experts.

3. Problem & Consequences 
 Impact
29/03/2016 (C) Heinz Tonn 3
Problem:
• Business-unaware IT experts are asking
the wrong questions (e.g. asking for
server capacity or network traffic).
• Business users or owners cannot give
an answer or give wrong answers.
Consequence:
• Business requirements
are missing, incorrect or
undefined.
• System requirements are
defined by business
rather than IT experts.

4. 29/03/2016 (C) Heinz Tonn 4
Impact 
 Remedy
• Badly defined or missing business requirements jeopardise the success of any
project.
• Without business requirements there is no foundation to test or measure the
fitness or success of the project in business terms.
 In the best case the business requirements become apparent when the solution
is being tested. This means usually major rework.
 In the worse case changes are so big that the contract partners have to accept
and agree the failure of the project.

5. 29/03/2016 (C) Heinz Tonn 5
Remedy 
 Limitations of Use
• Experienced PMs, architects and developers can collect business
requirements if they know what to ask for. All they need is
A business requirements framework or catalogue and some guidance
• The following slides provide a basic business requirement framework.
• There are however a number of limitations which should be known.
• Readers are asked to be mindful about these limitations.

6. 29/03/2016 (C) Heinz Tonn 6
Limitations of Use
 Business Requirements Framework
• The framework is to be understood as guidance, not checklist.
• Dependencies between categories are not considered (e.g. security & user
devices) but need to be understood.
• Business analysis is not a single-pass exercise even if this list might
suggest otherwise. Business analysis is an iterative process.
• Business requirements will change once a price tag is put on the resulting
solution. Good analysts will know how to drive this process.

7. 29/03/2016 (C) Heinz Tonn 7
Business Requirements - Main Categories
Describes the organisation for which the solution has to work.
Provides the basics understanding of the Business.
Defines the verifiable features of the solution in
business terms. Main input to the test plans.
Laws, rules and regulation which must be considered and
adhered to in the implementation and operation of the solution.
Requirements which are validated or
verified by the extend of the achievement.
Requirements with regard to the quality of the
solution. Only partly input to the test plans.
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional Requirements

8. 29/03/2016 (C) Heinz Tonn 8
Business Requirements - Main & Sub-Categories
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional Requirements
Mandate
Stakeholder
Stakeholder Impact
Motivation
Core Business
Business Administration
Service Management
Business Standards
Implementation Guidelines
Certifications
Market Share
Financials
Customer Satisfaction
Employee Satisfaction
Social Responsibility
SustainabilityUser & Usage
Availability & Continuity
Performance
Security
Safety

9. (C) Heinz Tonn 9
Business Context
29/03/2016
Stakeholder
Stakeholder Impact
Motivation
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional
Requirements
What are the positive impacts (benefits) and
negative impacts of the solution?
All impact have to be addressed by the project.
Especially negative impacts should not be ignored.
Who is the business owner, responsible for the
success of the project? Who is the budget holder?
Mandate
Who are the stakeholders of the project?
Do not only think “user”. Also consider customers, clients and
other groups or people affected by the solution or its use.
Why has the project being launched? What is the expected business
outcome (in contrast to the purpose of the solution)?
Consider how the outcome and purpose can be quantified and measured.

10. (C) Heinz Tonn 10
Functional Requirements
29/03/2016
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional
Requirements
Which regular business tasks and activities should the solution to automate?
Consider UML, swimlanes or BPMN for modelling.
What maintenance processes are part of operational business support?
Usually these processes cover setup/change/delete of users/accounts and master
data management (e.g. product data). Reporting usually reflects audit needs and logs.
What are the processes to ascertain that the solution provides the expected quality?
This is not how the solution works in the business environment. Processes can be
Helpdesk, Incident Management, and Change Management.
Each of the sub-categories can be divided into:
1) Process & transactions,
2) Information & data management and
3) Reporting
Core Business
Business Administration
Service Management

11. (C) Heinz Tonn 11
Constraints
29/03/2016
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional
Requirements
(C) Heinz Tonn 11
Standards are outcome-based, meaning that these define the outcome (e.g. a
secure solution), not necessarily the way to achieve the outcome.
In contrast to Standards, Implementation Guidelines define how to achieve the
outcome (e.g. how to document or test the solution, which design or
development methods to be used).
Certifications are e.g. specific test or assurance procedures which exist
for some Business Standards and Implementation Guidelines.
Constraints are regulations or laws which exists in
some industries. Example are banking (e.g. data
security) transportation or critical infrastructure (e.g.
operational safety, health & safety).
It is important to identify the constraints as well as
their impact on the implementation project and
solution design.
Business Standards
Implementation Guidelines
Certifications

12. Typically measured by power
consumption and carbon footprint
of old and new hardware.
Likely to be measured
by survey.
(C) Heinz Tonn 12
Corporate Objectives
Market Share
29/03/2016
Financials
Customer Satisfaction
Employee Satisfaction
Social Responsibility
Sustainability
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional
Requirements
These objectives are common for all projects and
solutions.
Ideally they not only provide the objective but also a
method of measuring achievement. These methods
could be used to define the measurable benefits of the
project.
The main question is therefore: What is a reasonable
extend of achievement, considering that there are
other influencing factors beyond the solution or
project?
Most likely to be defined with a measuring unit.

13. Which and how many user are there? This can cover quantities, types (e.g.
power-user) as well as user devices & other endpoints (e.g. laptops, phones,
BYOD, IoT-sensors).
What is average and peak usage of the system by user quantities and type? Are
there periodical usage patterns (e.g. monthly, yearly)?
What are the user and endpoint locations and their geography distribution? This
might require some assumptions if the solution is publically used.
Last but not least: what are the growth predictions for all of the above?
(C) Heinz Tonn 13
Non-Functional Business Requirements
Users & Usage
29/03/2016
Availability & Continuity
Performance
Security
Safety
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional
Requirements
The NFR are the core of Business
Requirements and where most thing
can go wrong (i.e. asking for system
instead of business requirements).
Also see next two pages.

14. What are the office hours? When is the solution needed and is this the same time a
helpdesk, support or both must be available?
Are scheduled downtimes or outages acceptable? If not, what is the RTO (Recovery
Time Objective) and the MTPoD (Maximum Tolerable Period of Disruption)?
What is maximum tolerable data loss (e.g. transaction or Zero-Data-Loss)? With
other words: What is the RPO (Recovery Point Objective)?
It makes sense to consider and check Business Impacts Levels (see www.gov.uk for
more detail).
(C) Heinz Tonn 14
Non-Functional Business Requirements
Users & Usage
29/03/2016
Availability & Continuity
Performance
Security
Safety
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional
Requirements
The NFR are the core of Business
Requirements and where most thing
can go wrong (i.e. asking for system
instead of business requirements).
Also see next two pages.

15. What is the required performance of the solution (e.g. responsiveness)?
Is a reduced performance acceptable? If so, under which conditions?
What is the acceptable change to performance under load conditions (e.g. peak
load)?
(C) Heinz Tonn 15
Non-Functional Business Requirements
Users & Usage
29/03/2016
Availability & Continuity
Performance
Security
Safety
Business Context
Functional Requirements
Constraints
Corporate Objectives
Non-Functional
Requirements
What are the security classification of the information held in the solution?
Are relevant threat and attack scenarios known (e.g. Denial-of-Service)? If so,
what are the business impacts of such scenarios?
What are the relevant operational threat and attack scenarios (e.g. hacking of
critical infrastructure)? If so, what are the business impact of each scenario?
The NFR are the core of Business Requirements
and where most thing can go wrong (i.e. asking
for system instead of business requirements).

16. A final word of advice
29/03/2016 (C) Heinz Tonn 16
• There is no replacement for good analysis in a dedicated project phase and
best-practice requirements management.
• It should not be done as a pre-sales activity
• It should not be performed by sales people or technical staff of the design
and implementation team in isolation.
• Some categories of these business requirements should be part of an
Business Policy, by this avoiding to re-visit those for each and every project.
These categories are
• Corporate Objectives (fully)
• Business Context, Constraints, Non-Functional Requirements (partly)
• Defining a Business Policy will cost money but each and every project will be
able to reduce its efforts by having one.

17. End of presentation
Find the author on LinkedIn
29/03/2016 (C) Heinz Tonn 17