We are going to be covering chapter five, which is the requirements Lifecycle Management knowledge area. So, requirements Lifecycle Management is basically just the upkeep of all of the information and the requirements relate related to a specific project or initiative that we are currently undertaking. So this particular knowledge area describes the tasks that VA is performing or to manage and maintain requirements and design information from inception to retirement. So we'll talk a little bit more about what that means later. But those are two important terms that you're going to want to understand is that as soon as a need is identified, that is the inception of debt retirement is basically can sometimes be further past, the project being closed. But we'll talk about that.

And so the purpose of this knowledge area is to ensure that business that the business stakeholder and solution requirements and design. So these are the various levels of requirements. So business requirements, they could requirements and solution requirements and designs are aligned to one another and that the solution implements them. So we're basically helping to ensure that the information is available for future use. And so bad Bach basically describes, you know, the requirements lifecycle as something that begins with representation of a need, or representation of a business need, right? We all know that requirements are a representation of a need, and it continues through the development of a solution, right, and our designs are our solutions.

And then it ends when a solution and the requirements that represented are retired. So this goes back to when we talked about returning Up here, retirement is not necessarily when the project closes, it is when a solution that uses those requirements is actually retired. Alright, and another thing to note is that the concept of a requirements lifecycle is different from a methodology. So when we think about, you know, traditional waterfall methodology in the in the phases, you know, you've got your initiation and analysis and requirements phases. That's the sdlc. Right?

So that's a little bit different from the requirements lifecycle. And this is just a quick image of a potential requirements lifecycle, not every requirement goes through the same life cycle. So you start with, you know, maybe a requirement and this is one that's a little mature. So this one is actually being assessed. So we're determining whether or not rubbing it forward if we do yes Then you're going to get your approval or send it off for approval. Once you get their approval if it's approved again, you're either going to maintain it or trace over or prioritize it.

So if it doesn't, if it doesn't meet, make the assessment, right, you're just going to continue that cycle again. So if it's no here, you just got to keep on assessing it until you're able to move it forward. And then if it's not approved, then you need to go back to the drawing board and start all over. So this is a you know, a typical requirements lifecycle. But this doesn't this is kind of like once it reaches assessment, it does several other states that it will probably enter before it goes into that into assessment. So the requirements Lifecycle Management knowledge area typically includes well according to bad luck, it includes trace requirements, maintain requirements, prioritize requirements, etc.

Requirements changes and approve requirements. So tracing is basically where we analyze and maintain the relationships between requirements design and the solution components. Maintaining the requirements is where we're making sure that the requirements and designs are accurate and current, right. So as information changes or information updates, we need to make sure that we are updating our documentation and any information that is being used for work down the line. So we're maintaining those requirements. prioritized requirements is where we're actually assessing the value, urgency and risk associated with particular requirements and designs.

So most of us associated this with you know, prioritizing a backlog or, you know, having certain dates that represents the urgency for a particular piece of work that's being done or the work that you know, we want to make sure that the work that's most important, gets done first. And then assess requirements changes is where we evaluate new and changing stakeholder requirements to determine if they actually need to be acted upon. And then approve requirements is where we assess and work with the stakeholders involved in the governance process in order to reach an approval and agreement. So here's our business analysis core concept model. It basically describes how the core concept model is used within the context of the requirements Lifecycle Management. Each week, I outside of the first week I've skipped past this.

It's good for you to know as a supplement information, but we talked about it during week one. And then once you get more familiar with the various tasks within Requirements Lifecycle Management, I'd recommend going back and just going over those core concepts to see how you can apply them to this particular knowledge area. And so our inputs for the requirements Lifecycle Management knowledge area include requirements, designs, proposed change, and requirements that are actually verified. And then again, here are five tasks that we're going to be performing in this knowledge area. And so our outputs are all all of our outputs are simply going to be requirements and designs, but there'll be in various states. So the various states would include trace requirements and designs, maintain requirements and designs, prioritize requirements and designs.

And then we're also going to have some requirements change assessments, requirements and design, change assessments, and then approve requirements and designs. Alright, so let's talk about turning requirements. So the purpose of tracing requirements is to ensure that requirements and designs at different level are aligned with one another. So earlier, we talked about our business requirements, they could have requirements and solution requirements, we want to make sure that they align which means as if something changes, if we determine that a, you know, stake requirement needs to get updated, then our solution requirements, meaning our functional and non functional requirements need to reflect that change, or if we are down the line, and we determined that, you know, once we're doing some design work that the solution requirements doesn't make sense, then we need to go back further and make sure that our stakeholder requirement reflects the changes that we've made as well and also that that still aligns with the business need And when we're tracing requirements, we're basically documenting the lineage of each requirement.

So this includes our backwards traceability in force traceability. So, backwards traceability is when we are looking backwards. So we're looking at our solution requirements, tracing it back to stakeholder requirements, which traces back to your business requirements, which traces back to a need. And so the for traceability is just the opposite is what we're looking forward. So your need your business requirements, your stakeholder requirements, solution requirements, and then the actual solution that implements or design that represents the the functional or the solution requirements, and then the actual implementation or solution that implements the requirements and designs. And we're going to make sure that our solutions conform to the requirements.

And once we get into looking further into these, we're going to be detecting any missing functionality. And traceability basically enables faster and simpler impact analysis, right. So when we're assessing changes, if we've properly traced our requirements, we can see what exactly is going to be the impact of that change if we traced the requirements and designs Well, it also allows for more reliable discovery of in consistencies and gaps. And it also allows for us to to perform deeper insight into the scope and complexity of a change over time, and it also enables reliable assessment of which requirements have been addressed and which ones have not right. So traceability allows us to keep track of you know, things that have been implemented and things that have not. And so as the as we are charged with balancing how in depth would need to trace how formula needs to be.

So we're balancing the number of relationship types with the benefits gained from actually representing them because traceability tends to take away from other activities we can perform. So we want to make sure that we are getting the most out of the traceability and not doing more work than we're actually getting benefited from. And these are two types of traceability that you need to understand. So there's process traceability and in their software requirements traceability Bab up focuses much more on software requirements traceability, but it is important to understand process traceability, which starts with the value chain, and then goes into the business process, a sub process, and then your activity and then the tasks. So This is basically like a thumbnail. So this is your highest level value and you decompose these all the way down to your most detailed task item.

And then for software requirements, traceability, you're going to start with your actually you would start with a need, or problem opportunity, and then you're refining that into your business needs. And then you break that down to your, your, your business requirements, and then you break that down after you've identified your stakeholders. And then you turn those into stakeholder requirements. And then you transition those into solution requirements which will be in the form of functional requirements and non functional requirements. Okay. And so, then you would create designs, you being the business analyst in the design team, being the technical team.

With the business analysts having some insight into that, and then they would develop code for that. And then the test team or the QA team would develop test cases for that as well. And then, you know, the developer would have tests, and then the QA team would have tests for all of this information. And again, all of this going from top to bottom is for traceability. And then going from the bottom to the top. That would be backwards traceability.

This is actually a pretty important image for you to understand. So keep that in mind. And so your inputs are going to be requirements and designs. Then we go through our trace requirements exercise, and then our outputs are traced requirements and designs. So, your elements are basically just the level of formality. So, like I discussed earlier, we as the as this, we determine how much effort we need to put into tracing.

Because, you know, the effort grows basically, you know, as the number of requirements and the level of formality increases. So, the more formal, the methodology or the framework or the more requirements we have, so, if you've got, you know, 200 requirements, that's probably going to require a lot more tracing than you know, a small project with maybe 15 requirements. And then you need to know the relationships that the different types of traceability relationships derived is the most common So, this is basically the relationship between two requirements when one requirement is derived from another, so, This basically describes backwards traceability where a solution requirement is described, I'm sorry is derived from a business requirement or a stakeholder requirement. And depends is basically when one requirement depends on another requirement. So, there's two types of depends, depends relationship. So, one is a necessity, where it only makes sense to implement one particular requirement, if the related requirement is also implemented.

And then the effort depends relationship is when implementing one requirement is easier if another requirement is also implemented. And so satisfy is the relationship between an implementation element and the requirement that it satisfies so to say to in another word, You know, you might have a functional requirement, and then a solution component. So basically some type of functionality that satisfies the functional requirement. That's your satisfy relationship. And then validate is just the requirement and the test cases, right. So each requirement should have a test case to accompany it.

