Requirements Engineering within Software Engineering
What is meant by a 'requirement' in the context of software
engineering? A requirement is a statement of the real need of the
customer; it is testable, and it may be prioritized. Requirements
must be stated in an objective manner, as they are more than a vague
notion of a customer 'need'. A requirement is the output of the
elicitation process that has a specific meaning to a software
engineer [1]. Zave offers a classification of RE effort. RE is the
branch of software engineering (SE) concerned with real-world goals,
constraints, and precise specifications of software behaviour. The
subject is broad, interdisciplinary and open-ended. Sometimes it
takes the form of translation from informal observations of the real
world into mathematical specification languages [2].
Requirements' expression can be undertaken using natural language,
formal language, or with semi-formal constructs. There is no
substantial body of research in the literature on natural language
expression apart from to point to its inadequacy although there are
guidelines that are believed to distinguish between better and
lesser representation [3]. Formal language expression, as
characterized by formal language theories (e.g. 'Z') [4] have a role
to play, albeit a limited role [5]. Examples of semi-formal
constructs are represented by the use case notation that forms part
of the UML [6].
Prior to the acceptance of RE as a distinct function, the task of
requirements gathering was undertaken in the analysis function. The
change from an emphasis on analysis to an emphasis on RE has taken
place because it was necessary to make the distinction between
problem elicitation and solution discovery. Analysis, as a task, has
been considered part of the solution space.
To discover more about Requirements Engineering, and especially
about Problem Frames, Domain Modelling, and Use Case Modelling go to
the Download page and read the relevant section from the literature
survey.
[1.] Van Buren, J. and Cook, D., Experiences in the Adoption of
Requirements Engineering Technologies, December 1998, Crosstalk,
www.stsc.hill.af.mil/crosstalk/frames.asp?ure=1998/12/cook.asp
[2.] Zave, P., Classification of Research Efforts in Requirements
Engineering. ACM Computing Surveys, (1997). 29(4): p. 315-321,
Associated Computing Machinery (ACM) http://citeseer.nj.nec.com/zave97classification.html
[3.] Abbott, R.J., Program design by informal English descriptions.
Communications of the ACM, (1983). 26(11): p. 882-894, ACM Press
[4.] Spivey, J.M., The Z Notation: a Reference Manual. (1989), Upper
Saddle River, N.J., Prentice Hall
[5.] Khazaei, B. and Roast, C., The Influence of Formal
Representation on Solution Specification. Requirements Engineering,
(2003). 8(1): p. 69-77, Springer Verlag
[6.] Fowler, M. and Scott, K., UML Distilled - A Brief Guide to the
Standard Object Modeling Language. (1999), Upper Saddle River, N.J.,
Addison Wesley Longman
Selected Software Engineering links
General SE links
| British Computer Society Requirements Engineering Specialist Group |
| The Software Engineering Institute at Carnegie Mellon |
Methodology links
| Rational Unified Process (RUP) |
| Some history on Objectory which became RUP |
Modelling links
| ‘How to Avoid Use Case Pitfalls’ by Susan Lilly |
| ‘An Introduction to Systems Engineering with Use Cases’ by Ian Alexander, Thomas Zink |
| Pols Consulting |
| Alistair Cockburn (name pronounced "Coburn") |
| Martin Fowler |