The techniques chapter is, is it's basically providing us a high level overview of all of the knowledge, all of the techniques that a business analysts you would use, but not necessarily things that a business analyst would use, but it's the most commonly, or are the most widespread techniques that are used within the practice of business analysis. And so a lot of these techniques that actually get mentioned can be used in conjunction with one another individually or, you know, whatever best suits the context of the situation. Okay. And so our first technique is going to be acceptance criteria, and evaluation criteria. So this is one of those techniques. Babak does that a lot where it'll look to similar techniques together, or more.

So this is actually to say Separate techniques, but they're very similar in nature. So your acceptance criteria is really used to define requirements, outcomes and conditions that really need to be met in order to be considered acceptable by the key stakeholders. But the evaluation criteria, on the other hand, are usually the measures that are used to assess a set of requirements in order to choose between multiple solutions. And so the acceptance criteria basically defines the measures of value attributes to be used when assessing and comparing solutions and alternative designs. And it describes the minimum set of requirements used in order for a particular solution to be worth implementing. Now, your evaluation criteria is used to define a set of measures that allow for ranking so this is really good for ranking multiple apps.

And so, your elements include your value attributes, which basically are you know, the components that are agreed upon in order to determine you know pieces of value. This is kind of like a good figure figure 10.11. For acceptance criteria, it shows this is the actual flow of the acceptance criteria where you have your acceptance criteria value attributes, which might include cost performance, usability functionality. And then you define those requirements through various elicitation methods or measures rather. And these are the requirements that must be met. And then you come up with some type of tests for those.

And so, you conduct usually user acceptance testing, and this must be presented in a way that the tester can verify that the test cases is either a pass or fail. And so you're whenever you have multiple solutions, right? So acceptance criteria is for one solution. multiple solutions is when you're going to want to use your evaluation criteria. Your value attributes might be cost, performance, usability and functionality. And then here you're going to define the measures where you're going to these is, this is the criteria that you're going to use to assess all of those potential solutions.

And then you're going to measure each of those solutions and then rank them according to how well they perform. So, you know, when you having design options and solution options, you're going to rank them in order to see which one you're actually going to execute. And then your next element is some type of assessment, right? So you got to be able to assess your criteria which really needs to be testable if it's acceptance criteria, so it's usually presented in a statement that can be verified as true or false. And like I mentioned earlier, it's usually verified through user acceptance testing Are you at now, evaluation criteria needs measures as a form of assessment. And so this provides a way to determine if the features provide the value necessary to satisfy the needs, right, gives us something to rank against.

So you've got several strengths and limitations of these one big strength of acceptance criteria is that that's the major form in Agile frameworks. Actually, agile isn't a methodology. I'm actually shocked that they had that in there. But agile frameworks typically require some form of testable acceptance criteria. And another good strength is that it provides the ability to assess the requirements On some type of agreed upon criteria. evaluation criteria helps to define priorities right?

Because we're ranking it, we're ranking those priorities against one another. And then limitations or weaknesses in acceptance and evaluation criteria is that acceptance criteria may come off as you know, contractual obligations. And it can be difficult to change in some scenarios, and evaluation criteria for different needs. among different stakeholders can be challenging because you have to, you know, determine whose priority is more important than someone else's. So our next technique is backlog management. In backlog management is another technique that's pretty popular in Agile frameworks.

And it's basically used to record track and prioritize remaining work items and it usually occurs when The volume of work items to be completed exceeds the actual capacity to complete them. So when you have more work that can actually be done in a specific period of time, you're likely going to be needing to do some type of a backlog. And so things your elements include items in the backlog which might come in the form of a use case, most often user stories, functional requirements, non functional requirements, designs, change request defects, and so on. And then we know that the backlog items need to be prioritized that way we know which items are going to be placed into the next iteration or the next sprint. And usually you will start with a more high level. Priority, right so you'll designate certain user stories or stories as high medium or low priority.

And then once it comes time to be closer towards implementing them, you'll give them a more granular estimation to determine their priority and then that way you can actually rank them against one another rather than just clustering them into these groups. And then your prioritized backlog items need to be estimated right. So kind of like I just talked about earlier, usually give a high level estimate and then because there's very little detail, but as work progresses and more information is known, you are able to decompose it in order to provide a more detailed estimate of the size and the complexity. Then of course, you have to manage changes to the backlog. So as new information is learned or requirements change or requirements or identify you have to be able to To manage your backlog in order to make sure that the most important items are remaining at the top, so any new information or new backlog items are ranked against the backlog items that are currently in on the backlog list.

So one of the strengths of backlog is that it's an effective approach to respond to change, right, because it's kind of a built in process to incorporate change. And only items near the top of the backlog are elaborated in detail. So that means you could get to, you know, focus on the most important items. And you know, things that aren't as important those are at, you know, you those get less attention to distract away from the most important items. And one of the limitations of backlog management is that when a backlog gets too large, it becomes it can become difficult to manage and cumbersome. Alright, so now we're on to balanced scorecards.

