459,99 zł
- Wydawca: John Wiley & Sons
- Kategoria: Nauka i nowe technologie
- Język: angielski
- Rok wydania: 2018
The book presents a comprehensive discussion on Software Quality issues and Software Quality assurance (SQA) principles and practices, and lays special emphasis on implementing and managing SQA. Primarily designed to serve three audiences; universities and college students, vocational training participants, and software engineers and software development managers, the book may be applicable to all personnel engaged in a software projects Features: * A broad view of SQA. The book delves into SQA issues, going beyond the classic boundaries of custom-made software development to also cover in-house software development, subcontractors, and readymade software. * An up-to-date wide-range coverage of SQA and SQA related topics. Providing comprehensive coverage on multifarious SQA subjects, including topics, hardly explored till in SQA texts. * A systematic presentation of the SQA function and its tasks: establishing the SQA processes, planning, coordinating, follow-up, review and evaluation of SQA processes. * Focus on SQA implementation issues. Specialized chapter sections, examples, implementation tips, and topics for discussion. * Pedagogical support: Each chapter includes a real-life mini case study, examples, a summary, selected bibliography, review questions and topics for discussion. The book is also supported by an Instructor's Guide.
Ebooka przeczytasz w aplikacjach Legimi na:
Liczba stron: 1077
Podobne
CONTENTS
Cover
Series Page
Title Page
Copyright
Dedication
Preface
The Book Structure
Unique Features of This Book
The Author's Former Book on SQA
The Book's Audience
The Instructor's Guide
Acknowledgments
About the Author
Guides for Special Groups of Readers
Part I: Introduction
Chapter 1: SQA – Definitions and Concepts
1.1 Software Quality and Software Quality Assurance – Definitions
1.2 What is a Software Product?
1.3 The Principles of SQA
1.4 Software Errors, Faults, and Failures
1.5 The Causes of Software Errors
1.6 Software Quality Assurance Versus Software Quality Control
1.7 Software Quality Engineering and Software Engineering
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 2: Software Quality Factors (Attributes)
2.1 Complaints from the City Computer Club Members – an Introductory Mini Case
2.2 The Need for Comprehensive Software Quality Requirements
2.3 Mc Call's Classic Model for Software Quality Factors
2.4 The ISO/IEC 25010 Model and Other Alternative Models of Software Quality Factors
2.5 Software Compliance with Quality Factors
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 3: The Software Quality Challenges
3.1 Introduction
3.2 The Uniqueness of Software Quality Assurance
3.3 Software Development, Maintenance, and SQA Environment
Summary
Review Questions
Topics for Discussion
Chapter 4: Organization for Assuring Software Quality
4.1 Introduction
4.2 Top Management's Quality Assurance Activities
4.3 Department Managers with Direct Responsibilities for Quality
4.4 Project Management Responsibilities for Quality
4.5 The SQA Unit and its Associated Players in the SQA System
4.6 The Associated Players in the SQA System
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 5: The SQA World – An Overview
5.1 First Area: Introductory Topics (Part I of the Book)
5.2 Second Area: SQA Process Implementation Activities (Part II of the Book)
5.3 Third Area: Product Assurance Activities for Conformance (Part III of the Book)
5.4 Fourth Area: Process Assurance Activities for Conformance (Part IV of the Book)
5.5 Fifth Area: Additional Tools and Methods Supporting Software Quality (Part V of the book)
5.6 Sixth Area: Appendices (Part VI of the Book)
5.7 The SQA Hall of Fame
Part II: SQA Process Implementation Activities
Chapter 6: Establishing SQA Processes and Their Coordination with Relevant Software Processes
6.1 Establishing SQA Processes
6.2 Coordinating SQA Processes with Related Software Processes
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 7: SQA Plan and Project Plan
7.1 Introduction
7.2 The Process of Preparing an SQA Plan
7.3 The SQAP Elements
7.4 The Process of Preparing a Project Plan
7.5 Jack Thanks his Department Manager – a Mini Case
7.6 The Elements of the Project Plan
7.7 Project Plans for Small Projects and for Internal Projects
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Appendix 7.A Risk Management Activities and Measures
Chapter 8: Preproject Process – Contract Review
8.1 The CFV Project Completion Celebration – an Introductory Mini Case
8.2 Introduction
8.3 The Contract Review Process and its Stages
8.4 Contract Review Evaluation Subjects
8.5 Implementation of a Contract Review
8.6 Contract Reviews for Internal Projects
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Appendix 8.A: Proposal Draft Review
Appendix 8.B: Contract Draft Review
Chapter 9: Cost of Software Quality
9.1 This Time the Budget was Approved – an Introductory Mini Case
9.2 Objectives of Cost of Software Quality Measurement
9.3 The Classic Model of Cost of Software Quality
9.4 The Scope of the Cost of Software Quality – Industry Figures
9.5 An Extended Model for Cost of Software Quality
9.6 Application of a Cost of Software Quality System
9.7 Problems in Application of CoSQ Measurements
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 10: The Effectiveness and Cost of a V&V Plan – The SQA Model
10.1 The Data Required for the SQA Model
10.2 The SQA Model
10.3 Application of the SQA Model for Comparing V&V Plans
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 11: SQA Records and Documentation Control
11.1 Jeff's Troubles – an Introductory Mini-Case
11.2 Introduction
11.3 Objectives of Documentation Control Processes
11.4 The Implementation of Documentation Control
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Part III: Product Assurance Activities for Conformance
Chapter 12: Evaluation of Products for Conformance
12.1 Introduction
12.2 The Evaluation of Project Plans for Conformance
12.3 The Evaluation of Project's Software Products for Conformance
12.4 Evaluation of Project Products for Acceptability by the Customer
12.5 The Evaluation of Project's Operation Phase Products for Conformance
12.6 The Evaluation of Software Product by Measurements
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 13: Reviews
13.1 Introduction
13.2 The Happy Design Review – an Introductory Mini Case
13.3 Formal Design Reviews (DRS)
13.4 Peer Reviews
13.5 Expert Opinions
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 14: Software Testing
14.1 Introduction
14.2 Joe Decided to Skip In-process Testing – an Introductory Mini-case
14.3 Software Testing Strategies
14.4 Requirement-Driven Software Testing
14.5 Planning of the Testing Process
14.6 Designing the Testing Process
14.7 Implementation of the Testing Process
14.8 Automated Testing
14.9 Alpha and Beta Site Testing Programs
14.10 Code Review Activities for the Programming and Testing Phases
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 15: Assuring Software Quality Conformance for Operation Services
15.1 Introduction
15.2 HR Software's Success - an Introductory Mini Case
15.3 The Foundations of High-Quality Operation Services
15.4 Software Maintenance Maturity Model – a Model for the Operation Phase
15.5 Managerial Processes of Software Operation Quality Assurance
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 16: Software Product Quality Metrics
16.1 What are Software Quality Metrics? – an Introduction
16.2 Implementation of Software Quality Metrics
16.3 Product Metrics and Their Classification
16.4 Software Product Size Metrics
16.5 Software Product Attribute Metrics
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Appendix 16.A: FSM Method Implementation
Chapter 17: Procedures and Work Instructions
17.1 Introduction – the Need for Procedures and Work Instructions
17.2 Superbox Pays $9000 in Damages Due to Failing Support Center – a Mini Case
17.3 Procedures and Work Instructions and Their Conceptual Hierarchy
17.4 Procedures and Procedure Manuals
17.5 Work Instructions
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Appendix 17.A: Design Review Procedure
Part IV: Process Assurance Activities for Conformance
Chapter 18: Evaluation of Processes and Development Environment for Conformance
18.1 Introduction
18.2 The Evaluation of Life Cycle Processes and Plans for Conformance
18.3 The Evaluation of the Required Environment for Conformance
18.4 The Evaluation of Subcontractor Processes for Conformance
18.5 The Evaluation of Software Process by Measurements
18.6 The Assessment of Staff Skills and Knowledge
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 19: Improvement Processes – Corrective and Preventive Actions
Continual Improvement Requirement
19.1 The “3S” Development Team – Revisited – an Introductory Mini Case
19.2 Introduction
19.3 The Corrective and Preventive Actions Process
19.4 Organization for Preventive and Corrective Actions
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 20: Software Process Assurance Activities for External Participants
20.1 Introduction
20.2 The Pharmax Tender – a Mini Case
20.3 Benefits and Risks of Introducing External Performers
20.4 Benefits and Risks of Using Readymade Software
20.5 QA Activities for Assuring External Performers' Process Quality
20.6 QA Activities for Assuring Quality of Readymade Software
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 21: Software Process Quality Metrics
21.1 Software Process Metrics – an Introduction
21.2 North Against South – Who'll Win this Time Round? – a Mini Case
21.3 Software Development Process Metrics
21.4 Software Operation Process Metrics
21.5 Software Maintenance Process Metrics
21.6 Management Process Metrics
21.7 Limitations of Software Metrics
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 22: Software Change Control Processes
22.1 Introduction
22.2 How a Well-Planned Project Lost over Half a Million Dollars – a Mini Case
22.3 The Process of Handling an SCR
22.4 The SCC Function in the Organization
22.5 Software Quality Assurance Activities Related to Software Change Control
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 23: Staff Skills and Knowledge – Training and Certification
23.1 Introduction
23.2 Surprises for the “3S” Development Team – an Introductory Mini Case
23.3 The Objectives of Training
23.4 The Staff Training Process for Software Development
23.5 The Training Process for the SQA Function Team
23.6 The Objectives of Certification
23.7 The Certification Process
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Part V: Additional Tools and Methods Supporting Software Quality
Chapter 24: Templates and Checklists
24.1 Introduction
24.2 Templates
24.3 The Organizational Framework for Implementing Templates
24.4 Checklists
24.5 The Organizational Framework for Implementing Checklists
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 25: Configuration Management
25.1 Introduction
25.2 Software Configuration Items
25.3 Release of Software Configuration Versions
25.4 Documentation of Software Configuration Versions
25.5 Configuration Management Planning
25.6 Provision of SCM Information Services
25.7 Computerized Tools for Performing Configuration Management Tasks
25.8 The Software Configuration Management Function in the Organization
25.9 Software Quality Assurance Activities Related to SCM
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Chapter 26: Case Tools and IDEs – Impact on Software Quality
26.1 What is a CASE tool?
26.2 The Classic CASE Tool
26.3 IDE CASE Tools
26.4 Real CASE Tools
26.5 The Contribution of CASE Tools to Software Quality
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Part VI: Appendices
Appendix A: Software Development and Quality Assurance Process Standards
A.1 Introduction – Standards and Their Use
A.2 IEEE Std. 730-2014 Standard for Software Quality Assurance
A.3 ISO/IEC Std. 12207-2008: System and Software Engineering – Software Life Cycle Processes
A.4 IEEE Std. 1012-2012 Systems and Software Verification and Validation
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Appendix B: Software Quality Management Standards and Models
B.1 ABC Software Ltd – An Unnecessary Loss – a Mini-Case
B.2 The Scope of Quality Management Standards
B.3 Software Quality Management Standards as SPI Standards
B.4 ISO/IEC 90003
B.5 Capability Maturity CMMI Models -- Assessment Methodology
B.6 The SPICE Project and the ISO/IEC 15504 Software Process Assessment Standard
B.7 Additional Software Quality Management Standards
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Appendix C: Project Progress Control
C.1 Introduction
C.2 Finally, a Successful Project – a Mini Case
C.3 The Components of Project Progress Control
C.4 Progress Control of Distributed and Globally Distributed Software Development Projects
C.5 Progress Control of Internal Projects and External Participants
C.6 Implementation of Project Progress Control
C.7 Computerized Tools for Software Progress Control
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Appendix D: From SDLC to Agile – Processes and Quality Assurance Activities
D.1 The Classical Software Development Models
D.2 The Object-Oriented Model
D.3 The Incremental Delivery Model
D.4 The Staged Model
D.5 The Agile Methodology Models
Summary
Selected Bibliography
Review Questions
Topics for Discussion
Author Index
Subject Index
End User License Agreement
List of Tables
Table A.1
Table A.2
Table A.3
Table B.1
Table B.2
Table B.3
Table D.1
Table D.2
Table D.3
Table D.4
Table D.5
Table D.6
Table D.7
Table D.8
Table 1.1
Table 2.1
Table 2.2
Table 2.3
Table 7.A.1
Table 8.1
Table 8.2
Table 8.A.1
Table 8.B.1
Table 9.1
Table 9.2
Table 9.3
Table 9.4
Table 9.5
Table 10.1
Table 10.2
Table 10.3
Table 10.4
Table 10.5
Table 10.6
Table 12.1
Table 13.1
Table 13.2
Table 13.3
Table 13.4
Table 14.1
Table 14.2
Table 14.3
Table 14.4
Table 14.5
Table 14.6
Table 14.7
Table 14.8
Table 14.9
Table 14.10
Table 15.1
Table 16.1
Table 16.2
Table 16.3
Table 16.4
Table 16.5
Table 16.6
Table 16.7
Table 16.8
Table 16.9
Table 16.10
Table 16.11
Table 16.12
Table 16.A.1
Table 16.A.2
Table 16.A.3
Table 16.A.4
Table 18.1
Table 19.1
Table 19.2
Table 20.1
Table 21.1
Table 21.2
Table 21.3
Table 21.4
Table 21.5
Table 21.6
Table 21.7
Table 21.8
Table 21.9
Table 21.10
Table 21.11
Table 21.12
Table 21.13
Table 21.14
Table 21.15
Table 21.16
Table 21.17
Table 21.18
Table 21.19
Table 25.1
Table 25.2
Table 25.3
Table 26.1
List of Illustrations
Figure A.1
Figure B.1
Figure B.2
Figure B.3
Figure B.4
Figure B.5
Figure C.1
Figure C.2
Figure C.3
Figure C.4
Figure D.1
Figure D.2
Figure D.3
Figure D.4
Figure D.5
Figure D.6
Figure 1.1
Figure 2.1
Figure 3.1
Figure 3.2
Figure 4.1
Figure 4.2
Figure 5.1
Figure 7.1
Figure 8.1
Figure 9.1
Figure 9.2
Figure 9.3
Figure 10.1
Figure 10.2
Figure 10.3
Figure 13.1
Figure 14.1
Figure 14.2
Figure 14.3
Figure 15.1
Figure 16.1
Figure 16.A.1
Figure 17.1
Figure 19.1
Figure 20.1
Figure 21.1
Figure 23.1
Figure 23.2
Figure 24.1
Figure 26.1
Guide
Cover
Table of Contents
Begin Reading
Part 1
Chapter 1
Pages
ii
iii
iv
v
vi
xvii
xviii
xix
xx
xxi
xxii
xxiii
xxiv
xxv
xxvi
xxvii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
IEEE Press Editorial Board
Ekram Hossain, Editor in Chief
Giancarlo Fortino
Andreas Molisch
Linda Shafer
David Alan Grier
Saeid Nahavandi
Mohammad Shahidehpour
Donald Heirman
Ray Perez
Sarah Spurgeon
Xiaoou Li
Jeffrey Reed
Ahmet Murat Tekalp
About IEEE Computer Society
IEEE Computer Society is the world's leading computing membership organization and the trusted information and career-development source for a global workforce of technology leaders including: professors, researchers, software engineers, IT professionals, employers, and students. The unmatched source for technology information, inspiration, and collaboration, the IEEE Computer Society is the source that computing professionals trust to provide high-quality, state-of-the-art information on an on-demand basis. The Computer Society provides a wide range of forums for top minds to come together, including technical conferences, publications, and a comprehensive digital library, unique training webinars, professional training, and the TechLeader Training Partner Program to help organizations increase their staff's technical knowledge and expertise, as well as the personalized information tool myComputer. To find out more about the community for technology leaders, visit http://www.computer.org.
IEEE/Wiley Partnership
The IEEE Computer Society and Wiley partnership allows the CS Press authored book program to produce a number of exciting new titles in areas of computer science, computing, and networking with a special focus on software engineering. IEEE Computer Society members continue to receive a 15% discount on these titles when purchased through Wiley or at wiley.com/ieeecs.
To submit questions about the program or send proposals, please contact Mary Hatcher, Editor, Wiley-IEEE Press: Email: [email protected], Telephone: 201-748-6903, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774.
Software Quality
Concepts and Practice
Daniel Galin
This edition first published 2018
© 2018 the IEEE Computer Society, Inc.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.
The rights of Daniel Galin to be identified as the author of this work have been asserted in accordance with law.
Registered Office
John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA
Editorial Office
111 River Street, Hoboken, NJ 07030, USA
For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.
Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Some content that appears in standard print versions of this book may not be available in other formats.
Limit of Liability/Disclaimer of Warranty
While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
Library of Congress Cataloging-in-Publication Data
Names: Galin, Daniel, author.
Title: Software quality : concepts and practice / by Daniel Galin.
Description: Hoboken, NJ : John Wiley & Sons, 2017. | Includes bibliographical references and index. |
Identifiers: LCCN 2017039554 (print)| LCCN 2017044698 (ebook) | ISBN 9781119134503 (pdf) | ISBN 9781119134510 (epub) | ISBN 9781119134497 (cloth)
Subjects: LCSH: Computer software–Quality control.
Classification: LCC QA76.76.Q35 (ebook) | LCC QA76.76.Q35 G35 2017 (print) | DDC 005.3028/7–dc23
LC record available at https://lccn.loc.gov/2017039554
Cover Design: Wiley
Cover Images: (Codes) © Degui Adil/EyeEm/Gettyimages; (Three Checks) © NuStock/Gettyimages
To my beloved family, Amira, Michal, Yoav, Guy and Maayan. I love all of them.
Preface
The following software “glitches” seem very real:
Thousands of the US students in numerous cities around the United States had just taken their examination. Tired and excited, they pressed the submit button only to find that their answers could not be uploaded with the software (purchased specifically for this purpose). As expected, the anger, utter frustration, and disappointment of the students turned into a flood of lawsuits against the exam software company.
More than 24 inmates from a US jail were wrongly released, among them were prisoners jailed for violent crimes. The faulty release was caused by the erroneous release of documents that were produced by a new software system recently implemented to manage the institute's records. According to the spokesman of the county jail, the mistake was due to glitches in the software, which caused the misprocessing of a number of input documents. The early detection of the software failure prevented a much higher number of faulty inmate releases.
A software failure in an income tax collection system caused millions of citizens to use the wrong tax code in the income tax site program. This mistake caused many people to pay less than required, and many to pay more than required. Unfortunately, it took a whole year to identify the failure. Naturally, the inevitable happened, and the income tax department now faces innumerable filings for tax returns. Only when these return procedures have concluded, will the income tax department be able to estimate the total damage caused by the software failure.
The above are just a sample of glitches that happen every day. These software failures have the potential to cause substantial damages. Every single one of them could have been eliminated, or practically eliminated, if only the software project teams would have performed appropriate software quality assurance processes, and SQA professionals would have carried out properly the required process coordination, follow-up, and evaluation tasks. These software quality assurance processes, and many more, are the contents of my book Software Quality: Concepts and Practice.
The Book Structure
The book is structured in six parts that follow the IEEE Std. 730:2014 outline:
Part I: Introduction – Presents definitions and topics associated with software quality.
Part II: SQA Process Implementation Activities –Dedicated to software quality assurance activities of the SQA function, and includes establishing the SQA processes in the organization, planning the SQA activities, and the application of software quality costs.
Part III: Product Assurance Activities for Conformance – Deals with evaluation and product quality measurement.
Part IV: Process Assurance Activities for Conformance – Discusses process quality evaluation and measurement, process improvements, and also the assessment of staff skills and knowledge and the required training.
Part V: Additional Tools and Methods Supporting Software Quality – Presents configuration management, CASE tools, and the topic of templates and checklists – all of significant contribution to achieve software quality requirements.
Part VI: Appendices – Presents basic software quality and software engineering topics associated with SQA: software engineering and SQA standards and models and project progress control. This part also includes a review of software development methodologies and processes, and their quality assurance activities.
Unique Features of This Book
The following key features of this book are of special importance:
A broad view of SQA.
The book delves extensively into the SQA subject matter and covers issues much beyond the classic boundaries of custom-made software development by large established software houses. It dedicates significant attention to issues related to in-house software development, subcontractors, suppliers of readymade software, and other external participants in the software development process, and also covers small software projects.
An up-to-date wide range coverage of SQA and SQA-related topics.
The book provides comprehensive coverage on a wide range of SQA and SQA-related subjects, and includes topics that are rarely discussed in SQA texts. These include procedures and work instructions, tools and supporting techniques such as templates and checklists, documentation control, staff certification, and cost of software quality.
A comprehensive discussion of new technology and methodology topics.
The text covers extensively the current SQA topics, and discusses the impact of new software development methodologies, computerized SQA tools, and international SQA standards.
A thorough presentation of the SQA function.
and its tasks Establishes the SQA processes, planning, coordinating, follow-up, reviewing and evaluation of SQA processes performed by software process teams and others.
Special emphasis on the SQA plan and project plan topics.
The processes of preparing and updating the plans and their implementation are discussed in detail.
Special attention is given to SQA implementation issues.
Throughout the book a focus is placed on implementation issues in specialized chapter sections, examples, implementation tips and topics for discussion.
Consistent structure in each chapter:
A mini case study at the beginning followed by subject matter that includes examples, summary, selected bibliography, review questions, and topics for discussion – the book is tailor-made for semester classes in software engineering programs, and should prove to be very useful as a textbook for many different courses.
An Instructor's Guide
The Author's Former Book on SQA
The author's former book Software Quality Assurance: From Theory to Implementation, (Addison-Wesley, 2004) had a wide readership and was also adopted as a textbook for a variety of courses in numerous faculties at higher education institutes and professional training and hi-tech upskill courses around the world.
The current book differs from the previous (2004) book mainly in the following ways:
The book's topics themselves and their coverage have been updated according to technological and methodological developments.
New topics have been added to the already wide variety of subjects covered by the 2004 book.
The subject of SQA function has received substantially more attention, and the book provides a thorough presentation of the SQA function and its tasks.
The structure of the book now follows the IEEE Std. 730: 2014 outline.
The readability of the book has been improved, notably by the many mini cases that open the chapters.
The Book's Audience
The book is intended to address challenges faced by a wide audience interested in software quality assurance. The five main audience types are as follows:
University and college students
Software engineering practitioners, naturally involved in quality issues of software development and maintenance
Practitioners of software quality assurance
Vocational training course – students and lecturers
Managers of software development departments, project managers, and others
Special interest groups of readers
Readers interested in the ISO 9000-3 Standard.
Readers interested in the ASQ Certified software quality engineers (CSQE) body of knowledge.
Readers interested in the QAI (Quality Assurance Institute) CSQA CBOK (Certified Software Quality Analyst common body of knowledge).
Readers of both interest groups will find comprehensive discussions on both topics throughout the book.
The Instructor's Guide
An Instructor's Guide that includes PowerPoint presentations for each of the book's chapters has been prepared by the author.
The guide is available to instructors who have adopted the book for a course. It can be obtained by sending an email to [email protected]
Acknowledgments
I would like to take this opportunity to express my heartfelt gratitude to all those who helped me write this book. This book has benefited from practical experience gained from consulting projects, and greatly from interactions with students throughout numerous sessions and courses. I have not listed all the names here, albeit I am grateful to each and every one of them.
I owe many thanks to my reviewers for their important comments that contributed greatly to this book.
Special thanks to Ms. Mary Hatcher, Editor at Wiley-IEEE Press for her cooperation, guidance, and valuable advice throughout the writing and publishing process. I would also like to express my appreciation and thanks to Victoria Bradshaw, Vishnu Narayanan, and Melissa Yanuzzi at Wiley, as well as Abhishek Sarkari at Thomson Digital typesetter, responsible for production of this book.
I wish to express my appreciation to Lisa Harel, who edited my drafts with devotion and contributed substantially to their readability and accuracy.
Finally, I wish to express my gratitude to my family: my wife, Amira Galin, who is a constant source of inspiration, has always encouraged scientific thinking and is a role model, and my daughter, Michal, and my son, Yoav, for their continuous support, important comments on the book's drafts, and for always believing.
About the Author
Dr. Daniel Galin received his BSc in Industrial and Management Engineering, and his MSc and DSc in Operations Research from the Faculty of Industrial Engineering and Management, the Technion – Israel Institute of Technology, Haifa, Israel.
He acquired his expertise in SQA through many years of consulting, teaching, and writing in the field. His courses include software quality assurance, analysis and design of information systems, and strategic information systems. Dr. Galin has been a member of staff at the faculty of the Lander Institute in Jerusalem and the Ruppin Academic Center, where he headed the Information Systems Studies.
Dr. Galin published a book entitled Software Quality Assurance: From Theory to Implementation (Addison-Wesley, 2004), and an earlier book on the same topic, coauthored with Dr. Z. Bluvband, entitled Software Quality Assurance, (Opus, 1995 – in Hebrew). Many of his papers have been published in English language professional journals. Dr. Galin has also authored additional books in Hebrew, which were published by Israel's leading publishers.
Guides for Special Groups of Readers
Among the readers interested in software quality assurance, one can distinguish two special groups:
Readers interested in the ASQ (American Society for Quality) CSQE BOK E (Certified Software Quality Engineer body of knowledge).
Readers interested in the QAI (Quality Assurance Institute) CSQA CBOK (Certified Software Quality Analyst common body of knowledge).
Guide to the ASQ's CSQE Body of Knowledge
Almost all the elements of the CSQE (Certified Software Quality Engineer) body of knowledge, as outlined in ASQ (American Society for Quality), are available in the book. The following table directs the reader to the relevant chapters and sections.
CSQE BOK 2016 Table
CSQE BOK chapter
CSQE BOK subject
Book reference
I. General knowledge
A
Benefits of software quality engineering
Section 1.1, Chapter 18
B
Ethical and legal compliance
—
C
Standards and models
Appendices A and B
D
Leadership skills
Chapter 4
E
Team skills
Chapter 23
II. Software quality management
A
Quality management system
Sections 6.1, 7.4, 20.3, and 20.5, Chapter 11
B
Methodologies
Chapters 9, 13, and 19
C
Audits
Sections 6.2, 12.4, and 15.5
III. System and software engineering
A
Lifecycle and process models
Appendices .D.1, D.3, and D.5
B
System architecture
—
C
Requirement engineering
Chapter 2
D
Requirement management
Chapter 22
E
Software analysis, design and development
Chapter 2, Appendix D
F
Maintenance management
Chapter 15
IV. Project management
A
Planning, scheduling, and deployment
Sections 7.4–7.6
B
Tracking and controlling
Section 6.2, Appendix C
C
Risk management
Section 7.4
V. Software metrics and analysis
A
Process and product measurement
Chapters 16 and 21
B
Analysis and reporting techniques
—
VI. Software verification and validation
A
Theory
Chapters 12 and 14
B
Test planning and design
Chapter 14, Section 20.5 and 20.6
C
Reviews and inspections
Chapter 13
D
Test execution documents
Sections 14.7 and 14.8
VII. Software configuration management
A
Configuration infrastructure
Section 25.3
B
Configuration identification
Section 25.2
C
Configuration control and status accounting
Section 25.6
D
Configuration audits
Section 25.9
E
Product release and distribution
Sections 25.3, 25.7, and 25.8
Guide to the QAI's CSQA Common Body of Knowledge
Almost all the elements of the CSQA (Certified Software Quality Analyst) common body of knowledge, as outlined in the QAI (Quality Assurance Institute), are available in the book. The following table directs the reader to the relevant chapters and sections.
CSQA CBOK 2012 Table
CSQA CBOK chapter
CSQA CBOK subject
Book reference
SC1. Quality principles and conceptions
1.1
Vocabulary of quality
Section1.1
1.2
The different views of quality
Section 1.1, Chapter 2
1.3
Quality concepts and practices
Section 1.3,
1.4
Quality control and quality assurance
Section 1.6
1.5.
Quality pioneers approach to quality
—
SC2. Quality leadership
2.1
Leadership concepts
Section 6.2
2.2
Quality management infrastructure
Chapter 4
2.3
Quality environment
Section 3.3
SC3. Quality baseline
3.1
Quality baseline concepts
Section 25.2
3.2
Methods used for establishing baselines
Section 25.3
3.3
Models and assessment fundamentals
Appendices B.5 and B.6
3.4
Industry quality models
Appendices A and B
SC4. Quality assurance
4.1
Establishing a function to promote and manage quality
Sections 3.3, 4.5, Chapter 6
4.2
Quality tools
Appendix C
4.3
Process deployment
—
4.4
Internal auditing and quality assurance
Appendix C.5
SC5. Quality planning
5.1
Planning concepts
Sections 7.2 and 7.4
5.2
Integrating business and quality planning
—
5.3
Prerequisites to quality planning
Section 7.3
5.4
The planning to mature IT work processes
Section 7.4, Appendices B.5.3 and B.6.3
SC6. Define, build, implement, and improve work processes
6.1
Process management concepts
Section 18.1
6.2
Process management processes
—
SC7. Quality control practices
7.1
Testing concepts
Section 14.1
7.2
Developing testing methodologies
Section 14.3
7.3
Verification and validation methods
Sections 14.5 and 14.6
7.4
Software change control
Chapter 22
7.5
Defect management
Section 21.3
SC8. Metrics and measurements
8.1
Measurement concepts
Section 16.2.1
8.2
Measurement in software
Chapters 16 and 21
8.3
Variation and process capability
Appendices B.5.2 and B.6.3
8.4
Risk management
Section 7.3, Appendix C.3
8.5
Implementing and measurement program
Section 16.2.4 and 21.7
SC9. Internal control and security
9.1
Principles and concepts of internal control
Section 6.1
9.2
Risk and internal control models
—
9.3
Building internal controls
Chapter 6
9.4
Building adequate security
—
SC10. Outsourcing, COTS, and contracting quality
10.1
Quality and outside software
Sections 20.3 and 20.4
10.2
Selecting COTS software
Sections 20.5 and 20.6
10.3
Selecting software developed by outside organizations
Section 20.5.1
10.4
Contracting for software developed by outside organizations
Sections 20.5.1 and 20.6.1
10.5
Operating for software developed by outside organizations
Section 20.3 and 20.6.2
Part IIntroduction
The opening part of the book presents definitions and background subjects related to software quality:
SQA – definitions and concepts (
Chapter 1
)
Software quality factors (attributes) (
Chapter 2
)
SQA challenges (
Chapter 3
)
Organization for assuring software quality (
Chapter 4
)
An additional chapter,
Chapter 5
, presents “the world of SQA”, an overview of the book.
Chapter 1SQA – Definitions and Concepts
1.1 Software Quality and Software Quality Assurance – Definitions
We shall Start by delving into our target topic of software quality and discuss the following basic definitions:
Software quality
Software quality assurance (SQA)
Software quality assurance – an expanded definition
The objectives of SQA activities
The definition of software quality is shown in Frame 1.1.
Frame 1.1: Software Quality – a Definition
Source: IEEE Std. 730-2014 (IEEE, 2014)
Software quality is
The degree to which a software product meets established requirements; however, quality depends upon the degree to which established requirements accurately represent stakeholder needs, wants, and expectations.
Two aspects of software quality are presented in the above definition: one is meeting the requirements, while the other is generating customer/stakeholder satisfaction. A high quality software product is expected to meet all written development requirements – whether defined fully before the development began, or later in the course of the development process – and to meet the relevant regulations and professional conventions. Quality is also achieved through fulfillment of stakeholder needs and wants.
Software Quality Assurance – Definition
One of the most commonly used definitions of SQA is proposed by the IEEE, cited in Frame 1.2.
Frame 1.2: Software Quality Assurance – a Definition
Source: IEEE Std. 730-2014
Software quality assurance is
A set of activities that define and assess the adequacy of software process to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended processes. A key attribute of SQA is the objectivity of the SQA function with respect to the project. The SQA function may also be organizationally independent of the project, that is, free from technical, managerial, and financial pressures from the project.
This definition may be characterized by the following:
Plan and implement systematically. SQA is based on the planning and implementation of a series of activities that are integrated into all stages of the software development process. These activities are performed in order to substantiate the client's confidence that the software product will meet all the technical requirements.
Refer to the software development products keeping the specified technical requirements and suitability for stake holder's intended use. However, it does not include quality of the operation services.
Refer to the technical appropriateness of the development process. However, important attributes of the development process, namely schedule and budget keeping, are not included. It is noteworthy that:
The appropriateness of project schedule and budget is a major issue in SQA as can be seen by requirement for performing contract reviews and project planning.
The major part of project progress control procedures, given to the issues of schedule and budget.
The close relationships that exist between software product quality, project schedule, and project budget, where schedule and budget failures result, almost always, in unavoidable software quality failure.
An extended SQA definition was created considering the importance of the quality of the software operation and the important effect of schedule and budget keeping on the software quality product.
The resulting expanded SQA definition is shown in Frame 1.3.
Frame 1.3: Software Quality Assurance – an Expanded Definition
Software quality assurance
A set of activities that define and assess the adequacy of software process to provide evidence that establishes confidence that the software processes are appropriate for producing software products of suitable quality, for their intended processes, or for their intended operation services and fulfils the requirements of schedule and budget keeping
The Objectives of SQA Activities
The objectives of SQA activities refer to the functional and managerial aspects of software development and software maintenance. These objectives are listed in Frame 1.4.
Frame 1.4: The Objectives of SQA Activities
The objectives of SQA activities are
Ensuring an acceptable level of confidence that the software product and software operation services will conform to functional technical requirements and be suitable quality for its intended use.
According to the extended SQA definition – ensuring an acceptable level of confidence that the software development and software operation process will conform to scheduling and budgetary requirements.
Initiating and managing activities to improve and increase the efficiency of software development, software operation, and SQA activities. These activities yield improvements to the prospects' achieving of functional and managerial requirements while reducing costs.
The other sections of the chapter deal with the following issues:
What is a software product?
The principles of SQA
Software errors, faults, and failures
The causes of software errors
Software quality assurance versus software quality control (SQC)
Software quality engineering and software engineering
1.2 What is a Software Product?
Intuitively, when we think about software, we imagine an accumulation of programming language instructions and statements, usually referred to as “code.” However, when referring to a professional software product, “code” by itself is not sufficient. Software products need to undergo defect corrections, and other maintenance services, which typically include user instruction, corrections, adaptations, and improvements of the software product during their life cycle. Accordingly, software products also comprise components, required to ensure operational success of the services provided by the product. The ISO/IEC/IEEE definition shown in Frame 1.5 lists these components.
Frame 1.5: Software Product Definition
Source: ISO/IEC/IEEE Std. 90003:2014 (ISO/IEC/IEEE, 2014)
Software product is
Set of computer programs, procedures, and possibly associated documentation and data.
The software product components are:
Computer programs “the code”
.
The computer programs activate the computer system to perform the required applications. The computer programs include several types of code, such as source code, executable code, test code, and so on.
Procedures
.
Procedures define the order and schedule within which the software or project programs are performed, the method for handling common malfunctioning of software products, and so on.
Documentation
.
The purpose of the documentation is to instruct or support new software product version developers, maintenance staff, and end users of the software product. It includes the various design reports, test reports, and user and software manuals, and so on.
Data necessary for operating the software system
.
The required data include lists of codes and parameters, and also standard test data. The purpose of the standard test data is to ascertain that no undesirable changes in the code or software data have occurred during bug corrections and other software maintenance activities, and to support the detection of causes for any malfunctioning.
To summarize the above discussion, the definition of a software product is presented in Frame 1.6.
Frame 1.6: Software Product Definition
Software product is
A collection of components necessary to ensure proper operation, and efficient maintenance during its life cycle. The components include (1) computer programs (“code”), (2) documentation, (3) data necessary for its operation and maintenance (including standard test), and (4) procedures.
It should be noted that software quality assurance refers to the quality of all components of the software product, namely, the code, documentation, necessary operating and standard test data, and procedures. Moreover, the composition of software product components varies significantly according to the software development tools and methodology.
1.3 The Principles of SQA
Source: after ISO 9000:2000 (ISO, 2000)
The following principles guide organizations in their process to ensure the software quality of their software products and services satisfies the needs and wants of stakeholders.
Customer focus.
Organizations depend on their customers, and thus need to understand their current and future needs, fulfill their requirements, and achieve their satisfaction.
Leadership.
An organization's leaders should create an internal environment in which employees are involved in achieving the quality targets.
Involvement of people-employees.
The involvement of employees at all levels enables benefiting from their capabilities to promote software quality issues.
Process approach.
Managing activities and resources as processes results in their improved efficiency.
System approach to management.
Process management achieves higher effectiveness and efficiency through identification, analysis, and understanding of interrelated processes.
Continual improvement.
Continual combined improvement of quality and processes' effectiveness and efficiency performance are a permanent objective of the organization.
Factual approach of decision-making.
Decisions should be based on data and information.
Mutually beneficial supplier relationships.
Understanding that an organization's supplier relationships based on mutual benefits contributes to improved performance of the organization with regard to quality, efficiency, and effectiveness.
1.4 Software Errors, Faults, and Failures
To better understand the essence of software errors, faults, and failures, let us take a look at the performance of a deployed software system, as perceived by customers.
Example: The Simplex HR is a software system that has been on the market for 7 years. Its software package currently serves about 1200 customers.
One of the staff from the Simplex HR Support Centre reported a number of quotes from typical customer complaints:
“We have been using the Simplex HR software in our Human Resources Department for about four years, and have never experienced a software failure. We have recommended the Simplex HR to our colleagues.”
Immediately following this positive testimony, the same employee complained that he could not prepare a simple monthly report.
“I started to use the Simplex HR two months ago; we have experienced so many failures that we are considering replacing the Simplex-HR software package.”
“We have been using the software package for almost five years, and were very satisfied with its performance, until recently. During the last few months, we suddenly found ourselves having to contend with several severe failures.”
Is such a variation in user experience relating to failures possible for the very same software package?
Can a software package that successfully served an organization for a long period of time “suddenly” change its nature (quality) and be full of bugs?
The answer to both these questions is YES, and the reason for this is rooted in the very characteristics of software errors.
The origin of software failures lies in a software error made by a software designer or programmer. An error may refer to a grammatical error in one or more of the code lines, or a logical error in carrying out one or more of the specification requirements.
A software fault is a software error that causes improper functioning of the software in a specific application, and in rare cases, of the software in general. However, not all software errors become software faults. In many other cases, erroneous code lines will not affect the functionality of the software (software faults are not caused). It should be noted that in some software fault cases, the fault is corrected or “neutralized” by subsequent code lines.
Naturally, our interest lies mainly in software failures that disrupt the use of the software. A software failure is a result of a software fault, hence our next question.
Do all software faults inevitably cause software failures? Not necessarily: A software fault becomes a software failure only when it is “activated” – that is when the software user tries to apply the specific, faulty application. In many cases, a software fault is in fact never activated. This is either due to the user's lack of interest in the specific application, or to the fact that the combination of conditions necessary to activate the software fault never occurs. The following two examples demonstrate the software fault – software failure relationships.
Example 1 The Simplex HR Software Package
Let us return to the Simplex HR software package mentioned above.
The software package includes the following fault:
Overtime compensation – This function was defined to allow two levels of daily overtime, where the user can specify the details and compensation per each level. For instance, the first 2 hours' overtime (level 1) should be paid at a rate that is 25% more than the regular hourly rates, while each following additional hour (level 2) should be paid at a rate that is 50% more than the regular hourly rates.
The programmer's mistake caused the following fault: In cases when two levels of overtime were reported, the higher compensation was paid for overtime hours reported for both the levels.
Let us now examine the software failures experienced by two of Simplex HR users:
A chain of pharmacies
Overtime pay – The policy of the chain was to implement overtime for no more than 2 hours on top. The first level of overtime compensation was defined at 3 hours.
Thanks to its policy, the chain did not experience software failures relating to the overtime features?
A regional school
Overtime pay – The school has lately introduced the Simplex HR software package to support the management of its teacher staff. Cases of overtime happen quite frequently, and are due to the replacement of teachers on sick leave, personal leave of absence, and so on. The teachers' compensation was 30% above their hourly regular rate for the first 2 hours (level 1), and 75% above their hourly rate per each additional hour overtime (level 2). The failure related to overtime calculations was evident from the first salary calculations. Teachers who worked relatively long hours' overtime (over 2 hours per time) in the past months were both astonished and delighted to discover significantly higher overtime compensation than anticipated.
It should be noted that once software failures are identified, Simplex HR maintenance team is expected to correct them.
Example 2 The “Meteoro-X” Meteorological Equipment Firmware
Meteoro-X is a computerized recording and transmission equipment unit designed for meteorological stations that perform temperature and precipitation measurements. The Meteoro-X is also equipped with three wind vanes for wind velocity measurements. Meteorological measurements are defined to be transmitted every 5 minutes to a meteorological center.
“Meteoro-X” firmware (software embedded in the product) includes the following software fault:
Temperature threshold – The safety control specifications require shutting down the equipment if its temperature rises above 50 degrees centigrade.
The programmer error that resulted in a software fault – he registered the threshold as 150 degrees centigrade. This fault could only be noted, and consequently cause damage, when the equipment was subjected to temperatures measuring higher than 50 degrees.
Let us now examine the failure experienced by some of the Meteoro-X users:
Meteorological authorities of a southern European country
Temperature threshold – The Meteoro-X performed with no failures for about 3 years, due to the fact that temperatures higher than 50 degrees centigrade had not been recorded. It was only in the month of August of the fourth year when temperatures reached 57 degrees centigrade that an equipment disaster in one of the meteorological stations occurred.
North European Meteorological Board
Temperature threshold – The Meteoro-X had no failures due to the fact that temperatures higher than 50 degrees centigrade were not recorded.
A review of the specification document and the relevant code modules revealed the causes of the software faults, and enabled their correction.
These examples clearly demonstrate that at some time during the software service, some software faults will become software failures. Other software faults, and in some cases even a major portion of them, will remain hidden, invisible to software users, only to be activated when specific conditions are in place.
Figure 1.1 illustrates the relationships between software errors, faults, and failures; of the 17 software errors yielded in the development process, 8 become software faults, while only 3 of these faults become software failures. The customer's software usage characteristics determine which software applications are used, and thereby which faults become failures. In other words, the characteristics serve as a “failure filter.”
Figure 1.1 Software errors, software faults, and software failures
1.5 The Causes of Software Errors
As software errors are the cause of poor software quality, it is important to investigate their causes, in order to prevent them. It should be noted that these errors are all human errors, made by system analysts, programmers, software testers, documentation experts, managers, and sometimes clients and their representatives. Even in rare cases where software errors may be caused by the development environment: interpreters, wizards, automatic software generators, and so on, it is reasonable to claim that these too are human errors, as someone is responsible for the failure of the development. The causes of software errors can be classified according to the stages of the software development process in which they occur. A classification of error causes into nine classes is presented:
Faulty definition of requirements
A faulty definition of a requirement, usually prepared by the client, is one of the main causes of software errors. The most common errors of this type are:
Erroneous definition of requirements
Lack of essential requirements
Incomplete requirements definition
For instance, one of the requirements of a municipality's local tax software system refers to discounts granted to various segments of the population: senior citizens, parents of large families, and so on. Unfortunately, a discount granted to students was not included in the requirements document.
Inclusion of unnecessary requirements, functions that are not expected to be applied.
Client–developer communication failures
Misunderstandings resulting from defective client–developer communication are additional causes for errors that prevail in the early stages of the development process:
Misunderstanding of the client's instructions in the requirement document.
Misunderstanding of the client's requirement changes presented to the developer in written form or verbally during the development period.
Misunderstanding of the client's responses to design issues presented by the developer.
Lack of attention to client messages relating to requirement changes, and client responses to questions raised by the developer.
Deliberate deviations from software requirements
In several circumstances, developers may deliberately deviate from the documented requirements – an action that often causes software errors. The most common situations of deliberate deviations are:
