Software Engineering Body of Knowledge (SWEBOK)

The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), published by the IEEE Computer Society (IEEE CS), reflects the current state of generally accepted, consensus-driven knowledge derived from the interaction between software engineering theory and practice. Its 18 knowledge areas (KAs) summarize key concepts and include a reference list for detailed information.

SWEBOK Guide V4.0 introduces new topics, updates existing ones, and retires outdated subjects. Agile and DevOps have been notably integrated into several KAs due to their widespread adoption since the previous edition. Additionally, three new knowledge areas—Software Architecture, Software Engineering Operations, and Software Security—have been added to enhance the foundational knowledge in software engineering. The new Guide also aims to better align related disciplines by reorganizing and renaming some content within different knowledge areas. The table of contents for Version 4 is below.

The SWEBOK Guide serves multiple purposes:

• Defines the contents of the software engineering discipline;
• Promotes a consistent understanding of software engineering worldwide;
• Clarifies the boundaries of software engineering in relation to other disciplines;
• Provides a foundation for training materials and curriculum development;
• Supports certification and licensing of software engineers.
• Reflects current practices and integrates emerging technologies.

SWEBOK V4.0 is the latest version of the globally respected Guide to the Software Engineering Body of Knowledge. Designed as a dynamic, evolving document, the guide has been developed by leading experts, reviewed by professionals, and made available for public review and feedback, continuing its 20-year legacy as the most authoritative and trusted definition of the software engineering profession.

The principles guiding the development of this project include:

• Transparency: The development process is fully documented and publicly accessible.
• Consensus-building: The process is designed to gradually build consensus among industry professionals, academic institutions, and standards-setting bodies.
• Wide distribution: The Guide will remain freely accessible in at least one format to ensure it reaches a broad audience.

25 September 2025 Update: SWEBOK v4.0 document has been updated with some minor revisions. To clearly distinguish this updated release, it is now identified as SWEBOK v4.0a.To make sure you’re using the latest version, please download the updated document using the same form. Thank you for keeping current with SWEBOK.

Editor Hironori Washizaki, Waseda University Japan (IEEE Computer Society 2024 President-Elect, 2025 President)

H. Washizaki, eds., Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), Version 4.0, IEEE Computer Society, 2024; www.swebok.org.

The committee responsible for the 2014 SWEBOK Guide recognized the need for future revisions and outlined a process for continuous updates. The reasons for this are:

Evolving Practices: Software engineering practices are constantly changing due to the introduction of new tools, methods, and types of software. What was once considered experimental may now be accepted as standard practice. While the Guide emphasizes widely accepted, enduring practices, the software environment can shift dramatically due to changes in business and job requirements. For example, the importance of security in good software development has become increasingly clear in recent years. Economic factors can also influence which methods are recognized as best practices in software engineering.

Emerging Viewpoints: Other IEEE Computer Society products, such as the Certified Software Development Professional (CSDP) exam and the Software Engineering 2004 curriculum guide, offer slightly different perspectives on the body of knowledge. It’s important to examine these differences and align SWEBOK Version 4 with them where appropriate. For instance, it would be logical to establish a core set of references that these products share. Comparing these efforts has also highlighted the need for new knowledge areas and revisions to existing ones.

Expanding Knowledge: Since the first SWEBOK Guide was published in 2004, many of the books it cited have been updated, and new articles have been added to the body of knowledge. SWEBOK Version 4 reflects these changes.

Learn a bit more about the evolution of SWEBOK through our webinars on SWEBOK Guide V4.0: https://waseda.box.com/v/swebok-webinar-opening.

Introduction: Slides of Introduction, Introduction Recording

Chapter 1: Software Requirements, Slides of Chapter 1, Chapter 1 Recording

Chapter 2: Software Architecture. Slides of Chapter 2, Chapter 2 Recording

Chapter 3: Software Design, Slides of Chapter 3, Chapter 3 Recording

Chapter 4: Software Construction, Slides of Chapter 4, Chapter 4 Recording

Chapter 5: Software Testing, Slides of Chapter 5, Chapter 5 Recording

Chapter 6: Software Engineering Operations, Slides of Chapter 6, Chapter 6 Recording

Chapter 7: Software Maintenance, Slides of Chapter 7, Chapter 7 Recording

Chapter 8: Software Configuration Management, Slides of Chapter 8, Chapter 8 Recording

Chapter 9: Software Engineering Management, Slides of Chapter 9, Chapter 9 Recording

Chapter 10: Software Engineering Process, Slides of Chapter 10, Chapter 10 Recording

Chapter 11: Software Engineering Models and Methods, Slides of Chapter 11, Chapter 11 Recording

Chapter 12: Software Quality, Slides of Chapter 12, Chapter 12 Recording

Chapter 13: Software Security, Slides of Chapter 13, Chapter 13 Recording

Chapter 14: Software Engineering Professional Practice, Slides of Chapter 14, Chapter 14 Recording

Chapter 15: Software Engineering Economics, Slides of Chapter 15, Chapter 15 Recording

Chapter 16: Computing Foundations, Slides of Chapter 16, Chapter 16 Recording

Chapter 17: Mathematical Foundations, Slides of Chapter 17, Chapter 17 Recording

Chapter 18: Engineering Foundations, Slides of Chapter 18, Chapter 18 Recording

Appendix B: Slides of IEEE and ISO/IEC Standards Supporting SWEBOK (Appendix B), IEEE and ISO/IEC Standards Supporting SWEBOK (Appendix B) Recording

The main objectives of the SWEBOK project included:

• Promoting a consistent view of software engineering worldwide;
• Specifying the scope of, and clarifying the place of software engineering concerning other disciplines such as computer science, project management, computer engineering, and mathematics;
• Characterizing the contents of the software engineering discipline;
• Providing topical access to the Software Engineering Body of Knowledge;
• Providing a foundation for curriculum development and individual certification and licensing material

The intended audience for the SWEBOK Guide includes:

• Public and Private Organizations: Those aiming to establish and promote a consistent understanding of software engineering within their operations, particularly when setting education and training standards, job classifications, and performance evaluation policies;
• Practicing Software Engineers: Individuals actively working in the field of software engineering who can use the Guide as a reference for best practices and professional development;
• Policymakers: Those involved in creating public policy related to software engineering, including the development of licensing rules and professional guidelines;
• Professional Societies: Organizations that define accreditation standards for university software engineering programs, as well as certification rules and guidelines for professionals in the field;
• Software Engineering Students: Individuals studying software engineering who can use the Guide to deepen their understanding of the discipline;
• Educators and Trainers: Those responsible for developing curricula and course content in software engineering programs

Consensus on a Core Body of Knowledge Is Crucial

Despite the millions of software professionals worldwide and the ubiquitous presence of software in our society, software engineering has relatively recently reached the status of a legitimate engineering discipline and a recognized profession.

In engineering, the accreditation of university programs and the licensing and certification of professionals are regarded as essential. These processes are vital for the continuous development of professionals and the overall enhancement of the profession’s standards. Establishing a core body of knowledge is fundamental to the creation and accreditation of university curricula, as well as the licensing and certification of professionals.

Reaching a consensus on this core body of knowledge is a significant milestone in any discipline. The IEEE Computer Society has identified this as crucial for advancing software engineering towards full professional recognition. The SWEBOK Guide, developed under the Professional Activities Board, is part of a long-term project aimed at achieving this consensus. The ongoing SWEBOK project, with its upcoming milestone—SWEBOK Version 5.0—will continue to redefine “accepted knowledge” and introduce new areas of focus.

Focus on Generally Accepted Knowledge

The software engineering body of knowledge is an all-inclusive term that describes the sum of knowledge within the profession of software engineering. Since it is usually not possible to put the full body of knowledge of even an emerging discipline, such as software engineering, into a single document, there is a need for a Guide to the Software Engineering Body of Knowledge. This Guide will seek to identify and describe that subset of the body of knowledge that is generally accepted, even though software engineers must be knowledgeable not only in software engineering, but also, of course, in other related disciplines.

What do we mean by “generally accepted knowledge”?

To better illustrate what “generally accepted knowledge” is relative to other types of knowledge, the figure below proposes a draft three-category schema for classifying knowledge.

Categories of Knowledge

The Project Management Institute in its Guide to the Project Management Body of Knowledge defines “generally accepted” knowledge for project management in the following manner:

“Generally accepted” does not mean that the knowledge and practices described are or should be applied uniformly on all projects; the project management team is always responsible for determining what is appropriate for any given project.

The Guide to the Project Management Body of Knowledge is now an IEEE Standard, IEEE 1490-2003.

The Industrial Advisory Board of the SWEBOK Guide better defines “generally accepted” as knowledge to be included in the study material of a software engineering licensing exam that a graduate would pass after completing four years of work experience. These two definitions should be seen as complementary.

Knowledge Area Editors are also expected to be somewhat forward-looking in their interpretation by taking into consideration not only what is “generally accepted” today, but what they expect will be “generally accepted” in a 3 to 5 year timeframe.

Software Engineering Body of Knowledge and Curriculum are Not the Same

Software engineers must not only be knowledgeable in what is specific to their discipline, but they also, of course, must know a lot more. The goal of this initiative is not, however, to inventory everything that software engineers should know, but to identify what forms the core of software engineering. It is the responsibility of other organizations and initiatives involved in the licensing and certification of professionals and the development of accreditation criteria and curricula to define what a software engineer must know outside software engineering. We believe that a very clear distinction must be made between the software engineering body of knowledge and the contents of software engineering curricula.

View the SWEBOK table of contents to get an overview of topics.

KA EDITORS

Software Requirements

Steve Tockey, Construx Software, USA.

Software Architecture

Rich Hilliard, USA.

Software Design

Rich Hilliard, USA.

Software Construction

Xin Peng, Software School, Fudan University, China.

Steve Schwarm, Synopsys – Black Duck Software, USA.

Software Testing

Eda Marchetti, ISTI-CNR, Italy.

Said Daoudagh, ISTI-CNR, Italy.

Software Engineering Operations

Francis Bordeleau, École de technologie supérieure (ÉTS), Canada.

Alain April, École de technologie supérieure (ÉTS), Canada.

Software Maintenance

Ali Ouni, École de technologie supérieure (ÉTS), Canada.

Alain April, École de technologie supérieure (ÉTS), Canada.

Peter Leather, Exceptional Performance, UK.

Software Configuration Management

Maria Isabel Sánchez Segura, Universidad Carlos III de Madrid, Spain.

Bob Aiello, CM Best Practices, USA.

Software Engineering Management

Kenneth E. Nidiffer, George Mason University, USA.

Software Engineering Process

Juan Garbajosa, Universidad Politécnica de Madrid, Spain.

Software Engineering Models and Methods

Hironori Washizaki, Waseda University, Japan.

Akinori Ihara, Wakayama University, Japan.

Shinpei Ogata, Shinshu University, Japan.

Software Quality

Alain April, École de technologie supérieure (ÉTS), Canada.

Steve Tockey, Construx Software, USA.

Steve Schwarm, Synopsys – Black Duck Software, USA.

Software Security

Nobukazu Yoshioka, Waseda University, Japan.

Seiji Munetoh, IBM Research, Japan.

Software Engineering Professional Practice

Katsuhisa Shintani, Waseda University, Japan.

Eiji Hayashiguchi, Waseda University, Japan.

Software Engineering Economics

Maria Isabel Sánchez Segura, Universidad Carlos III de Madrid, Spain.

Steve Tockey, Construx Software, USA.

Computing Foundations

Yatheendranath TJ, DhiiHii Labs Private Limited, India.

Mathematical Foundations

Yatheendranath TJ, DhiiHii Labs Private Limited, India.

Steve Tockey, Construx Software, USA.

Engineering Foundations

Yatheendranath TJ, DhiiHii Labs Private Limited, India.

