So we're on functional decomposition. And basically functional decomposition helps manage complexity by breaking things down into smaller, more simplistic forms. So it helps to manage complexity and reduce uncertainty by breaking down processes, systems, functional areas, or deliverables into simpler constituent parts. So, we all know that it's usually best to break things down into something a little more simple. And here's just an example of a functional decomposition diagram where you're breaking down a basic function, breaking it down into sub functions, and then further into processes and then further down into activities. For exam purposes, it is good to know that you start with the function sub function processes and then down to activities as well.

So the elements of functional decomposition include the objectives you basically wants to know why you're decomposing whatever it is you're decomposing, so that you know you know how deeply you want to decompose and where basically you want to start. And so these are all the different reasons you might want to decompose something, something that might be to measure or manage something or to design or analyze, estimate, reuse, optimize, substitute or encapsulation of something. So things that you can decompose might be a business outcome work. You know, if you're doing a project and you're trying to estimate something, you might do a work breakdown structure by decomposing a larger task down to the smaller tasks, something that you can actually give a more reliable estimate. You could also decompose a business process a function or an activity and also decisions. Something you want to keep Mind is the level of decomposition.

And so you really want to decompose at a level that's appropriate for, you know, whatever it is you're trying to define, you know, for whatever the objective is you're trying to meet. So if you're doing something a little more high level, you don't need to decompose too much. But if you're really getting into the details of something, you're going to have to decompose a little further. And then there are several ways that you can present functional decomposition. Some of the common techniques might be a tree diagram, use case diagrams, a flow diagram, cause and effect diagrams, decision trees or mind maps, amongst others that you can see here. So one of the major strengths of functional decomposition is that it makes complex endeavors more possible by breaking it down into simpler, more feasible parts.

It also simplifies measurements and estimation of the amount of work work in defining work and defining process metrics and indicators. One of the limitations is that it really requires, you know, deep knowledge of the subject. And so you would have to either have that knowledge or it would involve extensive collaboration with with a large group of stakeholders. Alright, next technique is glossary. So glossary might seem very straightforward, but there's just a couple of things you're gonna want to know. It's really used to define key terms that are relevant to the business domain.

It's really used to provide a common understanding of terms that are used by the stakeholders. You usually will want to use a glossary when there are terms that might be unique to a domain, or if there's multiple definitions of a term, or maybe the definition implied is outside of the terms coming up. So there might also be a reasonable chance of misunderstanding. Those are also always, you know, good times to use a glossary. And also you can use a glossary when you're trying to, you know, break down acronyms and things like that. So another thing to consider is that your definition should be clear, concise and brief.

And again, like I just mentioned, acronym should be spelled out if used in the definition. So some of the strengths is that it promotes a common understanding of a business domain. And it also simplifies the running and maintenance of other business analysis information. And one limitation, well, there's a couple but one limitation is that sometimes it can be difficult for various stakeholders to agree on a single definition. So Sometimes you kind of have to do, you know, come to agree with using different words or different reasons to use a specific term and things like that. All right, our next technique is interface analysis.

This can be fun some time. It's really used where you're trying to identify where, what why, when, how, and for whom information is exchanged between solution components or across different solution boundaries. So it usually includes there's different types of interfaces, you can do a user interface analysis, or you could do people that are internal or external to the solution. You can do this for business processes, data interfaces between systems. A lot of us have probably heard of the term API's application programming interfaces analysis For that is usually pretty good if you are grabbing information from somewhere else. And this is just a quick diagram of what it could look like.

So you've got one solution here, another solution here. You're inputting information here, and then you're validating or transforming information, and then sending it back to the system. And then you got the same thing going on here. So this kind of shows, you know, the interface between two systems and one interface that actually does something with the information. And so the elements include preparing for identification. And so we really need to, you know, understand why we're doing an interface analysis.

So, usually things like a document analysis or an observation, maybe interviews will help us, you know, determined that the data or the information that we need to include in the in the interface analysis And also a context diagram can reveal those high tech, those high level interfaces between human actors, organizational units, business processes, and other solution components. And so when you're conducting an interface analysis, we really want to describe the functions of the interface, really assess the frequency of it, right? So is it something that's daily hourly, based on you know, some type of trigger and also evaluate which type of interface may be appropriate. And you look on going to look at the details about the interface, like data points and things like that. And then you're going to define your interface and that might be naming the interface determining you know, the exchange method between the two entities looking at the method message format, And again, the frequency of the interaction or the exchanges.

And so what the interface analysis one of the strengths is that when you do it early on, it increases the functional coverage that's provided. So, basically making sure that you are covering all of the applications that are involved and potentially identifying different users that might be involved or impacted by the solution as well. One of the limitation is that it does not provide insight into other aspects of the solution or the internal components like, you know, logic or design or things like that. All right. Our next technique is interviews. So interviews is a pretty common approach.

According to Baobab, they consider it to be a systematic approach designed to elicit business analysis information from a person or group by talking to interviewees asking relevant questions, and documenting responses. It's also a good way to establish relationships and building trust. To key points you want to know about the interviews is that there's two basic types. And that's your structured interview and your unstructured interview. The structured interview is where the interviewer has a predefined set of questions. So you're basically going to ask everybody the same questions and try to you know, get some feedback.

The unstructured interview is where you don't have predetermine questions or format. And you really vary the questions or the approach based on the interviewee and their responses, and the various interactions. The elements of an interview is your interview goal. So you always want to have your overall purpose for performance. The interviews and you might want to have individual interviews per persons or or individual. Your next element is your potential interviewees.

You want to identify the people, you know, that are relevant to the change or who are considered stakeholders usually identify them with the help of a project manager or the sponsor. other stakeholders can also assist you in identifying other people to interview. You can also look at the goals of the interview as well to determine who you should be interviewing. And then there's your interview questions, which are basically developed according to your interview goals. And so there's two broad types of interview questions right, so we've probably heard of open ended questions and closed ended questions. Now your open ended questions are usually used to dialogue on things that can't be answered in a simple fashion right.

So usually when you're trying to discover something, you kind of leave it open so that you can basically just get a feel for the responses that people are going to provide. So this is good when you are when you are able to look for information that you may or may not be aware of the close interview questions are good to elicit single responses such as yes or no or maybe something quantitative or a specific number. Your next element is your interview logistics, right? So that's just the location of the interview whether or not you're going to record it, you know, whether or not you're going to send the questions to and basically the overall flow the overall well I guess, logistics of the interview and then you've got your overall flow, usually things, techniques that are collaborative, always have an opening, during and a closing. So your opening is really where you're going to describe the purpose of the interview.

During the interview, you're going to always want to maintain focus, by you know, sticking to your established goals and the predefined questions if you have them. Typically, upon closing, you're going to summarize the session and outline the process for how the interview view results will be used and distributed. And you're always going to want to follow up, because that's going to help you confirm the results with the interviewees as soon as possible after the interview. All right, so one of the strengths of an interview is that it can help establish rapport with stakeholders. That's one of the big ones that I think, at least for me, kept showing up on the exam is establishing rapport. through interviews, and it also allows the interviewer and the participants to have full discussions and explanations of the questions and answers.

