Requirements Engineering (eBook)
XX, 239 Seiten
Springer International Publishing (Verlag)
978-3-319-61073-3 (ISBN)
Written for those who want to develop their knowledge of requirements engineering process, whether practitioners or students.
Using the latest research and driven by practical experience from industry, Requirements Engineering gives useful hints to practitioners on how to write and structure requirements. It explains the importance of Systems Engineering and the creation of effective solutions to problems. It describes the underlying representations used in system modeling and introduces the UML2, and considers the relationship between requirements and modeling. Covering a generic multi-layer requirements process, the book discusses the key elements of effective requirements management. The latest version of DOORS (Version 7) - a software tool which serves as an enabler of a requirements management process - is also introduced to the reader here.
Additional material and links are available at: http://www.requirementsengineering.info
Jeremy Dick has been consulting in tool-supported requirements processes for over 20 years, across a wide range of sectors in the UK and elsewhere, most recently in the Civil Nuclear and Oil & Gas industries. A past chairman of the INCOSE International Requirements Working Group, he has contributed to the development of the discipline, particularly with regard to traceability.
Elizabeth Hull is Professor Emerita of Computing Science at Ulster University. She has published extensively on software engineering and requirements engineering. She is a Chartered IT Professional and an Honorary Fellow of the BCS, The Chartered Institute for IT.
Ken Jackson has over 40 years experience in the development of real time systems. For 16 years he worked as a requirements management consultant in a wide set of domains including defence, automotive, aerospace and telecommunications. He has contributed to INCOSE and is a founder member of the IEEE committee on ECBS (Engineering of Computer Based Systems).
Jeremy Dick has been consulting in tool-supported requirements processes for over 20 years, across a wide range of sectors in the UK and elsewhere, most recently in the Civil Nuclear and Oil & Gas industries. A past chairman of the INCOSE International Requirements Working Group, he has contributed to the development of the discipline, particularly with regard to traceability. Elizabeth Hull is Professor Emerita of Computing Science at Ulster University. She has published extensively on software engineering and requirements engineering. She is a Chartered IT Professional and an Honorary Fellow of the BCS, The Chartered Institute for IT. Ken Jackson has over 40 years experience in the development of real time systems. For 16 years he worked as a requirements management consultant in a wide set of domains including defence, automotive, aerospace and telecommunications. He has contributed to INCOSE and is a founder member of the IEEE committee on ECBS (Engineering of Computer Based Systems).
Preface to the Fourth Edition 6
Preface to the Third Edition 7
Preface to the Second Edition 8
Preface to the First Edition 9
Acknowledgements 11
Contents 12
1 Introduction 16
1.1 Introduction to Requirements 16
1.2 Introduction to Systems Engineering 19
1.3 Defining Requirements Engineering 22
1.3.1 Definition of a Requirement 22
1.3.2 Definition of a Stakeholder 23
1.3.3 Definition of Requirements Engineering 24
1.4 Requirements and Quality 25
1.5 Requirements and the Lifecycle 26
1.6 Requirements Tracing 29
1.7 Requirements and Modelling 33
1.8 Requirements and Testing 35
1.9 Requirements in the Problem and Solution Domains 36
1.10 Requirements and Design Agnosticism 38
1.11 Requirements and Interfaces 44
1.12 How to Read this Book 45
2 A Generic Process for Requirements Engineering 48
2.1 Introduction 48
2.2 Developing Systems 48
2.3 Generic Process Context 51
2.3.1 Input Requirements and Derived Requirements 53
2.3.2 Acceptance Criteria and Qualification Strategy 53
2.4 Generic Process Introduction 55
2.4.1 Ideal Development 55
2.4.2 Development in the Context of Change 56
2.5 Generic Process Information Model 58
2.5.1 Information Classes 58
2.5.2 Agreement State 60
2.5.3 Qualification State 61
2.5.4 Satisfaction State 62
2.5.5 Information Model Constraints 63
2.6 Generic Process Details 64
2.6.1 Agree Requirements 64
2.6.2 Analyse and Model 66
2.6.3 Derive Requirements and Qualification Strategy 67
2.6.3.1 Deriving Requirements 67
2.6.3.2 Deriving the Qualification Strategy 69
2.7 Summary 71
3 System Modelling for Requirements Engineering 72
3.1 Introduction 72
3.2 Representations for Requirements Engineering 73
3.2.1 Data Flow Diagrams 73
3.2.2 Entity-Relationship Diagrams 79
3.2.3 Statecharts 80
3.2.4 Object-Oriented Approaches 81
3.2.4.1 Class Diagrams 82
3.2.4.2 Use Cases 82
3.3 Methods 83
3.3.1 Viewpoint Methods 84
3.3.1.1 Controlled Requirements Expression (CORE) 85
3.3.1.2 Structured Analysis and Design Technique (SADT) 88
3.3.1.3 Viewpoint-Oriented Requirements Definition (VORD) 89
3.3.2 Object-Oriented Methods 93
3.3.2.1 OOA 94
3.3.2.2 OMT 94
3.3.2.3 Booch 95
3.3.2.4 Objectory 95
3.3.2.5 The UML 95
3.3.3 The UML Notation 96
3.3.4 SysML 101
3.3.5 Formal Methods 104
3.3.5.1 Z—A Model-Based Formal Method 105
3.4 Model-Based Systems Engineering 106
3.5 Modelling and Qualification 106
3.6 Summary 107
4 Writing and Reviewing Requirements 108
4.1 Introduction 108
4.2 Requirements for Requirements 109
4.3 Structuring Requirements Documents 109
4.4 Key Requirements 111
4.5 Using Attributes 112
4.5.1 Definition of a Requirement Expression 112
4.6 Ensuring Consistency Across Requirements 114
4.7 Value of a Requirement 115
4.8 The Language of Requirements 116
4.9 Requirement Boilerplates 118
4.10 Granularity of Requirements 120
4.11 Requirements and Modelling 122
4.12 Criteria for Writing Requirements Statements 122
4.13 Guide to Writing Requirements 124
4.14 Summary 126
5 Requirements Engineering in the Problem Domain 127
5.1 What is the Problem Domain? 127
5.2 Instantiating the Generic Process 128
5.3 Agree Requirements with Customer 130
5.4 Analyse & Model
5.4.1 Identify Stakeholders 131
5.4.2 Create Usage Model 132
5.4.2.1 Characteristics of Use Scenarios 134
5.4.3 Scoping the System 136
5.5 Derive Requirements 136
5.5.1 Define Structure 136
5.5.2 Capture Requirements 140
5.5.2.1 Sources of Stakeholder Requirements 140
5.5.2.2 Stakeholder Interviews 140
5.5.2.3 Extracting Requirements From Informal Documents 141
5.5.2.4 Identifying Capability Requirements From Scenarios 142
5.5.2.5 Requirements Workshops 143
5.5.2.6 Requirements Learnt From Experience 144
5.5.2.7 Requirements From Prototypes 144
5.5.2.8 Constraints in the Stakeholder Requirements 145
5.5.2.9 Refine Requirements 146
5.5.2.10 Derive Qualification Strategy 146
5.5.3 Define Acceptance Criteria 147
5.5.4 Define Qualification Strategy 147
5.6 Summary 148
6 Requirements Engineering in the Solution Domain 149
6.1 What is the Solution Domain 149
6.2 Engineering Requirements From Stakeholder Requirements to System Requirements 151
6.2.1 Producing the System Model 151
6.2.2 Creating System Models to Derive System Requirements 153
6.2.2.1 Internal Functionality 154
6.2.2.2 Interface Functionality 155
6.2.2.3 Human Interaction Functionality 156
6.2.2.4 Safeguard Functionality 156
6.2.2.5 System Transactions 157
6.2.2.6 Modes of Operation 158
6.2.2.7 Additional Constraints 158
6.2.3 Banking Example 158
6.2.3.1 Internal Functionality 158
6.2.3.2 Interface Functionality 159
6.2.3.3 Human Interaction Functionality 160
6.2.3.4 Safeguard Functionality 160
6.2.3.5 System Transactions 161
6.2.3.6 Modes of Operation 161
6.2.4 Car Example 161
6.2.4.1 Internal Functionality 163
6.2.4.2 Interface Functionality 163
6.2.4.3 Human Interaction Functionality 164
6.2.4.4 Safeguard Functionality 164
6.2.4.5 System Transactions 165
6.2.4.6 Modes of Operation 165
6.2.5 Deriving Requirements From a System Model 166
6.2.5.1 Create a Document Structure for the Requirements 166
6.2.5.2 Derive or Allocate Requirements 166
6.2.6 Agreeing the System Requirements with the Design Team 167
6.3 Engineering Requirements From System Requirements to Subsystems 168
6.3.1 Creating a System Architecture Model 168
6.3.2 Deriving Requirements From an Architectural Design Model 170
6.4 Other Transformations Using a Design Architecture 170
6.5 Summary 171
7 Advanced Traceability 173
7.1 Introduction 173
7.2 Elementary Traceability 174
7.3 Rationale 176
7.4 Satisfaction Statements 176
7.5 Rich Traceability 177
7.6 Supporting Information and Evidence 181
7.7 Sufficiency and Necessity 183
7.8 Reviewing Traceability 184
7.9 The Language of Satisfaction Statements 184
7.10 Rich Traceability Analysis 184
7.11 Requirements Flow-down 186
7.12 Rich Traceability for Qualification 187
7.13 Implementing Rich Traceability 188
7.13.1 Single-layer Rich Traceability 188
7.13.2 Multi-layer Rich Traceability 188
7.14 Design Documents 189
7.15 Metrics for Traceability 193
7.15.1 Breadth 194
7.15.2 Depth 195
7.15.3 Growth 195
7.15.4 Balance 196
7.15.5 Latent Change 197
7.16 Summary 199
8 DOORS: A Tool to Manage Requirements 201
8.1 Introduction 201
8.2 The Case for Requirements Management 202
8.3 DOORS Information Model 202
8.4 The Project Area 203
8.5 Modules as Documents 205
8.6 Artifacts 206
8.7 Traceability Links 208
8.8 Views 210
8.8.1 Rows in Views 211
8.8.2 Columns in Views 213
8.9 Artifact Types and Attributes 215
8.10 Import and Export 219
8.11 Summary 220
9 Management Aspects of Requirements Engineering 221
9.1 Introduction to Management 221
9.2 Requirements Management Problems 222
9.2.1 Summary of Requirement Management Problems 224
9.3 Managing Requirements in an Acquisition Organisation 224
9.3.1 Planning 224
9.3.2 Monitoring 227
9.3.3 Changes 227
9.4 Supplier Organisations 229
9.4.1 Bid Management 229
9.4.1.1 Planning 230
9.4.1.2 Monitoring 231
9.4.1.3 Changes 232
9.4.2 Development 233
9.4.2.1 Planning 233
9.4.2.2 Monitoring 234
9.4.2.3 Changes 235
9.5 Product Organisations 235
9.5.1 Planning 235
9.5.1.1 Single Product Version 235
9.5.1.2 Multiple Products and Versions 237
9.5.2 Monitoring 239
9.5.3 Changes 240
9.6 Agile Development 241
9.7 Organisational Culture 242
9.8 Summary 243
9.8.1 Planning 243
9.8.2 Monitoring 244
9.8.3 Changes 244
9.8.4 Organisational Culture 244
Bibliography 245
Index 248
Erscheint lt. Verlag | 23.8.2017 |
---|---|
Zusatzinfo | XX, 239 p. 161 illus. |
Verlagsort | Cham |
Sprache | englisch |
Themenwelt | Informatik ► Software Entwicklung ► Requirements Engineering |
Informatik ► Software Entwicklung ► User Interfaces (HCI) | |
Mathematik / Informatik ► Informatik ► Theorie / Studium | |
Schlagworte | DOORS • HCI • Human Computer Interaction • Requirements Engineering • Software engineering • Systems Engineering |
ISBN-10 | 3-319-61073-2 / 3319610732 |
ISBN-13 | 978-3-319-61073-3 / 9783319610733 |
Haben Sie eine Frage zum Produkt? |
![PDF](/img/icon_pdf_big.jpg)
Größe: 13,0 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich