Business analysis and requirements management are a key to project success.
This workshop helps candidates perform better based on sharing real life experience with them.
2. WHO AM I?
Mena Mostafa
Instructor, Coach & Advisor
15 years experience (software development field)
Project Manager, Business Analyst & Developer
Worked in the enterprises world (ASSET, ITWorx,
etisalat…)
Managed over 150 projects (simple websites, portals,
ERP, eCommerce, games…)
Requirements gathering & management SME in ITWorx
Led teams (co-located, remote, vendors)
Joined the entrepreneurship & the world of startups
3. WHO ARE YOU?
Introduce yourself
What would you like to know?
4. WHY WE ARE HERE?
Intentions
Understand what business requirements and analysis
are
Understand how a full-spectrum of requirements fit
together
Pick up some tips that might be useful on your projects
Values
Coaching session
More practical than theoretical
Context
Our time is short and our topic is large
6. Switch off/silent your mobile phones
Participate
Ask questions
Share your experience
Make mistakes & learn from them
Request a break when you need to
Respect break times
Have fun!
THE DEAL
7. TOPICS
Introduction
Common issues & challenges
The Business Analyst
How to do the job?
Requirements gathering techniques
How to document requirements?
Matching requirements with user experience
Towards a better output
The workshop
9. WHY REQUIREMENTS GATHERING &
ANALYSIS?
This common sense seems to disappear!
“Measure twice, cut once”
“Look before you leap”
What do these sayings have in common?
They're about Thinking before Acting
Why?
Because it Saves time, money and effort
It's plain common sense
Yet, when it comes to software development…
10. WHAT IS REQUIREMENTS GATHERING?
A Process of Collecting the user needs
to Solve a problem or issues
and Achieve an objective
An important Phase in a project life cycle
If the Requirements Gathering is not done properly
All below phases get incomplete
No matter how good the Design is
Requirements are the foundation of any Project
If you don’t know where you’re going, any road will take
you there!
11. TYPES OF SOFTWARE PROJECTS
New Development: services & products
Implementation: customization on existing software
(service or product)
Research: proof of concept for new ideas
Bug Fixing & Modifications: on existing software
(service or product)
Maintenance & Support: on existing software
(service or product)
12. WHAT IS A REQUIREMENT?
A requirement is a capability that a product must
possess to satisfy a customer need or objective
A key component of any business project
They help a project team define
Goals
Scope of the work
They provide objective ways to measure the
project's success
13. BUSINESS REQUIREMENT
A series of needs that must be fulfilled to achieve a
high-level objective
Clear business requirements help ensure that the
end result of a project fulfills the stakeholders'
needs
14. FUNCTIONAL REQUIREMENT
A detailed breakdown that explains how the
outcome of a project will operate to meet the
specified business requirements
Include a list of the steps that each user will take in
the new system
The functional requirements for a project are
defined and developed after the project's business
requirements have been established
15. BUSINESS REQUIREMENT VS. FUNCTIONAL
REQUIREMENT
Upgrade the manual payroll process by switching to an
automated payroll process
Business requirements
“Implement a computerized system that reduces errors and
increases efficiency by calculating employees' wages,
withholding required deductions and paying the employee the
amount she is owed.”
Functional requirements
How many employees the system must accommodate
Are they hourly, salaried or both
What a pay period is
What states' tax
16. NON-FUNCTIONAL REQUIREMENTS
What an organization needs to do to support the
project's outcome during and after implementation
Examples:
Hardware
Software
Performance
Number of normal and concurrent users
Page response time
Usability
Cultural aspects
Availability
Reliability
Maintainability
Extensibility
Security…
17. WHAT IS A FEATURE?
A set of logically related requirements that allows
the user to satisfy an objective
A feature tends to be a higher-level objective than a
requirement
A requirement tends to be granular, and is written
with the implementation in mind
A feature is something you’ll print on a detailed
datasheet of your product
18. FEATURE VS. REQUIREMENT
Feature
Online shopping cart
Requirements
User shall be able to add books to online shopping cart
User shall be able to remove books from online
shopping cart
User shall be able to view books in the online shopping
cart at any time
User shall be able to start his checkout from the
shopping cart
19. I’m trying to write a DOS bat file that runs an Access
macro to import a CSV output file from my COBOL
program. Any help would be appreciated!
20. TYPES OF REQUIREMENTS
Conscious Requirements
Stakeholder is aware of
Unconscious Requirements
Stakeholder knows the requirement so well that he
thinks that it's not worth mentioning
Undreamed Requirements
Stakeholders does not ask for, either because he
thinks they are not possible or because they are new
ideas that have occurred to them
21. COMMON ISSUES & CHALLENGES
Why Do Projects Fail?
Requirements Gathering Challenges
Requirements Volatility Causes
What Causes Changes to Requirements?
Scope Creep
23. WHY DO PROJECTS FAIL?
A Standish group research report says that:
31% of all projects are cancelled before they ever
get completed
53% of projects cost almost twice their original
estimates
25. STAKEHOLDERS ISSUES
Users don't understand what they want
All requirements are critical, no priority is defined
Scope and Vision not clearly defined
Users won't commit to a set of written requirements
Users change requirements after the cost and schedule
have been fixed
Communication with users is slow
Users often do not participate in reviews
Users are technically unsophisticated
Users don't understand the development process
Users don't know about present technology
26. ENGINEER/DEVELOPER ISSUES
Technical personnel and end users may have
different vocabularies
Consequently, they may wrongly believe they are in
perfect agreement until the finished product is
supplied
Engineers and developers may try to make the
requirements fit an existing system or model, rather
than develop a system specific to the needs of the
client
Analysis may be often carried out by engineers or
programmers, rather than personnel with the
people skills and the domain knowledge to
understand a client's needs properly
27. What if these challenges were not beaten?
The final product will not be Delivered to the customer
Successfully in Time
Why?
Because the impact of the above points is huge in the
product’s life cycle
30. REQUIREMENTS VOLATILITY CAUSES
Internal Factors
Not capturing requirements from all relevant
stakeholders
Not using right requirement capturing technique
depending on the context
Not capturing all relevant details
Not having measures such as check-list to ensure
completeness of requirements captured
Not having measures to ensure clarity
External Factors
Market driven
31. WHAT CAUSES CHANGES TO
REQUIREMENTS?
Requirements errors, conflicts and inconsistencies
during analysis
Evolving customer/end-user knowledge of the system
Technical, schedule or cost problems
Changing customer priorities
Changing business environment
Emergence of new competitors, staff changes, etc.
New laws, regulations
Environmental changes
Organizational changes
Changes in structure and processes
New technology (technology push)
32. SCOPE CREEP
Refers to uncontrolled changes or continuous
growth in a project's scope
This can occur when the scope of a project is not
properly defined, documented, or controlled
It is generally considered harmful
33. WHO IS THE BUSINESS ANALYST?
The Analyst Job
Responsibilities
Business Analyst Qualifications
34. THE ANALYST JOB
Demonstrate the ability and inclination to tolerate
chaos
ambiguity
and lack of knowledge
and to function effectively in spite of them
35. RESPONSIBILITIES
Help businesses implement technology solutions in a
cost-effective way by:
Understanding business change needs
Assessing the business impact of those changes
Capturing, analyzing and documenting
requirements
Supporting the communication and delivery of
requirements with relevant stakeholders
36. I know that you believe that you understand what you
think I said but I am not sure you realize that what
you heard is not what I meant
43. HOW TO DO THE JOB?
Software Development Lifecycle (SDLC)
Requirements Management Process
Requirements Gathering Activities
Change Management
Requirements Traceability
Signoff
46. REQUIREMENTS GATHERING ACTIVITIES
Eliciting Requirements
Communicating with users to determine their requirements
Analyzing Requirements
Determining whether the stated requirements are unclear, incomplete,
ambiguous, or contradictory and then resolving these issues
Recording Requirements
Requirements may be documented in various forms
Natural-language documents
Use cases
User stories
Process specifications
Validating Requirements
Checking that a product, service, or system meets requirements and that it
fulfills its intended purpose
47. A user will tell you anything you ask about,
but nothing more
48. CHANGE MANAGEMENT
The process of managing the changes to
requirements
Hard problem because of continuous changes
during development process
The principal concerns are
Managing the relationships between requirements
Managing priorities between requirements
Managing changes to agreed requirements
Managing the dependencies between different
documents
requirements document
other documents produced in the systems engineering process
49. REQUIREMENTS TRACEABILITY
Requirements cannot be managed effectively
without traceability
Traceable means knowing about
Who suggested the requirement
Why exists the requirement
What requirements are related to it
How relates that requirement to other information such
as:
Mockups
System design
Implementations
User documentation
50. SIGNOFF
Final & most important step in requirements
gathering process
Requirements should be freezed
Later request for changes should be treated
separately
Technical opinion should be involved
Review with customer before signoff
52. REQUIREMENTS GATHERING TECHNIQUES
4 out of 5 software development projects go over
time, over budget or don’t deliver expected results
Poor requirements account for 71% of software
project failures
It pays to put in the effort upfront to minimize the
risk of failure
The question is, how do we achieve this?
There is no perfect method for gathering and analyzing
requirements
If there was, we'd all be using it
Rather, there are many approaches to choose from…
53. REQUIREMENTS GATHERING TECHNIQUES
A structured approach to requirements
management resolves these problems
Develop SMART objectives which nearly
guarantees the success of the project
Scientific approach requires a constant description
of all activities, objectives and corrective measures
to counter potential loopholes
54. REQUIREMENTS GATHERING TECHNIQUES
Apprenticing Technique
Observes the
business users
Understands the day
to day activities
Capture/documents
the requirements
Get signoff from
customer
55. REQUIREMENTS GATHERING TECHNIQUES
Brainstorming Technique
Idea generation
Idea reduction and voting
Mind Mapping Technique
Use emphasis
Use association
Be clear
Layout
Use Case Workshop Technique
Most popular
Collect requirements in step-by-step manner
Helps understanding the details
Easy to document and written in natural language
56. REQUIREMENTS GATHERING TECHNIQUES
Interviewing Technique
Fix up the time with business user
Attend the session
Note down the information in notebook
Stake Holder 1 Stake Holder 2 …………
Requirements #1 Definition
Scope
Date of Interview
Deadlines and Boundary
Requirements #2 Definition
Scope
Date of Interview
Deadlines and Boundary
57. REQUIREMENTS GATHERING TECHNIQUES
Family Therapy Technique
Refers to all stake holders in the project
Works based on the model
Intake Meaning Significance Response
Stake Holder 1 Stake Holder 2 …………
Requirements #1 Intake/Idea
Meaning
Significance
Responses/Consolidations
Requirements #2 Intake/Idea
Meaning
Significance
Responses/Consolidations
58. REQUIREMENTS GATHERING TECHNIQUES
Reusing Requirements Technique
Multiple things are present for single common purpose
Two or more modules have same functionality
Re-use the functionality and save the time
Videos & Photographs Technique
Applies to all type of requirements
When we are not able to understand the requirements
Re-visit the videos & photographs and get more clarity
Prototyping Technique
Screens mock ups visualize application
Present to customer
Make sure we and customer having same understanding
Prototype functionality not how/what code
Data flow functionality overview
61. REQUIREMENTS IMPORTANCE
Requirements Gathering is
about info transferring and sharing
Requirements Document is
the project Contract between users & developers
Requirements Document is
the first draft of the Project Plan
Requirements Document is
used throughout the project from start to delivery by all
stakeholders (planning, designing, mockups, testing, acceptance)
62. REQUIREMENTS MEANING
The Requirements Document is…
The Business coded version of …
The User’s Specifications written using…
The Human Programming Language!
63. WHAT SHOULD THE BA RECORD?
Stakeholders
Include stakeholders names, titles & signatures
Role in requirements gathering
Role in approval
Problem Statement
Brief idea about the purpose of the project
Overview of problem background & impact of implementation
Business Goals
Helps developer and business stakeholders understanding
the goal of the project & sharing the same view
64. WHAT SHOULD THE BA RECORD?
Scope
Cleary states what the proposed solution will cover & what it
won’t
Determines In Scope & Out of Scope requirements
Assumptions
Helps all stakeholders viewing, as much as possible, the
requirement from the same viewpoint
May include business, technical & planning assumptions
Constraints & Risks
Identifies problems facing product implementation at early
stages
Facilitates decision making & project planning
May be business and/or technical
65. WHAT SHOULD THE BA RECORD?
Pre-requisites
Define project dependencies
Project will not be launched unless they exist
References
Refer to other helper systems or documentation
System Actors/Users
Define users who will have access to the system
Brief description about their roles
User/Actor Role Comments
Student Review Schedule
66. WHAT SHOULD THE BA RECORD?
Business Processes/Workflows
Describe the steps of the business processes
Use swim lanes presentation to illustrate the workflowExpenseReporting
AccountantManagerEmployee
Submit Expense
Report
Correct
Report
?
Issue Payment
Write Expense
Report
Sign
Yes
No
67. WHAT SHOULD THE BA RECORD?
Business ERD (Entity Relationship Diagram)
Relations between objects
Division Department
EmployeeProject
is
assigned
to
operates
employs
68. WHAT SHOULD THE BA RECORD?
Functional Requirements
Describe each role/function clearly
Functionality, fields & actions
Field
Name
Description Type
Linked
To
Default
Value
Constraint/
Validation
U
n
i
q
u
e
V
i
s
i
b
l
e
R
e
q
u
ir
e
d
Comments
Subject The name of the
subject
Text
Date … Date Should exclude
week ends
Time … Time
Action Name Description Type Comments
View Opens a new page with the details of the
schedule
Button Display a warning message to save changed
data
69. WHAT SHOULD THE BA RECORD?
Use Cases
“An end to end sequence of interactions between an
actor and a system that yields a result of observable
value to an actor”
Written as a flow or sequence of steps
Actor does something
System does something
Actor does something else
System does something else
Made up of one main flow and a number of alternate
and/or exception flows (some of which can branch back to
the main flow)
70. WHAT SHOULD THE BA RECORD?
Use Cases
Waiter
Client
Cashier
Chef
Order
Food
Serve
Food
Eat
Food
Pay for
Food
Order
Water
Cook
Food
Drink
Water
Pay for
Water
Serve
Water
Receive
order
Accept
payment
Pay
Facilitate
payment
Place
order
Confirm
order
<<extend>>
<<extend>>
<<extend>>
<<extend>>
{if water was
consumed}
{if water was
served}
{if water
was
ordered}
71. WHAT SHOULD THE BA RECORD?
User Stories (Agile Projects)
A tool to support the iterative and incremental approach
Provide a framework where the detail can be added as
it is needed, just enough and just in time
Sentences described in everyday or business language
Captures 'who', 'what' & 'why' of a requirement
Limited in detail by what can be hand-written on a small
paper notecard
73. WHAT SHOULD THE BA RECORD?
Reporting Requirements
What reports are needed
Business need
Report name, filters, output, header, footer
GUI Requirements
Describes the needed user graphical interface
Look & feel
74. WHAT SHOULD THE BA RECORD?
Non-functional Requirements
Hardware & software requirements
Performance, number of normal & concurrent users
Page response time
Usability, cultural aspects
Availability, reliability, maintainability, extensibility, security…
Open Issues/Pending Decision/Questions
Help getting quick & precise answers to vague requirements
ID Question Owner Type Answer Status Priority Open Date Target Date
36
Will all students have the
same schedule
view? SH1 Business clarification Yes Closed High 6-Jun 10-Jun
76. WHAT IS UX?
How a person feels when interfacing with a system
UX designers study and evaluate how users feel
about a system
Ease of use
Perception of the value of the system
Efficiency in performing tasks…
UX deals with users’ needs
77. WHERE DOES UX COME?
Business
System
Users
High Level
Detail
• Sponsor point of view
• Scope of the project
• Business objective
• User point of view
• User goals
• User inputs & outputs
• Functional
• Non-functional
79. EXAMPLE
App: Facebook
Feature: Invite friend(s) to an event
Requirements
Display the list of friends
Select friend(s) from the list
Confirm action
Cancel action
UX…
83. GUIDELINES:1
Focus & clarity
Clearly state the objective & define the scope
Clarify what the project does and does not cover
A format for specifying requirements
Use whichever method works for you
Understanding is the most important outcome
Not all formats of requirements documentation are equal
Requirements document author
Writing skills
Balance understanding the project domain against
understanding the process of software development
84. GUIDELINES:2
Requirements language
Use the same language as your client
If the language is consistent, it greatly lowers the risk of
requirements misinterpretation
Accuracy is critical
Accurately reflect client needs
Walk the client through the requirements
It costs more to fix things in testing than in the requirements
phase
Minimize the risk of errant interpretation
Ensure everyone has the same understanding
Use diagrams, pictures, or sample data illustrating
requirements meaning
86. TIPS:1
Build trust in your experience & knowledge
Understand the business domain
Act as a subject matter expert
Be your client’s consultant
Network and build relations
Set correct expectation
Give space for yourself
Never promise before getting back to your team
Educate your client
87. TIPS:2
Add value
Don’t just simulate what’s on the paper
Understand the goals/needs
Deliver an intelligent output
Suggest improvements
Challenge requirements with yourself then with your
client
88. TIPS:3
Convince & influence
Select your communication medium
Know what to say, when and to whom
Ask smart questions
Have empathy with your client and team members
89. TIPS:4
Protect the idea
Do whatever it takes to deliver the idea
Use visuals and illustrate with charts, WBS and
drawings
Make it easy to trace and understand things
Use examples and build scenarios
Keep the business goal in mind and explain it to
your team
90. TIPS:5
Ask for assistance & be aware
Refer to developers for advice, feasibility and
verification
Keep the PM updated
Understand the impact of additions on effort and
cost
Know when to say No!
91. TIPS:6
Dig deeper
Analyze, analyze, analyze
Think about ways to group similar components
Identify re-usable components and data
92. TIPS:7
Organize
Use mind maps
Track changes in your documents
Track versions and brief about change history
Document naming convention
93. TIPS:8
Plan
Your meetings
Your questions
When to discuss which features/requirements
Use reminders, emails, summaries, agendas and
meeting minutes
Prioritize in case of shortage in time and budget
94. TIPS:9
Be productive
Save your time and others’ time
Eliminate paper and pen usage
Document everything then select what to use
Share online
Minimize possibilities of re-work
Take lead and be in control
96. CONCLUSION
There is no silver bullet, no one answer, no perfect
approach method or technique to requirements
gathering
Developing a good requirements document is about
giving your project the best chance of success
To do so, you must reduce the risk of common mistakes
that arise from a lack of communication or
understanding
Keep this in mind as you gather your requirements that
project will have the best chance of success
98. ACTIVITIES
Meeting with client
Develop
Requirements document
Presentation for the top management approval
Review deliverables together
Evaluation
Team will evaluate each other
Mentor’s evaluation
99. WHAT WE WILL EVALUATE
Requirements
Taking care of all
requirements
Clearness of
requirements in head
Ability to answer
questions
Maintaining scope
Using examples
Adding value
Challenging input
Asking meaningful
questions
Management
On time delivery
Decision making
Signoff
Overall
Being productive
Maintaining
professional image
Ability to convince &
influence