This document summarizes an online study group session for the IIBA UK BABOK guide. The session will cover Chapter 5 on Requirements Life Cycle Management and include presentations from Saffron House, the IIBA UK Director of Professional Development, and two IIBA UK volunteers. Participants will work through the key chapters of the BABOK guide over nine weeks and are encouraged to ask questions during the session. The session will also include polls to engage participants.

1. @UKIIBA #UKIIBA
IIBA UK BABOK online study group
31st August 2021
Starting at 7pm
Welcome

2. What to
expect
Saffron House: IIBA
UK Director of
Professional
Development. Host for
tonight
A panel of presenters:
I will introduce you to
these shortly
9-week cycle: Working
through key chapters
of the IIBAs BABOK
guide
Tonight, we are looking at
Chapter 5 of the BABOK
Guide: Requirements Life
Cycle Management
Do use the Question
Panel to type
questions at any time.
The host will pose
these at the
appropriate time
We will ask you
questions occasionally
using the “Polls”
feature and then
share the responses
Please stay on mute
until the presenters
have finished sharing
their slides. There will
be an opportunity to
speak a bit later

3. Joining me tonight….
Vivienne Onwuocha
IIBA UK Volunteer &
Managing Partner with
SlingStone Business
Consulting
Himanshu Jain
IIBA UK Volunteer &
Agile & Project
Management Trainer
& Coach

4. 5
BABOK
FRAMEWORK

5. 6
Requirements Analysis and Design Definition

6. 7
The Business Analysis Core Concept Model
BACCM

7. 8
5.1 TRACE REQUIREMENTS
The purpose of Trace Requirements is to ensure that requirements and designs at different
levels are aligned to one another, and to manage the effects of change to one level on related
requirements.

8. 9
5.2 MAINTAIN REQUIREMENTS
The purpose of Maintain Requirements is to retain requirement accuracy and consistency throughout
and beyond the change during the entire requirements life cycle, and to support reuse of requirements
in other solutions.

9. 10
5.3 PRIORITIZE REQUIREMENTS
The purpose of Prioritize Requirements is to rank requirements in the order of relative importance.

10. 11
5.4 ASSESS REQUIREMENTS CHANGES
The purpose of Assess Requirements Changes is to evaluate the implications of proposed changes to
requirements and designs.

11. 12
5.5 DEFINE DESIGN OPTIONS
The purpose of Approve Requirements is to obtain agreement on and approval of requirements and designs for
business analysis work to continue and/or solution construction to proceed.

12. Case Discussion
Pierre’s Restaurant

13. Pierre’s Restaurant
• Mr Pierre is the owner and manager of the restaurant
‘Pierre’s’. This is a popular French restaurant that is busy
most evenings and full at weekends with a lot of repeat
trade. The restaurant is only open in the evenings and seats
50 customers with only one service per night. Currently all
bookings are received over the telephone. On answering the
call, Mr Pierre always requests the required date and the
number of guests to be seated.
• He then checks to see if the booking can be accommodated.
Where the booking can be accommodated, he asks the
customer for further booking details including the booking
name, contact number and number of people in the booking.
He then logs the booking into the restaurant diary under the
relevant date. Mr Pierre also asks whether there are any
special dietary requirements or whether the booking is for a
special occasion such as birthday or anniversary, so he can
arrange for birthday cakes, balloons, special wines etc.
• Mr Pierre always reads the details he has taken back to the
customers so that they can confirm their bookings. If the
restaurant is full on the required evening, Mr Pierre offers an
alternative date for the booking or, if this is not acceptable,
asks if the customer would like to be added to a waiting list.
• The waiting list is recorded at the bottom of each page in the
diary and a contact name & number along with number of
people in the booking is taken. This enables Mr Pierre to
view bookings regularly and manage changes to bookings
should someone cancel or change their booking.
• On a daily basis the Head Chef, Jacques, will check the diary
to see if there is any special dietary requirement he needs to
be aware of that day. Francoise, the Head Waiter, also prints
the diary each day in order to draw up a table plan for each
service.
• As the restaurant is so busy Mr Pierre would like to start
opening lunch times but currently the telephone bookings
are taking up too much of his time. Further, Mr Pierre has
received feedback from his customers that they cannot
sometimes get through to book as the phone line is busy. In
response to this, Mr Pierre has decided to invest in an on-line
booking system that would enable customers to make
reservations on-line.
• Mr Pierre is keen that the new system does as a minimum
what his current restaurant diary enables him and his staff to
do. The hope is that this will reduce the telephone calls as
well as provide an alternative method of booking at his
restaurant which has been requested by for his loyal
customers.

