Business analyst training for freshers.pptx

business analyst training slides for freshers and experienced

1. BA Training 2023

2. Syllabus Introduction • Introduction to IT Business Dynamics. • Overview of SDLC - Software Development process • Why Business Analyst is critical for a Project • Introduction to Types of Requirements • Typical questions to be asked for the business team while gathering requirements • Change management • Feasibility Analysis /Risk Analysis • Configuration management • Processes to be followed to gather requirements • Roles and Responsibilities of BA • Skills required to perform BA role • Deliverables of a BA

3. Syllabus Requirement Prioritization • Why prioritizes requirements • Factors to consider while prioritizing requirements • Participants of Requirement Prioritization • The process to follow while prioritizing requirements • Requirement Prioritization Model SDLC Models • What is a Software project • Models of SDLC Waterfall Model • Agile Model • How as a BA we get involved in different phases of SDLC

4. Syllabus Business Documents • Overview of Documentation • Overview of BRD Document • Overview of FRD Document • Overview of Use Case Requirement Management Tools & Traceability Matrix • Overview of RM Tools - JIRA, Azure Dev Ops • Tools Vs SDLC Models Working with RM Tools - Requirement Creation & Management • Requirement Mapping & Traceability Creation, Review

5. Syllabus System Quality Attributes • What are System Quality Attributes • What are the various SQA • Non-Functional Requirements • What are non-functional requirements • What is the significance of non-functional requirements • How the non-functional requirements are gathered • Non-functional requirements document template

6. Syllabus Flow Chart • UML Diagrams (class, state, interaction, etc..) • What is a flowchart diagram • Different symbols used in a Flowchart diagram • How the flowchart diagram is used in a software project • How flowchart diagrams can be drawn using Microsoft Visio UML • What is UML • The significance of UML Diagrams • UML Diagrams (Activity, Use Case)

7. Syllabus Wireframes or Mock-ups • What is a wireframe • Why is wireframe used • How a wireframe can be drawn using Microsoft Visio • An example wireframe Documentation • Epic • Feature • User story

8. Syllabus Testing • In-depth concepts of Software testing • Different types of testing • Difference between Manual and automation testing • Various levels of software testing • Testing artifacts • Step by step process of software testing • Test case document • A real-life example of a test case document • Role of a BA during testing

9. Syllabus Domain Knowledge Frequently asking questions SQL

10. Introduction

11. What is SDLC? Software Development Life Cycle. One of the fundamental procedures of developing software in a step by step manner is by following the Software Development Life Cycle (SDLC). SDLC is a popular practice that is followed by different organizations for designing and developing high-quality software applications.

12. What are the stages will be there in SDLC. Requirement Collection Analysis Designing Coding Testing Maintenance

13. Different models in SDLC Agile Safe Agile Waterfall V-Share model

14. FAQ What is the difference between Agile And Water fall model? Which model is suitable for Software? Explain each phase in SDLC? Which process model you are using in your organization?

15. Who is BA? A  Business Analyst  is a person who helps businesses to analyze their processes, products, services, and systems to improve current processes and make profitable decisions through insights and data analysis. A Business analyst also helps organizations to document business processes by assessing the business model and its integration with technology. Business Analysts have emerged to have a key role in recent business scenarios. Some people think that the role of Business Analyst is to make money for the organization, which may not be true in direct context. But indirectly, the action and decision taken by Business Analysts do leave an impact on the financial prospects of the organization.

16. What’s the role of BA BAs break down the work in small chunks. This makes work easier to understand and confirm. It also makes developing and testing easier. BAs document the scope and keep the project on track. A primary job responsibility of Business Analyst is to communicate with all stakeholders & to elicit, analyse and validate the requirements for changes to business processes, information systems, and policies. A professional business analyst plays a big role in moving an organization toward efficiency, productivity, and profitability.

17. What are the best skills for the BA? Analytical skills – An outstanding analytical skills will separate out a good business analyst. A good part of BA role includes basics of business analysis, analysing data, workflow, user or stakeholders inputs, documents, etc. Leadership skills – One of the Business Analyst responsibilities is directing team members, forecasting budget, helping team members with the problem, etc. Business process and planning – Planning the project scope, understanding and implementing requirement of project, identifying resources required for the project and so on Technical skill – If a business analyst is in the IT sector, few technical aspect are expected to know like operating systems, hardware capabilities, database concepts, networking, SDLC methodology, etc.

18. Types of Requirements Business Requirements User Requirements System Requirements

19. Business Requirements Business requirements are of most importance to the project stakeholders which includes the people paying for the work to be completed, the employees that will use the system, and the project manager for planning purposes. Business requirements directly drive the purpose of the project. They are the reason the project was even considered in the first place. Business requirements are the problems that the customer is trying to solve.

20. User Requirements User requirements are more focused on the end-user, the employee, or the customer, that will be interacting with the system on a day to day basis. User requirements need to capture all of the possible inputs and outputs to the system. These IO aspects may include efficient screen flow, support for bulk operations, integration with internal and all external systems, etc. Documenting these requirements were often coax out many more user experiences and suggestions than were first considered, it is essential that you record them.

21. System Requirements The final category is System Requirements include aspects of the proposed solution which are less obvious than database files all those generated monthly reports. They can also include functional aspects such as system architecture, performance, response times, monitoring, reporting, and notification features plus a whole lot more. Quantifying as many requirements as possible early on in a development process is paramount to embarking on a project with a realistic understanding from all parties. This quantification will feed directly into a qualification phase later on.

22. Types of Requirements Functional Vs Non Functional It is common to hear two terms when describing requirements, those that are functional, and those that are non-functional. But what does this mean and what types of issues fit into which category. Well let’s take a look at a few now.

23. Functional Requirements Functional requirements defined the software functionality that developers must build into the project to empower its users with the ability to accomplish their tasks and fulfil their business requirements. In layman’s terms, functional requirements state what the system must do. Business Rules Transactions, Adjustments, Postings Security Access, Protection Data Capture, Transformation, Interpretation Performance, Monitoring, and Reporting External Interactions Legal, Environmental, Regulatory Constraints

24. Non-Functional Requirements Non-Functional requirements are by contrast more constraints or standards that have been imposed upon the system which it must exhibit or comply with.Non-functional requirements to find the system’s quality characteristics. As a general rule a firm, non-functional requirements can end with it, although this is not always the case. Availability 99.99 uptime Maintainability Capacity, Response Data Accessibility Data Integrity System Recoverability Interoperability Manageability Interact-ability(UX)

25. FAQ: What are the difference between Functional and Non-Functional Requirements. What do you cover in FRD document?

26. Team Structure It depends on the experience you have, you need to handle multiple team members. For the BA role level it’s like you can manage maximum of 2 teams and each team size is of 8 members and a Scrum master should be there. For the PO role you can handle multiple teams and each team is of 8 members size and a Scrum master and Individual BA will be there. Sample Team Structure: UI – Front end team (Tech lead – 1, Developer – 2) – Angular Frame work Backend – (Tech lead – 1, Developer – 2) – Java/.Net QA (Automation lead – 1, Automation tester – 1) - Selenium Scrum master – 1 BA - 1

27. FAQ What’s your team size? Which technology is your team is using? How many BA’s are there in your project?

28. Requirement Gathering

29. What is Requirement Gathering? Requirements gathering, or requirements elicitation, is the process of determining all the requirements of a project. There are two main types of project requirements, business and technical requirements. Business requirements define what an organization will accomplish with the project, while technical requirements explain how the project must be executed. They’re gathered during the initiation phase of the  project life cycle , but project owner need to monitor them throughout the project timeline, as they can change.

30. What Is a Requirements Document? A requirement document is used to explain what is needed from the product. Among the things it defines is the  product vision  and how it must be achieved by the end of the project. It doesn’t go into details about how it will be delivered, though. It’s more to put the product in context, as why the product is needed or what problem it’s solving. The details of how it will do this are not included.

31. Documents to be drafted as a BA/PO BRD FRD Epic/Feature User story

32. Requirements Gathering Techniques Use Case Scenarios A use case is a document that explains how users will perform tasks on your product. It is written from a user’s point of view and done in steps that include: who’s using the product, what they want from the product, the user’s goal, the steps they take to accomplish their task and how the product responds to their action. Brainstorming Conduct a brainstorming session with a group of participants who can say whatever they want about the product as long as they feel it’s important. Have a facilitator lead the group, organizing and prioritizing their responses. Start by explaining the objective of the brainstorming session, get the group to provide as many ideas as possible, don’t criticize or debate and when done gather all the information. Workshop: Requirement Workshop Techniques (aka JAD i.e.  Joint Application Development ) is a very efficient way of gathering business requirements. This technique can save a lot of your system design time if done properly. The agenda of the requirement workshop technique is to get the design right first time and reduce the iterations.

33. FAQ What are Requirement elicitation or gathering techniques you follow? What is FRD document? Who drafts the FRD document? What details will be there in FRD? What are the difference between BRD & FRD? Which are the documents you draft as a BA/PO? Who provides the requirements to you? How do you capture the requirements?

34. Agile Ceremonies PI Planning – Program Incremental planning. Sprint Planning. Scrum meeting/SOS. Sprint Grooming. Sprint Review meeting. Sprint Retrospective meeting. Go, No-Go Meeting.

35. Agile Cermonies

