Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Understanding THE GOAL: The best-seller by Eli Goldratt and Jeff Cox



Business requirements gathering and analysis

Business analysis and requirements management are a key to project success.

This workshop helps candidates perform better based on sharing real life experience with them.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Business requirements gathering and analysis

  1. 1. BUSINESS REQUIREMENTS By: Mena Mostafa Apr-2015 Gathering & Analysis Workshop A key to project success
  2. 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. 3. WHO ARE YOU?  Introduce yourself  What would you like to know?
  4. 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. 5. SCHEDULE The Theory Break (30 mins) The Workshop Break (30 mins) Review & Evaluation
  6. 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. 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. 8. INTRODUCTION Why Requirements Gathering & Analysis? What Is Requirements Gathering? Types of Software Projects Requirements & Features Types of Requirements
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. COMMON ISSUES & CHALLENGES Why Do Projects Fail? Requirements Gathering Challenges Requirements Volatility Causes What Causes Changes to Requirements? Scope Creep
  22. 22. The sooner you begin coding the later you finish
  23. 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. 24. REQUIREMENTS GATHERING CHALLENGES A user is somebody who tells you what they want the day you give them what they asked for
  25. 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. 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. 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. 28. “What if users developed their own applications?!”
  29. 29. What is not on paper has not been said
  30. 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. 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. 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. 33. WHO IS THE BUSINESS ANALYST? The Analyst Job Responsibilities Business Analyst Qualifications
  34. 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. 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. 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. 37. BUSINESS ANALYST QUALIFICATIONS Technical Analytical Business Management Communication
  38. 38. BUSINESS ANALYST QUALIFICATIONS Technical Analytical Business Management Communication • Engineering systems concepts and principles • Technical computer knowledge • Complex modeling techniques • Technical writing
  39. 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. 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. 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. 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. 43. HOW TO DO THE JOB? Software Development Lifecycle (SDLC) Requirements Management Process Requirements Gathering Activities Change Management Requirements Traceability Signoff
  45. 45. REQUIREMENTS MANAGEMENT PROCESS Elicitation Analysis Recording Validation Change Management Traceability Signoff
  46. 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. 47. A user will tell you anything you ask about, but nothing more
  48. 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. 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. 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. 51. REQUIREMENTS GATHERING TECHNIQUES Requirements are the What Design is the How
  52. 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. 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. 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. 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. 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. 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. 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. 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. 60. HOW TO DOCUMENT REQUIREMENTS? Requirements Importance Requirements Meaning What Should the BA Record?
  61. 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. 62. REQUIREMENTS MEANING The Requirements Document is… The Business coded version of … The User’s Specifications written using… The Human Programming Language!
  63. 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. 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. 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. 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. 67. WHAT SHOULD THE BA RECORD?  Business ERD (Entity Relationship Diagram)  Relations between objects Division Department EmployeeProject is assigned to operates employs
  68. 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. 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. 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. 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. 72. WHAT SHOULD THE BA RECORD?  User Stories (Agile Projects)
  73. 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. 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. 75. MATCHING REQUIREMENTS WITH USER EXPERIENCE What Is UX? Where Does UX Come? Elements of UX Design
  76. 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. 77. WHERE DOES UX COME? Business System Users High Level Detail • Sponsor point of view • Scope of the project • Business objective • User point of view • User goals • User inputs & outputs • Functional • Non-functional
  79. 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. 80. EXAMPLE Filter Status info Already invited Selected Count
  81. 81. TOWARDS A BETTER OUTPUT Guidelines Tips
  82. 82. GUIDELINES Users don't know what they want until you show it to them
  83. 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. 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. 85. TIPS You never realize until you’ve been there!
  86. 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. 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. 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. 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. 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. 91. TIPS:6 Dig deeper  Analyze, analyze, analyze  Think about ways to group similar components  Identify re-usable components and data
  92. 92. TIPS:7 Organize  Use mind maps  Track changes in your documents  Track versions and brief about change history  Document naming convention
  93. 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. 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. 95. CONCLUSION Continuous effort to improve the quality of software development activities
  96. 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. 97. THE WORKSHOP No physician is really good before he has killed one or two patients ~Hindu Proverb
  98. 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. 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. 100. LET’S GO!
  101. 101. LET’S KEEP IN TOUCH  Twitter: @menameissa  Blog: A Project Manager’s Diary  Slide Share presentation: requirements-gathering-and-analysis
  102. 102. THANK YOU
  103. 103. REFERENCES The credit goes to…
  104. 104. REFERENCES  http://www.techwr-     project-requirements-right/     management/requirements-management-a-key-to-project-success  experience/
  105. 105. REFERENCES  65938.html      description/#.VSqagRCUftI    http://www.iai.uni- nt.pdf    analysts-create/
  106. 106. REFERENCES     to-document-your-requirements/      overview-tools-and-resources/   interview-with-patrick-quattlebaum/   
  • Timmery

    Sep. 23, 2021
  • AnilJayaprakash

    Sep. 6, 2021
  • TheresaPagdanganan

    Aug. 23, 2021
  • PrabhuK36

    Aug. 15, 2021
  • arlynne

    Aug. 8, 2021
  • SyedAfaqueAkhtar

    Jun. 30, 2021
  • majupevi

    Jun. 20, 2021
  • TrngThyHng

    Jun. 10, 2021
  • WaleedAbdellatif1

    May. 7, 2021
  • OsaMaMohaMed58

    May. 3, 2021
  • DarrynWarner1

    Apr. 23, 2021
  • GenevieveOjas

    Apr. 22, 2021
  • dinaibrahim12

    Apr. 22, 2021
  • MohamedAli273

    Apr. 22, 2021
  • SophiaPiccoli

    Mar. 24, 2021

    Mar. 10, 2021
  • KifleworkDinku1

    Mar. 5, 2021
  • ZufaKanwal

    Mar. 5, 2021
  • EdgetEdget

    Feb. 22, 2021
  • LottieYinka

    Jan. 3, 2021

Business analysis and requirements management are a key to project success. This workshop helps candidates perform better based on sharing real life experience with them.


Total views


On Slideshare


From embeds


Number of embeds