So balanced scorecards, the purpose of balanced scorecards is to manage the performance in any business model, organizational structure, or business process. So a balanced scorecard generally consists of learning and growth, business processes, customer and financial dimensions, these are referred to as dimensions. And so this is an example in figure 10 point 3.1 of a balanced scorecard. As you can see each dimension has, you know, objectives and measures, targets and initiatives within it. And so your elements are also your dimensions and so we talked about learning and growth which is the measures that are in regards to training learning employees, products and service innovation and the corporate culture. The business process dimension really includes metrics that indicate how well the Enterprise's operating and how well they're meeting the customer needs.

Another customer dimension. These are the metrics that focus on customer satisfaction and the actual delivery of value. Then we have our financial dimension which identifies what is financially necessary to realize strategy, right. So what's the cost of things what's, you know, how much profitability revenue growth and economic value are involved in these items. And then, your last element that's not a dimension is your measures or indicators So your indicators are usually going to come in the form as lagging indicators or leading indicators. And lagging indicators provide the results of actions that have already been taken.

Right. So they're showing things that we've done and what the result of that were as leading indicators provide information about future performance, we're expecting the performance of something to be some of the strengths is that a balanced scorecard can provide a holistic and balanced planning or I'm sorry, it can facilitate holistic and balanced planning and thinking and it's also a good way to align operational tactical and operational teams so that everybody's on the same page. One of the limitations is that if there is a lack of a clear strategy, then aligning the Dimensions can be very difficult. And also the the technique itself can be misinterpreted as a replacement for strategic planning. Whereas it's really a supplement to strategic planning and a visual to help communicate the plan to you know the larger organization all right benchmarking and market analysis. So, this is usually conducted in order to improve organizational operations increase customer satisfaction and increased value to stakeholders.

So, typically, benchmarking studies are conducted to compare an organizational practice against the best in class practices. So, many of you may have heard of the term best in class which really just means, like a leader in the industry or a leader in The market, the person who is identified as being the best. So that's we're going to want to compare our operations against. Now market analysis on the other hand, so again, this technique is one of those ones that's broken up into two, that's two techniques disguised as one. So your second technique is a market analysis. And this actually involves researching customers in order to determine products and services that they need or want and the factors that influence their decisions to purchase and any competitors that exists in a particular market.

And so the elements for this is really just the benchmarking and the market analysis, which we just kind of went over. So the strength to benchmarking and market analysis is that any Oregon can use benchmarking to identify best practices that competitors might be using in order to meet or exceed its competition. The market analysis can actually expose weaknesses within a certain company or industry. And your limitations to benchmarking is that it cannot produce innovative solutions, right? Because you're really just comparing it against something that somebody's already done. There's no you know, room for you to create a competitive advantage there or something innovative.

The market analysis, limitation, well, there's a couple but the one that I'm pointing out is just that it can be time consuming and expensive. And that you know, the results may not be immediately available. All right, so our next Next technique is brainstorming. So the purpose of brainstorming is to really foster creative thinking about a problem, it's a really good way to produce a large amount of new ideas. That can basically be used to derive themes for further analysis. But it's a good way to generate a lot of ideas quickly in a short amount of time.

Your elements of of brainstorming are pictured here in figure 10 point 5.1 which includes your preparation, your sessions and your wrap up. Now for preparation, you're really just defining the area of interest, determining a time limit, identifying your participants, and then establishing your evaluation criteria that you're going to use later on. On the actual session itself is going to be facilitated by a facilitator. But the team or the participants will share ideas, the facilitators work or maybe the recorder will record the ideas. And the you're going to build on, the participants are going to build on each other's ideas. And then overall, we're going to try to elicit as many ideas as possible.

And so for wrap up, we're going to discuss and evaluate the ideas based on the evaluation criteria. We're going to create a short list and write them and then we're going to distribute a final list to the participants for further analysis. And that's what I just discussed here. And so some of your strengths of brainstorming is that it provides the ability to elicit many ideas in a short period of time. It also creates an environment of non judgement right and enables creative thinking because you're not busy concerned about how others are perceiving your ideas. One limitation is that it is dependent on individual creativity and the willingness to participate from all of the participants.

Okay, so our next technique is business capability analysis. This probably isn't one that's going to show up on the exam, but still good to know about. So the business capability analysis provides a framework for scoping and planning by generating a shared understanding of outcomes, identifying alignment with the strategy and providing a scope for a prioritization filter. So it basically describes what the enterprise our part of the enterprise can and can't do. And so your elements include your capabilities, which are, you know, the abilities of the enterprise to either perform something or transform something that's going to you know, achieve some type of goal or value or objective. And then your next element is actually using the capabilities because the capabilities impact value through increasing or protecting value or either reducing costs or preventing costs, providing some type of service and you know, positioning the company for the future.

So, the using the capabilities is actually almost like the reason that we are using them. Then the performance expectations are basically just you know, what measures or expectations we have for each capability. And then the risk model is basically Whenever a particular capability is lacking in or busy or poorly performing in a certain area that can become a risk. Strategic Planning. This is basically you know, whenever we're doing capabilities for the current state and the future state, you're usually trying to determine what the enterprise needs to do in order to accomplish an overall strategy. So, this is basically saying that the business capability analysis is used for strategic planning.

