Bite sized training sessions:
Business And Functional Requirements
Objectives
• 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:
Drivers
Drivers
Stakeholders
Drivers
Drivers
Objectives Objectives Objectives Objectives
Objectives
Change
Requirements
Stakeholders
Change
Requirements
Change
Requirements
Change
Requirements
Change
Requirements
Change Requirements must be assumed to be wrong until they are proved to be
right
What are Requirements?
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 Requirements?
ISEB have 7 types of requirement:
1.
2.
3.
4.
5.
6.
7.
General Requirement
Business Requirement
Functional Requirement
Detailed Requirement
Non-functional Requirement
Data Requirement
Technical Requirement
What are Requirements?
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
change”.
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
Examples
• 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
orders
6.
Prompt the owner of the sales order to
notify the customer of cancelled sales
orders.
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
•o
• Should have requirement
• Could have requirement
•o
• Wish list requirement
Functional Requirement
Prioritisation Logic
• Must have: the project objectives cannot be met without this
requirement
• 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 from?
• Declared by Stakeholders
– Interviews
– Workshops
– ‘Casual’ communications
• Constraining standards and procedures
– Documents
– Interviews
– workshops
• Proposed by Business Analysts!
– All the time
– Any way that is needed.
Exercise: Document some functional requirements
• 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
Questions?