Welcome to module three. In the last module, we addressed more of the rules we need to follow in order to develop good requirements statements. In particular, we looked at the rules that relate to the use of vague and superfluous words. In this module, we address more of those rules starting with some more rules about other words we should avoid when writing requirements, and in particular, we look at avoiding conjunctions unless we introduce a formal convention for logical conditions. We'll also discuss why we have to avoid unbounded statements and escape clauses. In the last presentation, we addressed the first few other rules that we need to follow in order to develop good requirements statements. In this presentation, we addressed more of those rules starting with some more rules of the terms that we should avoid when writing text-based requirements. We discussed in the last presentation a number of rules for avoiding vague words because their use leads to ambiguity. In that vine, we should also avoid the use of conjunctions. A conjunction is a word used to connect clauses in a sentence, or to connect terms inside a clause. So, conjunctions of words such as 'and', 'or', 'then', 'unless', 'but', 'however', 'whether', 'meanwhile', 'whereas', and 'otherwise'. It also would included this some rule phrases such as, 'as well as', 'but also', 'on the other hand' which are, otherwise is saying those conjunctions. We should also avoid the oblique symbol as we want to use it, and commonly in English, we want to use it as and/or because it's even worse than using all the conjunction at a time. It's not even clear what that construct means often, it could mean one of them, or both, or not. So, the presence of conjunctions in requirements statement usually indicates that there are multiple requirements, and each should be written in a separate statement. Aside from that, the words also create ambiguity. Let's look at some examples. So, the first reason for avoiding conjunctions is to ensure the requirements statements are singular. There are a number of ways to write in a single sentence, to encapsulate a single requirement. So for example, if we say, "The user_interface shall display the Location and Identity of the Lead_Vehicle", it's in fact stating two requirements through the use of the conjunction 'and', and we should split it. To say that the user_interface shall display the Location of the Lead_Vehicle, and it shall display the Identity of the Lead_Vehicle in two separate sentences. Of course, there are occasions where the two requirements are to be met at the same time- we call those simultaneous requirements. We use the word 'simultaneity' to relate to those two requirements being needed at the same time. In that case, we need to use a formal logical construct, and we'll discuss that shortly. Note also that the requirements must be split because the verification statement written for each requirement will also be different. For example, the requirement statement, "The vehicle should have a Maximum_Speed of and the Maximum_Range of, should be split into two requirements. One related to Maximum_Speed and the other to Maximum_Range. Because they are in fact, two requirements, but also because, the maximum range will be verified in a different manner to that that we use to verify the speed. The second reason we should avoid conjunctions is that persons almost always creates ambiguity. So for example, consider this requirement. "The Maintenance_Staff shall fertilise and spray weeds on the Grass_Area." Now we saw earlier that the presence of the conjunction results in two actions which warns us that there are in fact two requirements. However here, the ambiguity causes issues about how the word is splitted. So for example it could mean, that the maintenance staff should fertilise and then spray the weeds that are on the grass areas, or they should fertilise the grass areas, and then spray the weeds on the grass areas. Common sense would employ the latter, but in some cases, the interpretation is not so easy to come across. Similarly, the conjunction 'or' should be avoided because it often hides multiple requirements, but also because it often leads to ambiguity. For example, the requirement, "The system shall provide an audible or visible alarm," is ambiguous because it's a moot point whether the designer can choose which alarm to implement, or whether both alarms should exist but the operator can select one, or whether both exist and operate but the system passes its verification test if only one of the alarms alerts the operator. Despite the fact they introduce ambiguity as we mentioned earlier, there might be times when we need to state logical requirements that require us to use the conjunctions 'and' and 'or'. So, the conjunctions may be used in requirements statements when used in the context of logical of operators. In that case however, the terms are normally written in all capitals or italics to show that they are used as operators rather than as conjunctions. So we might write 'AND' in capitals or 'and' in italics, 'OR' in capitals or 'or' in italics. And so for example we might say, "The User_Interface shall display the Location AND Identity of Lead_Vehicle", employing that both have to be explained at the same tone. Now, that requirement needs rewrited. Notice that User_Interface shall display the Location and did it in the Lead_Vehicle. Actually it leaves the relationship between the location and the lead vehicle in a bias. What we could do, strictly speaking, is make sure that we are writing it carefully to say that the User_Interface shall display the Location of the Lead_Vehicle AND the Identity of the Lead_Vehicle. That may leads to a little ambiguity because it's not clear whether the "and" joins words, phrases, or clauses. To be absolutely sure that there's no ambiguity, a convention for logical conditions uses a formal structure to ensure that it's clear as to what elements of the requirement are joined by the AND or the OR. For example in this case, we could isolate the elements between curly brackets or square brackets so that it's clear in order these two statements that the conditions being joined are those inside the brackets. Further ambiguity is introduced with the use of phrases such as, 'and so on', 'et cetera', 'but not limited to'. As we saw before, if the authors of the requirement statement require all items in a list, each of those items must be specified explicitly. Use of phrases such as 'and so on' leads to ambiguity because it allows different interpretations as to which of the items is in such an open-ended list. Further, the requirement is not met until it has been verified for all elements in the list. If the list is incomplete (or emplied to be infinite), verification activities cannot be completed. So for example, "The System shall display the Account_Balance, the Account_Holder, and so on," has two problems. First, the list is potentially endless and the requirements need to be split because of the conjunction. So, more correctly, the system shall display the Account_Balance, the system shall display the Account_Holder, followed by any additional statements if there are other items to be displayed. In addition to being open-ended, requirements authors are often tempted to generalise, using such phrases as 'where possible', 'if practicable', 'if necessary,' 'as much as possible,' and 'where possible'. These are escape clauses which, in an acquirer-supplier relationship, may allow the supplier to have any excuse not to bother with such a requirement by simply stating that in their view, it wasn't possible, necessary, or practicable. In this presentation, we addressed more the rules we need to follow in order to develop good requirements statements. In the next presentation, we'll complete the discussion of things to avoid when writing good text-based requirements. So now you know more about requirements writing and why it's so important to get the requirements right before we go any further with the systems development. Once again, please get back to the presentation until you're comfortable. Then you can confirm that you absorb the material by completing the module quiz. In the next module, we'll complete our look at the rules regarding requirements by considering precision, units, ranges and tolerances, and cross references.