And then the actual map itself is just the visual or the graphical view of how the elements involved in an analysis are illustrated. So some figures to take a look at our video. 10 point 6.1 figures 10 point 6.2 and figure 10 point 6.3, which I'll actually discuss, because I think this one's the most it's the easiest to explain. So in this example here, we can see that we've got different areas, which is the business value, the customer value, and then the performance gap here. And then this is the risk, right? So these are, you know, parts of the elements.

And then within the organizational analysis, these are the different capabilities, how well we do certain things, how well we do a capability analysis how well we do root cause analysis, process analysis, de card analysis, roadmap construction. Okay. So this here is basically telling us how much business value does this capability have, right? So capability analysis has a high impact on business value. But the root cause analysis has a low impact on business value. Okay?

So same thing for customer value, the capability analysis has a low impact to customer value, but the root cause analysis has a high impact to customer value. Now, here is what gets to be important now we're talking about the gap, the gap in between where we want to be and where we are. So if there's a high performance gap, that means we're performing pretty poorly and our capability analysis, okay, for root cause analysis, we're kind of doing you know, performing midway. Now, the amount of risk involved because this is a high risk with a high value for the business and low risk for the customer. It's an overall medium risk. That we have a high performance gap.

Okay. And so that means, you know, we need to make a moderate amount of effort in order to remedy this high performance gap. Now for the root cause analysis, it's a medium performance gap. And since it's a medium performance gap, but it's a high low business value but a high customer value, we're going to consider this to be a low overall risk because it's only a medium performance gap. Okay, so the use of considerations for business capability analysis is that it is a strength is that it helps to align business initiatives across multiple aspects of the organization. But a limitation is that when it's created unilaterally or integrated, Accu it fails to deliver the goals of alignment and a shared understanding.

So it really requires a broad and cross functional collaboration whenever you're defining this model, which can take a little bit of work. Okay, business cases. So the purpose of business cases is to provide a justification for a course of action based on benefits to be realized by the proposed solution as compared to the cost effort, and other considerations to acquire or live with that solution. So, this is a little weird, but basically the cost to acquire that solution and so a business case really The most important thing that you want to note down about the business cases that it documents the rationale for taking a course of action or undertaking a change. And so you can use a business case to define a need, determine the desired outcomes, assess constraints, assumptions and risks, and also to recommend a solution. So your elements include your needs assessment, which is really the driver of the business case right.

Why are we doing this? The desired outcomes describes the state that we should be in as a result of fulfilling a particular need. The next element is assessing the alternatives which identifies the various alternative alternate alternative solutions that But basically satisfy the need, but we still have to figure out which one has the most value. And so within those alternatives, you want to look at them in terms of the scope, which defines the, whatever the alternative is that's being proposed. You want to look at the feasibility right, which is the organizational technical ability to complete or execute that alternative. Then you also want to look at any assumptions risk as constraints, where our assumptions are agreed to effects that may have influence on the initiatives.

The constraints are really just the limitations, and then the risk are the potential problems with each of those alternatives. You also want to look at each alternative from a financial analysis and value assessment. Which includes an estimation of cost to implement and operate each alternative, then you want to have a recommended solution. So this describes the most desirable way to solve a problem or leverage an opportunity. And this is all very high level, right because this is at the business case, which is way at the beginning, based only on the information that you have available for you today, it's likely going to change as the project progresses and new information is obtained. So one of the strengths of the business case is that it provides a detailed financial analysis of costs and benefits.

But one of the limitations is that it's frequently not updated at once funding for the initiative is secure. So once they get sign off from the executive teams are the powers that be you Now it basically just becomes, you know, a project document where it should really be a living document that continually gets updated and is used to make decisions. Business Model Canvas. So you might have seen one of these before. It's basically Well, the purpose of a business model canvas is usually to describe how an enterprise creates delivers and captures value for and from its customers, right, so to and from its customers. And so it's comprised of nine building blocks that describe how an organization intends to deliver to deliver value.

So I'll describe each of those when we talk about the elements. It can also serve as a blueprint for implementing a strategy so in figure 10.8 point One you can see all of the nine building blocks which include key partnerships, key activities, key resources, cost, structure, value proposition. customer relationships, channels, customer segments and revenue stream can also be used as a diagnostic tool, in addition to a planning tool. So our key partners are those that might be involved in helping us deliver value, usually with some type of sharing proprietary information with them. If they're good at producing something that we're not key activities are those that are critical for the creation of the creation, delivery and maintenance of value, as well as other activities that support the operation of the enterprise. Generally, these activities are going to be classified as value added, non value added or bitten or a business non value added.

These are terms you're going to want to remember value added is anything that the customer is willing to pay for non value added is things that the customer is not willing to pay for oftentimes non buy activities into being waste. And then business non value added is are basically elements or processes that need to be included in the in the offering or in the product in order to meet regulatory or some other type of need or cost, but the customer is not willing to pay for it. So it's probably something that happens in the background that the customer doesn't notice, but is really has a decent impact on the overall product itself. You your key resources are just the internal and external assets needed. Execute the model. So this usually comes in the form of a physical things like, you know, applications or machine financial things like funding, intellectual things like patents, copyrights, and branding, and then your human resources, right?

