Requirements Elicitation: A Survey of Techniques, Approaches, and Tools
---
paper_title: Mastering the Requirements Process

paper_content:

● The teaching chapters are reinforced with hands-on workshops. ● Discuss issues with an instructor who has real-world experience. ● Learn industry-proven requirements techniques. ● In the final session, through discussions, interaction and demonstrations, you ensure that you have the requirements process that is suitable for your organization. ● Receive the Volere Requirements Specification Template with advice on how to make this your own template. ● Receive a copy of Suzanne and James Robertson's book Mastering the Requirements Process Second Edition. Special Features
---
paper_title: A Logic-Based Framework for the Management of Changing Software Requirements

paper_content:

 Abstract—Requirement change management is very critical and the most important aspect in the software development. Changings unleash themselves during all the stages of software development. Hence we must need to have some effective techniques to tackle these changings. Basically change is a transition from current way of working to another looked-for way and this nature of the change coupled with complexity of services create problems. This paper depicts the main hurdles in the change management like dependability, traceability etc. and efficient tools to cope these changes so that it would not affect the stability. Ultimate aim is to propose a framework to manage this important trait in the process of software development.
---
paper_title: Requirements Engineering: A Good Practice Guide

paper_content:

From the Publisher: ::: Requirements engineering is the process of discovering, documenting and managing the requirements for a computer-based system. The goal of requirements engineering is to produce a set of system requirements which, as far as possible, is complete, consistent, relevant and reflects what the customer actually wants. Although this ideal is probably unattainable, the use of a systematic approach based on engineering principles leads to better requirements than the informal approach which is still commonly used. This book presents a set of guidelines which reflect the best practice in requirements engineering. Based on the authors' experience in research and in software and systems development, these guidelines explain in an easy-to-understand way how you can improve your requirements engineering processes. The guidelines are applicable for any type of application and, in general, apply to both systems and software engineering.
---
paper_title: Four dark corners of requirements engineering

paper_content:

Research in requirements engineering has produced an extensive body of knowledge, but there are four areas in which the foundation of the discipline seems weak or obscure. This article shines some light in the “four dark corners,” exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary for sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements and engineering to be successfully completed.
---
paper_title: The world and the machine

paper_content:

As software developers we are engineers because we make useful machines. We are concerned both with the world, in which the machine serves a useful purpose, and with the machine itself. The competing demands and attractions of these two concerns must be appropriately balanced. Failure to balance them harms our work. Certainly it must take some of the blame for the gulf between researchers and practitioners in software development. To achieve proper balance we must sometimes fight against tendencies and inclinations that are deeply ingrained in our customary practices and attitudes in software development. In this paper some aspects of the relationship between the world and the machine are explored; some sources of distortion are identified; and some suggestions are put forward for maintaining a proper balance.
---
paper_title: Software For Use A Practical Guide To The Models And Methods Of Usage Centered Design

paper_content:

Thank you for downloading software for use a practical guide to the models and methods of usage centered design. As you may know, people have search numerous times for their favorite novels like this software for use a practical guide to the models and methods of usage centered design, but end up in infectious downloads. Rather than reading a good book with a cup of tea in the afternoon, instead they juggled with some infectious bugs inside their computer.
---
paper_title: Requirements Engineering: Processes and Techniques

paper_content:

Requirements Engineering Processes and Techniques Why this book was written The value of introducing requirements engineering to trainee software engineers is to equip them for the real world of software and systems development. What is involved in Requirements Engineering? As a discipline, newly emerging from software engineering, there are a range of views on where requirements engineering starts and finishes and what it should encompass. This book offers the most comprehensive coverage of the requirements engineering process to date - from initial requirements elicitation through to requirements validation. How and Which methods and techniques should you use? As there is no one catch-all technique applicable to all types of system, requirements engineers need to know about a range of different techniques. Tried and tested techniques such as data-flow and object-oriented models are covered as well as some promising new ones. They are all based on real systems descriptions to demonstrate the applicability of the approach. Who should read it? Principally written for senior undergraduate and graduate students studying computer science, software engineering or systems engineering, this text will also be helpful for those in industry new to requirements engineering. Accompanying Website: http: //www.comp.lancs.ac.uk/computing/resources/re Visit our Website: http://www.wiley.com/college/wws
---
paper_title: Mastering the Requirements Process

paper_content:

● The teaching chapters are reinforced with hands-on workshops. ● Discuss issues with an instructor who has real-world experience. ● Learn industry-proven requirements techniques. ● In the final session, through discussions, interaction and demonstrations, you ensure that you have the requirements process that is suitable for your organization. ● Receive the Volere Requirements Specification Template with advice on how to make this your own template. ● Receive a copy of Suzanne and James Robertson's book Mastering the Requirements Process Second Edition. Special Features
---
paper_title: Issues in Requirements Elicitation