That way we can verify that it is implemented and functioning correctly. And then you also want to have a traceability repository. So this is your third element. You know, there might be specific requirements tools that might be used to make manage or tracing a large number of requirements easier. But it can be something as simple as an Excel spreadsheet, as well just depending on the formality of it and how many requirements you have guidelines in tools include domain knowledge, information management approach, legal and regulatory information. And then again, your requirements management tools repository.

So, like I said, it can be something as simple as you know, a text document or Excel or as complex as a dedicated requirements management tool. So there's a few text techniques that you can use for traceability or tracing and that might be you know, business rules can be used to trace you know, business rules to requirements. functional decomposition is, you know, what we can use to trace high level concepts to lower level concepts, right. So, tracing our business requirements back to the lower level, functional requirements, non functional requirements or solution components. Scope modeling is also a good way to trace requirements to the entire scope right to make sure that change to a requirement is still within the scope of the project. Stakeholders would include customers domain subject matter expert in user your implementation subject matter expert and tracing is good for them because it helps ensure that the solution is being developed to actually meet the business needs.

And then you'd also include your operational support project manager, sponsor, supplier and your tester, right we talked about the the validate relationship here where your testers are going to have to validate they need to understand the traceability to validate whether or not that, you know, that solution component is meeting the requirements need. So, they need to understand the tracing relationships to understand where the requirements are implemented. Also in order to create their test plans appropriately. And so, your outputs are simply trace requirements and trace designs and so, requirements and designs that are trace basically have a clearly defined relationship to other requirements solution components or releases phases or iterations within a solution scope. So, ultimately, you want to be able to identify any effects of change or clearly identify any effects of change and that goes for requirements and designs. Okay, so maintain requirements.

Maintain requirements. The purpose of this is to, like we talked about earlier is basically to retain the accuracy and consistency throughout and beyond the initiative. And to make sure that these are remaining consistent throughout the entire requirements lifecycle. And also, we maintain requirements in order to support reuse. So, not every requirement is the best source or the best candidate for reuse. But in order to maximize the benefits of maintaining requirements and reusing them, we want to make sure that the requirements are consistently consistently represented and that they are reviewed and approved for maintenance using some type of standardized process that allows for the proper access rights right.

And also that it is easily accessible and understandable, right because the purpose of reusing it is so that anybody can get So we don't want to have something that's difficult for other business analysts or other stakeholders to get to. Again, your inputs are requirements and designs and our task is maintaining those requirements. So our output is basically going to be requirements and designs that are maintained. So again, these aren't actual deliverables. These are more so a state of the requirements and the designs. Okay, and so your first element is maintain requirements.

So, in order for requirements to be properly maintained, they must be clearly named and defined and easily available to stakeholders. This is something you should understand, I think, that might pop up on the exam. So you want to make sure that requirements are clearly name defined and easily available to stakeholders. So you want to use posit tours with excepted taxonomies to assist in establishing and maintaining links between the maintain requirements and facilitate the traceability. element number two is maintaining the attributes. So, first we maintain the requirements and now we're maintaining the attributes.

So our attributes are, you know, different components within the requirement. So, when we're actually eliciting with requirements, we should also be eliciting the attributes. So that might include you know, the source of information, the priority of that requirement, complexity of the requirement, right and these all, you know, aid in managing the requirement throughout the lifecycle. So you know, things like your unique identifier, and things like that will all assist in maintaining the requirements as changes come about. One thing to know is that a an attribute may change even though the requirement doesn't right. So, for example, you know, we know that a state of the status of the requirement can change, right.

So something can go from, you know, assessment to approved to implement, implemented or close out are completed, right. So, this, the attributes don't always stay the same. Now, things like a unique identifier should never change, but many other attributes do not change for a requirement, I'm sorry, do change for requirement. And then our third element is actually reusing the requirements. So requirements that are good candidates for long term were used are those that again, are clearly names that are identified, defined and stored in a manner that makes it easily retrievable by other stakeholders. So, um, requirements can also be used in a lot of different ways.

