Business requirements gathering and analysis

Mena M. Eissa
Mena M. EissaProject Manager/Mentor at Freelancer
BUSINESS REQUIREMENTS
By: Mena Mostafa Apr-2015
Gathering & Analysis Workshop
A key to project success
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
WHO ARE YOU?
 Introduce yourself
 What would you like to know?
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
SCHEDULE
The Theory
Break (30 mins)
The Workshop
Break (30 mins)
Review & Evaluation
 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
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
INTRODUCTION
Why Requirements Gathering & Analysis?
What Is Requirements Gathering?
Types of Software Projects
Requirements & Features
Types of Requirements
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…
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!
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)
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
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
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
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
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…
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
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
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!
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
COMMON ISSUES & CHALLENGES
Why Do Projects Fail?
Requirements Gathering Challenges
Requirements Volatility Causes
What Causes Changes to Requirements?
Scope Creep
The sooner you begin coding the later you
finish
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
REQUIREMENTS GATHERING
CHALLENGES
A user is somebody who tells you what they
want the day you give them what they
asked for
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
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
 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
“What if users developed their own applications?!”
What is not on paper has not been said
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
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)
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
WHO IS THE BUSINESS ANALYST?
The Analyst Job
Responsibilities
Business Analyst Qualifications
THE ANALYST JOB
 Demonstrate the ability and inclination to tolerate
 chaos
 ambiguity
 and lack of knowledge
 and to function effectively in spite of them
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
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
BUSINESS ANALYST QUALIFICATIONS
Technical
Analytical
Business
Management
Communication
BUSINESS ANALYST QUALIFICATIONS
Technical
Analytical
Business
Management
Communication
• Engineering systems
concepts and principles
• Technical computer
knowledge
• Complex modeling
techniques
• Technical writing
BUSINESS ANALYST QUALIFICATIONS
Technical
Analytical
Business
Management
Communication
• Details oriented
• Planning, documentation,
analysis and business
requirements management
techniques
• Evaluation of
profitability/risk
• Testing, verification and
validation techniques
BUSINESS ANALYST QUALIFICATIONS
Technical
Analytical
Business
Management
Communication
• Ability to have a business-
oriented vision
• Improvement of business
and engineering processes
• Strategic planning
• Business writing
BUSINESS ANALYST QUALIFICATIONS
Technical
Analytical
Business
Management
Communication
• Fundamentals of project
management
• Management of customer
relationships
• Time management &
personal organization skills
• Decision-making
BUSINESS ANALYST QUALIFICATIONS
Technical
Analytical
Business
Management
Communication
• Communication of
technical information to a
non-technical audience
• Communication of
business information to a
technical audience
• Negotiation
• Tact
HOW TO DO THE JOB?
Software Development Lifecycle (SDLC)
Requirements Management Process
Requirements Gathering Activities
Change Management
Requirements Traceability
Signoff
SOFTWARE DEVELOPMENT LIFECYCLE (SDLC)
REQUIREMENTS MANAGEMENT PROCESS
Elicitation
Analysis
Recording
Validation
Change Management
Traceability
Signoff
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
A user will tell you anything you ask about,
but nothing more
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
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
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
REQUIREMENTS GATHERING
TECHNIQUES
Requirements are the What
Design is the How
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…
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
REQUIREMENTS GATHERING TECHNIQUES
 Apprenticing Technique
Observes the
business users
Understands the day
to day activities
Capture/documents
the requirements
Get signoff from
customer
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
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
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
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
RELATIVE STRENGTHS IN REQUIREMENTS
GATHERING TECHNIQUES
: Limited Effectiveness
: Effective
: Very Effective
TECHNIQUE CONSCIOUS UNCONSCIOUS UNDREAMED
Apprenticing      
Brainstorming     
Mind Mapping       
Use Case Workshops       
Interviewing      
Family Therapy     
Reusing Requirements     
Videos & Photographs      
Prototyping       
HOW TO DOCUMENT
REQUIREMENTS?
Requirements Importance
Requirements Meaning
What Should the BA Record?
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)
REQUIREMENTS MEANING
The Requirements Document is…
The Business coded version of …
The User’s Specifications written using…
The Human Programming Language!
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
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
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
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
WHAT SHOULD THE BA RECORD?
 Business ERD (Entity Relationship Diagram)
 Relations between objects
Division Department
EmployeeProject
is
assigned
to
operates
employs
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
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)
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}
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
WHAT SHOULD THE BA RECORD?
 User Stories (Agile Projects)
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
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
MATCHING REQUIREMENTS WITH
USER EXPERIENCE
What Is UX?
Where Does UX Come?
Elements of UX Design
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
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
ELEMENTS OF UX DESIGN
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…
EXAMPLE
Filter
Status info
Already invited
Selected Count
TOWARDS A BETTER OUTPUT
Guidelines
Tips
GUIDELINES
Users don't know what they want until you show it to them
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
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
TIPS
You never realize until you’ve been there!
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
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
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
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
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!
TIPS:6
Dig deeper
 Analyze, analyze, analyze
 Think about ways to group similar components
 Identify re-usable components and data
TIPS:7
Organize
 Use mind maps
 Track changes in your documents
 Track versions and brief about change history
 Document naming convention
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
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
CONCLUSION
Continuous effort to improve the quality of software
development activities
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
THE WORKSHOP
No physician is really good before he has killed one or two
patients
~Hindu Proverb
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
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
LET’S GO!
LET’S KEEP IN TOUCH
 Twitter: @menameissa
 Blog: A Project Manager’s Diary
 Slide Share presentation:
http://www.slideshare.net/menameissa/business-
requirements-gathering-and-analysis
THANK YOU
REFERENCES
The credit goes to…
REFERENCES
 http://www.techwr-
l.com/techwhirl/magazine/writing/softwarerequirementspecs.html
 http://www.code-magazine.com/Article.aspx?quickid=0102061
 http://www.codeproject.com/useritems/Requirement_Gathering.asp
 http://www.umsl.edu/~sauterv/analysis/random_analysis_thoughts.html
 http://www.project-portfolio-management-blog.com/2007/03/13/getting-the-
project-requirements-right/
 http://en.wikipedia.org/wiki/Requirements_analysis
 http://www.sitepoint.com/article/requirements-gathering
 http://www.bajob.ca/businessanalyst-job/business-analyst-skills-a4.html
 http://www.esi-intl.com/courses-and-certifications/courses/project-
management/requirements-management-a-key-to-project-success
 http://johnnyholland.org/2011/06/matching-requirements-with-user-
experience/
REFERENCES
 http://smallbusiness.chron.com/functional-requirements-vs-business-requirements-
65938.html
 http://www.advstr.com/web/resources/downloads/Defining_Requirements.pdf
 http://www.accompa.com/kb/answer.html?answer_id=170
 http://rmblog.accompa.com/2012/06/features-vs-use-cases-vs-requirements/
 http://www.businessanalystsolutions.com/what_is_a_business_analyst.html
 http://www.villanovau.com/resources/business-analysis/business-analyst-job-
description/#.VSqagRCUftI
 http://en.wikipedia.org/wiki/Verification_and_tion
 http://www.ppmstudio.com/Solutions_ApplicationLifecycleManagement.aspx
 http://www.iai.uni-
bonn.de/III/lehre/vorlesungen/SWT/RE05/slides/08_Requirements%20Manageme
nt.pdf
 http://www.projectsmart.co.uk/smart-goals.php
 http://www.wikihow.com/Write-a-Requirements-Document
 http://www.bridging-the-gap.com/what-requirements-specifications-do-business-
analysts-create/
REFERENCES
 http://www.conceptdraw.com/How-To-Guide/swim-lane
 http://info.slis.indiana.edu/~dingying/Teaching/S511/new/labs/lab5.htm
 http://en.wikipedia.org/wiki/Scope_creep
 http://pmblog.accompa.com/2009/09/22/use-cases-top-10-reasons-for-using-them-
to-document-your-requirements/
 http://en.wikipedia.org/wiki/User_story
 http://www.batimes.com/articles/user-stories-and-use-cases-dont-use-both.html
 http://en.wikipedia.org/wiki/Use_case
 http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html
 http://www.smashingmagazine.com/2010/10/05/what-is-user-experience-design-
overview-tools-and-resources/
 http://usabilitygeek.com/requirements-gathering-user-experience-pt1/
 http://www.bridging-the-gap.com/what-a-ba-should-know-about-the-ux-profession-
interview-with-patrick-quattlebaum/
 https://www.pinterest.com/pin/222294931583422543/
 http://www.liquid-code.net/
 http://www.quotegarden.com/experience.html
1 of 106

Recommended

Agile Requirements Gathering Techniques by
Agile Requirements Gathering TechniquesAgile Requirements Gathering Techniques
Agile Requirements Gathering TechniquesOnur Demir
6.7K views22 slides
Gathering requirements by
Gathering requirementsGathering requirements
Gathering requirementsDoan Truong Giang
1.9K views19 slides
Requirement and Specification by
Requirement and SpecificationRequirement and Specification
Requirement and Specificationsarojsaroza
1.5K views16 slides
Business requirements documents by
Business requirements documentsBusiness requirements documents
Business requirements documentshapy
66.2K views15 slides
Requirement Elicitation Techniques by
Requirement Elicitation TechniquesRequirement Elicitation Techniques
Requirement Elicitation TechniquesShwetha-BA
4.7K views38 slides
Business user requirements for it development by
Business user requirements for it developmentBusiness user requirements for it development
Business user requirements for it developmentSimon Misiewicz
3.6K views27 slides

More Related Content

What's hot

REQUIREMENT ENGINEERING by
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGSaqib Raza
13.5K views37 slides
Requirements Engineering by
Requirements EngineeringRequirements Engineering
Requirements EngineeringBenoy Ramachandran
17K views56 slides
Software quality assurance by
Software quality assuranceSoftware quality assurance
Software quality assuranceAman Adhikari
51.3K views30 slides
Requirement Writing for Product Management by
Requirement Writing for Product ManagementRequirement Writing for Product Management
Requirement Writing for Product ManagementNainil Chheda
8.2K views43 slides
Requirements Management by
Requirements ManagementRequirements Management
Requirements ManagementMohamed Mobarak
14.6K views58 slides
Software requirement and specification by
Software requirement and specificationSoftware requirement and specification
Software requirement and specificationAman Adhikari
19.1K views60 slides

What's hot(20)

REQUIREMENT ENGINEERING by Saqib Raza
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
Saqib Raza13.5K views
Software quality assurance by Aman Adhikari
Software quality assuranceSoftware quality assurance
Software quality assurance
Aman Adhikari51.3K views
Requirement Writing for Product Management by Nainil Chheda
Requirement Writing for Product ManagementRequirement Writing for Product Management
Requirement Writing for Product Management
Nainil Chheda8.2K views
Software requirement and specification by Aman Adhikari
Software requirement and specificationSoftware requirement and specification
Software requirement and specification
Aman Adhikari19.1K views
8 Most Effective Requirements Gathering Techniques. by Xebrio
8 Most Effective Requirements Gathering Techniques.8 Most Effective Requirements Gathering Techniques.
8 Most Effective Requirements Gathering Techniques.
Xebrio1.4K views
Non functional requirements. do we really care…? by OSSCube
Non functional requirements. do we really care…?Non functional requirements. do we really care…?
Non functional requirements. do we really care…?
OSSCube16K views
Requirement elicitation by vivacemente
Requirement elicitationRequirement elicitation
Requirement elicitation
vivacemente20.6K views
Lecture4 requirement engineering by Shahid Riaz
Lecture4 requirement engineeringLecture4 requirement engineering
Lecture4 requirement engineering
Shahid Riaz3.8K views
Requirements Gathering Best Practice Pack by Amy Slater
Requirements Gathering Best Practice PackRequirements Gathering Best Practice Pack
Requirements Gathering Best Practice Pack
Amy Slater25K views
Software Engineering- Requirement Elicitation and Specification by Nishu Rastogi
Software Engineering- Requirement Elicitation and SpecificationSoftware Engineering- Requirement Elicitation and Specification
Software Engineering- Requirement Elicitation and Specification
Nishu Rastogi7K views
Requirement Elicitation by Ravikanth-BA
Requirement ElicitationRequirement Elicitation
Requirement Elicitation
Ravikanth-BA2.7K views
Requirement Elicitation Techniques/Methods by SUFYAN SATTAR
Requirement Elicitation Techniques/MethodsRequirement Elicitation Techniques/Methods
Requirement Elicitation Techniques/Methods
SUFYAN SATTAR1.1K views
Rational Unified Process by Kumar
Rational Unified ProcessRational Unified Process
Rational Unified Process
Kumar 4.5K views
Requirements analysis by asimnawaz54
Requirements analysisRequirements analysis
Requirements analysis
asimnawaz5446.8K views

Viewers also liked

Understanding THE GOAL: The best-seller by Eli Goldratt and Jeff Cox by
Understanding THE GOAL: The best-seller by Eli Goldratt and Jeff CoxUnderstanding THE GOAL: The best-seller by Eli Goldratt and Jeff Cox
Understanding THE GOAL: The best-seller by Eli Goldratt and Jeff CoxAGI - Goldratt Institute
303.9K views37 slides
Sample Business Requirement Document by
Sample Business Requirement DocumentSample Business Requirement Document
Sample Business Requirement DocumentIsabel Elaine Leong
182.2K views11 slides
Sample Project Requirements Document – Library Blog by
Sample Project Requirements Document – Library BlogSample Project Requirements Document – Library Blog
Sample Project Requirements Document – Library BlogALATechSource
212.3K views4 slides
Srs present by
Srs presentSrs present
Srs presentVidyas Gnanasekaram
8.6K views26 slides
Distributed User Interfaces: How to Distribute User Interface Elements across... by
Distributed User Interfaces: How to Distribute User Interface Elements across...Distributed User Interfaces: How to Distribute User Interface Elements across...
Distributed User Interfaces: How to Distribute User Interface Elements across...Serenoa Project
5.4K views51 slides
Other requirements, requirement specification and map by
Other requirements, requirement specification and mapOther requirements, requirement specification and map
Other requirements, requirement specification and mapcsk selva
1.1K views18 slides

Viewers also liked(20)

Understanding THE GOAL: The best-seller by Eli Goldratt and Jeff Cox by AGI - Goldratt Institute
Understanding THE GOAL: The best-seller by Eli Goldratt and Jeff CoxUnderstanding THE GOAL: The best-seller by Eli Goldratt and Jeff Cox
Understanding THE GOAL: The best-seller by Eli Goldratt and Jeff Cox
Sample Project Requirements Document – Library Blog by ALATechSource
Sample Project Requirements Document – Library BlogSample Project Requirements Document – Library Blog
Sample Project Requirements Document – Library Blog
ALATechSource212.3K views
Distributed User Interfaces: How to Distribute User Interface Elements across... by Serenoa Project
Distributed User Interfaces: How to Distribute User Interface Elements across...Distributed User Interfaces: How to Distribute User Interface Elements across...
Distributed User Interfaces: How to Distribute User Interface Elements across...
Serenoa Project5.4K views
Other requirements, requirement specification and map by csk selva
Other requirements, requirement specification and mapOther requirements, requirement specification and map
Other requirements, requirement specification and map
csk selva1.1K views
Innovation Benefits Realization for Industrial Research (Part-3) by Iain Sanders
Innovation Benefits Realization for Industrial Research (Part-3)Innovation Benefits Realization for Industrial Research (Part-3)
Innovation Benefits Realization for Industrial Research (Part-3)
Iain Sanders1K views
White Paper: Application Modernization by EMC
White Paper: Application Modernization  White Paper: Application Modernization
White Paper: Application Modernization
EMC4.9K views
Business Requirements Gathering - Current & Future State by Jason Bargent
Business Requirements Gathering - Current & Future StateBusiness Requirements Gathering - Current & Future State
Business Requirements Gathering - Current & Future State
Jason Bargent9.8K views
Online property management system design document by Abhilasha Lahigude
Online property management system design documentOnline property management system design document
Online property management system design document
Abhilasha Lahigude70.6K views
Project Business Requirements Document by Joshua Flewelling
Project Business Requirements DocumentProject Business Requirements Document
Project Business Requirements Document
Joshua Flewelling49.5K views
Business Analysis Techniques by IIBA UK Chapter
Business Analysis TechniquesBusiness Analysis Techniques
Business Analysis Techniques
IIBA UK Chapter131.4K views
Example requirements specification by indrisrozas
Example requirements specificationExample requirements specification
Example requirements specification
indrisrozas140.4K views
Business Analysis Fundamentals by waelsaid75
Business Analysis FundamentalsBusiness Analysis Fundamentals
Business Analysis Fundamentals
waelsaid7581.6K views
Business Analyst Training by Craig Brown
Business  Analyst  TrainingBusiness  Analyst  Training
Business Analyst Training
Craig Brown43.9K views
Event Management System Document by LJ PROJECTS
Event Management System Document Event Management System Document
Event Management System Document
LJ PROJECTS149.7K views
Hospital management system(database) by Iftikhar Ahmad
Hospital management system(database)Hospital management system(database)
Hospital management system(database)
Iftikhar Ahmad184.1K views

Similar to Business requirements gathering and analysis

CIB 3103: Requirements Capture by
CIB 3103: Requirements CaptureCIB 3103: Requirements Capture
CIB 3103: Requirements CaptureAhmad Ammari
1K views31 slides
Agile Manifesto & XP by
Agile Manifesto & XPAgile Manifesto & XP
Agile Manifesto & XPSemen Arslan
1.1K views51 slides
Project management concepts by
Project management conceptsProject management concepts
Project management conceptsNayyabMirTahir
108 views33 slides
Business Analyst_PennonSoft by
Business Analyst_PennonSoftBusiness Analyst_PennonSoft
Business Analyst_PennonSoftPennonSoft
387 views20 slides
Requirement Engineering.ppt by
Requirement Engineering.pptRequirement Engineering.ppt
Requirement Engineering.pptDrTThendralCompSci
130 views33 slides
Requirement Engineering Processes & Eliciting Requirement by
Requirement Engineering Processes & Eliciting Requirement Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement AqsaHayat3
99 views28 slides

Similar to Business requirements gathering and analysis(20)

CIB 3103: Requirements Capture by Ahmad Ammari
CIB 3103: Requirements CaptureCIB 3103: Requirements Capture
CIB 3103: Requirements Capture
Ahmad Ammari1K views
Agile Manifesto & XP by Semen Arslan
Agile Manifesto & XPAgile Manifesto & XP
Agile Manifesto & XP
Semen Arslan1.1K views
Business Analyst_PennonSoft by PennonSoft
Business Analyst_PennonSoftBusiness Analyst_PennonSoft
Business Analyst_PennonSoft
PennonSoft387 views
Requirement Engineering Processes & Eliciting Requirement by AqsaHayat3
Requirement Engineering Processes & Eliciting Requirement Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement
AqsaHayat399 views
BABoK V2 Requirements Elicitation (RE) by AMJAD SHAIKH
BABoK V2 Requirements Elicitation (RE)BABoK V2 Requirements Elicitation (RE)
BABoK V2 Requirements Elicitation (RE)
AMJAD SHAIKH4.1K views
What organisations are doing to nurture and grow a culture of high-performance by Marcio Sete
What organisations are doing to nurture and grow a culture of high-performanceWhat organisations are doing to nurture and grow a culture of high-performance
What organisations are doing to nurture and grow a culture of high-performance
Marcio Sete276 views
Requirements Engineering Process Improvement by Ian Sommerville
Requirements Engineering Process ImprovementRequirements Engineering Process Improvement
Requirements Engineering Process Improvement
Ian Sommerville4.1K views
Chp14 Tactical Execution by Chuong Nguyen
Chp14 Tactical ExecutionChp14 Tactical Execution
Chp14 Tactical Execution
Chuong Nguyen618 views
Run Learning Like a Business by William West
Run Learning Like a BusinessRun Learning Like a Business
Run Learning Like a Business
William West1.1K views
Downloads abc 2006 presentation downloads-ramesh_babu by Hem Rana
Downloads abc 2006   presentation downloads-ramesh_babuDownloads abc 2006   presentation downloads-ramesh_babu
Downloads abc 2006 presentation downloads-ramesh_babu
Hem Rana29 views
Integrating Ux And Agile by Daniel Jaeger
Integrating Ux And AgileIntegrating Ux And Agile
Integrating Ux And Agile
Daniel Jaeger726 views
Requirement Management.ppt by Soham De
Requirement Management.pptRequirement Management.ppt
Requirement Management.ppt
Soham De5 views

Recently uploaded

DSD-INT 2023 Thermobaricity in 3D DCSM-FM - taking pressure into account in t... by
DSD-INT 2023 Thermobaricity in 3D DCSM-FM - taking pressure into account in t...DSD-INT 2023 Thermobaricity in 3D DCSM-FM - taking pressure into account in t...
DSD-INT 2023 Thermobaricity in 3D DCSM-FM - taking pressure into account in t...Deltares
9 views26 slides
Winter '24 Release Chat.pdf by
Winter '24 Release Chat.pdfWinter '24 Release Chat.pdf
Winter '24 Release Chat.pdfmelbourneauuser
9 views20 slides
Citi TechTalk Session 2: Kafka Deep Dive by
Citi TechTalk Session 2: Kafka Deep DiveCiti TechTalk Session 2: Kafka Deep Dive
Citi TechTalk Session 2: Kafka Deep Diveconfluent
17 views60 slides
DSD-INT 2023 SFINCS Modelling in the U.S. Pacific Northwest - Parker by
DSD-INT 2023 SFINCS Modelling in the U.S. Pacific Northwest - ParkerDSD-INT 2023 SFINCS Modelling in the U.S. Pacific Northwest - Parker
DSD-INT 2023 SFINCS Modelling in the U.S. Pacific Northwest - ParkerDeltares
8 views16 slides
WebAssembly by
WebAssemblyWebAssembly
WebAssemblyJens Siebert
32 views18 slides
DSD-INT 2023 Wave-Current Interaction at Montrose Tidal Inlet System and Its ... by
DSD-INT 2023 Wave-Current Interaction at Montrose Tidal Inlet System and Its ...DSD-INT 2023 Wave-Current Interaction at Montrose Tidal Inlet System and Its ...
DSD-INT 2023 Wave-Current Interaction at Montrose Tidal Inlet System and Its ...Deltares
9 views32 slides

Recently uploaded(20)

DSD-INT 2023 Thermobaricity in 3D DCSM-FM - taking pressure into account in t... by Deltares
DSD-INT 2023 Thermobaricity in 3D DCSM-FM - taking pressure into account in t...DSD-INT 2023 Thermobaricity in 3D DCSM-FM - taking pressure into account in t...
DSD-INT 2023 Thermobaricity in 3D DCSM-FM - taking pressure into account in t...
Deltares9 views
Citi TechTalk Session 2: Kafka Deep Dive by confluent
Citi TechTalk Session 2: Kafka Deep DiveCiti TechTalk Session 2: Kafka Deep Dive
Citi TechTalk Session 2: Kafka Deep Dive
confluent17 views
DSD-INT 2023 SFINCS Modelling in the U.S. Pacific Northwest - Parker by Deltares
DSD-INT 2023 SFINCS Modelling in the U.S. Pacific Northwest - ParkerDSD-INT 2023 SFINCS Modelling in the U.S. Pacific Northwest - Parker
DSD-INT 2023 SFINCS Modelling in the U.S. Pacific Northwest - Parker
Deltares8 views
DSD-INT 2023 Wave-Current Interaction at Montrose Tidal Inlet System and Its ... by Deltares
DSD-INT 2023 Wave-Current Interaction at Montrose Tidal Inlet System and Its ...DSD-INT 2023 Wave-Current Interaction at Montrose Tidal Inlet System and Its ...
DSD-INT 2023 Wave-Current Interaction at Montrose Tidal Inlet System and Its ...
Deltares9 views
DSD-INT 2023 Simulating a falling apron in Delft3D 4 - Engineering Practice -... by Deltares
DSD-INT 2023 Simulating a falling apron in Delft3D 4 - Engineering Practice -...DSD-INT 2023 Simulating a falling apron in Delft3D 4 - Engineering Practice -...
DSD-INT 2023 Simulating a falling apron in Delft3D 4 - Engineering Practice -...
Deltares6 views
How to Make the Most of Regression and Unit Testing.pdf by Abhay Kumar
How to Make the Most of Regression and Unit Testing.pdfHow to Make the Most of Regression and Unit Testing.pdf
How to Make the Most of Regression and Unit Testing.pdf
Abhay Kumar10 views
DSD-INT 2023 3D hydrodynamic modelling of microplastic transport in lakes - J... by Deltares
DSD-INT 2023 3D hydrodynamic modelling of microplastic transport in lakes - J...DSD-INT 2023 3D hydrodynamic modelling of microplastic transport in lakes - J...
DSD-INT 2023 3D hydrodynamic modelling of microplastic transport in lakes - J...
Deltares7 views
DSD-INT 2023 Dam break simulation in Derna (Libya) using HydroMT_SFINCS - Prida by Deltares
DSD-INT 2023 Dam break simulation in Derna (Libya) using HydroMT_SFINCS - PridaDSD-INT 2023 Dam break simulation in Derna (Libya) using HydroMT_SFINCS - Prida
DSD-INT 2023 Dam break simulation in Derna (Libya) using HydroMT_SFINCS - Prida
Deltares17 views
DSD-INT 2023 Baseline studies for Strategic Coastal protection for Long Islan... by Deltares
DSD-INT 2023 Baseline studies for Strategic Coastal protection for Long Islan...DSD-INT 2023 Baseline studies for Strategic Coastal protection for Long Islan...
DSD-INT 2023 Baseline studies for Strategic Coastal protection for Long Islan...
Deltares10 views
Les nouveautés produit Neo4j by Neo4j
 Les nouveautés produit Neo4j Les nouveautés produit Neo4j
