Possible lecture topics for Berry (for 16 May -- Early July) 1. Scope Determined (D) and Scope Determining (G) Requirements: A New Categorization of Functional Requirements Daniel M. Berry, Marcia Lucena, Victoria Sakhnini, and Abhishek Dhakla Context: Some believe that Requirements Engineering (RE) for a computer-based system (CBS) should be done up front, producing a complete requirements specification before any of the CBS's software (SW) is written. Problem: A common complaint is that (1) new requirements never stop coming; so upfront RE goes on forever with an ever growing scope. However, data show that (2) the cost to modify written SW to include a new requirement is at least 10 times the cost of writing the SW with the requirement included from the start; so upfront RE saves development costs, particularly if the new requirement is one that was needed to prevent a failure of the implementation of a requirement already included in the scope. The scope of a CBS is the set of requirements that drive its implementation. Hypothesis: We believe that both (1) and (2) are correct, but each is about a different category of requirements, (1) scope determininG (G) or (2) scope determineD (D), respectively. Past Work: Reexamination of the reported data of some past case studies through the lens of these categories indicates that when a project failed, a large number of its defects were due to missing D requirements, and when a project succeeded, the project focused its RE on finding all of its D requirements. Conclusions: The overall aim of the future research is to empirically show that focusing RE for a chosen scope, including for a sprint in an agile development, on finding all and only the D requirements for the scope, while deferring any G requirements to later releases or sprints, allows upfront RE (1) that does not go on forever, and (2) that discovers all requirements whose addition after implementation would be wastefully expensive, wasteful because these requirements are discoverable during RE if enough time is devoted to looking for them. 2. Requirements for Monitoring Inattention of the Responsible Human in an Autonomous Vehicle: The Recall and Precision Tradeoff Johnathan DiMatteo, Daniel M. Berry, and Krzysztof Czarnecki Recent fatal accidents with partially autonomous vehicles (AVs) show that the responsible human in a vehicle (RHV) can become inattentive enough not to be able to take over driving the vehicle when it gets into a situation that its driving automation system is not able to handle. Studies show that as the level of automation of an AV increases, the tendency for the RHV to become inattentive grows. To counteract this tendency, an AV needs to monitor its RHV for inattention and when inattention is detected, to somehow notify the RHV to pay attention. Requirements engineering for the monitoring software needs to trade off false positives (FPs) and false negatives (FNs) (or recall and precision) in detecting inattention. An FN (low recall) is bad because it represents not detecting an inattentive RHV. An FP (low precision) is bad because it leads to notifying the RHV too frequently, to the RHVC's ignoring notifications, and thus to degraded effectiveness of notification. The literature shows that most researchers just assume that FPs and FNs (recall and precision) are equally bad and weight them the same in any tradeoff. However, if, as for aircraft pilots, notification techniques can be found whose effectiveness do not degrade even with frequent repetition, then many FPs (low precision) can be tolerated in an effort to reduce the FNs (increase the recall) in detecting inattention, and thus, to improve safety. 3. Requirements Engineering for Artificial Intelligence: What Is a Requirements Specification for an Artificial Intelligence? Daniel Berry Context: This article concerns requirements for an artificial intelligence (AI) that does a non-algorithmic task that requires real intelligence. Problem: The literature and practice of AI development does not clarify what is a requirements specification (RS) of an AI that allows determining whether an implementation of the AI is correct. Principal ideas: This article shows how (1) measures used to evaluate an AI, (2) criteria for acceptable values of these measures, and (3) information about the AI's context that inform the criteria and tradeoffs in these measures, collectively constitute an RS of the AI. Contribution: This article shows two related examples of how such an RS can be used and lists some open questions that will be the subject of future work. 4. The Prehistory and History of RE as Seen by Me Daniel Berry This talk traces in parallel, (1) my life in computing from when I built a small relay adder in 1963 and learned to program in 1965 through to my present deep involvement in the field of Requirements Engineering (RE) and (2) the prehistory and history of the field of RE, from when the oldest of its people were in Programming Languages, through the birth of Software Engineering, through the birth of RE, until the present day. The two time lines form a twin peaks. My experiences were telling me all along that RE, even before it had a name, is where the action is, and others in the field were undergoing similar experiences and coming to similar conclusions, and we bullt off each other. The talk concludes by my questioning some of RE's basic assumptions. 5. How Important is Ambiguity Detection? Cristina Ribeiro and Daniel Berry The research into detection and avoiding ambiguity in requirements specifications has been assuming that the danger that ambiguous requirements specifications would be interpreted differently by different developers is significant. Cristina and others have been doing research to test this assumption. Indications are that amibiguity is not really a problem in practice. 6. Importance of Ignorance Ali Niknafs and Daniel Berry It has been assumed that to effectively elicit and invent requirements for systems to be developed, the requirements analysts need to be knowledgeable about the domain of the system. However, there is evidence that people who are ignorant of this domain expose tacit assumptions and think out of the box to come up with better invented requirements. Ali and others have conducted empirical studies that show that domain ignorance IS helpful for some SE and some RE tasks. 7. EPMcreate & POEPMcreate and Optimal Team Size for Creativity Luisa Mich, Vicky Sakhnini, and Daniel Berry EPMcreate is a new creativity enhancement technique and POEPMcreate is an optimization of EPMcreate. POEPMcreate has been shown empiricallly to be more effective than EPMcreate, which in turn has been shown empiricallly to be more effective than traditional brainstorm in getting teams of analysts to generate creative requirement ideas. Vicky and others have recently done empirical studies to determine optimal team sizes for the use of EPMcreate, POEPMcreate, and other cerativity enhancement techniques. 8. Dumb Tools in RE Daniel Berry, Ricardo Gacitua, Pete Sawyer, and Sri Fatima Tjong Since most requirements specifications are written in natural language, most tools developed to assist the requirements analyst are based on natural-language processing (NLP) tools, which generally are based on NL parsers and part of speech taggers. These parsers and taggers are never ore than 95% accurate because NL is well.. naturally ambiguous. :-). This limitation of NLP tools means that RE tools based on NLP can never have better than 95% recall. Sometimes that is not enough to prevent the analyst from having to manually process the WHOLE of a document. Daniel and others have been looking at different approaches to develop RE tools that steer clear of these so-called smart NLP tools. 9. Evaluation of Tools for Hairy Requirements Engineering and Software Engineering Tasks Daniel Berry [Context and Motivation] A hairy requirements or software engineering task involving natural language (NL) documents is one that is not inherently difficult for NL understanding humans on a small scale but becomes unmanageable in the large scale. A hairy task demands tool assistance. Because humans need help in carrying out a hairy task completely, a tool for a hairy task should have as close to 100% recall as possible. A hairy task tool that falls short of close to 100% recall that is applied to the development of a high-dependability system may even be useless, because to find the missing information, a human has to do the entire task manually anyway. For a such a tool to have recall acceptably close to 100%, a human working with the tool on the task must achieve better recall than a human working on the task entirely manually. [Problem] Traditionally, many hairy requirements engineering and software engineering tools have been evaluated mainly by how high their precision is, causing us to believe that tools are more useful than they actually are. [Principal Ideas] This paper describes using recall, a properly weighted F-measure, and a new measure called summarization to evaluate tools for hairy requirements engineering and software engineering tools and shows how this kind of evaluation can be performed on several tools reported in the literature. [Contribution] The finding is that some of these tools are actually better than they were thought to be when they were evaluated using mainly precision or an unweighted F-measure. 10. Requirements Determination Cannot be Stopped Daniel Berry, Krzysztof Czarnecki, Michal Antkiewicz, and Mohammad AbdElRazik A number of companies have gotten the message that it's important to determine requirements for a system BEFORE commencing the development of code for the system and have instituted a serious RE process into its software development lifecycle. Yet, many times these companies have the same problems that companies with no serious RE process have. An in-depth investigation by Dan and others at one company that was having this problem determined why, thereby exposing a fundamental truth: that ending the RE process when its deadline arrives does not necessarily mean that there are no more requirements to determine, and when there ARE such requirements, they get determined anyway by the wrong people. 11. Requirements Engineering for Buildings Daniel Berry Anyone who has built or remodeled a house and has developed or enhanced software must have noticed the similarity of these activities. I have learned some lessons about requirements engineering while being a customer in a house building and two house remodelings. The biggest problem is to avoid very expensive requirements creep. The main lesson is the importance of the customer insisting on following a full requirements engineering process, including goal identification, requirements elicitation, analysis, and specification, and validation of the specification. A secondary lesson is that a customer has an important role in requirements engineering and he or she sometimes needs to learn that role. 12. 4-Levels of RE in and about DASs Daniel Berry A dynamically self adapting system (called a DAS) is a system that is capable of adapting its behavior in response to changes in the world in which it executes. In a DAS, the adaptation code is in effect doing requirements engineering to determine how the system needs to adapt to its new world. Closer examination of DASs by Dan and others has shown that there are 4 levels of RE done in or about DASs. 13. Emotion, Values, and Beliefs in RE Isabel Ramos and Daniel Berry Occasionally a well-developed system that ostensibly meets all of its specified requirements fails miserably as it is deployed into the real world. In many of these cases, it is clear that the development of the system did not consider the emotions, values, and beliefs of its users. Isabel Ramos and others have argued that it is necessary to consider users' emotions, values, and beliefs during requirements engineering so that the system is developed from the beginning taking its users' emotions, values, and beliefs into account.