I'm going to go through chapters one and two. So that's basically the introduction and the business analysis key concepts. And I wanted to initially I started not to talk about these, because they're less emphasized on the exam. But I think it's so very important because so many people tend to skip it because they feel that it's not important. But it's actually really key to understanding how to navigate through the guide and how to, you know, understand what you're reading and why you're reading it. So, um, this is the introduction chapter.

So, basically, the purpose of bat bot is basically to define the profession of business analysis and provide a common set of accepted practices. babylock is not a book that gives you a methodology or anything like That block is very flexible. And it's basically just used as a framework or a guide. Alright, so this image here is pretty important for understanding where the business analyst falls within a project because most people think a business analyst is just kind of in a box. So this box here basically represents a project. So this is the start of a project.

And this is the end of a project. But business analysis actually starts before and after. So you know, when we have our before you've got some pre project work, you're trying to forgot the rationale right? So generally, you have your business cases that have to go through the steering committee before the project even gets approved. So those are all things that happen in the strategy analysis piece before We, you know, start with a project delivery work and the requirements analysis and design definition. And then your solution evaluation happens while you're testing.

But it also happens post project too, because at this point, you are monitoring and testing your critical success measures to see how well the the solution is actually performing. So just keep this in mind to know that, you know, Business Analysis goes beyond the scope of a project in most cases. And so again, this little sentence basically just says that it shows how the knowledge areas support the delivery of business analysis before, during and after the lifecycle of a project. So what is business analysis? And basically, business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions to deliver value to stakeholders. I think that's it in a nutshell.

Once we talk about the business analysis core concept model, you'll see a little more. And usually, initiatives can be strategic, tactical, and operational. Now, Babak doesn't talk a lot about these three types of initiatives. But I know they they kind of come up on the exam, for those of you who might be taking the C bet, or the CCDA. And strategic initiatives are basically initiatives that come from higher level executives and go all the way down. So this is referred to as your top down initiative.

Your tactical is something that comes from middle management, right? So the middle managers need something to help them make an initial decision or additional resources. And then you might also have operational and operational is a type of initiative that starts either at the customer or a line worker or an end user, and they basically escalate an issue that gets transferred into a person Project. All right, so who is a business analysts? According to Bab Bock, a business analyst is basically any person who performs business analysis tasks described in the data guide, no matter their job title or organizational roll up. Sorry about that.

I'm sorry, I just got an email. All right. So the activities that business analysts perform typically include these items here, which are understanding the enterprise problems and analyzing needs and solutions, devising strategies driving change, and facilitating stakeholder collaboration. Oops. Okay, and some common business analysis titles that aren't necessarily business analyst, but you might see are, you know, a business architect or a business systems analyst, maybe even a data analyst, you know, that's why back recently released the certified business data analysis or certification because that is a subset of business analysis. And then you've got your enterprise analysts who is a little more of a senior role and they typically do higher level business analysis work so they focus a little more on strategy, and the market and things like that.

Um, management consultants do a lot of business analysis of work, even though it's a fairly different realm. They've got your process analysis, product managers, product owners, we all know about the heated debate of Agile where Some people feel that the BA is not needed because of the product owner. And some organizations have the business analysts play dual roles as the product owner. So that's a very good conversation to have for another time. Then also requirements engineer and systems analysts or other common roles of people that perform business analysis work. Alright, and so your key concepts, basically here.

This section is about providing a basic understanding of the central ideas for understanding the business analysis guide. So this chapter includes the business and office core concept model, which we'll talk about key terms requirements, classification, schema, stakeholders, and requirements and design. Now we're going to move on to the knowledge which areas so this is the core of the bat guide. And knowledge areas are pretty much a special area of work and, or a specific business analysis expertise that encompasses several different tasks. So your six knowledge areas include the business and office planning and monitoring elicitation and collaboration requirements Lifecycle Management, strategy analysis, and solution evaluation. Oops, and I'm sorry requirements analysis and design definition.

We don't need to go over these now. I will recommend that for you guys. The overall understanding the overall purpose of each knowledge area is very useful, specifically for exam purposes. And then also you're going to want to know of course the tasks that are within each one and the The deliverables, the outputs are pretty important as well, because they help give you they help you visualize, you know what the purpose or the angle is of this specific knowledge area. Alright, so really quick, I'll go over these, the business analysis planning and monitoring describes the tasks that ba perform in order to organize and coordinate the efforts. So that's initially what the business analysis planning and monitoring are the Pete, the BA PM, knowledge area consists of elicitation and collaboration describes the tasks that business analysts perform to prepare for and conduct elicitation and confirm the results.