One of the limitations is that there is a risk of unintentionally leading the witness or leading the interviewee. Alright, so item tracking is pretty common in business analysis and project management. It's basically where we, you know, most of the time, you might refer to it as an issues log, but it's really used to capture and assign the responsibility for issues and stakeholder concerns that pose an impact to the solution. So usually, the way it works is stakeholders might identify, you know, item types, such as actions, assumptions, constraints, dependencies, defects enhancements that need to be made, or just overall issues and item tracking tracks the item from the time we record it all the way down to we basically close it out and come up with some type of agreement upon how it's going to close. And so the elements include your item record. So usually, your item records are going to include your item identifier, which is really like a unique identifier.

The summary, which is a brief description, a category where you're grouping items together. The type which is the kind of item that's raised, the date identify who identified it, the impact, which could be you know, the possible consequences. If the item is not resolved. Then the priority against the other items that's on the list. Resolution date is, you know, an agreed upon date to where the item must be resolved or closed, who the owner is, and that's the person who is assigned for managing In Game managing the issue until it closes, the resolver is the person that's assigned to resolve the item a little bit different from the resolver usually the owner delegates who a resolver is, but the owner is ultimately responsible then the agreed upon strategy so you know, the team or whoever owns it will decide on you know whether or not you're going to accept the the issue pursue it, ignore it or mitigate it somehow, with that strategy is going to be the status is the current state of the item and that usually changes quite a bit resolution updates, which is the running log of the details right.

And then it escalates matrix, which is what we will do if the item is not resolved by a given due date. So another element is your item, man. So this is basically, um, you know, how we are going to be managing the items basically. And it's usually prescribed by the stakeholder needs and any organizational standards that we have. So, you know, whatever, that's usually a part of your business analysis planning, or your governance, you know how you're going to be handling your issues, log or items tracking. You might also have metrics to determine you know, how well the items are being resolved.

And also the progress on those particular initiatives and also how well the item tracking process is being utilized. Some of the strengths of item tracking is that it can ensures that all of the state code concerns Around requirements are captured track and resolved. But one limitation is that it can use up time that might be better spent doing other efforts. Okay. Our next technique is our lessons learned, often called a retrospective. So usually in waterfall it's called lessons learned in Agile, let's call it a retrospective.

And so the purpose of the lessons learned is really to compile and conduct successful efforts, as well as opportunities for improvements, failures and recommendations for improving the performance of future projects. And so it can really be done in any venue or format that's acceptable to the key stakeholders. Things that you might want to review during a lessons learned might be your business analysis activities, a final solution Automation or technology that was introduced positive or negative variances, root causes and recommendations for behavioral approaches. strengths of lessons learned is that it identifies areas of opportunity, or I'm sorry, opportunities of for improvement, it can also reduce the risk for future actions. And it helps recognize strengths or shortcomings. One of the limitations is that it really you have to do what's called, you know, a safety check, which is where you're going to make sure that everybody is honest.

And making sure that people are not reluctant to, you know, bring things to the forefront or blame one another. And also, you Want to make sure that the the the the sessions remain focused on the solution and not the actual people's performance? Well, not the I mean, the people's personal issues we we do kind of want to talk about their performance. Okay, Kathy says, Do you recommend including a JIRA ticket as a part time worker? Oh, Tracy. Yeah.

If if you're if you're gonna document, um, you know, the platform in your item tracking list, yeah, I would put the JIRA number in in the ticket. Absolutely. That way, you know, if the issue got, you know, transferred to someone further down the line who might have access to JIRA, they might want to look in JIRA and see the actual you know, history of the ticket or the items that were documented in the ticket. Great question. All right, metrics and key performance indicator KPIs. So this is a pretty common strategy, I guess, for measuring performance.

And so metrics and key performance indicators measure the performance of solutions, solution components and other matters of interest to stakeholders. Usually, KPIs are used to manage people as well. But from a business analysis perspective, we're looking at it from more of a solution performance perspective. And so there's two key components. And so a metric is a quantifiable level of an indicator that an organization uses to measure progress. So Let's just say that your quota is 100 100 applications a month, and you reach 60.

So that 60 is your metric. The indicator actually identifies the specific numerical measurement that represents the degree of progress towards achieving a goal objective output activity or further input. So while the metric is that, that 60 mark the 60 applications you completed, the indicator is that 60 in addition to your goal, which was 100. So, right now, you're only at 60% of your goal for that month. So, the metric is just that simple number, but the indicator is what that number means, right? In comparison to the overall go right so, that is really showing your Actual progress towards the goal.

And so metrics and reporting are usually key key components when you're monitoring and evaluating. So, um so for business process, business analysis, processing, I'm sorry, business analysis, evaluation and monitoring would be using the metrics and reporting in order to measure the business analysis performance. And so your elements in your KPI or key performance indicator are your indicators. So like I mentioned earlier, the indicator really displays the result of analyzing one or more specific measures for addressing a concern. So a good indicator should be clear, which is, you know, precise and unambiguous, relevant, which means it's appropriate to the concern. economical is something that's available and at a reasonable cost or feasible to actually report on adequate means it provides a sufficient basis to assess performance.

Quantifiable is something that can be actually validated, and trustworthy, incredible, which is based on evidence and research. So we talked about metrics earlier. And metrics are quantifiable levels of indicators that are measured at a specific point in time, right. So that's important that it's measured at a specific point in time. You Target target metric is the objective. So in the example I gave earlier 100 apps a month is your target metrics.

You're at that specific point, we were only at 60. Right? So structure, you really want to have a structured approach to monitor your KPIs and have some type of evaluation system planned out. So when you're dealing with KPIs, three things you're going to want to keep in mind is reliability, which is the extent to which the data is stable and consistent across time. validity is the extent that the data clearly and directly measures actual performance. So how valid is this KPI in time timeliness is that it's fit for their frequency, right?

So is this something we should be doing every month, every two months, and things like that. And then reporting is basically the measure that we use or the the platform that we would use to, you know, compare the baseline current metrics and target metrics with the differences presented and the absolute so the absolute would be, you know, where we are right now, and also in relative relative terms. So you might want to do something over time, right? So the, if I'm at 60, today, but last month, I was at 40. It's relatively better than you know where I was at last month at this around this time. And so the strength of KPIs is that allows stakeholders to understand the extent to which the solution meets an objective, or any other thing, a stakeholder or you know, employee meets an objective.

One limitation is that if you gather excessive amounts of data beyond what's actually needed, it can lead to unnecessary expenses. A lot of the times whenever I'm gathering, you know, reporting requirements, you know, I might hear a stakeholder say, Oh, just give me all the data. But it's like, No, we don't want to give you everything because it's going to be expensive. So just let us know what you need. And we will, you know, get you the data points that you need in order to make that happen. All right, so our next technique is mind mapping.

