scispace - formally typeset
Search or ask a question
Topic

Requirements elicitation

About: Requirements elicitation is a research topic. Over the lifetime, 4014 publications have been published within this topic receiving 78454 citations. The topic is also known as: requirements gathering & requirement gathering.


Papers
More filters
Proceedings ArticleDOI
01 Jun 2000
TL;DR: The initial description of a complex safety-critical system is used to illustrate a number of current research trends in RE-specific areas such as goal-oriented requirements elaboration, conflict management, and the handling of abnormal agent behaviors.
Abstract: 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 high quality 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 safety-critical system is used to illustrate a number of current research trends in RE-specific areas such as goal oriented requirements elaboration, conflict management, and the handling of abnormal agent behaviors. Opportunities for goal based architecture derivation are also discussed together with research directions to let the field move towards more disciplined habits.

778 citations

Journal ArticleDOI
Pamela Zave1, Michael Jackson1
TL;DR: It is shown that all descriptions involved in requirements engineering should be descriptions of the environment, and certain control information is necessary for sound requirements engineering, and the close association between domain knowledge and refinement of requirements is explained.
Abstract: 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.

769 citations

Book
14 Mar 1993
TL;DR: 1. The Software Requirements Specification: Specifying Behavioral Requirements and Nonbehavioral Requirements and Requirements Prototyping.
Abstract: 1. Introduction. 2. Problem Analysis. 3. The Software Requirements Specification. 4. Specifying Behavioral Requirements. 5. Specifying Nonbehavioral Requirements. 6. Requirements Prototyping. 7. Some Final Thoughts. Glossary. Annotated Bibliography.

740 citations

Proceedings ArticleDOI
19 Nov 2007
TL;DR: The existing definitions of the term 'non-functional requirement' are surveyed, the problems with the current definitions are discussed, and concepts for overcoming these problems are contributed.
Abstract: Although the term 'non-functional requirement' has been in use for more than 20 years, there is still no consensus in the requirements engineering community what non-functional requirements are and how we should elicit, document, and validate them. On the other hand, there is a unanimous consensus that non-functional requirements are important and can be critical for the success of a project. This paper surveys the existing definitions of the term, highlights and discusses the problems with the current definitions, and contributes concepts for overcoming these problems.

728 citations

Journal ArticleDOI
TL;DR: The needs for requirements definition are examined, and a proposed approach to meeting those objectives with three interrelated subjects: context analysis, functional specification, and design constraints is proposed.
Abstract: Requirements definition encompasses all aspects of system development prior to actual system design. We see the lack of an adequate approach to requirements definition as the source of major difficulties in current systems worlk This paper examines the needs for requirements definition, and proposes meeting those objectives with three interrelated subjects: context analysis, functional specification, and design constraints. Requirements definition replaces the widely used, but never well-defined, term "requirements analysis."

719 citations


Network Information
Related Topics (5)
Software development
73.8K papers, 1.4M citations
92% related
Software system
50.7K papers, 935K citations
91% related
Software construction
36.2K papers, 743.8K citations
90% related
Business process
31.2K papers, 512.3K citations
87% related
Web service
57.6K papers, 989K citations
85% related
Performance
Metrics
No. of papers in the topic in previous years
YearPapers
202356
2022150
2021102
2020156
2019158
2018163