paper_content:

Abstract : There are many problems associated with requirements engineering, including problems in defining the system scope, problems in fostering understanding among the different communities affected by the development of a given system, and problems in dealing with the volatile nature of requirements. These problems may lead to poor requirements and the cancellation of system development, or else the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system. Requirements engineering can be decomposed into the activ- ities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. This report concentrates instead on elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. An elicitation methodology is proposed to handle these concerns. This new elicitation methodology strives to incorporate the advantages of existing elicitation techniques while comprehensively addressing the activities performed during requirements elicitation. These activities include fact-finding, requirements gathering, evaluation and rationalization, prioritization, and integration. Taken by themselves, existing elicitation techniques are lacking in one or more of these areas.
---
paper_title: Elicitation technique selection: how do experts do it?

paper_content:

Requirements elicitation techniques are methods used by analysts to determine the needs of customers and users, so that systems can be built with a high probability of satisfying those needs. Analysts with extensive experience seem to be more successful than less experienced analysts in uncovering the user needs. Less experienced analysts often select a technique based on one of two reasons: (a) it is the only one they know, or (b) they think that a technique that worked well last time must surely be appropriate this time. We present the results of in-depth interviews with some of the world's most experienced analysts. These results demonstrate how they select elicitation techniques based on a variety of situational assessments.
---
paper_title: Writing Better Requirements

paper_content:

From the Book: ::: ::: It isn't that they can't see the solution. It is that they can't see the problem. ::: G. K. Chesterton ::: Requirements are essential ::: Requirements are the key to project success. We all know this, but we often forget n and pay the price. Many projects, both in industry and in the public sector, fail to do what is needed. They deliver late, over budget, and poor quality. Missing out on requirements is disastrous. ::: Who this book is for ::: Writing Better Requirements is designed as a short, convenient overview for practising systems engineers and others who find they need to write requirements. Because it is about practical techniques, it should be useful in many different kinds of system and software project. We aim to enable readers to write requirements good enough for successful systems to be specified, designed, and tested against them. ::: ::: This book should also form a useful introduction for students who want to learn how to get started with requirements. ::: What this book does and does not cover ::: This book specifically focuses on how to discover and express requirements. It is not about system specification, nor how to make a design that meets user needs, nor even about how users should ensure their requirements are met.Since users own the requirements, these must be expressed in a way users can understand. This book treats requirements as simple pieces of text, supported by operational scenarios and informal diagrams. Many attempts have been made to improve on these simple means, using more formal structures and notations with varying success. We have not tried to cover all these approaches. ::: ::: To place requirements in context,the book must of course cover some aspects of the development process. Project management, verification, quality assurance, and the development life cycle are all closely linked with requirements n indeed each of these areas is meaningless in isolation. But in this book, we concentrate on the tasks of capturing and writing requirements. Each chapter contains exercises to help readers to practice their skills. ::: ::: We recommend some good books for readers who want to go beyond writing good requirements to other aspects of systems and requirements engineering. ::: Getting the best from this book ::: This book is meant to be read in the order in which it is written, taking the reader through a disciplined process of identifying, gathering, organizing, and reviewing. This is vital for success. ::: ::: Each chapter introduces a stage in the requirements process. Key terms are defined informally, explained, and illustrated with examples and exercises to develop the practical skills of good requirements writing. ::: ::: These skills involve looking at problems, dealing with people, looking critically at what is being written, and reviewing requirements effectively. Reviewing is to some extent a separate skill and can be looked at separately; the others belong together in a more or less strict sequence. ::: Structure of this book ::: We begin by illustrating the importance of requirements. You may need this chapter to convince other people that they have a problem. Too many projects have poor requirements, and never recover. If you are already convinced, you can skip this introductory chapter. ::: ::: We then show in a non-technical way how to define a problem, in close co-operation with the only people who know what the problem is, the users. The body of the book steps through the process, looking at: ::: how to capture requirements from users; ::: how to organize these into a clear message from users to developers; ::: techniques for the special kind of writing needed for requirements; ::: how to review requirements informally at every stage, then formally. ::: ::: ::: Practical Exercises ::: All the chapters in the body of the book contain practical exercises for the reader. These are designed to take about half an hour each. Some are sufficiently open-ended for more extended self-instruction, or student projects. We recommend that readers attempt each exercise, at least briefly, to get an actual feeling for the difficulties involved. At the back of the book are short answers to all the questions, with hints to the reader for more complete projects. ::: Problems before Solutions ::: If the message of this book can be stated in a sentence, it is: ::: ::: Get agreement on what people want, before attempting to create solutions. ::: ::: Finding out what is needed, instead of rushing into presumed solutions, is the key to every aspect of system development. Most technical problems can be solved, given determination, patience, a skilled team n and a good definition of the problem to be solved. ::: Acknowledgements ::: We would like to thank the anonymous reviewers who checked the book so carefully; our wives and families for tolerating us while we wrote; and all our consultancy, training and workshop clients who experienced the material first-hand and showed us the way it needed to be explained. We are specially Richard Marshall for reading an early draft, and to Professor Ken Jackson for his perceptive and precise comments.
---
paper_title: Techniques for requirements elicitation

