analysis & business requirements

Business RequirementsAbout the current state of business analysis &

A suggestion for a Business Requirements Framework

29/03/2016 (C) Heinz Tonn 1

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.

Problem & Consequences

Impact29/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.

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.

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.

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.

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

29/03/2016 (C) Heinz Tonn 8

Business Requirements - Main & Sub-Categories

Business Context


Constraints


Non-Functional Requirements

Mandate

Stakeholder

Stakeholder Impact

MotivationCore Business

Business Administration

Service Management

Business Standards

Implementation Guidelines

CertificationsMarket Share

Financials

Customer Satisfaction

Employee Satisfaction

Social Responsibility

SustainabilityUser & Usage

Availability & Continuity

Performance

Security

Safety

(C) Heinz Tonn 9

Business Context

29/03/2016

Stakeholder

Stakeholder Impact

Motivation

Business Context


Constraints


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.

(C) Heinz Tonn 10


29/03/2016

Business Context


Constraints


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

(C) Heinz Tonn 11

Constraints

29/03/2016

Business Context


Constraints


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

Typically measured by power

consumption and carbon footprint

of old and new hardware.

Likely to be measured

by survey.

(C) Heinz Tonn 12


Market Share

29/03/2016

Financials

Customer Satisfaction

Employee Satisfaction

Social Responsibility

Sustainability

Business Context


Constraints


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.

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


Performance

Security

Safety

Business Context


Constraints


Non-Functional

RequirementsThe 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.

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


Users & Usage

29/03/2016


Performance

Security

Safety

Business Context


Constraints


Non-Functional

RequirementsThe 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.

http://www.gov.uk/

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


Users & Usage

29/03/2016


Performance

Security

Safety

Business Context


Constraints


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).

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.

End of presentationFind the author on LinkedIn

29/03/2016 (C) Heinz Tonn 17

https://uk.linkedin.com/in/heinztonn

analysis & business requirements

Internet