Collect Requirements process in PMBOK6. Enjoy this video of my free online PMP Exam Preparation training course and prepare to sit and pass the PMP certification exam from PMI. This PMP training video is based on PMBOK6 (PMBOK Guide) and covers the process of Collecting Requirements, which is under Scope Management knowledge area.
hello and welcome back to my PMP training course in this video we will discuss the process called collect requirements which is the second process in the scope management knowledge area now this is one of the more important processes because requirements are at the heart of scope management and pretty much all of what we do on a project is based on what the requirements are when we had a project charter initially to start a project the Charter would have listed the high level objectives of the client or customer and the the next steps that we do after that is identify stakeholders meet up with them and collect their requirements and specifications so in other words we take what the customer wants as a high level business need we convert that into a set of requirements which we later on schedule activities and resources for us be able to implement those requirements collect requirements is the process where we document what the customer wants what their expectations are every customer has expectations on what the end products going to look like and they also have expectations on what the project needs to meet so from the project side here we can think about time requirements budget requirements compliance types of resources that they want us to use maybe in-house resources or maybe external resources so they might have some project related requirements as well as the product requirements which are the descriptive aspects of the end product if you’re making a table then what does the table look like its specifications length width height if it’s a building how many floors and maybe if it’s a process then functions within a process roles responsibilities these would be considered the technical specs so these would be product requirements now the project’s success is going to be directly impacted by our efficiency in capturing and managing requirements and also it’s going to require participation from stakeholders if stakeholders don’t agree to meet with you to collect to share information on how things are right now or what they expect of the end product then you might have a difficult time collecting enough requirements for you to be able to work on this project the process that we use to collect requirements is called elicitation installation is another word for collecting however it means drawing out information and if you’ve ever tried to collect requirements you probably know that collecting requirements is not an easy process mainly because these customers or stakeholders don’t really have enough information and you have and you’re at a loss sometimes for where the way the information needs to come from so elicitation is drawing out information that you need for you to be able to implement the project and once you get that information from them you want to record it in enough detail so that it can be used later on for confirmation of delivery so if you said the wall must be 8 feet tall then later on the acceptance criteria would be that if we measured the height of the wall it will be 8 feet tall so then we need to be able to document these requirements clearly enough so that we can test them later on we usually want to start with the project Charter or any information that is available to us early on such as business cases or contracts but project charters in this case here would have high-level objectives of the organization and then we from there we identify who the stakeholders are go meet up with them the stakeholders are typically listed in a document called a stakeholder register which we will cover when we get to the stakeholder management knowledge area but we would have them on a list set up some time with these different stakeholders based on their experiences or role and then we sit with them and use using different techniques that we will now cover soon and requirements from them so what is a requirement a requirement can be one of two things it’s either a condition or a capability a condition would be something that is mandated on the project so timelines cost like budget could be for example the way we need they want the documentation at the end the type of resources that should be on the project like how many senior managers are there at all times should they be PMP certified also the meetings that they require how often they want you to meet with them and update them the way they want you to update them these are requirements that don’t describe the product in any way but instead they discuss how the project should be managed so we call them project requirements so those project requirements tend to be most of the time part of the conditions that are mandated on you other than conditions we also have capability so other than condition we have capabilities these capabilities are the descriptive aspects of the end product so if this is a car or if it’s a building then all specs about that car or the building the height the number of rooms if it’s a building that you know the elevator aspects security system maybe the the color the spaces the number of units that are in it these are part of the capabilities capabilities may refer to technical aspects of the system how it interfaces with something else what it does may have to do with the look of it may have to do with the size or what it actually does if this if this was a business process then maybe how fast it can complete how many of a certain if it’s not a process let’s say if it’s a processor then how many transactions you can do for a minute per hour per day so what the system can do what it looks like these are all part of the capability requirements conditions again what the system must comply with and so we need to be able to extract from stakeholders or from documents the requirements that are conditions or capabilities that have to be met by the system or the product or the service or the result right in order to satisfy what the stakeholders are expecting from this project now requirements usually would be quantifiable and we need to document them in a way that we can validate later on so we consider them to be the quantified and documented needs wants and expectations of the sponsor or the stakeholders so just to stress these points again there are project requirements and there are product requirements project requirements could be meeting a number of meetings you need to have project management reports that they need staff that they need to be on the project communication that needs to happen on the project whereas product product requirements would be referring to the technical specs of the end results now moving on this is the table that PMI gives us it includes the inputs tools techniques and outputs and in here you see that one of the key inputs is going to be your project charter that’s a key input the reason it’s an input is it has all of the high-level objectives goals and so on and the stakeholder register is going to have the list of the stakeholders that we’re going to go back to and meet with them in case not in case an instance is where there’s a business case already produced where they’ve studied the the initiative and they’ve looked at the cost and benefits and risks and so on that business case the outcome of it called the business case would have expectations listed in it and therefore it is also one of the start points when there are contracts agreements then those are also a reference point for us okay we will discuss this a little bit more on the next slide but I just want to show you this over here in the middle all of the techniques that we need to be familiar with don’t be deceived when you look at it and you know you see things such as data representation and you see interpersonal and team skills these are big sections that have several techniques in them and so you need to know the underlying techniques for example over here it says data gathering up at the top but you know it includes brainstorming focus groups and so on so each of these numbers you know you see this you look at it it looks like you know number one to eight but then underneath every one of these could be multiple techniques that you need to be familiar with which we will cover here there’s a very good chance that this video might be split into more than one part because it’s pretty long if I do it in one long run the end result is going to be a requirements document that’s what you see in the output this is a live document that would be updated every time we have new requirements and something called the traceability matrix which we will discuss later on all right so we already started discussing inputs I’m just gonna like maybe wrap up the inputs here just so we can go past it so the Charter this is the initial document that initiates the project names the p.m. and lists the high-level goals and objectives therefore it is the high level set of requirements that they want usually has the cost the budget sorry the cost and the timeline the scope and maybe some risks are listed in there and some key stakeholders are listed in this Charter that was discussed in the integration management knowledge area so you can always go back and read that or listen to the video related to that the project management plan that is listed here is not going to be complete at this point so you’re still collecting requirements at this stage there would be very little in the project management plan but if you recall from the previous video the previous process we have the scope management plan here we had the requirements management plan and if you did this in sequence you probably would have a stakeholder engagement plan at this point but that we only cover in stakeholder management knowledge area later on but in the normal sequence of a project you would have gone from charter to stakeholders so you would have done the stakeholder engagement plan and then you go into collecting requirements so before collecting requirements you do the scope management plan and the requirements management plan those are technically the only things that you’re going to see in the project management plan at this stage before you start collecting requirements I mentioned previously that you could have a business case where the initiative was studied for benefits and costs and risks this is to justify investing in it and putting any kind of money into it so that business case already sets out some scope expectations from the customer and you may want to refer to that business case agreements or contracts if you were a contractor then you probably have to avoid not probably you would have to abide by the contract terms and conditions and the set of requirements that are listed in the contract other documents that could be beneficial would be any assumptions that were made in writing up the project Charter or maybe when the business case was prepared if there was an assumption log then you may need to refer to that this an assumption is an expectation of the environment of the project and these the we base all our plans based on these assumptions so assuming for example that there are available vendors for a specific function to be developed in the solution means that we don’t have the requirement were not mandated to have the requirement to do this ourselves we can always outsource this portion of it so these assumptions play a huge role in how we plan our our checks so whenever we have assumptions we need to review those lessons learn from previous projects from the past from current ongoing projects these are gonna tell us things that would be beneficial for us to know so that we don’t repeat the same mistakes the last two here I want to expand a little bit on them Enterprise environmental factors these are the environment in which you are going to run the project in so the culture of the organization the mentality that they have are they supportive not do they have you know inner fighting between themselves that they are like power grabs power fights these could affect how well you’re going to engage with these stakeholders and you know could either make things simple or create problems for you in collecting information marketplace infrastructure personnel admin this is going to tell you about the bigger picture environment so if you are if you are going to run a project in an industry that is well understood that has a lot of information out there then that factor is going to help you a lot if you are working in a very unique niche type product and you’re trying to collect requirements then the marketplace isn’t going to offer a lot for you so understanding the environment in which you’re doing this and knowing what you can get out of that environment and how much information is available in that environment is going to make a difference the last one here organizational process assets these could be constraints on you so policies rules laws regulations business rules all of these things would would eventually become requirements for you you cannot avoid them so any law that says you must do this before you can do that that’s a requirement or if the company has its own policies all of its policies are essentially requirements for you you cannot do anything outside of that without prior approval so the procedures or policies or rules that the organization abides by our going to be most of the time mandatory on you in running your projects now besides that if they have this part of it which is you know the historical records right if they have a knowledge base if they have previous projects that are similar in nature you should be able to tap into those and collect requirements from them all right you should be able to look at previous similar projects and look at the requirements documentation and look at all changes that have happened risks and so on and that would be an excellent starting point for you to be able to get your requirements for that specific project now let’s start with the techniques for collecting requirements as it is throughout the pin book expert judgment is one of the tech tools that you will see throughout the pin book and the reason we have that is because in every step of project management you’ll you’ll always be able to tap into somebody’s expertise and in this case you might need someone who is familiar with business analysis which focuses heavily on collecting and managing and analyzing analyzing requirements so someone who is pretty good with eliciting requirements analyzing documenting these requirements or maybe someone who’s worked in a similar project before they’re probably familiar with how to do this and they probably familiar with a lot of their requirements associated with these types of projects if you are working and there are certain types of projects that are maybe a process-oriented or IT driven you might find that let’s say flowcharts someone who knows how to develop or write flowcharts someone who knows for example how to do entity relationship diagrams class diagrams data flow diagrams state diagrams and so on these are highly technical and we don’t really need them for PMP but if you know depending on what your project is you might need someone who knows how to use some you know software like Visio for example is useful diagramming and when you diagram when you create any of these diagrams you’re kind of confirming or validating the requirements so someone who’s familiar with these would be excellent facilitation if you’re not the type that knows how to manage a workshop keep it in check you know in order then you might need the help of somebody else who can do this workshops focus groups brainstorming sessions even interviews you might need someone who can guide that activity and make sure that it runs according to plan so that’s why you see if it’s dilatation here conflict management comes in handy where you see discrepancies or maybe conflicting information people giving you different requirements or maybe people don’t agree on a set of requirements then you might need to tap into your conflict management skills in order to resolve the issue that is on hand for the set of the require for the requirements that you’re trying to resolve all right moving forward we start with the data gathering techniques and the first one that you see there is brainstorming a brainstorming we all do brainstorming but a lot of people don’t really differentiate between brainstorming and workshops brainstorming is like a workshop except that we don’t allow for any arguments or discussions of the requirements instead what we allow for is a three flow of ideas and requirements so in a brainstorming session to collect requirements we would have an agenda set of topics or even components that we want to get requirements on we would invite people that are relevant to that topic and they will sit there and they will give us ideas or requirements we will just document these things but we will not allow for people to discuss or argue or shoot down or whatever that can be held back for later when we do the workshop so maybe you want to collect the requirements in a brainstorming session take a break then come back and do a workshop where people can discuss their requirements that were collected so that’s the key thing about brainstorming is that it is intended to generate and collect multiple ideas without stopping anyone and without analyzing much alright the next one is interviews and these are frequently done by us we go meet with the stakeholders typically in their own environment in their own office and we ask them questions and we try to clarify stuff so I want to add here that there are two types of interviews that we do they’re structured interviews and there’s unstructured interviews if you’re meeting with someone who’s an expert in a specific field you’re most like you would have a set of questions that you would have prepared and you want to go there sit with them and ask them all these questions these are called structured interviews because you have a structured list of questions that you want to get through now if you’re meeting with someone who is let’s say a senior manager and you want to discuss the goals and objectives of the project then you probably don’t have much in terms of questions that are ready and it is called unstructured because you just started out with the goals and objectives and you’re just going through you just having a discussion and you’re hoping that somewhere in the discussion information is coming out that is beneficial to you for the project so that’s what any of you is our focus groups these are like workshops but they happen for small groups it’s called focus groups for a reason the group is focused on a specific discipline or type of work or they come from a specific department or unit so for example you want to meet with just operations and sit with them and get their point of view or set of requirements for operational purposes and then later on you’ll have another focus group where it let’s say facilities facility management and facility management the people in it would be from facility management they would discuss their own requirements focus groups are allow you to get good information fast and you can sort through the requirements not like rain storming you can actually sort through it but you can expect less conflict less arguments less you know heated discussions as you would in a workshop so we do focus groups for that purpose we can also do questionnaires and surveys questionnaires and surveys are similar in the sense that you are asking people to give you feedback but we tend to do surveys for very large groups where we put a set of questions and and maybe four or five answers to every question and people get to choose from these answers the trick here or maybe the effort here is to know what questions you want to ask and for every question what are the possible answers so it does take some effort to put this together plus then you’ve got a coordinate this you’re going to make sure it gets to the people that you want and that they that they are aware of it and they respond and then you collate all the information and then you know for every question what percentage shows a specific answer and that’s going to give you an idea of what the stakeholders are thinking so survey is useful for very large groups can give you a very good idea of what they’re what they prefer what they think and so on on the left-hand side here you see questionnaires questionnaires a group force I mean are good for a smaller group of people so if you had five people or less you can even do open-ended questionnaires so I would you know selectively use this with maybe the very senior manager so asking questions such as what features do we want in the next release you know that’s gonna open a can of worms you know they’re gonna give you a list of requirements and expectations so that you can only do with a small refined group of people that are major decision makers I wouldn’t do this for a law for a large number of people because you know you cannot you’ll not be able to manage it plus maybe all of their requirements are not really relevant and they may not be the ones who make the decision for a larger group let’s say more than five people I would use a closed a closed questionnaire or a closed-ended question here where I would ask them do you want for example translation into Chinese yes/no so you want that kind of an answer yes No so it’s just one answer that’s what you get with a closed-ended question here open-ended questionnaires would be like who should we target on the next marketing campaign and you’re just leaving it wide open so only use open-ended question is for a very small group of people a hand handful and maybe close ended question is for maybe 5 to 15 people beyond that I would say you know stick with surveys and that would be the better approach to follow all right next technique that we want to discuss is benchmarking benchmarking refers to comparing your own product or process or practice to those of comparable organizations that know how to do it well now the comparable organizations can be within your own company can be outside of your own company they can also be within your industry or outside of your industry so it is not unusual for a hospital to compare with a hotel for its own patient experience versus guest experience there’s a lot of similarities there customer service for example can be replicated against multiple industries so we want to compare against those who do it best so those who have the best practices being used and generate ideas that we can then maybe evaluate for whether we can use in our own project and that would be it’s not it wouldn’t be a bad idea to start your requirements gathering using benchmarking document analysis is another technique that we have to use and we probably use it heavily if you are in a contract then the contract terms and conditions need to be reviewed and that’s why you see agreements here we will need to review the terms of the agreement and make sure that you know anything that is mandated on us is listed as a requirement we have to comply with it business plans business cases so on they have they have expectations listed in them that we can extract and convert into a requirements business processes interfaces business rules current process flows all of these that are documented for example operational excellence flowcharts things that you can get from a center of excellence business rules business policies you review them technical specs from a supplier you got to review them historical documents you review these and you try to see where there are requirements that you can extract from them for your own project this time around now this one decision-making kind of falls out of place because we’re still talking about techniques here but we’ll cover it anyways whenever you have disagreement on a set of requirements you may need to vote it so for example you have a disagreement on let’s say you’re releasing the next the next iPhone or Samsung phone and you’re trying to decide on the cameras so some are saying we should have 3d camera others are saying no we should have a camera in the front camera in the back someone is saying no two cameras in the front two in the back and so you don’t really have one requirement and you want to make sure you want to get to some sort of agreement so you put it to a vote when everybody agrees we call that Mitch we call that unanimity that means it’s unanimous everyone is on board everyone thinks this is how we should go about it sometimes you don’t have everybody agreeing but you have more than half that agree and so that’s considered the majority but then sometimes you don’t have even the half that agree and that’s when you have plurality plurality is a term you need to remember because you’re probably not used to it but let’s say out of ten people that you asked to vote on the camera requirement you have three three of them that agreed and the others all had separate opinions like two one two and so on but you don’t have any group that is bigger than three that agreed on the requirements in that case you would go the plurality which is the three people that agreed and that would be the requirement that would be approved in some instances you would find that autocratic or dictatorship decision-making is done and that’s when maybe the boss or the CEO or others or director says well this is how we’re going to do it and they don’t really listen to the rest of the votes they just make the decision on behalf of everybody else it’s dictatorship but sometimes it’s required when we have too much of a disagreement within the group the next technique and decision making here is multi-criteria decision analysis in multi-criteria decision analysis we have several options so you see we have option a over here we have option B we have options C I don’t think we’re going to use this too much for requirements but we’re probably gonna use it for designs or maybe functions or features that include tons maybe they include several requirements in them so we call them designs so we’re choosing between this that or the other and we’re trying to evaluate which one is better we probably have done this in our own lives maybe it should your rent should you buy what are the benefits or maybe what matters to you should you stay here for a job or should you take this job or the other and you let your compare the salaries and then but you also say well this one is close to home or maybe this one is in my field or my domain of experience and so you find that there are different criteria that matter to you so what we do in multi-criteria decision analysis is that we list all of the criteria on here and you can see here we have cost time and maybe a few other criteria we have six criteria doesn’t have to be six but in this example we have six and you see that they have different weightages for the criteria so this column here listed or the wait age and you see that the highest weight is put on criteria 6 which has 28% down here in the bottom so 28% of the decision is tied to criteria 6 and after that 22 percent goes to criteria for time is almost irrelevant because only carries 2% but then we look at every option and we see how much it meets every one of these criteria and we score based on that percentage so for example option a let me remove let me remove all of the writings on this you see that option a fully meets on the cost criteria so it gets the full 14 percent but only meets 50% on criteria for so it doesn’t really get the full 22 percent gets half of that gets 11 percent so based on that you see it gets 11.2% here the total that option it gets is 60.9 option B get sixty three point seven four then option C gets seventy and therefore we want to go with option C you don’t really need to know the math too much here although I would recommend that you do it you don’t need to know it for this section but you do need to know it someplace else so but that’s what it looks like right you’re comparing different options based on different weightages sometimes we refer to this as average weighted criteria but you can also call it multi-criteria decision analysis and we use this when we have requirements or a design of requirements that we are unsure of which one presents a better option and we need to decide the next one here is the affinity diagrams and although it’s called an affinity diagram is called a diagram it’s not really a diagram it’s done as an activity where everybody is given a post-it note or several post-it notes and we’re trying to come up with requirements and so you write one requirement per post-it note and then we go up to a whiteboard or a wall and then we tape we paste a post-it note based on what’s in it so for example I have one one requirement that I wrote on a post-it note for let’s say security right and I go put it on one side of the wall then the other requirement is about the interfaces so I put it on a different side of the wall so I may go and do there let me just mark on these so I put this here because this has to do with security I put that one it has to do with interfaces right and maybe I put another one down here that has to do with location requirement and then somebody else comes up with their own requirements and they try to match their post-it notes to your post-it notes and if they find something related to security they’re probably gonna put it right next to you next to that one and the reason is they are related to the same topic so we start to relate the post-it notes by topic and by the time everybody’s gone around and done this we have a nicely categorized set of requirements with every post-it note holding one requirement then later on we can sort through them and that helps us get the requirements for the project it’s a very nice exercise I’ve used it a lot and I’d highly recommend that you also try using that the next one we want to discuss is mind mapping in mind mapping you will take your start with your idea down here and then you start to branch it out okay you branch it out by subsets of the idea so let’s say we want to talk about the the looks of the ATM that we are rolling out we might talk about the color and that one branch will be the color the other could be the material external material and then there could be something about the material Giroux durability and maybe price and then a we have a requirement for each portion of it so it’s a way to branch out or maybe break down every component of the requirement into subcomponents and then analyzing each and then coming up with a requirement for every one of these by the time you finish mind mapping this it looks like you know it looks like something nice I mean it could look like a spider web over here but it could look like something really nice that you see on the right here and you can color it and so on to give it a flavor but it’s a good way to visualize all the different subsets of your solution I can take a solution like an airplane and break it down into for example the the engine and then the wings and then the cargo area the the pilots cockpit you know the entertainment system and so on you get the idea and then for every one of these there are different subsets that we need to get requirements for and it could be a good starting point to sort out your thoughts and identify requirements we talked about voting another word for voting is called nomination so nominal group technique is where we nominate certain requirements to be ranked higher so let’s say you ended up with 38 requirements and you don’t know you have limited time so you can only fit so many of them then we may want to vote where the priorities are so we we we vote you can vote in different ways but the idea is at the end you want to be able to rank all of the ideas from most important to least important and so on so this is what they call nominal group technique all right we’re almost done have some patience the next technique we want to cover is observation if you have an ongoing process that you’re trying to enhance then what you would have what you would do is you’d go around observe how people are doing their job see how they’re interfacing or engaging with the current solution and that would give you an idea of where enhancements are required you would understand where things are a must where people have options just by observing how they use that specific product and how to engage in that environment so that’s called observation we can also converse with these people talk with them ask them why they doing these things when you’re chatting and asking this is called active observation when you’re just standing on the side and just watching it’s called passive observation you’re just taking notes and you know determining that you know the technician has to do that they do this first and they do that next and that’s a way to collect requirements you could also use observation in construction if you want to check out the land before you do any work on it and you want to see how much traffic goes through it or how many people use that specific land maybe people are jogging in the morning so you want to see that and you do that by observation alright so that’s the technique to collect requirements facilitation I think we already talked about that’s mainly for workshops or focus groups the terms jad here jad refers to a joint application design this is where two teams or two companies are working together or partners are working together in jointly developing an application or you can have quality function design and so on user stories are heavily used by business analysts and this is where we sit with users and ask them how they’re going to work with how they’re going to use a system and then the user might say well as a frequent flyer I expect to have a discount code that allows me to get discounts on my next booking and so you take that as a requirement and then you know that is given to the the development team to analyze and figure out you know the level of effort required so facilitation mainly refers to workshops and related sessions where you need to make sure that all stakeholders are working nicely together so that you can collect requirements for your project I think we have a couple more context diagrams this is you putting something in context of its environment so if you’re looking at the location of a hotel for example you could look at where the entrance will be in where the parking will be and you can look at the road that leads into the hotel and you know within the context of the road and the environment you know where should the entrance to the parking be and that’s you’re putting something in context of its environment and you might get requirements out of that with regards to IT you can look at how you know a business system is going to be used by specific people how they will interact or engage with it and by looking at the texe of its usage some requirements will come up so that’s called a context diagram I think we can say finally here prototypes are used to create a sample of the final product so we create a mock up a test small version mini version or a small piece of the solution is demonstrated in order for us to understand if this meets our requirements or if we have additional requirements that we want to include so it helps us get early feedback on the requirements by providing a model of the expected outcome and these could be in the end either simulations photoshop’s could be 3d models 2d drawings but it allows people to experiment with it or see it and and it’s extremely beneficial when your stakeholder is not able to visualize and they seem to be incapable of giving you any requirements it helps to give them a visual and that’s where prototypes become beneficial so two types of prototypes that you can expect out there one shows functionality and so maybe you’re testing out a simple single function like the login function where you put some sample data and you test it out with no regard to what it looks like it’s just to test the function and that’s a functional prototype and then we also have visual prototypes these we use just to show you what it looks like without any functionality to it so we can use Photoshop and such to show you what the solution is going to look like now we come to the end of this you know we’ve collected all of these requirements where do we go with these requirements well it helps to have a requirements list and so the requirements documentation that we’re going to use here it’s it’s an excel sheet let me just move a couple of slides down you see here this is the requirements documentation it’s Excel and what you want to do is you want to you know if you want you can put an ID to some of these requirements so you have an ID this here would list the requirement maybe you could put additional technical specs here you could put the high-level requirement on the left maybe additional details here it’s really up to you how you want to list your requirements any basic excel sheet will do you just want a list of all of the requirements that you collected I personally like to categorize my requirements because we have different types and I may need to outsource one set of the requirements that I don’t usually handle as a company I can even do sub categorizing of the requirements and so on in addition I probably want to list who gave me that requirement so that’s the stakeholder that asked for the requirement keep their contact details handy if I’ve heard any kind of concerns that made them ask for the requirement or if you know if they voiced out any priority or attachment to that requirement then I want to list it there in the end you know I can add as many columns as I want here it’s really up to you I can you know even put a WBS or a phase and I can link the requirement to that I can link it to a business objective by the way that’s called traceability when you’re tracing the requirement to a source maybe to a rule to a contract term to a la policy or to a person or maybe to a suppliers recommendation that’s tracing backward to the source of the requirement and over here you see that I want to list whether this requirement was approved and I may also mark it you know for whether was approved for this release or next release so this is called a requirements document is actually it’s actually a little bit a little bit more than a requirements document it’s also a traceability matrix so later on here you see the term traceability matrix shows up and for me it is the same requirements document but it has all the information about the source of the requirement and where the requirement ended up in the final solution I want to link it to a piece of the WBS I want to link it to maybe some design aspect I want to to a test case something that proves that the requirement has been implemented so if you look at this chart provided by PMI you’ll see that I can link the requirement to maybe some business needs or goals I can link it to some objectives this is linking backwards to where I got this requirement from and then forward I can link this requirement to a WBS to show where it ended up under what part of the scope the design aspect or the maybe the test case that proves that that requirement has been implemented so that’s what traceability matrix does you can combine traceability matrix with the requirements document now when it comes to requirements there are different types it’s not like we’re going to list in that way we just list our requirements but one thing you want to note here and this is really important is that you don’t want to just collect all the technical requirements so a lot of people collect functional requirements like what should the system do yes we want those these are the technical requirements but that’s not all what about some specific stakeholder requirements maybe some stakeholders need to access the solution from home they have their own specific needs some some stakeholders need certain translations to be there ease-of-use accessibility type requirements these are stakeholder requirements we also want to get those requirements we also don’t want to forget about the business requirements like we don’t want to overspend we don’t want to take too long to implement the solution we want to make sure that it is scalable or not or that it connects to existing systems that it complies with certain rules that they have or it fits within their branding requirements so take what the business wants understand their high-level requirements take what some specific stakeholder stakeholders want understand the technical solution expectations even the non-functional requirements these are like the looks of the system not necessarily what the system does but what it looks like how fast how safe these are non-functional requirements you want to collect these and you also want to get the project requirements like the service level agreements key performance indicator acceptance criteria what does the organization or buyer or your management mandates on you as you work on this on the project sometimes there are confidentiality requirements there are performance requirements and those are needed so you also want to collect project requirements there’s also quality requirements like what sorts of tests need to be done does it require any kind of certification or validation you need to understand these requirements in order to maybe at least when the support of your stakeholders finally I want to talk about transition and readiness requirements these are needed whenever you are working on migrating a system from an existing one to maybe an updated version of it so let’s say so let’s say you have a CRM or ERP that you’re upgrading this would come in handy you would need to consider what happens you know at the point where you are migrating the system you want to make sure that it doesn’t shut down the current operation and that things remain safe so those are the transition requirements alright that’s all for now I’ll see you on the next process if you like this video please make sure to click the like button and share it with people who you feel would benefit from it thank you and see you on the next video bye bye