36. Release Structure Release timeline – 3months/1.5 months depends on the organization. Sprint – 2 weeks/3 weeks which is constant always. For Interview we can say our release is of 7 weeks release. 2 sprints (4 weeks) – Dev 1 Sprint(2 weeks) – QA 1 IP sprint (1 week) – Production deployment, prep work for the next release.

37. PI Planning PI planning is program increment planning, which usually works better when project managers work on agile projects with more than one team. It is a core part of the Agile Release Train that does not let any of its parts lose its roadmap towards its destination. PO has to bring the epics to provide the vision for the each release. Release Train Engineer will be providing the Team chattering, timeline and previous content. At the end of the meeting RTE will be publishing the release plan and deliverables to everyone.

38. Sprint Planning Sprint Planning is the process of planning the scope and other related aspects of a Sprint. Sprint Planning is done before the start of a Sprint in what is known as a Sprint Planning meeting. Scrum meeting Scrum meeting is the daily stand up discussion where the Scrum master will showcase the scrum board and check with the team members on the tasks. Scrum of Scrum meeting SOS will be conducted by RTE to discuss about the project status with the scrum masters and check whether team is having any blockers to proceed the work further.

39. Sprint Review The  sprint review  is a  Scrum Event  that takes place at the end of the Sprint to inspect the increment and adapt the  product backlog . The Sprint review allows all the stakeholders to inspect and adapt to what's already built. It provides a transparent view of the current state of the product, and gives a platform to ask questions, give suggestions, and have discussions on how to move forward based on the current situation. Participants: Scrum team Internal Stake holders External stake holders

40. Sprint Retrospective Sprint Retrospective  is the last  scrum event  in Sprint. It's an opportunity for the scrum team to inspect itself and plan for improvements in the next Sprint. Participants: Scrum Master Product owner Scrum development

41. FAQ What is your sprint duration? What’s your release cycle? What the agile ceremonies are there in Agile? Explain about each ceremony? Difference between Sprint review & Retrospective? What’s your team capacity? What’s the role of BA in the sprint review meeting? UAT testing?

42. Requirement Prioritization Prioritization in agile is the act of deciding in what order the agile team will work on the requirements in a project. Participants: Stake holders, Product owner

43. Popular prioritization techniques MoSCoW Prioritization: Must– The must requirements is given the topmost priority Should– Next priority is given to the requirements that are highly desirable, though not mandatory Could– The next priority is given to the requirement that is nice to have Won't– And the final consideration is given to the requirements which will not work in the process at that point of time. 100 $ Technique: The stakeholders divide their 100 dollars by assigning a spending amount to each feature. Once all the 100 dollars are spent, the moderator then tallies all the points and the feature with the most dollars assigned is given the highest priority, followed by tasks with the next highest amounts..

44. FAQ Who set the priority for the user stories/Features? Which technique do you use for prioritizing the requirements?

45. User story

46. What is User story? A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer. The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team. Card: Written on note cards Conversation: Details behind the story. Confirmation: Acceptance test.

47. User story Template There are different templates for drafting the user story. 1. As a <Some role> I want <Some need> So that <Some benefit> Ex: As a User I want to reserve a hotel room so that I can take some rest As a User I want to cancel the reservation. 2. Given the <some context> when <some action> Then <some benefit>

48. User Story Structure User story Title Description Personas Scenarios Dependencies Design

49. What is the criteria for god story? I ndependent N egotiable V aluable to End user or customers E stimable S mall T estable

50. Estimation of the user story Any user story should be estimate with the story points. And each work Item will be having different measurement. Epic – T-shirt sizing Features – This is from the story points [Sum of all the story points]. User story – Story points Task – Hours (<8 hours) Estimation Technique: We use poker planning for the getting the estimation.

51. As is and To be AS IS maps are used to map out processes that are currently being used, while TO BE process maps show how things should be done in order to reach some future state. Both AS IS and TO BE process maps are critical parts of the process improvement journey

52. User story What is User story? How do you estimate a User story? What is the technique you use for drafting the user story? What is the estimation technique you use?

53. Product backlog The Product Backlog is a prioritized list of all the functionalities that we need in the product. It's a single source of truth for all the product requirements. The team is not supposed to work on anything that is not on the product backlog. The  Product owner  is responsible for managing the backlog. The Product backlog helps in monitoring the progress towards goals. The backlog helps in determining the work remaining, which we usually do at the end of every sprint.

54. Sprint Backlog A  Sprint Backlog  is a set of  Product Backlog   items  that we select for the sprint. It also includes a plan to deliver these items and to meet the sprint goal. It essentially contains everything that the  Scrum Development Team  will work on, including Stories, tasks, defects, tech debts, improvement areas from previous  retrospectives , etc.

