Before we leave requirements, it's common to consider two additional aspects of requirements and requirements engineering. First, there is certain characteristics we desire from a well formed requirement, a good requirement we say. And second, we often upend to the requirement statement one or more attributes. And the purpose of doing that is to use those attributes to help us to manage the requirement statement itself, and the set of those requirement statements. But let's first look at the characteristics of a well formed requirement before we come back to consider its attributes. Desirably, to be useful, each requirement statement should exhibit all of the following characteristics. And the first is, to be Necessary. Now, of course, it seems to be quite obvious statement that the requirement must be necessary, otherwise we wouldn't have included it. But it's a good test for us to say, well, is this requirement actually necessary? It must be necessary if the system has to function in the desired way. It follows then, the requirement that isn't necessary can't be traced back to a higher level requirement or indeed be traced back to a higher need. So I just add that little simple test is this requirement necessary, allows us to understand whether the requirement really should be there or not. And that helps us regarding instincts like scope crew. The next characteristic is Singular. A requirement can't be a combination of two or more requirements. Remember we said a requirement is an agreed-to obligation, and for an obligation to be fair, it has to be singular. We have to say one thing. It also helps us then when we're testing it, et cetera to make sure that we're talking about a single thing. So, it's very important to make sure that requirements are singular. They simply apply to a single function, not to a combination of functions, and that means that the requirement is concise and it's clear. It follows that the requirement should also be correct. Again, that it is correct, as axiomatic, we need to know that, but this is a little test. We say, is this this requirement correct? Are we sure it's correct? Are we all sure it's correct? To make sure that we don't carry forward requirements that aren't real requirements or requirements that actually are misleading. And that brings us to the next characteristic, requirements should be Unambiguous. That is, everybody who reads it should all understand the same thing as they've read that requirement. Now, that's particularly difficult in languages like English where one statement can have a large number of meanings and every word has a considerable number of synonyms. And so it's very important to make sure that every future reader of this requirement will understand correctly what the requirement is communicating. The next characteristic is feasible. And again, that sounds obvious. But a little test before we continue on is if we say that, and we want the system to perform that function, is it actually feasible? That is, can we do it with existing technologies? Can we do it with existing skill sets? Can we do it with the existing manufacturing capabilities? And so on. And again, it's just that little test ensures that we don't go writing requirements that aren't in the end going to be able to be completed or manufactured or produced. As well as those, other characteristics include, well firstly appropriate to level. That is, that the requirement may even be all of the previous characteristics but being said at the wrong level. So we really oughtn't to be talking about sub system functions at the system level for example, because it's a system level statement and we're talking about the outside. The system as a black box, not the inside of the system. So we need to be very careful then to only say those things that are appropriate to the level when we're talking about an entity at that level. The next characteristic is complete. The requirement itself, now this is not the set of requirements, this is the individual requirement, needs to be complete. We say in English, that it shouldn't beg the question, that there shouldn't be things that are raised by reading it. You should be able to read the requirement and know exactly what it means. And that is, it should not need any further explanation. Then the requirement should conform. That means that each requirement must conform to a standard formal structure, probably as described by the organization or perhaps by some external standard. And that means that when we read it, because we read it always in the same way, in the same standard format, it means of course that requirements are therefore less ambiguous as a result. And last, as we said, not that long ago, requirements need to be verifiable. That is, we have written a verification statement. We need to be able to know how it is we propose to prove that the system meets or possesses this, this property that this requirements requires. Verification could be by one, or any number of means. But it's worth a while here before we continue. It's sort of like being feasible. If the requirement is feasible, what is the feasible verification method that goes along with it, because we have to pay for the function. We also have to pay for the verification method, and so the person who's writing the system specification has to know what those two things are. What is it we want and how it is we propose to know that we've got what we want at the other end. In addition to requirements characteristics, we use attributes to support analysis and management. And so, a requirement could be allocated a number of attributes. In fact, there could be many such attributes to, to a requirement sometimes, up to some 300. Here we only identify a small number which would be the major attributes. But you get the idea of the sorts of things that an organization might wish to attach to a requirement to allow that organization to manage that requirement better over the life of the system. The first, of course, is the unique identifier. Words that are general and long lists of words become difficult to manage. So, each requirement must have a separate unique number to identify the unique statement. And of course, you know, requirements database that generally tends to come for free, as you are allocated a key to the database. But the point is that, whichever way we manage them, we need a unique identifier. That number of course is also not terribly useful. So it helps to add to the number a short title. And that short title then, in three words, four words long, simply summarizes the requirement. It's not as useful as the requirement, obviously, but it is useful to refer to the requirement by its short title rather than reading out a number which doesn't seem to make sense or reading the long sentence every time. Each requirement also needs to have attached to it a priority. And that's important because later on, we'll talk about the idea of design space. That is that the designers can trade off weight for range, for burn rate, for leg room and so on, on a platform like an aircraft. If we don't understand which is more important to the customer, then it's very difficult to use that design space to design the system. So priority is a way which the originator of the requirement communicates to the designers, and how important each those aspects is to them. Now, it's not mandatory, but it's also very useful whilst writing the requirement to attach to the requirement some indication of risk. It could be a risk level, or could actually be a risk statement in some, in some, systems. That is when the writer of the requirement articulates it, they also have to think a little while about what risk is attached to that, and that goes back to as we were talking before about the feasibility of the requirement, and, and also the ability to verify. If we need to ever in the future discuss the requirement, we might need to go back to the source. Now it could be a standard, it could be a regulation. But it's also commonly of course, an individual or an organization, or a committee, or a workshop. Also molicitation process that gave us the requirement. And so we need to know where it came from in case we need to go back to discuss perhaps if two requirements conflict, for example. We might need to go back to reconcile that with the original sources. Another useful attribute, as we saw before, is a rationale. Some people would write a rationale statement. Others might include rationale in the attributes. I doubt that it matters really either way, but what's important again, as we said before, that we record the reason for the existence of the requirement. We also might want to record some history. Now again, of course, in a relational database the history is tracked generally by the database so it sort of comes for free. But we want like to know, when was this requirement raised? How often has it been changed? Have we deleted it? So where are the old requirements that we deleted? So, history is a really useful thing to help us understand how it's changed in the future. We also might like to know, as we saw before, and we'll talk again later about traceability. How does this requirement relate to other requirements? And so those relationships ought to be tracked as well. Again, it could be in the attributes or it could be part of the relational database in the modern requirements management system. And of course as I said before there can be up to some 300 requirements attached, so lots of other information could be included as an attribute of a requirement. We can the date of raising, the status, and is it currently being reviews, has it been accepted, was it rejected, any comments that are useful to subsequent designers are very useful things to include. And finally, it's often useful to add a type attribute, so the requirements can be seated in various logical groupings that are useful in their management. The type can be of any type really. Some organizations insist on having a structured series of types, of labels that can be attached. Others allow the type field to be open to allow people to add any number of types. But the value of the type field is to be able to record what sort of requirement this is. So it could a, a safety requirement, a security requirement, a training requirement and so on. The idea is that we get orders a lot in requirements databases. So if somebody says to us, so, where are all your safety requirements? Or, where are all your requirements that relate to standard xyz? It's very useful to be able to use the type field in a database, to say, well, let me print out all the safety requirements. And therefore search and print based on the type field safety, rather than have to go through and look and see which of the requirements might relate to safety, for example. And so there are any number of types and each organization would use a slightly different system. But whatever they use, type is a very useful attribute to attach to a requirement statement as part of a requirement expression. Finally, in this module, we make brief reference to what we call the emergent properties of a system. That is, we have to recognize that when we develop a system, it will have certain properties that are those possessed by the system as a whole. And that those properties may not have been obvious in any of the elements, or the interconnections as we built the system from the component, all the way up to the subsystem level. And those properties, therefore, only emerge once all the individual system elements have been integrated, and hence we call them emergent properties. Those properties are not obvious by looking at the elements or the sub systems. They are only possible when you look at the system as a whole, and perhaps even only possible when you're looking at the system as a whole as it interacts with its environment. That is as it's operating. There are many examples of emergent properties, and we don't really have time to deal with them properly here. We just point them out because firstly, there are lots of, of, there is maintainability, reliability, usability, security, safety and so on. All of these things are only obvious when the entire system is put back together. And secondly, it is possible that there is a property which emerges which is unexpected, and that's something that we need to be aware of. Many of these properties we do want and we expect and we design for. It is of course, possible for there to be an emerging property, which is undesired. If you want to keep an example in mind on the way through, perhaps the bicycle's one of the best examples, because if we looked at a bicycle itself and looked at all the sub-systems, we'd see wheels and frames and handlebars and so on. But if we stood it up, it would fall over. In fact, even if you put the rider on it, it falls over. It's not until the rider is on it, and is pedaling, moving forward, that the entire functionality of the system is obvious. And so that property of the system, which is really what we would call a bicycle, is an emergent property. It doesn't exist until all of the elements of the system are together, including the operator, and that all of those systems are interacting with their environment with gravity and, and so on, and the wind, until we can see the actual properties of the system. We're interested in emergent properties because they have to be defined top-down. They can't be obtained by specifying requirements for individual elements and then hoping that those properties will emerge as we combine those elements together. So for example, if we say the system must be safe, it's up to the designer to decide how the elements contribute to that safety. So that when all the elements are together, the entire system is safe. But it could be true that none of the individual elements themselves are safe, but the combination is. And so that emergent properties are very important thing, it has to be specified top down, and it has to be controlled by the designer as the system design continues. Of course, as I said before, we must also consider the possibility of the completed system exhibiting some emergent property that hadn't been considered as part of the original design. And in some cases may be undesirable, in the completed product. That is, we have to understand that when we are putting subsystems or elem, system elements together to interact, that some of those interactions may well be unforeseen. In this module, we've discussed requirements, the levels at which they exist, and the relationship between them at each of those levels. We looked at a number of definitions, and then finished with an introduction to requirements engineering. In the next module, we'll look in more detail at how to create, and how to validate a set of requirements.
