Overview
- Authors:
-
-
Elizabeth Hull
-
Faculty of Informatics, University of Ulster, Newtownabbey, Co Antrim, Northern Ireland, UK
-
Ken Jackson
-
Telelogic UK Ltd, Oxford, UK
-
Jeremy Dick
-
Telelogic UK Ltd, Oxford, UK
- Presents the latest techniques from practicing requirements engineers
- Introduces a flexible process for a variety of system development contexts
- Introduces the requirements management tool - DOORS
- Explains the important new concept of rich traceability
Access this book
Other ways to access
Table of contents (9 chapters)
-
Front Matter
Pages i-xxiii
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 1-22
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 23-46
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 47-73
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 75-92
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 93-116
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 117-140
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 141-159
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 161-185
-
- Elizabeth Hull, Ken Jackson, Jeremy Dick
Pages 187-204
-
Back Matter
Pages 205-216
About this book
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.
Authors and Affiliations
-
Faculty of Informatics, University of Ulster, Newtownabbey, Co Antrim, Northern Ireland, UK
Elizabeth Hull
-
Telelogic UK Ltd, Oxford, UK
Ken Jackson,
Jeremy Dick
