Skip to main content
Top

Hint

Swipe to navigate through the chapters of this book

2017 | OriginalPaper | Chapter

3. Requirements Engineering

Author : Gerard O’Regan

Published in: Concise Guide to Software Engineering

Publisher: Springer International Publishing

Abstract

This chapter discusses requirements engineering and discusses activities such as requirements gathering, requirements elicitation, requirements analysis, requirements management, and requirements verification and validation.

Dont have a licence yet? Then find out more about our products and how to get one now:

Springer Professional "Wirtschaft+Technik"

Online-Abonnement

Mit Springer Professional "Wirtschaft+Technik" erhalten Sie Zugriff auf:

  • über 102.000 Bücher
  • über 537 Zeitschriften

aus folgenden Fachgebieten:

  • Automobil + Motoren
  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Elektrotechnik + Elektronik
  • Energie + Nachhaltigkeit
  • Finance + Banking
  • Management + Führung
  • Marketing + Vertrieb
  • Maschinenbau + Werkstoffe
  • Versicherung + Risiko

Jetzt Wissensvorsprung sichern!

Springer Professional "Technik"

Online-Abonnement

Mit Springer Professional "Technik" erhalten Sie Zugriff auf:

  • über 67.000 Bücher
  • über 390 Zeitschriften

aus folgenden Fachgebieten:

  • Automobil + Motoren
  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Elektrotechnik + Elektronik
  • Energie + Nachhaltigkeit
  • Maschinenbau + Werkstoffe




 

Jetzt Wissensvorsprung sichern!

Springer Professional "Wirtschaft"

Online-Abonnement

Mit Springer Professional "Wirtschaft" erhalten Sie Zugriff auf:

  • über 67.000 Bücher
  • über 340 Zeitschriften

aus folgenden Fachgebieten:

  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Finance + Banking
  • Management + Führung
  • Marketing + Vertrieb
  • Versicherung + Risiko




Jetzt Wissensvorsprung sichern!

Footnotes
1
It is desirable that the user or system requirements describe what is to be provided rather than how it is to be provided. That is, in theory, design or implementation information should be excluded in the specification. However, in practice, it is sometimes difficult to exclude all design information (e.g. consider the case where a system needs to work with an existing system).
 
2
It may involve getting end-users to talk about how they currently do a certain task and brainstorming on better ways in which the proposed system can do the same task.
 
3
Conflicts are inevitable as stakeholders will have different needs, and so discussion and negotiation are required to resolve these conflicts and achieve consensus.
 
4
Essentially, the mathematical language provides the facility to prove that certain properties are true of the specification, and that certain undesirable properties are false in the specification.
 
5
This principle is named after the medieval philosopher, William of Ockham.
 
Literature
1.
go back to reference I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Modelling Language User Guide (Addison-Wesley, Reading, 1999) I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Modelling Language User Guide (Addison-Wesley, Reading, 1999)
2.
go back to reference G. O’Regan, A Practical Approach to Software Quality (Springer, New York, 2002) G. O’Regan, A Practical Approach to Software Quality (Springer, New York, 2002)
3.
go back to reference T. Kuhn, The Structure of Scientific Revolutions (University of Chicago Press, Chicago, 1970) T. Kuhn, The Structure of Scientific Revolutions (University of Chicago Press, Chicago, 1970)
4.
go back to reference M.M.A. Airchinnigh, Conceptual models and computing. PhD Thesis. Department of Computer Science, University of Dublin. Trinity College, Dublin, 1990 M.M.A. Airchinnigh, Conceptual models and computing. PhD Thesis. Department of Computer Science, University of Dublin. Trinity College, Dublin, 1990
Metadata
Title
Requirements Engineering
Author
Gerard O’Regan
Copyright Year
2017
DOI
https://doi.org/10.1007/978-3-319-57750-0_3

Premium Partner