User:Iansommerville/RE Draft 2
Requirements engineering (RE) is a systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system [1]. While there are differing definitions of the term, common factors are that requirements engineering is a subdiscipline of systems and software engineering and is concerned with establishing the goals, functions and constraints of hardware and software systems. [2] [3]
The first use of the term 'requirements engineering was probably in 1979 in a TRW technical report [4] but did not come into general use until the 1990s with the publication of an IEEE Computer Society tutorial [5] and the establishment of a conference series on requirements engineering.
In the traditional waterfall model of the systems or software engineering process [6], requirements engineering is presented as the first stage of the development process, with the outcome being a requirements document or Software requirements specification. In fact, requirements engineering is a process that continues through the lifetime of a system as the requirements are subject to change and new requirements must be elicited and documented and existing requirements managed over the lifetime of the system.
Alan M. Davis maintains an extensive bibliography of requirements engineering. [7]
Requirements engineering activities[edit]
The sub-processes that are part of a general requirements engineering process vary widely, depending on the type of system being developed and the specific practice of the organization developing the requirements. [8]Activities within the RE process may include:
- Requirements elicitation - discovering requirements from system stakeholders
- Requirements analysis and negotiation - checking requirements and resolving stakeholder conflicts
- Requirements specification (Software Requirements Specification)- documenting the requirements in a requirements document
- System modeling - deriving models of the system, often using a notation such as the Unified Modeling Language
- Requirements validation - checking that the documented requirements and models are consistent and meet stakeholder needs
- Requirements management - managing changes to the requirements as the system is developed and put into use
These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities.
References[edit]
- ^ Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons. 1998
- ^ Phillip A. Laplante (2007) What Every Engineer Should Know about Software Engineering. Page 44.
- ^ Zave, P. 'Classification of Research Efforts in Requirements Engineering'. ACM Computing Surveys, 29(4): 315-321, 1997.
- ^ Software Requirements Engineering Methodology (Development) Alfor,M. W. and Lawson,J. T. TRW Defense and Space Systems Group. 1979.
- ^ Thayer, R.H., and M. Dorfman (eds.), System and Software Requirements Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1990.
- ^ Royce, W.W. 'Managing the Development of Large Software Systems: Concepts and Techniques', IEEE Westcon, Los Angeles, CA> pp 1-9, 1970. Reprinted in ICSE '87, Proceedings of the 9th international conference on Software Engineering.
- ^ Requirements bibliography Reviewed November 10th 2011
- ^ Sommerville, I. Software Engineering, 7th ed. Harlow, UK: Addison Wesley, 2006.