Les nouveautés produit Neo4j
Neo4j27 views
DSD-INT 2023 Next-Generation Flood Inundation Mapping for Taiwan - Delft3D FM... by Deltares
DSD-INT 2023 Next-Generation Flood Inundation Mapping for Taiwan - Delft3D FM...DSD-INT 2023 Next-Generation Flood Inundation Mapping for Taiwan - Delft3D FM...
DSD-INT 2023 Next-Generation Flood Inundation Mapping for Taiwan - Delft3D FM...
Deltares7 views
Applying Platform Engineering Thinking to Observability.pdf by Natan Yellin
Applying Platform Engineering Thinking to Observability.pdfApplying Platform Engineering Thinking to Observability.pdf
Applying Platform Engineering Thinking to Observability.pdf
Natan Yellin12 views
Cycleops - Automate deployments on top of bare metal.pptx by Thanassis Parathyras
Cycleops - Automate deployments on top of bare metal.pptxCycleops - Automate deployments on top of bare metal.pptx
Cycleops - Automate deployments on top of bare metal.pptx
Neo4j y GenAI by Neo4j
Neo4j y GenAI Neo4j y GenAI
Neo4j y GenAI
Neo4j35 views
Unmasking the Dark Art of Vectored Exception Handling: Bypassing XDR and EDR ... by Donato Onofri
Unmasking the Dark Art of Vectored Exception Handling: Bypassing XDR and EDR ...Unmasking the Dark Art of Vectored Exception Handling: Bypassing XDR and EDR ...
Unmasking the Dark Art of Vectored Exception Handling: Bypassing XDR and EDR ...
Donato Onofri643 views
Upgrading Incident Management with Icinga - Icinga Camp Milan 2023 by Icinga
Upgrading Incident Management with Icinga - Icinga Camp Milan 2023Upgrading Incident Management with Icinga - Icinga Camp Milan 2023
Upgrading Incident Management with Icinga - Icinga Camp Milan 2023
Icinga36 views