So this is where we're actually getting the information, communicating with the stakeholders and basically transfer basically confirming that we heard the right things when we talked to the stakeholders Then we've got requirements Lifecycle Management. And these are the tasks we perform in order to manage and maintain requirements and design information from inception to retirement. So this is actually pretty key, I should have had this highlighted. For those of you who will take the exam, you need to know that requirements Lifecycle Management maintains requirements from the very start of a requirement or need all the way to the retirement. So that includes, you know, a solution that is functioning after a project because you might, you know, you might have a project that ends but the requirements still need to be maintained. And now we've got strategy analysis.

So this is an area that a lot of business analysts tend to struggle with because in most cases, It happens prior to the project starting. So it happens prior to where many project business analysts enter a project. So it's something that's a little more difficult for many VA to put into practical use. But you know, it's fairly simple. It's basically describing the work we do in order to collaborate with stakeholders to identify the need of a strategic or tactical important. So, a little further down, we'll talk about what a need is.

And then we need to align the the higher level and the low level strategies together. Again, these are things that may even happen before a project gets approved to be initiated. So you know, drafting your business case and things like that often happen in your strategy analysis area. And then we've got requirements analysis. And design definition. So this is considered the meat or the heart of business analysis.

This is where we structure and organize the requirements that are scoped discovered during elicitation into something that's actually representative of a requirement. So we're taking all of our notes and diagrams and information in interviews. We're synthesizing it and organizing it, and then turning it into something that we're going to have to communicate back to the stakeholders in order to represent the needs for the particular project. And then we've got solution evaluation, which describes the task that is performed in order to assess the performance and value delivery of a solution. So when you think solution evaluation, you know, we might be testing things with prototypes. We might be testing or I'm sorry, we won't be testing it.

With prototypes, we might be testing actual partial functioning solutions. Or we might be monitoring a live solution to see how successful it is. So solution evaluation can happen before, during and after the implementation of a solution. All right, so relationships between the knowledge areas, so I get a lot of questions about what does this diagram mean? And it doesn't really have a whole lot of meaning. I mean, it does, but it doesn't.

Essentially what this is telling us is that many of the knowledge areas are fluid. Right, you know, there's no specific order, you don't always start with business analysis, planning and monitoring, and then, you know, move into elicitation and collaboration. Many of these can be, can start off first and then move into another. I will say that these three internal knowledge areas are things that are more about adding value to the business and are more specific to the organization. Whereas these outer tasks are more like activities that have to get done for a very specific project. These things may are really a part of a project, but they can really go beyond that.

So if you notice, these are the same images, the same knowledge areas that are in that first diagram that I showed you how strategic might be, our strategy analysis might be before a project or premise and design requirements analysis and design is kind of in the middle. And then solution evaluation is, you know, towards the end or even after a project or solution is implemented. Now, one thing to keep in mind too is that depending on the type of project you have, you may have you may start with strategy analysis if it's something new, or you're taking advantage of an opportunity. But if you're making process improvement or you're fixing a an existing system, you may start with solution evaluation, right that might be a part of seeing where you are today and evaluating the system to see where the issue is or where the defect is through some type of root cause analysis.

So now let's talk about tasks. tasks are very efficient. pourtant for those of you who might be taking the any of the exams, or are interested in taking the exams, the tasks are basically discrete pieces of work that may be performed formally or informally as a part of business analysis. So the parts that you're going to have to know are these pieces here, each task in back is broken down by a purpose, a description, an input, the elements, the guidelines and tools, the techniques, the stakeholders, and the outputs. And the the components that I have highlighted here are the pieces that I feel are most important for you to understand for the sake of these exam, specifically the purpose and the elements. The purpose is very important because it basically tells you the outcome or the goal of that particular task.

The description is pretty important too, but I would say the purpose is more important. And then your elements is very important because a lot of the questions that are on the exam are at least for the ccpa, and see that are pulled out of the elements, levels of the guy. So be sure that you have you understanding those elements. techniques is important, but not as important because basically you want to know how that technique can be used within the scope of that specific task. There's way too many to remember. So I recommend having a general understanding of each of the 50 techniques and then being able to, you know, align it with Okay, well, if this technique does this, then I would probably use it like this for this particular task.