Steve Tockey, Construx Software, USA.

Appendix A: Knowledge Area Description Specifications

Juan Garbajosa, Universidad Politécnica de Madrid, Spain.

Hironori Washizaki, Waseda University, Japan.

Appendix B: IEEE and ISO/IEC Standards Supporting SWEBOK

Annette Reilly, USA.

Appendix C: Consolidated Reference List

Hironori Washizaki, Waseda University, Japan.

CONTRIBUTING EDITORS:

The following persons contributed to editing the SWEBOK Guide V4:

Michelle Phon

Eric Berkowitz

SWEBOK is an acronym that stands for the Software Engineering Body Of Knowledge, an all-inclusive term that describes the sum of knowledge within the profession of software engineering.

Since it is usually not possible to put the full body of knowledge of even an emerging discipline, such as software engineering, into a single document, there is a need for a Guide to the Software Engineering Body of Knowledge.

This guide identifies and describes that subset of the body of knowledge that is generally accepted, even though software engineers must be knowledgeable not only in software engineering, but also, of course, in other related disciplines.

Software engineers worldwide can participate in the guide’s development. Anyone can sign up to be a reviewer. Look for postings of other opportunities and reviewer sign up on the SWEBOK Volunteer page.

Anyone who develops software should be familiar with the guide and use it where applicable.

There are a multitude of purposes for using SWEBOK including:

• Understanding Software Engineering
• Guiding Education and Training
• Professional Development
• Standardizing Practices
• Certification Preparation

The Computer Society began defining this body of knowledge in 1998 as a necessary step toward making software engineering a legitimate engineering discipline and a recognized profession. As software becomes the center of critical systems, it is only natural that standards of practice, knowledge, and training would arise in software engineering.

A simple definition is “established traditional practices recommended by many organizations.”

Another definition that the SWEBOK guide uses comes from the Project Management Institute. Its Guide to the Project Management Body of Knowledge defines “generally accepted” knowledge for project management in the following manner:

“‘Generally accepted’ means that the knowledge and practices described are applicable to most projects most of the time and that there is widespread consensus about their value and usefulness. ‘Generally accepted’ does not mean that the knowledge and practices described are or should be applied uniformly on all projects; the project management team is always responsible for determining what is appropriate for any given project.”

The Industrial Advisory Board for the 2004 SWEBOK guide better defines “generally accepted” as knowledge to be included in the study material of a software engineering licensing exam that a graduate would pass after completing four years of work experience. These two definitions should be seen as complementary.

The SWEBOK guide uses a rigorous process that includes successive levels of review. When an editor proposes a draft knowledge area, a selected group of invited experts provide wide-ranging comments, in a review similar to that for academic papers. The group discusses these comments, and the editor then incorporates the accepted changes.

Next, a larger group of invited practitioners answers a set list of about 14 questions on the new draft. These questions have to do with relevancy and usefulness, and the editor uses the responses to further refine the draft. The last review is open to the public, but comments must be specific and refer to a particular line or item within the draft.

Many publications and books have referred to the SWEBOK Guide. Examples are the following but not limited to them. Many more publications discuss and refer to the SWEBOK Guide available on the IEEE Computer Society Digital Library (CSDL) and the IEEE Xplorer®.