55. Wireframe a wireframe is a two-dimensional skeletal outline of a webpage or app. Wireframes provide a clear overview of the page structure, layout, information architecture,  user flow , functionality, and intended behaviors. As a wireframe usually represents the initial product concept, styling, color, and graphics are kept to a minimum. Wireframes can be drawn by hand or created digitally, depending on how much detail is required. Wireframing is a practice most commonly used by UX designers. This process allows all stakeholders to agree on where the information will be placed before the developers build the interface out with code.

56. Purpose of Wireframe The wireframing process tends to take place during the exploratory phase of the product life cycle. During this phase, the designers are testing the scope of the product, collaborating on ideas, and identifying business requirements. A wireframe is usually the initial iteration of a webpage, used as a jumping-off point for the product’s design. Armed with the valuable insights gathered from the user feedback, designers can build on the next, more detailed iteration of the product’s design—such as the prototype or mockup. Tool We use for Wireframe: Figma

57. Diagram Process: Use whenever data is being manipulated,most of the time for arthmatics operations. Single flow line enters and exists. Sub Process: Decision: Document: Start/End: Used to Indicate the start and end of the flow chart. Single flow line. Flow begins and ends here. Data:

58. Flow Chart Start Fight Scene Introduction fight Hero Intro Direct review the recording End Heroine Intro Director is satisfied Director is Unsatisfied

59. Flow Chart E-commerce application Start Search Product Apply Filter Choose Product Buy? Add to Cart Place Order Shipment Address Shipment Address Pay amount End Add to Wishlist Receipt

60. FRD Revision History Document approval Project Description: Background: Purpose: Assumptions and Constraints: Systems dependent: Interface and External systems: Use cases: Functional and Non-Functional requirements:

61. NPI What is New Product Introduction (NPI) A New Product Introduction (NPI) program encompasses all the activities within an organization to define, develop and launch a new or improved product. The product could be something tangible, as in the case of a new model automobile, or intangible as in a particular service offered. The acronyms NPI (New Product Introduction) and NPD (New Product Development) are used interchangeably by many organizations. In some cases, NPI activities begin after design and development and merely deal with the product production launch and marketing.  The NPI process can vary greatly from organization to organization. In some cases, it can actually vary within different divisions of the same company. For an NPI process to succeed it must have full active support of upper management in all divisions and departments. An effective NPI program involves a large amount of cross-functional communication and teamwork.

62. How to Implement New Product Introduction (NPI) A New Product Introduction process can consist of various phases or gates. The phase gate system keeps management apprised of the project progress and assures all activities are completed on time. The example shown below consists of six phases: Define Feasibility Develop Validate Implement Evaluate

63. Define During the Define Phase, the product’s functional / performance requirements are defined along with the VOC. The Marketing and Product Management divisions of an organization are usually the primary sources of this information.  Feasibility The purpose of the Feasibility Phase is to allow management an opportunity to evaluate the project’s potential for success.  During the Feasibility Phase, the project team reviews the product design concepts and selects the design that best fulfills the previously defined requirements. Develop The Develop Phase activities are focused on advancing the product design features and characteristics into a more defined form while assessing risk in the design. A validation plan is also developed during this phase. A comprehensive review of the design is performed to evaluate the robustness of the design and its ability to meet customer and performance requirements.

64. Validate During the Validate Phase, product analysis and testing are performed. Some testing cannot occur until prototype parts are available. Design changes are possible due to the results of validation testing but very costly.   Implement During the Implement Phase of the NPI process the manufacturing processes are refined and validated through pilot builds and capability studies. In addition, process documentation and quality controls are being developed and implemented.   Evaluate The Evaluate Phase timing can vary depending upon the organization, the product being produced or the service provided. It is generally initiated 30 to 60 days following production launch. The Evaluate Phase serves several purposes in the product introduction process. This phase provides the team an opportunity to tie up any remaining documentation tasks, review process performance and collect customer feedback on the new product.

65. MVP MVP The Minimum Viable Product The minimum viable product (MVP), as originally defined by Eric Ries, is a learning vehicle. It allows you to test an idea by exposing an early version of your product to the target users and customers, to collect the relevant data, and to learn from it. For instance, to test the viability of using ads as the major revenue source, you could release an early product increment with fake ads, and measure if and how often people click on them.

66. MMP The Minimal Marketable Product Another concept that encourages you to create a minimal offering is the minimal marketable product (MMP). It is based on the idea that less is more: The MMP describes the product with the smallest possible feature set that addresses the needs of the initial users (innovators and early adopters), and can hence be marketed and/or sold. The MMP is a tool to reduce time-to-market: It can be launched more quickly than a fat, feature-rich one.

67. RoadMap

68. Release Planning

69. Use Case

70. FAQ What is the difference between User story & Use case?

71. UML

72. Change Management

73. Risk Analysis

74. Gap Analysis It mainly talk about current state and how do you reach to Desired state.

75. EHR Radiology Hospital Pharmacy Laboratories Patient Registration Billing Clinical Content Orders & Results