All right, and so To understand what these components mean, so, like I had mentioned earlier, when you're reading the purpose, you need to understand that the purpose is the reason that the BA might perform this task. So that's basically telling you the value that's created when you do this particular task. And then the description basically goes into greater detail about that specific task. But this is really giving you the bottom line here. Your inputs represent information that you need to begin a task. So we're going to talk about inputs and we're also going to talk about guidelines and tools.

Inputs are different are more needed, I guess, I would say, because the inputs are actually needed before the task can begin in most cases. So this is basically saying that if this information Is not there then that we can't start this task. Again, the elements are the concepts that you need to understand how to perform the task. And remember that the CCDA and C bap are competency based exams. So they really want to understand, they really want to assess whether or not you're able to understand how to perform a specific task. Now, the CBA is a little more general knowledge.

So you might not have to worry about the elements as much as the CCB or the C bap ticker would. Now the guidelines and tools are like I said, you just want to have a general understanding of them. You don't need to try to memorize them or anything like that. These are just giving you instructions or descriptions on why or how to undertake a task. So it's basically helping you do it more efficiently. But you don't necessarily need these, like you need the inputs in order to start a task.

So like I said, it's good to know what the guidelines and tools are, but I wouldn't spend too much time trying to memorize them for the C bap or the CCDA. The ECA is a little more knowledge base, so they might ask you a couple of questions about some of the guidelines and tools for a specific task. Okay, so for techniques, we all know that this is basically the list of techniques but it's basically how that technique can be used to perform whatever task that we're in. You're probably already know what a stakeholder is. Basically, that's anybody that's involved in the project or impacted by it. And so, then each task has outputs.

Now outputs are important you won't necessarily have Questions on these, but it's going to help you be able to organize how to, I guess facilitate the knowledge areas and the tasks within it. Basically, the outputs are the results that are produced by a task. So sometimes it might be a deliverable, or it might just be a specific state of something. So for those of you who are students, I'm going to be providing you guys with a list of deliverables. For each task to help you guys understand basically how to, you know where these tasks are in a practical setting to help you, you know, align them more with what you would see in reality. Alright, so those are the knowledge areas and then you're going to also have some questions on your underlying competencies.

So these are just basically The set of knowledge skills, behaviors and characteristics, or personal qualities that help individuals perform business analysis more successfully, or more effectively. So these are a lot like to say a lot of these are soft skills, but actually some of these are hard skills to that are listed. But most of these are behavioral related skills. And so for each underlying competency, you'll want to understand the underlying competencies purpose, the definition again, understand it, but you really want to know the purpose, and then the effectiveness measures. So, for test takers, you'll probably be given a scenario and it'll ask you which underlying competency would help in this particular situation. So, you will want to underline Understand the effectiveness measures because that'll help you be able to during the process of elimination to see which underlying competency you should be focusing on.

Or underlying company could help you solve that particular scenario that you're faced with in the on the exam. All right, and so your purpose is basically the purpose of the underlying company. So we're no longer talking about the task, we're talking about the underlying competencies. So the purpose of your underlying competencies, those basically describe why it's beneficial for a business analyst to have this particular competency. And the definition of the competency basically describes the skills and expertise involved in applying that particular competency. Your effectiveness measures basically describes how to determine whether it works person is actually demonstrating that so how do I know that I'm a good communicator?

Or how do I know that I'm a good listener or facilitator or something like that? Alright. So that was the underlying competencies chapter. And then the techniques are basically just all of the 50 techniques that Babak feels are most relevant to business analysis, at least at the time that Barack was originally written, or the latest version was written. But the structure of the techniques again, you're really want to have a solid understanding of the purpose of the techniques. In fact, those of you who have taken the course you'll know that one of the gamification tools that give you is a purpose matching activity that helps you Not necessarily memorize, but memorize, you know the purpose of each technique to just get a general awareness of it.

Again, your descriptions are helpful. And then the elements are a little more important because you might need to understand or identify which technique is being discussed in a specific element or in a specific scenario on the exam. So, understanding the elements involved in that technique would help you more like with the word association. And then your use consideration is also very important because that, again is going to help you during the process of elimination when you're faced with exam questions, because you'll basically be given a scenario and you'll need to know which technique is the best to resolve that problem. So the use of consideration is going to be very helpful for you to eliminate, you know, when the, you know, immolated eliminate the techniques that are not the best choice for that particular scenario. And again, your purposes for the techniques section.

