Lecture Notes on Requirements Elicitation

Requirements elicitation is the first of the four steps in software requirements engineering (the others being analysis, specification, and validation). Software engineers use several elicitation techniques. To facilitate teaching these techniques, materials are provided to support an introductory lecture and four lectures on specific techniques: joint application design, brainstorming, interviewing, and the PIECES framework. A role-playing exercise is provided that allows students to experience each of the techniques. Information for instructors includes educational objectives, pedagogical considerations, additional exercises, and a bibliography

Lessons on Converting Batch Systems to Support Interaction

Software often evolves from batch to interactive use. Because these two usage styles are so different, batch systems usually require substantial changes to support interactive use. Specific issues that arise during conversion include assumptions about duration of system execution, incrementaland partial processing, scope of processing, unordered and repeated processing, and error handling. Addressing these issues affects the implementation in the areas of memory management, assumptions and invariants, computational organization, and error handling. We use as a working example our conversion of the batch processor for the UniCon architecture description tool into an interactive architecture development tool. To capture the lessons for practitioners undertaking this type of conversion, we summarize with a checklist of design and implementation considerations.</p

Rationale for SQL Ada Module Description Language SAMeDL

The SQL ADA Module Description Language, SAMeDL, is a language for the specification of Abstract Interfaces as delineated by the SQL ADA Module Extensions (SAME) methodology. The language is formally defined in the SAMeDL Reference Manual. This document is a companion to the Reference Manual. Whereas the Reference Manual is meant to be precise, the Rationale is meant to be clear. An explanation of the problem solved by the SAMeDL is given. The creation of a new language is justified and the underlying principles of that language are described. Crucial issues in the language are then explained. These include: * The form and meaning of identifiers in the SAMeDL. * The role of and procedures for data definition in the SAMeDL. This includes support for enumerations and constants in the SAMeDL. * The typing rules of the SAMeDL. The proposed use of some SAMeDL features is also illustrated. These include Standard Post Processing and User Defined Base Domains

Requirements Engineering and Analysis Workshop Proceedings

The Software Engineering Institute (SEI) hosted the Requirements Engineering and Analysis Workshop in Pittsburgh, Pennsylvania, on March 12-14, 1991. The intention of the workshop was to focus discussion on issues and activities that could help the Department of Defense (DoD) to deal more effectively with the requirements of mission-critical systems. The SEI workshop built upon work performed previously at the Requirements Engineering and Rapid Prototyping Workshop held by the U.S. Army Communications-Electronics Command (CECOM) Center for Software Engineering in Eatontown, New Jersey, on November 14-16, 1989. The workshop participants were divided into four working groups: Requirements Engineering Process and Products, Requirements Volatility, Requirements Elicitation, and Requirements Engineering Techniques and Tools. A summary of the findings of each working group follows

Abstractions for Software Architecture and Tools to Support Them

Architectures for software use rich abstractions and idioms to describe system components, the nature of interactions among the components, and the patterns that guide the composition of components into systems. These abstractions are higher-level than the elements usually supported by programming languages and tools. They capture packaging and interaction issues as well as computational functionality. Well-established (if informal) patterns guide architectural design of systems. We sketch a model for defining architectures and present an implementation of the basic level of that model. Our purpose is to support the abstractions used in practice by software designers. the implementation provides a testbed for experiments with a variety of system construction mechanisms. It distinguishes among different types of components and different ways these components can interact. It supports abstract interactions such as data flow and scheduling on the same footing as simple procedure call. It can express and check appropriate compatibility restrictions and configuration constraints. It accepts existing code as components, incurring no runtime overhead after initialization. It allows easy incorporation of specifications and associated analysis tools developed elsewhere. The implementation provides a base for extending the notation and validating the model.</p