In the previous lesson, we talked about the qualities of a good requirement. Now, let's dig into the specifics of the language you should, and should not use, when writing your requirements. After this video, you'll be able to describe the basic language elements used to construct a good requirement. You also will be able to list common pitfalls in writing requirements, and how to avoid them, and we'll end by going over three sample syntaxes, that you can use to write good requirements. And again, whether you're writing requirements or agile user stories, I think you'll find the information here equally applicable. In larger context of things, remember that we are in the analysis phase, and we're talking about writing requirements, which is one of the primary functions of a business analyst. Future lessons will go into things, such as requirements gathering methods, diagrams, and other documentation that the business analyst prepares during analysis phase. Let's talk about requirements and the language you should use when writing requirements. Requirements that are mandatory and binding, shall use 'shall'. The most of your requirements will probably fit into this category, so examples are, the system shall provide a way for the user to create an invoice. That's a simple requirement, that unambiguously states that this needs to be part of the system. Sometimes there is a preference or a goal or some desired functionality but it's non-mandatory, in this case you can use the word 'should', in your requirement. Other things in your requirements document might be suggestions or allowances, in this case you can use the word 'may', so the system may provide a means for the user to create an invoice, if the functionality is not required. Non-requirements, such as descriptive text, use verbs, such as 'are, 'is', and 'was'. It is best to avoid using the term 'must', because this might lead to interpretation as a requirement. It's not that this language doesn't have a place in our requirements document, it's just that we want to avoid mistaking descriptive text, for an actual requirement of the system. It's useful if we phrase our requirements in terms of what the system should do, instead of negative requirements, such as what the system should prohibit or what the system does not need to do. We should use active voice. Avoid using passive language, such as 'shall be able to select'. It's best to avoid superlatives because these aren't measurable, there's no way to know whether or not we have the best system or the best user interface, and then therefore it's not testable. So, there's no way to verify that it would meet requirement, with that kind of language. Avoid subjective language such as user-friendly, easy to use, cost effective, and I've already given an example of a requirement in my career where this happened. Finally, vague pronoun, such as it, this, and that, instead replace the pronoun with the proper noun, that it refers to. Ambiguous adverbs and adjectives, almost, always, significant, minimal, again these are not measurable, and we should avoid use of these in our requirements, open-ended, non verifiable terms, such as being able to provide support for, 'but not limited to', 'as a minimum', we should avoid these, as well as comparative phrases such as, 'better than' or 'higher-quality'. Loopholes, such as 'if possible', because you can always just determine that it's not possible, and not implement that requirement or 'as applicable'. Finally, incomplete references, such as specifying the reference, with its date and version number, not specifying just the applicable parts of the reference, to restrict verification work, there are often many versions of documents out there, and we need to be clear about what version of a particular document we're referring to. Finally, avoid negative statements, such as statements of system capability not to be provided. Those are things that you should avoid, now let's look at what you should do. I'm going to give you three sample syntaxes that ISO recommends, as part of their requirements documentation. The first example of how to construct a good requirement, follows this pattern. It starts with some kind of condition, and then a subject takes an action on object, subject to some constraint. So for example, this would be in more of a real time systems category, when signal x is received, the system shall set the signal x received bit within two seconds. Another variant of syntax would be, starting with the condition, you can then move to an action or constraint, and then a value. So, at sea state one, the radar system shall detect targets, at ranges out to 100 nautical miles. Finally, more of a business oriented example, the subject action value. The invoice system shall display pending customer invoices in ascending order, in which the invoices are to be paid. That concludes our look at writing good requirements, next we'll look at how to categorize requirements into functional and nonfunctional requirements, and why that's important.
