A last method of artifact driven elicitation is knowledge reuse. Systems are rarely conceived from scratch. Requirements, engineers and stakeholders tend to reuse knowledge from past experience with other systems that are related to, well, what they know. Such knowledge may refer to the host organization, to the domain in which the problem is rooted or to the kind of problems that were experienced with similar systems. May also relate to the kind of requirements that need to be considered for addressing such problems. As we gain knowledge we can transpose our systems. Transposition can be achieved through mechanisms like looking for opportunities and instantiation, specialization and feature inheritance. We can also try to reformat the vocabulary from the old system into the target system. And we'll see some examples of this through this lesson. Once you've retrieved existing information and transform that information from the existing system to the new system, you should then validate the result and adapt it if necessary. And then integrate. Integration is always the fun part. Adaptation and integration may require further elicitation and like everything else we have talked about in this lesson, you should be doing this in an iterative matter. Knowledge about similar organizations, domains and problem worlds helps us to reuse requirements, reuse assumptions, reuse domain properties and more. There are different types of reuse depending on the domain properties. Requirements taxonomies exist from many different domains to help us with our identification. For example, to thoroughly think about the needed nonfunctional requirements in the system. Consider this nonfunctional requirements taxonomy that you see here. Nonfunctional requirements are the ities of our work. Things like security, usability, so on and so forth. They define the way that the software should be, will satisfy the functional requirements. Or it also gives some ideas about the way that it should be developed. For example, the diary constraints of a participant may not be disclosed to any other invited participant. That's a pretty loose example. But there are a wide range of such constraints that make it helpful to classify them into a taxonomy. Taxonomies list specific classes to help us then characterize precisely for the product that we need. They help us think of corresponding classes that might usually be overlooked. Note that this example right here is only a subset of a full taxonomy. For each node, well actually, for each leaf node in an available requirements taxonomy, ask yourself, is there some requirement from this class that's in my system? In our meeting scheduler project example, we might look at all points in the system where responses are required in reaction to some kind of input stimuli. One example there would be the average response time. In thinking about response times, you might elicit assumptions about if there are particular average response times for getting the constraints from the participants. Are there required or desired response times for, once we have the constraints, for getting the meeting scheduled? Once the meeting's scheduled, what about when the notification for the meeting is given? Each of these questions focuses on the nonfunctional requirement of time. By focusing on these sorts of questions early, you may also think of more functional requirements and also some alternatives for those requirements. For example, if we want to get a meeting notification quickly, first, getting a meeting notification quickly is, yes, it is a requirement. But what does it mean? It's not measurable. If you need it very quickly, say in five minutes, the notification might be sent by email, and might be sent by text. If you have a little bit of extra time to get the meeting notification out, you could leave that out of the system pretty much entirely by you running down the hall. It all depends. Focusing on non functional requirements early, allows us to consider alternatives. Requirements taxonomies can be expanded with domain-independent knowledge, and also, domain-dependent knowledge. Thinking on how specific requirements classes can be refined, and see how those requirements classes could conflict with each other. Conflicts will happen, these are just big models. But they're helpful in making us think.
