Business Analysis - Essentials


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Business Analysis - Essentials

  1. 1. Fundamentals of BUSINESS ANALYSIS Global Knowledge, March 2011 Barbara BermesThursday, February 16, 2012
  2. 2. Overview ✤ Role of a BA - Solving “the problem” ✤ Business Analysis as part of a Project ✤ Eclication (Techniques) ✤ Stakeholders and Stakeholders Profiles ✤ Vision and Scope Document ✤ Business Needs & Business Requirements ✤ BRD - Business Requirements Document ✤ Business Plan ✤ How to apply all of this to CBCThursday, February 16, 2012
  3. 3. Before we start... ✤ Have you ever worked on a project that was understood like this....Thursday, February 16, 2012
  4. 4. A project: from concept to deliveryThursday, February 16, 2012
  5. 5. CHAOS Report ✤ Common Reasons for Project Failure ✤ Incomplete requirements ✤ Changing requirements ✤ A requirement is something that a particular solution (product or service) must have to ensure successThursday, February 16, 2012
  6. 6. So why do we need BAs? ✤ To help identify the problem ✤ Need to understand all aspects of the solution ✤ To suggest a solution of the problem ✤ How things are (as-is) and how they should be (to-be) ✤ To meet the business needs related to the problem ✤ Represent users to development team ✤ Bridge between the business and the stakeholders ✤ Filter wishes from actual requirementsThursday, February 16, 2012
  7. 7. The Definition of Business Analysis ✤ “Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals” (The BABOK Guide, Business Analysis Body of Knowlegde)Thursday, February 16, 2012
  8. 8. BA, PM, SA Role Primary Focus Example Project Manager Project Budget, schedule Value business results, Business Analyst Business needs product/service provided System Analyst Technical solution SpecificationsThursday, February 16, 2012
  9. 9. Knowledge Areas of a BAThursday, February 16, 2012
  10. 10. BA Tasks ✤ Vision and Scope Document ✤ Planning requirement activities ✤ Requirements Elicitation ✤ Analyzing requirements ✤ Documenting requirements ✤ Verifying and Validation requirements ✤ Final testing of the solution ✤ Find solution to meet organizational goalsThursday, February 16, 2012
  11. 11. Definition of Requirement 1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents 3. A documented presentation of a condition or capability as in (1) or (2) - The BABOK GuideThursday, February 16, 2012
  12. 12. Requirements Planning: Vision and Scope Document ✤ Current state and desired state from the business perspective ✤ In-scope and out-of-scope solution features ✤ Puts the solution in the business contextThursday, February 16, 2012
  13. 13. Requirements Planning: Vision and Scope Document ✤ Background: Need for solution ✤ Users and Stakeholders ✤ Vision Statement: How stakeholders envision the solution, purpose and intent ✤ In/Out Scope Features ✤ Assumptions, add some degree of risks ✤ Constraints ✤ Risks, Business, Financial, Technical, including Risk Mitigation, contingencyThursday, February 16, 2012
  14. 14. Stakeholders ✤ Sponsor ✤ Domain SME ✤ Business Analyst ✤ Implementation SME ✤ Project Manager ✤ Tester ✤ Customer ✤ Regulator ✤ End User ✤ SupplierThursday, February 16, 2012
  15. 15. Stakeholder Profiles ✤ Demographics ✤ Location ✤ Role and responsibilities ✤ Special needs ✤ Solutions attitude ✤ Name and Title ✤ Number ✤ Solution influence ✤ AuthorityThursday, February 16, 2012
  16. 16. Requirements Elicitation ✤ Elicitation is not requirements gathering (implies that requirements already exist) ✤ Merriam-Webster Online Dictionary, elicitation means: ✤ To draw forth or bring out (something latent or potential) ✤ To call forth or draw out (as information or a response)Thursday, February 16, 2012
  17. 17. Elicitation Techniques Preplanning Preparation Closing ExecutionThursday, February 16, 2012
  18. 18. Peoples Techniques ✤ People techniques are used when your resource for requirements is a person ✤ Each person poses different challengesThursday, February 16, 2012
  19. 19. Techniques Technique When/Advantage need general information about requirements, want Interview stakeholders to explain their needs, conflicting req. want to gauge users’ attitude and preferences Focus Group towards solution or current situation Need requirment consensus on noncontroversial Requirements Workshop issues, want to generate ideas, review requirments creative, innovative solutions (large number of Brainstorming solutions) Need to learn about user’s environment, need to understand Observation workflow, need information that user can’t provide fully Only short time, have a lot of remote users to Survey contact, need statistical and survey writing abilities Identify usability issues, concrete representation of Prototyping the proposed solution to elicit feedback see how competitors solve the problem, see if COTS Product Trials (commercial off-the-shelf) product might be the solutionThursday, February 16, 2012
  20. 20. Select Techniques ✤ Always consider these three factors ✤ Stakeholders ✤ Requirement type ✤ Product geographyThursday, February 16, 2012
  21. 21. Using Models for Analysis ✤ Model: A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication and understanding (The BABOK Guide)Thursday, February 16, 2012
  22. 22. Models/Diagrams ✤ Organizational Model: to show stakeholders connections, roles, help to understand the scope of the organization ✤ Location Model: show geographical locations and facilities ✤ Process Model: show business process, ✤ Visual presentation of the order, flow, and logic that controls a set of activities or actions, ✤ Excellent to show as-is and to-be stateThursday, February 16, 2012
  23. 23. Models ✤ Use Case Model: describes a system’s behavior as it responds to the request that originates from outside of that system ✤ Can easily be understood ✤ Identify possible mistakes ✤ CRUD (Create-Read-Update-Delete) Matrix: describes users permissions to manipulate the dataThursday, February 16, 2012
  24. 24. Models ✤ Data Model/ERD Diagram: describe the information needs of the business area, data is clustered around the concept of a real-world object or event ✤ State Diagram: show how and why a data item, or a system, changes state, sued to identify missing requirements related to business rules, events, data attributes, use cases, and procedural stepsThursday, February 16, 2012
  25. 25. Types of Requirements ✤ Business Requirements Describe the reasons a project is started, its objectives, and its success measures in terms of the organization as a whole ✤ Stakeholder Requirements Capture and describe requirements of a particular stakeholder or stakeholder group ✤ Solution Requirements Describe the behavior or capabilities of the component of the solution ✤ Transition Requirements Describe the capabilities that the solution must process in order to assist the change from current state to the desired future state of the enterpriseThursday, February 16, 2012
  26. 26. Prioritization of Requirements ✤ Consents/Agreements with stakeholders what requirements are high- priority / low-priority in order to proceed/succeed with the solution ✤ Make sure requirements are accurate with stakeholdersThursday, February 16, 2012
  27. 27. Requirements Documentation ✤ Business Requirements Document ✤ Verification ✤ Validation ✤ Sign-OffThursday, February 16, 2012
  28. 28. Why Documentation ✤ Stakeholders need to see a clear set of requirements which they can affirm their needs to, evaluate the end solution ✤ Development Team needs clear set of requirements, ✤ Alleviate Risks ✤ Stakeholders can give feedback and to reduce risksThursday, February 16, 2012
  29. 29. How to document ✓ Cohesive Requirements about a particular feature should be grouped together ✓ Consistent Requirements should not be duplicated, nor should they contradict each other. The level of detail should also be consistent. The terminology should be consistent with the language used in the organization ✓ Modular Requirements should be presented in such a way that changes can be made easily without affecting other unrelated requirements ✓ Unambiguous Requirements should mean the thing to anyone who reads themThursday, February 16, 2012
  30. 30. Common BRD Defects BRD Defects Effects Reviewers miss other defects; Information hard to find or unclear developer does not follow requirements Requirements not clearly differentiated Features are added into product that from other information should not be there Importance of each requirement is not Tester concentrates on the wrong documented requirements Requirements not numbered Review of requirements is wrongThursday, February 16, 2012
  31. 31. Tips for writing BRD ✓ Use simple language ✓ Visual methods ✓ Use “shall” ✓ Importance ratings ✓ Unique identifiers ✓ RationalThursday, February 16, 2012
  32. 32. Time Boxing ✤ Time Management Technique that divides the schedule into a number of separate time periods/boxes where each box has its own deliverables, deadline and budgetThursday, February 16, 2012
  33. 33. Verification ✤ Verification of requirements, must be ✤ Consistent ✤ Complete ✤ Correct ✤ Feasible ✤ ValidableThursday, February 16, 2012
  34. 34. Validation ✤ Ensure that the requirement supports the business goals and objectives meet the business needs ✤ Rule: If requirement cannot be validated as business need, it should be eliminatedThursday, February 16, 2012
  35. 35. Verification and Validation Techniques ✤ DESK CHECKING, individually go to desks and talk to stakeholders, time intensive ✤ WALKTHROUGH, efficient method of finding defects, normally with a group of people ✤ PEER REVIEW, walkthrough of group of people with same level to find defectsThursday, February 16, 2012
  36. 36. Requirements Sign-Off ✤ Sometimes called Requirements Gate ✤ Releases the funds for the project ✤ Make sure stakeholder / sponsor actually read the documentThursday, February 16, 2012
  37. 37. Requirements Management and Communication ✤ Happens throughout the whole life cycle ✤ Everyone should always have the same understanding of the solution scope ✤ BAs manage conflicts, issues and changesThursday, February 16, 2012
  38. 38. Change Control Process / Request ✤ Receive solution change request ✤ Determine impact of not implementing change ✤ Determine impact of implementing change ✤ Make decision ✤ Communicate actions to be taken ✤ Check if actions have been taken ✤ Changed need to be aligned with projects vision and scope ✤ Change needs approvalThursday, February 16, 2012
  39. 39. Change Requests - Steps ✤ Change request (CR) needs to be defined, its impact , should be numbered and tracked ✤ CR will be received by anyone who might be affected ✤ Change Authority (CA) meets with everyone who is affected by the change ✤ CA makes the decision. The CA can be a PM, sponsor or Change Control Board (CCB)Thursday, February 16, 2012
  40. 40. Requirement Attributes ✤ Gives additional information about requirement ✤ Unique identifier ✤ Source ✤ Priority ✤ RationaleThursday, February 16, 2012
  41. 41. Requirements Communication ✤ Goal is ✤ to find the best way of communication with each stakeholder ✤ to make all stakeholders understand the requirements ✤ to make all stakeholders understand the BRDThursday, February 16, 2012
  42. 42. Ways of Communication ✤ Emails ✤ Workshops ✤ Formal presentations, using slides and handouts ✤ Reports ✤ Memos ✤ Meetings, formal / informal ✤ WalkthroughsThursday, February 16, 2012
  43. 43. Requirements Documentation ✤ Requirements activity status: Status reports include wether or not deadlines are being met or if the schedule has changed ✤ Requests for requirement feedback and approval: Ask for feedback or approval during requirements elicitation and when a requirement change is requested ✤ Notifications of requirement changes: Even if a stakeholder does not have to approve the change, he or she should always be notified of any changes to the original requirements baselineThursday, February 16, 2012
  44. 44. Solution Validation and Acceptance ✤ Assessments performed during solution validation include both ✤ Testing: solutions is run using defined inputs in a defined enviornment with defined expected outputs ✤ Non-testing methods: Calculating, Simulating, Prototyping, Analyzing, Reading documents, obtaining user feedbackThursday, February 16, 2012
  45. 45. Purpose of Validation Proving Uncovering solution defects + compliance to the requirements = Validation GOAL is to identify as many defects in the solution as possibleThursday, February 16, 2012
  46. 46. The Art of Testing Finding the greatest number of defects Performing the smallest number of testsThursday, February 16, 2012
  47. 47. Levels of Testing ✤ Unit Testing: conducted by software developers ✤ Integration Testing: conducted by developers, QA ✤ System Testing: conducted ✤ Business-level testing/acceptance testing: solution tested against the BRD requirements, followed by sign-off, managed by BA ✤ Stakeholder assessment: conducted after system has been deployedThursday, February 16, 2012
  48. 48. Role of BA during Testing ✤ The BA is responsible for providing assurance to the PM and the customer that all of the solution testing is adequateThursday, February 16, 2012
  49. 49. Solution Acceptance and Closeout ✤ Sponsor is completely in charge of selecting the evidence he or she feels provides the requisite comfort needed to accept and use the solution within the scope of the requirements ✤ Once the solution is accepted, the ownership passes from project team to sponsor and the project is considered completedThursday, February 16, 2012
  50. 50. Enterprise Analysis ✤ Normally executed/done by Senior BAs or Business Architects ✤ Define the business needThursday, February 16, 2012
  51. 51. Enterprise Analysis - Business need ✤ Basis of the business analysis activities related to determining a solution ✤ Clearly defining the problem to find the solution ✤ Ask questions: Who? What? When? Where? Why? and How? ✤ Includes Root cause Analysis as the identification and evaluation of the reason for the problemThursday, February 16, 2012