Advertisement

Requirements Engineering

  • Elizabeth Hull
  • Ken Jackson
  • Jeremy Dick

Part of the Practitioner Series book series (PRACT.SER.)

Table of contents

  1. Front Matter
    Pages i-xxiii
  2. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 1-22
  3. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 23-46
  4. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 47-73
  5. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 75-92
  6. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 93-116
  7. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 117-140
  8. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 141-159
  9. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 161-185
  10. Elizabeth Hull, Ken Jackson, Jeremy Dick
    Pages 187-204
  11. Back Matter
    Pages 205-216

About this book

Introduction

We live in a commercial world where much of our work is undertaken through a project -oriented approach. This has the advantage of determining the cost and time of the project to be undertaken, which in their turn are based on the knowledge of what the project is to deliver. Computing is no different in this regard, and so in order to organize our activities, we need to know what it is that is to be delivered. Hence Requirements Engineering, an organized approach to determining what is required in the project/ system that is being undertaken. There are some problems with the idea of Requirements Engineering, which I have on previous occasions encapsulated in a single sentence called 'The Mock Theorem of Information Systems' which states 'There exists some point in time when everyone involved in the system knows what they want and agrees with everyone else' Clearly nonsense (how would you know what everyone is agreeing to for example?). But in order to build a system on a project basis, this sentence has to be assumed to be true (either explicitly, or even worse, implicitly). Then Requirements Engineering can be made to work, and the correct prod­ uct/ system delivered by the project. However, we do not have an established alternative to the project approach, and the business world is used to projects. So Requirements Engineering is necessary, but it needs tempering to allow for the desired certainty actually being unknown.

Keywords

DOORS HCI Requirements Engineering design language modeling requirements management software systems engineering systems requirements testing

Authors and affiliations

  • Elizabeth Hull
    • 1
  • Ken Jackson
    • 2
  • Jeremy Dick
    • 2
  1. 1.Faculty of InformaticsUniversity of UlsterNewtownabbey, Co AntrimNorthern Ireland, UK
  2. 2.Telelogic UK LtdOxfordUK

Bibliographic information

  • DOI https://doi.org/10.1007/978-1-4471-3730-6
  • Copyright Information Springer-Verlag London 2002
  • Publisher Name Springer, London
  • eBook Packages Springer Book Archive
  • Print ISBN 978-1-85233-577-9
  • Online ISBN 978-1-4471-3730-6
  • Series Print ISSN 1439-9245
  • Buy this book on publisher's site