These are the people. Value Proposition This is important for any business. This is basically what the customer is willing to pay or exchange for their needs being met, or what they're willing to pay for your service. Then we've got customer relationships, right. So, you know, there's various forms of customer relationships, you know, there's consumers, there's internal customers, external customers, those types of things. Then there are channels, right, which are the different ways that the enterprise can interact with customers and also deliver value to customers.

Customer segments is basically what we use to group different customers with common needs into a way that helps us more effectively or more efficiently communicate with them or address their needs. The cost structure, we want to know about the cost structure because any type of activity, entity or product has a cost associated with that. So we need to understand this in order to understand the different types of costs. And you know, basically how they can impact our initiative and the overall organization. revenue streams, basically how we're getting our money. This is how the organization is getting revenue, right how it's getting paid in exchange for the realization of value.

Some ways we might do this might be through lending, renting or leasing sales transactions. licensing or subscription fees. So some strengths for the business model canvas include the fact that it's a widely used and effective framework that can be used to understand and optimize business models. It's also simple to use and easy to understand. Now limitations is that it doesn't account for alternative measures of value such as social and environmental impacts, right? So it doesn't look at look outside of the organization's like a doesn't look at external factors.

Okay, so our next technique is business rules analysis. So business rules analysis is used to identify Express, validate, refine and organize the rules that shape the day to day business behavior, and guide operational business decision making. A business work Rule itself is something that really should be specific, testable and serve as a criteria for guiding behavior, shaping judgment, or making decisions. So your elements include your definition or rules. And your definition or rules are used to shape concepts or produce some type of knowledge or information. It usually indicates something is either true or not true.

To distinguish definitional rules from the havior rules, just think of it as something that's derived or inferred or calculated based on information that's available to the business. So a calculation is a prime example of a definitional rule Business I'm sorry, behavior rules, on the other hand, are those that are considered to be people rules. These are also considered guidelines that, you know, serve to shape or govern the day to day business activities. So behavior rule for which there is no enforcement is called a guideline. Right? So, they're saying is that there's no real penalty for not following it.

Behavior rules can sometimes just be considered guidelines. So some strengths of the business rules analysis is that a centralized repository can create the ability to reuse business rules across organization and business rules themselves can provide a structure to govern business behaviors. A limitation is that you know if the vocabulary is not sufficiently rich, or if the vocabulary is inconsistent if it's not business friendly if the rules are poorly defined, then basically you know your business rules analysis can be inaccurate or contradictory to one another. Collaborative games. Collaborative games encourage participants in an elicitation activity to collaborate with one another. Which helps to build a joint understanding of a problem or a solution.

Usually, the games are used to help participants share their knowledge and experience for a given topic and is used to identify hidden assumptions and explore that knowledge in a way ways that may not occur during, you know, normal or daily interactions. So each game has a game purpose. So now we're talking about the elements. The first element is a game purpose, which is, you know, the defined purpose of each of those games. Then, each game also has a process, which includes an open process, the exploration steps, and then the closing steps, then those are going to be followed by some type of outcome. So at the end of the game, the facilitator and the participants are going to work through the results in order to determine any solutions or actions.

And so, what you would want to understand, I guess, not necessarily memorize but just understand is the three examples Have collaborative games, which include the product box, which is where participants construct a box as if it were being sold in a retail store. And the objective here is to identify the features of that product and to help drive interest in the marketplace. an affinity mat. Here, participants are going to write down features on sticky notes, put them on a wall and then move them closer to other features in a way that allows it to create some type of pattern so that the items or the features that are similar to one another are usually move closer together, right? So you're really just grouping them and this is used to identify similar features or themes. The fishbowl game is what Participants are divided into two groups.

One group of participants speak out about a particular topic, while the other group listens carefully and documents their observations. And this is really used to identify assumptions or perceptions, or perspectives, I'm sorry. So some of the uses considerations for collaborative games. One of the strengths is that it challenges participants who are not nor who may typically normally be quiet or reserved, to take more of an active role and the team activity. One of the limitations is that the playful nature of collaborative games may be received as or perceived as you know, silly. It might make certain stakeholders who are a little more reserved might make them a little uncomfortable.

All right concept modeling. The purpose of concept modeling is used to organize business vocabulary that's needed in order to communicate knowledge. So a concept model usually starts with a glossary and then focuses on the core nouns, concepts of a domain. So that doesn't give a visual example of a core cost of a concept model, other than the business analysis core concept model, which let me see if I can look at that real quick. Right, so here are your nouns that are spoken about and the Concept modeling technique. And then these are your relationships.

So verb relationships. So, you know, stakeholders might initiate change, right? Or needs lead to value, right. So all of these have some type of relationship to one another. And so, for our concept model that's what these verb concepts are relating to right? The basic structural connections between the noun concepts, right and our six core concept models are each of those are the basic noun concept.