So you can use a requirement, reuse a requirement within the current initiative, maybe in a different phase, or in a similar initiative. Right. So if you've implemented a project in the past and you're, you know, maybe updating something, some type of system, you can use, reuse those requirements in a similar initiative, or in a similar department, right. So if you are implementing the same type of initiative, maybe with a different department, right, you can reuse some of those high level requirements, or you can reuse requirements throughout the entire organization. It typically requirements at a higher level of abstraction meaning requirements that are at a higher level in general, more generic With limited reference to solutions, those are better candidates for reuse. Because the more detailed you get, and the more you know, detailed and concrete you get, that's where the changes happen, right, those are subject to more changes, and more specification, so those are less likely to be reused.

So again, like business requirements or you know, business needs, that represents that are represented in a general manner, without direct ties to particular tools or you know, an organizational structure. Those are more reusable. And that also ties into you know, the, the taxonomy we use for you know, the system shell where, you know, I've had a lot of developers say things like, Well, why don't you just say the name of the solution and a part of the reason is to remain system agnostic because we can still implement a need. And but we might change the solution. So if we decide on a different solution down the line, you would have to update those requirements. You know, if we didn't make that change, so that's why you see system shall our system must rather than saying the actual name of the actual solution, though there are cases where, you know, implementing the actual name of a solution does has its place.

But you know, you make a requirement, more system agnostic and more reusable by omitting the actual system name. So your guidelines and tools is just your information management approach. So this just indicates how requirements will be managed to use. So that's just a subset of your business analysis approach. Some techniques you might use are business rules analysis, data flow diagrams that have got a modeling, document analysis, functional decomposition, process modeling, use cases, scenarios and user stories. So maintaining requirements may include several stakeholders including your domain subject matter expert, your implementation, subject matter expert, operational support, the regulator and the tester.

And as you can see, most of these people, these stakeholders are just going to be referencing those maintain requirements. Right, but your implementation subject matter expert might use it for, you know, as you know, they're actually working through the implementation process or doing regression testing, things like that. And, you know, again, your tester is going to be using it to aid in the test plan, creation. And, again, you outputs are just another state of the requirements. So that particular state is going to be a maintain state. And so you typically define the requirements and the design once and then it's available for long term reuse by the organization.

Also requirements. One thing that batum doesn't talk about a whole lot in the documentation is a process, organization process, asset or RPA. And that's basically just a documentation that is used as a guide to help the organization reach a particular go. So Organizational Process acid as a general term that people in business analysis in the project world should have an understanding of. So requirements are maintained in order to become an organizational process asset. Okay, next task and requirements Lifecycle Management Is prioritize requirements.

So most of us are familiar with this process. So this is really suggest ranking requirements in the order of relative importance. And so when a requirement is prioritized, we're basically giving it a higher or lower priority. And this might be the relative value against other requirements. But it can also refer to the sequence in which we're going to actually address or implement that particular requirement. And prioritization may be an ongoing process as new information is learned or as you know, stakeholders needs change.

So, you know, you prioritize and reprioritize you know, on a continuous basis. Another thing that prioritizing does is it also identifies interdependencies between requirements um, you No and this might also be used as a basis of prioritization. So, if one requirement depends on another, the requirement that is dependent upon would be have a higher level or have a higher priority than the one that is dependent on the other. So, our inputs again are just requirements and designs and then our task is prioritize those requirements. So our outputs are going to be requirements and designs that have been properly prioritized. So the elements of prioritized requirements include the basis of requirements.

So this is something that is typically agreed upon by you know, relevant stakeholders on during the business analysis, planning and monitoring activities. And this is what basically Almost like parameters that determine how significant a particular requirement is. And so some typical basis factors include benefit, right. So this is really the advantage that occurs when, you know, to the stakeholders when an actual requirement is implemented. And that's typically measured against the goals and objective of that change. penalty is the consequence that results from not implementing a particular requirement.

So a lot of the times this is related to like maybe the compliance or some type of government. Some type of government rule or regulation. Costs is the efforts and the resources needed in order to implement that requirement. So, cost is often used in conjunction with other criteria such as a financial analysis. cost benefit analysis, when we're determining that we're doing prioritization risk is the chance that the requirement can't be delivered, or the need can't be met. So usually, if there is some type of risk, we manage that.

So we manage that, you know, in order to minimize the any negative input. So, sometimes risk might be technical feasibility, right. So if we think there's a risk that we can't implement this requirement at all, we typically will prioritize that earlier so that we can do find out whether or not we actually can implement something so that we're not spending resources on it down the line, or find out that, you know, we can't actually achieve that goal later down the line, right, so that's something we want to discover up top. Again, we talked about dependencies but basically dependence Is the relationships where one requirement cannot be fulfilled unless Another one is. So, again, that's something that you identify as a part of your tracing requirements task. Time sensitivity is the best before date of a requirement.

