This document outlines a workshop led by Mena Mostafa on business requirements gathering and analysis, emphasizing its importance in project management for software development. It covers techniques, challenges, and roles associated with business analysts, along with the relationship between business and functional requirements. The workshop aims to provide participants with practical insights and tools for successful requirements management to ensure project success.

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

37. BUSINESS ANALYST QUALIFICATIONS
Technical
Analytical
Business
Management
Communication

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

44. SOFTWARE DEVELOPMENT LIFECYCLE (SDLC)

45. REQUIREMENTS MANAGEMENT PROCESS
Elicitation
Analysis
Recording
Validation
Change Management
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

51. REQUIREMENTS GATHERING
TECHNIQUES
Requirements are the What
Design is the How

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…

80. EXAMPLE
Filter
Status info
Already invited
Selected Count

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

100. LET’S GO!

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

102. THANK YOU

103. REFERENCES
The credit goes to…

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