They can also be other connections. Such as categories classifications, a positive or a whole part connections. And maybe they could have various roles. So uses consideration for a concept model is that it provides a business friendly way to communicate with stakeholders about precise meaning and subtle distinctions. It's also helpful to ensure that a large number of business rules and complex decision tables are free of ambiguity and fit together cohesively. One of the limitations is that usually knowledge and rule base focus on concept model makes it foreign to stakeholders.

So, I just highlighted this because I kind of feel like This and this kind of contradict each other, but I think it means that the knowledge and rule focus might be foreign to outside stakeholders who are not you know involved in that group of business participants or stakeholders who have these knowledge of the rules. So it I think it could have been a such as that set to stakeholders who are, you know, more or less involved in the daily activities of the business rose analogy or something like that. Alright, so our next technique is the data dictionary. This is basically used to standardize the definition of data and enable a common interpretation of the data elements. So I'm not going to get a whole lot into detail about this. But this is a technique you're going to want to understand a little bit about.

And so the elements in a data dictionary include your primitive data elements, your composite elements. And so your primitive elements are just the single data elements in themselves. And some examples might be a name, which is kind of like your, your unique name, the alias are alternative names, values and meanings is basically you know, a description of the element. Or it might be examples of what it could be. And then your description is really the definition of you know, the particular data limit. And so composite is a combination of primitive data elements.

So if your data elements are first name, middle name, and last name, the full customer name is a composite element that's a combination of first name, middle name and family name, right. So this is an example of your composite element. That's what we just discussed all of these. And so some of the things that builds a composite element is sequence repetitions, and other optional elements. Some of the strengths to a data dictionary is that it provides stakeholders with a shared understanding and the format of relevant data information. Also a single repository of corporate metadata promotes the use in a consistent manner.

And so for those of you who might not know, metadata is really the data about data or data that describes particular data elements in further detail and discusses how it should be used. And a limitation in data dictionary is that it requires regular maintenance in order to remain relevant. Another technique you're going to want to know about So, take note of this one as well is your data flow diagrams. And so data flow diagrams really show where data comes from, which activities process data and rather not the input results are stored or utilized by some other activity or external entity. In a nutshell, data flow diagrams illustrate the movement and transformation of data between externals and processes. And so there's different layers of data models or different levels of abstraction right, or different levels of detail.

And so the highest level is a context diagram which might present the entire system. And then, you know, in its entirety. So then you break those down into different levels. But figure 10 point 13 dash one is an example of a context diagram and the gain sarsa notation. So there's two or three notations that babic mentions in regards to the data flow diagram. So just have an understanding of both of them.

And then the next level down is a level one, which is where you're illustrating processes related to the system with respect to input and output data that's transformed into, you know, some other type of data. And then figure 10 point 13. Dat two is another level one diagram but this one's in the your dot notation. And so you can see these squares here. These are your external agents. These circles here are your data processes.

These two little lines, that's a data store. Right and you can see your inputs, your x and O's are serving as inputs to your processes. Once one thing you're going to want to understand is that things that Only have arrows going away from it those are called sources and elements that only have things coming, arrows pointing into it, but nothing coming out which this one doesn't have an example of that. But whenever you do see all the arrows touching the process those are called sinks. So again your elements include your externals which is might be entity sources or sinks. So, an external is you know represents a person, organization, automated system or any device that's capable of producing data or receiving data.

Your externals are usually in the form of sources Or destinations right? So the destinations again are syncs. A data store is a collection of data where the data may be read repeatedly and where it can be stored right so remember in the image in the your dot notation, the data store is just those two little lines. bike so you don't have a data data store in this one. Then you've got your processes, which is anything that transforms data into an output right. So your processes were the circles in the data in the diagram, your data flow, those are your arrows, right.

So the data flows the movement of data between external a process a data store and is represented by a data flow. So these little arrows here are data flows. Again, figure 10 point 13.3 is a, a data flow diagram in the gain sarsen notation. Oh, this one's giving us an example of a data flow and the gains session notation so this one in this notation it's kind of like a square little you are sideways you and then the process aren't circles but they're like the curved square shapes. Okay, and these are more examples of the notation shapes. So in the year dot notation, the external agents are squares.

Your data flows are just the lines with the arrows. Your data processes are circles. Your data stores are two lines, strengths of data flow diagrams. So a strengths is that it's an excellent way to define the scope of a system. And all the systems interfaces and user interfaces that are attached to it. It's also most used, usually most users find it relatively easy to understand.

And it's also good for helping to explain the logic behind data flow within a particular system. A limitation is that with the different methods and notation and symbols that can create, you know, some documentation challenges, and also it doesn't necessarily illustrate sequence, right. It's not like a sequence diagram. It just really just shows things go going in and out. Oh great data mining. Data mining is used to improve decisions makings by finding useful patterns and insights from data.

There's usually three main types of data mining which might be descriptive diagnostic and predictive. Descriptive is usually things that identifies patterns diagnostics, show why patterns exist, and predictive, such as neural networks shows how likely something is to be true or false. Sir elements include requirement elicitation. So you really just elicit requirements for those the same way you would for any other situation. Then you prepare your data, which is usually from by merging records of multiple tables. And then you have to analyze the data, right?

