[Top 80] Business Analyst Interview Questions and Answers

hello there if you have a business analyst interview coming up shortly then this is the video for you over the last two years we have published several videos on business analyst interview preparation we have merged the key questions into this single video we have covered 80 plus questions ranging from stakeholder management requirements agile methodology sql to testing in this video this video is ideal for your preparation just the day before your interview when you are short of time for it go over this video and attend the interview with confidence the video is split using chapters for easy navigation to your interested section if you have not already subscribed to our channel please go ahead and subscribe to our channel and hit the bell icon we have lots to cover so let's get started do you have a business analyst interview coming up shortly if so this is one of the videos for you in this video we are going to cover the top eight interview questions pertaining to stakeholders identifying and engaging stakeholders is the vital part for the project's success and one of the key activities for a business analyst and hence interviewer would be keen to know the list of stakeholders you have interacted with how you identified them and also the challenges you faced while interacting with them we are going to cover these questions in this video so stay tuned if you have not already subscribed please go ahead and click on the subscribe button and the bell icon so that you are notified when we post a new video and we post regularly on business analysis interview preps skills and techniques okay we have got a lot to cover so let's get started as always we will use a simple case study which will make the concepts easy to grasp rahul is a ba working with a client running a restaurant called wagon gardens the client is looking for a mobile app which will allow their customers to book a table let us use the simple case study and see who the stakeholders for this project are how to identify them and the challenges faced while interacting with them question one who is a stakeholder stakeholder can be defined in simple terms as a party who will be impacted with the change they can be classified under two categories who receives the benefit and who will deliver the change who receives the benefit these are the end users customers business unit managers operation team manager and so on and who will deliver the change this is the project team ranging from project managers developers testers trainers and so on moving on to question number two who are the list of stakeholders you have worked with this question is asked by the interviewer to know the depth of your interactions we can cover the various stakeholders here again look at from our classification earlier for the first category who receives the benefit it comprises of business unit manager of the unit which gets benefited in our example it would be the sales department manager who would be benefited by this change as it would help to streamline and ease stable booking for the customers which should result in increase in the number of visitors boosting sales and also helping saving cost by reducing the number of people allocated for taking phone reservations the next would be the customers in the example again the customers who have to call and wait for making the table reservations can do so just with the touch of few buttons in their mobile and can get a table booked with instant confirmation sent to them this solution would also benefit the staff at the hotel who are also using the staff and of the application for viewing the customer reservations all the manual tasks for checking the availability and making the list of reservations for the given day have all been automated and this results in increased staff efficiency subject matter expert they are usually part of the business unit operations team who have been working on the current system and process for a considerable amount of time and are usually experts and can provide guidance on the current state and also help to identify problems and provide recommendations on the target state the last category is regulators they are regulating body who ensure compliance in our example they may not be appropriate but just wanted to list as they are also a key stakeholder so as part of the requirement gathering sessions the above stakeholders are your key people you need to engage and gather the requirements as you would be working to satisfy their needs and objectives coming to the next category who delivers the change this includes the business sponsor who is responsible for funding and delivering the change and is your key stakeholder to engage when you are stuck or you need guidance and also sponsor would help in identifying the stakeholders next we have the support business units like legal and marketing units they will also provide further guidance on shaping the change to ensure we are covered from all the angles the rest of the people are what is generally termed as the project team project managers can be one or more based on the scale of the project they ensure the project gets delivered as per the deadline and are responsible for the plan then we have the developers and testers to develop and test the software in accordance with the functional requirements lastly the trainer who is responsible for training the staff with a new system in our example trainer can be a senior person in the staff who would be responsible for training the staff with navigation and working of the new system and also creation of standard operating procedures ba works with them by providing working screenshots of the system and also help to draft the standard operating procedures this covers more or less the list of stakeholders and when you are explaining you can use your project examples and go over question number three how do you identify stakeholders this is another commonly asked question the interviewer would ask once you join the project what would be your approach for identifying the stakeholders listed below are a few techniques first one contacting business sponsor you can get a list of stakeholders by contacting the business sponsor you can also check with the project manager who would be able to help you with the stakeholder list second one organization charts you can use the organization charts of the impacted business unit to identify the stakeholder list third one process models in complex environment where the process is handled by multiple teams if you can look at the process models it would have to identify the impacted teams fourth one document analysis if you look at the existing documents of your organization you can get the stakeholder list from there fifth one also when you are meeting the identified stakeholders they will also provide some names during the discussion and that is another source of getting the impacted stakeholders in our case study since it is a small team of people the business sponsor in our example would be the owner of the restaurant chain who would be able to provide the names of the managers from sales and operations teams and also based on the discussion with them we can get additional names moving on to question 4 what would happen if you miss a key stakeholder the interviewer might ask since there are a lot of stakeholders in a complex program and missing one of you is possible and what do you think will happen if we miss again it's a good question which emphasizes on the stakeholder management the answer is the solution which we are developing may not go live until the requirement of the missing stakeholder is taken care of causing delays and it may also result in development and testing rework as it may have an impact on the existing functionalities let us take an example from our case study what if we did not engage the operations team on the ground who is involved in seating of the customers their requirement could have been to have a screen which shows the list of reservations for the given day and the allocated table numbers in case this is not built even though everything is ready from a customer perspective we still cannot go live with the solution until this is built this would result in developing the screen near to the goal life causing delays and reworks hence it is very important to identify all the impacted stakeholders at the beginning phase of the project question number five what is a racy matrix racy matrix stands for responsible accountable consulted and informed it provides a view of the responsibilities of the involved stakeholders let us take the requirements task in the table as an example to walk through first one is r which is responsible this indicates the person who will be performing the task as you're all aware business analyst is a person who will be gathering and documenting the requirements hence in the table if you can see under the requirements task it is marked as r for the business analyst next is a or accountable this is a person who is accountable for the task in our example business analyst is responsible for gathering and documenting the requirements and the project manager is accountable to ensure it is done within the agreed timelines project manager is ultimately held accountable and answerable for the successful completion of the task next in the line is c which stands for consulted this stands for the stakeholders who will be asked to provide information or guidance about the task in our example sma group is marked as c as they would be the participants of the requirement gathering sessions and the ones who provide the requirements to the business analyst next in the list is i which stands for informed this is the next group of stakeholders who need to be informed in our example i have marked the technical lead and test leads as informed as they have to be kept informed about the completion of the requirement gathering question number six what is a stakeholder matrix stakeholder matrix is a list of stakeholders as you can see on the slide it has the following details of the stakeholder like name role they contact details impact to them due to the change and also their influence to shape the change let us look at the example matrix created for our case study we have john who is the restaurant owner and sponsor for this project who has high impact and high influence you have to work closely with him and ensure you have his agreement and support on all aspects of the change next we have jane who is the operations manager the change has high impact on her as she and her team needs to adapt to the new ways of looking up at the reservations and using the tool to seat the customers but she does not have high influence however she and her team are also key end users of this staff side of the application and rahul rba from the case study should engage and understand their needs and interests they can become the goodwill ambassadors for the change next up in the line we have sean who is one of our chefs and one who gave a tour of the kitchen and walked through of the menu when rahul visited the restaurant as there is a next change proposal to enable online delivery but from the current change there is not much impact to sean and hence from an impact perspective we have none and also he has low influence he just have to be kept informed at the most on what is happening on the change then we have kelly who is the finance manager she has no impact directly due to the change but has high influence as she holds the budget the ba should meet and ensure she is believed and rally up her interest in this change question number seven what are personas personas are fictional characters which represent your typical customers they are helpful to understand the customer's needs and build the product accordingly first off personnels will be created based on the brainstorming ideas by the internal team and post that research is conducted with the actual customers to validate the team's assumptions using a number of requirement gathering techniques identifying and validating the needs of the personnel are very important to ensure we are building the product which satisfies their need let us take two personnels for example first one the office manager this is a typical manager who has number of team members reporting to him there would be quarterly or sometimes monthly team outings and the manager is responsible for looking for the fun places to have a team lunch or dinner their needs are quick snapshot of the service offerings and also a receipt of the bill emailed to them so that they can do claims for reimbursement as all the outings are built to the company second one is the family man who wants to book on the weekends for a brunch lunch or a dinner he does not care about the digital copy of the bill but is very keen on the services offered for the kits and the seating arrangements if you see just going at the high level we have got two requirements first one soft copy of the bill to be emailed as a pdf second one the service offerings should be shown in the booking app or the website again these two are just assumptions and have to be validated based on the actual customer research moving to the last question in the series question number eight tell me about a time when you managed a difficult stakeholder this is a very common question and i have just listed two of the common scenarios i bet you would have faced one of these in your project you have worked on the first one is the conflicting stakeholders this is very commonly faced where the key stakeholders are not agreeing with a decision or an approach and without their agreement we cannot move forward one of the things which works in this scenario is meeting them separately and identifying their concerns and work on mitigating the same in our case study let us consider a scenario where the sales department head wants to only focus on having the website or the application for the customer to make the booking but the operations head wants to have a fully functional staff facing portal to help the staff for which the sales head feels is a wasted effort rahul rba can meet both and try to facilitate an agreement as you see both of them from their point of view are right here rakhi can meet them separately and understand their concerns and explain a workable approach which in this case can be in addition to the customer facing website and application a minimalistic staff facing portal with only some two to three key functions can be considered this would be a win-win situation for both the parties second one is unavailability of stakeholders this is a very common problem you invite the key stakeholders for meeting and they don't turn up they don't return your phone calls or your emails there are two approaches for working through this situation the first one can be in the communication to the stakeholder whether it is an email or a voicemail you can explain the importance of the project and the impact and the benefit the change will have on their department this usually works by getting their attention second one can be approaching to connect you with their deputy or any other team member who can help if they are busy at the moment this is a common issue when dealing with senior stakeholders and the about two approaches work like charm use your project experience and see if you can link them to these two categories while answering hello there do you have a business analyst interview coming up shortly if so this is the video for you as you know a key responsibility or a skill for a business analyst is to elicit document and maintain requirements and this video is going to help you to discover the top 9 commonly asked questions in business analyst interviews on requirements so that you are well prepared to make it easier for grasping the concepts and the answers we're going to use a case study in this case study uh a movie theater chain called xyz cinemas is looking to build a digital channel for allowing the customers to book their movie tickets online rather than calling up the customer care or standing in the long queues and getting their tickets at the ticket counter so we are going to use this example case study for answering all the questions question number one how do you define a requirement as per babblock version 3 a requirement is defined as a usable representation of a need to simply put a requirement is articulation of a business need for solving a problem or capitalizing on a business opportunity this representation is actually required for the engineering team to develop the solution accordingly to meet the business need i've listed few of the examples here so these are different types of requirements which we'll be covering in this video i just listed it here to give you a view of the requirements so number one sales department needs a digital channel for allowing customer customers to book their movie tickets online basically it's expanding on the case study then the system shall display the available seats for a movie show systems shall allow the customer customers to select the available seats a system should respond within two seconds of a user's input a customer can book a maximum of 10 tickets at one time so these are all different statements as i was stating earlier you know these are all different types of requirements which we'll be covering shortly the nature of the representation may be a document or set of documents and it varies depending on the circumstances and the methodology used in developing a solution we're going to cover this in question number nine so stay tuned question number two what is the difference between a business and a functional requirement this is one of the tricky question which is asked in the interview i'll try to simplify it using the below two tables first off business requirement business requirements are basically representation of a business need goal objective or outcomes it represents the what example sales department needs a digital channel for allowing customers to book their movie tickets it's very high level and it just represents what is required by the sales department it doesn't give guidance on how it can be achieved it just represents the what functional requirements on the other side they describe what a system must do to achieve the business requirements it represents the how example the system shall display the available seats for a movie show the system shall allow the customers to select the available seat ideally it talks more on how to meet the business requirement and you can see it kind of ties back into the business requirement question number three what is a non-functional requirement so this is this question can be asked as a standalone question or it can be also stated as can you tell the difference between a functional and a non-functional requirement so we're going to cover that in this slide non-functional requirement is a quality requirement or a constraint to the solution so it covers the following aspects so first one is performance so what should be the response time for a system to respond to a user's input so that is captured as part of a non-functional requirement related to performance second one would be security how secure the system or the solution should be third one would be the reliability so there are a few applications or systems which should be up all the time so it can we can state that the system should be available 99 of the time so this would be a reliability uh non-functional requirement which can be captured then the next one would be usability how uh how easy it is for the users to use the system on the solution which we're developing the next one would be maintainability how easy it can to maintain this solution and on the last one would be related to portability so these are some few aspects which we are going to document as part of as a non nfr which is non-functional requirements for the solution which is being developed so let's look at an example the system should respond within two seconds of a user's input so which is a performance nfr so as we discussed uh in the previous slide regarding the functional requirement for the system to display the available seats so if you try to put it together so a customer should be able to click on a movie show and within two seconds the system should show them with a list of available seats so that's how we are you know tying it together to have a great customer experience question number four what is a business rule this is a question where most of the people get it wrong uh so let me try to simplify this as per babblock version three a business rule is a specific testable directive that serves as a criterion for guiding behavior shaping judgments or making decisions that's a little complex definition but to simply put a business rule is a criterion or a constraint which has to be followed by the solution or the system which we are building so for example the xyz cinemas they had a business rule that a customer can book only up to a maximum of 10 tickets at a single time while calling up the customer care or standing in the uh line at the ticket counter so this ensured that you know there are plenty of tickets available for everyone so this business rule has to be taken into consideration while uh developing this digital or solution digital channel so this gives rise to a functional requirement for restricting the number of seats which a customer can book at a single point of time so for example it can be stated as such like this the functional requirement that the system should not allow the customers to select more than 10 available seats so this is a restriction which we are capturing as part of a functional requirement which was basically divide sorry derived from a business rule question number five what are the requirement elicitation techniques you have used in the past i can bet you 100 percent that this question will be asked in each and every business analyst interview the reason as i stated earlier elicitating requirement is one of the key skill and query responsibility of a ba and the interviewer would definitely love to hear how well you have done it in the past and also what are the different techniques which you have used i've listed most of the commonly used techniques in this slide and we're going to cover uh them one by one the first one is the workshop this is one of the highly recommended technique for gathering high quality requirements in a short span of time i've already made a video on how to run a successful workshop and gather requirements in less than one session you can check out in the link below in the description link below so uh taking example of xyz cinemas if you want to uh perform a you know capture requirement so using workshop technique then you have to invite all the key people or smes from the sales department you know customer care department ticket counter finance so all the key people from different departments who are involved in this particular digital solution so you can get everyone into a single session in a room it can be a few hours or even it can be a day if they are spread across it can be done by a video conferencing or web conferencing so you have all the participants and you can get the requirements uh on their views on how the digital solution would be and it can be captured and you know for further solution development second one is the intro interview technique so in case if you're not able to get all these different people from different departments at a single session then you can schedule separate interview sessions with each of them and try to gather the requirements which they need from this digital solution so it can be done on an individual basis and if that two or more people available it can be done as a group interview as well so again this is also one of the commonly used technique for capturing uh requirement or elicitating requirements the top one would be observation uh it can be passive or active so observation if you take an example uh you can walk down to the ticket counter and and you can see how the staff is getting the request from the customer and issuing the tickets like it can show which seats they want uh how the customers select so all these things can be observed and it can be translated uh as a requirement for the digital channel to kind of mimic this uh process so there as i stated that two types of pa ah observation passive and active passive is you just stand there and observe and try to gather as much information or requirements and active as you stand there observe but now you can ask question to the staff who's issuing the tickets or who's doing it's like why are you doing it this way is there a reason you know it provides more insight and it can be kind of translated to the requirements for the digital channel the fourth one would be the document analysis so this can be the documents which are available on the process it can be the procedures it can be the business rules so the business rule which we kind of spoke about in the previous question would be uh you know would be found out from this document analysis technique and it can be translated to a functional requirement the next one would be the focus groups and the brainstorming they're more similar to workshops and it's again done in a similar way brainstorming is more of taking one item and trying to get the ideas and the views from people and kind of ranking it them and then translating into requirements and also the priority of them the next one would be the process analysis so the process analysis is looking at the looking at the end-to-end process if it's already one if it's already there if not creating one and then meeting up with the stakeholder and showing them okay this is the process flow what all the uh things you need from a digital solution which you are building okay so this is also a good way of capturing the requirements looking at the end-to-end process so you don't miss out on anything the next one would be prototyping again if let's say if you want to look at the detailing of the digital solution you can do a mock-up of the screen navigation flow and then you can walk up to the stakeholders and ask okay in the screen what all the elements do you need is this better or do you need a different color to kind of sync up with your brand so all those detailing uh can be achieved using the prototype technique the last one would be surveyor questioner this is again used only if you want to collect the response from a huge number of stakeholders for example if you want to get a view of which of a feature would be beneficial for the customer so you can just draft few of the questions and send it across to the entire sales department or customer care department and then they can select the options and then you can get it back and that can be used for framing the requirements and also prioritization so these are some few uh techniques which i've covered definitely this is a question which would be uh coming up so this can be used by you know you can answer these questions by using some experience from your previous projects question number six what is the difference between verification and validation of a requirement another tricky question so verification refers to ensuring that the requirement meets the quality standards that is whether the requirement is clear is it consistent with other requirements there's no contradiction whether the requirement is complete whether it is testable whether it is unambiguous and also whether it's understandable to all the stakeholders involved the development team the testing team so it ensures that the the quality of the requirement is is good enough for the uh the engineering team to proceed with it validation on the other hand refers to whether the requirement is kind of aligned to the business need goal or outcome and whether it really supports the needed value so let's say in our example if we take a requirement which talks about allowing the customers to book refreshments uh over a digital channel it's a good requirement and you know it it kind of satisfies the verification criteria but uh whether is it aligned to the the business need or the goal of a digital channel to low customers to book tickets no it's a good feature but it's not really aligned to that particular high level business requirement hence you know when the validation process takes place this kind of requirement is termed as low priority and can be revisited once the the key requirements are delivered question number seven what is rtm or requirement traceability matrix so this is one of an important tool or technique which is used to trace requirements so this provides backward and forward traceability as shown in this diagram and it helps faster impact analysis and reliable assessment to ensure that all your business requirements are covered so if you look at this example uh rtm or requirement disability matrix so the business requirement uh will be mapped to the stakeholder requirements uh sql requirement one and two so in our example if you if you talk about the digital channel for allowing customers to book tickets the stakeholder requirement number one can be related to the customer facing screens and how they can how it allows and the other stakeholders who can be involved would be the backend team or the back office operations team and what are the requirements from their side to process the customers online booking so that's how the different stakeholders will have a different set of requirements so the first level of mapping would be with respect to the business requirement and the stakeholder requirements and then the stakeholder requirements would be mapped to the functional requirements and also the non-functional requirements which we spoke about and then the functional requirements or non-functional requirements in turn would be mapped to this design component okay in order to deliver this functional requirement what are the design components required so if you take an example of the screen to show the customers the list of available seats so the design would involve uh different screens and also the the the logic for uh showing up the available seats so so that all comes under the design and then the design component maps to the the code so in which a particular language the the co the code is there it may be java.net or it can be any other new technologies like python so all of this programming comes under the code and it is mapped to the design component and once the code is kind of completed and then it's maps to the test case so the test case would ensure that the code which is developed works accordingly to the requirement so this kind of gives an end-to-end mapping to ensure that a business requirement is kind of developed and tested so it's a very useful tool and this is one of the key things which also use on a day-to-day basis and it can be asked in an interview hello there requirements prioritization this has been a challenge for every business analyst and it is going to be a challenge in the future as well because the business stakeholders they want all the requirements delivered as soon as possible immediately possibly in the single release we know that's not going to happen if you're having trouble convincing the business on the requirements prioritization or you would need a technique or a guidance on on the prioritization of the requirements this is the video for you in this video we're going to cover the four key requirement prioritization techniques which will help you to communicate with the business and get the highest business value items delivered first so we are going to cover these four key thing four key prioritization techniques so a lot of cover we can get started but before i do i just wanted to tell you that this is one of the video in the business analyst techniques video series so i've listed the other videos in the description box so please feel free to go and check it out and also if you haven't already subscribed to our youtube channel or you're seeing the video for our video for the first time i will request you to go and hit the subscribe button and also the bell icon so that you'll be notified when we do a new video we do a weekly video on business analysis techniques tools concepts and also the interview questions so let's get started on the requirement prioritization techniques as always we'll be using a case study and using the case study we'll be driving the concepts of requirement prioritization again this is a case study which we have used in several of our videos because it's very simple and easy for everyone to understand but if you want me to use a different case study open to suggestions please feel free to comment your case study idea in the comments section and we will pick it up for the next videos so in this case study a movie chain named xyz cinemas they're looking for a mobile app which will allow their customers to book movie tickets online simple as that they don't want the customers to stand in the queue they just want the customers to use their mobile app book it and what enjoy the the movie so the features of the app which which the client is looking for are registration customer registration login feature the ticket booking booking ticket feature and seed selection so ability for the customers to select the seats in the theater online payment and again number six is more of uh ordering uh refreshments like popcorn coke if in the app itself so that they don't have to stand in the line for buying these and the seventh feature they're looking for is once the refreshments popcorn or coke are ordered it can be delivered to the seeds where the customers are booked using this particular online app so it's a very good feature set uh making the customer's life easy so this is the features so let's say how how we will be using the requirement prioritization to deliver these features uh released by release i i know it's good to have everything at one shot but again we know it's not feasible so let's see how we can use a different requirement prioritization technique to prioritize and deliver these in a release wise okay let's get started with the first requirement requirements prioritization technique called moscow it's one of the most commonly used technique worldwide the requirements are basically classified into must should could and would must are your mandatory requirements without which there is no point in even having a release so they are the highest priority items which has to get in the next comes the should they should are basically they're also high priority items but even if they're not delivered in a release there are workarounds through which uh you know the same functionality can be uh can be satisfied and then we have the good and wood so basically good and wood are nice to haves it's it's good to get them into release but if you know if you're not able to make it that's okay we can defer it to the next release so let's see how we can apply this moscow to our example case study so if we if we prioritize the requirement requirements so the registration the login and the book tickets are the must you know it's the key key things like the purpose of the app is for the customers to book the tickets online and the registration and login are a pretty precursor basically in order to book the tickets right whom are we booking against if they generally build do you even create an account and then uh the seed selection and make payment agree they're again high priority requirements but without the ability for the customer to select the seats or make online payment they can still book the seats uh online right the seats will be randomly assigned based on the best possible uh you know fit for the number of seats and also the payment they can walk in and pay the cash i understand it's not a you know best customer experience but you can still go hard if you just have the book ticket feature and the registration login working fine seed selection and make payments can be handled as a workaround you know with the with the cash as we just uh talked about and then we have the buying of the popcorn coke and having them delivered to their seat yeah it's really you know it's really nice to have but it won't stop the release because the purpose of the app is not to uh for the customer to order refreshments but it's basically booking the tickets online so that is the purpose that's the reason this these two things will become good so now if we have this list sorted mastered and could it's better when you have a discussion with the it okay you know what these are are must these are should could and you know if if we have that clarity it's it's both good for the from an idea perspective to get the built-in also it's good from a business perspective because we are uh highlighting to the business that the higher value items are being delivered first so it's a win-win in either way okay moving on to the next technique on our list the next technique is called ranking so these are again another commonly used technique basically this comes into place when let's say we have like 10 must and then the problem again now comes is it would have bandwidth only for let's say seven of them so again we are in a fix as we have stated in the previous technique all the must should make it to the release but now we are going to prioritize further so that is where this technique comes into play which is called ranking here you rank those requirements from a scale of one two two three four five six and so on and the smallest rated requirements has to go in first so if we apply this technique to our case study it would look something like this so the registration is first then the login we have the book tickets functionalities number three then the seed selection make payment by refreshment refreshment server to the seat so this is another another way or another technique of basically ordering uh ordering the the requirement uh requirements or the product backlog because sometimes what will happen is if you go to the business and we still explain them you know must should then could they will again tell you know what all these tens are must so it will be again a bottleneck will be a difficult situation so in that scenario you can use this technique okay we understand these are must let's try to rank them when we rank them they'll be much more clarity on the highest value or higher value items so that again this clarity will help to get those higher value items delivered again a very useful technique and used again commonly worldwide okay let's start to look at the requirement prioritization number technique number three the canon analysis so again this is a different view of looking at the requirements and we're going to look at it exclusively from the customer's perspective who's going to use the product so here there are three factors one is the basic factors performance factors and excitement factors basic factors are something like if you don't have the feature in the app then the customers are straight off disappointed they won't even use the particular app or an application and then we have the performance factors so which are basically the drawing factor for the customers to use the application or the app and then they are the the next one is excitement feed factors so these are basically your differentiator from the competitors and your usp or unique selling proposition so customers will be like very excited to use the app or the application because of these particular features so let's try to apply the canon analysis to our case study so it looks something like this the registration login book tickets pretty basic without them there is no point even even using the app because if you're not able to book the tickets why are we even using the app and then seed selection and making online payment yep it would be a you know customers would be really happy to use this because they have the ability to select the seats and they don't have to stand in us in a line again to pay for the cash so they'll be happy to make an online payment just then get onto the theater just walk in and then the refreshments and the refreshments sir to the seat that would be an excitement uh factor basically the the reason for uh uh you know the the the reason for this is basically well again there is a queue for buying refreshments so if you're able to do that using the app then it's like you just walk in after doing the booking the you you've selected the seats you made the online payments and then when you arrive uh at the time of your choosing you're getting your popcorn coke you don't have to stand anywhere no line nothing everything is taken care so that is basically you know it the customers will be excited to use this particular feature and because of this there will be more people being driven into this particular cinema so it will increase the revenue so so these are some things it's a basically a different lens of doing the prioritization so it's called the canon analysis and it is used it's looking mostly from the customer's perspective and the last technique we have on the list is called user story map so basically i've i've covered thoroughly taking in another case study in one more video i'm going to link it in the description box so please go and check it out where you will be uh shown how to build a story map from scratch and then to do the prioritization so it's basically a visual representation of your entire product backlog from the the activity sequence of a user so in our example would be the customer when they order the book the tickets online and the time they you know they walk into the movie theater watch the movie and then get out so this is a basically a customer journey we call it and there will be tasks below it so those would be your you know the the user stories so basically if you put this in a map like some somewhat we show this this is a basically an example of a online home delivery ordering service so you will be able to visualize it better and the business will be able to visualize it better because they will be able to see the end-to-end picture rather than a sequential list and then we can go again and you know check with the business okay this is how it is can can you please you know which would be the highest benefit we can put put put the put the requirements in so the release one as we see here it's called the mvp or the minimum viable product so that is like without which you cannot even you know go in and then similarly the other requirements are prioritized to release to release three it's a similar to what we have seen uh in you know in the previous techniques but again this is more visual and gives an end-to-end view for the business which the other techniques won't give so again it's a very useful technique for them to understand and provide the uh you know the priorities so you're basically assisting them to see the end-to-end feature and which will be really appreciated so these are the four techniques and uh what we are going to do is i provided a link in the description for kind of downloading a quick cheat sheet so you can download it keep it for your reference and start using it in your day-to-day job when you're dealing with the requirements and prioritization hello there in this video we are going to cover questions pertaining to requirement gathering or elicitation which is one of the key skills for a business analyst in the previous video we discussed identification and types of stakeholders which is the first key step for business analyst post onboarding to a project once the ba has the list of stakeholders the next step would be to engage them using different requirement gathering sessions to gather the requirements we will cover the techniques used for gathering business requirements in this video and will focus on techniques for functional requirements in the next video so let's get started with the video as always we will use a simple case study which will make the concepts easy to grasp ravel is a ba working with a client running a restaurant called wagon gardens the client is looking for a mobile app which will allow their customers to book a table moving on to question 1 what are the requirement elicitation techniques you have used in the past this is one of the most commonly asked question and listed below are the commonly used requirement elicitation techniques some of them are document analysis workshops interviews observation focus groups brainstorming process analysis prototyping survey or questionnaire we will discuss these techniques in detail in the upcoming questions based on your answer the interviewer will ask deep dive questions on the techniques which you would have mentioned that you have used so make sure you tell the technique which you have used question 2 what is the first elicitation method you would use the answer in my view would be document analysis this involves reading the existing documents available related to the project which you are working on this will help to provide context and background while engaging with the stakeholders through other elicitation techniques this will help you to identify the current state and the problems faced in the current business unit process and others going back to our case study rahul our ba on the project can request for and look into the below documents before engaging with the stakeholders organization chart this would give the background of the people and business unit structure as vegan garden restaurant has several branches the organization chart would provide information on number of branches and names of the key people in each branch user manual and standard operating procedures this would give rahul a view of how the current table booking process works and which system is used by the staff so rahul will be familiar with the current systems and have a better understanding while speaking with the stakeholders rahul can also look at design documents technical documents process flows problem reports business rule documents or any previously captured requirement documents which would help as stated earlier in understanding the current state and context of the new project let us look at question number three in your opinion what you think is the best elicitation method there is no right or wrong answer you can answer based on your experience in my view the best elicitation method is the workshop technique as you can gather high quality business requirements in a short span of time with a variety of stakeholders the workshop technique involves getting all the key impacted stakeholders from different departments together for an extended period of time like a day or two to go over the project details and understanding from each of them what they are looking for as an outcome since we have the key stakeholders present any conflict can be resolved impacts can be identified and can easily gain agreement from all the stakeholders at the same place we will discuss this technique in depth in the next question question number four can you tell me about a time when you conducted a workshop if you have answered that you have used the workshop technique then interviewer might ask this question to get an insight into your experience for every requirement elicitation technique as mentioned in baboch version 3 it has three phases prepare conduct and post the session let us consider the workshop in context with our case study rahul rba is going to use the workshop technique for gathering the business requirements for the online table reservation system first off rahul needs to prepare for the workshop which includes setting a clear purpose which is to gather business requirements for the table reservation system identifying the key stakeholders and ensuring they are available to attend the workshop the key stakeholders would include the sponsor who is the owner of the restaurant the business managers from different branches and senior operations staff who are involved in the table booking process currently once he has the list of the key stakeholders he would schedule a place and time convenient for all the key stakeholders usually workshop is a full day or two days event the venue should have all the facilities like whiteboard projector adequate seating etc and refreshments like coffee snacks should also be arranged rahu chooses his company's conference room which has a seating arrangement for 15 plus people and invites the key stakeholders there for a full day workshop he has also arranged for lunch and other refreshments next off rahul would make and share the agenda with the attendees agenda will have sessions or activities for that day so that the stakeholders come prepared sample full day agenda would be like this 9 to 9 30 introductions can happen 9 30 to 11 15 walk through of the current process 11 15 to 12 break 11 30 to 1 discussion on the target process design 1-2 lunch break 2-4 gathering the business requirements for the target 4 state 4 30 they can have a short break and again 4 30 to 5 they can have a playback session the first stage is key if the preparation is good then conducting the workshop is pretty easy moving to the second stage conducting the workshop the stakeholders meet at the venue on the day of the workshop and rahul uses the agenda shared earlier to drive the workshop and will try to adhere to the agenda as close as possible as the workshop progresses rahul documents the discussions requirements and actions if help is available one can also use them for documentation during the workshop they are referred to as crime the last stage is post the workshop which would include activities like closing out any open actions raised during the workshop rahul can then share the captured business requirements for sign off to the stakeholders if required rahul can arrange a review session with the stakeholders to walk through the requirements captured for obtaining a sign off moving on to the next question question number five what are the challenges faced while using the workshop technique and how would you mitigate it this is another follow-up question asked on workshop the major challenge would be non-availability of the key stakeholders getting all the required people together for a day or two is by far a difficult task some mitigation would be the below approaches number one explaining the importance of the workshop and how it will help to shape the system which they are trying to build number two rescheduling to a suitable time so that everyone can attend number three in case a key person is not available then asking them to send their deputy or a representative from their team if still we are unable to get everyone together then covering off with the key stakeholders individual interview is an option which will cover in the next slide next question question number six can you tell me about a time when you conducted an interview if you have answered that you have used the interview technique then interviewer might ask this question to get to know more about your experience like we spoke for the workshop the interview elicitation technique has three phases prepare conduct post decision let us continue with our case study and say one of the key stakeholder jim who is the manager of customer support could not attend the workshop rahul would then use the interview technique for sharing the outcome of the workshop and gather any missing business requirements from the customer support perspective first off rahul needs to prepare for the interview which includes setting a clear purpose which is to gather business requirements from a customer support perspective schedule a place in time convenient for jim to attend next off rahul would make a list of questions like what the customer support staff would like to see in the new system for answering the customer queries what are the functionalities required in case there is change required by the customer and so on and shared these questions in the meeting invite to jim so that he can speak to the team up front and have the answers ready as stated earlier first stage preparation is always the key if the prep is good then conducting the interview is pretty easy moving to the second stage it was agreed to have a discussion on the conference call and both rahul and jim joined the call for the interview rahul briefly touched upon the outcome of the workshop and then used the questions shared earlier to drive the interview process rahul used active listening techniques and made notes on the discussions requirements and open actions once all the questions were covered rahul thanked jim for his time and informed that he will share the minutes of meeting and also the requirements captured for his review and sign off post the workshop rahul shared the minutes with open actions and also shared the requirements captured for review and sign off moving on to the next question question number seven can you tell me about a time when you conducted an observation session if you have answered that you have used observation technique then interviewer might ask this question to get to know more about your experience like we spoke for the previous two techniques the observation elicitation technique also has three phases prepare conduct and post the session let us go back to our case study one of the open actions in the workshop was for rahul to capture a time and motion study that is how much time does the current reservation process take and also document the current steps taken by the staff to complete the booking rahul is going to use the observation technique for completing these two actions first off rahul needs to prepare for the observation session and he follows the following steps setting a clear purpose which is to document the detailed process used by the staff now and do a time and motion study identifying the participants with the help of one of the branch managers and scheduling a convenient time for the session share the agenda with the participants up front so that they are prepared for the session as always first stage is the key if the prep is good the rest follows easily moving to the second stage rahul meets the participants at their workplace at the scheduled time and briefs them on the required outcome and the reason for the same rahul uses passive observation technique he captures the start time when a call is made by the customer and end time when the booking is made in the current system it is around 3 minutes he then asks the branch manager for a staff to make a note of the time from today so that the average time can be benchmarked and used for presenting back to the sponsor who wants to know this he also observes couple of staff and makes note on the steps taken by the staff for making the booking from the time when the customer calls and the booking is done on the system once the staff completes the booking he asks couple of clarifying questions on the doubts he had on the process he then thanks the participants for their time and heads back to the office the last stage is to ensure what he captured is right he converts the steps into process diagram and sends it to the staff for review and also follows up on the open action for the average time for booking process from the manager question number eight another follow-up question on observation what is the difference between active and passive observations there are two types of observations first one active observation when the staff is performing the steps in the process if you have any questions you stop the staff and ask clarifying questions when they are performing that step to gain insights point number two passive observation you make a note of all the questions and wait for the staff to complete all the steps in the process and then ask your questions active observation is used when you are more interested in specific part of the process whereas passive is generally used to capture the metrics of the time taken to complete the process and for benchmarking question number nine what is focus group and how to conduct one this is similar to the workshop you get the key people together at the same place to get their thoughts and opinions going back to our previous video where we discussed about personas which are fictional characters who represent the typical customers they are helpful to understand the customer's need and build the product accordingly based on brainstorming with the internal team the requirements would have been locked on what these personnels would need identifying and validating the needs of the personnels are very important to ensure we are building a product which satisfies their need focus group is one such technique to use for that let us take two personas as example first one the office manager this is a typical manager who has number of team members reporting to him there would be quarterly or sometimes monthly team outings and the manager is responsible for looking for fun places to have a team lunch or dinner their needs are quick snapshot of the service offerings and also the receipt of the bill emailed to them so that they can do claims for reimbursements as all the outings are built to the company second one family man one who wants to book on weekends for brunch lunch or dinner he does not care about the digital copy of the bill but is very keen on services offered for the kids and the seating arrangements if you see just going at a high level we have got two requirements first one soft copy of the e bill to be emailed as a pdf second one service offerings should be shown in the booking app or the website again these are just assumptions and has to be validated focus group is one of the way to validate the assumptions made rahul can get the details of their previous regular customers from both the categories office manager and family men and arranged for a focus group session with them to go over the feature of the new online booking system he also provides perks for participating in the session by giving them free lunch or dinner coupons at the restaurant again similar to the workshop technique agenda can be shared upfront to these people so that they are prepared during the session rahul uses the agenda and goes over the list of business requirements captured to get their thoughts on each one of them rahul makes a note of the participant's feedback once all the items in the agenda are complete then rahul thanks the participants post the focus group session rahul compiles the report based on the insight received and shares with the key stakeholders this would help to understand which business requirements are key to the target audience and which can be discarded or be prioritized let us look at question number 10 how can you gather requirements from a large number of people or they can ask you to tell about a time when you used survey or questionnaire technique answer is survey or questionnaire technique we cannot use any of the techniques we spoke about earlier due to the sheer volume continuing with our case study rahul wants to get a view on the thoughts of the vegan gardens existing customers on the new online booking system before starting the bill to ensure their requirements are satisfied going back to our three stages in prepare stage rahul would compile a list of question and answer options to send out to the participants it is important to have options for each question and not have a free text field as it will be difficult to interpret the answers sample questions can be like do you prefer a mobile app or a web app for making the booking do you want to receive reminders on your reservation using the questions rahul will create an online survey and get the survey link in conduct stage rahul sends an email to thousand plus existing customers of the restaurant to help to take the survey he can also provide perks to the customers like discounts for participating in the survey and it is very important to give a deadline for the customers to complete the survey otherwise we cannot close the activity post the deadline date rahul can review the results of the survey and compile insights and log them as business requirements hello there do you have a business analyst interview coming up shortly if so this is the video for you in this video we're going to look at the top 9 interview questions asked related to the requirement documents as you're already aware eliciting and documenting the requirements are one of the key aspects of a ba role so the interviewer would be definitely interested in understanding the requirement documents which you have created in your past projects we have a lot to cover so let's get started i can assure you that they're going to be couple of questions from this video which will be asked in your next business analyst interview we're going to look at the brd frds their contents and structure we're going to also discuss on rtm epic user stories their format and also the acceptance criteria so it's going to be a informative video so make sure you watch it till the end and also if you have not already subscribed to our channel please go ahead and subscribe to our channel right now so that you will be notified and you won't miss out on any of our future videos to make it easier for grasping the concepts and the answers we're going to use a case study with this case study a movie theater chain called xyz cinemas is looking to build a digital channel for allowing the customers to book their movie tickets online rather than calling up the customer care or standing in the long queues and getting their tickets at the ticket counter so we are going to use this uh example case study for answering all the questions okay let's get started question number one what are the different documents you are prepared for capturing requirements this question i would say is a sure short one and it is asked in almost all the business analyst interviews i've listed the majorly used documents it varies from company to company but these are the common ones so the first one is the brd which is the business requirement document the purpose of this document is to capture the business requirements and the core business context of a particular change initiative the second one is the functional requirement document which is the frd the purpose is to capture the functional and non-functional requirements and it kind of maps back into the business requirements then we have the use case document again the purpose would be to document the use cases uh which details the interaction between an actor and the system or the solution which we are trying to build and then we have the activity diagrams so this uh documents the flow of events uh the in the interactions uh between the user and the system and also the detailed step-by-step flow which basically which will help the it team to build the solution which we're looking for and then we have the wireframes so the wireframes are basically used uh to provide a view of how the screen should should be looking for the customer so it will be the look and feel the colors and also the various user interface items so all these things would be mocked up into the wireframes and then we have the epics and user stories so all the documents which we just spoke about are used in the traditional waterfall model but in case if a project is using agile the requirements are captured in epics which is again the high level requirements and then the user stories which are epics are broken down into user stories so and all the use cases activity diagram wireframes are all you know converted into supporting models and they are basically attached to the user stories for the epics to provide more context and a better understanding of what is required to the it team so that they can build it accordingly and the last one common one which is used is the rtm which is the requirement traceability matrix it is basically used to trace the requirements backward and forward right from the business requirements to the test case and vice versa we're going to talk about all of these in details in the further slides moving on question number two what are the contents of brd or the business requirement document again this is a a question asked to gauge your depth of experience of preparing such kind of documents so you you can use example to provide the contents of the brd and i've listed few of the uh components here but again it varies from company to company project to project but these are the few uh common uh building blocks so the first one would be the executive summary so if you looking at our example this would summary would state that the business xyz cinemas is looking for a digital channel for the customers to book their movie tickets and the business context will provide why they are looking for this change initiative well here in this context it's just to make it more convenient for the customer to book online rather than standing up in the long queues or calling up uh other customer care and you know waiting for it to be confirmed so that is the customer convenience and also if you look it from at the staff perspective uh this can help to free up for some of these steps were doing these rules and they can be allocated to uh you know other priorities other opportunities and then there will be a current state and target state current state will be a basic business process flow like what's happening now when the customer comes in uh goes to the ticket counter and similarly what happens when they call up the uh customer care and the target state will be how the customer with the the target state process flow will show the how the customer will be using this digital solution to book the tickets and how they will be permitted into the cinema halls you know the end-to-end business process flow how the target state would be so this will give more contacts to all the stakeholders involved and also to the engineering team i.t and the testing team uh the development testing team to understand what is being done and why is why it is being done and then the scope the scope section would actually have uh what are the things which are in scope for now so let's say if you're looking for the solution whether we wanted to be limited only to you know the web web app or a web login or do we want to also develop a mobile app where the customer can book their ticket so this would be the scope and it should be pretty clear what is in scope and what is out of scope and then comes the business and you know the stakeholder requirements so these are the requirements which are are you know needed to achieve the target state so this talks about this can talk about the requirements related to the customers uh able to book their tickets online and also uh the cancellations uh what are the things the customer can do with the online channel and also similarly on the staff side it can be like how the staff can identify these book tickets how they can let the customer into the hall so all of these requirements would be under these sections and then the next one would be the assumption so what are the assumptions for this initiative so one of the assumption i can think of is once this channel is available the customers will start using it you know that's a basic assumption and then the dependencies what are some things which have to be in place for this thing to work and then the business rules if there's any rules for example like the they might have a rule that only a maximum of 10 tickets can be booked at one time so this is a business rule this can be translated and documented uh for a functional requirement and you know ensure that the digital solution also uh withhold like holds this business rule true and then the last section would be a glossary which will just summarize all the abbreviation acronyms used in the whole document so just to give a view of the person who is reading the document understand it better so these are some common sections in a brd moving on question number three what are the contents of a functional requirement document or frd so this is similar to our previous question again uh they want to understand your depth of knowledge in preparing such documents so quickly gonna list out all the common sections which is uh you know used in drafting uh frd so first one would be the purpose again what is the purpose of this particular document uh how it's how it you can borrow some context from the brd to put it here similarly the scope section again can be borrowed from the brd what is in scope what is out of scope so it's very clear and then comes these functional and non-functional requirements so these are the system related requirements and here you'll be document documenting what the system should do in our example if we take this would talk about how the customer should be able to see the list of shows the list of seats which are available for on each show and where they can select the seats and also make an online payment so these are basically a translation of the business requirements uh into this is the functional requirements which which basically again what you want the system to do and these are all linked back to the business requirements similarly a business rule which we spoke about the maximum of 10 seats can be booked that also can be translated to a functional requirement ensuring only 10 seats can be booked online and then we come to the non-functional requirements so these are the requirements related to the performance the security stability of this online solution so one such example is responsiveness uh we want the solution the system to respond within two seconds of the user's input so for example user selects a date within two seconds we should be the customer should be able to see the next screen so that's one example of it then the assumptions we just spoke about and then the major chunk of this document would be the supporting models which will provide more context to the engineering team and helping them to understand how we want the solution to work so that they can build it accordingly and you know tested it as well so this is about the use case diagrams activity diagrams mockups which we just spoke about earlier so all of these would comprise a you know will be part of a vr sorry frd and then the last one is a glossary again just to provide more context on the acronyms and of the abbreviations used question number four what is the format and contents of an epic so far we discussed about the waterfall methodology and the documents used when you come to agile it's very document light and all the requirements are captured in the form of epic or user stories epics are tileable and then they are broken down into detail user stories so i've listed uh this down the key components of an epic in this slide ideally in essence what an epic has is who what and why who requires it what is required why is it required so this is kind of a format which is you know used to capture the requirements so a template which are provided which is a commonly industry-wide format which is used across as a who requires it i want what is required so that why is it required so that's a format if you look at an example as a customer i want to pay for my movie tickets online so that i don't have to stand in queue to pay cash at the movie theater so this is a again a customer convenient convenience requirement where we're talking about the ability for the customer to pay online for the movie tickets which they have booked so it captures the requirement in this particular format and it also has some additional information like priority what is the priority of the requirement is it a must should or record or if you're using ranking it can be ra you know prioritizes one two three four etcetera etcetera so it all uh helps in the prioritization of the backlog so that the highest value item is delivered first and then this has the business contacts so it provides more context on why this particular requirement is uh you know listed in first place so all the things which we spoke about in brd so those things can be added here as a business context and then it has links to the detailed user stories so if you look at an epic it gives a high level requirement of what is required in the next slide we will speak about the detailed user stories question number five what is the format and contents of an user story so we are building upon from the previous question which you know which is epic and these are the detailed user stories so the format of a user story is very similar to the epic who what and why so what i try to provide as an example is the epics the epic spoke about how the customer should be able to pay online and in these two user stories we are breaking down it further so if you look at the first one as a customer i want to pay online using my debit or credit card for my movie tickets again he wants to avoid standing in queue the second user story talks about customers ability to pay online using the online banking portal so for example they don't use a credit card they want to use their online banking net banking portal so this breaks down the epic into more details of the channel which the customer wants to use we can still have more user stories like the mobile valids paypal etc etc so this kind of gives you a view how an epic is kind of linked to the user story and what is the format and the user story also has like additional information like the priority similarly must should could or high medium low again one two three four ranking and then it will also have the epic which is linked to and then the acceptance criteria which will uh we speak about uh in the next slide and also the supporting models so the use cases activity diagrams the mockups which we spoke earlier all of them would be created and attached to the user story as a supporting model to provide more context and more information to the engineering team to build the solution question number six what is an acceptance criteria and its former as discussed in the previous question acceptance criteria is a for is a part of our user story and it's a very important part it basically uh states the condition or outcome which has to be satisfied in order for a re uh for a solution to be acceptable to the business stakeholders so it's very key in terms of coming up with the qa test scripts and also the uat test scripts so so it's a very vital component of a user story when we look at the template or the format so usually the acceptance criterias are also given as a one line statement in an example demonstrate that the customer is able to pay using their debit or credit card but that is there is high level statement on in order to make it more robust and ensure that everybody gets a clear understanding this is the format which you see on the screen it's based off bdd behavior driven development so the format is given a context when an event happens then what is the outcome which is expected if we translate that to an example based on the user story which we just discussed given customer has selected the show and selected their seats when they are on the payment page of the digital solution then they should be able to pay online using their debit or credit card so it clearly spells out what are the uh what is the context what is the event and then what should happen so it's very clear to everyone the developers and also the testing team what the outcome we are looking for in what condition and it ensures that we build a solution according to the uh business requirements question number seven what is rtm or requirement traceability matrix so this is one of an important tool or technique which is used to trace requirements so this provides backward and forward traceability as shown in this diagram and it helps faster impact analysis and reliable assessment to ensure that all your business requirements are covered so if you look at this example rtm or requirement traceability matrix so the business requirement will be mapped to the stakeholder requirements uh sql requirement one and two so in our example if you if you talk about the digital channel for allowing customers to book uh tickets the stakeholder requirement number one can be related to the customer facing screens and how they can how it allows and the other stakeholders who can be involved would be the backend team or the back office operations team and what are the requirements from their side to process the customers online booking so that's how the different stakeholders will have a different set of requirements so the first level of mapping would be with respect to the business requirement and the stakeholder requirements and then the stakeholder requirements would be mapped to the functional requirements and also the non-functional requirements which we spoke about and then the functional requirements or non-functional requirements in turn would be mapped to this design component okay in order to deliver this functional requirement what are the design components required so if you take an example of the screen to show the customers the list of available seats so the design would involve different screens and also the the the logic for showing up the available seats so so that all comes under the design and then the design component maps to the the code so in which a particular language the the co the code is there it may be java.net or it can be uh any other new technologies like python so all of this programming comes under the code and it is mapped to the design component and once the code is kind of completed and then it's maps to the test case so the test case would ensure that um the code which is developed works accordingly to the requirement so this kind of gives an end-to-end mapping to ensure that a business requirement is kind of test developed and tested so it's a very useful tool and this is one of the key things which also use on a day-to-day basis and it can be asked in an interview moving on question number eight what are the different visual models you created for documenting requirements so this is another key questions which keeps getting repeated in the business analyst interview so i've listed the major ones used but there are much more uh visual models uh which have been used so i'll be creating another video only dedicated to this but in this video i'm just going to quickly cover of the commonly used ones the first one is the use case diagram which uh kind of documents the interactions between the user and the system which we are building what are the different things a user can do functions with the user can perform using the system then there is the activity diagram which again captures uh the interaction between the user and the system in a very detailed way let's say example if the if the customer selects on uh the particular show what happens what is the screen which is shown to the customer uh let's say it is in the seed selection let's say customer proceeds without selecting a seat then there should be an error message which should be thrown so all of these things are kind of captured as part of the activity diagrams and then it comes the wireframes so this is basically the look and feel of the screens so how the screen should look what are the colors what are the components which are which should be available to the customer in the screen so all of this visual part are handled using the wireframes then we have the prototypes which is similar to the wireframes but this kind of gives a journey in a visual way if the customer clicks on one button on one screen then what is the next screen which is popping up they click on this what is the next screen which is popping up it's kind of you know it's a storyboard which is very easy for the developers to visualize while they're building the solution and also for the testers to test the solution and then we have the business process flows it's the end-to-end flow basically what happens uh when the event is started who are the actors you know they are depicted by swim lanes what are the actions which are taken by the customers by the staff on the on the business side so all of these things are visually represented as part of the business process flows the last one key key one is the data flow diagrams uh basically these are uh more of a technical in nature which shows how the data flows from which is the source and how it's get getting captured in the backend database so these are some key things and commonly used visual models if you feel there are any any similar ones which are very key and used widely please comment in the comment box and i'll pick it up while i'm creating the other video moving on to the last question question number nine what are the tools you have used for documenting requirements so this is one of those tricky questions where the base might not be prepared while facing the interview so i've just listed it out here so predominantly most of the requirements are captured using the ms office tools if you are following the waterfall model word the frds and brds are captured in the word document and the the powerpoints can be used for presenting these key parts to the stakeholders for either sign off or you know just to present and get their views on and then excel is used for the requirement traceability so it's it's mo it's more or less all the business analysts work heavily on ms office and then there's a sharepoint where all these documents are commonly uh maintained so it's like requirements management is done using the sharepoint which all these documents which we spoke about if you're using waterfall but if you're using agile methodology i think most of the things are on jira uh the epics are created on jira the user stories are created on jira acceptance criteria is documented as part of the user stories and all the supporting models like we spoke about the mock-ups the use cases activity diagrams all will be just part of the jira and confluence is also used uh extensively uh where i want to make uh provide more notes or more context so jiran confluence are the key tools in the agile methodology and there is this require requisite pro this is also one of the requirements management tool um which will which is which which is used and then we have the vizio and eris so these are the business process modeling tools so you can create business process models using that and visio is extensively you know it can be used for your activity diagram use case diagrams any type of diagrams and you know the mock-ups can be created uh using visio powerpoint and also ms paint and then if you want to go a little high-tech on the tools for capturing the business process models and all the different uh diagrams the visual models i think lucidchart is one tool which is uh which have all the pre-built templates and can be used readily uh uh readily and it can be uh you know it can save a lot of time and then we have ballismic this is also it's a mock-up tool and it's basically used for creating all these web-based mockups and mobile phone app mock-ups so these are the things which uh you know commonly used again please comment in the comment box if there are any other tools which you think i've missed out here hello there welcome to this video in this video you're going to discover the top 10 commonly asked questions in interviews on scrum agile methodology if you have an interview coming up shortly then this is a video for you question one what are the events ceremonies in agile methodology so there are four key uh events and we're going to cover those in detail in the upcoming slides but i'm just going to provide an overview of these four events in this particular question so we have a sprint planning which happens during the beginning of the sprint and then we have the daily scrum which happens daily during the duration of the sprint and then we have sprint review and sprint retrospective towards the end of the sprint so we're going to cover all of these events in detail so stay tuned number two so this is again another commonly asked question is the composition of the scrum team so ideally the scrum team comprises of three main roles which are listed in the slide one is the product owner two is the scrum master and third one is the development team the development team includes the developers uh the testers or any other i.t stuff so all these three roles comprises of a scrum team question number three so this question relates to the artifacts in scrum as you know scrum methodology is basically very light in documentation but these are the three major are kind of used in the process so first one is the product backlog so this contains all the things which relates to the doubler for the product the epics the user story the defects any other ideas so all of this goes into the product backlog and then we have the sprint backlog so as i was speaking in the question one about sprint planning so the items which deliver most value to the customer based on urgency or based on other factors so all these items are transferred from product backlog to the sprint backlog which becomes the scope of that particular sprint and which is used throughout the sprint the third artifact is basically the product increment which is delivered in that sprint it can it contains the software package the release notes and the user user manuals on how to use the functionality which was delivered in that particular sprint so that summarizes the three major artifacts used in the scrum methodology question number four is what is velocity so ideally it is ability of the scrum stream to deliver valuable product increment so it's basically calculated based on the story points of the backlog items which were delivered in that sprint or we can term it as done in that particular sprint so let's say for an example 41 story points worth of product backlog items were delivered in or completed in sprint one so then the velocity of that scroll scrum team can be termed as 41. let's continue the example let's say in sprint to the team uh completes uh 42 then they're going to average out 41 and 42 and then use that as a variable in the sprint planning meeting basically this kind of gives an idea of what the team can deliver in a particular sprint and it's used for planning so that's the main use of velocity question number five what is the use of a sprint burn down chart or what is a sprint burn down chart so again this is one of the artifacts used uh in the process to kind of track how the progress is with respect to the sprint goal and then kind of adapt to achieve the goal which was planned in the beginning of the sprint so if you look at the example chart which is given here uh it's a two week sprint let's say it's 14 days worth of for days it's tracking and then the yellow line kind of for tracks the story point which needs to be completed on a daily basis to achieve the sprint goal and then the red kind of signifies what is the actual so it's basically giving a plan versus actual view and then during the daily scrum meeting this chart can be referred and the team can adapt or adjust accordingly to complete this part particular sprint goal so again it's a very useful metric for tracking progress question number six so i was telling we'll discuss more in detail of the events so this is the first of the four events in scrum process so which is a sprint planning meeting so a lot of interviews will ask what actually happens in those meetings so so what the basically the purpose of this meeting is just to craft a sprint goal and also plan to achieve it so the participants would include the scrum team uh the development team scrum master and product owner and then they will use the product backlog and then pick okay these are the product backlog items let's see what should we target for this release so for example if it's a the team is building a ticket booking app for a movie theater chain so maybe they would have delivered the basic functionality of login registration and booking the tickets but they wouldn't have the functionality of seat selection by the customer so that can be one of the major functionality which they can target in the sprint and that can go that can be the goal of like that can be the sprint goal and then that goal can be broken down into the user stories and epics which will populate this print backlog and also the velocity is used as an input to kind of determine what the team can kind of complete in that sprint so it's as we discussed in the previous slide if the team can complete 41 story points worth of uh items then in the next print also they can use that as a guiding parameter and then they can keep okay let's we can only do for 41 uh let's see what we can fit in those things yeah and then using all this uh input so the output will be the sprinkle as i was just telling in the example the seat selection feature can be a sprint goal and then the sprint backlog all the epics and the users user stories related to that particular functionality can be included in the backlog and then a sprint burn down chart which we just looked in the previous slide can be charted with the plan planned story point completion throughout the sprint process yep and the question number seven is the next item or which is the even which is the daily scrum meeting explained basically they would ask to explain what happens in the daily scrum meeting so this is a daily scrum or it's also termed as a stand-up meeting so the purpose is just to review the team's progress on the sprint goal and not just the plan to get there the development that the participants mainly would be the development team and the scrum master product owner is kind of optional so it's good to include the product owner but again he or she is optional so the inputs would be the sprint backlog okay these were the items the user stories and the tasks which are outstanding for this particular sprint and also the sprint burn down chart how how is the team progressing so the progress would be inspected and if there's any impediments or was telling about the blockages uh it can be a technical issue or a environmental thing or well various factors which will be blocking progress so those can be identified and then um usually a follow-up call or a follow-up meeting would be set up to work on resolving those impediments usually it's all driven by a scrum master oh my question number seven question number eight is basically uh describe what happens in sprint review meeting so this review meeting happens at the end of the sprint and ideally the purpose is to just showcase the work which was completed in the sprint to the stakeholders this meeting will have extended stakeholder list along with the scrum team which will include the sponsors the customers or the end users and also the sales team they would like to see how the product is shaping up and they also can provide their feedback so the input again would be the goal so example we spoke about like seed selection feature and then how the feature which was developed so the usually it will be done by the product owner they'll just showcase or demo this particular functionality to this extended audience and then get their feedback like are they happy with it or if there's any improvements or any enhancements which can be done it would be noted down and it'll be added to the product backlog so that was mainly happens in this review meeting again the product owner also provides a status report and also a forecast of what would be coming in the next prince if yeah and also when there is a release planned so all those things kind of gets discussed in this particular meeting and we'll move on to question number nine so this is the last major event in the scrum methodology which is print retrospective meeting so here basically it's the participants or the scrum team themselves the development team the scrum master product owner the main agenda is to identify how we can make the product development process better simple yeah so they look at all the uh impediment list that's the main thing so that they can be prepared in the next print and also the review comments which were provided by the stakeholders in the review meeting so those things can be kept in mind uh while working on the next sprint and also the burned on especially the progress uh and how how what where like what what things can be done better in order to hit the plan so it's more of a looking back reflecting back and also looking forward so those outputs would be the action items for improvements which can be implemented in the upcoming sprints so that there's a better process question for this particular video is again it's what is definition of done this is one of a tricky question which is asked and basically it's an exit criteria which is agreed with the product owner and the development team for marking a backlog item has been completed and it's ready to be shipped so example login feature or one of the features which we discussed the seed selection feature yeah it can be only termed as done if it is coded tested reviewed and accepted by the product owner so this is one of the terminology for an item to be termed as completed so let's say if the one of the item is only coded and tested you cannot term it as done all these factors which have been pre-agreed should be completed in order for an item to be complete termed as done hello there do you have a business analyst interview coming up shortly if so this is the video for you in this video we're going to discuss the top 15 commonly asked interview questions on acronyms or ba terminologies used in business analysis ranging from crud sipoc rfq rfi cots and much more we're going to take the term expand it and provide its usage with an example so that this will help you to answer the questions in the interview process we have a lot to cover so let's get started question number one what is invest invest stands for independent negotiable valuable estimable small testable the inverse guidelines are used in agile methodology while writing the user stories the above criteria ensures a well-written news stories let's look at it again independent it talks about the user story being independent of other user stories dependency between user stories create complexity and wherever possible we should maintain uh user story independent of the others negotiable this talks about having a conversation with the team and trying to work out the details of the story accordingly valuable the this talks about the user story should be creating value to the end user be the customer or be the staff or working with application if it doesn't deliver any value then there is no purpose for user story to be on the backlog in the first place so to ensure that the user story creates some value to the end user estimable so this talks about how the user story should be written so that the development team can help i can you know look at the story and come up with estimates it can be a ballpark but yeah it should be able to estimable by the development team so that it helps in the prioritization process and the release planning small wherever possible the story should be broken down into uh the smallest part of it and it should not be combined with other features so wherever possible it should be limited to a single requirement from an end user or from an internal staff so it becomes easy for development testing and maintenance the last part is testable so by looking at the user stories the testing team should be able to come up with their test scripts and help in their testing process ideally the acceptance criteria helps in this place acceptance criteria as part of the user stories can be created sorry translated into test cases and can be used by the testing team question number two what is crud crutch transfer create read update and delete so these are the four basic functions to be considered in software development while we're dealing with data and this the same uh thread can be used for drafting you know high level requirements if you're looking for an example uh and you're i'll be tasked to do a requirements for an online food ordering app even before you are meeting the business you can just come up with these requirements using crud c stands for create so customer should be able to place an order r stands for read customers should be able to view their order and u stands for update customer should be able to update their order and d stands for delete customers should be able to cancel their order so it's a very good technique to uh ensure that the data is handled end to end right from creation up to deletion question number three what is what so what stands for strength weakness opportunities threats it's a strategic planning technique used to craft out strategies let's try to look at this with an example one of your clients is a business owner and sorry restaurant owner and he has a come to your consulting firm seeking help on how to uh you know how to create a strategy to combat a new restaurant which has come down the corner so you can use swot and help out craft that strategy so let's let's look at it first we identify what is the strengths of the client so the bus the restaurant uh has been for a while and it's very appreciated for its uh taste and also it is highly economical and there's huge flocks of crowd are you usually coming during the lunch time uh during the office hours to grab a bite so that's the strength if you look at the weakness the restaurant closes at uh 8 p.m uh due to la you know not not many office going people kind of hang out at that particular restaurant whereas a new restaurant which is coming up is open till 11 a.m so if anyone after 8pm wants to kind of uh you know hang out they can go to the new restaurant so that's a weakness so one of the strategical point to combat it is maybe open the closing time of the restaurant next and the closing time of the restaurant maybe to 10 or 11 and you know see how it works out and then the opportunities so this new restaurant bringing up it opens up for opportunity one of the opportunities which you can think of is the client's restaurant is in indian cuisines while the new restaurant is chinese so maybe can just have a conversation with the restaurant owner and try to see if you can cross cross serve maybe they can promote your restaurant i can tell you if you're an indie restaurant you can go down the rounder and you can do the same vice versa what's happening is collectively you're trying to in collaboration you're trying to grow each other's business the threat is the new restaurant um happens to be better and it's able to serve faster than i think you this particular business will be taken out of going on question number four what is uml this is a very commonly asked question in the interview sessions uml stands for unified modeling language it's basically a standardized modeling language for visualizing and documenting the artifacts of the software programs most commonly used uh uml diagrams are the activity diagrams use case diagram sequence diagrams so basically these diagrams provide a view to the development team how the interaction between the user and this system should be which will help them to visualize and come up with the solution accordingly question number five what is the difference between rfi rfq and rfp this is one of the commonly asked confusing question in the interview process i'm just going to try to simplify it in this particular slide rfi stands for request for information all we're doing here is reaching out to the different vendors and trying to understand what are the services or the capabilities which the vendor can deliver only that nothing much just reaching out and trying to understand the services which they provide rfq stands for request for code this is usually uh used when you know what you want you're reaching out to the different vendors to understand what the cost involved in delivering the solution for that for that particular requirement so this involves reaching out to the different vendors just telling them what you need and trying to get the code from them for comparison the last one is rfp this is the one which is commonly used this involves a kind of a business stay a business need or a problem statement you reach out to vendors and you give them that and you ask them to come back with their proposal and the cost so the proposal would basically involve the approach the tools which they'll be used are using to solve the business problem statement or achieve the business need and also the cost involved so rfp is one of the most commonly used but there there are uh companies which do use rf i and rfq as well question number six what is cods cots stands for commercial off the shelf code system are developed and maintained by external organization and they are just implemented as part of the business to meet their business need or solve a problem statement rather than developing their own in-house software system for example a business needs a customer relationship management platform instead of developing an in-house solution they can go and get sap crm zoho crm or salesforce similarly if they want to send out emails to their customers they can use a vapor get response etc so the idea here is instead of using the time developing in-house system the business can use a readily available software and they can get started to address their business need or resolve a problem statement moving on to the next question what is wbs wbs stands for work breakdown structure this is a process of decomposition of the task and effort required to complete a project or an objective so from a ba prospective let's say you're tasked with the requirement gathering for a particular initiative so at a high level the initiative will result in a requirement document maybe in form of use stories or brd or fl you know the functional requirements so in order to break down and make it more easy for managing and reporting maybe you can split that requirement gathering sessions from a customer facing view and then you can have requirement gathering session with department e department b and department c so you're basically breaking down the requirement gathering process across and having some timelines to it and also then crea having a process of documenting the requirements and getting the required sign off so all of these act activities can be broken down and then into small components it can be planned and managed accordingly so they provide some more visibility and easy for the individual performing those activities to accomplish question number eight what is cpoc sipoc stands for suppliers input process inputs process outputs and customers cpoc diagram is used for defining the scope of a process improvement initiative and also helps to understand the current state and then to work out on the process improvements so cpoc ideally basically talks about who the suppliers are what are the type of inputs they provide to a process raw materials data etc and then what is the process which converts the inputs to the required outputs what are the required outputs and who are the ultimate users of those outputs so it's in a in a simple line uh in a table or a diagram can understand what's happening currently and can work on the process improvements accordingly question number nine what is jad chad stands for joint application development chat sessions are similar to workshops or where you have a variety of stakeholders ranging from the customer the end user smes business stakeholders business analysts developers all collaborating together for capturing high quality functional requirements basically you want to uh the end result of this particular session would be what the what is that the system should do in order to accomplish the business requirements so that's the whole agenda for this particular sessions and this provides a a good understanding to the development team uh what is required and also some business context on why it is required so that it will help them to develop the solution accordingly question number 10 what is bpmn bpmn stands for business process model annotation bpmn is a methodology or an industry standard language used for visually represent representing the business process in the form of diagrams so the business user or a technical developer if they just look at this business process model they will be able to understand or what is the flow of events who does what so usually the business process models are in the form of swim lanes uh one actor and all the activities for that actor are confined to a swim lane so if you're taking an example you have actor one and actor two let's say customer uh and a ticket provider for a movie tickets so customer walks in hands over uh informs the the ticket counter which show and how many tickets he or she wants to buy and then the ticket provider will just show them the screen and as ask the customer to pick the seats once the seats are being picked picked by the customer uh the ticket provider confirms the ticket and then uh charges informs the customer how much the ticket is and once the customer pays the money the ticket is printed out and handed over to the customer so this back and forth interaction can be easily represented in a business process model and let's say if a business is trying to take this journey to a digital channel where the customer can book their tickets using phone or you know online then this particular process model can be used to model the interac the interaction by the developers and it's pretty easy it's all there in a process model it's easily understandable and can be used accordingly for the development question number 11 what is dfd dfd stands for data flow diagram so dhp is a visual representation of flow of data through a software system again this really helps the development team uh during the development process so let's say if you're working on a reporting requirement uh you can provide a view of how the data is captured and where it is stored so let's say example the customer data is captured through the you are the front-end screens and it is stored in one particular database similarly the transactional data are recorded in another database and then how which are the fields you can try to capture from which database so you can you can provide this view in a data flow diagram and this will really help the development team to come up with a required solution for the report question number 12 who is an sme sme stands for subject matter expert smes are invaluable resources for understanding how the current processes work so uh they are actually either uh you know experts in their own niche or on field for example if you're looking at a particular part of the business the first point of contact uh would be an sme because they know inside out they've been in the system for a few years they may be uh senior team members of the team or business architects or sometimes even the business analysts who have been working on that particular uh process for a while would be an sme the smes are really key during the requirement gathering phase uh when you're eliciting requirements they are the point of contact to provide how the current process is and what are the things they would require to make it better question number 13 what is rtm rtm stands for requirement reasonability matrix it's basically a matrix used to trace requirements it provides the backward and forward traceability and it helps in a faster impact analysis and unreliable assessment to ensure all the business requirements are designed developed and tested so let's look at an example in the below diagram we have a business requirement it's a map to the stakeholder requirements one and two and the stakeholder requirements is further mapped to the functional requirement and non-functional requirement and then the functional requirement in turn is mapped to the design component which traces to the code whichever language it can be written in java.net python and then the particular code then it maps up to a test case so if you just look at this particular diagram and metrics you can ensure that a business requirement here on stakeholder requirements here is is is designed developed and tested so this provides an end-to-end view and ensures that everything is covered question number 14 what is roi roi stands for written on investment this is a very important metric and it measures the return of investment relative to the investment cost and this is a again as i state it's a very important metric for approval of a project or an initiative let's take an example if there are a certain number of business use user perform users performing a certain activity and let's say on an yearly basis that amount is around hundred thousand dollars spent year-on-year for that particular activity and there is a proposal for automating that part and the cost for implem implementing the solution would be let's say 50 000 and then year on year maintenance cost of ten thousand dollars so if you look at a five-year uh time frame without implementing this solution the cost would be around five hundred thousand dollars a hundred thousand dollars a year on year but if we implement the solution the total of cost for five years would be hundred thousand dollars uh fifty thousand dollars for first year and then ten ten ten ten for the subsequent years sorry it's 90 000 so when you're looking at five year time frame with implementation of the solution it's 90 000 without implementation of the solution it's 500 000 so there's a clear benefit of 410 000 uh saved due to implementing this particular proposed solution so when you present these figures to the business it's easy for them to take a decision for providing the funding and go ahead for a project or initiative moving on to the last question question number 15 what is uat i believe most of you guys already know know the answer but i just wanted to cover it off the uat stands for user acceptance testing uat is performed by the business end users of that particular application and they check whether the developed software works in line with the with their business requirements and the business analyst role in this part would be to assist the end users to perform uat uh by helping them with the test cases desk scripts defect arising a defect defect management or defect resolution and also to clarify whether a certain request which is raised during uat whether it's part of the initial requirement or is it a scope creep hello there do you have a business analyst interview coming up shortly if so this is one of the videos for you in this video we're going to cover the top 11 into week questions asked on sql queries you may be wondering why would they ask sql query in a business analyst interview if you are appearing for a role of a system analyst it business analyst or in a techno functional role then definitely there will be questions on sql so this video will help you prepare for the interview and also having a techno functional expertise is always considered a plus during the hiring process so we have a lot to cover let's get started before we proceed further i would request you to please go ahead and subscribe to our youtube channel if you have not already done so and also please go ahead and click on the bell icon so that you will be notified when we will be uploading a new video in the business analyst interview series we are planning to upload 10 more videos so please go ahead and click on the bell icon so that you're notified whenever we upload it okay let's get started as we usually do we look we take a case study and then answer the questions using the case study so in this case study we are going to have a company e-commerce company which is selling electronics like mobile phone laptop on tab tablet and this is a particular table in the database called orders which kind of records who's the customer what are they ordered what is the value of the order in which city they awarded and also the mode of payment is it cash paypal or credit cards so we're going to use this table and then we're going to derive the the queries and also look at the results question number one how do you retrieve all records from a table so this is one of the most commonly asked and the basic question anyone will ask you an interview so the sql query for that is select star from table name so in our example the table name is order so that's why it's select star from orders and the result would be all the rows and the fields which we saw in the table would be displayed question number two how do you retrieve only custom name and order value fields so the select star displayed all the fields from the table now the interviewer will be checking your knowledge on how would you retrieve certain fields which are of interest to you so here the customer name and the order value so the sql query for that is select name which style which is for the customer name and value which is for the order value from orders the table the result would be as such so now if you see the result will have only two fields or two columns corresponding to the customer name and the order value it won't show all the fields which are you know from the table so this will help to uh focus while you're doing the analysis when you're looking for only certain values uh certain fields and their values question number three how do you retrieve only customers with order value more than five hundred dollars so this is again some conditionality is being uh placed into the question so the sql query for this is we're going to select the name and the order value from the table but we're going to add a conditionality which is where value is greater than 500 so what this will do is it will only filter out the rows with a order value more than 500 dollars so from our previous example we had seven rows but now there's only four rows displayed because only four rows for these four uh customers the other value is greater than five hundred dollars again this will help you i will performing the analysis and that's why these are the questions which the interviewer will ask so that to kind of uh gauge your depth under understanding in the sql queries question number four how do you retrieve only customers with order value more than 500 and from ordered from seattle which is a city so again building upon from the previous question here we are further fine tweaking the conditionality and getting a narrower result so the sql query for this remains the same as what we saw in the previous question only the additional thing is where value is 500 and city equal to seattle so and city equal to clt will be the additional part in the sql query which will give us a result as such uh where we had four rows from the previous query but this query will return only one because this is only a row which satisfies both this condition where the value is greater than 500 and also the customer ordered from seattle so that's why we're again fine tuning it so these are all again conditional conditional questions which will be asked to gauge your understanding on sql queries most of the time it will be based on scenario they won't just ask can you give me an example with this and that how do you filter it'll be most on a business scenario so that they will they they understand that you understand the concept of how do you take a business query and business requirement and translate into a sql query moving on question number five so again we are asking how do you retrieve only customers with order value more than 500 or more is cache again these are all conditionalities but here it's our conditionality either this or that so we'll look at the query it is the same as what we saw previously the only change is after value is greater than 500 we have a r clause and then mode equal to cash so we are interested in customers with order value more than 500 or was paid in cash so the query will return as such if you see there are five rows here and i want to point out the row number two smith even though his order value is less than 500 which is 450 because his cache mode the mode is cache the sql query will return this particular result moving on question number seven so here uh the question would be how do you retrieve customers whose order value is between 100 and 500. so this is a range question i think we covered values now this is a range so the sql query for this is again name value from orders but we're going to use a clause called between so we're going to use a where value between 100 and 500 so what this sql query will basically retrieve is all the order values ranging from 100 to 500 and the result would kind of look like this so these are the three records which are having a value greater than 100 but lesser than 500 so this is again really useful when you're doing the analysis and also translating the business requirement into functional specs and also sometimes the itbas provide inputs to the technical spec and that's where all these queries will come in handy pushing forward question number seven how do you retrieve only customers ordered from seattle and baltimore so the previous question was more of a range and this question is uh values if the value equals to this or that how it will happen so one of the uh syntax we can use is the in in syntax so we select name city from orders remain the same but the where conditionality changes with city in seattle baltimore so which will result the records or the rules of of customers ordered from seattle or baltimore okay moving on question number eight so this is a very interesting question how do you find the total number of rec orders so the interviewer might just ask how do you find total number of orders in the database so the syntax for that is count star so if you hit select count star from orders it will give you the number of records from the table so in our case study or example we had seven records and that's the reason the result would have written seven question number nine how do you insert a order to the table so this is so we all the queries we looked at till now is more of fetching the data so this query would be insertion or addition of a order of a record to the table so let's let's see the sql query for the same so this is a query insert into orders which is the table name and we're going to list on all the fields of the particular table order number name category value city and mode and then we are going to input the values which we are going to add to these particular fields using the values syntax and then we give order number is 8 name of the customer is jane the category of purchase is mobile value of the purchase is 300 city from the purchase where the purchase is made is new york and the mode of payment is cash so this is a query once the query is executed the result would look like this the table would have an additional row which is the last row or order number eight and all the parameters which we have supplied as values will be added to that particular row of the table question number ten how do you update an order value so we looked at fetching the records then we looked at how we add a record to a table let's say we have added a record to a table but the value is not correct it's incorrect due to an error so we can use the sql query with update to update it to the correct value so the syntax would be something like this update orders set city equal to baltimore so the city we had entered as part of the insertion was new york but which was incorrect actually the customer ordered from baltimore so now that's why we are updating it using set city is equal to baltimore where order number is eight so this order number or where order number is equal to eight is the clause basically it'll search for this particular record we know it's unique because order number is unique and then it'll look for the city and replace whatever value with baltimore so post the execution of this query order number eight would look something like like this everything will be the same except the city would be updated from new york to baltimore question number 11 the last question in this video how do you find customers with minimum and maximum order value so is this again an uh query for analysis so if you want to find what is a minimum order value the syntax is select min value which is the field name from orders so this would result in 225 because this is the minimum order value in the orders table similarly if you want to look at what is the maximum value we want to find out what the maximum order value then the syntax is similar select instead of min it will be max value which is a field from the orders table and the result would be thousand so if you've seen earlier 1000 is the highest order value placed by a customer till now and that's the reason thousand would be written so again these are all um kind of uh analysis queries uh and it and it can be comes in handy during the analysis phase so that's about it from a questions and answers perspective so it's only 11 questions again as i told earlier these are all very simple queries but if you don't get this right you won't progress further in the interview uh the interviewer might not be even interested to ask more so i know these are basics but it's good it's uh you know always good to revise the basics and in the next two videos i'll be covering most of the more advanced sql queries and also some more concepts of sql like rdbms or the different types of keys primary key for foreign all those things i'll be covering in the next set of videos so please make sure your you subscribe to this uh youtube channel and click on the bell icon so that whenever we load it you'll be notified question number three what are the different levels of testing this is one of the question asked to gauge your knowledge of different types of testing across the software development life cycle let's look at it i've summarized it in this particular diagram so the first level of testing is called the unit testing and it is done by the developers so once they've written the code they check if everything works fine as per the requirement the second level of testing is called sit or system integration testing so once the unit testing is successful it's deployed to the sit region and sad environment and then the the testers would be performing the system integration testing just to ensure the connectivity works and all the test cases and test scenarios which have written against the requirement works well and the thirdly the third level of testing is called uat or user acceptance testing so this is done by the business users so these are the end users of the application which is being developed and these are the users who would have provided the requirements in the first place so they will be doing it or there will be a representative from the business team who will be doing it on their behalf so they'll be checking whether the application develops satisfies their requirements and once everything is successful then the the code moves to the production environment so the go live or the deployment of production usually happens on a weekend and once the code is deployed to production there will be a couple of people from again from the business team the end users will be checking whether the code works fine in the live environment so there's no hiccups there's no at least the basic critical test cases would be executed by them to ensure everything works fine so this type of testing is called live testing there are different names to it but the concept remains the same so these are the different levels of testing i hope it helps on understanding the concepts involved there in this video you're going to look at a variety of topics uh from business analyst role in testing creation of test plan rtm test scenarios and test case creation and also the different testing tools used and also we're going to look at all these questions from a view of a business analyst so this is a really a different view and all the other videos which we have on testing interview and questions and this talks in specific and in relation to a business analyst and also if you have not already subscribed to our channel i would request you to please go ahead and subscribe to our prefix ba youtube channel so that you're notified when we come up with the next video we have a lot of cover so let's get started to make it easier for grasping the concepts and the answers we're going to use a case study in this case study uh a movie theater chain called xyz cinemas is looking to build a digital channel for allowing the customers to book their movie tickets online rather than now calling up the customer care or standing in the long queues and getting their tickets at the ticket counter so we are going to use this uh example case study for answering all the questions question number one what is the role of a business analyst during testing phase this is a sure short question and ninety percent of the time this question would be asked in the interview so there are two major testing phases uh one will be the site system integration testing the other one will be the uat user acceptance testing so we're going to look at the rules and responsibilities of a business analyst during these two key testing phases so let's start with sit so the first key responsibility of a business analyst would be the walkthrough of the requirements to the testers so the business analyst will explain what the requirement is answer any questions from the tester so they understand what is being required and now what is being developed and then the testers will go back and come back with the test scenarios and test cases and that is a second task for a business analyst to review them and ensure that they have got the scenarios and the test cases right for all the requirements which leads us to the third point which is checking requirements traceability we're going to talk about more on this in the subsequent slide when we talk about the requirement and traceability metrics but here just to this step is done to ensure that all the requirements are having a subsequent scenario or test case and then the other key part or key role is when the test execution happens once the defect has been locked by the uh the testing team it is assigned to the to the business analyst first to ensure that the defect is valid before it you know gets assigned to the development team if it is an invalid defect like invalid scenario or the testers might not have understood it correctly then it can be rejected by the business and less than and there so that the time of the development team is not wasted so it's like a different triage it's done by the business analyst the last key thing is articulating business impact and assisting in defect prioritization let's say there are like 10 defects and there will be a question asked what is the priority of the defects because we might not be in a position to fix everything by the development team then it becomes a responsibility of a business analyst to get the business impact for all those defects and then assign the priority one two three so that it makes it easier for the development team to get it done and if there are further defects it can be pushed over to the next release which are not very critical or high so that's on the site coming to the uat i think most of the things what we discussed holds good for uat as well the walkthroughs the reviews or traceability validity of the defects and articulating business impact along with that this is where there would be additional things asked by a business analyst that is here creation of the test scenarios and test cases so as you know the uat is done by the business users and they are not very uh equipped with testing concepts or you know testing or they might not have that time because they are doing you 18 addition to their day job so there will be a request rise for the business analyst to create the test scenarios and test cases so this is where your knowledge of scenarios and test cases will come in handy and the other one would be this management and reporting again due to the lack of bandwidth by the business use users so the management like the test planning creation of schedule strategy environment setup all of those things would come as a responsibility of a business analyst and also the daily reporting and ensuring the high priority defects are being resolved all those management is being asked by to the to be done by the business analyst ideally these were a traditional role of a test manager but nowadays the trend has been the business analysis are being asked to pitch in so having knowledge of these will give you edge over the other candidates in the interview process question number two what is functional and regression testing i know there are a lot of different types of testing sanity testing load testing performance testing etc etc but with respect to business analysts these are the key or two key types of testing which is functional and regression so let's look at them quickly first one is functional testing this refers to testing of functionalities developed as part of that current release so these are the new functionalities which are delivered and testing of those functionalities is referred to as functional testing regression testing so this refers to testing of the existing functionalities and to ensure that they still work fine post addition of these new functionalities to the application so this is usually done at the end of the test cycle let's try to look at these with an example so again the example refers to our case study and the new release delivers the online payment functionality to the customers so prior to this release customers were using the application to book movie tickets post booking the tickets they would use to get a confirmation and then they used to give the confirmation to the ticket counter and pay make the payment either using cash debit card or pay mobile balance at the ticket counter suppose this release the customers can make online payments through the application itself so they don't have to take the confirmation go to the ticket counter and all of those things so it's much more simplified and a better customer experience right so let's look at what is functional and regression testing in this example functional testing so this refers to the online payment functionality which is being deployed as part of the current release so it's a new functionality so testing of that is known as functional testing regression testing so testing of the functionalities which were already existing which is like registering login seat selection for the movies so all of these are existing functionalities and they still need to work post the deployment of the online payment functions functionality so testing of those existing functionality is referred to as regression testing so these these are the key uh types of key to uh two types of testing and which would be asked by the interviewer question number four what is a test scenario a test scenario refers to a particular functionality which needs to be tested as simple as that so test scenarios uh can be created using use cases if your project is using waterfall methodology or acceptance criteria if your project is using agile methodology so if the business asks you can you create the scenarios there's no need to panic all you have to do is translate the use cases acceptance criteria to test scenarios as simple as that let's look at a couple of examples to give a wider context so again these examples are taken from our case study so test scenario number one check the search functionality for the movies so this scenario basically talks about where the customer can enter a keyword and the appropriate movie appears in the listing test scenario number two check the availability of seats for a particular movie so this is where the customer logs in selects the movie the timings and then goes to a screen where it shows which seats are available or which seats are not for selection so the seats which are available maybe in white and the seats which are not available can be grayed out just scenario number three check for the online payment functionality so this is a functionality where the customers can pay using credit card debit card paypal or any mobile ballots so if you see all these scenarios test scenarios are basically either use cases or acceptance criteria so if a need arises for you to create a test scenario it's as simple as translating the user's use use cases or acceptance criteria question number five what is the test case or the components of test case so this question uh is another commonly asked one so test case is defined as a series of actions executed to verify a particular functionality so basically this is an extension of the test scenario so these are the steps taken uh by the tester to verify whether the test scenario is as per the expectation so let's look at it using an example so if we you look at the test scenario which was check the availability of seats for a particular movie let's see how a test case for it looks like so there will be a test case name so can we test the seat availability display and then this table and the columns are pretty key here so it has the step number description expected result actual result pass fail defect id so this answers what are the components of a test case if asked the these are the key information key columns there can be additional columns used by the sit testers but again if if if it's from a uat perspective and you're preparing a test case this is more than sufficient so let's look at the example so step number one and the description so the description is like enter the xyz cinema url what is the expected result this xyz cinema's website should open in a browser and step number two search for a movie expected result is the search movie should appear with an image and the name step number three uh click on the movie uh name or image once it is clicked the expected result will be the timing should be displayed and then the last step is to click on the particular time and here is where the the key uh test key expected result is which is the seating arrangement should be displayed with the available seats in white and the reserve seats or the book seats already grayed out so this is the expected result so you're doing all the steps involved to come to step number four to check whether the available seats are shown in white yeah and can be clicked so this is how a test case looks like or these are the components of test case so this can be used to answer the question as far as in the interview and if the business asks you to prepare a test case you can use the same template to prepare one for the uh the business in the next slide we're going to look at the test execution and how the remaining columns are filled so let's look at it in the next slide previous slide if a question is asked what happens in the execution so you can use this explanation as a reference let's say a business user is executing this particular test case as part of the uat the actual result pass fail and defect id the last three columns should be updated as part of the execution so if you go by this so the first step was to enter the url for the xyz cinemas the website should open which which it did and then the second step was to search for a movie the actual result was once it was searched the movie with the image was displayed the relevant movie which the customer was uh searching for and then once the the movie was clicked the timing should have been displayed which was displayed in this uh execution cycle so once these steps are successful uh which is the actual result is as per the expected result then the pass fail column should be updated with pass pass pass indicate indicating that these steps were successful let's look at the last step where once you once the particular time is clicked the seats available seats should be shown in white but what was observed was all the seats were grayed out even the available seats so which is a fail so this particular step was not successful so when this happens the tester needs to indicate it by fail by updating the password column as fail and then a defect has to be erased so a tool which is used for defect management jira qc whatever is used in the particular project defect has to be raised the defect usually contains what is the defect what is the problem expected actual results what are the steps taken all of this information is already available it can be taken here and copy pasted there and also accompanying screenshots so this will help for further investigation of the defect we're going to look at the defect life cycle the next question but just wanted to give you a view of what all the key components of raising a defect so this is what happens in the execution so if there's any question asked so this explanation can be used to answer answer it question number six explain the defect life cycle so this is one of the most commonly asked question in the interviews on testing so let's look at it so it all starts with a defect being raised by the testing team it can be sit or it can be uat the business user the the life cycle remains the same so the defect is rise i've indicated the status of the defect by the highlighted yellow box the status of the defect will be new and before going to the next step it's very crucial and critical that the the these components are present in the defect which is the description of the defect what exactly is a there's a problem and what is what was the expected result what is actual results and what was the steps taken to execute this particular test case and then the screenshots the relevant screenshot so this will really help the the analysis of the defect to be very faster so once the defect is raised it's usually assigned to the business analyst so it's your job to first check whether all of these components are available if not first and foremost you have to inform the testers to add all these components so it comes to the business analyst the business analyst first checks whether it's valid or not whether it is asked by the requirement or the testers are testing something which is autoscope so if it's valid then it is it gets assigned to the development team and the status of the defi defect gets changed to assign and in case if it's not valid the business analyst rejects the defect stating it's an invalid and also the reason for rejection and the status of the defect goes to rejected and then once it is assigned to the development team the development will team will check the validity of the defect first if it's not valid maybe it's this detailer or environment then it gets rejected as invalid with the reasons specified by the development team but in case it's valid it goes further investigations are done by the development team so the first check is to check whether if there's any duplicate defect already out there so this is more common when if you're doing a pro testing of an application for a global robot so there will be multiple countries involved or multiple stakeholders testing the same thing what would happen in that scenario as there would be multiple testing teams testing the same functionality and there are a lot of cases where there might be duplicate defects so they'll check whether it's duplicate or not if it's duplicate they will tag it to the original defect or the defect which was raised first and the status of the of this particular defect will be a duplicate and then let's say it's not a duplicate they will check whether they're able to fix it so there are several reasons where the development team might not be able to fix a defect one of them would be the time constraint let's say that defect is raised three days uh uh until the end of the testing cycle or two days or on the last day so this doesn't give the development team enough time to fix it or if a defect is too complex to fix maybe it requires architectural changes so there are variety of reasons where they won't be able to fix it in that particular release then those type of defects would be deferred to the next release and the status of that particular defect would be deferred and then let's say they're able to fix it if they're able to fix it then they would resolve the fix and then they will deploy the fix so once this deployed the fix is deployed the status will change to fixed indicating the testing team to retest the defect so that defect will be retested if the defect is fixed or not if it's not fixed it will be reassigned back to the development team with with stating the same thing the providing the resale read test results the screenshots etc etc let's say if it is fixed then the defect will be closed and the status of the defect will be closed and also there are the other defects the rejected ones and the duplicate ones are also will be moved to closed eventually and then this brings us to the end of the defect lifecycle again a very key question so you can use this and also try to use an example when you explain this to the interviewer question number seven what is the difference between priority and severity again a very commonly asked question and it's a tricky one most of the people get it wrong and this is a key one for a business analyst because business analysts are involved in the prioritization of a defect so let's look at it priority priority basically defines the order in which the defect should be fixed and it's based on the business value so let's say there are 10 defects the priority defines how the development team should be fixing them and the priority is based on the business value again so one of the key activities and responsibilities of a business analyst is during the defect management defect triage to come up with this priority so which will help the development team to fix the key defects uh for you know the release so that you know the release goes as per planned and the lesser priority ones can be taken up in the next release severity so cvrt is a degree of impact the defect has on the operation of the application so this is the functionality's uh impact so if for key functionality it doesn't work the severity is very high and it is severity is based on the impact of functionality so there are again two priority and severity are two different things but you know it may look the same but they are slightly they're two different things uh let me try to explain this with an example and this is also again a commonly asked question can you tell me an example of high priority and low severity so one of the things is the company logo is wrong so there is no key impact to any functionality if a company logo is wrong so it doesn't the severity is very low but the priority is high because if the company logo is not correct one if the customers who are visiting the xyz cinemas online booking website they may think you know what this is not the website or this may be a scammy website or there are a lot of thoughts and this will prevent the usage of usage of this particular online booking service by the customers so from a business perspective it is a very high priority and it needs to be fixed so this is one of the key examples which can be given the other one is high severity and low priority so the footer links on the online booking platform does not work let's say for an example so they don't work and from a functionality perspective a url not working is a high severity but if if the online booking url if it's not working like if they click on book tickets if that doesn't work then again it becomes high priority but if the footer links does not work it becomes low priority the reason being is most of the customers don't use it let's say 90 of the customers don't click on the footer links so in case if it's not being fixed on this particular release due to the resource or time constraint it can be fixed in the next release so it becomes a lower priority so this is the difference uh and uh you can frame you can use examples from your own own past projects so that'll add more value while answering this particular question moving on to question number eight what is rtm or requirement traceability matrix we covered this in couple of our videos earlier but i'm going to cover it today just from a testing perspective so as you know it's a matrix used to test requirements backward and forward from a testing perspective what is required here is to ensure that all the business requirements are covered as part of testing which is the mapping of the requirements to the test cases so if you look at an example the business requirement would be mapped to the stakeholder requirements and stakeholder requirement would be mapped to the functional and non-functional requirement and then the functional requirements which would be mapped to the test scenarios and test scenarios will be mapped to the test cases so this is the key part and when as a business analyst as we spoke about in the first question that is one of the key responsibilities of a ba is to review the test cases and ensure you know that it all covers all the requirements so you can use the requirement traceability matrix to do that so you can map all the test scenarios and test cases and ensure that everything is covered as part of the test cycle both from an sit and also can be same can be used from a uat perspective this brings us to question number nine the last question what are the tools used in testing so this particular question is asked used to just test your exposure to testing related activities and also the artifacts you can just pick and choose from the table here to answer this particular question so the test strategy test plan uh documentation is done by ms wood we didn't cover this as part of the video this is another thing it might require a video on its own but this plant strategy is basically a document which provides the approach which would be used for testing the testings which are in scope the schedule when will the testing will happen in scope out scope and also the rules and responsibilities and reporting uh but it's a video on its own so that's the reason i didn't cover it here but it's all done using ms word and then the test cases documentation the test case which we discussed so the documentation is done using qc or alms so these are the tools used if there's no tools used then it will be just ms office which is the excel and then the google sheets if the company doesn't use office and they just wanted to use the google suit then google sheets is used and then for execution qc or alum is used so in the tool itself once the test cases are done instead of updating it on an excel spreadsheet the testers can update it directly in the tool itself and reporting is very quick you can just export the whole results for you used on the test execution update done to qc or alum so that's one key tool and then the defect logging so we discussed the defect lifecycle and the there are a lot of tools in the market for defect management and logging defects so the common used ones are jira in case of agile if it's waterfall still the qc alum is used and we have bugzilla and clearquest so these are some common common use tools which have come up in the recent past and then for screenshots for defects so i've stated that the screenshots are very key for defect management and for screenshots we have some sniping tools like uh snagit uh light chart screen ticker if nothing works you can just take a screenshot and edit it using ms paint so this helps to provide more details in the defect for the business analyst or also the development team for quicker resolution and in case if there's database testing involved then toad or squirrel is used commonly used so these are some commonly used tools you can just pick and choose based on your experience while answering this particular question wow that's a long video i didn't expect it when i started filming but thanks so much for sticking around to this point did you enjoy this video if so i would request you to go ahead and subscribe to our youtube channel and also download the business analyst interview guide so there's a link in the description you can click on it and download it it will have over 50 plus questions again commonly asked questions which will help you to smash your next business analyst interview so please go ahead and download it and use it as a prep material for your next business analyst interview and also i request you again to subscribe to our channel we post videos regularly on business analyst techniques tools uh tutorials and also interview prep so until i speak to you in the next video thank you so much for listening to this particular video see you around and bye bye

Channel: ThePrefectBA

Views: 202,158

Rating: 4.9288316 out of 5

Keywords: business analyst interview questions and answers, interview questions and answers, business analyst interview, business analyst interview questions, business analyst, business analyst training for beginners, business analysis, business analyst interview questions and answers for freshers, BA Interview, BA Interview Questions, ba, business analysis interview, BA interview questions and answers, business analyst interview preparation, interview questions, job interview

Id: YxNMzdYoXR0

Length: 178min 7sec (10687 seconds)

Published: Tue Sep 22 2020