In this section of the mastering business analysis requirements elicitation part of the course, we are going to look at 14 characteristics of good requirements. And you're also going to get a small homework assignment. So let's go ahead and dive right in and look at those 14 characteristics. The requirement should be goal oriented, concise, correct and grammar and terminology, clearly written, understandable, detailed, correct in substance necessary, verifiable, consistent, complete, modifiable, measurable and traceable and consistent with company standards. So let's go ahead and take a little deeper dive and look at each one of these. A goal oriented requirement is focused on outcomes.

So it's written in terms of function meaning what and doesn't specify how to perform the function. So you should not include or describe design or implementation information. So for example, you don't want to say that a user makes a selection by clicking on a radio button or selecting from a drop down list. A good requirement states that the user has to make a selection, but not how they're going to make that selection. goal oriented requirement example would be something like users will have the ability to select from the following payment types credit, debit and check. So we're not saying how they're going to make that selection.

If there'll be a drop down list box that has credit debit and check to select from, we're not stating that we're just saying that we want our users to have the ability to select one of those options. Next, we have concise, good requirements. Documentation doesn't waste words, right? There's no room for fluff and requirements. You don't want to add things just for the sake of adding them and making them look bigger, we actually want them to look smaller. We want them to be concise.

So keep sentences and paragraphs shortened to the point. Don't include jargon flowery language unnecessary adjectives stay exactly what the new or enhanced functionality is that's desired. Leave no room for misinterpretation. Use crisp and definitive language and present only one requirement per statement or paragraph. They should be correct in grammar and terminology. You want to use proper grammar.

You want to use proper industry, business or project terminology. You should not include technical terms that are not generally understood, unless you're going to put them into a glossary. Sometimes it's necessary, especially if you're working on a technical project, that you have to include technical terminology, but you should not assume that everybody reviewing your documentation has the same understanding or knows what those technical terms mean. So you should always include a glossary. You want to make sure sure that you are using the right structure and words in order to create those good requirements, they should be clearly written. Good requirements are easy to follow requirements are written as a complete sentence.

Not a bulleted list of buzzwords, acronyms or sound bites. If abbreviations are used, the first occurrence of the abbreviation should appear in parentheses immediately following the abbreviated term or phrase, and then you can just use the abbreviated term after that. So for example, if I were talking about the International Institute of business analysis in my documentation, I would spell that out first and then put in parentheses iba and then going forward in my documentation, I could just simply put iba statements have two components, a subject and a predicate. So for example, the subject is a user type or the system under discussion and the predicate is a condition action or an intended result. So look at it that way when you're writing your requirements, they should be understandable. A good requirement makes its meaning clear, right?

We don't want to use vague language we want to avoid jargon and unnecessary words don't use and or without clearly establishing what that order of operation is and what's happening when you say and or define terms with multiple meanings that are not clear on the glossary. And like I mentioned before, don't use vague language. Some examples of vague language would be words like optimum, easy, efficient, modular, adequate, instantaneous, right? I love that one. Instantaneous, expandable, minimum, fast, rapid, acceptable, flexible, improved, reasonable, General, any of those words are words like that are things that are leaving things up to interpretation to other people, right? My idea of instant taneous is going to be different than yours.

My idea of easy may be different than yours. So you want to make sure that you're not using vague language that can be interpreted one way by one person and another way by another person. Now let's take a look at detailed, good requirements have sufficient content. To achieve this characteristic, you should record requirements at a consistent level of detail. Do not include things like to be determined to statements as placeholders. Do not use the terminology business as usual.

You want to say what that business is, right? They're saying there shouldn't be any change it should be business as usual, and find out what business as usual is what does that mean? An example of a requirement would be users will have the ability to select from the following payment types credit debit and chat. a better example of that would be users will be required to select from the following payment types credit debit and check so the difference between will have the option ability to and will be required to, to a developer means that now they have to write the code to force a user to make one of those selections, rather than saying they have the option of making the selection. So when you say they have the ability to it's like saying they have the option to so you want to make sure you're not using language like that can be misinterpreted.

I want to say something about that to determine thing too. So when I say don't include to be determined statements as placeholders, if you are in a requirement session, and you ask somebody a question, and that person responds back and says, You know what, I'm not really sure. I don't know about that. But I know Sally knows about it. I will get with Sally and get back to you on that. Then you can put a note in your notes, right and even in the meeting minutes or documentation that you send out.

That does say to be determined Susan is getting with Sally will update by and you want to get a date from Susan when she's going to get that information from Sally. Put that in there as the placeholder, knowing that you're going to update that when you get the information, you should never complete requirements documentation with anything that is still a TBD in it. It's okay while you're going through the initial process, but you just want to make sure you clean all those up, they should be correct in substance. Good requirements represent faithfully what the stakeholders expressed, right? So you want it to be correct. You want it to be accurate in what they told you.

And you also want to resolve any discrepancies between points of view. So if you have one stakeholder with one point of view, and one with another specifically related to the same requirement, you don't want to leave that hanging out there. You want to get that resolved and figure out exactly where are we going to go with this. They also of course, are necessary. So a good set of requirements is really minimal. You only want to define requirements that are necessary to the system where the application so for example, if a requirement were to be removed or deleted There should be a deficiency there should be a hole there, there should be something missing that has to be there, right?

If you have a requirement that you can pull out and it doesn't affect anything, then you really need to look at it and say, Is this really a requirement? Or is this just maybe additional information that would be good as a detail for another requirement? Or is it truly a requirement? You also want to avoid overlapping requirements and avoid escape clauses. So escape clauses in requirements are things like if, but, when, except, unless, although any of those types of terms will tell you that it means that there could be something else right. So if you see that, that it may be that there are two requirements together, there may be some more analysis that needs to be done around that to see if we need to break that out further.

They also should be verifiable. For good requirements. It's absolutely clear how to determine whether The implementation meets the need related to that requirement. So you want to make the requirements physically and functionally testable. The requirements should be able to be verified through inspection, analysis, demonstration, or even software testing. If it is an actual software solution, then obviously, you would do testing to verify that you don't want to express suggestions of possibility.

So words like may might, should, ought, could, perhaps, probably, those are suggestions of possibilities, not definitive things, right. So we don't want to use that language. You also want to avoid wishful thinking. wishful terms include things like 100% reliable, you can't really say that something's 100% reliable. So that is a wishful thinking term. Things like safe you All failures, guaranteed, fully upgradeable or able to run on all platforms, really all platforms or all platforms known as of today, and then specify what those are, right?

Because there's always new platforms, there's always new technology being developed, you can never say that. It's literally all platforms. You also wouldn't want to say that when talking about that. 100% reliable, right? To me 100% reliable might mean that there's never going to be any downtime, the application is going to be available 24, seven 365 days a week, and I'll never get any errors. Is that really feasible to say that it's not, but that's my interpretation of 100% reliable, so when you say that you're leaving it up to other people to interpret it, in how they mean it.

You also want to avoid words like etc, and so on and avoid relative terms such As like similar resembling, again, any of those things can mean one thing to somebody else you want to be clear and specific in the requirements so that you can make sure that when they're testing it, they're not having to say okay, this is like this. So when I tested that this was the outcome. So that means I should get the same outcome. It may not actually mean that but when you use that term like that's what it's saying to people. So an example of a non verifiable requirement would be, users will be required to select payment types such as credit, debit, etc. A verifiable example is users will be required to select from the following payment types credit, debit, check and PayPal.

We're not using the term etc. Or things specifically which ones they should be able to use so that there is a specific selection made and can be verified during the testing process. Consistent good requirements make sense taken as a group and they don't conflict with each other. Let's take a look at an example of a case study around consistency. So the context of this is, the purpose of the project is to create an attractive, user friendly prototype for a virtual archive. So a virtual framework for virtual items or collection groups within a larger collection of research materials.

So in other words, look at it as maybe like an electronic library, right where we've got all of this information stored. So the first requirement is around item retrieval. And the requirement states This option allows a user to retrieve items in any format. First of all, that's vague, and because it's vague, it's now left the door open for a conflict. So now our second requirement comes in, and it says that there won't be any file conversion, file conversion should not be supported is our requirement. So now as the VA, we're identifying a conflict here between these two requirements.