So you can use a different variety of statistical measures in order to, and visualization tools in order to turn that data into some type of insight. Then there's different modeling techniques include neural networks, predictive, linear and logistic regression. Then you have to deploy whatever type of data mining you use, right? So a lot of the times, you know, you have data mining tools, but you have to actually deploy it to make it useful, right. So you might data you might deploy something in SQL or something of that nature. Okay, so some of the strengths of data mining is that it can reveal hidden patterns and create useful insights during analysis.

It can also be used to eliminate or reduce human bias. A limitation to data mining is that the results may be hard to deploy if the decision making process is not is poorly understood. And we're going to jump right into data modeling, data modeling or data mining data modeling, data analysis, it gets a little, a lot of data data dictionary. Alright, so now we're on data modeling. So a data model basically describes entities and classes or data objects that are relevant to a domain. It also describes the attributes are used to describe those objects and their relationships among them.

There's different variations and three main variations include your conceptual data model, which is the most high level. It basically is used in a way that is independent of a solution or technology or solution agnostic. And it is used to present data in a way that the business can understand and perceive it. So this is the most high level. And then the logical data model is where we take an abstraction of the concept or the conceptual model and incorporate the rules of normalization to this. And this is where we're going to start looking at the integrity of data and relationships and then the physical data model is usually used by the subject the implementation subject matter expert or the develop developer or data analyst.

Because this is going to describe how to physically organize the data in whatever platform they're using or whatever application they're using. So, I just, I just have an understanding of the three different types of data modeling, the very various levels and so on, logical and physical er DS will be used to implement a relational database, whereas a class diagram will be used to support object oriented software development. Okay, and so your elements include an entity or class. And so entities present themselves as something physical, right like a warehouse, something organizational, like a sales area or a team, or something abstract, like a product or product line, even an event such as an appointment. So an instance or class can really just be anything that needs to be that impacts the requirements. And entities are referred to as entities in a entity relationship diagram.

But if you're in a class diagram, you're going to refer to these entities as classes. Now, entities and classes, both have attributes. And again, your attributes are things that describes a particular piece of information associated with an entity or class. So this usually includes Name, the values the meanings, and then the description of that entity or class relationship or associations. So, these are the relationships between those entities, how they provide structure to the overall data model and also into indicating which entities relate to which other ones important concept is cardinality and this is used to determine the minimum and maximum number of occurrences to which an entity can relate to one another. Now, when you're talking about a class model, your cardinality so for er DS, the, the, it's referred to as cardinality but for class models, it's referred to as multiplicity.

So, just keep that in mind but and why Look at that when we look at the images below. Then there's the diagrams. So one thing you're going to want it for those of you taking the C back study figure 10 dot 15 dot one, entity relationship diagram, crow's feet notation. This is going to be very important for you to understand for the exam. These are the key pieces. Now Babak doesn't go into great detail about the notation.

If I were you, I would look on YouTube for more information about how to create an entity relationship diagram and to understand the notation of that. The most important thing to understand is the cardinality and the multiplicity. So, you know, understanding what each of these means so when you see it three prongs here, that means any numbers zero to many, then you've got this symbol here, which means zero to one, then only one is the two lines here, and then a line and the three prongs is any number from one to many, right? So this is like a little one, and that's like a little zero. So that's any number, zero to many, and that's one at number one to many. So it has to be at least one.

That's what this is saying. Also study figure 10 dot 15 dot two, which is your class diagram, which is a form of a UML. The multiplicity here looks a little bit different. When you have your asterisks, that's any numbers zero to many. And x is something that must be a particular number. So this might be like a four.

So you know must be exactly And then any number from x to y, so that might be you might see any number from four to seven, right? So that's any number from four to seven. And then any number from one to asterisks, so that means any number from one to many, right, so that's at least one. And your data models also have metadata. So I talked a little bit about that earlier. And metadata basically describes what the entities represents, when and why they were created for change or changed, and how they should be used, how often they are used when and by home.

So that's kind of a good decent definition of metadata. Okay, use its considerations. So I'm done. models used to communicate consistent vocabulary used by the domain between subject matter experts and implementation subject matter experts, and they provide a consistent approach for documenting data limitations is that standards that are too rigorous might lead to models that might be, you know, unfamiliar to people who are not from an IT background. Very. So a decision analysis is basically a process for, you know, solving a problem to determine possible solutions to determine the value, the value of alternative outcomes, basically to make a choice to make a decision on something.

Usually, when you're doing a decision analysis, you're going to define the problem to find the alternatives. Evaluate the alternatives choose an alternative to implement and implement the choice that you chose. different tools for decision analysis might be the force field analysis, decision tables, or decision trees. And so your elements include the components of a decision analysis. Which is the decision to be made or your problem statement, the decision maker, the person who makes a decision or who's going to make the decision, the alternative, right, so the different possible options, the decision criteria. So this is the evaluation criteria that's going to that you're going to use in order to rank or, you know, assess the alternatives.

