Software Quality - Daniel Galin - ebook

Software Quality ebook

Daniel Galin

0,0
439,99 zł

Opis

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:

Androidzie
iOS
czytnikach certyfikowanych
przez Legimi
Windows
10
Windows
Phone

Liczba stron: 1077




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: