 All right, go ahead with your basically role you can share the screen too. Okay, just one moment. All right, so Sidra. Can you see where it's a crane? Yeah, you can see your screen. So go ahead with your role like... Okay, be a role. Describe the role of a be a... A role of be a during the business analysis phase. There are three basic roles of the business analyst. First is to build the understanding about the project, what actually the project is. And he gets access to the existing documentation at the share point and read all the available available information on the project charter which give the information about what actually the project is. What is the statement of the problem and list of the stakeholders and current state and the future state of the project. Then he can talk to the subject matter expert which is the helping person for the business analyst to onboard him for the project. Then the next task of the business analyst is identification of the stakeholders. He can scale the meetings with the stakeholders and present the project. And in the project, he can describe what actually the title of the project is and what the title number of the project and what will be the outcome and what is the current state and scope of the project. Then the next task is he has the requirements gathering session with the business analyst and where he create the... He will get the requirements and he create the business requirement document and upload that document on the share point. BA will explain the picture of that document very well rather than the stakeholders to the team including system analyst, developer and QA's quality assurance team. BA give the review of the document and explain the current state and the future state and requirement of the project. If he has any query then the BA is answerable. So I have the question here. The business analyst document the requirement in the form of use case. Is it right or not? No, it's wrong. Use case is written in a system specification document. Who writes the system specification document? Business analyst. The system specification document SSD. Right. So he will create the system analyst will create the use case. Use case is a component of system specification document. All right. Okay. Got it. So in the next phase the BA role during the system analysis phase the system analyst system architect software architect solution architect. They use this BRD to understand the business needs and then propose the solution and design the system. The system analyst present the different solutions that the design options in front of relevant stakeholder and the requirements are documented as system specification document functional requirement document system design document at the system design. And these are the name of all the names of the same document. Okay. So during the system analysis versus the function of the BA the BA will walk through the solution team with business requirement document. He and she review the document with the analysis team if they have any query the BA is answerable. The nature of the question might be very depending on the nature of the project in each phase. So the role of BA during the development phase when all the requirements satisfy and developers start working on it. The developing team do coding on them and prepare the test cases as the development happens that developers create user stories in agile. Is it right. Right. But you know we are just talking developers create a user stories in agile. You know that's not right. First thing develop a role of a BA during the development. So developers are, you know, just leave the agile part yet. Okay. Then the BA review the documents with them with the developing team system analysis team and the testing team and will helping them understand the requirements note the requirements and answering them. If BA don't know the answer then he may go back to the stakeholders. In the next phase, the role of BA during the testing phase. Testing phase is basically done by the quality assurance team and party assurance team work on these test cases to prepare the test case use case and user stories. So the BA role is same as in developing phase to review the documents with the testing team. The last one is the role of BA during the user acceptance testing. Basically the end users normally perform the user acceptance testing. They are the most efficient group to test the software in this in this form because they know exactly how the software will be used on a daily basis and what changes need to be made to be suitable for this day to day use. And UAT happened when testing complete and BA has two roles as the stage. BA asked to the stakeholders that the product is ready to use and who will be the testing person as business users. Stakeholders provide the list of business users are the UAT testers who will test on business behalf. The second role is at the same time the BA work with quality assurance team and ask them for the login and the password for the UAT testers to access the test environment. And BA prepared the test script based on each requirements. Test script describe how to open and use the application or the products. So BA prepared the report based on the test data and user focused test cases. It may take two to four weeks or sometimes two to four months depending on the nature of the project. And it is important to validate and verify that the product is error-free and meeting the business moves. That's it. Well, I have a question. So what I remember from the last time is like in the development phase goes to the stakeholders and ask for the UAT. Isn't that is often the development phase? No. It's like after the development and after the testing happened, the product is ready. Then will be the UAT that will start. But business analyst when the testing is happening, business analyst working with the stakeholder to getting basically preparing for the UAT. So that there should not be any gap between, you know, when the testing is done and the UAT will start. Make sense? Yes. In a way that there is a no gap in it to ensure that there is no gap. So business analyst like time when the business analyst start working with the stakeholder is when QA is doing their testing. Okay. At the same time when the testing is getting towards it's like, you know, towards the ending, then business analyst start getting ready for a UAT. They are working with the stakeholder to know who is basically like, you know, will be the UAT tester. And then basically working with the QA is to get the test data, test login. And then as the QA testing is done, UAT will basically start. We will do the kickoff for UAT and then UAT will start. Okay. But I mean like, you know, he has to ask for the UATs, right? So that's the thing, isn't that in the development phase? So the BA has to ask the stakeholders. I think that's what you told us like in the like two days, like two meetings ago, that BA has to ask the stakeholders in the development phase. They're like in the ending of development phase, so they give them the UATs and then the testing is done. So that's what I'm saying. That's, you know, incorrect understanding that when the testing, because development is phases before testing, when development happened, then the testing can test that code, which the developers have done, right? So as the testing is progressing and moving towards the end at that time, we start asking the stakeholder and getting that information and getting ready because what we need to start the basically, you know, UAT testing. First, the QA testing is completed. And then second, you know, login and credential for the UAT tester are ready. Then third, user acceptance testing test cases are ready. Okay. And then fourth, list of those users who have to participate as a UAT tester is ready. When these four items will happen, the UAT can start, but it will start after the QA testing is done. Okay. So development phase is before QA testing. Okay, that makes sense. Okay. Then you want the QA testing. So there was one mistake that you did during probably like development. You mentioned that, you know, the VA will review the, you know, document with the solution team and then development team and the testing team. Okay. So in that solution team means system analyst and system architect, whoever basically designing that that is called the solution team. So VA will review the document at that point because we already reviewed the document with the solution team or system analyst or architect, and then they did the design. Now, VA will review with development and testing team. Okay. And then for development, not only the VA will review, VA will review business requirement document and system analyst will review the design. Okay. So development team and testing, the testing team, they both need to understand business requirement document with the respect perspective of what are the needs of the business, as well as a design document to understand what is the solution means what are the system requirements. Okay. The system analyst basically what the system analyst analyst does, they convert business requirement into system requirement means if the business requirement is a business want to view the, you know, like last month sales, sales. Okay. That's what the business requirement is that we business want to view that. So there would be a system requirement corresponding to business requirement will be with which will be basically solution of that business requirement. Okay. So that requirement will be system shell. Get the data from the databases, ABCD or, you know, sales database, and then show that database to the user interface, which is basically accessible to the user. So that will be corresponding like a system requirement. Okay, so who makes a system requirements like the system analyst or the business analyst system analyst. Because system. According to the BRD, right? Right. Unless makes it according to the BRD, right? Exactly, because those system requirements are catering the needs of business requirements. Okay, they are the solution of those business requirements. What is asked in the business requirement, the answer is in that system requirement. Okay, that how system will deliver that functionality, what their business is asking. Okay. So, and then developer, they need to develop that basically solution in like actual. So they need to understand both what is the business perspective and what is the solution direction. Okay. And they have to basically, and that system requirement document or solution document is, you can say guideline, it can change based on basically what the development team will learn. For example, the solution is like they said like in the sales, you know, get the data from the sales database and show it to the on the UI to the user. But when actually they started, they dig into the data they check like in the sales database, they don't have a data. Okay, so that means like you know, the database of the sale is in another data that is transactional data. Okay, so then they will basically update that requirement to you know, get the data from the for that from the transactional database and show that so the system requirement would be updated based on the basically what the development team will find, but business requirement will remain same. Okay. So that means the solution that design is our guidance, you know, solution guidance, it that solution doesn't have to be always according to, you know, that it there can be a little variation, but the business requirement kind of the they will remain same. They will not change until unless they will say that you know, for this requirement, they have no solution. Then probably like, okay, all right. Then requirement can change but that is an exception to the norm. Okay. So basically like, you know, so these little back detailed thing when you are talking about, you know, that be a role with the development during the development phase, mainly just talk about, you know, you work with the development team, given them overview of the business requirement answered their questions. Okay. And then work throughout the development process. Okay. With the development team. Okay. And at the same time. You are basically linking also you are telling the events basically as the same time when the development was happening started working with the QA team to help them prepare the test cases. Okay. So now use cases and user stories. These are not like, you know, the QA doesn't prepare that they prepare test cases. And test scripts. Okay. They prepare test cases and test scripts. Okay. And how they prepare those test cases. Test cases is just converting those requirement into basically testing criteria. For example, the requirement is that business want to view the sales last month, like a month wise sale data. Okay. So how you can test it. The development team developed the solution. So you will test it. If it is the user on the user side, there should be some button where they will like a lot sales data view sale data. Okay. So QA will click on that. Okay. And on the, so QA will basically, you know, both user requirement and system requirement, both will basically test. So QA test cases will be to type one for the business requirement for business requirement test cases would be simply like, you know, clicking on the button. It should open the screen screen or it should show the basically like a last month wise sales data. Okay. So that is the basically test case for a user or business requirement, but there would be a test case for system requirement too. So that test case will be like when the user clicked on the button, a query will run, which will communicate to the, you know, that particular database. So they will test that by running the query, is it running or not. Okay. And what, so they will test the system to that the query is running right, right query is running. And then that database will package that all the information that is asked in that query, and then transmit in a package to user interface. So that is another basically test criteria that they will test. Okay. So means that they, in simple word, if we will say, so testers are QAs, they convert requirements into test cases. Okay. And test cases are basically like, you know, a one complete test is called test case. Okay. And the script of the language of that test case is called test scripts. Okay. All right. Make sense. Yes, it makes sense. Question. Okay, one thing in the developing phase, the development team just create the coding. They do coding. Right. And the QAs will work on this coding. You will test that coding. Okay. Okay. Basically, we say that you will test that functionality that is delivered by the development team is a coding is some functionality. Right. So we don't say but actually what they're doing they're testing that coding that what they coded. Okay. So the QA will test that functionality. Okay, that development has developed. You will test that functionality. Right. So, like the QA should know coding but like the system analysts or the business around this does should not should not know the coding right. I mean, I will not give that blanket statement like should not they even if they know the coding that's not their fault but you know, it doesn't have to know the coding that the business analyst or project manager. Okay, that doesn't have to know the coding. Okay. But for the QA QA doesn't have to know the coding to okay. They if but they would be able to read the code. Okay. So there doesn't have to be expert in writing the coding but they should be able to read the code and that reading the code is also kind of nice to have that is not mandatory. Okay, because the QA will have their tool that they will use to do the testing. Okay. Okay, but but like but like in order. So I am I have learned coding as my thing is business analyst. Right. But if you said yeah, they have to read they have to read the like check code. Don't need to do it, but you can only read the coding like usually the people who do coding are usually SQL or are or Python right but you need to know it to understand or read it. Otherwise, like coding is very difficult to read it if you don't know how to code. You will not know what is going on. The thing is that it's nice to have if you if they know but if they don't know that is like okay too. Okay, because they are not gonna code or they are not gonna change the code. They are only gonna test the code and the testing will be done by using your tools. Okay, and if you will like so they just need to know the operation of that tool, they need to know what they are testing. They need to know the basically they would be able to write the test cases and test scripts. They need to they would be able to understand what they are testing and why they are testing. Okay, and that just those tools like you know handy with those tools that's pretty much it. They don't need to know the coding QA but if they know that's a kind of a plus point. Okay, so only developer in their need to know the coding also the system analysts are architect. They are kind of you know they have a development background mostly so they used to be developer but now they are kind of moved up to become system architect or system analyst because you will only analyze the system when you know the system. Okay, you know how the means like complex is the system and you know what different application in and out. Okay, so system analyst are kind of you know the stakeholder system analyst are especially system architect. Those are the stakeholders of the basically they are the technical system stakeholders. Okay, they know the system just like the business stakeholder know they are the business. The system architect or enterprise architect or system analyst they mostly know the system system analyst is usually like you know kind of junior guy who may may not understand the system but you know architect system architect or enterprise architect they are there must have the knowledge of that you know system means they know the architecture and whole structure of the system that how the applications are being built which is delivering that you know function. And to imagine that look and feel of the system imagine it's kind of stacks of application means the applications are kind of you know in just like in a stack. Okay, there might be you know 10s might be hundreds, and they are communicating to each other. So it's kind of like make a really complex web of you know, based on how big is the organization and how we guard the system. All right, so what I'm thinking is that the code so the business analyst drafts the PRD and from that requirement system analyst requires makes out the system or whatever this there should they're going to make according to the requirements that we are and then they make a design like how you know how it should be and what are the requirements what are the calls of it, and then the developers make it that is what you're saying right. Right. Then developers code it. Right. Okay. Make sense. That makes sense. Okay, yeah, so it's like simple only thing is kind of you know, it's simple understandable, but easily forgettable until unless you will basically make your stories and practice it. Okay. So, yeah, so that's, that's basically the role of a VA. Okay. So business analyst role at the time. Your turn to basically present. Present your understanding of the role and ask the question that you have all of business in here can I share my screen as well. Yeah, yeah. Yeah, I've written some North Sin in form of that and the form of the signing. Good, good. Go ahead. So in a submission. If face that will be like two to three weeks of placement manager will give you the be a job description. Then we in the back end, we have to update that resume. And understand what they are looking for scheduling meeting with the trainers and then they will be interview phase the placement when we will set up time for interview and schedule an interview. So, you know, with you, we will prepare your time. We will set up a time to prepare for the interview then. Right. So that was just the information basically like, you know, yeah, yeah, yeah. We'll start before. Yeah. Yeah. Before joining the placement manager will get to encounter either that's the data. So, so the be a role will start from there that. The follows step by step by step by step is that what is the project is about the land for the project for the requirement. And analysis go through the documents in the SharePoint look for the project charter and plan document after one to two weeks ready for to hold a session ready for information on ppt slide schedule requirement session meeting with using Microsoft calendar day to day. Day to day setup. And there is something written is that to. And the role of business analysts. I've written that one as well. So, in that one is the identification of the stakeholders and just schedule a meeting with them regarding the project. And schedule requirement gathering sessions to create business requirement that's a BRD document. And that's again upload that one into the SharePoint. And be actually explain the picture of a document to every stakeholder. The team that's including a system analyst developers and quality assurance team. And that actually give the review of the document. And that explain the current status and the future state and the requirement of the project. So, if the team if the team has any questions regarding the document or regarding anything so the behavioral answer. The main role of the base to answer that. Any queries arise by the by the team regarding regarding the documents. Then the then there is a system analysis phase in a in a system analysis phase. The be the be the system of the system analyst or you can call is the architect or solution and architect. Use that that business requirement document. Understand they will understand the business needs and propose the solution and the design to the system. And the system analyst will present different solutions and design options. So, and the requirements are documented always documented in a in a SSD document and. And the be a will walk through the solution team and and review the documents with the analysis team. Then there will be a development phase. And in a development phase you you have already told that in the development phase and in testing phase the both the teams. Developers and and the testing team like quality insurance team, they will require the business documents and. And to understand what is the project is all about what is going on. And so when all the requirements will be met by the developers, they will start working on that. And they will do coding and it stuff. And then they will prepare their coatings. And in the meantime, the be a role in that phase is to review the documents with them, the developers and helping them understand the requirements. And any requirements they have to and the be able answer the requirements and answer their any questions if they have some. And if the be a as in some cases if be is the question is beyond the capacity of the be a so it will go to the stakeholders or the sponsor of the project to communicate that. That thing. And the same is with the testing phase, the role of being the testing phase. He will work with the quality assurance team. And on these test cases to prepare. You the cases and in the in the last phase, the role of be a in a user acceptance test. And so it is it is kind of a testing of. Of testing off that software. That is been developed by the coding. And so the most. This is basically the most important step. Because they will be testing. And the software exactly according to the requirement. And, you know, written on the on the on the main document. And if something has to be changed, it has to be communicated to the be a the be able to work with the user test. The testing team. And, and resolve any issue or the question and communicate with the developers. Regarding the. Regarding any issue. And at this time, the be a. At this time, the be able importantly. Ask stakeholders that the product is ready to use and. Who will be testing as a business user and stakeholder provide the list of business users and will test on behalf on behalf of business. And at the same time, the be a work with the quality insurance and ask them to log in and password to. The tester to assess the test requirement. We also prepare the test script based on each requirement. And then lastly, the be a prepared the report based on the test data and the user focus cases. You really takes like. Three to five months. Depending on the project. And in the last. That it is important for be able to validate and verify. If a product. And has. Has any kind of loss. So, and, and, and second is that the product is exactly what. Required by the business. Document. So that's the main role. Of the be a, which I understand. Okay, we use your turn. Yes, I am here, but I have two questions. So what he did was, I think it was the previous assignment was not the recent assignment. I have mine written on a, on paper. I wrote it down everything down the paper. I don't have it on the world document. You just explain it. That'll be fine. Okay. So, so what does what a business analyst does in a system analysis phase is a business analysis would help understand the requirements from the BRD. The system architect show the system analyst and help them build their like SSD, the documents called SSD, right? According to the needs of the requirements given by the stakeholders and he'll check upon and like go through with the system analyst people that whether if they're making the system system. The SSD according the BRD or not. And he goes through answers in the questions which are in his authority to answer not every he cannot the business analyst can answer every question but what he can is from the BRD and what he has been told from the stakeholders. He'll help them. He helped clarify it to the system analyst so they so they can design it in a way that that is easier. Like for the developers to make and also is compatible and goes with the requirements of the business. Like also, I don't know they did not give examples but you asked us to give examples from the projects we have done so I'll take the Wells Fargo project which we did. That was I think the only project I was given talking like in the Wells Fargo we were supposed to make an app. Like we were supposed to have an app for people who could invest from the app as well. So in this case, a business analyst would have a BRD document right that requirements that are to be taken place like in the app and so he will explain the system analyst the system analyst people. Okay, we want this this this thing in order to be in the app and we want it to function in a this in this this this way. Right, so he'll tell them the documents and so it's like the system analyst people job to make the SSD and the requirements and he'll just go through it and make it and make sure all of the things written in the SSD or the requirements in the SSD align with the BRD document. And then the business analyst job in the developers phase is it's not it's not a lot different from what is it in the system analysis as his work is to just to go through like what they are doing and make sure make sure like whatever whatever the coding is and the outcome of that is like the code they are writing the outcome of that is aligned with the requirements of the business and like the app or whatever they're making so I so that's what I think I asked before or the UAT but I you said it's not in that phase so I think in the developers phase the most important task business analyst has to do is like work out with work with them and see and like make sure like whatever they're coding whatever they're making aligns with the requirements of the SSD and the BRD because if SSD is aligned with the BRD then I think developers will be able to make a perfect app or whatever they're making or like the coding they're doing and in that phase the BS job is to just go through and like read all the codes and like run it through if and like find out he just has to see the outcomes if the outcome is fine because in in coding if even if you're not coding you just have to like control and enter and you'll see whatever the outcome of that if that outcome aligns with the requirements I think that's all his job and developers phase and then that in the testing phase I think he goes like the stakeholders and ask them for the UATs and and in the testing phase I think his job is to make sure like that everything is like working fine and whatever it's it's in the SSD or the BRD the app is whatever the app is supposed to do you know he is going to check out all the outcomes of the app like whether if it's working fine and also the main thing is if the app is working according to the requirements of the business and what the business of the stakeholders want and I think that is all I actually think that I didn't have the UAT version because I didn't because UAT is like just the user interface testing I guess I wasn't sure about what BS job was in UAT but I only had these three. Thank you. Thank you. I think he is here. She's with me. And I'm also part of the plan as a BA role. And now it's my turn to explain the BS role. Okay. As per my understanding, BA joins the project and there's already a project manager who is taking care of our whole the project and be a giant is that project. He will have the access to like a SharePoint site where the already prepared documents are available with the project manager. He may discuss with the project manager that where he can get the documents of the project which were previously like prepared by the stakeholders. And I think he might be more concerning about the project charter via where he can get the project milestones and the deliverables as well as the project timelines. So, as soon as he got the timelines, he will square his work, like the project is of total six months duration. He has to like follow the schedule. So he has to prepare the things according to time. So we will make some slides about his first meeting with the stakeholders. He will call a meeting. He has to face meeting or meeting through our video link. So, in first meeting, we will invite the key stakeholders. That might be from development team or other departments. So, he will ask the questions from key stakeholders like what they exactly require about the product and so on and so on. He will like frequently conduct those sessions and write it down and take notes and present in the next meeting with the stakeholders to reconform the things like all these things are exactly what they need. So, after doing that, we will prepare the whole BRT document. We will get it finalized and get it signed from the key stakeholders or the persons who are nominated to get signed the document, who are authorized to sign the document. Signed by the key stakeholders, we will head over the document to the system analyst and the developers who will start their work on development phase. So, during the development phase, our developers may contact to back BA for understanding of any topic or requirement. Then, the next phase is like after the development, they will be part of QA. They will also like get in touch with BA for understanding of any phase or requirement. Then the like BS work will be to prepare some test cases. Those test cases will be prepared in cooperation with the key stakeholders. They will also help out to BA and BA will like help out to key stakeholders to prepare those test cases. After that, the user acceptability testing will be performed and the project will be go to at an end. Thank you. Alright, so any question, anybody? So, I would want you guys to basically I'm going to share the recording of this session. Okay, just hear your response. Okay, and then basically others response and see how you crafted your response. So, Sidra's response was close to basically just couple of mistakes. Otherwise, that was the kind of, you know, normal response or, you know, closer to okay response. And then the response was better too. Okay, so rest, everybody did great. But here these out, so I'm putting, you know, these responses as a reference. Okay, and I'm going to explain the role of a BA to. Okay, just quite a quick recap. And this is what I want you when you're explaining. So the explain use this terminology and use basically the words that are like I'm using are been teaching you guys to use. Okay. So, as a BA, when I start on a new project, the first thing I do is to understand what project is all about to do that. What I do, I go check the SharePoint site, and because I'm just new I don't know where the SharePoint site is. So, then to get the information of the SharePoint site, I ask the project manager, or secondly, the person who is helping me on board. I get the information from them for the SharePoint site, I go on the SharePoint site, and as a BA, I need to know two things. First, what is my timeline, which I will know from the project plan, which will give you from the timeline project timeline that when I have to deliver that, you know, requirements, because as a BA my main job is to get gathered and document requirements. And secondly, I will start looking into the project charter to understand the high level requirement that what is the business ask. Okay. As I am doing that at the parallel, the third task I will start doing is getting to know my stakeholders and identifying the stakeholders doing. I call it like the stakeholder analysis. So to do the stakeholder analysis, which is simply basically getting to know them. So I start with the list from the project, you know, charter, the stakeholder list. And I also check there is any list that project manager has made. Okay, I take those list of stakeholders and all of them, all of them invite. And then hold a meeting with them. The purpose of that meeting is basically agenda is sent out that to identify the primary and secondary stakeholder for this particular project. Okay. So I send out an email in that email will okay this is the project title, and this is the project number. This is a project SharePoint and I am the business analyst for this project. So, I am holding this meeting to identify the right stakeholder. So please join is the link of, you know, zoom or like whatever the tool we are using at the organization. And then I schedule that meeting hold that meeting and in that meeting we basically ask that first I go over give them a little bit like okay all right this is what the project about little bit information, which I gather, which I got from their project charter. Just like introduction of the project charter, you know problem statement or opportunity statement current state future state, you know, with the same headings as they are in the project chart. Okay, the same information. I start always start my meeting with that, which you know I learned from experience that most of the stakeholder they might be coming from five different projects. Okay, and if I don't bring them to what project they are in to census, they probably start talking nonsense or maybe start start talking something that is not related to this project but some other project to avoid that I always start that meeting with that little presentation that you know, so that they will know where they are at and then in that meeting basically for the stakeholder went over and verify who is the primary stakeholder who is the secondary stakeholder after I've done that then I schedule those primary and secondary stakeholder requirement sessions. Okay, and the reason I do the primary and secondary stakeholder identification because if I'm working with the 10 people. And out of those 10 people they are like the primary stakeholder are just, you know, three people. Okay, so then I only have to check the schedule of those three people that they must attend the meeting. Okay, but if I will not know then I will probably like in last because you know I don't know that who is must for that, you know, requirement sessions. Anyway, then I schedule the requirement session ask question and document requirement, and I prepare that document. That is called the business requirement document, and as the business requirement document is ready, then I put that document at the SharePoint side and then let the all the team members know that is ready, and also I schedule a review session with the system solution team system analyst and architects at strong. I give them overview of that requirement, and if they need me to schedule a meeting for them, where they will present their solution, I do schedule that meeting for them so I basically partner with them help them to create their system specification document. Okay, and how I help by explaining my requirements, and helping them understand the requirement. And as that they're like requirement document, yes, a system design document or specification document is ready, then I partner with them, and we do overview of business requirement which I does, and the system design document which really system analyst give the overview to both development and testing team. Okay, and I answer all the questions related to the requirements. Okay. And then, when the development is happening I usually attend their meeting, and if they have any question, I just like sit back and, you know, just basically participate. If they have any question about those requirements, then I give them the answer. So if some of if I don't know the answer, then I'll go back to relevant stakeholder that who that requirement to belong to and check with that like hey this is the question from the development team or the testing team. I don't know the answer what what you think. Okay. And that basically, as a BA, my role is a liaison between business and it. I am the voice of the business with the ID. So I participate almost in all all meetings. So, anyway, when the development is complete, then I work with the testing team, they execute the testing, and I help them. If they have any question about the requirement. And as the testing is done, then I act as a UAT lead. I check with the stakeholder that and get the list of UAT tester from them from the Q a lead I get a log in and the password for the environment for the testing environment, and then also if there is any test data. Okay, and I do prepare the user acceptance test cases. Okay, so usually those cases I get from the user acceptance user test inventory from the Q a, but as I created the requirement I sometimes, you know, do it myself. And then as the test cases are ready, and the test logins already I have the information of the state UAT tester I schedule meeting with them and start UAT testing activity. Okay, and they tested and if they had report any defects or any they see anything that is not working they let me know, and I test myself and if it is still like some bug, then I report back to our development team and they fix it and then I ask them to retest. Okay, so by that back and forth, you know, we got get through that user acceptance testing, and sometime it's like two to four week time for the UAT really. And as the user user acceptance testing is complete. I jar down the test results and send it to release team who then basically like you know release that you know solution or software to the user. And this is my end to end role as a BA. Okay, so now you guys have a reference. So just listen to that. And what you do, take a pen and paper, and start crafting your response based on so far you've got the understanding of role of a BA. And then, while you create your response, any questions that you face or any conflict that some I told something different in the before but no, no you tell this in any such kind of kind of right the question. Okay, and then tomorrow one by one you can basically contact me. Okay, we can set up in 2030 minutes, a call or you know zoom meeting, and we will discuss your basically questions. Okay, but tomorrow everybody will have their whole end to end response in writing in their own words. Okay. So basically like, you know, as a BA. Okay, and when I say like in their own words mean the concept and terminology will remain same, but the words will be your so I mean everybody we have a specific style of, you know, speaking, or, you know, crafting the way we speak, we get a specific style. Okay, so write this concept without, you know, changing the terminology terminology is just like, you know, business requirements, and all those like the terminology don't use common words for them for them, just use that. Okay, and, you know, don't use like the BRD where you have to speak the requirement instead of BRD. Okay, BRD is a document and that document contain the requirements and the basically development team or testing team doesn't ask you about document. They ask you about their questions are about the requirements that are in document in their document. Okay, so when you will say that you know, they ask me about the BRD, that doesn't make sense because they will ask you about the requirements in the in your document. Okay, not the BRD not about the document because they already have document why they're going to ask you about the document. Okay, but content of their document, which are what basically requirements make sense. Yes. Okay, all right, so I'm going to finish the meeting send going to send you that link. So please like review your response and see because everything is making sense to you, but usually, you know, things make sense to us but when we try to reproduce or replicate or explain, then it's we kind of you know, if not like well practiced, then we are kind of all around and you will see in this basically, you know, your own response you will review that where you are kind of you know, going like in the wrong direction. All right. So that was it for today. Thank you very much everybody for joining. I am going to send you the link. And then we will speak tomorrow. So tomorrow in the morning between nine to 11 try to connect with me I would have a time to talk to you guys. Like, can we have a time at the later time because if it's like very less time to work on our stuff. Okay. You know, all right, yeah, that's that's that's okay. So I will have time between nine to 11 year nine to 12, you know, then after that I will have time between like in a three to five. Okay. Okay, three to five is fine. All right, so anytime that you are basically and your basically target is to create your own response that as a be a just like you know, I have given you a response kind of my response then like you and you got the whole basically stories how the be a work and all different aspects. So create a response of your and we will review that response and wherever we will be like kind of you know, wherever the gap will, we will fix the gap in tomorrow's meeting. So don't you like a worry about a take like kind of a panic. Just relax. Step back and write the response. Okay. All right. Okay. Okay, then good night everybody.