R. R. Dube
ABSTRACT
Software requirements express the requirements and constraints on a software product that contributes to the satisfaction of some 'need' in the real world. Ambiguity is a major problem in requirements specification. At its most basic, a requirement is a property that a system must exhibit in order for it to meet the system's motivating need. We ignore intentional ambiguity or the ambiguity that exists in early stages of requirements elicitation and focus on ambiguity that remains in a so-called final natural language requirements document. Ambiguity is a problem because the different readers of the requirements specification may understand different things.
An essential property of all requirements is that they should be verifiable. In a typical project there will be a large number of requirements derived from different sources and expressed at different levels of detail. The existing Requirement Engineering Techniques and Methodologies are supporting to a specific set of activity like Elicitation or validation. Requirement Engineering develops a mutual understanding between customers and project teams about the product or system requirements. An agreed-upon and approved product requirement becomes the initial baseline for product design. Knowledge of ambiguous, inconsistent requirements to requirement engineer increases the capability to view the requirements from different perspectives.
This paper discusses the requirement generation process and allied activities in it. It also focuses on methodologies, models and techniques for requirement engineering. As a part of applying complete requirement engineering, we claim that the crucial issues like architecture and design in system development can be effectively addressed.
- Matthias Jarke and Klaus Pohl, Requirements engineering in 2001: (virtually) managing a changing reality, Software Engineering Journal November 1994 pp. 257--266.Google Scholar
- Axel van Lamsweerde, Emmanuel Letier, Handling Obstacles in Goal-Oriented Requirements Engineering, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 26, NO. 10, OCTOBER 2000 pp. 978--1005 Google ScholarDigital Library
- Balasubramaniam Ramesh, Matthias Jarke, Toward Reference Models for Requirements Traceability, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 27, NO. 1, JANUARY 2001 pp. 58--93. Google ScholarDigital Library
- Bernhard Westfechtel, Bjorn P. Munch, Reidar Conradi, A Layered Architecture for Uniform Version Management IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 27, NO. 12, DECEMBER 2001 pp. 1111--1133. Google ScholarDigital Library
- Giuliano Antoniol, Gerardo Canfora, Gerardo Casazza, Andrea De Lucia, Ettore Merlo, Recovering Traceability Links between Code and Documentation, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 10, OCTOBER 2002 pp. 970--983. Google ScholarDigital Library
- Lionel C. Briand, Sandro Morasca, Victor R. Basili, An Operational Process for Goal-Driven Definition of Measures, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 12, DECEMBER 2002 pp. 1106--1125. Google ScholarDigital Library
- Jane Cleland-Huang, Carl K. Chang, Mark Christensen, Event-Based Traceability for Managing Evolutionary Change, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 9, SEPTEMBER 2003 pp. 796--810. Google ScholarDigital Library
- Luiz Marcio Cysneiros, Julio Cesar Sampaio do Prado Leite, Nonfunctional Requirements: From Elicitation to Conceptual Models, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 30, NO. 5, MAY 2004 pp. 328--350. Google ScholarDigital Library
- Andreas Gregoriades and Alistair Sutcliffe, Scenario-Based Assessment of Nonfunctional Requirements, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 31, NO. 5, MAY 2005 pp. 392--409. Google ScholarDigital Library
Index Terms
- Process-oriented complete requirement engineering cycle for generic projects
Recommendations
Usability requirements for requirement engineering tools
IHM '14: Proceedings of the 26th Conference on l'Interaction Homme-MachineRequirement engineering (RE) tools are necessary for several reasons: they allow engineers to manage an increasing amount of information, to maintain traceability between requirements, solution and tests, and to evaluate requirement change impact on the ...
A process for goal oriented requirement engineering
SE '08: Proceedings of the IASTED International Conference on Software EngineeringThere is an increasing emphasis and use of "goals" within requirements engineering. Work done in Goal-Oriented Requirement Engineering (GORE) have also been applied effectively in Business Process Re-engineering (BPR), specifically dealing with NFRs, ...
Goal Oriented Requirement Engineering: A Critical Study of Techniques
APSEC '06: Proceedings of the XIII Asia Pacific Software Engineering ConferenceThe term "Goal" is increasingly being used in Requirement Engineering. Goal-Oriented requirement engineering (GORE) provides an incremental approach for elicitation, analysis, elaboration & refinement, specification and modeling of requirements. Various ...
Reviews
Richard John Botting
I thought I was in for a real treat when I started to review this conference paper. We certainly need a good survey of the software requirements discipline, but this paper is not it. Dube and Dixit omit much of the literature on requirements. Worse, they fail to cite sources for the many methods, techniques, models, and frameworks they mention. For example, SQD, IBIS, SSM, and JAD are listed and briefly described, without a clue as to where one can find out more about them. This lack of traceability can be frustrating and confusing. For example, CORE [1] is defined as "controlled requirements expression," without citations. If the authors had given a citation, I wouldn't have confused it with "consortium requirements engineering" (CoRE) [2], which is not even mentioned. Michael Jackson's JSD is briefly described (with no citation), but his later work [3] is not. Other omissions include use cases, the IEEE SRS standards (IEEE 830-1998), Parnas' seminal contributions, software cost reduction [4,5], the TCAS 2 experiments [6], Harel's state charts and the unified modeling language (UML), and the IBM Rational Unified Process (RUP). To summarize, the proposed "complete cycle" is not complete and not clearly linked to academic evidence or any practical experience or tools. The reason might be that the conference had a strict limit on paper length. Publishing an expanded version could remedy these shortcomings. Online Computing Reviews Service
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments