Learn from a certified business analyst the best practices in writing good requirements statements that can help your project deliver successfully.
Hello and welcome to my video on how to write requirements statements this is a skill that is needed by just about everybody in the professional field but mostly by project managers and business analysts I’ve seen some very bad requirement statements out there and they range from just one word like you know blue to a whole description of what the end solution is so they might describe a truck with what it needs to have inside and what the outside should look like or they could be describing something like a system something you know I’ve seen requirements that say supports 500 users 24 hours a day with no drop in volume something like that so these are really bad requirements either because they are just one word things that don’t mean much to anyone looking from the outside or there are a full paragraph your paragraph describing just about everything that you want in this one solution now for someone who works with you day in day out they might be able to figure you out and understand what you want but you know they might do a lot of follow-up questions but you don’t realize that but that’s because they want to clarify it and be a lot more specific so what this video is going to do is show you how you’re supposed to write requirements documents sorry how you’re supposed to write requirements statements which will go inside requirements documents and these statements you will find would have a certain structure and certain quality attributes let’s start with the structure that these requirements need to have a good business requirement structure must contain specific information so for example let’s look at the following requirement the system must include the new company products now you might think this is a good requirement you know system having new company products but it is not very specific and it is not very measurable why well you know what system what company products there’s a lot of unknowns in this it can be improved by adding some specific information first of all we need to identify who wants this information who has the need this could be a sales person for example right what result are they trying to achieve it could be that they want access to information so they can show their customers and that information is the new company product when would they like this information typically for sales people if they want to be effective in their jobs they probably want this information as soon as possible and sooner than the general public finds out about it so this way they have the information beforehand so let’s qualify this and say one day prior to the new product launch now let’s rewrite the requirement with all the information that we just figured out the sales agent must have information about any new products one day prior to the product launch now if you look at the structure of this business requirement you can see that we figured out that the sales agent is the who the must have information about is what result we’re looking for any new products is the object of the requirement and one day prior to product launch is the qualifier by using a structure like this the statement now indicates who would like the information sorry who would like this requirement that’s the sales person what is the result they’re looking for that’s to have information what is the object the requirement addresses and that’s the new products what is the qualifier that is now measurable that would be the one day prior to product launch as a result you’ll see that this requirement is now clear less ambiguous and more measurable okay so now let’s go to the rest of what a requirement statement needs to have and these are the quality aspects of a good requirement I’ll go through them one by one first a requirement needs to be atonic and what that means is that it needs to be self contained and capable of capable of being understood independently of any other requirements or designs so if you say for example the wall must be 8 feet high that is very clear and we can measure 8 feet high on its own but let’s say you had said stated that the wall must be higher than the rest now you need to know what the rest are for you to be able to figure out how high the wall needs to be so it needs to be atomic in the sense that it can be understood on its own without having to compare with any other requirement the requirement must be complete as in the structure that we just described previously having all of the information and appropriate level of detail for the work to continue the requirement needs to be consistent that means it should not contradict or come into conflict with any other requirements it needs to be concise has no extraneous or unnecessary contents or things like it must be 8 feet high because we need to prevent so-and-so from crossing above we don’t need to know the whole story of why you need to have it 8 feet high requirements are one line items they don’t get mixed up with any others they don’t you don’t blend two requirements so for example you don’t state the hotel must be 5 it must be a five-star hotel that is 500 feet away from the office these are two separate requirements you need to split it into two requirements one that states it’s a 5-star Hotel and the other one that states is 500 feet from the office so it needs to be concise to the point and be very specific and have only one point to it so it’s a one liner item the requirement must also be feasible reasonable and possible can be done I don’t want to have a requirement statement that talks about something that can’t ever happen so for example dog must fly well unless you’re gonna add a little more to it that’s not a feasible requirement unambiguous that means it needs to be clear and understood and not going to be translated differently by different people must be testable you know in the sense that there’s got to be some metric or some number or some aspect of it that can be measured now there are a lot of quantitative ways of measuring or maybe there are qualitative requirements that are harder to measure so for example must be easy to use must be easy to use is kind of hard for people to measure but you could say for example an average person or maybe eight out of ten random users must be able to go through it in two minutes maybe that would qualify it as easy to use so it should be testable one way or another also a requirement must a requirement must be prioritize about in the sense that it must have a ranking relative to other requirements it can’t be forced upon you if it is forced upon you it’s a low quality requirement it is still a requirement but it’s a low quality requirement what you want is a requirement that can be prioritized and ranked against any other requirements it also finally needs to be understandable that means using common terminology of the audience the one who’s going to be reading this and putting the requirement into action so here we have it these are the qualities that a good requirement needs to have atomic complete consistent concise feasible unambiguous testable prioritized and understandable hope you like this video and if you liked it please give it a thumbs up and also if you feel somebody else could benefit from this kindly share with others and if you haven’t subscribed yet please subscribe and we hope to see you on the next video thank you