Then decision matrices. So there's usually two types. So a simple decision matrix looks kind of like this, where you're really just seeing whether or not each alternative meets the criteria. But when you really need to run them, you're going to want to use a weighted decision matrix in order to, you know, weigh the criteria, you know, more heavily than others, right, so this particular one might have a value of three, this one is 15. Or I'm sorry, you're going to be looking at the winning criteria. So criteria, one is worth 1.2 was worth one point, criteria, three and four are a little higher weight, right?

So that's where things start getting a little more complicated because you're gonna have to do some multiplication there in order to get to your final values. In this example, what the final values will look like here. Another form is a decision tree. Which is a method of assessing preferred outcomes when there are multiple sources of uncertainty that may exist, we're going to see an example of that down the line. You also have to consider trade offs. Basically a trade off is what you're getting in exchange for something else.

So when you're making trade offs, you're going to want to look at the elimination of the dominator alternatives. And the dominator alternatives are basically things that are just so plainly inferior to the other options. You can just get rid of them. right up front, and then your ranking objectives on a similar scale, right. So when you're doing your your way of ranking, right, just make sure that each of the evaluation criteria is used on in a similar scale, so that the prior the ranking is there. Strength is that it can be a prescriptive approach for determining alternate options and making complex decisions.

Limitation is that usually decisions have to be made right away. So you don't have the luxury of doing a formal, you know, process in order to make the best decision. Decision modeling is just really how you model repeatable decisions. So, it's a lot of the same concepts as decision model. I'm just going to get into the examples which is the decision table which we looked at earlier, and they usually contain one or more condition columns that map to specific data elements. So figure 10 point one is an example of a decision table where you've got different conditions, you know, If a loan amount for example, this one says the loan amount is less than or equal to $1,000, and the person is over the age of 18, they're eligible.

If they're under the age of 18, they're ineligible. Then decision trees are also used to represent a set of business rules, where each path on his decision tree is a single rule. So and figure 10 point 17 point to this example of a decision tree. So all of this equals our rule. So for instance, again, if the loan amount is less than or equal to 1000, then their age is over 18. They're eligible but if they're under 18, they're ineligible.

Then we also have what's called a decisions requirements diagrams. This is basically a visual representation of information knowledge and the decision making involved in more complex business decisions. And so the elements usually include a decision input data, business knowledge models, knowledge sources, so knowledge sources mean you know, that's either the document or the person that the rule came from, or the person that you need to speak to. You know if you ever need clarification on something and here's an example of a decision requirements diagram. And as you can see, the source document is the source knowledge sources kind of made with the you know, documentation notation here. Okay decision models usually simplifies complex decision making by removing business rules management from the processes and they also assist with managing large number of rules and decision tables by grouping rules by decision.

Limitations that it cuts across many organizational boundaries, which might make it difficult to get sign off on a particular model. And also may not address behavioral business rules in a direct fashion, right. So, these are most likely going to decision models are most likely going to be dealing with your definitional rules. Document analysis is basically looking for background information in existing documentation, right. So it's another way to elicit business Analysis information and get contextual understanding and requirements you know, in the existing business environment. So this might be background information, research information.

Examples might be market studies, industry guidelines, different standards, company memos, and organizational charts. So these are all things that are very helpful for helping you to form questions and to see the current state analysis. So, your elements include prepper preparation, which is really where you're just, you know, looking for either public or proprietary sources of information in regards to you know, the business or the organization that you're working within. You're going to do the actual review in an hour. All right, you're going to conduct the the review where you're reviewing all the documents, you're going to note any relevant trends or questions, record anything that's relevant, identify any conflicts or duplicates, and then note any gaps. And I'm going to record the findings.

Strength is that, you know, you can use existing sources of information and the VA doesn't have to create any new content. But a limitation is that it's usually only helpful for your current state analysis, you know, when you're looking at the as his information, and also, you know, sometimes existing documentation can be out of date. So that's another thing to keep in mind. estimation, estimation is the forecast of cost and effort involved with pursuing a course of action. Usually things cost Like cost of effort, expected benefits, estimation in terms of performance value, the cost of creating or operating something or potential risks. So your first element is the different types of estimations.

Get to know all of these, the most important ones are the top down and the bottom up. top down is things that come from a higher up or executives and goes down the hierarchical hierarchical breakdown. So, comes from topic level executives down to the chain bottom up comes from the lowest level of the value chain or lowest level of the hierarchy and then goes up so a customer or somebody you know on the line or who works with customers reported an issue and it got escalated up to you know, be important enough to make a project period metric estimation uses calibrated parametric model to to basically make estimations and calibrate it basically means you're using standards that were, you know, apparent in the previous situation ages applying a different set of numbers to that situation. So if you know that you've got your last project, one requirement takes 10 minutes and in this new project, you've got 50 requirements, so that's 50 times 10.

So that's how you calibrate rough order of magnitude or ROM is we have very limited information right? So you just really are just taking a shot in the dark. Rolling wave is where you give repeated estimates throughout the initiative. providing more detailed information, the closer you get Add to the activity. So, this is very prominent in Agile environments, you usually start with a high level estimate. And then when things are at the top of the backlog, then you give them a more detailed estimation.