So mind mapping is used to articulate and capture thoughts, ideas and information It's also considered to be a form of note taking to capture thoughts, ideas and information in a nonlinear diagram. It also uses images, words and color to connect relationships and apply structure and logic to thoughts, ideas and information. Here's an example of a mind map, you usually start with your main topic, which is the general idea. And then you expand out to your topic, which is you know, you're further elaborating on the main idea with the topic. And then you're going to further elaborate on the topic with subtopics. And so in between each of these levels, the main topic, topic and subtopic, you're going to have branches, so the lines that connect each of these topics are the branches, which basically are going to have a key word to show the association between the topic and the Lower Level topics.

So for instance, if this is a hospital, this the hospital might have, you know, many doctors, right? And then doctors have many patients, right? So that might just be, you know, something that a way that you can use a mind map. Right. And again, a mind map is also a form of functional decomposition. So you're taking a topic and decomposing it down further into you're getting into more detail.

So your elements include the main topic that we talked about the topic, and the subtopics. We talked about the branches and the keywords. You might also use color to categorize, prioritize and analyze topics, subtopics and their associations, or you can use images because we know that an image is worth 1000 words. So images might help To express larger volumes of information that can't be communicated clearly with just those topic headers. Okay, and so our strength of my maps is that's effective collaborative, and it's an effective collaboration and communication tool. It also helps summarize complex thoughts, ideas and information in a way that shows the overall structure.

One limitation is that it can be misused as a brainstorming tool. Usually you want to brainstorm first and then use a mind map to organize the information. Okay, so now we are on non functional requirements analysis. So are non functional requirements analysis examines the requirements of a solution to define how well the solution must perform. So non functional requirements are all about quality of service, the operation of a system, right. So these are also known as quality attributes or quality of service requirements.

Usually, you're gonna want your non functional requirements to be in some type of declarative statement to have some type of constraining factor. So, for instance, I might say that, you know, errors must not exceed three per use. Transactions must be at least, you know, 90%, processed after five seconds, right? So, within this example statement, you've got a bunch of different constraints, right? At least, you know, not to exceed right. Those are all coming constraining factors.

There's several types of non functional requirements, I would recommend, just you know, going over these and kind of, you know, having a high level understanding of them. I'll go over a few of them up some that might be on the exam might be availability, which is really the degree to which the solution is operable and assessable. compatibility is the degree to which it the solution can operate effectively with other components or other environments. maintainability is the ease at which the solution can be modified or corrected. portability is the ease at which the solution can be transferred from one environment to another. Role liability is where you're actually meaning is where the solution is actually meaning the performance that it's expected to perform right.

Given a specific period of time, scalability is when you definitely want to understand scalability is the degree to which the solution is able to grow or evolve or handle increase of nonce have worked. I know when I took the C bap scalability came up security, these involve the aspects that protect the solution from being misused you know, by some type of malicious access use or modification or destruction. Also, localization is one that came up on the exam. This deals with requirements along with local languages, laws, currencies, culture spelling, right, you know, if I am creating a solution that's in, you know, it's American based company, but the users are Mexico. We're gonna want to have right some Spanish translation or something like that, that's localization. extensibility is the ability for the solution to incorporate new functionality measures of non functional requirements.

So, you usually want to make the non functional requirements quantifiable whenever possible, right. So, for example, you want to say something like 90% right 90 is quantifiable 90% of operators must be able to use the new process after no more than six hours of training right. So, no more than is our constraining factor six hours is you know, quantifiable context. So you usually want to have some type of context. When you are creating the nonfunctional Requirements because sometimes your context might change the information might change. Therefore, you know, requirements may not bookstore requirements may need to be adjusted or removed outright depending on how the larger environment changes.

Uses considerations for non functional requirements so, the strength is that non functional requirements clearly state the constraints that apply to a set of functional requirements. A limitation is that the clarity and usefulness of non functional requirements depends on what the stakeholders know about the needs of the solution. And also if you make non functional requirements overly strict or quick, too constraining, it can add more time and cost to the solution. And usually, you know, you want to make your non functional requirements quantitative, but many times they're qualitative You know, they can be difficult to measure. All right. Our next technique is observation.

One of my favorite techniques, also known as job shadowing. It's used to elicit information by reviewing and understanding activities in their natural environment or in their context. It's used as a basis for identifying needs opportunities, understanding a business process, setting performance standards, evaluating a solution or supporting training and development. And so it's really where we are examining the work activity firsthand as it's being performed. There's two basic approaches to job shadowing or observation and that's active or noticeable and passive or unnoticeable. Active is where we're actively asking them questions as they come about.

So we're basically observing them, and asking questions interrupting them asking for clarification as they go through the process. Passive or unnoticeable, might be where we are observing them but not interrupting them. And we wait till after the observation is over to ask our questions or clarifying questions. And sometimes, you know, this could be monitoring or observing someone through video. Some of the elements for observation is the observation objective, you just want to have a clear and specific reason established for, you know, the observation session. In order to prepare for the observation.

You want to let the person you're observing know why you are observing them, and you also wants to You know, create a scaffold a schedule if you have to observe, you know, different people conducting the observation session while you're doing the observation, you want to let the person know that, you know, it's not it's not their personal performance that's being judged. Let them know what the overall goal is. You know, during this session, you basically want to watch the person attentively take notes, and note things that are typical or atypical and note the steps record with seen and the time it takes them to perform the work its quality and process anomalies. So if anything weird happens, you're going to want to note that, and again, you're going to want to ask probing questions, right? So a lot of the times people who do work every day, aren't good at explaining things.

So as the BA we have the x probing questions so that we can get the information we need. And then after the session, you're going to confirm and present that Observation results. So after the session, you usually follow up with the person you observe with the notes and the data that you recorded to make sure that you documented things appropriately. And then you know any gaps or ask any questions that you might need to ask. Some of the strengths of observation is that it can help you gain a realistic and practical insight about activities and their tasks within an overall process. And things that are informally performed, and workarounds are usually discovered or uncovered during observation.

One of the limited a couple of limitations is that it can be destructive, disruptive to the person that you are observing. And you always have to keep in mind that whenever you're being you're shadowing someone that person might be altering their normal practices. To be more, you know, to seem to go a bit more with, you know what's to be expected. Okay, so our next technique is organizational modeling. And the purpose of organizational modeling is to describe the roles, responsibilities and reporting structures that exist within an organization and also to align those structures with organizational goals. So, an organizational model really defines how an organization or organizational unit is structured.

And this might define the boundaries of our group for more relationships, functional roles, or maybe some interfaces or dependencies. And there's different types of organizational models. You might have a functionally oriented model where you group staff together based on their shirt skills, this is one of them. The most typical org charts, right? So you've got your, your typical function who manages them, and then the people they manage. And then we have our market oriented.

So let me step back. There's three typical forms. There's functionally oriented, and market oriented. And then there's the Matrix Model. So, functionally oriented is what we went over. That's the most typical org chart.

Market oriented is where you might have an org chart that's segregated by particular groups of people, market segments, customer groups, geographical areas, projects or processes. So that might look like this, where you've got, you know, the President, the CEO, the staff, then you might have market one which might be the East Coast, this might be the West Coast, and then the Midwest, right or whatever. And then each of those market segments has repeating areas within them. And then you might have a finance which has a shared role with these market segments. And then your matrix model has separate managers for each functional area and for each product service or group, so, employees will typically have a a line manager and a market manager. So, a Matrix Model would look like this.