paper_content:

The authors survey and evaluate techniques for eliciting requirements of computer-based systems, paying particular attention to dealing with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. The last three techniques grew out of ethnomethodology and sociolinguistics. They can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself. >
---
paper_title: Mastering the Requirements Process

paper_content:

● The teaching chapters are reinforced with hands-on workshops. ● Discuss issues with an instructor who has real-world experience. ● Learn industry-proven requirements techniques. ● In the final session, through discussions, interaction and demonstrations, you ensure that you have the requirements process that is suitable for your organization. ● Receive the Volere Requirements Specification Template with advice on how to make this your own template. ● Receive a copy of Suzanne and James Robertson's book Mastering the Requirements Process Second Edition. Special Features
---
paper_title: Knowledge acquisition using structured interviewing: an empirical investigation

paper_content:

The knowledge acquisition problem endures as a bottleneck in the construction of expert system knowledge bases. Despite the recent proliferation of techniques and the availability of more sophisticated methods for this task, the interview technique continues to be widely used, especially in business domains. This paper reports the results of an experiment conducted to compare the unstructured knowledge acquisition interview with a specific type of structured knowledge acqui- sition interview. Structure for the interview was provided by a domain model of the business decision-making activity that attempted to capture the subjective and quali- tative aspects of decision making. Senior managers from industry served as the subjects in the experiment The interview technique was evaluated along efficiency and effectiveness dimensions. Results indicate improved performance with the struc- tured interviewing method.
---
paper_title: The role of task analysis in capturing requirements for interface design

paper_content:

Recently, the role of task analysis in design has been brought into question. It has been argued, for example, that task analysis leads to the non-creative redesign of existing artefacts. In this paper. we offer a view of task analysis that resolves this problem. In particular, we argue that by focusing upon the analysis of user/operator goals rather than an existing task implementation, task analysis encourages novel and apt design. A reformulation of hierarchical task analysis is offered, based on the sub-goal template (SGT) scheme. The SGT scheme provides a notation for goal-oriented task analysis and defines an appropriate level at which task analyses can inform the design process without constraining it to existing task implementations. The SGT scheme is compared with the systems analysis-based design methodology SSADM and the advantages of each approach are reviewed.
---
paper_title: A usability-oriented approach to requirements engineering

paper_content:

We describe and propose a usability-oriented approach to requirements engineering, the Delta method. We suggest that by focusing primarily on the tasks that the users are supposed to accomplish using a system, rather than the functionality of the system, functional requirements are elicited in a natural way and in their right context. The Delta method was developed in collaboration with a consultancy firm and validated in a commercial project. The components of the Delta method are outlined and discussed. The method is described further in a case study, and the results of this industrial application are reported.
---
paper_title: The domain theory for requirements engineering

paper_content:

Retrieval, validation, and explanation tools are described for cooperative assistance during requirements engineering and are illustrated by a library system case study. Generic models of applications are reused as templates for modeling and critiquing requirements for new applications. The validation tools depend on a matching process which takes facts describing a new application and retrieves the appropriate generic model from the system library. The algorithms of the matcher, which implement a computational theory of analogical structure matching, are described. A theory of domain knowledge is proposed to define the semantics and composition of generic domain models in the context of requirements engineering. A modeling language and a library of models arranged in families of classes are described. The models represent the basic transaction processing or 'use case' for a class of applications. Critical difference rules are given to distinguish between families and hierarchical levels. Related work and future directions of the domain theory are discussed.
---
paper_title: Problem frames: analyzing and structuring software development problems

paper_content:

This book is a must-have for all IT professionals facing software development problems on a daily basis. If you are a systems analyst or requirements engineer it will provide an essential, practical guide from the task of identifying the problem to making the descriptions needed to resolve it.
---
paper_title: Techniques for requirements elicitation

