The problems of designing large software systems were studied through interviewing personnel from 17 large projects. A layered behavioral model is used to analyze how three lgf these problems-the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns-affected software productivity and quality through their impact on cognitive, social, and organizational processes.

This paper describes a formal analysis technique, called consistency checking, for automatic detection of errors, such as type errors, nondeterminism, missing cases, and circular definitions, in requirements specifications. The technique is designed to analyze requirements specifications expressed in the SCR (Software Cost Reduction) tabular notation. As background, the SCR approach to specifying requirements is reviewed. To provide a formal semantics for the SCR notation and a foundation for consistency checking, a formal requirements model is introduced; the model represents a software system as a finite state automaton, which produces externally visible outputs in response to changes in monitored environmental quantities. Results are presented of two experiments which evaluated the utility and sealability of our technique for consistency checking in a real-world avionics application. The role of consistency checking during the requirements phase of software development is discussed.

This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future. 1

Software requirements specifications (SRS) are often validated manually. One such process is inspection, in which several reviewers independently analyze all or part of the specification and search for faults. These faults are then collected at a meeting of the reviewers and author(s). Usually, reviewers use Ad Hoc or Checklist methods to uncover faults. These methods force all reviewers to rely on nonsystematic techniques to search for a wide variety of faults. We hypothesize that a Scenario-based method, in which each reviewer uses different, systematic techniques to search for different, specific classes of faults, will have a significantly higher success rate. We evaluated this hypothesis using a 3 \Theta 2 4 partial factorial, randomized experimental design. Forty eight graduate students in computer science participated in the experiment. They were assembled into sixteen, three-person teams. Each team inspected two SRS using some combination of Ad Hoc, Checklist or Scenario meth...

In this paper, we present our experiences in using symbolic model checking to analyze a specification of a software system for aircraft collision avoidance. Symbolic model checking has been highly successful when applied to hardware systems. We are interested in whether model checking can be effectively applied to large software specifications. To investigate this, we translated a portion of the state-based system requirements specification of Traffic Alert and Collision Avoidance System II (TCAS II) into input to a symbolic model checker (SMV). We successfully used the symbolic model checker to analyze a number of properties of the system. We report on our experiences, describing our approach to translating the specification to the SMV language, explaining our methods for achieving acceptable performance, and giving a summary of the properties analyzed. Based on our experiences, we discuss the possibility of using model checking to aid specification development by iteratively applying the technique early in the development cycle. We consider the paper to be a data point for optimism about the potential for more widespread application of model checking to software systems.

Requirements engineering (RE) is concerned with the identification of the goals to be achieved by the envisioned system, the operationalization of such goals into services and constraints, and the assignment of responsibilities for the resulting requirements to agents such as humans, devices, and software. The processes involved in RE include domain analysis, elicitation, specification, assessment, negotiation, documentation, and evolution. Getting highquality requirements is difficult and critical. Recent surveys have confirmed the growing recognition of RE as an area of utmost importance in software engineering research and practice. The paper presents a brief history of the main concepts and techniques developed to date to support the RE task, with a special focus on modeling as a common denominator to all RE processes. The initial description of a complex safetycritical system is used to illustrate a number of current research trends in RE-specific areas such as go...

This paper publicly reveals, motivates, and surveys the results of an ambitious hidden agenda for applying algebra to software engineering. The paper reviews selected literature, introduces a new perspective on nondeterminism, and features powerful hidden coinduction techniques for proving behavioral properties of concurrent systems, especially renements; some proofs are given using OBJ3. We also discuss where modularization, bisimulation, transition systems and combinations of the object, logic, constraint and functional paradigms t into our hidden agenda. 1 Introduction Algebra can be useful in many dierent ways in software engineering, including specication, validation, language design, and underlying theory. Specication and validation can help in the practical production of reliable programs, advances in language design can help improve the state of the art, and theory can help with building new tools to increase automation, as well as with showing correctness of the whole e...

In 1990, Anthony Hall published a seminal article that listed and dispelled seven myths about the nature and application of formal methods. Today - five years and many successful applications later - formal methods remain one of the most contentious areas of software-engineering practice. Despite 25 years of use, few people understand exactly what formal methods are or how they are applied. Many nonformalists seem to believe that formal methods are merely an academic exercise -- a form of mental masturbation that has no relation to real-world problems. The media's portrayal of formal methods does little to help the situation. In many "popular press" science journals, formal methods are subjected to either deep criticism or, worse, extreme hyperbole. Fortunately, today these myths are held more by the public and the computer-science community at large than by system developers. It is our concern, however, that new myths are being propagated, and more alarmingly, are receiving a certain tacit acceptance from the system-development community. Following Hall's lead, we address and dispel seven new myths about formal methods: Formal methods delay the development process; formal methods lack tools; formal methods replace traditional engineering design methods; formal methods only apply to software; formal methods are unnecessary; formal methods are not supported; and formal-methods people always use formal methods.

This paper surveys and evaluates some techniques for eliciting requirements of computer-based systems, paying particular attention to how they deal with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. Although they are relatively untried in Requirements Engineering, we believe there is much promise in the last three techniques, which grew out of ethnomethodology and sociolinguistics. In particular, they can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself.

The formal methods community is in general very good at undertaking research into the mathematical aspects of formal methods, but not so good at promulgating the use of formal methods in an engineering environment and at an industrial scale. Technology transfer is an extremely important part of the overall effort necessary in the acceptance of formal techniques. This paper explores some of the more informal aspects of applying formal methods and presents some maxims with associated discussion that may help in the application of formal methods in an industrial setting. A significant bibliography is included, providing pointers to more technical and detailed aspects.