Bite sized training sessions: Business And Functional Requirements

1
Bite sized training sessionsBusiness And
Functional Requirements
2
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

3
Chain Of Reasoning
Stakeholders

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

4
What are Requirements?

• IEEE Definition
• 1. a condition or capability needed by a user to
  solve a problem or achieve an objective2. 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 document3. a documented
  representation of a condition or capability as in
  (1) or (2)

5
What are Requirements?

• ISEB have 7 types of requirement
• General Requirement
• Business Requirement
• Functional Requirement
• Detailed Requirement
• Non-functional Requirement
• Data Requirement
• Technical Requirement

6
What are Requirements?

• IIBA have 6 types of requirement
• Business Requirements.
• User Requirements
• Functional Requirements
• Quality of Service Requirements
• Assumptions and constraints
• Implementation requirements.

7
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?
8
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
9
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?
10
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.

11
Examples of poor functional requirements

• Be able to use diary functionality
• Be able to flag premium customers
• Be able to track and report on sales
• Increase accuracy of sales information
• Allow authorised users of team-leader and above
  to cancel sales orders
• Prompt the owner of the sales order to
• notify the customer of cancelled sales
• orders.

12
Common mistakes

• Designing the solution
• Unjustified requirements
• Putting in unjustified extra information
• Not putting sufficient detail in
• Protecting requirements ego fuelled analysis!

13
Functional Requirement Prioritisation - MoSCoW

• Must have requirement
• o
• Should have requirement
• Could have requirement
• o
• Wish list requirement

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

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

16
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

17
Questions?
18
(No Transcript)