Guide to the Software Engineering Body of Knowledge Version 3.0 PDF

 Guide to the Software Engineering Body of Knowledge Version 3.0 SWEBOK ® A Project of the IEEE Computer Society  Guide to the Software Engineering Body of Knowledge Version 3.0...

 Guide to the Software Engineering Body of Knowledge Version 3.0 SWEBOK ® A Project of the IEEE Computer Society  Guide to the Software Engineering Body of Knowledge Version 3.0 Editors Pierre Bourque, École de technologie supérieure (ÉTS) Richard E. (Dick) Fairley, Software and Systems Engineering Associates (S2EA) Copyright and Reprint Permissions. Educational or personal use of this material is permitted without fee provided such copies 1) are not made for profit or in lieu of purchasing copies for classes, and that this notice and a full citation to the original work appear on the first page of the copy and 2) do not imply IEEE endorsement of any third-party products or services. Permission to reprint/republish this material for commercial, advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from IEEE by writing to the IEEE Intellectual Property Rights Office, 445 Hoes Lane, Piscataway, NJ 08854-4141 or [email protected]. Reference to any specific commercial products, process, or service does not imply endorsement by IEEE. The views and opin- ions expressed in this work do not necessarily reflect those of IEEE. IEEE makes this document available on an “as is” basis and makes no warranty, express or implied, as to the accuracy, capabil- ity, efficiency merchantability, or functioning of this document. In no event will IEEE be liable for any general, consequential, indirect, incidental, exemplary, or special damages, even if IEEE has been advised of the possibility of such damages. Copyright © 2014 IEEE. All rights reserved. Paperback ISBN-10: 0-7695-5166-1 Paperback ISBN-13: 978-0-7695-5166-1 Digital copies of SWEBOK Guide V3.0 may be downloaded free of charge for personal and academic use via www.swebok.org. IEEE Computer Society Staff for This Publication Angela Burgess, Executive Director Anne Marie Kelly, Associate Executive Director, Director of Governance Evan M. Butterfield, Director of Products and Services John Keppler, Senior Manager, Professional Education Kate Guillemette, Product Development Editor Dorian McClenahan, Education Program Product Developer Michelle Phon, Professional Education & Certification Program Coordinator Jennie Zhu-Mai, Editorial Designer IEEE Computer Society Products and Services. The world-renowned IEEE Computer Society publishes, promotes, and dis- tributes a wide variety of authoritative computer science and engineering journals, magazines, conference proceedings, and professional education products. Visit the Computer Society at w ­ ww.computer.org for more information.  TABLE OF CONTENTS Forewordxvii Foreword to the 2004 Edition xix Editorsxxi Coeditorsxxi Contributing Editors xxi Change Control Board xxi Knowledge Area Editors xxiii Knowledge Area Editors of Previous SWEBOK Versions xxv Review Team xxvii Acknowledgements  xxix Professional Activities Board, 2013 Membership xxix Motions Regarding the Approval of SWEBOK Guide V3.0 xxx Motions Regarding the Approval of SWEBOK Guide 2004 Version xxx Introduction to the Guide xxxi Chapter 1: Software Requirements 1-1 1. Software Requirements Fundamentals 1-1 1.1. Definition of a Software Requirement 1-1 1.2. Product and Process Requirements 1-2 1.3. Functional and Nonfunctional Requirements 1-3 1.4. Emergent Properties 1-3 1.5. Quantifiable Requirements 1-3 1.6. System Requirements and Software Requirements 1-3 2. Requirements Process  1-3 2.1. Process Models 1-4 2.2. Process Actors 1-4 2.3. Process Support and Management 1-4 2.4. Process Quality and Improvement 1-4 3. Requirements Elicitation 1-5 3.1. Requirements Sources 1-5 3.2. Elicitation Techniques 1-6 4. Requirements Analysis 1-7 4.1. Requirements Classification 1-7 4.2. Conceptual Modeling  1-8 4.3. Architectural Design and Requirements Allocation 1-9 4.4. Requirements Negotiation 1-9 4.5. Formal Analysis 1-10 5. Requirements Specification 1-10 5.1. System Definition Document 1-10 5.2. System Requirements Specification 1-10 5.3. Software Requirements Specification 1-11 6. Requirements Validation 1-11 6.1. Requirements Reviews 1-11 6.2. Prototyping 1-12 v vi SWEBOK® Guide V3.0 6.3. Model Validation 1-12 6.4. Acceptance Tests 1-12 7. Practical Considerations 1-12 7.1. Iterative Nature of the Requirements Process 1-13 7.2. Change Management 1-13 7.3. Requirements Attributes 1-13 7.4. Requirements Tracing 1-14 7.5. Measuring Requirements 1-14 8. Software Requirements Tools 1-14 Matrix of Topics vs. Reference Material 1-15 Chapter 2: Software Design 2-1 1. Software Design Fundamentals 2-2 1.1. General Design Concepts 2-2 1.2. Context of Software Design 2-2 1.3. Software Design Process 2-2 1.4. Software Design Principles 2-3 2. Key Issues in Software Design 2-3 2.1. Concurrency 2-4 2.2. Control and Handling of Events 2-4 2.3. Data Persistence  2-4 2.4. Distribution of Components 2-4 2.5. Error and Exception Handling and Fault Tolerance 2-4 2.6. Interaction and Presentation  2-4 2.7. Security 2-4 3. Software Structure and Architecture 2-4 3.1. Architectural Structures and Viewpoints 2-5 3.2. Architectural Styles 2-5 3.3. Design Patterns 2-5 3.4. Architecture Design Decisions 2-5 3.5. Families of Programs and Frameworks  2-5 4. User Interface Design  2-5 4.1. General User Interface Design Principles 2-6 4.2. User Interface Design Issues 2-6 4.3. The Design of User Interaction Modalities 2-6 4.4. The Design of Information Presentation 2-6 4.5. User Interface Design Process 2-7 4.6. Localization and Internationalization 2-7 4.7. Metaphors and Conceptual Models 2-7 5. Software Design Quality Analysis and Evaluation 2-7 5.1. Quality Attributes 2-7 5.2. Quality Analysis and Evaluation Techniques 2-8 5.3. Measures 2-8 6. Software Design Notations 2-8 6.1. Structural Descriptions (Static View) 2-8 6.2. Behavioral Descriptions (Dynamic View)  2-9 7. Software Design Strategies and Methods 2-10 7.1. General Strategies  2-10 7.2. Function-Oriented (Structured) Design 2-10 7.3. Object-Oriented Design 2-10  Table of Contents vii 7.4. Data Structure-Centered Design 2-10 7.5. Component-Based Design (CBD) 2-10 7.6. Other Methods 2-10 8. Software Design Tools 2-11 Matrix of Topics vs. Reference Material 2-12 Chapter 3: Software Construction 3-1 1. Software Construction Fundamentals 3-1 1.1. Minimizing Complexity 3-3 1.2. Anticipating Change  3-3 1.3. Constructing for Verification 3-3 1.4. Reuse 3-3 1.5. Standards in Construction  3-3 2. Managing Construction 3-4 2.1. Construction in Life Cycle Models 3-4 2.2. Construction Planning 3-4 2.3. Construction Measurement  3-4 3. Practical Considerations 3-5 3.1. Construction Design 3-5 3.2. Construction Languages 3-5 3.3. Coding 3-6 3.4. Construction Testing 3-6 3.5. Construction for Reuse 3-6 3.6. Construction with Reuse 3-7 3.7. Construction Quality 3-7 3.8. Integration 3-7 4. Construction Technologies 3-8 4.1. API Design and Use 3-8 4.2. Object-Oriented Runtime Issues  3-8 4.3. Parameterization and Generics 3-8 4.4. Assertions, Design by Contract, and Defensive Programming 3-8 4.5. Error Handling, Exception Handling, and Fault Tolerance 3-9 4.6. Executable Models  3-9 4.7. State-Based and Table-Driven Construction Techniques 3-9 4.8. Runtime Configuration and Internationalization 3-10 4.9. Grammar-Based Input Processing  3-10 4.10. Concurrency Primitives 3-10 4.11. Middleware 3-10 4.12. Construction Methods for Distributed Software 3-11 4.13. Constructing Heterogeneous Systems 3-11 4.14. Performance Analysis and Tuning 3-11 4.15. Platform Standards 3-11 4.16. Test-First Programming 3-11 5. Software Construction Tools 3-12 5.1. Development Environments 3-12 5.2. GUI Builders 3-12 5.3. Unit Testing Tools 3-12 5.4. Profiling, Performance Analysis, and Slicing Tools 3-12 Matrix of Topics vs. Reference Material 3-13 viii SWEBOK® Guide V3.0 Chapter 4: Software Testing 4-1 1. Software Testing Fundamentals 4-3 1.1. Testing-Related Terminology 4-3 1.2. Key Issues 4-3 1.3. Relationship of Testing to Other Activities 4-4 2. Test Levels 4-5 2.1. The Target of the Test  4-5 2.2. Objectives of Testing  4-5 3. Test Techniques 4-7 3.1. Based on the Software Engineer’s Intuition and Experience  4-8 3.2. Input Domain-Based Techniques 4-8 3.3. Code-Based Techniques 4-8 3.4. Fault-Based Techniques  4-9 3.5. Usage-Based Techniques 4-9 3.6. Model-Based Testing Techniques 4-10 3.7. Techniques Based on the Nature of the Application 4-10 3.8. Selecting and Combining Techniques  4-11 4. Test-Related Measures 4-11 4.1. Evaluation of the Program Under Test  4-11 4.2. Evaluation of the Tests Performed 4-12 5. Test Process 4-12 5.1. Practical Considerations 4-13 5.2. Test Activities 4-14 6. Software Testing Tools  4-15 6.1. Testing Tool Support  4-15 6.2. Categories of Tools  4-15 Matrix of Topics vs. Reference Material 4-17 Chapter 5: Software Maintenance 5-1 1. Software Maintenance Fundamentals 5-1 1.1. Definitions and Terminology 5-1 1.2. Nature of Maintenance 5-2 1.3. Need for Maintenance  5-3 1.4. Majority of Maintenance Costs  5-3 1.5. Evolution of Software  5-3 1.6. Categories of Maintenance  5-3 2. Key Issues in Software Maintenance 5-4 2.1. Technical Issues 5-4 2.2. Management Issues 5-5 2.3. Maintenance Cost Estimation 5-6 2.4. Software Maintenance Measurement 5-7 3. Maintenance Process 5-7 3.1. Maintenance Processes 5-7 3.2. Maintenance Activities 5-8 4. Techniques for Maintenance 5-10 4.1. Program Comprehension 5-10 4.2. Reengineering 5-10 4.3. Reverse Engineering 5-10 4.4. Migration 5-10 4.5. Retirement  5-11  Table of Contents ix 5. Software Maintenance Tools 5-11 Matrix of Topics vs. Reference Material 5-12 Chapter 6: Software Configuration Management 6-1 1. Management of the SCM Process 6-2 1.1. Organizational Context for SCM  6-2 1.2. Constraints and Guidance for the SCM Process  6-3 1.3. Planning for SCM  6-3 1.4. SCM Plan 6-5 1.5. Surveillance of Software Configuration Management  6-5 2. Software Configuration Identification 6-6 2.1. Identifying Items to Be Controlled  6-6 2.2. Software Library 6-8 3. Software Configuration Control  6-8 3.1. Requesting, Evaluating, and Approving Software Changes  6-8 3.2. Implementing Software Changes  6-9 3.3. Deviations and Waivers  6-10 4. Software Configuration Status Accounting 6-10 4.1. Software Configuration Status Information  6-10 4.2. Software Configuration Status Reporting  6-10 5. Software Configuration Auditing  6-10 5.1. Software Functional Configuration Audit  6-11 5.2. Software Physical Configuration Audit 6-11 5.3. In-Process Audits of a Software Baseline 6-11 6. Software Release Management and Delivery 6-11 6.1. Software Building  6-11 6.2. Software Release Management  6-12 7. Software Configuration Management Tools 6-12 Matrix of Topics vs. Reference Material 6-13 Chapter 7: Software Engineering Management 7-1 1. Initiation and Scope Definition  7-4 1.1. Determination and Negotiation of Requirements 7-4 1.2. Feasibility Analysis 7-4 1.3. Process for the Review and Revision of Requirements 7-5 2. Software Project Planning 7-5 2.1. Process Planning  7-5 2.2. Determine Deliverables 7-5 2.3. Effort, Schedule, and Cost Estimation 7-6 2.4. Resource Allocation 7-6 2.5. Risk Management 7-6 2.6. Quality Management 7-6 2.7. Plan Management 7-7 3. Software Project Enactment 7-7 3.1. Implementation of Plans 7-7 3.2. Software Acquisition and Supplier Contract Management 7-7 3.3. Implementation of Measurement Process 7-7 3.4. Monitor Process 7-7 3.5. Control Process 7-8 3.6. Reporting 7-8 x SWEBOK® Guide V3.0 4. Review and Evaluation 7-8 4.1. Determining Satisfaction of Requirements 7-8 4.2. Reviewing and Evaluating Performance 7-9 5. Closure 7-9 5.1. Determining Closure 7-9 5.2. Closure Activities 7-9 6. Software Engineering Measurement  7-9 6.1. Establish and Sustain Measurement Commitment 7-9 6.2. Plan the Measurement Process  7-10 6.3. Perform the Measurement Process 7-11 6.4. Evaluate Measurement 7-11 7. Software Engineering Management Tools 7-11 Matrix of Topics vs. Reference Material 7-13 Chapter 8: Software Engineering Process 8-1 1. Software Process Definition 8-2 1.1. Software Process Management  8-3 1.2. Software Process Infrastructure 8-4 2. Software Life Cycles 8-4 2.1. Categories of Software Processes 8-5 2.2. Software Life Cycle Models  8-5 2.3. Software Process Adaptation 8-6 2.4. Practical Considerations 8-6 3. Software Process Assessment and Improvement 8-6 3.1. Software Process Assessment Models 8-7 3.2. Software Process Assessment Methods 8-7 3.3. Software Process Improvement Models  8-7 3.4. Continuous and Staged Software Process Ratings 8-8 4. Software Measurement 8-8 4.1. Software Process and Product Measurement  8-9 4.2. Quality of Measurement Results 8-10 4.3. Software Information Models 8-10 4.4. Software Process Measurement Techniques 8-11 5. Software Engineering Process Tools 8-12 Matrix of Topics vs. Reference Material 8-13 Chapter 9: Software Engineering Models and Methods 9-1 1. Modeling 9-1 1.1. Modeling Principles  9-2 1.2. Properties and Expression of Models 9-3 1.3. Syntax, Semantics, and Pragmatics 9-3 1.4. Preconditions, Postconditions, and Invariants 9-4 2. Types of Models 9-4 2.1. Information Modeling 9-5 2.2. Behavioral Modeling 9-5 2.3. Structure Modeling 9-5 3. Analysis of Models 9-5 3.1. Analyzing for Completeness 9-5 3.2. Analyzing for Consistency 9-6  Table of Contents xi 3.3. Analyzing for Correctness 9-6 3.4. Traceability 9-6 3.5. Interaction Analysis 9-6 4. Software Engineering Methods 9-7 4.1. Heuristic Methods 9-7 4.2. Formal Methods 9-7 4.3. Prototyping Methods 9-8 4.4. Agile Methods  9-9 Matrix of Topics vs. Reference Material 9-10 Chapter 10: Software Quality 10-1 1. Software Quality Fundamentals 10-2 1.1. Software Engineering Culture and Ethics 10-2 1.2. Value and Costs of Quality 10-3 1.3. Models and Quality Characteristics 10-3 1.4. Software Quality Improvement 10-4 1.5. Software Safety  10-4 2. Software Quality Management Processes 10-5 2.1. Software Quality Assurance 10-5 2.2. Verification & Validation 10-6 2.3. Reviews and Audits 10-6 3. Practical Considerations 10-9 3.1. Software Quality Requirements 10-9 3.2. Defect Characterization 10-10 3.3. Software Quality Management Techniques 10-11 3.4. Software Quality Measurement 10-12 4. Software Quality Tools 10-12 Matrix of Topics vs. Reference Material 10-14 Chapter 11: Software Engineering Professional Practice 11-1 1. Professionalism 11-2 1.1. Accreditation, Certification, and Licensing 11-3 1.2. Codes of Ethics and Professional Conduct  11-4 1.3. Nature and Role of Professional Societies 11-4 1.4. Nature and Role of Software Engineering Standards  11-4 1.5. Economic Impact of Software 11-5 1.6. Employment Contracts 11-5 1.7. Legal Issues  11-5 1.8. Documentation  11-7 1.9. Tradeoff Analysis  11-8 2. Group Dynamics and Psychology 11-9 2.1. Dynamics of Working in Teams/Groups  11-9 2.2. Individual Cognition 11-9 2.3. Dealing with Problem Complexity  11-10 2.4. Interacting with Stakeholders 11-10 2.5. Dealing with Uncertainty and Ambiguity  11-10 2.6. Dealing with Multicultural Environments  11-10 3. Communication Skills  11-11 3.1. Reading, Understanding, and Summarizing  11-11 xii SWEBOK® Guide V3.0 3.2. Writing  11-11 3.3. Team and Group Communication  11-11 3.4. Presentation Skills  11-12 Matrix of Topics vs. Reference Material 11-13 Chapter 12: Software Engineering Economics 12-1 1. Software Engineering Economics Fundamentals 12-3 1.1. Finance 12-3 1.2. Accounting 12-3 1.3. Controlling 12-3 1.4. Cash Flow 12-3 1.5. Decision-Making Process 12-4 1.6. Valuation 12-5 1.7. Inflation 12-6 1.8. Depreciation 12-6 1.9. Taxation 12-6 1.10. Time-Value of Money 12-6 1.11. Efficiency 12-6 1.12. Effectiveness 12-6 1.13. Productivity 12-6 2. Life Cycle Economics 12-7 2.1. Product 12-7 2.2. Project 12-7 2.3. Program 12-7 2.4. Portfolio 12-7 2.5. Product Life Cycle 12-7 2.6. Project Life Cycle 12-7 2.7. Proposals 12-8 2.8. Investment Decisions 12-8 2.9. Planning Horizon 12-8 2.10. Price and Pricing 12-8 2.11. Cost and Costing 12-9 2.12. Performance Measurement 12-9 2.13. Earned Value Management 12-9 2.14. Termination Decisions 12-9 2.15. Replacement and Retirement Decisions  12-10 3. Risk and Uncertainty 12-10 3.1. Goals, Estimates, and Plans 12-10 3.2. Estimation Techniques 12-11 3.3. Addressing Uncertainty 12-11 3.4. Prioritization 12-11 3.5. Decisions under Risk 12-11 3.6. Decisions under Uncertainty 12-12 4. Economic Analysis Methods 12-12 4.1. For-Profit Decision Analysis 12-12 4.2. Minimum Acceptable Rate of Return 12-13 4.3. Return on Investment 12-13 4.4. Return on Capital Employed 12-13 4.5. Cost-Benefit Analysis 12-13  Table of Contents xiii 4.6. Cost-Effectiveness Analysis 12-13 4.7. Break-Even Analysis 12-13 4.8. Business Case 12-13 4.9. Multiple Attribute Evaluation 12-14 4.10. Optimization Analysis 12-14 5. Practical Considerations 12-14 5.1. The “Good Enough” Principle 12-14 5.2. Friction-Free Economy 12-15 5.3. Ecosystems 12-15 5.4. Offshoring and Outsourcing 12-15 Matrix of Topics vs. Reference Material 12-16 Chapter 13: Computing Foundations 13-1 1. Problem Solving Techniques 13-3 1.1. Definition of Problem Solving 13-3 1.2. Formulating the Real Problem 13-3 1.3. Analyze the Problem 13-3 1.4. Design a Solution Search Strategy 13-3 1.5. Problem Solving Using Programs 13-3 2. Abstraction 13-4 2.1. Levels of Abstraction 13-4 2.2. Encapsulation 13-4 2.3. Hierarchy 13-4 2.4. Alternate Abstractions 13-5 3. Programming Fundamentals 13-5 3.1. The Programming Process 13-5 3.2. Programming Paradigms 13-5 4. Programming Language Basics 13-6 4.1. Programming Language Overview 13-6 4.2. Syntax and Semantics of Programming Languages 13-6 4.3. Low-Level Programming Languages 13-7 4.4. High-Level Programming Languages 13-7 4.5. Declarative vs. Imperative Programming Languages 13-7 5. Debugging Tools and Techniques 13-8 5.1. Types of Errors 13-8 5.2. Debugging Techniques 13-8 5.3. Debugging Tools 13-8 6. Data Structure and Representation 13-9 6.1. Data Structure Overview 13-9 6.2. Types of Data Structure 13-9 6.3. Operations on Data Structures 13-9 7. Algorithms and Complexity 13-10 7.1. Overview of Algorithms 13-10 7.2. Attributes of Algorithms 13-10 7.3. Algorithmic Analysis 13-10 7.4. Algorithmic Design Strategies 13-11 7.5. Algorithmic Analysis Strategies 13-11 8. Basic Concept of a System 13-11 8.1. Emergent System Properties 13-11 xiv SWEBOK® Guide V3.0 8.2. Systems Engineering 13-12 8.3. Overview of a Computer System 13-12 9. Computer Organization 13-13 9.1. Computer Organization Overview 13-13 9.2. Digital Systems 13-13 9.3. Digital Logic 13-13 9.4. Computer Expression of Data 13-13 9.5. The Central Processing Unit (CPU) 13-14 9.6. Memory System Organization 13-14 9.7. Input and Output (I/O) 13-14 10. Compiler Basics 13-15 10.1. Compiler/Interpreter Overview 13-15 10.2. Interpretation and Compilation 13-15 10.3. The Compilation Process 13-15 11. Operating Systems Basics 13-16 11.1. Operating Systems Overview 13-16 11.2. Tasks of an Operating System 13-16 11.3. Operating System Abstractions 13-17 11.4. Operating Systems Classification 13-17 12. Database Basics and Data Management 13-17 12.1. Entity and Schema 13-18 12.2. Database Management Systems (DBMS) 13-18 12.3. Database Query Language 13-18 12.4. Tasks of DBMS Packages 13-18 12.5. Data Management 13-19 12.6. Data Mining 13-19 13. Network Communication Basics 13-19 13.1. Types of Network 13-19 13.2. Basic Network Components 13-19 13.3. Networking Protocols and Standards 13-20 13.4. The Internet  13-20 13.5. Internet of Things 13-20 13.6. Virtual Private Network (VPN)  13-21 14. Parallel and Distributed Computing 13-21 14.1. Parallel and Distributed Computing Overview 13-21 14.2. Difference between Parallel and Distributed Computing 13-21 14.3. Parallel and Distributed Computing Models 13-21 14.4. Main Issues in Distributed Computing 13-22 15. Basic User Human Factors 13-22 15.1. Input and Output 13-22 15.2. Error Messages 13-23 15.3. Software Robustness 13-23 16. Basic Developer Human Factors 13-23 16.1. Structure  13-24 16.2. Comments 13-24 17. Secure Software Development and Maintenance 13-24 17.1. Software Requirements Security 13-24 17.2. Software Design Security 13-25 17.3. Software Construction Security 13-25 17.4. Software Testing Security 13-25  Table of Contents xv 17.5. Build Security into Software Engineering Process 13-25 17.6. Software Security Guidelines 13-25 Matrix of Topics vs. Reference Material 13-27 Chapter 14: Mathematical Foundations 14-1 1. Set, Relations, Functions 14-1 1.1. Set Operations 14-2 1.2. Properties of Set 14-3 1.3. Relation and Function 14-4 2. Basic Logic 14-5 2.1. Propositional Logic 14-5 2.2. Predicate Logic  14-5 3. Proof Techniques 14-6 3.1. Methods of Proving Theorems 14-6 4. Basics of Counting 14-7 5. Graphs and Trees 14-8 5.1. Graphs  14-8 5.2. Trees  14-10 6. Discrete Probability 14-13 7. Finite State Machines 14-14 8. Grammars 14-15 8.1. Language Recognition  14-16 9. Numerical Precision, Accuracy, and Errors 14-17 10. Number Theory 14-18 10.1. Divisibility  14-18 10.2. Prime Number, GCD  14-19 11. Algebraic Structures 14-19 11.1. Group 14-19 11.2. Rings  14-20 Matrix of Topics vs. Reference Material 14-21 Chapter 15: Engineering Foundations 15-1 1. Empirical Methods and Experimental Techniques  15-1 1.1. Designed Experiment 15-1 1.2. Observational Study 15-2 1.3. Retrospective Study 15-2 2. Statistical Analysis  15-2 2.1. Unit of Analysis (Sampling Units), Population, and Sample 15-2 2.2. Concepts of Correlation and Regression  15-5 3. Measurement  15-5 3.1. Levels (Scales) of Measurement  15-6 3.2. Direct and Derived Measures  15-7 3.3. Reliability and Validity 15-8 3.4. Assessing Reliability  15-8 4. Engineering Design  15-8 4.1. Engineering Design in Engineering Education 15-8 4.2. Design as a Problem Solving Activity  15-9 4.3. Steps Involved in Engineering Design 15-9 5. Modeling, Simulation, and Prototyping  15-10 5.1. Modeling 15-10 xvi SWEBOK® Guide V3.0 5.2. Simulation  15-11 5.3. Prototyping 15-11 6. Standards  15-12 7. Root Cause Analysis  15-12 7.1. Techniques for Conducting Root Cause Analysis 15-13 Matrix of Topics vs. Reference Material 15-14 Appendix A: Knowledge Area Description Specifications A-1 Appendix B: IEEE and ISO/IEC Standards Supporting the Software Engineering Body of Knowledge (SWEBOK) B-1 Appendix C: Consolidated Reference List C-1  FOREWORD Every profession is based on a body of knowl- In 1958, John Tukey, the world-renowned stat- edge, although that knowledge is not always istician, coined the term software. The term soft- defined in a concise manner. In cases where no ware engineering was used in the title of a NATO formality exists, the body of knowledge is “gen- conference held in Germany in 1968. The IEEE erally recognized” by practitioners and may Computer Society first published its Transactions be codified in a variety of ways for a variety of on Software Engineering in 1972, and a commit- different uses. But in many cases, a guide to a tee for developing software engineering stan- body of knowledge is formally documented, usu- dards was established within the IEEE Computer ally in a form that permits it to be used for such Society in 1976. purposes as development and accreditation of In 1990, planning was begun for an interna- academic and training programs, certification of tional standard to provide an overall view of soft- specialists, or professional licensing. Generally, ware engineering. The standard was completed in a professional society or similar body maintains 1995 with designation ISO/IEC 12207 and given stewardship of the formal definition of a body of the title of Standard for Software Life Cycle Pro- knowledge. cesses. The IEEE version of 12207 was published During the past forty-five years, software engi- in 1996 and provided a major foundation for the neering has evolved from a conference catch- body of knowledge captured in SWEBOK 2004. phrase into an engineering profession, character- The current version of 12207 is designated as ized by 1) a professional society, 2) standards that ISO/IEC 12207:2008 and IEEE 12207-2008; it specify generally accepted professional practices, provides the basis for this SWEBOK V3. 3) a code of ethics, 4) conference proceedings, This Guide to the Software Engineering Body 5) textbooks, 6) curriculum guidelines and cur- of Knowledge is presented to you, the reader, as ricula, 7) accreditation criteria and accredited a mechanism for acquiring the knowledge you degree programs, 8) certification and licensing, need in your lifelong career development as a and 9) this Guide to the Body of Knowledge. software engineering professional. In this Guide to the Software Engineering Body of Knowledge, the IEEE Computer Society pres- ents a revised and updated version of the body of Dick Fairley, Chair knowledge formerly documented as SWEBOK Software and Systems Engineering Committee 2004; this revised and updated version is denoted IEEE Computer Society SWEBOK V3. This work is in partial fulfillment of the Society’s responsibility to promote the advancement of both theory and practice for the Don Shafer, Vice President profession of software engineering. Professional Activities Board It should be noted that this Guide does not IEEE Computer Society present the entire the body of knowledge for soft- ware engineering but rather serves as a guide to the body of knowledge that has been developed over more than four decades. The software engi- neering body of knowledge is constantly evolv- ing. Nevertheless, this Guide constitutes a valu- able characterization of the software engineering profession. xvii  FOREWORD TO THE 2004 EDITION In this Guide, the IEEE Computer Society estab- standards. These workshops involved practitio- lishes for the first time a baseline for the body ners sharing their experiences with existing stan- of knowledge for the field of software engineer- dards. The workshops also held sessions on plan- ing, and the work partially fulfills the Society’s ning for future standards, including one involving responsibility to promote the advancement of measures and metrics for software engineer- both theory and practice in this field. In so doing, ing products and processes. The planning also the Society has been guided by the experience resulted in IEEE Std. 1002, Taxonomy of Software of disciplines with longer histories but was not Engineering Standards (1986), which provided a bound either by their problems or their solutions. new, holistic view of software engineering. The It should be noted that the Guide does not pur- standard describes the form and content of a soft- port to define the body of knowledge but rather to ware engineering standards taxonomy. It explains serve as a compendium and guide to the body of the various types of software engineering stan- knowledge that has been developing and evolv- dards, their functional and external relationships, ing over the past four decades. Furthermore, and the role of various functions participating in this body of knowledge is not static. The Guide the software life cycle. must, necessarily, develop and evolve as software In 1990, planning for an international stan- engineering matures. It nevertheless constitutes dard with an overall view was begun. The plan- a valuable element of the software engineering ning focused on reconciling the software process infrastructure. views from IEEE Std. 1074 and the revised US In 1958, John Tukey, the world-renowned stat- DoD standard 2167A. The revision was eventu- istician, coined the term software. The term soft- ally published as DoD Std. 498. The international ware engineering was used in the title of a NATO standard was completed in 1995 with designa- conference held in Germany in 1968. The IEEE tion, ISO/IEC 12207, and given the title of Stan- Computer Society first published its Transactions dard for Software Life Cycle Processes. Std. ISO/ on Software Engineering in 1972. The committee IEC 12207 provided a major point of departure established within the IEEE Computer Society for the body of knowledge captured in this book. for developing software engineering standards It was the IEEE Computer Society Board of was founded in 1976. Governors’ approval of the motion put forward The first holistic view of software engineer- in May 1993 by Fletcher Buckley which resulted ing to emerge from the IEEE Computer Society in the writing of this book. The Association for resulted from an effort led by Fletcher Buckley Computing Machinery (ACM) Council approved to develop IEEE standard 730 for software qual- a related motion in August 1993. The two motions ity assurance, which was completed in 1979. led to a joint committee under the leadership of The purpose of IEEE Std. 730 was to provide Mario Barbacci and Stuart Zweben who served as uniform, minimum acceptable requirements for cochairs. The mission statement of the joint com- preparation and content of software quality assur- mittee was “To establish the appropriate sets(s) ance plans. This standard was influential in com- of criteria and norms for professional practice of pleting the developing standards in the following software engineering upon which industrial deci- topics: configuration management, software test- sions, professional certification, and educational ing, software requirements, software design, and curricula can be based.” The steering committee software verification and validation. organized task forces in the following areas: During the period 1981–1985, the IEEE Com- puter Society held a series of workshops con- 1. Define Required Body of Knowledge and cerning the application of software engineering Recommended Practices. xix xx SWEBOK® Guide V3.0 2. Define Ethics and Professional Standards. It is hoped that readers will find this book use- 3. Define Educational Curricula for undergradu- ful in guiding them toward the knowledge and ate, graduate, and continuing education. resources they need in their lifelong career devel- opment as software engineering professionals. This book supplies the first component: required The book is dedicated to Fletcher Buckley in body of knowledge and recommend practices. recognition of his commitment to promoting soft- The code of ethics and professional practice ware engineering as a professional discipline and for software engineering was completed in 1998 his excellence as a software engineering practi- and approved by both the ACM Council and the tioner in radar applications. IEEE Computer Society Board of Governors. It has been adopted by numerous corporations and other organizations and is included in several Leonard L. Tripp, IEEE Fellow 2003 recent textbooks. Chair, Professional Practices Committee, IEEE The educational curriculum for undergraduates Computer Society (2001–2003) is being completed by a joint effort of the IEEE Computer Society and the ACM and is expected Chair, Joint IEEE Computer Society and ACM to be completed in 2004. Steering Committee for the Establishment of Every profession is based on a body of knowl- Software Engineering as a Profession (1998–1999) edge and recommended practices, although they are not always defined in a precise manner. In Chair, Software Engineering Standards Committee, many cases, these are formally documented, usu- IEEE Computer Society (1992–1998) ally in a form that permits them to be used for such purposes as accreditation of academic pro- grams, development of education and training programs, certification of specialists, or profes- sional licensing. Generally, a professional society or related body maintains custody of such a for- mal definition. In cases where no such formality exists, the body of knowledge and recommended practices are “generally recognized” by practitio- ners and may be codified in a variety of ways for different uses.  EDITORS Pierre Bourque, Department of Software and IT Engineering, École de technologie supérieure (ÉTS), Canada, [email protected] Richard E. (Dick) Fairley, Software and Systems Engineering Associates (S2EA), USA, [email protected] COEDITORS Alain Abran, Department of Software and IT Engineering, École de technologie supérieure (ÉTS), Canada, [email protected] Juan Garbajosa, Universidad Politecnica de Madrid (Technical University of Madrid, UPM), Spain, [email protected] Gargi Keeni, Tata Consultancy Services, India, [email protected] Beijun Shen, School of Software, Shanghai Jiao Tong University, China, [email protected] CONTRIBUTING EDITORS The following persons contributed to editing the SWEBOK Guide V3: Don Shafer Linda Shafer Mary Jane Willshire Kate Guillemette CHANGE CONTROL BOARD The following persons served on the SWEBOK Guide V3 Change Control Board: Pierre Bourque Richard E. (Dick) Fairley, Chair Dennis Frailey Michael Gayle Thomas Hilburn Paul Joannou James W. Moore Don Shafer Steve Tockey xxi  KNOWLEDGE AREA EDITORS Software Requirements Gerald Kotonya, School of Computing and Communications, Lancaster University, UK, [email protected] Peter Sawyer, School of Computing and Communications, Lancaster University, UK, [email protected] Software Design Yanchun Sun, School of Electronics Engineering and Computer Science, Peking University, China, [email protected] Software Construction Xin Peng, Software School, Fudan University, China, [email protected] Software Testing Antonia Bertolino, ISTI-CNR, Italy, [email protected] Eda Marchetti, ISTI-CNR, Italy, [email protected] Software Maintenance Alain April, École de technologie supérieure (ÉTS), Canada, [email protected] Mira Kajko-Mattsson, School of Information and Communication Technology, KTH Royal Institute of Technology, [email protected] Software Configuration Management Roger Champagne, École de technologie supérieure (ÉTS), Canada, [email protected] Alain April, École de technologie supérieure (ÉTS), Canada, [email protected] Software Engineering Management James McDonald, Department of Computer Science and Software Engineering, Monmouth University, USA, [email protected] Software Engineering Process Annette Reilly, Lockheed Martin Information Systems & Global Solutions, USA, [email protected] Richard E. Fairley, Software and Systems Engineering Associates (S2EA), USA, [email protected] Software Engineering Models and Methods Michael F. Siok, Lockheed Martin Aeronautics Company, USA, [email protected] Software Quality J. David Blaine, USA, [email protected] Durba Biswas, Tata Consultancy Services, India, [email protected] xxiii xxiv SWEBOK® Guide V3.0 Software Engineering Professional Practice Aura Sheffield, USA, [email protected] Hengming Zou, Shanghai Jiao Tong University, China, [email protected] Software Engineering Economics Christof Ebert, Vector Consulting Services, Germany, [email protected] Computing Foundations Hengming Zou, Shanghai Jiao Tong University, China, [email protected] Mathematical Foundations Nabendu Chaki, University of Calcutta, India, [email protected] Engineering Foundations Amitava Bandyopadhayay, Indian Statistical Institute, India, [email protected] Mary Jane Willshire, Software and Systems Engineering Associates (S2EA), USA, [email protected] Appendix B: IEEE and ISO/IEC Standards Supporting SWEBOK James W. Moore, USA, [email protected]  KNOWLEDGE AREA EDITORS OF PREVIOUS SWEBOK VERSIONS The following persons served as Associate Editors for either the Trial version published in 2001 or for the 2004 version. Software Requirements Peter Sawyer, Computing Department, Lancaster University, UK Gerald Kotonya, Computing Department, Lancaster University, UK Software Design Guy Tremblay, Département d’informatique, UQAM, Canada Software Construction Steve McConnell, Construx Software, USA Terry Bollinger, the MITRE Corporation, USA Philippe Gabrini, Département d’informatique, UQAM, Canada Louis Martin, Département d’informatique, UQAM, Canada Software Testing Antonia Bertolino, ISTI-CNR, Italy Eda Marchetti, ISTI-CNR, Italy Software Maintenance Thomas M. Pigoski, Techsoft Inc., USA Alain April, École de technologie supérieure, Canada Software Configuration Management John A. Scott, Lawrence Livermore National Laboratory, USA David Nisse, USA Software Engineering Management Dennis Frailey, Raytheon Company, USA Stephen G. MacDonell, Auckland University of Technology, New Zealand Andrew R. Gray, University of Otago, New Zealand Software Engineering Process Khaled El Emam, served while at the Canadian National Research Council, Canada Software Engineering Tools and Methods David Carrington, School of Information Technology and Electrical Engineering, The University of Queensland, Australia xxv xxvi SWEBOK® Guide V3.0 Software Quality Alain April, École de technologie supérieure, Canada Dolores Wallace, retired from the National Institute of Standards and Technology, USA Larry Reeker, NIST, USA References Editor Marc Bouisset, Département d’informatique, UQAM  REVIEW TEAM The people listed below participated in the public review process of SWEBOK Guide V3. Member- ship of the IEEE Computer Society was not a requirement to participate in this review process, and membership information was not requested from reviewers. Over 1500 individual comments were collected and duly adjudicated. Carlos C. Amaro, USA Istvan Fay, Hungary Mark Ardis, USA Jose L. Fernandez-Sanchez, Spain Mora-Soto Arturo, Spain Dennis J. Frailey, USA Ohad Barzilay, Israel Tihana Galinac Grbac, Croatia Gianni Basaglia, Italy Colin Garlick, New Zealand Denis J. Bergquist, USA Garth J.G. Glynn, UK Alexander Bogush, UK Jill Gostin, USA Christopher Bohn, USA Christiane Gresse von Wangenheim, Brazil Steve Bollweg, USA Thomas Gust, USA Reto Bonderer, Switzerland H.N. Mok, Singapore Alexei Botchkarev, Canada Jon D. Hagar, USA Pieter Botman, Canada Anees Ahmed Haidary, India Robert Bragner, USA Duncan Hall, New Zealand Kevin Brune, USA James Hart, USA Ogihara Bryan, USA Jens H.J. Heidrich, Germany Luigi Buglione, Italy Rich Hilliard, USA Rick Cagle, USA Bob Hillier, Canada Barbara Canody, USA Norman M. Hines, USA Rogerio A. Carvalho, Brazil Dave Hirst, USA Daniel Cerys, USA Theresa L. Hunt, USA Philippe Cohard, France Kenneth Ingham, USA Ricardo Colomo-Palacios, Spain Masahiko Ishikawa, Japan Mauricio Coria, Argentina Michael A. Jablonski, USA Marek Cruz, UK G. Jagadeesh, India Stephen Danckert, USA Sebastian Justicia, Spain Bipul K. Das, Canada Umut Kahramankaptan, Belgium James D. Davidson, USA Pankaj Kamthan, Canada Jon Dehn, USA Perry Kapadia, USA Lincoln P. Djang, USA Tarig A. Khalid, Sudan Andreas Doblander, Austria Michael K.A. Klaes, Germany Yi-Ben Doo, USA Maged Koshty, Egypt Scott J. Dougherty, UK Claude C. Laporte, Canada Regina DuBord, USA Dong Li, China Fedor Dzerzhinskiy, Russia Ben Linders, Netherlands Ann M. Eblen, Australia Claire Lohr, USA David M. Endres, USA Vladimir Mandic, Serbia Marilyn Escue, USA Matt Mansell, New Zealand Varuna Eswer, India John Marien, USA xxvii xxviii SWEBOK® Guide V3.0 Stephen P. Masticola, USA Thom Schoeffling, USA Nancy Mead, USA Reinhard Schrage, Germany Fuensanta Medina-Dominguez, Spain Neetu Sethia, India Silvia Judith Meles, Argentina Cindy C. Shelton, USA Oscar A. Mondragon, Mexico Alan Shepherd, Germany David W. Mutschler, USA Katsutoshi Shintani, Japan Maria Nelson, Brazil Erik Shreve, USA John Noblin, USA Jaguaraci Silva, Brazil Bryan G. Ogihara, USA M. Somasundaram, India Takehisa Okazaki, Japan Peraphon Sophatsathit, Thailand Hanna Oktaba, Mexico John Standen, UK Chin Hwee Ong, Hong Kong Joyce Statz, USA Venkateswar Oruganti, India Perdita P. Stevens, UK Birgit Penzenstadler, Germany David Struble, USA Larry Peters, USA Ohno Susumu, Japan S.K. Pillai, India Urcun Tanik, USA Vaclav Rajlich, USA Talin Tasciyan, USA Kiron Rao, India J. Barrie Thompson, UK Luis Reyes, USA Steve Tockey, USA Hassan Reza, USA Miguel Eduardo Torres Moreno, Colombia Steve Roach, USA Dawid Trawczynski, USA Teresa L. Roberts, USA Adam Trendowicz, Germany Dennis Robi, USA Norio Ueno, Japan Warren E. Robinson, USA Cenk Uyan, Turkey Jorge L. Rodriguez, USA Chandra Sekar Veerappan, Singapore Alberto C. Sampaio, Portugal Oruganti Venkateswar, India Ed Samuels, USA Jochen Vogt, Germany Maria-Isabel Sanchez-Segura, Spain Hironori Washizaki, Japan Vineet Sawant, USA Ulf Westermann, Germany R. Schaaf, USA Don Wilson, USA James C. Schatzman, USA Aharon Yadin, Israel Oscar A. Schivo, Argentina Hong Zhou, UK Florian Schneider, Germany  ACKNOWLEDGEMENTS Funding for the development of SWEBOK Guide various ways: Pieter Botman, Evan Butterfield, V3 has been provided by the IEEE Computer Carine Chauny, Pierce Gibbs, Diane Girard, John Society. The editors and coeditors appreciate the Keppler, Dorian McClenahan, Kenza Meridji, Sam- important work performed by the KA editors and uel Redwine, Annette Reilly, and Pam Thompson. the contributing editors as well as by the the mem- Finally, there are surely other people who have bers of the Change Control Board. The editorial contributed to this Guide, either directly or indi- team must also acknowledge the indispensable rectly, whose names we have inadvertently omit- contribution of reviewers. ted. To those people, we offer our tacit appre- The editorial team also wishes to thank the fol- ciation and apologize for having omitted explicit lowing people who contributed to the project in recognition. IEEE COMPUTER SOCIETY PRESIDENTS Dejan Milojicic, 2014 President David Alan Grier, 2013 President Thomas Conte, 2015 President PROFESSIONAL ACTIVITIES BOARD, 2013 MEMBERSHIP Donald F. Shafer, Chair Pieter Botman, CSDP Pierre Bourque Richard Fairley, CSDP Dennis Frailey S. Michael Gayle Phillip Laplante, CSDP Jim Moore, CSDP Linda Shafer, CSDP Steve Tockey, CSDP Charlene “Chuck” Walrad xxix xxx SWEBOK® Guide V3.0 MOTIONS REGARDING THE APPROVAL OF SWEBOK GUIDE V3.0 The SWEBOK Guide V3.0 was submitted to ballot by verified IEEE Computer Society members in November 2013 with the following question: “Do you approve this manuscript of the SWEBOK Guide V3.0 to move forward to formatting and publication?” The results of this ballot were 259 Yes votes and 5 No votes. The following motion was unanimously adopted by the Professional Activities Board of the IEEE Com- puter Society in December 2013: The Professional Activities Board of the IEEE Computer Society finds that the Guide to the Soft- ware Engineering Body of Knowledge Version 3.0 has been successfully completed; and endorses the Guide to the Software Engineering Body of Knowledge Version 3.0 and commends it to the IEEE Computer Society Board of Governors for their approval. The following motion was adopted by the IEEE Computer Society Board of Governors in December 2013: MOVED, that the Board of Governors of the IEEE Computer Society approves Version 3.0 of the Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Profes- sional Activities Board to proceed with printing. MOTIONS REGARDING THE APPROVAL OF SWEBOK GUIDE 2004 VERSION The following motion was unanimously adopted by the Industrial Advisory Board of the SWEBOK Guide project in February 2004: The Industrial Advisory Board finds that the Software Engineering Body of Knowledge project ini- tiated in 1998 has been successfully completed; and endorses the 2004 Version of the Guide to the SWEBOK and commends it to the IEEE Computer Society Board of Governors for their approval. The following motion was adopted by the IEEE Computer Society Board of Governors in February 2004: MOVED, that the Board of Governors of the IEEE Computer Society approves the 2004 Edition of the Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Profes- sional Practices Committee to proceed with printing. Please also note that the 2004 edition of the Guide to the Software Engineering Body of Knowledge was submitted by the IEEE Computer Society to ISO/IEC without any change and was recognized as Technical Report ISO/IEC TR 19759:2005.  INTRODUCTION TO THE GUIDE KA Knowledge Area literature. The purpose of the Guide is to describe Software Engineering Body of SWEBOK the portion of the Body of Knowledge that is gen- Knowledge erally accepted, to organize that portion, and to provide topical access to it. Publication of the 2004 version of this Guide to the The Guide to the Software Engineering Body Software Engineering Body of Knowledge (SWE- of Knowledge (SWEBOK Guide) was established BOK 2004) was a major milestone in establishing with the following five objectives: software engineering as a recognized engineering discipline. The goal in developing this update to 1. To promote a consistent view of software SWEBOK is to improve the currency, readability, engineering worldwide consistency, and usability of the Guide. 2. To specify the scope of, and clarify the place All knowledge areas (KAs) have been updated of software engineering with respect to other to reflect changes in software engineering since disciplines such as computer science, proj- publication of SWEBOK 2004. Four new foun- ect management, computer engineering, and dation KAs and a Software Engineering Profes- mathematics sional Practices KA have been added. The Soft- 3. To characterize the contents of the software ware Engineering Tools and Methods KA has engineering discipline been revised as Software Engineering Models 4. To provide a topical access to the Software and Methods. Software engineering tools is now Engineering Body of Knowledge a topic in each of the KAs. Three appendices pro- 5. To provide a foundation for curriculum vide the specifications for the KA description, an development and for individual certification annotated set of relevant standards for each KA, and licensing material and a listing of the references cited in the Guide. This Guide, written under the auspices of the The first of these objectives, a consistent world- Professional Activities Board of the IEEE Com- wide view of software engineering, was supported puter Society, represents a next step in the evolu- by a development process which engaged approxi- tion of the software engineering profession. mately 150 reviewers from 33 countries. More information regarding the development process can WHAT IS SOFTWARE ENGINEERING? be found on the website (www.swebok.org). Pro- fessional and learned societies and public agencies ISO/IEC/IEEE Systems and Software Engineering involved in software engineering were contacted, Vocabulary (SEVOCAB) defines software engi- made aware of this project to update SWEBOK, and neering as “the application of a systematic, disci- invited to participate in the review process. KA edi- plined, quantifiable approach to the development, tors were recruited from North America, the Pacific operation, and maintenance of software; that is, the Rim, and Europe. Presentations on the project were application of engineering to software).”1 made at various international venues. The second of the objectives, the desire to WHAT ARE THE OBJECTIVES OF THE specify the scope of software engineering, moti- SWEBOK GUIDE? vates the fundamental organization of the Guide. The material that is recognized as being within The Guide should not be confused with the Body this discipline is organized into the fifteen KAs of Knowledge itself, which exists in the published listed in Table I.1. Each of these KAs is treated in a chapter in this Guide. 1 See www.computer.org/sevocab. xxxi xxxii SWEBOK® Guide V3.0 Table I.1. The 15 SWEBOK KAs HIERARCHICAL ORGANIZATION Software Requirements Software Design The organization of the KA chapters supports the third of the project’s objectives—a characteriza- Software Construction tion of the contents of software engineering. The Software Testing detailed specifications provided by the project’s Software Maintenance editorial team to the associate editors regarding Software Configuration Management the contents of the KA descriptions can be found in Appendix A. Software Engineering Management The Guide uses a hierarchical organization to Software Engineering Process decompose each KA into a set of topics with rec- Software Engineering Models and Methods ognizable labels. A two (sometime three) level Software Quality breakdown provides a reasonable way to find topics of interest. The Guide treats the selected Software Engineering Professional Practice topics in a manner compatible with major schools Software Engineering Economics of thought and with breakdowns generally found Computing Foundations in industry and in software engineering literature Mathematical Foundations and standards. The breakdowns of topics do not presume particular application domains, business Engineering Foundations uses, management philosophies, development methods, and so forth. The extent of each topic’s In specifying scope, it is also important to iden- description is only that needed to understand the tify the disciplines that intersect with software generally accepted nature of the topics and for engineering. To this end, SWEBOK V3 also rec- the reader to successfully find reference material; ognizes seven related disciplines, listed in Table the Body of Knowledge is found in the reference I.2. Software engineers should, of course, have materials themselves, not in the Guide. knowledge of material from these disciplines (and the KA descriptions in this Guide may make REFERENCE MATERIAL AND MATRIX reference to them). It is not, however, an objec- tive of the SWEBOK Guide to characterize the To provide topical access to the knowledge—the knowledge of the related disciplines. fourth of the project’s objectives—the Guide identifies authoritative reference material for Table I.2. Related Disciplines each KA. Appendix C provides a Consolidated Computer Engineering Reference List for the Guide. Each KA includes relevant references from the Consolidated Refer- Computer Science ence List and also includes a matrix relating the General Management reference material to the included topics. Mathematics It should be noted that the Guide does not Project Management attempt to be comprehensive in its citations. Much material that is both suitable and excellent Quality Management is not referenced. Material included in the Con- Systems Engineering solidated Reference List provides coverage of the topics described. The relevant elements of computer science and mathematics are presented in the Computing DEPTH OF TREATMENT Foundations and Mathematical Foundations KAs of the Guide (Chapters 13 and 14). To achieve the SWEBOK fifth objective—pro- viding a foundation for curriculum development,  Introduction xxxiii certification, and licensing, the criterion of gen- The breakdown of topics in each KA consti- erally accepted knowledge has been applied, to tutes the core the KA description, describing be distinguished from advanced and research the decomposition of the KA into subareas, top- knowledge (on the grounds of maturity) and from ics, and sub-topics. For each topic or subtopic, a specialized knowledge (on the grounds of gener- short description is given, along with one or more ality of application). references. The equivalent term generally recognized The reference material was chosen because it is comes from the Project Management Institute: considered to constitute the best presentation of “Generally recognized means the knowledge the knowledge relative to the topic. A matrix links and practices described are applicable to most the topics to the reference material. projects most of the time, and there is consensus The last part of each KA description is the list about their value and usefulness.”2 of recommended references and (optionally) fur- However, the terms “generally accepted” or ther readings. Relevant standards for each KA are “generally recognized” do not imply that the des- presented in Appendix B of the Guide. ignated knowledge should be uniformly applied to all software engineering endeavors—each proj- APPENDIX A. KA DESCRIPTION ect’s needs determine that—but it does imply that SPECIFICATIONS competent, capable software engineers should be equipped with this knowledge for potential Appendix A describes the specifications provided application. More precisely, generally accepted by the editorial team to the associate editors for knowledge should be included in the study mate- the content, recommended references, format, rial for the software engineering licensing exami- and style of the KA descriptions. nation that graduates would take after gaining four years of work experience. Although this cri- APPENDIX B. ALLOCATION OF STAN- terion is specific to the US style of education and DARDS TO KAS does not necessarily apply to other countries, we deem it useful. Appendix B is an annotated list of the relevant standards, mostly from the IEEE and the ISO, for STRUCTURE OF THE KA DESCRIPTIONS each of the KAs of the SWEBOK Guide. The KA descriptions are structured as follows. APPENDIX C. CONSOLIDATED In the introduction, a brief definition of the KA REFERENCE LIST and an overview of its scope and of its relation- ship with other KAs are presented. Appendix C contains the consolidated list of rec- ommended references cited in the KAs (these 2 A Guide to the Project Management Body of references are marked with an asterisk (*) in the Knowledge, 5th ed., Project Management Institute, text). 2013; www.pmi.org.  CHAPTER 1 SOFTWARE REQUIREMENTS ACRONYMS does not imply, however, that a software engineer could not perform the function. Confidentiality, Integrity, and A risk inherent in the proposed breakdown is CIA Availability that a waterfall-like process may be inferred. To DAG Directed Acyclic Graph guard against this, topic 2, Requirements Process, FSM Functional Size Measurement is designed to provide a high-level overview of the International Council on Systems requirements process by setting out the resources INCOSE and constraints under which the process operates Engineering and which act to configure it. UML Unified Modeling Language An alternate decomposition could use a prod- SysML Systems Modeling Language uct-based structure (system requirements, soft- ware requirements, prototypes, use cases, and so on). The process-based breakdown reflects INTRODUCTION the fact that the requirements process, if it is to be successful, must be considered as a process The Software Requirements knowledge area (KA) involving complex, tightly coupled activities is concerned with the elicitation, analysis, speci- (both sequential and concurrent), rather than as a fication, and validation of software requirements discrete, one-off activity performed at the outset as well as the management of requirements dur- of a software development project. ing the whole life cycle of the software product. The Software Requirements KA is related It is widely acknowledged amongst researchers closely to the Software Design, Software Testing, and industry practitioners that software projects Software Maintenance, Software Configuration are critically vulnerable when the requirements- Management, Software Engineering Manage- related activities are poorly performed. ment, Software Engineering Process, Software Software requirements express the needs and Engineering Models and Methods, and Software constraints placed on a software product that Quality KAs. contribute to the solution of some real-world problem. BREAKDOWN OF TOPICS FOR The term “requirements engineering” is widely SOFTWARE REQUIREMENTS used in the field to denote the systematic handling of requirements. For reasons of consistency, the The breakdown of topics for the Software term “engineering” will not be used in this KA Requirements KA is shown in Figure 1.1. other than for software engineering per se. For the same reason, “requirements engineer,” 1. Software Requirements Fundamentals a term which appears in some of the literature, [1*, c4, c4s1, c10s1, c10s4] [2*, c1, c6, c12] will not be used either. Instead, the term “software engineer” or, in some specific cases, “require- 1.1. Definition of a Software Requirement ments specialist” will be used, the latter where the role in question is usually performed by an At its most basic, a software requirement is a individual other than a software engineer. This property that must be exhibited by something in 1-1 1-2 SWEBOK® Guide V3.0 Figure 1.1. Breakdown of Topics for the Software Requirements KA order to solve some problem in the real world. It requirements can be verified within available may aim to automate part of a task for someone resource constraints. to support the business processes of an organiza- Requirements have other attributes in addi- tion, to correct shortcomings of existing software, tion to behavioral properties. Common examples or to control a device—to name just a few of the include a priority rating to enable tradeoffs in many problems for which software solutions are the face of finite resources and a status value to possible. The ways in which users, business pro- enable project progress to be monitored. Typi- cesses, and devices function are typically complex. cally, software requirements are uniquely identi- By extension, therefore, the requirements on par- fied so that they can be subjected to software con- ticular software are typically a complex combina- figuration management over the entire life cycle tion from various people at different levels of an of the feature and of the software. organization, and who are in one way or another involved or connected with this feature from the 1.2. Product and Process Requirements environment in which the software will operate. An essential property of all software require- A product requirement is a need or constraint on ments is that they be verifiable as an individual the software to be developed (for example, “The feature as a functional requirement or at the software shall verify that a student meets all pre- system level as a nonfunctional requirement. It requisites before he or she registers for a course”). may be difficult or costly to verify certain soft- A process requirement is essentially a con- ware requirements. For example, verification straint on the development of the software (for of the throughput requirement on a call center example, “The software shall be developed using may necessitate the development of simulation a RUP process”). software. Software requirements, software test- Some software requirements generate implicit ing, and quality personnel must ensure that the process requirements. The choice of verification  Software Requirements 1-3 technique is one example. Another might be the depend for their interpretation on subjective use of particularly rigorous analysis techniques judgment (“the software shall be reliable”; “the (such as formal specification methods) to reduce software shall be user-friendly”). This is par- faults that can lead to inadequate reliability. Pro- ticularly important for nonfunctional require- cess requirements may also be imposed directly ments. Two examples of quantified requirements by the development organization, their customer, are the following: a call center’s software must or a third party such as a safety regulator. increase the center’s throughput by 20%; and a system shall have a probability of generating a 1.3. Functional and Nonfunctional Requirements fatal error during any hour of operation of less than 1 * 10−8. The throughput requirement is at a Functional requirements describe the functions very high level and will need to be used to derive that the software is to execute; for example, for- a number of detailed requirements. The reliabil- matting some text or modulating a signal. They ity requirement will tightly constrain the system are sometimes known as capabilities or features. architecture. A functional requirement can also be described as one for which a finite set of test steps can be 1.6. System Requirements and Software written to validate its behavior. Requirements Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional In this topic, “system” means requirements are sometimes known as constraints or quality requirements. They can be further clas- an interacting combination of elements sified according to whether they are performance to accomplish a defined objective. These requirements, maintainability requirements, include hardware, software, firmware, safety requirements, reliability requirements, people, information, techniques, facilities, security requirements, interoperability require- services, and other support elements, ments or one of many other types of software requirements (see Models and Quality Character- as defined by the International Council on Soft- istics in the Software Quality KA). ware and Systems Engineering (INCOSE). System requirements are the requirements for 1.4. Emergent Properties the system as a whole. In a system containing software components, software requirements are Some requirements represent emergent proper- derived from system requirements. ties of software—that is, requirements that can- This KA defines “user requirements” in a not be addressed by a single component but that restricted way, as the requirements of the sys- depend on how all the software components tem’s customers or end users. System require- interoperate. The throughput requirement for a ments, by contrast, encompass user requirements, call center would, for example, depend on how requirements of other stakeholders (such as regu- the telephone system, information system, and latory authorities), and requirements without an the operators all interacted under actual operat- identifiable human source. ing conditions. Emergent properties are crucially dependent on the system architecture. 2. Requirements Process [1*, c4s4] [2*, c1–4, c6, c22, c23] 1.5. Quantifiable Requirements This section introduces the software requirements Software requirements should be stated as clearly process, orienting the remaining five topics and and as unambiguously as possible, and, where showing how the requirements process dovetails appropriate, quantitatively. It is important to with the overall software engineering process. avoid vague and unverifiable requirements that 1-4 SWEBOK® Guide V3.0 2.1. Process Models marketing people are often needed to estab- lish what the market needs and to act as The objective of this topic is to provide an under- proxy customers. standing that the requirements process Regulators: Many application domains, such as banking and public transport, are regu- is not a discrete front-end activity of the soft- lated. Software in these domains must com- ware life cycle, but rather a process initiated ply with the requirements of the regulatory at the beginning of a project that continues to authorities. be refined throughout the life cycle; Software engineers: These individuals have identifies software requirements as configu- a legitimate interest in profiting from devel- ration items and manages them using the oping the software by, for example, reusing same software configuration management components in or from other products. If, practices as other products of the software in this scenario, a customer of a particu- life cycle processes; lar product has specific requirements that needs to be adapted to the organization and compromise the potential for component project context. reuse, the software engineers must carefully weigh their own stake against those of the In particular, the topic is concerned with how customer. Specific requirements, particu- the activities of elicitation, analysis, specifica- larly constraints, may have major impact on tion, and validation are configured for different project cost or delivery because they either types of projects and constraints. The topic also fit well or poorly with the skill set of the includes activities that provide input into the engineers. Important tradeoffs among such requirements process, such as marketing and fea- requirements should be identified. sibility studies. It will not be possible to perfectly satisfy the 2.2. Process Actors requirements of every stakeholder, and it is the software engineer’s job to negotiate tradeoffs that This topic introduces the roles of the people who are both acceptable to the principal stakeholders participate in the requirements process. This pro- and within budgetary, technical, regulatory, and cess is fundamentally interdisciplinary, and the other constraints. A prerequisite for this is that all requirements specialist needs to mediate between the stakeh