So basically anytime, after the best before date, the implementation of that requirement loses a significant amount of value. And that can also refer to season functionality as well. stability is important so this is basically the likelihood that a requirement will change. So if something is very stable, then we give a higher priority than something that's not stable. So if it's not stable, we give it a lower priority and in order to minimize an anticipated rework, or any type of wasted effort, Then regulatory and policy compliance. So, these are requirements that must be met in order to meet regulatory or policy demands.

So this actually goes hand in hand with penalty. So the regulatory and policy This is the actual requirement, but the penalty is what what happens if we don't meet that requirement? And then our next element is the challenges of prioritization. So one of the biggest challenges of prioritization is having multiple stakeholders, and in cases like that, many stakeholders might value different things. So it can become difficult to prioritize one requirement that is allocated to one stakeholder against another requirement that's allocated against another stakeholder. So If your number one priority is this and another person that already has that, how do we prioritize them against one another?

And there are things that we'll discuss when we talk about the prioritization technique further down the line in order to remedy that, so, and also stakeholders can have different difficulty characterizing a requirement as a lower priority. So we've all heard stakeholders say, oh, they're all urgent or they're all important. So one thing that a business analyst needs to keep in mind that if requirements has, if there, if there is no priority, then we can't we can't really implement that requirement, right. So if they're all urgent, if they're all important, that's just like saying there's no priority, right? So we have to coach Guide stakeholders to be able to consider the basis of prioritization in order for us to come up with a reasonable prioritization for the requirements. Now, this is something that again, prioritization is a bigger concept in more agile environments or adaptive environments, because and predictive environments, you typically implement all of the requirements that are there.

So prioritization usually happens only on a case by case basis. And then continue with prioritization. So again, as priorities shift and context changes or evolves, you know, different pieces of information becomes available. So, this might involve refining a previous prioritization. So a lot of the times, you might start off with a high level prioritization based off of, you know, whatever information You know, and then as new information is obtained you you do a more granular or refined prioritization prior to implementation. So some of the guidelines and tools might include your business constraints.

So like we talked about regulatory statues, contractual obligations and business policies that may define priorities. We talked about those with our regulatory requirements and our penalties, your change strategy domain knowledge governance approach, which outlines the prioritization process and then your requirements architecture. So this is helpful for understanding the relationship between other requirements, right, so as we talked about dependencies and things like that, understanding your requirements architecture would help. And then your requirements, management tools and repository and Solution scope would also be useful guidelines for prioritizing requirements. We've got several techniques, including backlog management, your business case, you know, you might use that to assess the requirements against the identified business goals. So that's good to determine your when we talk about a basis of benefits.

Looking at the business go is a good source for determining that benefit decision analysis, tool to use estimation might be used to produce estimates have a basis of amortization, if we have to consider time as a factor, right, because time is also a resource that is considered when we talk about cost. financial analysis, again, is the financial value of a set of requirements right. So that could also be considered when we're talking about benefits as well as costs. interviews I'm striking prioritization obviously, is a technique that we will be using to facilitate the prioritization process, as well as our risk analysis and management. So when we have understood the risks as a basis of prioritization, we're going to be managing that without risk analysis and management technique. And workshops is another technique, we'll probably use for prioritization.

Again, several stakeholders involved including the customer in user implementations, subject matter expert, your project manager, regular regulator, and your sponsor. So, most of these individuals, your customer and user, regulator and sponsor are going to be verifying the prioritization and making sure it's consistent and works. Where as your implementation subject matter expert is going to be providing some input relating to technical dependencies in your project manager might use this as an input for the overall project plan. outputs are going to be prioritized requirements and designs. So these are prioritized and ranked properly for additional work to continue. So we're just making sure that the highest valued requirements and designs are worked on and addressed first.

That's what prioritized means. So again, any questions on prioritizing requirements? I'm in the comments, if you will. All right. Alright, so assess requirements changes is our next task. So the purpose of this is really to evaluate the implement implications of proposed changes to requirements and designs.