So, these are the different areas. Each area has a line manager. And then within each area you have the employees so, you have a line manager here, but you also have a project manager here. So, you've got two managers and then In this one has a separate project manager and then another line manager and then so on. So the chain of command goes vertically and horizontally. So some of the other elements are the roles which are, you know, the units that are included the interfaces, which is usually communication between people or work products so it could be communicating in the form of deliverables and then the org charts themselves and so, the three main parts of the org chart include the organizational unit, right so, that's, you know, people, teams departments or divisions and then the people and the roles and then you also have your lines that, you know, indicate the lines of reporting.

So, That indicates accountability and control between those units. And so another element of organization model is influencers. And so within organizations, there's usually informal lines of authority that can influence, you know, how things are ran, right? And that's not directly aligned with the formal organization chart. So determining all the influencers is important for planning, communication, and also making provisions for user acceptance. One of the strengths of organizational modeling is that it is common and usually available in most organizations.

It also is helpful for future projects. If you're modeling a project and the users, future projects may benefit from knowing who was involved in a previous project. Some of the limitations is that an organism Your model can be out of date. And sometimes informal lines of authority or influence aren't reflected in the org chart making them difficult to identify. All right. prioritization is our next technique.

The purpose of prioritization is to facilitate stakeholder decisions and to understand the relevant importance of business analysis information. It's also used to determine the relevant importance of business analysis information. So there's usually about four approaches which include grouping ranking timeboxing, and budgeting negotiation. This model here model 10.331 just talks about Some of the approaches here so, you know, determining the importance of the business analysis information that you're going to choose approach. So grouping is where you're classifying business analysis information as high importance, low importance, or high priority or low priority. ranking them is where you are ordering them.

In order from least to most important. budgeting is when you're base basing the information or prioritizing based on a fixed resource. So if you're budgeting your fixed resource is money. If you're timeboxing, your fixed resources time. And then negotiation is just where the stakeholders come to a consensus about the requirements that are going to be prioritized. And those are also your elements So the strengths of prioritization is that it facilitates consensus building and trade offs, and also ensures that the solution value is realized.

One of the limitations is that some stakeholders may attempt to avoid difficult choices and fail to recognize the necessity to make trade offs. I think we've all heard of the, you know, the, the sticker that says, oh, they're all urgent, or they're all must haves, right? And it's like, No, we need to prioritize these. All right, so process analysis. This is a very important technique in life and for the exam. Really, it is the process where we're analyzing processes for its efficiency and effectiveness as well as its ability to identify opportunities for change.

It's usually used to recommend more efficient processes determine gaps between the current and the future state. Understand factors to be included for contract negotiation, understand how data and technology are used and analyze the impact of Pending Changes. common reasons for process analysis might be to reduce the time it takes to complete a task. Maybe you're trying to automate some steps right and you want to dig into it. In for business analysts, we typically look for how the process adds or creates value, how the process aligns with the organizational goals and strategy, things like that. The elements of process analysis include identifying gaps in areas to improve and so on.

When we're identifying these gaps, really identify the gaps between the current and the future state. identify the gaps between value added and non value added items, understand the various pain points that stakeholders face, understand the opportunities for improvement. And then, I'm sorry, understand opportunities to improve the process from multiple points of view. And then we're going to align the gaps and the areas to improve with the strategic direction of the organization. So we always want to go back to our business case or project charter, whichever document we're looking at. And then we're going to want to identify our root cause.

And so identifying that helps us ensure that we're actually addressing that our gap is addressing that our improvement is actually addressing the right gap. And then we create our evaluation options. And so we're really going to be helping the team evaluate and see the different points of view for improving the process. common methods include site POC, which is derived from the Six Sigma methodology. It provides a simple overview of a process where we're going to be looking at the suppliers, inputs, process outputs, and customers. So here's an example of a side path diagram.

So, here are all the sections and then your processes actually, you know, expanded into, you know, various steps to get more details of that. One thing to note is that there was something I want to say about Sai POC Was it? Well, anyway, usually you would start with the sometimes people like to start back backwards. I know the naming indicates that you start with the suppliers. But many I guess theologians suggest starting with the customer and then working your way backwards when you're analyzing the process. And then your value stream map.

This is another one that derived from six sigma, but from the lean methodologies. And so it usually provides a one page picture of all of the steps involved in the end to end process including both value added and non value added items. And so your value stream map might look something like this, where you've got your custom suppliers, your activities involved, you know your different times there's all of these have specific meanings. I You don't need to know exactly what all of them mean. There are a couple things you're going to want to understand like value added and non value added and maybe like total elapsed time, go back and look at the definitions for those. So, some of the strengths of process analysis is that it ensures that the solution addresses the right issues and minimizes waste limitation is that it can be time consuming, and that it can be inefficient if the initiative is knowledge or decision based.

So process modeling, is you know, how we bring our process analysis analysis into fruition or something tangible. So this is usually a standardized graphical view or model used to show how work is carried out. And is the foundation for process analysis usually describes a sequential flow of work or activities. And so usually at a high point you'll have like a context model. And then the lower levels is where we're going to have more operational analysis to define more granular activities. And then we're going to get even more detailed into the system level, which is where we're going to be you know, actually simulating exercises and you know, kind of talk about the functionality.

Most process models include some type of trigger or event, the sequence of activities and some type of end result. There are several types of process models flowcharts and value stream mapping. Those are used in the business domain, you might have a data flow diagram, and UML in more it areas, business process modeling and notation, you're definitely gonna want to know that for the exam, use in both business and information technology. And then see POC is used for process modeling, which all of these are. So that was kind of a weak definition but and these are just some common components that are in most process maps usually have an activity which are the individual steps or the pieces of work that's included in the business process. Your event usually initiate interrupts or terminates an activity.

The director flow is the path that indicates the logical sequence of the workflow. A decision point is a point in the process where the work is actually split into two or more flows or paths. Then you have a link, which is a connection to other process maps. So sometimes that'll just be like a little square with a plus sign into it. And then you can click on that and then I'll go to another process map. And then the roles right, these are the types of people or stakeholder groups that are involved in the process.

So here's an example of a flowchart. Figure 10 dot 35.1. Then we have an example of BP mn got our swim lanes here start and decisions, activities, data stores, sub process links. exclusions Or gateways. So have an understanding of all of these little commentaries for the sake of the exam, because you will have one or two questions on these. You've got your activity diagram here, bigger 10 dot 35 dot three, your start and decisions, tasks sub processes.

You'll have to understand what happens in your parallel gates here. Were a workflow splits. And a lot of the times I would say for the activity diagram, the BPM n and the flowcharts maybe look up some YouTube videos because Babcock doesn't go into A lot of detail about that. For those of you who are students of mine, my courses go further into detail but the back material doesn't give you a lot of the detail but they will ask you questions in regards to that, so just be prepared. Alright, so use consideration some of the strength is that process models appeal to the basic human understanding of sequence activities. So, this we know that visuals are very helpful for communicating information.

