You are on page 1of 18

Bite sized training sessions:

Business And Functional

To understand
What business and functional requirements are
The difference between them
Where they come from
Where they fit in to analysis
The importance of business and functional requirements
To be able to
Discover business and functional requirements
Document business and functional requirements
Chain Of
Reasoning: Stakeholders Stakeholders

Drivers Drivers Drivers Drivers

Objectives Objectives Objectives Objectives Objectives

Change Change Change Change Change

Requirements Requirements Requirements Requirements Requirements

Change Requirements must be assumed to be wrong until they are proved to

be right
What are
IEEE Definition

1. a condition or capability needed by a user to

solve a problem or achieve an objective
2. a condition or capability that must be met or
possessed by a system or system component
to satisfy a contract, standard, specification, or
other formally imposed document
3. a documented representation of a condition
or capability as in (1) or (2)
What are
ISEB have 7 types of requirement:

1.General Requirement
2.Business Requirement
3.Functional Requirement
4.Detailed Requirement
5.Non-functional Requirement
6.Data Requirement
7.Technical Requirement
What are
IIBA have 6 types of requirement:

1.Business Requirements.
2.User Requirements
3.Functional Requirements
4.Quality of Service Requirements
5.Assumptions and constraints
6.Implementation requirements.
What are Requirements?
A pragmatic definition

Requirements are the answers to the question:

what will this project change that is required in order
to deliver the objectives?

change can be create, update or delete something

The focus is on what will change not how will it


Question: Is there a material difference between

business and functional requirements?
Requirements Levels
Business & functional requirements are high level
requirements e.g. be able to take orders

Process and data models are low level requirements - rules

e.g. customers have to register before placing orders
as seen in Data and Process modelling sessions
Functional Requirements
The solution will automatically validate customers against the ABC
Contact Management System

The solution will enable users to record customers sales

The solution will enable Customer Order Fulfilment letters to be

automatically sent to the warehouse.

Question: What does solution mean in this context?

Best practice
Document requirements, not physical solutions!

Document one requirement at a time!

Map each requirement to the objective(s) and/or

principle(s) it contributes to delivering.

Make each requirement as complete and accurate as it

needs to be to answer the question what does the solution
need to change in order to deliver the requirements?.

If there is a known, verified constraint that materially

affects a requirement, then state it.
Examples of poor
functional requirements
1. Be able to use diary functionality

2. Be able to flag premium customers

3. Be able to track and report on sales

4. Increase accuracy of sales information

5. Allow authorised users of team-leader and above to cancel sales


6. Prompt the owner of the sales order to

notify the customer of cancelled sales
Common mistakes
Designing the solution

Unjustified requirements

Putting in unjustified extra information

Not putting sufficient detail in

Protecting requirements ego fuelled analysis!

Functional Requirement
Prioritisation - MoSCoW
Must have requirement
Should have requirement
Could have requirement
Wish list requirement
Functional Requirement
Prioritisation Logic
Must have: the project objectives cannot be met without this

Should have: the project objectives can be met without this

requirement but not as well as with it

Could have: this requirement only maps to one or more principles

Wish list: this requirement does not map to any project objectives
or principles.
Functional Requirement
where do they come
Declared by Stakeholders
Casual communications
Constraining standards and procedures
Proposed by Business Analysts!
All the time
Any way that is needed.
Exercise: Document some functional

Using the Objectives you analysed, define some

functional requirements
Map which objectives and/or principles they
contribute to
Prioritise them
If you need to make any assumptions,
document them.
Time allowed: 20 minutes
Deliverable: Flip chart list of requirements