So, the purpose of the techniques describes what the technique is, and the circumstances in which it's most likely to be applicable. The description describes the technique and gives you a little more detail about it. And then your elements are the key concepts that are needed to understand how to use that technique. So, again, your underlying competencies describe the conditions under which the technique may be more or less effective. So again, this is something that's going to be helpful for you to understand or to pinpoint, you know, when you have a potential answer on the exam, All right. So the last chapter and back is the perspectives.

I'm not going to spend any time here, just because the perspectives are not covered on the exam. I will say for those of you who are on here who are interested in just learning more about business analysis and not necessarily taking the exam, I would still go through the perspectives because we you know, we all know that business analysis is a very broad domain and there are a lot of different flavors of business analysis underneath that larger umbrella. So, if you are a person that works in you know, one of these domains, more so than the others, I would definitely go through the perspectives. However, again, if you are not, if you are taking the IB B certification exam, perspectives aren't really covered. So don't waste your time studying these, but I will say that the Agile perspective does have a little bit of relevance because the CCB Well, actually all three, the ecpa CCDA, and the C bap, talk a lot about adaptive versus predictive business analysis approaches.

And adaptive, agile falls under the adaptive approach. So having an understanding of the Agile perspective might help you better answer some of those questions on the exam that are related to predictive versus adaptive. All right, so now let's go ahead and move on to the business analysis key concepts. So this year basically provides the foundation of what business analysis is, and is the foundation for all of the other content within babba. So some key things to know are the business analysis core concept model. Now, this isn't a big deal on the exam for CCA and see bap takers.

But if you are someone taking the ecpa, or the Agile AC, the core concept model is something you're really going to want to understand. Then we're going to talk about some key terms. Sorry, and then the stakeholder roles. So basically, the stakeholder roles are basically the roles and characteristics of the individuals that are participating in a particular business analysis activity. For all intents and purposes, I would say the extension that you need to know T dS is really just what the role is and what their key responsibility is. And I'll talk a little bit more about those as we move for and their requirements and designs.

This is more for I think for CCP, A and C bat, they assume that you know the difference between these, but for ecpa, they, they do test you to make sure that you know the difference between requirements and designs and we will talk about the distinction between those two in a little bit. Okay, so the business analysis core concept model basically talks about what business analysis is and what it means to perform those tasks. So, it's basically composed of six terms that have common meaning in all business to all business analysts. So those six terms include change me Solution stakeholder value and context. And then Babcock is telling us that the business analysis core concept model can be used to describe the profession and domain of business analysis. It can be used to communicate about business analysis with a common terminology.

It can be used to evaluate the relationships of concepts in this analysis, and it can help us perform better business analysis. And then it can also evaluate the impact of these concepts in relationships and relationships at any point. So, I would say just have a high level understanding of each of these concepts. You know, Bob Bach basically goes into how the core concept model applies to each knowledge area. I don't really think you need to know that specifically, I think you really just want to have a high level understanding Have the business analysis core concept model as you move through your study. So change is essentially the act of transforming a response to a need.

And it helps us improve the performance of the enterprise overall. Need is something that's very important. I actually talked a lot about need in you know, social media about defining what it is. But a need is basically where it all starts. All business analysis starts with a need and all project starts within the so the needs are a problem or an opportunity to be addressed. I like to say it's a problem to resolve or an opportunity to take advantage of, but bad luck kind of consolidates them to say, both to be addressed.

And essentially deeds can cause changes by motivating stakeholders to act. So that basically just means that when stakeholders record There's a need, they need. They know that at this point, we need to do something in order to change that need, or in order to change this issue, or address this issue. And so solution is a specific way of satisfying one or more needs within a specific con text. And so a solution satisfies a need. For those of you who follow me on social media, I just did a Wednesday post about a wordsmith Wednesday post about satisfying that's a big concept in babylock.

You know everything there's various ways to satisfy something. So, solutions satisfy needs. So, when we talk about design versus requirement, designs represent solutions and requirements represents needs, so solutions satisfies knees therefore designs satisfy requirements. All right, our other three are stakeholders. And these are just the group of individuals that have a relationship to the change, need or solution. And they're often grouped based on their relationship to the needs changes or solutions.

Value is another big issue. Another big term. And Babak value is basically why we do what we are doing in this analysis. And so value here is described as the word or usefulness of something that a stakeholder to a stakeholder within a context. So we can resolve a problem. But if the stakeholder doesn't find value in it, then we've just wasted our time.