It's also effective as showing how to handle a large number of scenarios and parallel branches. It also provides transparency, transparency, and clarity to process owners and participants. Some of the limitations is that it can be become, you know, complex and unwieldly If it's not structured correctly, and more detail, a more detailed model with metadata is often used. So something like you know, a data dictionary or data mapping might be used to get more into the design aspects of a solution. Okay, prototyping. prototyping is used to.

That's technique number 36. By the way, turtle typing is used to elicit and validate the stakeholder needs through an interactive process that creates a model or design of requirements. It's also used to optimize the user experience and to evaluate design options as a basis for development. And it usually works by providing an early model of the funnel result which is known as prototype. So the elements are the approaches. And there's two common approaches including throw away, which is generally, you know, when you generate prototypes with very simple tools such as paper and pencil, and you just really want to, you know, uncover basic information and clarify some results, some requirements.

And then there's evolutionary or functional prototypes, which we create with the intent of extending them into functioning solutions as requirements are further defined. Through use stakeholder use. Some examples of prototyping include a proof of concept, which is where we're trying to figure out the feasibility of a particular concept or solution. Basically, we're trying to validate this system without modeling the appearance. We're basically Just trying to see is it something can actually do. A form study is where we explain the basic look and feel of the product without considering the functionality.

A usability prototyping is where we're testing how the end user interacts with the system. A visual prototype is where we're just testing the visual aspects of a solution, right? So the interface, a functional prototype, test the actual functionality, and the qualities of the system. So this might be more of something like a simulation. It's also referred to as a working model. So as we have more requirements, we add on to it and build on to it.

Common prototyping methods include storyboarding paper prototyping, which is a throw a type of throw away. workflow modeling is you know the sequence and then simulation is Actually demonstrating the solution or the components of the solution. This is what we use during usually like QA testing or ua T. and simulation is a type of functional prototype uses considerations is that it provides a visual representation of the future state and allow stakeholders to provide input and feedback. Usually when you have a vertical prototype where you're getting really detailed into the functionality of something, it can be used to assess the technical feasibility of something. also understand the difference between vertical and horizontal prototypes. I include those definitions in the glossary included in the on demand courses, but basically your vertical your vertical is You're getting more detailed into something whereas horizontal is, you know, you're looking at prototypes that are very high level and covering different functions.

Limitations of prototyping is that it can become, if you're not careful, you can get bogged down with the high the how, right which is the design elements of it rather than the what you're trying to resolve. Alright. Technique number 37 is reviews. Reviews are usually used to evaluate the content of a work product. Usually, each review should have an objective or purpose. There's various techniques you can use formal or informal techniques.

And you also want to identify the participants who should partake into the review Again, your elements include your objective, which is which should be clearly communicated to all the participants prior to the review, you want them to know why they are reviewing this work product or this piece of work. There are several techniques does an inspection form a walkthrough, which are very similar to one another. an inspection is basically a formal technique where you have an overview of the work product and the team members go through and look at the work product for for defects and follow up to make sure that changes were made. Formal walkthrough is where you're actually walking through the work product step by step and you're basically looking for the same information defects. You know, areas for opportunity, you're asking various questions walk through Ever can be done by peers or other stakeholders in the group.

And so a single issue review is where you focus on one issue or a particular standard. An informal walkthrough is an informal technique where you basically run through the product in a draft state, and basically get feedback before it's in its final state of techniques might include a desk check pass around or ad hoc reviews. There's various participants that should be included in a review. There's the author of the work, who's the author, the reviewers are the different peers or stakeholders. The facilitator is a neutral facilitator. who, you know, basically keeps the participants focused.

Then you also might have another neutral participant who's the scribe that might be documenting all the defects, suggestions and comments. Use its consideration. So for reviews reviews can help identify defects early on in the project, which can ultimately lead to lower project costs. Also, all parties involved in review become gauged in the final outcome of the work product. Limitations is that reviews that can be rigorous, can be time consuming and take a lot of effort. Also, informal reviews provide less assurance of removing all significant defects.

All right, technique number 38 is risk analysis and management. So the purpose of risk analysis and management is to identify areas of uncertainty that could negatively affect value and then you want to add analyze those and then evaluate those uncertainties and also manage ways of dealing with those risks. It usually involves identifying risks, analyzing risk and evaluating those risks. So the first element is risk identification. So, as risk are discovered and identified, you can use a combination of expert judgment, stakeholder input, experimentation, past experiences, and historical analysis in order to identify risks. here's just an example of a risk register, which is we're going to log everything in figure 10 point 38.1.

So have an understanding of that. Things that might be included are the risk event itself, the consequence, the probability impact risk level modification plan, who the owners are so a lot of some of these are kind of similar To the items in the items tracking, and then residual risk, you want to have an understanding of what residual risk is as well. So after you've got your information in your risk register, you're gonna want to analyze the information by understanding the risk and estimating the level of the risk. You also want to have an understanding of the likelihood of it occurring. And it's usually expressed as you know, high probability, medium or low or low, medium or high probability. And example.

Sorry, table 10.3 38.1. I'm sorry, 10 point 38.1 is an example of a risk impact scale, right. So that talks about the quality of the cost to effort scope, duration, reputation and social responsibility. These are just sample inputs for this type of scale. Your next element is evaluating that risk. So you want to, you want the risk results to be compared with the potential value of the solution to see how much change would be involved, or if the level of risk is acceptable.

The treatment of risk is important for exam purposes, you want to know whether or not you need to avoid transfer mitigate accept or increase risk. Avoid risk is where you're going to try to remove the risk or plan to plan adjustments to ensure that the risk does not occur. Transfer risk is where the risk is moved to shared with or shared with a third party. mitigate risk is Reducing the probability of the risk occurring or reducing the negative consequences. Accepting the risk is where you're really just deciding to do nothing about the risk, maybe coming up with some type of work around when it happens. And then increase risk is when you decide to take on more risk in order to pursue a bigger payout or a larger opportunity.

Strengths of risk analysis and management is that it can be applied to strategic risks that affect long term value of the enterprise. And it can also be useful for lessons learned for future initiatives. A limitation is that the number of possible risks too much initiatives can become large and unmanageable Okay, technique number 39 is the roles and permission matrix. So the purpose here is to ensure that there's coverage of activities as well as an understanding other responsibilities roles that are involved in this particular solution and also to help discover missing roles and communicate you know, how things are going to change okay. And it usually involves identifying roles associating these roles with so we should activities and then assigning authorities to you know, people who can perform those activities. And so figure 10 dot 39 dot one is is an example of the rows and permission matrix.

So you can see you've got your different activities here. And then the row groups are here. So you've got different rows administrator, manager sales customer, and these little X's indicate whether or not they can actually perform these various activities. So the elements include identifying the roles. Identifying the activities, right. common types of roles and permission matrix might include a Rossi Rossi is an important concept.

We're going to talk about the Rossi more when we talk about stakeholder lists, maps and personas, but Rossi is where we talk about responsibility accountable, consulted and informed. And then your crud is a little more related to technology systems. So that talks about who can create something, read something, update something or delete something that's referred to as a crud matrix. So we've got a crud matrix and a Rossi matrix. Identifying authorities so the authorities or the actions that identify that identify roles are permitted to perform. So each row should be able to have some type of functionality in the solution refinements so delegations is that when a particular authorities or a function can be delegated to an individual on a short term basis, so if I am a supervisor and I have supervisor, I don't know functionalities or activities.