Simple as that. We're really doing this as new needs or possible, you know, solutions are identified. So, we do this in order to determine whether or not that proposed change is going to increase value of the solution or decrease it. But if it's going to increase the value, what action should we take in order to implement that change? So um, we're also looking to see Rather proposed changes introduced conflicts with other requirements and also if they increase the level of risks. So, when we're looking at these changes, we're considering if the proposed change aligns with the overall strategy, how it affects the value delivered to the business or the stakeholder groups, how it impacts the time to deliver that the resources and the resources required and then if it alters any risks, opportunities or constraints, so, you know, you generally are going to want to have your Will you will have your change board right, looking at these requirements, changes right as identified in the the governance approach.

So, things like how it impacts time to deliver and the resources is something you might want to have a Someone like your implementation subject matter expert or someone on the technical team as part of your change control board, so that you can get someone with that insight on things like time and resources as such. And again, the decision making processes to your change control process approach is defined in your your plan, Business Analysis governance task. So your inputs are going to be your requirements designs, and also any proposed change have been Your task is you're going to assess these requirements changes, and your outputs will be your requirements and designs change assessment. All right. So you're The first element and assess requirements changes is the assessment formality. So, we know that you know, predictive approaches tend to be a little more formal, right?

So they would have a formal change control process where you'll actually have a change control board that consists of various stakeholders and your adaptive approaches however, tend to minimize the impact of changes by building it into the process. So, they you know, what, the more incremental approach right so, the idea of continuous evolution is really basically reducing the need for a formal change control approach. Where, whereas the predictive will have a formal process So they'll have likely in predictive projects, you'll likely have a change control board. Whereas adaptive approaches, it's usually just the product owner or the customer representative who makes those types of decisions probably right before they approve a requirement to go into the you know, the next iteration or during refinement sessions. Your next element is your actual impact analysis. And so this is where we are assessing the effect of the change.

So usually, your traceability, if you have done a good job of tracing, it helps with the impact analysis. So, you're going to be again, it's a lot of basis for assessing the impact is the same as the prioritization but a little bit different. So some of the things you're going to be considering are the benefits of making that change the cost of implementation and the associated work involved in making that change the impact, right? So that's the number of customers or business processes that are impacted by that change the schedule, what is the impact to the existing delivery commitments you have, as well as your urgency. So what's the level of importance? So thinking about things such as regulatory or safety issues, and then the impact resolution.

So this is basically what we're going to do, how we're going to resolve this. And we want to make sure that we're documenting all of these changes and that they're all all of the resolutions are communicated to all stakeholders. And so the way we do this is determined again in our business. In our plan, business analysis, governance. guidelines will be the change strategy, any domain knowledge you might have, right? So knowledge and expertise is something that's needed in order to assess a change.

And again, your governance approach is what's going to guide you regarding how the change control or decision making process is facilitated. legal and regulatory information is, you know, kind of a basis for assessing changes the requirements architecture, you know, how that requirement relates to other requirements can also determine its impact and the schedule as well. And the solution scope. So you want to make sure that the change that's being assessed is understood and also that it's within the scope of the proposed of the proposed change. various techniques, your business case is a good way to justify the proposed change. Just make sure again, it's in line with the goal.

Your business rules analysis, your decision analysis, right is a good way to facilitate change assessments. Right. So that'll let you develop the process for that. Document analysis estimation. Again, your financial analysis is used to estimate the financial consequences of a proposed change, interface analysis, interviews, item tracking, and then your risk analysis. And management, again, is used to determine the level of risk that's involved with a particular proposed change and workshops is a good way to facilitate that assessment.

So, you know, if you are in a predictive project and your habit change control board, they'll likely be doing workshops in order to make that final decision of that change. Alright, stakeholders might be customers, domain subject matter experts, and users operational support, project manager, regulators, sponsor and tester. And as you can see, a lot of these are just using information in regards to what the impact of that would be in order to provide input to that, the assessment of that change. And again, your operational support, need to know about, you know, any potential, you know, changes, right, what's the nature of a change in order to determine whether or not they are able to support the change? So it's nice that a, you know, a requirement is going to add benefit, but does the operational or the daily support team do they have the means to support that change for the future as well?

So that's something that awesome needs to be taken into consideration. And again, your outputs are requirements change assessments. So this is just the recommendation to either approve, modify or deny a proposed change to a requirement or design component. All right, so again, we trace requirements maintain those requirements or the initiative, we've prioritized those requirements. We have assessed requirements changes. And now we are on our last task, which is approved requirements.

And the purpose of this task is to basically obtain agreement and approval of requirements and designs for business analysis work so this could be approving requirements as they're being developed are also approving requirements changes. And so approval can be formal or informal, much like the assessment and the prioritization process. Predictive approaches we know have more formal approval processes that may require formal sign off. Whereas adaptive approaches typically only happen when we're about to start the implementation process of a particular requirement within a iteration. So inputs are verified requirements and designs. And then we go through the approved requirements process, and their outputs are just requirements and designs that are in an approved state.

So our first element and approve requirements is under Standing the stakeholder roles. So this actually goes way back to when we're doing our stakeholder analysis. We need to know who has approving authority, right. So we're responsible for obtaining these. So we're required to understand who holds decision making responsibility, and who possesses the authority to sign off documents and requirements across the entire initiative. So while many stakeholders may provide input or influence into decision making process, only a few stakeholders have the actual authority to approve or deny requirements or an actual change to those requirements.

Another element to provide requirements is conflict and issues management. So as we're trying to get consensus among the stakeholders, right, in order to get approval of the requirements, however, Um, you know, a lot of times it's difficult to get so we have to be able to manage those conflicts. And that is planned for and our governance, our plan, Business Analysis governance task. And another thing too is that business analysts tend to communicate, facilitate the communication between the stakeholders so that each of those stakeholders when there is a conflict, that we're able to help them have approved, improved appreciation for the needs of one another. Right? A lot of the times that will help us reach a conclusion when there is a conflict and then gaining consensus.

So this is basically us ensuring that the stakeholders with approval authority, understand and accept the requirements. And we typically get approval by reviewing those requirements and changes with the individuals who are accountable for making those decisions and approving and also indicating the agreement with the solutions and the designs. And so this is planned, the consensus is actually planned for, and the plan business and office governance and the communicate business analysis information, activities. One thing to note is that complete agreement may not be necessary for a successful change, right. So, not all stakeholders may agree to a particular requirement or a change. But if there is a stakeholder who is not agreeing with everyone else, and it's impossible to get agreements, we need to consider that a risk and manage that risk accordingly.

And then we also want to make sure that We're tracking and communicating these approvals as well. So we want to make sure that we're communicating these or maintaining these in our tracking tools. Because stakeholders need to be able to determine what permits, requirements and designs are currently approved, and which ones are in line for implementation, right. So that'll let us know what's been resolved and what's moving forward, and what we still need to look at. And so in our tracking process, we need to be able to communicate what has changed, who made the change, and the reasons for that change, as well as when it was made. And so some of the guidelines and tools for approving requirements might be your change strategy.

We know the governance approaches where we identify all of the formalities of that approval process. any legal or regulatory information, requirements management tools and repository is where we would record those requirements approvals. And then the solution scope is something that we need to consider doing approval as well. techniques we might use as the acceptance and evaluation criteria, right. So this is what we would use when we're determining whether or not we're going to be approving requirements. So when we're looking at the basis of approval or the change assessment, right, we have to develop some type of acceptance and evaluation criteria.

Decision analysis might be used to resolve those issues. Item tracking is used to identify to track issues that are identified during the agreement process, right. So again, if there is an outlying stakeholder who's not agreeing with the rest of the team, we need to consider that a risk to manage moving forward. Reviews might be used to evaluate requirements. And then a workshop might be used to facilitate an attending approval in a group setting. All right, so stakeholders involved would include your customer, domain subject matter expert, your end user, and your sponsor.

All of these would be a revealing either reviewing or reviewing and approving requirements. Also your operational support project manager, regulator, and tester would possibly be involved in the approval process, not necessarily as an approver. But they need to be informed on you know what the outcome is because it's going to impact work down the line. And so your outputs again, are going to be requirements and design that are in an approved state. And requirements and designs that are in an approved state are basically agreed to by stakeholders and are ready for use in some sequent business analysis activity. Design That are approved are agreed upon and ready for subsequent business analysis activities or solution development efforts.

Alright, so we have completed our requirements Lifecycle Management knowledge area and the five tasks that are inside within that are bye for now.