Business requirements gathering and analysis

  • 1. BUSINESS REQUIREMENTS By: Mena Mostafa Apr-2015 Gathering & Analysis Workshop A key to project success
  • 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
  • 5. SCHEDULE The Theory Break (30 mins) The Workshop Break (30 mins) Review & Evaluation
  • 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
  • 8. INTRODUCTION Why Requirements Gathering & Analysis? What Is Requirements Gathering? Types of Software Projects Requirements & Features Types of Requirements
  • 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
  • 22. The sooner you begin coding the later you finish
  • 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
  • 24. REQUIREMENTS GATHERING CHALLENGES A user is somebody who tells you what they want the day you give them what they asked for
  • 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
  • 28. “What if users developed their own applications?!”
  • 29. What is not on paper has not been said
  • 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
  • 38. BUSINESS ANALYST QUALIFICATIONS Technical Analytical Business Management Communication • Engineering systems concepts and principles • Technical computer knowledge • Complex modeling techniques • Technical writing
  • 39. BUSINESS ANALYST QUALIFICATIONS Technical Analytical Business Management Communication • Details oriented • Planning, documentation, analysis and business requirements management techniques • Evaluation of profitability/risk • Testing, verification and validation techniques
  • 40. BUSINESS ANALYST QUALIFICATIONS Technical Analytical Business Management Communication • Ability to have a business- oriented vision • Improvement of business and engineering processes • Strategic planning • Business writing
  • 41. BUSINESS ANALYST QUALIFICATIONS Technical Analytical Business Management Communication • Fundamentals of project management • Management of customer relationships • Time management & personal organization skills • Decision-making
  • 42. BUSINESS ANALYST QUALIFICATIONS Technical Analytical Business Management Communication • Communication of technical information to a non-technical audience • Communication of business information to a technical audience • Negotiation • Tact
  • 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
  • 59. RELATIVE STRENGTHS IN REQUIREMENTS GATHERING TECHNIQUES : Limited Effectiveness : Effective : Very Effective TECHNIQUE CONSCIOUS UNCONSCIOUS UNDREAMED Apprenticing       Brainstorming      Mind Mapping        Use Case Workshops        Interviewing       Family Therapy      Reusing Requirements      Videos & Photographs       Prototyping       
  • 60. HOW TO DOCUMENT REQUIREMENTS? Requirements Importance Requirements Meaning What Should the BA Record?
  • 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
  • 72. WHAT SHOULD THE BA RECORD?  User Stories (Agile Projects)
  • 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
  • 75. MATCHING REQUIREMENTS WITH USER EXPERIENCE What Is UX? Where Does UX Come? Elements of UX Design
  • 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
  • 78. ELEMENTS OF UX DESIGN
  • 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…
  • 81. TOWARDS A BETTER OUTPUT Guidelines Tips
  • 82. GUIDELINES Users don't know what they want until you show it to them
  • 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
  • 85. TIPS You never realize until you’ve been there!
  • 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
  • 95. CONCLUSION Continuous effort to improve the quality of software development activities
  • 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
  • 97. THE WORKSHOP No physician is really good before he has killed one or two patients ~Hindu Proverb
  • 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
  • 101. LET’S KEEP IN TOUCH  Twitter: @menameissa  Blog: A Project Manager’s Diary  Slide Share presentation: http://www.slideshare.net/menameissa/business- requirements-gathering-and-analysis
  • 104. REFERENCES  http://www.techwr- l.com/techwhirl/magazine/writing/softwarerequirementspecs.html  http://www.code-magazine.com/Article.aspx?quickid=0102061  http://www.codeproject.com/useritems/Requirement_Gathering.asp  http://www.umsl.edu/~sauterv/analysis/random_analysis_thoughts.html  http://www.project-portfolio-management-blog.com/2007/03/13/getting-the- project-requirements-right/  http://en.wikipedia.org/wiki/Requirements_analysis  http://www.sitepoint.com/article/requirements-gathering  http://www.bajob.ca/businessanalyst-job/business-analyst-skills-a4.html  http://www.esi-intl.com/courses-and-certifications/courses/project- management/requirements-management-a-key-to-project-success  http://johnnyholland.org/2011/06/matching-requirements-with-user- experience/
  • 105. REFERENCES  http://smallbusiness.chron.com/functional-requirements-vs-business-requirements- 65938.html  http://www.advstr.com/web/resources/downloads/Defining_Requirements.pdf  http://www.accompa.com/kb/answer.html?answer_id=170  http://rmblog.accompa.com/2012/06/features-vs-use-cases-vs-requirements/  http://www.businessanalystsolutions.com/what_is_a_business_analyst.html  http://www.villanovau.com/resources/business-analysis/business-analyst-job- description/#.VSqagRCUftI  http://en.wikipedia.org/wiki/Verification_and_tion  http://www.ppmstudio.com/Solutions_ApplicationLifecycleManagement.aspx  http://www.iai.uni- bonn.de/III/lehre/vorlesungen/SWT/RE05/slides/08_Requirements%20Manageme nt.pdf  http://www.projectsmart.co.uk/smart-goals.php  http://www.wikihow.com/Write-a-Requirements-Document  http://www.bridging-the-gap.com/what-requirements-specifications-do-business- analysts-create/
  • 106. REFERENCES  http://www.conceptdraw.com/How-To-Guide/swim-lane  http://info.slis.indiana.edu/~dingying/Teaching/S511/new/labs/lab5.htm  http://en.wikipedia.org/wiki/Scope_creep  http://pmblog.accompa.com/2009/09/22/use-cases-top-10-reasons-for-using-them- to-document-your-requirements/  http://en.wikipedia.org/wiki/User_story  http://www.batimes.com/articles/user-stories-and-use-cases-dont-use-both.html  http://en.wikipedia.org/wiki/Use_case  http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html  http://www.smashingmagazine.com/2010/10/05/what-is-user-experience-design- overview-tools-and-resources/  http://usabilitygeek.com/requirements-gathering-user-experience-pt1/  http://www.bridging-the-gap.com/what-a-ba-should-know-about-the-ux-profession- interview-with-patrick-quattlebaum/  https://www.pinterest.com/pin/222294931583422543/  http://www.liquid-code.net/  http://www.quotegarden.com/experience.html