All right, so we are on chapter seven, which is the requirements analysis and design definition, chapter and knowledge area. And this is the knowledge area that has the largest distribution of questions on the exam for all of the core exams. So it's a pretty important chapter. Now, requirements analysis and design definition really describes the tasks that we SBA is performed to structure organized requirements. During discovery elicitation activities, we also specify a model requirements and designs, validate and verify the information, identify solution options that meets the business need and estimate the potential value. There's a lot of different activities involved that might range from the initial concept and exploration of the need, all the way down through transforming those needs into a particular recommendation.

Both requirements and designs are important tools used by the business analysts in order to define and guide change. Now, while in many traditional spaces, the development team handles designs and the BA panels requirements, Babcock believes that requirements and designs are an important part of the business analysts role. And so, requirements and designs may either be high level or very detailed based on their appropriate skill set or knowledge set of those who are consuming the information. And when we are analyzing the requirements and designs, we are usually collaborating with both the implementation subject matter expert in order to define solution options that will be you know, evaluated in order to recommend the best solution option for those And when we're considering the business analysis value spectrum, the requirements analysis and design definition, knowledge area or the task within it really fall right in the middle of that value spectrum.

It's right in between strategy analysis and solution evaluation, in most cases, right, so it's a midway in between, you know, establishing potential value and recognizing the actual value. Now, the requirements analysis and design definition knowledge area includes several tasks, including specify and model requirements, verify requirements, validate requirements, define requirements, architecture, defined solution options, and analyze potential value and recommend solution. Now specifying requirements really describes the setup requirements and designs in detail Using some type of analytical techniques, so this is where we're actually, you know, trying to describe what we're trying to create here. Verifying requirements basically make sure that the requirements and design has been developed in enough detail to be usable by a particular stakeholder and is pretty much of high quality. So we want to make sure that it is usable down the line. Validate requirements ensures that the requirements and designs deliver the value and actually supports the organization's goals and objectives.

Define requirements architectures. This is basically the structure of all requirements and design and doing so in a way that supports the overall business purpose. To allow the requirements to work effectively in a cohesive manner to find solution options really just described today different possible ways of meeting that need, the need that we've defined to the requirements and analyze potential value and recommend solution is where we're going to assess the business value associated with each potential solution and compare the different options. And then we're going to recommend the solution option that delivers the greatest overall value. And the core concept model for requirements analysis. And design definition really describes the uses application of the core concepts within the context of requirements analysis and design definition.

But like the others, I recommend understanding the task in detail first and then going back and applying the core concepts to each of those tasks or each knowledge area. And so the inputs for the entire requirements analysis and design definition Knowledge area includes requirements and any state information management approach elicitation results at any state potential value, solution scope, and change strategy. We've talked about all the tasks and your outputs will include requirements that are modeled and specified requirements that are in a verified state requirements that are in a validated state, the requirements architecture, design options and then a solution recommendation. Alright, so our first task is specify a model requirements. Now the purpose of this task is to analyze, synthesize and refine elicitation results into requirements and designs. And so whenever we are focusing on specifying Modeling activities, whenever that's focusing on understanding a need, the outputs are usually what we call the requirements.

But when the focus of specifying a modeling activity is on the solution, the output is referred to as design. So, design is use. You know, like I had mentioned earlier in many it spaces. It's created by software developers, data architects and other implementations subject matter experts. But all business deliverables are referred to as requirements, right. So and that's that most companies, but again, Babcock believes that the business analyst should be involved in the quirements and the designs process.

So your inputs for specifying and modeling requirements includes a little dictation results in any state. So, modeling can began really, you know with any elicitation results and it can occur sequentially iteratively or concurrently. And so, your output after you specify one of the requirements will be requirements that are specified in modeled. And so the elements in specify a model requirements include the actually the task of model requirements, which is a descriptive and visual way to convey information in to a specific audience in order to support analysis, communication and understanding. So, as business analysts we usually choose from one of the following formats, which might be matrices, which is where we model requirements or a set of requirements that may be complex but have some type of uniform structure that can be broken down into elements. And matrices might be data dictionaries, requirements, traceability, or they might be used for a gap analysis.

Now, diagrams on the other hand, those are visual often pictorial, pictorial, I'm sorry, representations of requirements or a set of requirements, they usually depict complexity in a way that will be difficult to do with words. So the same holds true that a picture's worth 1000 words. And they're good at defining boundaries of business domains, also to categorize and create hierarchies, and also to show components of objects. Now, the modeling portion of the requirements might include some several different categories and those categories might include People in roles, which, you know, might represent organizational groups of people, roles and their relationships, right, we'll usually see this with organizational modeling roles and permission matrices, and maybe a stakeholder list, map, and persona. The next category is the rationale. And this represents the why of the change.

Usually, this might include decision modeling, scope modeling, Business Model Canvas, the root cause analysis, and a business rules analysis. The activity flow category represents a sequence of actions, events or a course that may be taken. We see this and process modeling, use cases and scenarios and also user stories. The capability category focuses on features or functions. This might include business capability analysis, a functional decomposition, or some type of prototyping. Now the data and information category represents the characteristics and exchange of information.

So we see this what we're dealing with the data dictionary, the data flow diagrams, data modeling, glossary, state modeling and interface analysis. And usually when we're modeling, we might use any combination of these models that's best suited to meet the stakeholder needs. Now, your next element is analyze requirements. And this is where we really decompose information into components to further examine them. So we examine them for anything that needs to change anything that should stay the same, anything that might be missing, or unnecessary, and also any constraints or assumptions that might impact the components. And analysis really provides a basis for discussion in order for us to reach a conclusion about solution options.

Now our next element is represent requirements and attributes. Now there's various attributes that can be specified for each requirement or set of requirements. And each attribute is selected when you're planning for in your information management. And as part of specifying, we can also categorize according to a specific schema that might have been described, you know, when we talked about the requirements classification schema. And categorizing, categorizing requirements can help ensure that the requirements are fully understood. And also that a set or any type of requirement is complete.

And also that there's an appropriate traceability between the types of requirements. Our next element is implement the appropriate level of abstraction. So we talked about abstraction earlier and that's really just a level of detail or how conceptual it is. And the level of abstraction of a requirement really varies based on the type of requirements as well as the audience, it may be appropriate to produce various viewpoints of requirements in order to represent the same need, but from the perspective of different stakeholders and it's also used to maintain the meaning of requirements as well. Also, the business analysis approach can influence the level of abstraction as well. So you know, the choice of models used when defining those requirements can can often be impacted by the frameworks or the methodologies and the guidelines and tools whenever you are specifying and modeling requirements might include different modeling notations, which is really just the standard templates.

Consent To help make sure that the right information is provided about the requirements, also a modeling tool, the requirements architecture will help show interrelationships among the requirements. A requirements lifecycle management tool might be useful. And also the solution scope, which is the boundary of the solution might provide the boundaries of the requirements and ended in the design models. And there's various techniques that you can use when you're specifying requirements. And that can include acceptance, any evaluation criteria, which would represent the acceptance and evaluation criteria, attributes of the requirements. You could use business capability analysis, Business Model Canvas business rules analysis, conceptual modeling can be used to define the terms and relationships that are relevant to change identity dictionary can record details about data that's involved in the change.

A data flow diagram can be used to visualize data flow requirements. data modeling will also be used to model the requirements to show how data is used. You could also use decision modeling functional decomposition. In order to identify constituent parts. You can use a glossary an interface analysis, a non functional requirements analysis to define the quality of service attributes. You can use organizational modeling, Process Modeling to show the steps or activities that are performed.

You could use prototyping to assist stakeholders in visualizing the appearance and capabilities of the solution. You can also use rows information matrix in order to specify and model requirements concerned with the separation of duties. You can also use a root cause analysis scope modeling sequence diagrams, stakeholder lists, maps and personas State modeling. You can also use use cases and scenarios in order to model the desired behavior of a solution. And you can also use user stories to specify requirements as a brief statement about what the people or stakeholders need to do. Now, the stakeholders involved in specifying and modeling requirements would be any stakeholders.

So the business analysts may choose to perform this task themselves. And you know, in order to separately package and communicate the requirements in order for the stakeholders to review and approve those requirements, or they may choose to invite some or all stakeholders to participate in this task. And so your output really just be requirements that are in a specified and modeled state. And this is really any combination of requirements and or designs in the form formatting text matrices in diagrams. Okay, so our next task is verify requirements. The purpose of verify requirements is to ensure that requirements and design specifications and models meet quality standards and that they're usable for the purpose they serve.

Verify requirements usually ensures that the requirements and designs have been defined correctly. It also constitutes a check by the business analysts and key stakeholders in order to determine that the requirements and designs are ready for validation usually a high quality specification is well written and easily understood by its intended audience. While a high quality model follows the formal and informal notation standards, and effectively represents reality, the most important characteristics of quality requirements and designs is fitness for use, meaning that they must meet the needs of the stakeholders who will use them. The inputs for this task are requirements that are in a specified and modeled state. And this is any requirements design, or set of those that may be verified in order to ensure that the text is well structured, and that the matrix season modeling notations are used correctly. The output for this task is just requirements that are verified.

Now the elements for verifying requirements include characteristics of requirements and design And there's several different requirements in design quality characteristics, and this includes the following. First, we have atomic, which is capable of being understood independently of other requirements. For exam purposes, atomic would also mean broken down to the lowest level. Another quality requirement is complete, and this is that it's in enough detail for further work at the appropriate level of detail to continue. A consistent requirement doesn't have any conflicting requirements that's conflicting with others. A concise requirement contains no extraneous or unnecessary content.

A feasible requirement is one that's reasonable and possible to achieve. And also that's feasible enough to investigate further an ambiguous requirements are those that are clearly stated and it are expressed in such a way where it's clear whether the solution does or does not meet the associated need. testable requirements are able to be verified that they have been fulfilled. So that requirement or design is something that you can actually test. Prioritize requirements are ranked or grouped in terms of importance and the value against all other requirements. requirements that are understandable are those that are represented using common terminology of the audience or the stakeholders.

Okay, so our next element is the verification activities. And these are usually performed iteratively throughout the requirements analysis process, verification activities might include checking for compliance with organizational performance standards, checking for the correct use of modeling notations, templates or forms. Also checking for the completeness within each model. You might also be comparing each model against other relevant models or verifying that the elements are reference consistency consistently. You would also be ensuring that terminology is used expressing the requirements in an understandable manner. Also, you want to be sure to add examples where appropriate for clarification purposes.

And your next element for verify requirements is checklists. checklists are used for quality control and when verify requirements and designs they're also used to ensure that I items determined to be important are included in the final requirements deliverables. Now wanting some tools when you're verifying requirements might be your requirements lifecycle management tools. And these might be used to check for issues that relate to many of the characteristics such as being atomic or on ambiguous and prioritized. Now the techniques that you might use for verifying requirements would be acceptance anybody wishing criteria, which you might use to ensure that the requirements are clearly stated. You could also use item tracking to ensure that any problems are issued are managed and resolved.

You could also use metrics and key performance indicators or KPIs. In order to identify how to evaluate the quality of the requirements. You can also use reviews which might be used to inspect the requirements documentation to identify requirements that are not of acceptable quality. And once again, the stakeholders involved in verifying requirements are all stakeholders. So usually the business analyst in conjunction with the domain and implementation subject matter experts have the primary responsibility for determining this task. But other stakeholders might discover problematic requirements as well.

In your output for verifying requirements are simply requirements that are in a verified state. And this is a set of requirements or design that is of sufficient quality to be used for the basis of further work. Now, the next task is validate requirements. Now, the purpose of validate requirements is to ensure that all requirements and designs are aligned to the business requirements. So we basically want to make sure that they trace back to the business requirements or the goals and objectives and that they support the delivery of the needed value. Now validating requirements ensures that stay Colors, solution and transition requirements all aligned to the business requirements, and that the designs satisfy the requirements for business analysts.

Understanding what the desired future state looks like for stakeholders is greatly beneficial for ensuring that the needs have been met. Now, when you're validating requirements, your inputs will include requirements that are specified in my lower part. It's I'm sorry requirements that are in a specified and modeled state, which is any of the requirements and designs that are able to be validated. Now validation activities may begin for requirements before they are completely verified, however, you cannot completely validate requirements before requirements are completely verified. So in other words, you need to make sure that your requirements are completely verified before you can completely validate them. Now the elements for validating requirements include identifying assumptions.

And a lot of the times when organizations might be launching an unprecedented product or service, it may be necessary to make some assumptions. Or it could be difficult or impossible to prove that a particular problem is derived from an identify root cause. But we must make sure that these assumptions are identified and defined so that the associated risks can be managed. Now the next element in validating requirements is defining measurable evaluation criteria. Now business analysts define the evaluation criteria that will be used to evaluate how successful the change has been. baselining metrics might be established in order to understand Where we are in the current state, and then the target target metrics can be developed in order to reflect whether or not we achieve the business goals and objectives.

The third element for validating requirements is evaluating alignment with the solution scope. And whenever a solution or a requirement does not deliver the benefits of the stakeholder, it's a strong candidate for elimination. When requirements do not align, either with either the future state must be re evaluated and the solution scope needs to be changed or the requirements should be removed from the solution scope. Now some guidelines and tools for validating requirements might be your business objectives, your future state description, your potential value could be used as a benchmark against which the requirements to be assessed and also you Solution scope would be used to ensure that the requirements provide benefit within the scope of the desired solution. Now, some of the techniques that might be used for validating requirements might include the acceptance and evaluation criteria. A document analysis can be used to identify previously documented business needs.

In order to validate those requirements of financial analysis might be used to determine the financial benefits of the requirements. You could also use item tracking, the matrices or the metrics and key performance indicators might be used to select the appropriate performance measures. Your reviews will help confirm whether or not the stakeholder agrees with the needs being met. And then your risk analysis and management might be used to identify possible scenarios that will alternate the benefit delivered by the requirement. Now all stakeholders would be involved in validating the requirements. Now again, The business analysts.

In addition to the customer, the end user and the sponsor would have the primary responsibility, but other stakeholders may discover problematic requirements as well. And so your output for validating requirements is simply requirements in a validated state. And these are requirements and designs that can demonstrate a benefit to stakeholders and also these requirements and designs that are aligned with the business goals and objectives of the change. Now, the next task is define requirements architecture, defining requirements architecture. The purpose of this is to ensure that requirements collectively support one another and fully achieve the objectives. Now requirements architecture is Really the structure of all the requirements of a change and ensures that all the requirements form a single hole that supports the overall business objectives.

As business analysts, we use requirements architecture to understand which models are appropriate. Organize requirements into structures relevant to different stakeholders, illustrate how requirements and models interact, ensure that requirements work together, and also to make trade off decisions. Now, requirements architecture is not intended to demonstrate traceability, but rather to show how the elements work together in harmony with one another. It also structures them in a way to align with the viewpoints of different stakeholders. Now the inputs for defining requirements architecture, include information management approach would be, which is where we'll be storing and accessing information required Mint's is another input and also the solution scope, which is where you know this must be considered in order to ensure that the requirements architecture is aligned with the boundaries of the desired solution. And your output again would be requirements architecture.

Now, the elements included in defining requirements architecture. The first is requirements, viewpoints and views. Now, a viewpoint is a set of conventions that define how requirements will be presented, how these representations will be organized, and how they will be related. A viewpoint usually provides some type of template for addressing the concerns for a particular stakeholder group. Requirements viewpoints are usually include standards and guidelines for modeling types use for requirements attributes that are included and consistently used, making sure that requirements model notations are used. also ensuring that different analytical approaches are used to identify and maintain relevant relationships to the requirements.

Necessary single viewpoint alone can form an entire architecture. Each viewpoint is stronger for some aspects of requirements and weaker in others. Examples of viewpoints might include a business process models viewpoint, data models and information viewpoint, user interaction viewpoints, audits, insecurity viewpoints, or business models viewpoints. Now slightly different from a viewpoint is a view. Now the actual requirements and designs of a particular solution from a chosen viewpoint refer to as a view and a collection of views make up the requirements architecture for specific solution. So in short, viewpoints tell business analysts what information they should provide for each stakeholder group to address while views describe the actual requirements and designs that are produced.

Now the next element is template architectures. an architectural framework is a collection of viewpoints that standard across an industry sector organization. business analysts treat frameworks as a predefined template to start from, and then some domain specific information might be added to make the information more accurate. The next element for defining requirements architecture is completed. Now in architecture helps ensure that a set of requirements is complete. It also ensures that the requirements set is cohesive and tells a full story.

The fourth element for defining requirements architecture is relate and verify requirements relationships. business analysts examine and analyze the requirements to find the relationships between them and also ensure that the representation of these relationships is provided by tracing. Now, usually business analysts will make sure that the requirements satisfy the following quality criteria that the relationships follow the following criteria. So, relationships between requirements need to be defined So we want to make sure that there is a relationship and that the type of relationship is described. We want to make sure that the relationship is necessary. So we want to make sure that it's necessary for understanding a requirement holistically.

We also want to make sure that it's correct the elements that do have the relationships described. So we want to make sure that the relationship between those requirements are correctly described. We also want to ensure that those requirements relationships are unambiguous, and that no relationships link to elements in two different or conflicting ways. We also want to make sure that the relationships are consistent. This means that the relationships are described in the same way using the same set of standard descriptions as defined in the viewpoints. Now The last element for defining requirements architecture or define requirements architecture is business analysis information architecture.

So the architecture of business analysis information is also information information architecture. And this defines this is defined as part of the plan business analysis information management tasks. And this describes how all of the business analysis information relates to the change. It's usually useful to start with defining this architecture before setting up whatever infrastructure for the requirements such as the requirements, lifecycle management tools, or some type of architecture management software or documentation repositories. So, the guidelines and tools for define requirements architecture include a architecture management software which can help to manage the volume, complexity and versions of the relationships. Also legal and regulatory information because they may impact the requirements architecture or its outputs, and then methodologies and frameworks, right, the defined set of models and relationships between the models might be used in order to represent different viewpoints.

Now, the techniques that might be used for defining requirements architecture include data modeling, functional deep composition might be used to break down an organizational unit product scope, or other elements into component parts. Other techniques might include interviews, organizational modeling, scope modeling, or you could use workshops to define the requirements structure. Now, the stakeholders involved in defining requirements architecture might include the domain Subject Matter Expert, the implementation subject matter expert, the project manager, and the sponsor tester, I'm sorry and the sponsor and the tester. These individuals may all assist in defining and confirming the requirements architecture. And also any stakeholder can assess the completeness of the requirements. So, your output for define requirements architecture is your requirements architecture, which is the requirements and the interrelationships among them, as well as any contextual information that gets recorded.

Alright, so our next task for requirements analysis and design definition is define design options. And the purpose of defined design options is to define the solution approach. identify opportunities to improve the business allocate requirements across solution components, and represent design options that achieve the desired future state. Now each design option represents a way to satisfy a set of requirements. design options usually exist at a lower level than the change strategy, and are tactical rather than strategic. business analysts must assess the effect each trade off will also have on the delivery of the value to the stakeholders.

Now, inputs to define design options include your change strategy, which describes the approach that will be followed to transition to the future state the requirements in a validated and prioritized state as well as requirements architecture, which is your full set of the requirements relationships. Now the elements for define design option include defining your solution options. And this is where you're describing whether the solution components will be created, purchased or some combination of both. Now, creating involves solution components being assembled, constructed and developed by experts, as directed as a direct response to a set of requirements. purchasing a solution component is where components are selected from a set of offerings that fulfill the requirements. And then the requirements and design options have enough detail to make a recommendation about which solution to purchase.

Or you might use a combination of both. So not all design options will fall strictly into one of these categories above. And whenever we're looking at these types of approaches to propose integration of components is also considered. Now the next element is identify improvement opportunities. So common examples of improvement opportunities include increasing efficiencies, which is where we might automate or simplify the work people perform by reengineering or sharing processes, changing responsibilities or outsourcing. We might also improve access to information which could provide greater amounts of information to staff who directly or indirectly interfaces with customers.

And this could reduce the need for specialists. And then another example is identify additional capabilities, which could highlight capabilities that have been that have the potential to provide future value and can support the value by solution. Now the next element for define design options Requirements allocation. And this process of assigning requirements to solution components and releases to the best achieve objectives. And allocation is usually supported by assessing the trade off between alternatives and in order to maximize the benefits and costs, requirements may also be allocated between organizational units, job functions, solution components, or releases of a solution. And then the last element of defined design options is to actually describe the design options and design options are investigated and develop while considering the desired feature state and in order to ensure that the design option is valid.

Solution performance measures are also defined for each design option. And each design element may describe a business policy and business rules business processes, people who operate and maintain the solution, operational business decisions, software application and application components or organizational structures. Now the guidelines and tools for defined design options might include existing solutions, which include existing products or services, or maybe even a third party that is considered as a component of the design option. You also want to use the future state description, the requirements that are in a trace state and your solution scope. Now various techniques that might be used for defining design option might be benchmarking and market analysis. brainstorming might help identify improvement opportunities and design options.

You could use document analysis. Interviews might be used to help identify improvements opportunities and design options as well. You could use a lessons learned mind mapping, root cause analysis, surveys or questionnaires vendor assessment or you could also use workshops. Now, the stakeholders involved in define design options would include your domain subject matter expert who might provide expertise within the business. Your implementation subject matter expert will provide their expertise in terms of the design options from a constraints of the solution and cost perspective. The operational support team can evaluate the difficulty and cost of integrating proposed solutions.

The project manager would also be involved because they would plan and manage the solution definition process and then suppliers would provide information on the functionality associated with the particular design. Now, your outputs for the Find design option would just be your design options, which describes the various ways to satisfy one or more needs in a particular context. That may include the solution approach potential improvement opportunities and the components that define the option. Now your next task for requirements analysis and design definition knowledge area is analyze potential value and recommend solution. And so the purpose of this task is to estimate the potential value of each design option and to establish which one is the most appropriate to meet the Enterprise's requirements. Now, this task describes how to estimate and model the potential value that's delivered by a set of requirements, design or design options.

Now value is usually described in terms of finance, reputation, or even the impact on the marketplace. So, any change may be a mix of increases or decreases in value. Define design options are evaluated by comparing the potential value of each option to the other options. And in some cases, there may be no best options to recommend or there may be a clear best choice. Now, the best choice maybe to begin work against more than one design option or perhaps to develop proof of concepts and then measure the performance of each. And in rare cases, it may be possible that the best recommendation is to do nothing.

Now the inputs to analyzing potential value and recommending a solution Include the potential value which is used as a benchmark against which the value delivered by the design is evaluated the design options and those are needed to be evaluated and compared. And then your output would be a solution recommendation. Now, the elements for analyze potential value and recommend solution include the expected benefits, which describe the best positive value that a solution is intended to deliver to the stakeholders. And that's going to include benefits, reduced risk, compliance with business policies and regulations, and improved user experience or any other positive outcome. Now the total expected benefit is the net benefit of all requirements in a particular design option. And benefits are often realized over a period of time.

The next element is expected cost. And this is any potential negative value that's associated with the solution. And this might include timeline, effort, operational costs, purchase or implementation costs, maintenance costs, physical resources, information resources or human resources. And you want to consider expected costs from a cumulative cost of each design component. You also want to consider the opportunity cost. opportunity costs are alternative results that may have been achieved if other resources time and funds devoted to a design have been taken.

Now your next element is to determine value of the business value of a solution to a stakeholder is usually based on the benefits. value can be positive if the benefits exceed the cost, or negative if the costs exceed the benefits. business analysts consider potential value from the viewpoints of the stakeholders. Also, it's important to remember that value to the entire enterprise is usually more heavily weighed than the value to any individual or stakeholder group. Also keep in mind that potential value is uncertain value. Also, business analysts will define a complete estimate of the purpose driven and monetary monetary effects of a proposed change by considering the tangible and intangible costs aside the tangible and intangible benefits Now our next element is to assess design options and recommend solution.

So each design option is assessed based on the potential value it's expected to deliver. And so there are several factors that's taken in consideration. So, we also consider the available resources right there may be limited resources regarding the amount of requirements that can be implemented. We also consider the strengths on the constraints on the solution. So this might include regulatory requirements or business decisions that may require certain requirements to be handled manually or automatically. Or could also require that certain requirements be prioritized above others.

And we also want to consider the dependencies between requirements. And this is needed to be you know if some requirements have to be delivered in order to support other high value requirements. business analysts will recommend the option or options deemed to be the most valuable solution to address the need. Now, the guideline for analyzing potential value and recommend solution would be your business objectives, which will be used to calculate the expected benefits. The current state description, the future state description, your risk analysis results, which includes an assessment of the level of risk and then your solution scope. Now, several techniques could be used while you are analyzing potential value and recommending solution.

Your acceptance and evaluation criteria is used when assessing the proposed solutions and determining whether the solutions meet the defined needs. You could also use backlog management brainstorming a business case could be used to assess the recommendations against the business goals and objectives. You could use Business Model Canvas decision analysis, estimation is used to forecast the cost and efforts. The financial analysis is used to evaluate the financial return of different options. a focus group is used to get stakeholder input interviews is also used to get stakeholder input. The metrics and key performance indicators or KPIs are used to create end evaluate the measures used to define value.

You could also use risk analysis and management surveys or questionnaires a SWOT analysis are also workshops to get input from stakeholders. Now, the stakeholders involved and analyzing potential value and recommendation might include the customer to analyze the benefits. The domain subject matter expert can assist in analyzing the potential value and benefits your end user would be involved as well as the implementation subject matter expert who would identify potential costs and risks, the project manager manages the selection process. The regulator might be involved in risk evaluation. And then your sponsor would also need to be involved because they would need to approve the expenditures have the resources that are used in order to purchase or develop a solution and approve the final recommendation. And so your output for this task would simply be a solution recommendation.

And this identifies the suggested most appropriate solution. Based on the evaluation of all defined design options. The recommended solution should maximize the value provided to the enterprise. So that concludes all of the tasks that are included in the requirements analysis and design definition. Knowledge area