While I'm on a two week vacation, I might delegate those that functionality to, you know, our senior analyst for a little bit And then inheritances is basically the opposite. So, inheritance is mean that, you know, what when things are at a hierarchy, hierarchical level, there might be like a supervisor role and then a analysts role like the more general role, or the more specific roles might inherent the functionalities of the general roles. So, if the general role is, let's say, analyst, the specific roles might be mortgage analysts or I don't know, banking analysts, but both of those would inherent the functionality of an analyst because the analysts role has A subset of functionalities or a general set of functionalities and then the people that inherit those have their own subsets of functionalities. Alright, and usage considerations. So the strengths of a rose and permission matrix is that it provides procedural checks and balances, as well as data security by restricting individuals from performing certain role certain tasks or actions.

It also provides documented roles and responsibilities. When limitation is that if you have too much detail, it can be time consuming, but if you do too little detail, it can exclude necessary roles or responsibilities. A root cause analysis is usually used to identify and evaluate the underlying cause of a problem. You don't want to just look at the symptoms of a problem. You want to look at the actual cause. cause of the problem and so they're usually used for active analysis and proactive analysis.

Active analysis is when you identify the root cause of an occurring problem and provide some type of corrective action. Proactive analysis is when you're identifying the potential problems in order to prevent them. So, the four main activities include problem statement definition, data collection, cause identification, where you're investigating patterns. And then actually identification where you are defining a corrective plan to prevent or minimize the recurrence. So, to one type of root cause analysis is the fishbone diagram otherwise known as Ishikawa, or cause and effect diagram and this focuses on the cause of a problem of a solution and organizes ideas for further analysis, these are the steps. You don't necessarily need to memorize those for the exam.

But here is what it looks like. It's called the fishbone diagram because it kind of looks like a fishbone. Usually when you see these, these will have like the effect will be like in the shape of a fish head. And these will kind of look more like little fish scales. And then you have your categories, and then your sub categories, some might be tertiary, secondary or primary. I would look up the definition of each of these because that doesn't really talk a lot about them here, but they're in the glossary.

They're in the glossary of the on demand courses. Sorry, they may or may not be in the glossary. I can't remember. Five why's is another root cause analysis technique as well. Basically, you're just asking why repeatedly until you get to the root cause of a problem. So, these are the steps, you basically write down the problem and ask why do you think a problem occurred?

And ask why again to get down to the lowest level of the root cause. strengths includes root cause analysis can help to maintain an objective perspective, when performing a cause and effect analysis. limitation is that it can be difficult with complex problems. Scope modeling, technique number 41. Scope modeling provides a nature of one or more limits or boundaries and places elements inside or outside of those boundaries. Typically, things are going to be classified as in scope out of scope or both.

And scope means it's going to be involved inside of the activity out of scope of is it's not involved in the activity or Or initiative both might be seen from both sides. So something like a Venn diagram where things are kind of like you know mesh together identifies boundaries seen from both sides of the boundary box. So your your elements include objectives. So usually scope models have an objective to clarify the span of control, relevance of elements or where effort should be applied, right. So project scope, solution scope, right. So these are all types of things you would be wanting to use for scope modeling.

Scope of a change is where you're concerned with elements that will be altered as part of a change. And so we you know, try to determine processes that are going to be defined or model functions that are going to be added change. To optimize use cases in situations that are going to be performed, stakeholders that are going to be impacted, you're also going to look at the level of detail. Basically, the proper level of detail provides a reduction of uncertainty. So basically, you want to get detailed enough to provide relevant information, but not too much detail that you get stuck in analysis paralysis. And those various relationships.

There's the parent child subset, right. So, again, like I talked about earlier, if there's a hierarchical decomposition, the parent child is the general and then the child is usually the subset of functional responsibilities, right? So we're an agent has specific functionalities to execute something so that's like a roll or swim lane. For an actor, right cause and effect right. So, associated elements that are involved or impacted by a change, you always want to identify your assumptions and then the modeling results. So, scope modeling can be textual descriptions diagrams, which it mostly usually is and matrices.

So, some strengths is that, you know, scope models facilitate agreement for the basis of estimating a project, justifying in scope or out of scope decisions, assessing the completeness of a solution. One of the limitations is that it can lack sufficient level of granularity in terms of boundary elements, which is often needed to ensure a clear scope identification technique 42 sequence diagrams. This is used to model the logic of usage scenarios by showing information passing between objects in a system through the execution of a scenario. So it really shows how processes or objects interact during a scenario. The sequence shows how objects use are used in the scenario, but not how they interact with one another. So, sequence diagrams are a part of UML language.

And so your elements include your lifeline. So your lifeline represents the lifespan of an object, and it's represented as a dash line that vertically descends from the object box. So here's your object box. But here's your lifeline. And so an activation box represents the period during which an operation is executed. So you've got your object box Lifeline and then here is your activation box.

And then an X shows represents when your lifeline is terminated. A message is an interaction between two objects. Usually it's represented as an arrow coming from one box basically to another and it kind of looks like this, this is a message. messages come in two forms synchronous and asynchronous. A synchronous call transfers control to the receiving object and the receiver the sender cannot act until a return message is received. So here's the sender.

I'm sending you a message, but I can't send you anything else until you send something back to me. So it's like, send you something, wait for a response send you something wait for response. asynchronous means that I can send many signals. But I can only accept one signal a lot of times I can send you 123. But I can only accept one at a time, but I can send you four or five, six, except number to send some eight nine except number three like that. All right.

Strength of a sequence diagram is that it shows the interaction between objects of a system in chronological order One limitation is that it's often considered to be too technical. for things that are outside of modeling system flows. stakeholder lists, maps and personas. These are pretty straightforward. One thing that's important to know about stakeholder list maps and personas is that you need to analyze the level of authority within each person identify right? understand their attitudes or interest towards the change the attitudes and interest towards business analysis as a whole and their level of decision making authority.

So, your list, you can usually come up with the list by you know, talking with your project manager or sponsor, but you can also Come up with the list by you know, doing brainstorming or interviews to generate an initial list. It's also important to have an exhaustive list to ensure that no important stakeholder is left out or look, because this can result in missed requirements. Your stakeholder map might be a stakeholder matrix or an onion diagram. Your stakeholder maps list the level of influence against the stakeholder interest, whereas your onion diagram indicates how involved the stakeholder is in the solution. So a stakeholder matrix looks like this, right? So you've got all these boxes, so you want to understand each of these.

So if a person is so on your vertical on your vertical axis, you've got the influence of the stakeholders. So if they are high influence or low influence. And then you've got the impact on the stakeholder, the impact the solution has on the stakeholder, right? low impact or high. So, it, the axes kind of goes like this, right? So this is high high, high low, right?

Because you're high here, low here. This is low low, right? They're low here and low here. And this is high low. And this is high high. And so these are the four brackets.

So if they're in each of these, this is basically how you're going to want to treat that stakeholder. So if a stakeholder is high influence, low impact, you're going to want to ensure that the stakeholder remains satisfied. If they are low influence, low impact you just Want to monitor to ensure that their interests don't change, high influence and high impact you want to work closely with these stakeholders to make sure that they are in complete agreement with the change and support it. If they are high influence I'm sorry if they are low influence, high impact, you want to keep them informed, this stakeholder is likely to be very concerned and they feel anxious about the lack of control right because they have a little influence. And so, these are just further descriptions of those different types of stakeholders that we discussed earlier. Figure 10 point 43.2 is a diagram of stakeholder onion diagram.

So it looks like this. And the more the closer a stakeholder is to the center here, the more involved they are with a project, right? So this is the project team and other people who are directly involved with the solution. Then you've got people that are further out all the way to, you know, customers, suppliers and regulators are a little more further removed. And then you got all of the levels in between, right. So we're back to our response, our responsibility or our Rossi metrics, again, which is responsible, accountable, consulted and informed.

This is a big concept on the exam, usually, when it comes to who should do what the answer is, according to the Rossi matrix, and so a person that Under are is responsible. This is a person who is performing an actual work or task. accountable is a person who was ultimately held accountable for the success of the task but they might not necessarily be doing the work. This is usually a decision maker. consultant is a person who would typically be asked to provide their opinion for information about a task. These are usually your SMEs, or subject matter experts informed is a person that you really just need to keep them up to date on a task and notified of the outcomes and interaction with them is usually one directional, whereas interaction with the consultant person is to directional figure 10 dot 43 dot three is an example of a Rossi matrix.

You can see all of the activities are the processes, and then the Rossi. Here is baby Basically, I'm sorry these are all of the stakeholders. And then you know, the Rossi is delegating is assigning them, you know their Rossi roles according to the project. And personas is another type of activity, right? So we got stakeholders, lists, maps and personas. Personas aren't really a big concept for the exam.

It is more so for the exam. But just so you know, personas are used to define a fictional archetype that exemplifies the way a typical user will interact with the product. Some of the strengths of these activities is that they identify specific people that must be engaged in requirements elicitation activities and they help Us fbas plan collaborative communication and facilitation activities to engage the stakeholders. Some of the limitations is that assessing information about specific stakeholders or representatives can be politically risky when we talk about things like influence and authority. Technique number 44 is state modeling. This is another one that appeared on the exam, at least on the CPA exam.

It's used to describe and analyze different possible states of an entity within a system, right. And a state is really just a form of representation of a status. State models usually represent a set of possible states of an entity, the sequence of those states, how the entity changes from one state to another, the events and conditions that caused the entity to change states and the action That must be performed by each entity in that state. The elements included is a state which is really just you know, whatever that status is during that lifecycle right. So, you can be in multiple states in at one time and also a complex state can be decomposed into sub states. So for instance, if you have a status of approved you can be approved, approved, with conditions pending and been fully approved or something of that nature.

The state transition is really just showing how the entity changes or transitions from one state to another. Then the diagram is the actual state diagram, which shows the life cycle of water entity beginning when the entity first comes into existence, and all the way until it ends. Figure 10 dot four four dot one is an example of a state transition diagram or a state diagram. So in this one, you've got your initials, your initial state, a transition state 1234. And then a final state which is where you're ending here. very simplistic example.

State tables are a two dimensional matrix showing states and the transitions between them. They're not really discussed a lot in bad luck or on the exam, but you know, it might be worth looking into for further investing for you know your own edification strengths of the state diagram is that identifies business rules and information attributes that apply to entities being modeled. One of the limitations is That sometimes a higher degree of precision about the states and transitions are required in order to build a state diagram. Technique number 45 is your surveys or questionnaires and these are used to elicit business analysis information, including information about customers products, work practices, and attitudes from the group of people in a structured way and in a relatively short period of time. Anytime you see a reference to a short period of time, it's good to use a survey. Surveys come in two types.

The questions which are closed ended and open ended which we talked about earlier when we talked about interviews, same concepts here close and it yes or no questions, open ended things that are, you know can have a range of responses or an are good for qualitative information. One thing to note is that open ended questions are more difficult and time consuming to categorize and analyze. Whereas closed ended questions are much easier to analyze. Your elements include prepare, where you're going to define the objective, define the target survey group, and choose the appropriate survey questionnaire type. Also, you're going to choose a sample group using statistical sampling methods to ensure that the sample is representative of the population so that the results can be generalized. So you always want to make sure that the results of your survey can be generalized to a broader group.

You also want to select the distribution and collection methods set a target level and timeline for the responses. If the response rate is low, you might not want to use those results because it means that results can be limited. Also, um, determine how the questionnaire should be supported with individually if it should be supported with individual review, interviews. Sometimes survey can give you very high level information. And then your interviews can get you, you know, to the next level or next more detailed information. You're gonna write your questions, test the questionnaire, and then distribute the survey.

Usually, it'll be something either in person email or with some type of survey tool. And that's going to be depending on the urgency, the level of security required and the geographical distribution of the response. That's another good indicator. If you're dealing with stakeholders that are geographically dispersed, and a survey or questionnaire is a good tool or technique, you're going to document the results by summarizing them and breaking them down into measurable outcomes. One of the strengths of surveys and questionnaires is that it's quick and relatively inexpensive to administer. It's also an effective and efficient when stakeholders are geographically dispersed, and you need information in a relatively short period of time.

One of the limitations is that the response rates may be too low for statistical significance and you can't generalize them. Alright, technique 46 SWOT analysis we all have probably heard about SWOT analysis, we're going to analyze our strengths, weaknesses, opportunities and threats to both internal and external conditions. It really identifies the overall state of the organization. your strengths are anything that the group does well, weaknesses are things or functions that the group does poorly or not at all. Opportunities are the external factors. There's that pose a, that the, that the group can take advantage of.

And then threats are external factors that negatively affect the group. Right? So usually you're going to begin the SWOT analysis with the opportunities and threats to set the context in order to identify the strengths and weaknesses. Figure 10 point 46.1 is an example of a SWOT analysis. And there are the four quadrants so there's S, o, s, t, w, o, and WT. So strengths opportunities, so really, all of the strengths, weaknesses, opportunities and threats should correlate with one another right?

Your strengths and opportunities should correlate your weaknesses and threats should correlate and things and an opposite, right so you're saying strengths and opportunities, you're going to be asking, How can the group strengths be used to exploit potential opportunities? whereas your strengths threats? You're going to be saying how can the group use its strengths to ward off potential threats? With weakness opportunities? Can the group use opportunity in order to eliminate or mitigate our weaknesses? And for the weaknesses and threats?

This is really your worst case scenarios. So is this a time for us to divest get out of this market? Right? What's the worst case scenario here? All right, so uses considerations is bad. It's good at directing the stakeholders to focus to factors that are important to the business.

One of the the limitations of the SWOT is that usually more detailed analysis is needed. Use Cases and scenarios. This is a pretty big one for the exam, I would recommend looking this up on YouTube, especially for the use case diagrams to you know, learn more about ABA notation and things like that. babba gives a very high level overview of it, but it tests you on some detail components. So use cases and scenarios are used to describe how a person or system interacts with the solution being modeled in order to achieve a goal. So you have a use cases, which describe the interactions between a primary actor the solution and any secondary actors to achieve the primary actors goal.

Usually triggered by the actor but could also be triggered by some type of system or external event. So you have business use cases which describe a particular process or business function and the system, and I'm sorry was described processes and business cases. And then you also have system use cases, which describe interactions between software applications and an actor. One thing that's important to understand is that a use case and a scenario are kind of separate things. us a net a scenario is just one specific way to accomplish a particular goal. So, a use case is actually a case a is a series of is a collection of scenarios.

So while the scenario is a collection of is a series of steps to perform an action The use case is a collection of several sub scenarios. So you've got your use case diagrams, relationships, the use case diagrams will have relationships that include extend and include. understand these thoroughly for the sake of the exam, you probably have questions on these. So this is an example 10 dot 47 dot one, where you have a use case that's extending. So a use case that is, that has the arrow pointing away from the use case is being extended. When the arrow is pointing to the use case, it's being included.

Also, extensions are optional, whereas include relationships mandatory. And so banach describes extension relationships where you're allowing the insertion of additional behavior to the use case. And here, the use case can be completely functional on its own. So basically, if I'm completely functional on my own, I'm a use case. And I might want to extend out some additional functionality here. But if I'm including this include, allows for a use case to make functionality present in another use case.

So this is basically where you're sharing functionality, right when you're including your sharing functionality, and the included use cases are not, they cannot be executed on their own. So we're sharing this functionality, but I'm including this functionality. Here, but I can't complete this use case until this functionality is completed. Also, this is your system boundary box or your boundary box actors. Primary actors are always on your left hand side and secondary actors always on your right hand side. So that's a use case diagram.

A use case description is a technical is a textual form of a use case. which usually includes a name, which is the unique name the goal which is a brief description of the outcomes of the use case, the actors involved. The preconditions are things that must be true in order for the use case to begin. The triggers are events that initiate a specific flow or event for the use case. Then the flows of events are You know the steps performed by the actor throughout the the use case, your flow is usually going to be your main flow which is also called basic or primary, which is the shortest and simplest path to success. Or you can have alternate flows, which are the less likely ways to successfully complete a use case.

And you're also going to have exceptions, which happens when you are not able to complete that use case. Post conditions or guarantees or things that happen, or that must be true once the use case is complete. Again, a use case is something that you're probably gonna want to YouTube or look more about. I also have a articles on the use case description and the use case diagram on my website on my techniques page. You can check that out as well. But the story Have a use cases that the diagrams can clarify the scope and provide high level understanding of requirements.

And descriptions are easily understood by stakeholders because of their narrative flow. And also they can articulate functional behavior of a system. A limitation is that decisions and business rules that define them should not be recorded in a use case those should be managed separately. Technique 48 is user stories most of us know about those. Those are a small concise statement of functionality, or quality needed to deliver value to a stakeholder. They focus on value and they are used to capture stakeholder needs to prioritize as a basis for estimation and planning and also for generating acceptance tests.

Elements include a title which is optional. The statement of value, the statement of value is your who what and why. Right Who's the persona? The what is the action or behavior or the feature or quality? And then the Why is the benefit or value received by the user? The typical format is, you know, as a who I need to what?

So that, so that why, right? That's typical format. Also, you're given when then is the gherkin format that is actually more of a format for your acceptance criteria. We know about the three C's. And in that is conversation, right? conversation is where the user stories are designed really to help the teams explore and understand features described in the actual user story or the card and the value that it would deliver to the stakeholders.

And then the acceptance criteria. So user stories alone aren't that helpful. User Stories are the equivalent of stakeholder requirements. acceptance criteria are equivalent to solution or functional and non functional requirements, where you're decomposing those requirements into the, you know, the actual details. And so user stories are usually supported through detailed acceptance criteria that really defines the boundaries of the user story, and help the teams and the developers understand what the solution needs to do in order to deliver value to the stakeholders. strengths of user stories is that they're easy to understand by stakeholders and that they focus on value to the stakeholder limitations is that user stories are intended to be a tool for short term capture and prioritization, not necessarily for long term knowledge retention to provide a detailed analysis technique 49 is our vendor assessment.

A vendor assessment is usually used to assess the ability of a vendor to meet commitments regarding the delivery and consistent provision of a product or service. So most vendor assessments on you know, they can be informal or they can be formal through a request for information or request for, quote, request for tender and request for proposal, I will look all of those items up in the glossary just to have a high level understanding of what they are. But what you really want to know about the vendor assessment is that you would use it and evaluation criteria in conjunction with evaluation criteria to assess partners and vendors. Some of the elements are the knowledge and expertise of the vendor, right because that's something you're going to want to consider the licensing and pricing models, right? You want to consider those for the best cost benefit ratio. The vendors market position, right See where they are in the market?

Are they the top supplier? Are they third? And third? Are they in the top? 10? Basically, what did they look like, according to their customer community, terms and conditions, right?

How difficult if you decide to go to another vendor in the future? Are their terms and conditions gonna lock you down? How difficult are they going to make it for you to transition to another supplier? And also, you want to consider the Venice experience reputation instability, right? Have they been around for a while? Are they stable?

You know, are they financially viable things like that? strengths of a vendor assessment is that it can help develop a productive and fair relationship with suitable and reliable vendors. One limitation is that it may be consuming in regards to time and resources. Oh, right. All right. Last technique is workshops.

So workshops bring stakeholders together in order to collaborate on achieving a predefined goal. One thing about workshops is that you're working together on a single goal. And also, you are working together on actually completing something. There's usually a defined deliverable at the end of a workshop. And so it's a focus event attended by key stakeholders and subject matter experts for a concentrated period of time. They usually include a representative group, we talked about that a defined goal, interactive, collaborative work, a defined work product, right so after the workshop, there should be some deliverable and then a facilitator.

Elements include preparing for the workshop where you're defining the purpose of the workshop, and To define goals, identifying the facilitator and describe and creating an agenda, amongst other things. During the workshop, you've got to have several roles which includes the sponsor, who is not usually a participant in the workshop, but they are ultimately responsible for the successful outcome of the workshop. The facilitator is going to make sure that all the participants are heard and are participating and also dealing with any issues and conflicts. scribes are going to be documenting decisions the timekeeper is going to keep the time and the participants are going to be sharing their subject matter expertise. while conducting the workshop, you're going to want to make sure that you're maintaining focus by you know, continuously validating the sessions activities within the work, purpose and outcomes. After the workshop, which is the post workshop Wrap up, you're going to follow up on any open ended action items that were recorded complete any documentation and distribute the the workshop notes to the attendees or any stakeholders who need to be kept informed.

The strengths of workshops is that they can help achieve agreement in a relatively short period of time. It's a good way for stakeholders to collaborate and make decisions. It's more cost effective than you know, multiple interviews. And it's also a good way to build relationships. Limitations is that you know, schedule complex So, availability can all can make it difficult to schedule a workshop, and also workshops that have too many participants can slow down the workshop process. Okay, we have completed our techniques and our series