paper_content:

The authors survey and evaluate techniques for eliciting requirements of computer-based systems, paying particular attention to dealing with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. The last three techniques grew out of ethnomethodology and sociolinguistics. They can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself. >
---
paper_title: A laboratory for teaching object oriented thinking

paper_content:

It is difficult to introduce both novice and experienced procedural programmers to the anthropomorphic perspective necessary for object-oriented design. We introduce CRC cards, which characterize objects by class name, responsibilities, and collaborators, as a way of giving learners a direct experience of objects. We have found this approach successful in teaching novice programmers the concepts of objects, and in introducing experienced programmers to complicated existing designs.
---
paper_title: Joint Application Development

paper_content:

Partial table of contents: IS JAD FOR YOU? What Is JAD? Why People Use JAD. JAD Jargon. HOW TO DO A JAD. The JAD Team and How to Select It. Phase 1: JAD Project Definition. Phase 2: Research. Phase 4: The Session. Phase 5: The Final Document. SESSION PSYCHOLOGY. Group Dynamics. The Facilitator's Repertoire. TOOLS AND TECHNIQUES. Promoting Creativity. Deciding Between Alternatives. Using Tools in the Session. Handling Large Projects. JAD AND BEYOND. JAD Across the Life Cycle. Son of JAD: Related Methodologies. Marketing Your Services. IN CLOSING. JAD Anecdotes. Assuring JAD Success. Appendices. References. Index.
---
paper_title: Focus groups : a practical guide for applied research

paper_content:

PREFACE ACKNOWLEDGEMENTS 1. Overview of Focus Groups 2. Planning the Focus Group Study 3. Developing a Questioning Route 4. Participants in a Focus Group 5. Moderating Skills 6. Analyzing Focus Group Results 7. Reporting 8. Styles of Focus Group Research 9. Focus Group Interviews With Young People 10. International and Cross-Cultural Focus Groups Interviewing 11. Telephone and Internet Focus Group Interviewing 12. Focus Group Interviews Within the Organization 13. Modifications of Focus Groups 14. Answering Questions About the Quality of Focus Group Research
---
paper_title: Techniques for requirements elicitation

paper_content:

The authors survey and evaluate techniques for eliciting requirements of computer-based systems, paying particular attention to dealing with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. The last three techniques grew out of ethnomethodology and sociolinguistics. They can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself. >
---
paper_title: Getting access to what goes on in people's heads?: reflections on the think-aloud technique

paper_content:

One of the basic usability testing techniques the HCI community draws on, and which stands out as unique, is thinking aloud. We introduce the many names, uses and modifications of the classical think aloud technique, and ask the rhetorical question: What do researchers think they get when they ask people to think aloud? We answer it by discussing the classical work of Ericsson and Simon(1984), in particular their distinction between vocalisation, verbalisation and retrospective reports and the relation to short term memory. Reintroducing the psychological perspective and the focus on higher order cognitive processes, we argue that access to subjective experience is possible in terms of introspection and describe a technique that invites the user to become a participant in the analysis of his or her own cognitive processes. We suggest that use of think aloud has as a prerequisite explicit descriptions of design, test procedure and framework for analysis. We point out, however, that if the aim is to get access to human thinking, HCI research may benefit from experimental research.
---
paper_title: Mastering the Requirements Process

paper_content:

● The teaching chapters are reinforced with hands-on workshops. ● Discuss issues with an instructor who has real-world experience. ● Learn industry-proven requirements techniques. ● In the final session, through discussions, interaction and demonstrations, you ensure that you have the requirements process that is suitable for your organization. ● Receive the Volere Requirements Specification Template with advice on how to make this your own template. ● Receive a copy of Suzanne and James Robertson's book Mastering the Requirements Process Second Edition. Special Features
---
paper_title: Apprenticing with the customer

paper_content:

how its customers work. Designing such a system requires intimate knowledge of customers’ work and motives to ensure that the system supports them well. The creation of a new system implicitly means designing the new work practice it will support. Because system design is so intimately involved with how people work, designers need better approaches to gathering customer requirements. The current interest in participatory design, ethnographic techniques, and field research techniques grows out of the recognition that traditional interviewing and surveying techniques are not adequate for designing today’s applications. These new approaches seek to improve requirements definition by creating new relationships between designers and customers [11]. It is the relationship between designers and customers that determines how well the design team understands the customer problem. This includes not only the overall relationship between design team and customer community, but the individual, minute-by-minute process by which a single designer works with a single customer to understand the customer’s work. It is by understanding each person in the context of that person’s work that the team comes to understand the whole work problem [5, 13]. Through face-to-face interaction, customers and designers define
---
paper_title: Requirements Elicitation and Validation with Real World Scenes