Delphi uses a combination of expert judgment and history and history from the organization. pert uses a specific model. So pert has a formula and it uses three given values which include the optimistic value, or the best case the pessimistic or the worst case, and then the most likely value. The formula here is the pessimistic plus the, I'm sorry, the optimistic plus the pessimistic plus four times the most likely. And then you take all of those and divide them by six and that's going to give you your product value. accuracy and estimation, basically, you know, the information is only as good as the knowledge of the people that provide the estimation.

But it, you know, accuracy and estimation considers a measure of uncertainty. So when you have something that's a has a plus 50% to minus 50% confidence level, it's pretty broad, right? You don't really want to trust something with a confidence level that but raw, something that's more accurate would have like a 10% confidence level or within 10% confidence level, which means that your numbers are expected to be you know, higher or lower, less than 10% higher or lower. All right, so your source information, analogous information is anything Like the element being estimated, so previous projects task or people, organizational history kind of speaks for itself right previous experience within the organization, then your expert judgment, right. So having people that have had experience in this, people that have dealt with similar projects are similar solutions in the past might be able to offer some expert judgment, precision and reliability.

Know these terms precision is basically how close something is to the actual estimate. Reliability is the ability for a person to repeat those same numbers using a different method of estimation. Then the contributors have estimator of estimates. Usually, the estimates of an element are the people who are usually responsible for creating the work right. So, if I'm the developer, I I'm going to give you the development the estimation, or the estimate to actually develop that deliverable or that piece of value. strengths estimates provide a rationale for an assignment, budget timeframe or size of a set of elements.

A limitation is that estimates are only as accurate as the level of knowledge about the elements being estimated. So basically, this is saying, you know, garbage in garbage out, right. If the people aren't that knowledgeable on the subject, then they're not going to be able to provide accurate estimates. And it's usually best to choose multiple estimation practices, or estimation techniques in order to get a more accurate estimation. So using just one method may lead to unreal realistic expectations. financial analysis.

The purpose here is to understand the financial aspects of an investment. You're looking for the financial viability, stability and benefit, realize of an invested investment option. I'm not going to have time to go over all of these but have an understanding of the cost of change, total cost of ownership, value realization, cost benefit analysis, be able to work through a cost benefit analysis. So that's table 10 dash 20 dash one. You might have to, you know, look that up on YouTube to get more detailed information about it. The financial calculations that you need to know about include return on investment, right your ROI, which is really just your total benefit.

It's minus the cost of investment, divided by the cost of the investment, memorize that formula. All of these other formulas, you're probably not going to have to worry about. You do want to understand the payback period. The payback period is really just the time period that's required in order to generate enough benefits to recover the cost. So basically, that's really, you know, the amount of months or years it takes for you to break even, right. So if something costs, you know, $100 for you to make, and each month you get $10 right on that 10th month, that's when you're going to break even so on the 11th month you're going to become profitable strengths is that it allows executive decision makers to Objectively compare different investments based on the financial perspective.

It also includes assumptions and estimates, right? So, assumption, assumptions are built into the benefits and the costs whenever you do your financial calculations, and that's in the form of when we're doing our business case, we include those assumptions. The limitation is that some costs and benefits are difficult to quantify financially. Right, like things like risk, you can't quantify that right? Okay, focus group is really just, I'm going to stop at focus group since we're already over 830. I'm going to just get through this one and then I will let you guys go.

So focus group is really a way to elicit ideas and opinions and about a specific product service or opportunity. In an interactive group environment, it's really focused around getting opinions. You usually want to have some type of train moderator to help prepare the session. And so the elements include the focus group objective, so you want to have a clear objective for the focus group. You also want to have a focus group plan which includes the purpose, the location, the logistics, and who the participants are. The budget, any timelines or outcomes, right, so you want to know how the results will be analyzed and communicated to the intended audience and the intended actions based on the results.

Participants usually a focus group you want to have between six to 12 attendees. They're included in your plan like earlier, you might want to have a discussion guide for the moderator so that you can have you know, some prepared script of specific questions and topics that you're going to want to discuss in order to meet the objectives of the session. Then you want to assign the moderator and the recorder, the moderator is able to engage all the participants, right. So usually the moderator is the same as the facilitator. The recorder takes notes you know, and and make sure that any, you know, opinions are accurately recorded. In the business analysts can fill the role of either the moderator or the recorder.

Then you're going to want to conduct the focus group by making sure that you're following the script and ensuring that the objectives are met. And then after the focus group, you're going to want to make sure That you transcribe or record the information as soon as possible. And that, you know, any disagreements. You know, you want to want to analyze that information, look for any disagreements, trends and responses and create some type of summary that you're going to redistribute back to the participants. strengths of focus groups is that they save time and cost compared to individual interviews. And they're also effective for learning people's attitudes, experiences and desires.

A limitation is that participants may be concerned about issues of trust, or may be unwilling to discuss sensitive or personal topics.