1 / 61

Business Analysis In Practice_Apex Global_demo

Module 1: Introduction to Requirement Engineering<br>Module 2: Requirements Elicitation<br>Module 3: Requirements Analysis<br>Module 4: Requirements Specification<br>Module 5: Requirements Validation<br>Module 6: Requirements Management

ApexGlobal
Download Presentation

Business Analysis In Practice_Apex Global_demo

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BUSINESS ANALYSIS IN PRACTICE Practical Training Course Author: Tran Cong Cao Phone: 0909 146 976 Email: cao.trancong@gmail.com Fb: fb/cao.trancong (#caotran) 1 Author: APEX Learning Content Development Team

  2. Introductions and Expectations Participant introductions v Name v Position and background v How long experience with Business Analysis or Requirement Engineering? v What do you want to get out of this course (expectation)? 2 Author: APEX Learning Content Development Team

  3. Learning Objectives v Understand the concepts of software requirements v Understand and appreciate the requirements process v Describe the importance of requirements in software development life cycle v Describe how requirements are used to solve business problem, create products and solution that meet the stakeholders’ needs v Use the requirements practices in the highly competitive software world v Organize and facilitate communicate between stakeholders, users and developers v Plan and setting the stage for requirements development v Elicit and analyze requirements correctly and efficiently v Document and validate requirements in a quality manner v Manage changes to requirements during the development process 3 Author: APEX Learning Content Development Team

  4. Logistics 4 Author: APEX Learning Content Development Team

  5. Rules of Engagement Participate. One person speaks at any given time. Keep discussions and questions to the point. Turn on your cell phones and other communication devices to Silence mode. Be prompt returning from breaks. 5 Author: APEX Learning Content Development Team

  6. Business Analysis In Practice Course Agenda v Module 1: Introduction to Requirement Engineering v Module 2: Requirements Elicitation v Module 3: Requirements Analysis v Module 4: Requirements Specification v Module 5: Requirements Validation v Module 6: Requirements Management 6 Author: APEX Learning Content Development Team

  7. INTRODUCTION TO REQUIREMENT ENGINEERING Business Analysis In Practice – Module 01 7 Author: APEX Learning Content Development Team

  8. Learning Objectives v Understand the Requirement Engineering v Understand the role of Requirement Engineer v Understand the competencies needs to success the role v Understand the relationships of requirements in the IT projects v Understand reason why requirement is important support IT project success v Understand the requirement approach with new project v Understand the common techniques to identify stakeholders and prepare for the project v Transform to requirement engineer mindset 8 Author: APEX Learning Content Development Team

  9. What is Requirement Engineering? v A method of obtaining a precise formal specification from the informal and often vague requirements with customers. v The science and discipline concerned with analyzing and documenting requirements. It comprises needs analysis, requirements analysis, and requirements specifications. Requirement Development Requirement Management Requirements Baseline Requirement Elicitation (Gathering) Requirement Analysis Requirements Traceability Requirements Verification & Validation Requirement Specification Requirement Change Management * Based on IEEE Standard Terminology 9 Author: APEX Learning Content Development Team

  10. What is Requirement? v A condition or capability needed by a user or customer to solve a problem or achieve an objective. Customer Provider v A condition or capability that must be met by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. Satisfaction Documents Systems Capability Objectives v A document representation of a condition or capability. Conditions Needs v Requirements are descriptions of the necessary and sufficient properties of a product or service that will satisfy the customer’s need. * Based on IEEE Standard Terminology 10 Author: APEX Learning Content Development Team

  11. Software Requirements v Requirements describe the behavior of the software as seen from the customer’s perspective. v Requirements serve as a communications channel between customers, users and project managers who are concerned with the development of software products or services. v If software people do NOT have well written requirements that users agree to, how can they develop software that satisfy those users? 11 Author: APEX Learning Content Development Team

  12. Software Requirements v The “TO DO” List of the Project Team. v The List of “WHAT” Customer’s need. v The List of “WHAT” the software must do to satisfy its Customers. v The List of “WHAT” components must be built. v The List of “WHAT” each component must “DO” and “HOW” they will “INTERACT”. 12 Author: APEX Learning Content Development Team

  13. Requirements Engineer Role v Requirements engineer: a software engineer who has the responsibility to gather, analyze, document and validate the needs of the project stakeholders. v This role in collecting and disseminating project information is critical and requires a lot of experience and training. 13 Author: APEX Learning Content Development Team

  14. Requirement Engineer – Job Titles Requirements Engineer Business Analyst System Analyst System Engineer Project Manager Data Analyst Product Owner Development Lead 14 Author: APEX Learning Content Development Team

  15. Three Levels of Business Analysis in the Enterprise Level 3 Level 2 v Focus to Business Problem Solving to define the strategy v Most time work with senior managers and SME v Most work products is Business Model, strategic plan v Focus to Business Problem Solving v Most time work with middle managers and SME v Most work products is business requirement as: Business case, project proposal Level 1 v Focus to Requirement Engineering in detail v Most time work with end- user and technical team v Most work products is User requirement and software requirement 15 Author: APEX Learning Content Development Team

  16. Underlying Competencies v Underlying competencies reflect knowledge, skills, behaviors, characteristics, and personal qualities that help one successfully perform the role of the Requirement Engineer. 16 Author: APEX Learning Content Development Team

  17. Requirements Engineer’s Tasks 1) Define business requirements 2) Identify stakeholders & user classes 3) Elicit requirements 4) Analyze requirements 5) Write requirements specifications 6) Model the requirements 7) Lead requirements validation 8) Facilitate requirements prioritization 9) Transfer requirement 10) Manage requirements 17 Author: APEX Learning Content Development Team

  18. Where Do Requirements Come From? 18 Author: APEX Learning Content Development Team

  19. Relationships of Requirements Requirement Business Requirements Documents Vision & Scope User’s view User Requirements Use Case System Requirements Developer’s view Software Requirements Hardware Requirements Software Requirement Specification 19 Author: APEX Learning Content Development Team

  20. Relationships of Requirements Business Needs System Subsystem A Subsystem B Subsystem C Software Hardware Software Hardware Software Hardware 20 Author: APEX Learning Content Development Team

  21. What are the problems of Product/System? 21 Author: APEX Learning Content Development Team

  22. Wrong Belief v Many peoples believe that for every project there is a set of firm requirements. v If they can get them, they can build them and produce a perfect product or solution. v Project team believe customers will clearly provide: Functional requirements How they want the work to be done How it will be used Performance & Scalability System boundary (Scope) Operating environment (Domain) Verification criteria ⦿ ⦿ ⦿ ⦿ ⦿ ⦿ ⦿ Is this true? 22 Author: APEX Learning Content Development Team

  23. Actually v Customers will provide: ⦿ A wish list of what they would like to have. ⦿ A solution to their problems without knowledge about how it might be implemented. ⦿ A vague description that limits implementation. ⦿ A technology that they read from newspapers. ⦿ Changes as they often change their minds. ⦿ Strict budget & schedule. 23 Author: APEX Learning Content Development Team

  24. Why Is It So? v Many customer expectations are NOT based on needs but wants. v University training is still focusing on solving problems NOT identifying problems. v Most software engineers do not receive adequate training on requirements engineering. v Many software engineers want to work on solutions rather than take time to understand the problem (code first, ask questions later). 24 Author: APEX Learning Content Development Team

  25. Who is the Customer? v A customer is an individual or organization who derives either direct or indirect benefit from a product. v A software customer is an individual or organization who request, pay for, select, specify, use or receive output generated by a software product. Is there all stakeholders is customer? 25 Author: APEX Learning Content Development Team

  26. Who are Stakeholders? v Stakeholder is a person or group that has an interest in the software and can influence the software requirements or can be impacted by the software product. 26 Author: APEX Learning Content Development Team

  27. REQUIREMENTS ELICITATION Business Analysis In Practice – Module 02 27 Author: APEX Learning Content Development Team

  28. Requirements Development Requirement Elicitation (Gathering) Requirement Analysis Requirements Verification & Validation Requirement Specification 28 Author: APEX Learning Content Development Team

  29. Requirements Development Process Re-Evaluate Elicitation (Gathering) Verification & Validation Analysis Specification Re-Write Clarify Correct and Close gaps Iterative process - Multiple-steps, Not sequential 29 Author: APEX Learning Content Development Team

  30. Wants vs Needs Al Davis’s Definition: Wants = The Stakeholders wish to have. Needs = The Stakeholders must have. The ideal situation will satisfy both, but in reality the Software Engineer must satisfy all of the needs and some of the wants. 30 Author: APEX Learning Content Development Team

  31. Practical Techniques v Interviews v Workshops v Observation 31 Author: APEX Learning Content Development Team

  32. Practical Technique INTERVIEWS 32 Author: APEX Learning Content Development Team

  33. Purpose Asking relevant questions An interview is a systematic approach designed to elicit business analysis information from a person or group of people by talking to the interviewee(s) Documenting the responses Establishing relationships and building trust Build support for a proposed solution Interview structure v Structured Interview v Unstructured Interview 33 Author: APEX Learning Content Development Team

  34. Interview Goal v The overall purpose of performing a set of interviews, based on a business need v The individual goals for each interview, based on what the interviewee can provide. v The goals are to be clearly expressed and communicated to each interviewee. 34 Author: APEX Learning Content Development Team

  35. Potential Interviewees v Potential interviewees are identified with the help of the project manager, project sponsors, and other stakeholders, based on the goals for the interview. 35 Author: APEX Learning Content Development Team

  36. Interview Questions v Collecting data, v Researching the stakeholder’s view of the change or proposed solution, v Developing a proposed solution, or v Building rapport with or support for the proposed solution from the interviewee. v Question Types ⦿ Open-ended questions ⦿ Closed questions 36 Author: APEX Learning Content Development Team

  37. Interview Logistics v The location for the interview. v Whether or not to record the interview v Whether or not to send the questions to the interviewees in advance. v Whether the interview results will be confidential 37 Author: APEX Learning Content Development Team

  38. Interview Flow Opening the interview includes: v Describing the purpose and the interviewees' time is needed, v Confirming the interviewees' roles and information v Explaining how information from the interview will be used. 38 Author: APEX Learning Content Development Team

  39. Interview Flow During the interview, the interviewer: v Maintains focus on the established goals and predefined questions v Adapts based upon the information provided and non-verbal communication from the interviewees, v Considers both the willingness and concerns of the interviewees v Practices active listening to confirm what the interviewer has said v Takes written notes or records the interview as appropriate. 39 Author: APEX Learning Content Development Team

  40. Interview Flow Closing the interview includes: v Asking the interviewees for areas that may have been overlooked in the session, v Providing contact information for the interviewees to follow up with additional information after the meeting as needed, v Summarizing the session, v Outlining the process for how the interview results will be used v Thanking the interviewees for their time. 40 Author: APEX Learning Content Development Team

  41. Interview Follow-Up v Organize the information and confirm results with the interviewees as soon as possible after the interview. v Sharing the information that has been learned allows the interviewees to point out any missed or incorrectly recorded items. 41 Author: APEX Learning Content Development Team

  42. Successful Interviewing Depends on Factors v Level of understanding of the domain by the interviewer, v Experience of the interviewer in conducting interviews, v Skill of the interviewer in documenting discussions, v Readiness of the interviewee to provide the relevant information and the interviewer to conduct the interview, v Degree of clarity in the interviewee’s mind about the goal of the interview, and v Rapport of the interviewer with the interviewee. 42 Author: APEX Learning Content Development Team

  43. Strengths v Simple, direct technique that can be used in a variety of situations. v Allows the interviewer and participant to have full discussions and explanations of the questions and answers. v Enables observations of non-verbal behaviour. v The interviewer can ask follow-up and probing questions to confirm their own understanding. v Allows interviewees to express opinions in private that they may be reluctant to express in public, especially when interview results are kept confidential. 43 Author: APEX Learning Content Development Team

  44. Limitations v Significant time is required to plan for and conduct interviews. v Requires considerable commitment and involvement of the participants. v Training is required to conduct effective interviews. v There is a risk of unintentionally leading the interviewee. 44 Author: APEX Learning Content Development Team

  45. REQUIREMENT ANALYSIS Business Analysis In Practice – Module 03 45 Author: APEX Learning Content Development Team

  46. Requirements Development Process Re-Evaluate Elicitation (Gathering) Verification & Validation Analysis Specification Re-Write Clarify Correct and Close gaps Iterative process - Multiple-steps, Not sequential 46 Author: APEX Learning Content Development Team

  47. Requirements Analysis v The process of analyzing the stakeholder’s needs to prepare the definitions of system and software requirements. v The process of transforming business needs into system descriptions with performance parameters and partitioning them into subsystems where allocation to hardware and software can take place. v Since stakeholders and developers may have different views and expressions, to facilitate better understanding, Software Engineers should use abstract descriptions that are easy to understand and interpret. 47 Author: APEX Learning Content Development Team

  48. Different Views Objective: To define what the system will do Stakeholders Developers vQualitative definition vInterpretation to be expected vAll requests must be met vRequirements are evolving vOn going process vSchedule driven vSystem must work vFunctional definition vPrecise, clear vComplete vFrozen, baseline vMust complete within time vTask driven v“Good” if not perfect system How do stakeholders and developers communicate? 48 Author: APEX Learning Content Development Team

  49. Requirement Analysis v Requirements analysis results in requirements models. v Requirements models are user requirements represented by diagrams, structured text (lists, tables, matrices) or a combination. v Requirements analysis also focuses on trade-offs among requirements to make decisions about their relative importance to support prioritization. v Software Engineers are responsible to analyze all requirements and collaborate with stakeholders to prioritize their needs. v Requirements analysis is an iterative process. Why Requirements Models? 49 Author: APEX Learning Content Development Team

  50. REQUIREMENTS SPECIFICATION Business Analysis In Practice – Module 04 50 Author: APEX Learning Content Development Team

More Related