paper_content:

A requirements specification defines the requirements for the future system at a conceptual level (i.e., class or type level). In contrast, a scenario represents a concrete example of current or future system usage. In early RE phases, scenarios are used to support the definition of high level requirements (goals) to be achieved by the new system. In many cases, those goals can to a large degree be elicited by observing, documenting and analyzing scenarios about current system usage. To support the elicitation and validation of the goals achieved by the existing system and to illustrate problems of the old system, we propose to capture current system usage using rich media (e.g., video, speech, pictures, etc.) and to interrelate those observations with the goal definitions. Thus, we aim at making the abstraction process which leads to the definition of the conceptual models more transparent and traceable. We relate the parts of the observations which have caused the definition of a goal or against which a goal was validated with the corresponding goal. These interrelations provide the basis for: 1) explaining and illustrating a goal model to, e.g., untrained stakeholders and/or new team members; 2) detecting, analyzing, and resolving a different interpretation of the observations; 3) comparing different observations using computed goal annotations; and 4) refining or detailing a goal model during later process phases. Using the PRIME implementation framework, we have implemented the PRIME-CREWS environment, which supports the interrelation of conceptual models and captured system usage observations. We report on our experiences with PRIME-CREWS gained in an experimental case study.
---
paper_title: Guiding goal modeling using scenarios

paper_content:

Even though goal modeling is an effective approach to requirements engineering, it is known to present a number of difficulties in practice. The paper discusses these difficulties and proposes to couple goal modeling and scenario authoring to overcome them. Whereas existing techniques use scenarios to concretize goals, we use them to discover goals. Our proposal is to define enactable rules which form the basis of a software environment called L'Ecritoire to guide the requirements elicitation process through interleaved goal modeling and scenario authoring. The focus of the paper is on the discovery of goals from scenarios. The discovery process is centered around the notion of a requirement chunk (RC) which is a pair . The paper presents the notion of RC, the rules to support the discovery of RCs and illustrates the application of the approach within L'Ecritoire using the ATM example. It also evaluates the potential practical benefits expected from the use of the approach.
---
paper_title: Objectives driven capture of business rules and of information systems requirements

paper_content:

There is a natural and logical relationship between the high level objectives of a business and the requirements of an information system supporting the business and its activities. We outline a framework for information systems requirements capture and specification, where the determination and explicit specification of business objectives play a vital role. The framework is described by a number of "meta-models", which guide the specification, structuring, and analysis of goals, problems, concepts, activities, processes, actors, and other descriptive components. The paper also describes how "business rules" have been incorporated in this approach. The nature of business rules is discussed, as well as sources from where the business rules are derived. The objectives driven approach has been successfully used in a number of real-life projects in information systems requirements engineering. >
---
paper_title: Goal-directed requirements acquisition

paper_content:

Requirements analysis includes a preliminary acquisition step where a global model for the specification of the system and its environment is elaborated. This model, called requirements model, involves concepts that are currently not supported by existing formal specification languages, such as goals to be achieved, agents to be assigned, alternatives to be negotiated, etc. The paper presents an approach to requirements acquisition which is driven by such higher-level concepts. Requirements models are acquired as instances of a conceptual meta-model. The latter can be represented as a graph where each node captures an abstraction such as, e.g., goal, action, agent, entity, or event, and where the edges capture semantic links between such abstractions. Well-formedness properties on nodes and links constrain their instances-that is, elements of requirements models. Requirements acquisition processes then correspond to particular ways of traversing the meta-model graph to acquire appropriate instances of the various nodes and links according to such constraints. Acquisition processes are governed by strategies telling which way to follow systematically in that graph; at each node specific tactics can be used to acquire the corresponding instances. The paper describes a significant portion of the meta-model related to system goals, and one particular acquisition strategy where the meta-model is traversed backwards from such goals. The meta-model and the strategy are illustrated by excerpts of a university library system.
---
paper_title: Viewpoints for requirements elicitation: a practical approach

paper_content:

The paper introduces an approach to multi perspective requirements engineering (PREview) which has been designed for industrial use and discusses our practical experience in applying PREview. We have developed a flexible model of viewpoints and using examples from an industrial application, show how this can be used to organise system requirements derived from radically different sources. We show how 'concerns', which are key business drivers of the requirements elicitation process, may be used to elicit and validate system requirements. They are decomposed into questions which must be answered by system stakeholders. We briefly describe the process of using PREview which has been designed to allow incremental requirements elicitation. Finally, we discuss some practical considerations which emerged when the approach was applied in industry.
---
paper_title: Method engineering for multi-perspective software development