14. Introducing the Case Study
• Mr Pierre is the owner and manager of a popular French restaurant. Currently all bookings are received over the telephone. On answering
the call, Mr Pierre always requests the required date and the number of guests to be seated. He then checks to see if the booking can be
accommodated. Where the booking can be accommodated, he asks the customer for further booking details including the booking name,
contact number and number of people in the booking. He then logs the booking into the restaurant diary under the relevant date. Mr
Pierre also asks whether there are any special dietary requirements or whether the booking is for a special occasion such as birthday or
anniversary, so he can arrange for birthday cakes, balloons, special wines etc.
• This project is to deliver an on-line booking system for Mr Pierre’s restaurant. The system should as a minimum:
• Allow customers to make bookings for lunch and dinner service
• Allow customers to enter dietary requirements
• Allow customers to enter special occasion
• Allow customers to be added to a waiting list
• The following documents has been documented and approved:
• Business case document consisting of Outline Business Requirements
• Architectural Overview
• Project Initiation Document
Project team: 1 Business analyst, Solution Partner (consists of Solution Architect, Technical Specialist/UX Designer), 1Tester, 1 Project Manager

15. Introducing the Case Study
• At the end of this stage of the knowledge area, the following documents should have been produced and approved:
• Requirements [traced, maintained, prioritized, approved]
• Designs [traced, maintained, prioritized, approved]
• Requirement Change Assessment
• Design Change Assessment
• The project will have one workstream:
• Design & Build of User Interface

16. Trace Requirements
• As a starting point we need to ensure we are replicating Mr Pierre’s current booking process.
• As it’s a small restaurant, we can look to see if there are existing tools that can be used to
document the requirements (e.g. M365 tools such as excel, word, etc.)
• The way the requirements are documented will be determined by the project methodology
• Waterfall – Requirement catalogue, Use Cases etc.
• Agile – Epic, Features, User stories, product backlog etc.
• Focus here is to understand and show the relationships between the requirements and design
• Can use a spreadsheet as the traceability tool
• Relationships that can be traced between requirements are:
• Use Cases
• Test cases
• Design IDs etc.
• Other tools that can be used to trace requirements are: Jira, Azure DevOps,
Ensure that requirements and designs at
different levels are aligned to one another,
and to manage the effects of change to one
level on related requirements.
• Level of Formality
• Relationships
• Traceability Repository
Trace
Requirements

17. Maintain
Requirements
• To keep it simple, an excel spreadsheet can be used to maintain the requirements
• The excel spreadsheet would include the requirements, Acceptance Criteria and comments/notes.
• Put checks in place to identify reusable requirements where applicable.
• As this is the first system to be automated, the requirements will be unique to this project but keep in
mind if the requirements can be used for other projects.
Retain requirement accuracy and consistency
throughout and beyond the change during the
entire requirements life cycle, and to support
reuse of requirements in other solutions.
• Maintain Requirements
• Maintain Attributes
• Reusing Requirements
Maintain
Requirements

18. Prioritise
Requirements
• Remember the goal is to replace Mr Pierre’s current booking system as a minimum.
• Agree the prioritisation methodology e.g. MoSCoW, Weighted Scoring, High, Medium,
Low, benefit, cost, risk etc.
• Educate your key stakeholders on the importance of prioritising requirements e.g. to
agree the MVP (Minimum Viable Product)
• A Must priority will be categorised as the MPV features to allow a customer to book an order
• A Should will be categorised as features not essential to book an order but will enhance the
User Experience
• A Could will be categorised as features that are nice to have and not necessary for MVP where
there was no feedback from User Experience report and no internal use
• A Will not have now but can have in the future
• The Priority column will be used by the development team as a guide on which features
need to be built for MVP
• Keep in mind that the prioritisation can change due to change in requirement, timelines
etc. so should be monitored continuously
• As the Business Analyst, you will also be responsible for managing conflicts among
stakeholders and working towards resolving them
To rank requirements in the order of relative importance.
• Basis for Prioritization
• Challenges of
Prioritisation
• Continual Prioritization
Prioritise
Requirements

19. Assess Requirements
Changes
• The business analysis approach agreed drives the requirement change
process
• The change request process should be communicated with your key
stakeholders
• Changes to requirements are evaluated against:
• Scope of the project
• Objectives of the project
• Value to the business
• Impact on project timeline
• Impact on budget
• Ensure, the impact of the change is communicated and understood by the
key stakeholders to enable them make an informed decision.
Evaluate the implications of proposed changes to
requirements and designs.
•Assess Formality
•Impact Analysis
•Impact Resolution
Assess
Requirements
Changes

20. Approve
Requirements
• Obtain approval from key stakeholders on the requirements and design.
• To approve the design, the Business Analyst can arrange a demo session with
the solution partner
• The MVP can be agreed as part of the approval session
• Conflicts that may arise between stakeholders are managed by the Business
Analyst
• Where stakeholders are unable to come to a consensus, the sponsor(Mr
Pierre) will make the decision
Obtain agreement on and approval of requirements and
designs for business analysis work to continue and/or
solution construction to proceed.
• Understand Stakeholder
Roles
• Conflict and Issue
Management
• Gain Consensus
• Track and Communicate
Approval
Approve
Requirements

21. Questions!
Use the question panel or unmute

22. What next?