1. D. R. Fairley, P. Bourque, and J. Kepple, “The impact of SWEBOK Version 3 on software engineering education and training,” 2014 IEEE 27th Conference on Software Engineering Education and Training (CSEE&T), 2014.
2. A. Rashid, G. Danezis, H. Chivers, E. Lupu, A. Martin, M. Lewis, and C. Peersman, “Scoping the Cyber Security Body of Knowledge,” IEEE Security & Privacy, Vol. 16, No. 3, 2018.
3. J. Voas, R. Kuhn, C. Paulsen, and K. Schaffer, “Computer Science Education in 2018,” IT Professional, Vol. 20, No. 1, 2018.
4. P. Bourque, “The SWEBOK Guide — More Than 20 Years down the Road,” 2020 IEEE 32nd Conference on Software Engineering Education and Training (CSEE&T), 2020.
5. Z. Sun, C. Hu, C. Li, and L. Wu, “Domain Ontology Construction and Evaluation for the Entire Process of Software Testing,” IEEE Access, Vol. 8, 2020.
6. I. Ozkaya, “An AI Engineer Versus a Software Engineer,” IEEE Software, Vol. 39, No. 6, 2022.
7. M. Kuhrmann, et al., “What Makes Agile Software Development Agile?” IEEE Transactions on Software Engineering, Vol. 48, No. 9, 2022.
8. Z. Kotti, G. Gousios, and D. Spinellis, “Impact of Software Engineering Research in Practice: A Patent and Author Survey Analysis,” IEEE Transactions on Software Engineering, Vol. 49, No. 4, 2023.
9. F. Ebbers, “A Large-Scale Analysis of IoT Firmware Version Distribution in the Wild,” IEEE Transactions on Software Engineering, Vol. 49, No. 2, 2023.
10. H. Washizaki, M. Sanchez-Segura, J. Garbajosa, S. Tockey, and K. Nidiffer, “Envisioning software engineer training needs in the digital era through the SWEBOK V4.0 prism,” 2023 IEEE 35th International Conference on Software Engineering Education and Training (CSEE&T), 2023.

The Consolidated Reference List identifies all recommended reference materials that accompany the breakdown of topics within each knowledge area (KA). This Consolidated Reference List is adopted by the software engineering certification and associated professional development products offered by the IEEE Computer Society. KA Editors used the references allocated to their KA by the Consolidated Reference List as their Recommended References. See Appendix C of the guide for more details.

• A. Silberschatz, P.B. Galvin, and G. Gagne, Operating System Concepts, 8th ed., Wiley, 2008.
• A.M.J. Hass, Configuration Management Principles and Practices, 1st ed., Addison-Wesley, 2003.
• B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, 2003.
• C.Y. Laporte, A. April, Software Quality Assurance, IEEE Computer Society Press, 1st ed., 2018.
• D. Budgen, Software Design, 3rd ed., CRC Press, 2021.
• D. C. Montgomery and G. C. Runger, Applied Statistics and Probability for Engineers, 7th ed. Hoboken, NJ: Wiley, 2018.
• D. Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster, Addison-Wesley Professional, 2022.
• E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1st ed., Addison-Wesley Professional, 1994.
• E.W. Cheney and D.R. Kincaid, Numerical Mathematics and Computing, 6th ed., Brooks/Cole, 2007.
• E.W. Cheney and D.R. Kincaid, Numerical Mathematics and Computing, 7th ed., Addison Wesley, 2020.
• F. Bott et al., Professional Issues in Software Engineering, 3rd ed., Taylor & Francis, 2000.
• G. Booch, J. Rumbaugh and I. Jacobson, The Unified Modeling Language User Guide, 2nd edition, Addison-Wesley, 2005.
• G. Kim, J. Humble, P. Debois, J. Willis and J. Allspaw, The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, 2nd ed., IT Revolution, 2021.
• G. Voland, Engineering by Design, 2nd ed., Prentice Hall, 2003.
• I. Sommerville, Software Engineering, 10th ed., Addison-Wesley, 2016.
• J. McGarry et al., Practical Software Measurement: Objective Information for Decision Makers, Addison-Wesley Professional, 2001.
• J. Nielsen, Usability Engineering, 1st ed., Morgan Kaufmann, 1993.
• J. Shore and S. Warden, The Art of Agile Development, O’Reilly Media, 2nd Edition, 2021.
• J.G. Brookshear, Computer Science: An Overview, 12th ed., Addison-Wesley, 2017.
• J.H. Allen et al., Software Security Engineering: A Guide for Project Managers, Addison-Wesley, 2008.
• J.M. Wing, A Specifier’s Introduction to Formal Methods, Computer, vol. 23, no. 9, 1990, pp. 8, 10–23.
• K. Rosen, Discrete Mathematics and its Applications, 8th ed., McGraw-Hill, 2018.
• K.E. Wiegers, Software Requirements, 3rd ed., Microsoft Press, 2013.
• L. Null and J. Lobur, The Essentials of Computer Organization and Architecture, 2nd ed., Jones and Bartlett Publishers, 2006.
• L. Null and J. Lobur, The Essentials of Computer Organization and Architecture, 5th ed. Sudbury, MA: Jones and Bartlett Publishers, 2018.
• M. Bishop, Computer Security: Art and Science, 2nd Edition, Addison-Wesley, 2018.
• M. Page-Jones, Fundamentals of Object-Oriented Design in UML, 1st ed., Addison-Wesley, 1999.
• N. Rozanski and E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2nd edition, Addison-Wesley, 2011.
• P. Clements et al., Documenting Software Architectures: Views and Beyond, 2nd ed., Pearson Education, 2010.
• P. Grubb and A.A. Takang, Software Maintenance: Concepts and Practice, 2nd ed., World Scientific Publishing, 2003.
• Project Management Institute and Agile Alliance, Agile Practice Guide, Project Management Institute, 2017.
• R.E. Fairley, Managing and Leading Software Projects, Wiley-IEEE Computer Society Press, 2009.
• R.N. Taylor, N. Medvidović, E. Dashofy, Software Architecture: Foundations, Theory, and Practice, Wiley, 2009.
• S. McConnell, Code Complete, 2nd ed., Microsoft Press, 2004.
• S. Naik and P. Tripathy, Software Testing and Quality Assurance: Theory and Practice, Wiley-Spektrum, 2008.
• S. Tockey, Return on Software: Maximizing the Return on Your Software Investment, 1st ed., Addison-Wesley, 2004.
• S.H. Kan, Metrics and Models in Software Quality Engineering, 2nd ed., Addison-Wesley, 2002.
• S.J. Mellor and M.J. Balcer, Executable UML: A Foundation for Model-Driven Architecture, 1st ed., Addison-Wesley, 2002.