And so value can be seen as potential or realized. So potential value is what we do when we're assessing the value when we're gauging Okay, this is the potential impact of this project. Realize value is when the project has been implement it. And we've been monitoring it and measuring it after a month or so or a couple of weeks. And we're seeing the actual performance of the implemented solution to see what the actual realized value is. Also value can be tangible or intangible.

So tangible are those that are directly measured. So our heart costs if something gives us more clients or more revenue, more profit, those are things that are tangible value, whereas intangible value is measured indirectly. So this might include something like you know, morale or reputation, things that are more relative to where we were before we implemented the particular solution. And then the value can also be absolute or it can be relative to something Else. So one solution option may be more valuable than another one from the perspective of a particular stakeholder. And so that's that.

And then we've got context. I think, if I were to say the one thing you need to know in order to pass all of the back exams is to know that everything is based on context. So if you ever get a question that is suggesting that more information is needed, or multiple approaches can be taken based on the context. That's the right answer. Again, Babcock is not a methodology and Babak is not prescriptive. Babak is very flexible.

And it leans a lot towards context. So just keep that in mind as you're studying and as you take your exams. Okay, and so, back to the core concept model context, these are the circumstances that influence or are influenced by and provide an understanding of a change. So why is this change happening? Who, you know, who were the people involved that initiated this change, things like that, what are we doing today that makes this change needed right. So, context is everything relevant to a change that is within the environment?

All right. And so, when we are performing a task or a technique, we consider how each core concept is addressed by asking these questions. actually think these this is like a good set of eyes. Questions for those of you who might ever try to build like a solicitation questions list, this would be a good guide for you to steer your questions, right. So you always want to know, what kinds of changes are we doing? What are the needs, we're trying to satisfy?

You know, why are we doing this? What are the solutions we're creating or changing? So, are we creating a new application? Or are we changing a process, right? And also, who are the stakeholders, you want to always make sure you have the right stakeholders involved? And also what stickers are impacted, right?

So someone might be directly impacted, who might be a part of the consulting team, or not a consulting team, you know, subject matter expert team or the business, but you also have to consider your external stakeholders or customers who might be indirectly impacted by a specific change. And then again, you want to have an understanding of what the stakeholders consider valuable, you know, us as ba days. And, you know, developers, you know, we all have our own perception of value. You know, we're looking at technical excellence and things like that. But, you know, you want to have a solid understanding of what is valuable to a stakeholder so that you can know that the solution that you're marching towards or building is going to be appreciated and actually used. And then again, you always want to know about the context that the solution might be in.

And this is your business analysis core concept model. This is again, it's not a big A topic on the CCB or a CBA, or CC, I'm sorry, the C bap or CC VA, but it is more into play for the CBA and the Agile analysis certification. So, basically is just basically saying that all of these interconnect and you know tie into one another, you can see that you know, needs are a solution satisfy a need, right and needs are driven by value, right. So, you can see how all of these are basically different triangles that connect to each other in one way or another. And so, you, Vic, they're kind of explained a little more in these in the tables here. There's another good example that I include in my course that talks about how these concepts actually relate to one another.

But like I said, it's basically something that's good to know, in general, for those of you who are practicing business analysis in your daily work. Okay, so now we're going to talk about some key terms. So this is what bap describes as business analysis. So, Babbo describes business analysis as the practice of enabling change in an enterprise by defining needs, and recommending solutions that deliver value to the stakeholders or to stakeholders. So if you notice this definition here of business analysis, includes all of the terms, all of the six terms that are in the the core concept model. So that's just something to think about.

And so the next term here is business analysis information. So this is a term that I have that actually ever had to use in a practical setting but bad luck decided to change it to business analysis information, we typically refer to this as requirements or requirements package or whatever. But business analysis information is basically any information at any level of any kind. That's used as an input or output for business analysis work. So just understand that when you see business analysis information is basically synonymous with either your elicitation results, your requirements, design, solution, options, solution, scope, or change, so anything that's related to the requirements, or helping build or communicate those requirements. Alright, so now we're talking about design.

Again, design is a usable representation of a solution. Right? Again, design is how we're going to solve a requirement or how we're going to solve a problem. And then we've got enterprise. So an enterprise is one or more organizations, and the solutions they use to pursue a shared set of common goals. So this is important.

I'll read organization and then I'll talk a little bit about them both at the same time. So an organization is an autonomous group of people under the management of a single individual or board that works towards common goals and objectives. And on the exams, you might be presented with a question that requires you to understand the difference between the two because they are very similar. The only thing you need to know about the difference between these two is that an organization is One group of people or one organization, where as an enterprise is a group of organizations. So, in a practical setting, if you think about a parent company and then the subsidiaries, right, so you know, those of us who are in the US you have like Ford, and then they have a bunch of subsidiaries like for credit for, you know, whatever else and then all those different subsidiaries underneath.

So just keep those in mind. Plan is another term you're going to want to understand. And plans basically describe a set of events, dependencies, expected sequences, scheduling, outcomes and materials for a specific initiative as well as the stickers involved. Now one thing I'll say about this is planning plan is a lot more detailed than that. approach. So, for babic, v3, they decided to change what used to be things that were plans, like you used to have a business analysis plan.

A lot of that stuff transitioned to a business analysis approach. So just know that an approach is more like the overarching direction of what you're going to do. And then the plan is a lot more detailed. And I did notice when I took the exam that they still had a lot of verbiage on plan. So it on the exam instead of stakeholder engagement approach, you might see stakeholder engagement plan. So the exam takers might use plan and approach interchangeably, so you know that they're using them interchangeably, but also know the difference between the two is that a plan is a little more detailed and descriptive than an overall approach.

Oh writing. And so our requirement is basically a usable representation of a need. So, this actually is consolidated a lot from previous definitions, which was used to be, you know, conditions that need to be met and things like that. We'll talk a little bit more about the different types of requirements a little further down. And then another key term we have is risk. So, risk is basically the effect of uncertainty on the value of a change a solution or the enterprise.

B A's generally want to identify, assess and prioritize risks so that we can deal with them importantly, ultimately, we want to mitigate the consequences or we want to remove the source of the risk or we try to avoid the risk altogether by deciding not to You know, partake in a particular initiative or activity? Right. So those are the key terms. All right, we've got our requirements classification schema. The wording revision on that is I don't know where I got that from. It sounds so technical.

Whenever you see the word schema, at least to me, but there's three core, or actually four core types of requirements that bedrock discusses and that's the business requirements, stakeholder requirements, solution requirements, and transition requirements. So we'll talk about those. So your business requirements are basically the statements of goals and objectives and outcomes. So in a practical setting, most of us have what we call the Brd. Now, the Brd has a little has usually a little more than what this is telling us is in there. So a lot of the times your Brd includes your business requirements in addition to some additional other elements.

So business requirements are really just your problem, your goal and your objectives and the outcomes. We typically will see this and business case or we might see this in the project charter. It doesn't always have to be represented and a business requirements document. Specifically speaking for if we're doing traditional project document documentation, and just for so that you guys know, I'm sure you've realized but Bab Bach focuses on more traditional methodology or frameworks, though it does discuss, you know, some adaptive approaches, but overall All the approach that discussed is more traditional. And so, again, you've got your goals, objectives and outcomes for your business requirements. And then those are elaborated to describe your stakeholder requirements, which actually talks about the needs, the stakeholders must meet in order to achieve the business requirements, right.

So in order to achieve these goals, objectives and outcomes, what do the stakeholders need to do? And a stakeholder requirements are basically your waterfall version of user stories in my opinion, and then you're going to break down those stakeholder requirements to talk more about what the actual system needs to do. So your solution requirements, these are your traditional system shell requirements, right? So your solution requirements, describe the capabilities qualities the solution must meet that meets the stakeholder requirements, right? So how do we, what does the system need to do in order to allow the Secretary to do something? So, you will need to know that the solution requirements are broken down into two sub categories including functional and non functional requirements.

These are what business analysts are usually more familiar with. So this is what the system needs to do the system capabilities and what the system must have in terms of behavior. So the system shall display this and blah, blah, blah, blah. The non functional requirements are the quality of service requirements are actually a description of the conditions under which the solution must remain effective. So how well the functional requirements perform. So another Non functional requirement might be something that talks about SLA.

So I need the functional requirement to respond within 30 seconds or three seconds or something of that nature or I need 24 hour access to something right. So those are your non functional requirements. Again, these are also referred to your as your quality requirements for quality of service. And then we've got your transition requirements. So these are the capabilities that the solution must have, and the conditions the solution must meet in order to facilitate transition from the current state to the future state. So these are basically the things that have to happen in order for us to make this change, right.

Are we going to have to sunset something, are we gonna start a new build a new application or we're gonna have to train people? Are we going to have to do some data conversion, right? So these requirements don't usually get as much air Time or discussion because they're temporary. Basically, after you implement the solution, they're no longer needed. So some examples might include data conversion training, or business continuity. Okay, um, these aren't talked about a lot on CCDA and CFA exams, I think they come more into play for the CBA.

You do want to have a good understanding of how they're different from one another. I can remember when I took the exam, I know I for sure had a question on transition requirements, and also quality requirements. But everybody's exam is different. So just be prepared for anything. All right, so now we are at our stakeholder section. So stakeholders are basically any stakeholder that's impacted.

By a change and any stakeholder can be a source of requirements, assumptions or constraints. So the list of stakeholders that Babcock discusses includes the business analysts, that's us, the customer domain subject matter expert, the end user, the implementation subject matter expert, the operator operational support, project manager, regular regulator, sponsor, supplier, and tester. We don't really need to go the business analysts is because most of us fill that role. But inherently business analysts are a part of any business analysis activity because we're typically the ones doing the work. The customer is usually your end user or anybody that uses the products or services that we're producing with a particular initiative. A lot of times they'll have a contract or some type of more obligation or right to something typically in waterfall We have some type of contract with our clients or our customers.

And then you have your domain subject matter expert Not to be confused with the implementation subject matter expert. So the domain subject matter expert is basically your Smee or the person from the business on that has individual or in depth knowledge of a topic that's relevant to the business need or the solution scope. So end users are usually subject matter experts. Or you might have managers or process owners, legal staff or consultants that have specialized knowledge that we need in order to help us make the best decisions during our analysis efforts. And then the end user is kind of like a subset of the subject matter expert, but the end user is specifically a person who's going to be directly interacting with the solution the product or the service once it's implemented. All right.

And so implementation subject matter expert. The implementation subject matter expert again, not to be confused with the domain subject matter expert is someone that's more technical in nature. So when you see implementation think, two, three things, think technical, think, cost of implementation and think delivery schedule. That's how your exam questions are going to be steered to let you know that the correct answer will probably be the implementation subject matter expert. So this is just a stakeholder who specializes in knowledge regarding the implementation of one or more solution components. And this person might be a change manager, configuration managers solution architect, a developer is a common one.

A database administrator, information architect, trainer or organizational change consultant. Um, again, when you see things like delivery schedule, cost of implementation or anything that's more technical in nature, that's going to be your implementation subject matter expert. Your operational support, those people are basically responsible for the day to day management of a particular system or product. So these are your product analysts, maybe somebody that works at the help desk, even your release manager. Then your project manager is responsible for managing the work required to deliver this. So, project managers manage the actual people that are within the project's business analysts manage the requirements on but you're Project Manager is responsible for managing the scope, budget, schedule, resources, quality, and risk.

Risk is the biggest indicator, when you're looking at maybe questions on the exam to let you know that you, it's the project managers responsibility, they're ultimately responsible for the risk of the project. And then a regulator is a person who's responsible for defining and enforcing certain standards. So when you think regulator, just think something like a person that deals with governance or audits or compliance, right, maybe, you know, outside regulators that work for the company, or maybe if you have a business, this is controls officer. Anything that's dealing with regulatory bodies or auditors is usually related or tracing back to your regulator. And then your sponsor, this is the person that gives us the money. So this is the person responsible for initiating the effort to define the business need, develop a solution that meets that need.

It sounds like they do a lot more in this in this description here than they actually do as far as within the project, but most sponsors are pretty hands off. They just have maybe the final say so. So they authorize the work. And they control the budget and the scope for the initiative, controlling budget, anything that talks about budget, or funding for the project, or making a final decision. That's going to lead back to your sponsor. Ultimately, the sponsor and waterfall or traditional projects.

Sponsors are the ultimate decision makers. business analysts and project managers are not decision makers. projects. So keep that in mind too. As you're dealing with questions, we are responsible for collecting information and presenting it to the sponsor in order to make the best decision and, you know, making a recommendation. But again, your sponsor is the ultimate decision maker.

And then you've got your suppliers. So these are typically people that are outside of the organization. They provide products and services that we might not the organization might not specialize in, but they might be needed for this particular initiative. And they often have contractual or moral rights as well. So we typically will have some type of contract with our providers or vendors and consultants in order to work with them, usually involving, you know, statements of works or you know, guidelines on scheduling and cost estimates and things like that. And then the final roll back discusses is the tester role.

And so testers are responsible for basically determining how to verify that a solution meets the requirements, the requirements that are defined by the BA. So anything that's dealing with the conducting verification or checking for defects or failures is typically handled by the tester. We, in a practical setting usually hear the terms QA team or quality assurance analyst, maybe even a ua t person or representative, those will all be considered a tester. Okay, and this is our last little section here, so I'll just get through this. Um, all right, so requirements and design. So like I had mentioned earlier You really want to understand the difference between requirements and designs.

In a lot of, you know, in the real world, the development or IT teams, tell us that bs don't handle designs and that, you know, we shouldn't be solutioning. And that, you know, we do it with requirements and they handle the design. But that's actually contrary to what Barack has to say that Apple believes that business analysts are responsible for the definition of design at some level. So we typically do the high level design pieces, you know, we'll talk about some examples later on, and then it goes more into the actually building of it, which is what the more technical teams handle. So requirements of books again on the need, while designs are focused on the solution. Usually a requirement leads to a design, which can in turn, you know, drive some more discovery that leads back To more requirements, so, bad luck causes complex and recursive.

So recursive basically just means going backwards. So again, you start with your requirement, you have a design that satisfies it. But as you date delve more into it, you might uncover some additional requirements. So requirements may be used to define a design. And that design may then be used to elicit additional requirements. One thing if you're not currently doing this, and this is something that I always make sure that if your design team is not including you, in design discussions, try to get them to do so.

But business analysts should review the final designs to ensure that they align with requirements. Now, you may not understand exactly what those designs are telling you if you're less technical, but you need To get with the developer or whoever created that model, to make sure that they are aligned with the requirements that you have outlined. And so this is just a nice cool little table that babba provides that lets you know the difference between requirements and designs. For those of you who might not be as familiar with how to distinguish between the two. So again, your requirements are your needs. So an example would be, you know, the requirement is to view six months sales data across multiple organizational units in a single view.

And so a design is basically a sketch of the dashboard. So, you know, many business analysts might be responsible for doing wireframes or process models, right? I know I do a lot of process models. Those items are actually those activities are actually considered parts of the design, even screen mock ups, right. Um, so just know that these types of things activities are considered designs as well. More so at a higher level.

And then you might have something like this is more like a business requirement that says develop business strategy goals and objectives for a new business. A design might be a business capability model, right? That's actually a technique that by Bach discusses. I personally would not have recognized that as a design, but that I've done so it opened my eyes a little more to understand what that box perception of a design is, right. So it's represented representing a solution in some sort. And again, prototypes with text display in English and French.

So any type of prototyping that's all considered a part of designing. All right, and so one thing that I did want to point out is that the importance of the role in business analysis or the business analyst lies in continuously asking the question, why, right? Why are we doing this? Why do we need to change? Why do we think that's valuable? You know, why is this guy needed?

What would happen if we didn't do it? You know, things like that. Why why why comes you know, the five why technique? Okay, and then this is just a little diagram that talks about the requirements and design cycle. So business requirements, um, is basically why do I want it right? So we have our business problem, our goals, our objectives, and the outcomes right, and you might have a design being a business capability model.

And then we might use that to outline our keys to figure out who our stakeholders are, and then come up with some stakeholder requirements. And I met, you know, the business capability model is actually a great way at the beginning of a project to determine stakeholders as well. I just wanted to mention that, um, for those of you who've had problems identifying stakeholders in the past, and then your stakeholder requirements are basically saying, what are the needs of this particular stakeholder? Right? So we'll design that out with maybe some screenshots. I'm sorry, not screenshots, our sticker requirements or user stories, and then those get further broken down or elaborated into your solution requirements, your functional and non functional requirements, which is what do I want?

What do I want the system to do? And what do I want? It should actually be and how and how do I want the system to do it, but that's more about design design is all about how, um, so then designs might be your, this actually might be a process map to or something of that nature. And then this design might be a wireframe, something more detailed or your prototyping. And so not necessarily leading into your transition requirements, but these are kind of like they're on their own little separate islands. So I would have drawn this kind of out here.

Again, your transition requirements are the conditions that need to happen in order to get from here to here, right. So what needs all of this needs to occur here, so how can we support all of these three things right, do we need data migration, data conversion? Are we sunsetting something Do we have to train people Do we need more resources, more people? Are there going to be changes in the organization? What are all of those things that need to happen? And you want to assess your outcomes.

And basically, this cycle continues until all of the requirements are met. So you continuously assess the outcomes and then you know, that might change this business requirement here. All right. So that is all of the content that I have for you guys today.