We might notice the possibility of a conflict because in one requirement, we're saying any format and in the other, we're saying file conversion won't be supported. So if file conversion won't be supported, how can we say any format? At this point, you would talk to the development team? And they would confirm that, yes, this is a conflict. Sometimes you need other people to assist you in determining, is this really a conflict? You might look at something and think it's a conflict, but you're not 100%?

Sure. And it's completely okay to talk that out with the other people on the project team and see if they're in agreement with that as well. So now you and the development team would probably work together to come up with some solutions that you could present to the business team or the business sponsors and stakeholders about how we might be able to resolve this conflict. We might be able to offer supporting file conversions for all major types and then increase the budget for the project. Support file. versions for a limited set of formats such as PDF RTF and dot docx, and increase the budget for the project, we may add the requirement, a separate version of each item one for every format required must be submitted to the system when a new item is added.

Or we may say that will only support the retrieval of items and formats that are already available. So let's assume that we presented these options and the business chose to go with option D. Also, because the technical team said that they felt that that was the best solution and it's completely okay to give a recommendation right to the business. Now, if they came back and said, No, I want to do option B, then Okay, you go with option B. But the point is you present some solutions so that they are able to kind of think through that and decide which do we feel from the business perspective is the right solution for us. Next, we have complete good requirements contain all relevant information. Such as all needs and wants expressed by the stakeholders, and the necessary information to communicate the desired end state.

And they also contain critical assumptions. So let's take a look at an example of a complete requirement that has a critical assumption. So our earlier requirement example was users will be required to select from the following payment types credit debit and check. When we add in a critical assumption, we would say payments accepted by users of the ABC application will be sent to a merchant payment processing system to complete the payment process. So we've got our requirement around payment, right, we want them to be able to select payment types. We're not saying that we take that out and we don't say any more that they can do that.

But we also want to have a requirement that says that the payments that we are accepting are being sent home merchant payment processing system to complete the payment process, because we can accept payments all day long. But if nothing happens, to actually get that money from one bank account to another or from one credit card company to a bank account and nothing happens with it. Right? It's like we didn't take that payment. So those are things that need to be taken into consideration. And if we're not going to implement within the application a way to process the payments, we want to make sure it's clear that we actually need to have some sort of connection to a system like that that's going to take care of that.

Next we have modifiable. A good requirement list is a living document. It's organized such that requirements can be added, changed or deleted without compromising the integrity of the whole document. You want your requirements document laid out in a way that allows for changes with minimal disruption to the document as a whole. You don't want to have to go back and change an entire section in your document because you took out one thing or changed one thing. So make sure that your requirements are laid out in a way that it's easy to modify them without having to change Change your complete documentation anytime you might make a change to one, they should also be measurable and traceable.

Good requirements are related to objectives each other and implementation artifacts. So, in a good requirement space, all requirements are related to a measurable objective. All requirements are uniquely numbered. The origin of each requirement is clear, the requirement is backward and forward traceable, so you can trace it back to an item within the scope. And you can also trace it forward once the documentation is created down the line to high level design, low level design test scripts all of that there should be tracing to each requirement is traceable to a business need to be delivered by the system or application. Right.

So again, we don't want unnecessary requirements, we want to be able to trace them specifically back to the needs within the scope. And each requirement is mapped to a test document in the acceptance criteria. So again, that tracing forward along with the backward. So an example of a measurable and traceable requirement. Let's take a look at this we had our earlier example of users will be required to select from the following payment types. This can be tracked back to a high level requirement, such as customer service reps will have the ability to take payments via phone.

Now, we would also probably be able to trace other requirements back to this high level requirement. It's not a one for one thing, so I want to make sure that that's clear that you would probably trace many more detailed requirements up to a high level requirements. And again, we want them to be consistent with standards so good requirements adhere to local customs and company standards, and they follow applicable templates and style guides that your organization uses. Now homework assignment, you're going to get five requirements that I would like you to know take what characteristics are lacking from each of them. And then rewrite them to be more effective based on your learning in this training