The document you are about to download is protected by US and international copyright laws, and is made available to you exclusively for your own individual, non-commercial purposes. This User License Agreement describes the terms and conditions that you agree to with regard to using SWEBOK version 4.0.

What You Can Do

This license gives you the right to print and retain a single hard copy of the PDF file, and to maintain the PDF version on your personal computer and/or mobile device. You may also post SWEBOK 4.0 on a corporate or institutional intranet or similar site for reference use by employees or staff (however, all other limitations and requirements apply to those users as well). You may quote or reproduce reasonable passages from SWEBOK 4.0 in a review, article, scholarly, or educational material, provided that you provide an appropriate citation to the source document. Educational use of this material is permitted without fee provided that:

• Copies are made for non-profit educational use and not for resale, advertising, or other commercial use;
• Any copy or other use is accompanied by a full citation to the original work and its copyright;
• The copied text has not been materially altered

What You Cannot Do

You may not copy or otherwise reproduce or share SWEBOK 4.0. Under no circumstances are you permitted to distribute or sell SWEBOK version 4.0 without permission. You may not post SWEBOK version 4.0 publicly, or provide any manner of public access to your downloaded document, including through links. You may not translate SWEBOK 4.0 into other languages, reuse significant portions of SWEBOK 4.0 for commercial purposes, or alter the text of SWEBOK 4.0 in any way.

The Fine Print

While all reasonable care has been taken in the preparation and review of SWEBOK version 4.0, the IEEE does not warrant that the document is accurate, current, or suitable for your particular purpose. In making this document available to you, IEEE is not rendering legal, accounting, technical, or other professional services. In no event shall the IEEE be liable for any direct, indirect, punitive, incidental, special, consequential, or any other damages or judgments whatsoever arising out of or connected with the use or misuse of this document.

This transaction is governed by the laws of New York.

If you have any questions or concerns regarding these terms, or if you have other questions regarding copyright and potential uses, please contact the IEEE Computer Society at help@computer.org.