paper_content:

Abstract This paper examines the role of the method engineer in the context of multi-perspective software development. Such development is characterized by the existence of multiple development participants who hold multiple views on a system and its domain. These views may be described and developed using multiple representation schemes and development strategies respectively. The paper outlines the Viewpoints framework—an organizational framework developed to model such a scenario—and then examines the method engineering process required to support the kind of multi-perspective development described. The role of tool support in this context is also explored.
---
paper_title: Techniques for requirements elicitation

paper_content:

The authors survey and evaluate techniques for eliciting requirements of computer-based systems, paying particular attention to dealing with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. The last three techniques grew out of ethnomethodology and sociolinguistics. They can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself. >
---
paper_title: Modern Structured Analysis

paper_content:

From the Publisher: ::: Yourdon provides a fresh perspective on structured systems analysis, integrating traditional methodologies with modern technology. He thoroughly discusses data modeling, real-time systems, prototyping, and 4GLs.N
---
paper_title: Quality Function Deployment : Integrating Customer Requirements into Product Design

paper_content:

A disposable compressed gas container having a cylindrical body with an annular collar projecting above the top and an annular skirt depending from the bottom. The collar and skirt are so dimensioned that the collar of one container nests in complementary disposition with respect to the skirt of a second container longitudinally stacked therewith. Latching means are provided to interlock the nested collar and skirt together, and plurality of axially stacked pair of coupled containers are adapted to be strapped about the girth of the waists defined by the nested collars and skirts.
---
paper_title: Soft Systems Methodology in Action

paper_content:

The Emergence of Soft Systems Thinking. Soft Systems Methodology--the Whole. Soft Systems Methodology--the Parts. Soft Systems Methodology--the Whole Revisited. Soft Systems Methodology--the Context. Conclusion. Appendix. Bibliography. Indexes.
---
paper_title: AbstFinder, A Prototype Natural Language Text Abstraction Finder for Use in Requirements Elicitation

paper_content:

Abstraction identification is named as a key problem in requirements analysis. Typically, the abstrac-tions must be found among the large mass of natural language text collected from the clients and users. This paper motivates and describes a new approach, based on traditional signal processing methods. for finding abstractions in natural language text and offers a new tool, AbstFinder as an implementation of this approach. The advantages and disadvantages of the approach and the design of the tool are discussed in detail. Various scenarios for use of the tool are offered. Some of these scenarios were used in case study of the effectiveness of rhe tool on an industrial-strength example of finding abstractions in a request for proposals.
---
paper_title: A multimedia approach to requirements capture and modeling

paper_content:

The Advanced Multimedia Organizer for Requirements Elicitation (AMORE) embodies a synthesis of technologies adapted specifically for application to requirements elicitation processes and models. Elicitors will use AMORE as a platform for storing requirements in as close to their natural forms as possible to maximize traceability and to promote understanding of original intentions and motivations. AMORE fills the gap that exists between raw requirements source material and the more formalized requirements representations commonly used by specification methods and CASE tools. The concepts and technologies demonstrated by AMORE are suitable for inclusion as a front-end augmentation to existing CASE analysis tools. >
---
paper_title: Creative problem solving using GroupSystems

paper_content:

Creativity is an important issue in the world of collaboration and it is widely accepted that techniques of creativity can energize participants and improve effectiveness of meetings. Specifically these techniques have been applied to 'creative problem solving'. This paper analyses why it can be difficult to be creative in conventional meetings and describes some current techniques for encouraging creativity. The paper then suggests that some of the features of Electronic Meetings naturally improve creativity and describes some research to measure creativity in meetings. A working agenda for creative problem solving in an Electronic Meeting is described. Creativity not an end in itself; creativity is a means to an end. The final objective of 'creative problem solving' is to get better results for the organization (e.g. increased profits, improved customer service, reduced cost, protection of the environment).
---
paper_title: Mastering the Requirements Process

paper_content:

● The teaching chapters are reinforced with hands-on workshops. ● Discuss issues with an instructor who has real-world experience. ● Learn industry-proven requirements techniques. ● In the final session, through discussions, interaction and demonstrations, you ensure that you have the requirements process that is suitable for your organization. ● Receive the Volere Requirements Specification Template with advice on how to make this your own template. ● Receive a copy of Suzanne and James Robertson's book Mastering the Requirements Process Second Edition. Special Features
---
paper_title: Using a groupware space for distributed requirements engineering

paper_content:

Requirements engineering (RE) is a necessary part of the software development process, as it helps customers and designers identify necessary system requirements. If these stakeholders are separated by distance, we argue that a distributed groupware environment supporting cooperative requirements engineering process must be supplied that allows them to negotiate software requirements. Such a groupware environment must support aspects of joint work relevant to requirements negotiation: synchronous and asynchronous collaboration, telepresence, and teledata. It should also add explicit support for a structured RE process, which includes the team's ability to discuss multiple perspectives during requirements acquisition and traceability. We chose the TeamWave software platform as an environment that supplied the basic collaboration capabilities, and tailored it to fit the specific needs of RE.
---
paper_title: The Requirements Apprentice: automated assistance for requirements acquisition

paper_content:

An automated tool called the Requirements Apprentice (RA) which assists a human analyst in the creation and modification of software requirements is presented. Unlike most other requirements analysis tools, which start from a formal description language, the focus of the RA is on the transition between informal and formal specifications. The RA supports the earliest phases of creating a requirement, in which ambiguity, contradiction, and incompleteness are inevitable. From an artificial intelligence perspective, the central problem the RA faces is one of knowledge acquisition. The RA develops a coherent internal representation of a requirement from an initial set of disorganized imprecise statements. To do so, the RA relies on a variety of techniques, including dependency-directed reasoning, hybrid knowledge representations and the reuse of common forms (cliches). An annotated transcript showing an interaction with a working version of the RA is given. >
---
paper_title: ACME/PRIME: requirements acquisition for process-driven systems

paper_content:

This paper discusses a requirements gathering methodology and tool support for a class of systems we term service-oriented systems. The requirements acquisition methodology that our tools support is, not surprisingly, a process centered methodology, since the processes of the system map to the services provided by our organization. The ACME/PRIME tool to support this methodology is built upon a conceptual modeling platform (ACME) that traces its roots to RML. The paper will discuss our approach to one of the fundamental problems of requirements engineering, i.e., dealing with over and under specification of requirements. We also provide some lessons learned from deploying the ACME/PRIME tool in our corporate requirements office.
---
paper_title: Issues in Requirements Elicitation

paper_content:

Abstract : There are many problems associated with requirements engineering, including problems in defining the system scope, problems in fostering understanding among the different communities affected by the development of a given system, and problems in dealing with the volatile nature of requirements. These problems may lead to poor requirements and the cancellation of system development, or else the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system. Requirements engineering can be decomposed into the activ- ities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. This report concentrates instead on elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. An elicitation methodology is proposed to handle these concerns. This new elicitation methodology strives to incorporate the advantages of existing elicitation techniques while comprehensively addressing the activities performed during requirements elicitation. These activities include fact-finding, requirements gathering, evaluation and rationalization, prioritization, and integration. Taken by themselves, existing elicitation techniques are lacking in one or more of these areas.
---
paper_title: Techniques for requirements elicitation

paper_content:

The authors survey and evaluate techniques for eliciting requirements of computer-based systems, paying particular attention to dealing with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. The last three techniques grew out of ethnomethodology and sociolinguistics. They can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself. >
---
paper_title: Viewpoints for requirements elicitation: a practical approach

paper_content:

The paper introduces an approach to multi perspective requirements engineering (PREview) which has been designed for industrial use and discusses our practical experience in applying PREview. We have developed a flexible model of viewpoints and using examples from an industrial application, show how this can be used to organise system requirements derived from radically different sources. We show how 'concerns', which are key business drivers of the requirements elicitation process, may be used to elicit and validate system requirements. They are decomposed into questions which must be answered by system stakeholders. We briefly describe the process of using PREview which has been designed to allow incremental requirements elicitation. Finally, we discuss some practical considerations which emerged when the approach was applied in industry.
---
paper_title: The domain theory for requirements engineering

paper_content:

Retrieval, validation, and explanation tools are described for cooperative assistance during requirements engineering and are illustrated by a library system case study. Generic models of applications are reused as templates for modeling and critiquing requirements for new applications. The validation tools depend on a matching process which takes facts describing a new application and retrieves the appropriate generic model from the system library. The algorithms of the matcher, which implement a computational theory of analogical structure matching, are described. A theory of domain knowledge is proposed to define the semantics and composition of generic domain models in the context of requirements engineering. A modeling language and a library of models arranged in families of classes are described. The models represent the basic transaction processing or 'use case' for a class of applications. Critical difference rules are given to distinguish between families and hierarchical levels. Related work and future directions of the domain theory are discussed.
---
paper_title: Goal-directed requirements acquisition

paper_content:

Requirements analysis includes a preliminary acquisition step where a global model for the specification of the system and its environment is elaborated. This model, called requirements model, involves concepts that are currently not supported by existing formal specification languages, such as goals to be achieved, agents to be assigned, alternatives to be negotiated, etc. The paper presents an approach to requirements acquisition which is driven by such higher-level concepts. Requirements models are acquired as instances of a conceptual meta-model. The latter can be represented as a graph where each node captures an abstraction such as, e.g., goal, action, agent, entity, or event, and where the edges capture semantic links between such abstractions. Well-formedness properties on nodes and links constrain their instances-that is, elements of requirements models. Requirements acquisition processes then correspond to particular ways of traversing the meta-model graph to acquire appropriate instances of the various nodes and links according to such constraints. Acquisition processes are governed by strategies telling which way to follow systematically in that graph; at each node specific tactics can be used to acquire the corresponding instances. The paper describes a significant portion of the meta-model related to system goals, and one particular acquisition strategy where the meta-model is traversed backwards from such goals. The meta-model and the strategy are illustrated by excerpts of a university library system.
---
paper_title: The Requirements Apprentice: automated assistance for requirements acquisition

paper_content:

An automated tool called the Requirements Apprentice (RA) which assists a human analyst in the creation and modification of software requirements is presented. Unlike most other requirements analysis tools, which start from a formal description language, the focus of the RA is on the transition between informal and formal specifications. The RA supports the earliest phases of creating a requirement, in which ambiguity, contradiction, and incompleteness are inevitable. From an artificial intelligence perspective, the central problem the RA faces is one of knowledge acquisition. The RA develops a coherent internal representation of a requirement from an initial set of disorganized imprecise statements. To do so, the RA relies on a variety of techniques, including dependency-directed reasoning, hybrid knowledge representations and the reuse of common forms (cliches). An annotated transcript showing an interaction with a working version of the RA is given. >
---
paper_title: ACME/PRIME: requirements acquisition for process-driven systems

paper_content:

This paper discusses a requirements gathering methodology and tool support for a class of systems we term service-oriented systems. The requirements acquisition methodology that our tools support is, not surprisingly, a process centered methodology, since the processes of the system map to the services provided by our organization. The ACME/PRIME tool to support this methodology is built upon a conceptual modeling platform (ACME) that traces its roots to RML. The paper will discuss our approach to one of the fundamental problems of requirements engineering, i.e., dealing with over and under specification of requirements. We also provide some lessons learned from deploying the ACME/PRIME tool in our corporate requirements office.
---
paper_title: Software requirements: analysis and specification

paper_content:

In a metal halide arc discharge lamp having an arc tube fill including mercury, halogen, sodium and a light emitting metal, controlled amounts of cesium, potassium or rubidium are added to the arc tube fill.
---

Title: Requirements Elicitation: A Survey of Techniques, Approaches, and Tools

Section 1: What is Requirements Elicitation?
Description 1: Define requirements elicitation and explain its importance in understanding user and project sponsor needs.

Section 2: The Process of Requirements Elicitation
Description 2: Describe the activities involved in the requirements elicitation process including communication, prioritization, and negotiation with stakeholders.

Section 3: Roles of the Requirements Engineer during Elicitation
Description 3: Outline the variety of roles and responsibilities assumed by the requirements engineer during the elicitation process.

Section 4: Techniques and Approaches for Requirements Elicitation
Description 4: Survey a wide variety of techniques and approaches used for requirements elicitation, detailing their strengths, weaknesses, and appropriate contexts.

Section 5: Comparison of Techniques and Approaches
Description 5: Compare the different techniques and approaches, identifying which are best suited for specific elicitation activities and how they can complement each other.

Section 6: Methodology Based Requirements Elicitation
Description 6: Provide examples of methodology-based requirements elicitation and explain their analytical techniques.

Section 7: Tool Support for Requirements Elicitation
Description 7: Describe the range of tools available to support the requirements elicitation process, from templates to requirements management software.

Section 8: Issues and Pitfalls of Requirements Elicitation
Description 8: Discuss the common issues and pitfalls encountered in the requirements elicitation process, categorizing them by process, communication, stakeholder, analyst, and research factors.

Section 9: Trends and Challenges in Requirements Elicitation
Description 9: Identify and discuss current trends and challenges in the field of requirements elicitation in both research and practice.

Section 10: Future Directions in Requirements Elicitation Research
Description 10: Suggest potential areas for future research in requirements elicitation to address unresolved issues and emerging challenges.

Section 11: Summary
Description 11: Provide a summary of the requirements elicitation process, reinforcing the need for a combination of different techniques to achieve successful outcomes.