1. Guide to the Software Engineering Body of
Knowledge
2004 Version
SWEBOK®
A project of the IEEE Computer Society
Professional Practices Committee
© IEEE – 2004 Version ®SWEBOK is an official service mark of the IEEE

2. © IEEE – 2004 Version

3. Guide to the Software Engineering Body of
Knowledge
2004 Version
SWEBOK®
Executive Editors
Alain Abran, École de technologie supérieure
James W. Moore, The MITRE Corp.
Editors
Pierre Bourque, École de technologie supérieure
Robert Dupuis, Université du Québec à Montréal
Project Champion
Leonard L. Tripp, Chair, Professional Practices Committee,
IEEE Computer Society (2001-2003)
http://computer.org
Los Alamitos, California
Washington • Brussels • Tokyo
© IEEE – 2004 Version ®SWEBOK is an official service mark of the IEEE

4. Library of Congress Cataloging-in-Publication Data
Guide to the software engineering body of knowledge : 2004 version
/ executive editors, Alain Abran, James W. Moore;
editors, Pierre Bourque, Robert Dupuis, Leonard L. Tripp.
p. cm.
1. Software engineering. 2. Computer software--Development. I.
Abran, Alain, 1949- . II. Moore, James W., 1948- .
To be completed
2001005442
Copyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved.
Copyright and Reprint Permissions: This document may be copied, in whole or in part, in any form or by any means, as is, or
with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included
unmodified in any copy. Any other use or distribution of this document is prohibited without the prior express permission of
IEEE.
You use this document on the condition that you indemnify and hold harmless IEEE from any and all liability or damages to
yourself or your hardware or software, or third parties, including attorneys' fees, court costs, and other related costs and expenses,
arising out of your use of this document irrespective of the cause of said liability.
IEEE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO WARRANTY, EXPRESS OR IMPLIED, AS TO
THE ACCURACY, CAPABILITY, 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.
To be completed
Additional copies may be ordered from:
IEEE Computer Society IEEE Service Center IEEE Computer Society
Customer Service Center 445 Hoes Lane Asia/Pacific Office
10662 Los Vaqueros Circle P.O. Box 1331 Watanabe Bldg., 1-4-2
P.O. Box 3014 Piscataway, NJ 08855-1331 Minami-Aoyama
Los Alamitos, CA 90720-1314 Tel: + 1-732-981-0060 Minato-ku, Tokyo 107-0062
Tel: + 1-714-821-8380 Fax: + 1-732-981-9667 JAPAN
Fax: + 1-714-821-4641 http://shop.ieee.org/store/ Tel: + 81-3-3408-3118
E-mail: cs.books@computer.org customer-service@ieee.org Fax: + 81-3-3408-3553
tokyo.ofc@computer.org
Publisher: Angela Burgess
Group Managing Editor, CS Press: Deborah Plummer
Advertising/Promotions: Tom Fink
Production Editor: Bob Werner
Printed in the United States of America
© IEEE – 2004 Version

5. TABLE OF CONTENTS
FOREWORD ..................................................................................................................................vii
SWEBOK Committees ................................................................................................................ ix
Preface to the SWEBOK Guide...............................................................................................xviii
CHAPTER 1 INTRODUCTION TO THE GUIDE ..........................................................................1-1
CHAPTER 2 SOFTWARE REQUIREMENTS ...............................................................................2-1
CHAPTER 3 SOFTWARE DESIGN ...........................................................................................3-1
CHAPTER 4 SOFTWARE CONSTRUCTION ..............................................................................4-1
CHAPTER 5 SOFTWARE TESTING..........................................................................................5-1
CHAPTER 6 SOFTWARE MAINTENANCE ...............................................................................6-1
CHAPTER 7 SOFTWARE CONFIGURATION MANAGEMENT ....................................................7-1
CHAPTER 8 SOFTWARE ENGINEERING MANAGEMENT .........................................................8-1
CHAPTER 9 SOFTWARE ENGINEERING PROCESS ..................................................................9-1
CHAPTER 10 SOFTWARE ENGINEERING TOOLS AND METHODS ...........................................10-1
CHAPTER 11 SOFTWARE QUALITY.......................................................................................11-1
CHAPTER 12 KNOWLEDGE AREAS OF THE RELATED DISCIPLINES………………….….…..12-1
APPENDIX A KNOWLEDGE AREA DESCRIPTION SPECIFICATIONS FOR THE
2004 VERSION OF THE GUIDE TO THE SOFTWARE ENGINEERING
BODY OF KNOWLEDGE.....................................................................................A-1
Appendix B EVOLUTION OF THE GUIDE ............................................................................... B-1
APPENDIX C ALLOCATION OF IEEE AND ISO SOFTWARE ENGINEERING STANDARDS TO
SWEBOK KNOWLEDGE AREAS ...................................................................... C-1
APPENDIX D CLASSIFICATION OF TOPICS ACCORDING TO BLOOM’S TAXONOMY ................D-1
© IEEE – 2004 Version v

6. vi © IEEE – 2004 Version

7. FOREWORD
In this Guide, the IEEE Computer Society establishes for the first time a baseline for the body of knowledge for
the field of software engineering, and the work partially fulfills the Society’s responsibility to promote the
advancement of both theory and practice in this field. In so doing, the Society has been guided by the experience of
disciplines with longer histories, but was not bound either by their problems or their solutions.
It should be noted that the Guide does not purport to define the body of knowledge, but rather to serve as a
compendium and guide to the body of knowledge that has been developing and evolving over the past four decades.
Furthermore, this body of knowledge is not static. The Guide must, necessarily, develop and evolve as software
engineering matures. It nevertheless constitutes a valuable element of the software engineering infrastructure.
In 1958, John Tukey, the world-renowned statistician, coined the term software. The term software engineering
was used in the title of a NATO conference held in Germany in 1968. The IEEE Computer Society first published its
Transactions on Software Engineering in 1972. The committee established within the IEEE Computer Society for
developing software engineering standards was founded in 1976.
The first holistic view of software engineering to emerge from the IEEE Computer Society resulted from an
effort led by Fletcher Buckley to develop IEEE standard 730 for software quality assurance, which was completed in
1979. The purpose of IEEE Std 730 was to provide uniform, minimum acceptable requirements for preparation and
content of software quality assurance plans. This standard was influential in completing the developing standards in
the following topics: configuration management, software testing, software requirements, software design, and
software verification and validation.
During the period 1981-1985, the IEEE Computer Society held a series of workshops concerning the application
of software engineering standards. These workshops involved practitioners sharing their experiences with existing
standards. The workshops also held sessions on planning for future standards, including one involving measures and
metrics for software engineering products and processes. The planning also resulted in IEEE Std 1002, Taxonomy of
Software Engineering Standards (1986), which provided a new, holistic view of software engineering. The standard
describes the form and content of a software engineering standards taxonomy. It explains the various types of
software engineering standards, their functional and external relationships, and the role of various functions
participating in the software life cycle.
In 1990, planning for an international standard with an overall view was begun. The planning focused on
reconciling the software process views from IEEE Std 1074 and the revised U.S. DoD standard 2167A. The revision
was eventually published as DoD Std 498. The international standard was completed in 1995 with designation,
ISO/IEC12207, and given the title of Standard for Software Life Cycle Processes. Std ISO/IEC 12207 provided a
major point of departure for the body of knowledge captured in this book.
It was the IEEE Computer Society Board of Governors’ approval of the motion put forward in May 1993 by
Fletcher Buckley which resulted in the writing of this book. The Association for Computing Machinery (ACM)
Council approved a related motion in August 1993. The two motions led to a joint committee under the leadership of
Mario Barbacci and Stuart Zweben who served as co-chairs. The mission statement of the joint committee was “To
establish the appropriate sets(s) of criteria and norms for professional practice of software engineering upon which
industrial decisions, professional certification, and educational curricula can be based.” The steering committee
organized task forces in the following areas:
1. Define Required Body of Knowledge and Recommended Practices;
2. Define Ethics and Professional Standards;
3. Define Educational Curricula for undergraduate, graduate, and continuing education.
This book supplies the first component: required body of knowledge and recommend practices.
The code of ethics and professional practice for software engineering was completed in 1998 and approved by
both the ACM Council and the IEEE Computer Society Board of Governors. It has been adopted by numerous
corporations and other organizations and is included in several recent textbooks.
The educational curriculum for undergraduates is being completed by a joint effort of the IEEE Computer
Society and the ACM, and is expected to be completed in 2004.
© IEEE – 2004 Version vii

8. Every profession is based on a body of knowledge and recommended practices, although they are not always
defined in a precise manner. In many cases, these are formally documented, usually in a form that permits them to be
used for such purposes as accreditation of academic programs, development of education and training programs,
certification of specialists, or professional licensing. Generally, a professional society or related body maintains
custody of such a formal definition. In cases where no such formality exists, the body of knowledge and
recommended practices are “generally recognized” by practitioners and may be codified in a variety of ways for
different uses.
It is hoped that readers will find this book useful in guiding them towards the knowledge and resources they need
in their lifelong career development as software engineering professionals.
The book is dedicated to Fletcher Buckley in recognition of his commitment to promoting software engineering
as a professional discipline and his excellence as a software engineering practitioner in radar applications.
Leonard L. Tripp, IEEE Fellow 2003
Chair, Professional Practices Committee, IEEE Computer Society, (2001-2003)
Chair, Joint IEEE Computer Society and ACM Steering Committee
for the Establishment of Software Engineering as a Profession (1998-1999)
Chair, Software Engineering Standards Committee, IEEE Computer Society (1992-1998)
viii © IEEE – 2004 Version

9. ASSOCIATE EDITORS
The following persons served as Associate Editors for either the Trial version published in 2001
or for the 2004 version.
Software Requirements
PeterSawyer and Gerald Kotonya, Computing Department, Lancaster University, UK,
{p.sawyer} {g.kotonya}@lancaster.ac.uk
Software Design
Guy Tremblay, Département d’informatique, UQAM, Canada, tremblay.guy@uqam.ca
Software Construction
Steve McConnell, Construx Software, USA, Steve.McConnell@construx.com
Terry Bollinger, the MITRE Corporation, USA, terry@mitre.org
Philippe Gabrini, Département d’informatique, UQAM, Canada,
gabrini.philippe@uqam.ca
Louis Martin, Département d’informatique, UQAM, Canada,
martin.louis@uqam.ca
Software Testing
Antonia Bertolino and Eda Marchetti, ISTI-CNR, Italy,
{antonia.bertolino} {eda.marchetti}@isti.cnr.it
Software Maintenance
Thomas M. Pigoski, Techsoft Inc., USA, tmpigoski@techsoft.com
Alain April, École de technologie supérieure, Canada, aapril@ele.etsmtl.ca
Software Configuration Management
John A. Scott, Lawrence Livermore National Laboratory, USA, scott7@llnl,gov
David Nisse, USA, nissed@worldnet.att.net
Software Engineering Management
Dennis Frailey, Raytheon Company, USA, DJFrailey@Raytheon.com
Stephen G. MacDonell, Auckland University of technology, New Zealand,
smacdone@aut.ac.nz
Andrew R. Gray, University of Otago, New Zealand
Software Engineering Process
Khaled El Eman, served while at the Canadian National Research Council, Canada,
khaled.el-emam@nrc-cnrc.gc.ca
Software Engineerting Tools and Methods
David Carrington, School of Information Technology and electrical Engineering, The
University of Queensland, Australia,
davec@itee.uq.edu.au
Software Quality
Alain April, École de technologie supérieure, Canada, aapril@ele.etsmtl.ca
Dolores Wallace, retired from the National Institute of Standards and Technology, USA
Dolores.Wallace@nist.gov
Larry Reeker, NIST, USA, Larry.Reeker@nist.gov
References Editor
Marc Bouisset, Département d’informatique, UQAM, Bouisset.Marc@uqam.ca
© IEEE – 2004 Version ix

10. x © IEEE – 2004 Version

11. Industrial Advisory
BOARD
At the time of the publication, the following people formed the Industrial Advisory Board:
Mario R. Barbacci, Software Engineering Institute, representing the
IEEE Computer Society
Carl Chang, representing Computing Curricula 2001
François Coallier, École de technologie supérieure, speaking as ISO/IEC JTC 1 / SC7
Chairman
Charles Howell, The MITRE Corporation
Anatol Kark, National Research Council of Canada
Philippe Kruchten, University of British Columbia, served as representative of Rational
Software
Laure Le Bars, SAP Labs (Canada)
Steve McConnell, Construx Software
Dan Nash, Raytheon Company
Fred Otto, Canadian Council of Professional Engineers (CCPE)
Richard Metz, The Boeing Company
Larry Reeker, National Institute of Standards and Technology,
Department of Commerce, USA
The following persons served along with the IAB in the Executive Change Control Board for
the 2004 edition:
Donald Bagert, Rose-Hulman Institute of Technology, represening the IEEE Computer
Society Professional Practices Committee
Ann Sobel, Miami University, representing the Computing Curricula Software
Engineering Steering Committee
© IEEE – 2004 Version xi

12. PANEL OF EXPERTS
The following persons served on the panel of expert for the preparation of the Trial version of the
Guide:
Steve McConnell, Construx Software
Roger Pressman, R.S. Pressman and Associates
Ian Sommerville, Lancaster University, UK
xii © IEEE – 2004 Version

13. REVIEW TEAM
The following people participated in the review process of this Guide, for the Trial version and/or
for the 2004 version.
Abbas, Rasha, Australia Bierwolf, Robert, The Charette, Robert, USA
Abran , Alain, Canada Netherlands Chevrier, Marielle, Canada
Accioly, Carlos, Brazil Bisbal, Jesus, Ireland Chi, Donald, USA
Ackerman, Frank, USA Boivin, Michel, Canada Chiew, Vincent, Canada
Akiyama, Yoshihiro, Japan Bolton , Michael, Canada Chilenski, John, USA
Al-Abdullah, Mohammad, USA Bomitali, Evelino, Italy Chow, Keith, Italy
Alarcon, Miren Idoia, Spain Bonderer, Reto, Switzerland Ciciliani, Ricardo, Argentina
Alawy, Ahmed, USA Bonk, Francis, USA Clark, Glenda, USA
Alleman, Glen, USA Booch, Grady, USA Cleavenger, Darrell, USA
Allen, Bob, Canada Booker, Glenn, USA Cloos, Romain, Luxembourg
Allen, David, USA Börstler, Jürgen, Sweden Coallier, François, Canada
Amorosa, Francesco, Italy Borzovs, Juris, Latvia Coblentz, Brenda, USA
Amyot, Daniel, Canada Botting, Richard, USA Cohen, Phil, Australia
Andrade, Daniel, Brazil Bourque, Pierre, Canada Collard, Ross, New Zealand
April, Alain, Canada Bowen, Thomas, USA Collignon, Stephane, Australia
Arroyo-Figueror, Javier, USA Boyd, Milt, USA Connors, Kathy Jo, USA
Ashford, Sonny, USA Boyer, Ken, USA Cooper, Daniel, USA
Atsushi, Sawada, Japan Brashear, Phil, USA Councill, Bill, USA
Backitis Jr., Frank, USA Briggs, Steve, USA Cox, Margery, USA
Bagert, Donald, USA Bright, Daniela, USA Cunin, Pierre-Yves, France
Baker, Jr., David, USA Brosseau, Jim, Canada DaLuz, Joseph, USA
Baker, Theodore, USA Brotbeck, George, USA Dampier, David, USA
Baldwin, Mark, USA Brown, Normand, Canada Daneva , Maya, Canada
Bales, David, UK Bruhn, Anna, USA Daneva, Maya, Canada
Bamberger, Judy, USA Brune, Kevin, USA Daughtry, Taz, USA
Banerjee, Bakul, USA Bryant, Jeanne, USA Davis, Ruth, USA
Barber, Scott, USA Buglione, Luigi, Italy De Cesare, Sergio, UK
Barker, Harry, UK Bullock, James, USA Dekleva, Sasa, USA
Barnes, Julie, USA Burns, Robert, USA Del Castillo, Federico, Peru
Barney, David, Australia Burnstein, Ilene, USA Del Dago, Gustavo, Argentina
Barros, Rafael, Colombia Byrne, Edward, USA DeWeese, Perry, USA
Bastarache, Louis, Canada Calizaya, Percy, Peru Di Nunno, Donn, USA
Bayer, Steven, USA Carreon, Juan, USA Diaz-Herrera, Jorge, USA
Beaulac, Adeline, Canada Carroll, Sue, USA Dieste, Oscar, Spain
Beck, William, USA Carruthers, Kate, Australia Dion, Francis, Canada
Beckman, Kathleen, USA Caruso, Richard, USA Dixon, Wes, USA
Below, Doreen, USA Carvalho, Paul, Canada Dolado, Javier, Spain
Benediktsson, Oddur, Iceland Case, Pam, USA Donaldson, John, UK
Ben-Menachem, Mordechai, Cavanaugh, John, USA Dorantes, Marco, Mexico
Israel Celia, John A., USA Dorofee, Audrey, USA
Bergeron, Alain, Canada Chalupa Sampaio, Alberto Douglass, Keith, Canada
Berler, Alexander, Greece Antonio, Portugal Du, Weichang, Canada
Bernet, Martin, USA Chan, F.T., Hong Kong Duben, Anthony, USA
Bernstein, Larry, USA Chan, Keith, Hong Kong Dudash, Edward, USA
Bertram, Martin, Germany Chandra, A.K., India Duncan, Scott, USA
Bialik , Tracy, USA Chang, Wen-Kui, Taiwan Duong, Vinh, Canada
Bielikova, Maria, Slovakia Chapin, Ned, USA Durham, George, USA
© IEEE – 2004 Version xiii

14. Dutil, Daniel, Canada Gresse von Wangenheim, Jones, Griffin, USA
Dutton, Jeffrey, USA Christiane, Brazil Jones, James E., USA
Ebert, Christof, France Grigonis, George, USA Jones, Alan, UK
Edge, Gary, USA Gupta, Arun, USA Jones, James, USA
Edwards, Helen Maria, UK Gustafson, David, USA Jones, Larry, Canada
El-Kadi, Amr, Egypt Gutcher, Frank, USA Jones, Paul, USA
Endres, David, USA Haas, Bob, USA Ju, Dehua, China
Engelmann, Franz, Switzerland Hagar, Jon, USA Juan-Martinez, Manuel-
Escue, Marilyn, USA Hagstrom, Erick, USA Fernando, Spain
Espinoza, Marco, Peru Hailey, Victoria, Canada Juhasz, Zoltan, Hungary
Fay, Istvan, Hungary Hall, Duncan, New Zealand Juristo, Natalia, Spain
Fayad, Mohamed, USA Haller, John, USA Kaiser, Michael, Switzerland
Fendrich, John, USA Halstead-Nussloch, Richard, Kambic, George, USA
Ferguson, Robert, USA USA Kamthan, Pankaj, Canada
Fernandez, Eduardo, USA Hamm, Linda, USA Kaner, Cem, USA
Fernandez-Sanchez, Jose Luis, Hankewitz, Lutz, Germany Kark, Anatol, Canada
Spain Harker, Rob, USA Kasser, Joe, USA
Filgueiras, Lucia, Brazil Hart, Hal, USA Kasser, Joseph, Australia
Finkelstein, Anthony, UK Hart, Ronald, USA Katz, Alf, Australia
Flinchbaugh, Scott, USA Hartner, Clinton, USA Kececi, Nihal, Canada
Forrey, Arden, USA Hayeck, Elie, USA Kell, Penelope, USA
Fortenberry, Kirby, USA He, Zhonglin, UK Kelly, Diane, Canada
Foster, Henrietta, USA Hedger, Dick, USA Kelly, Frank, USA
Fowler, Martin, USA Hefner, Rick, USA Kenett, Ron, Israel
Fowler, John Jr., USA Heinrich, Mark, USA Kenney, Mary L., USA
Fox, Christopher, USA Heinze, Sherry, Canada Kerievsky, Joshua, USA
Frankl, Phyllis, USA Hensel, Alan, USA Kerr, John, USA
Freibergs, Imants, Latvia Herrmann, Debra, USA Kierzyk, Robert, USA
Frezza, Stephen, USA Hesse, Wolfgang, Germany Kinsner, W., Canada
Fruehauf, Karol, Switzerland Hilburn, Thomas, USA Kirkpatrick, Harry, USA
Fuggetta, Alphonso, Italy Hill, Michael, USA Kittiel, Linda, USA
Fujii, Roger, USA Ho, Vinh, Canada Klappholz, David, USA
FUSCHI, David Luigi, Italy Hodgen, Bruce, Australia Klein, Joshua, Israel
Fuschi, David Luigi, Italy Hodges, Brett, Canada Knight, Claire, UK
Gabrini, Philippe, Canada Hoffman, Douglas, Canada Knoke, Peter, USA
Gagnon, Eric, Canada Hoffman, Michael, USA Ko, Roy, Hong Kong
Ganor, Eitan, Israel Hoganson, Tammy, USA Kolewe, Ralph, Canada
Garbajosa, Juan, Spain Hollocker, Chuck, USA Komal, Surinder Singh, Canada
Garceau, Benoît, Canada Horch, John, USA Kovalovsky, Stefan, Austria
Garcia-Palencia, Omar, Howard, Adrian, United Krauth, Péter, Hungary
Colombia Kingdom Krishnan, Nirmala, USA
Garner, Barry, USA Huang, Hui Min, USA Kromholz, Alfred, Canada
Gelperin, David, USA Hung, Chih-Cheng, USA Kruchten, Philippe, Canada
Gersting, Judith, Hawaii Hung, Peter, USA Kuehner, Nathanael, Canada
Giesler, Gregg, USA Hunt, Theresa, USA Kwok, Shui Hung, Canada
Gil, Indalecio, Spain Hunter, John, USA Lacroix, Dominique, Canada
Gilchrist, Thomas, USA Hvannberg, Ebba Thora, Iceland LaMotte, Stephen W., USA
Giurescu, Nicolae, Canada Hybertson, Duane, USA Land, Susan, USA
Glass, Robert, USA Ikiz, Seckin, Turkey Lange, Douglas, USA
Glynn, Garth, UK Iyengar, Dwaraka, USA Laporte, Claude, Canada
Goers, Ron, USA Jackelen, George, USA Lawlis, Patricia, USA
Gogates, Gregory, USA Jaeger, Dawn, USA Le, Thach, USA
Goldsmith, Robin, USA Jahnke, Jens, Canada Leavitt, Randal, Canada
Goodbrand, Alan, Canada James, Jean, USA LeBel, Réjean, Canada
Gorski, Janusz, Poland Jino, Mario, Brazil Leciston, David, USA
Graybill , Mark, USA Johnson, Vandy, USA Lee, Chanyoung, USA
xiv © IEEE – 2004 Version

15. Lehman, Meir (Manny), UK Miller, Mark, USA Phipps, Robert, USA
Leigh, William, USA Miranda, Eduardo, Canada Phister, Paul, USA
Lembo, Jim, USA Mistrik, Ivan, Germany Phister, Jr., Paul, USA
Lenss, John, USA Mitasiunas, Antanas, Lithuania Piattini, Mario, Spain
Leonard, Eugene, USA Modell, Howard, USA Piersall, Jeff, USA
Lethbridge, Timothy, Canada Modell, Staiger,USA Pillai, S.K., India
Leung, Hareton, Hong Kong Modesitt, Kenneth, USA Pinder, Alan, UK
Lever, Ronald, The Netherlands Moland, Kathryn, USA Pinheiro, Francisco A., Brazil
Levesque, Ghislain, Canada Moldavsky, Symon, Ukraine Plekhanova, Valentina, United
Ley, Earl, USA Montequín, Vicente R., Spain Kingdom
Linders , Ben, Netherlands Moreno, Ana Maria, Spain Poon, Peter, USA
Linscomb , Dennis, USA Mosiuoa, Tseliso, Lesotho Poppendieck, Mary, USA
Little, Joyce Currie, USA Moudry, James, USA Powell, Mace, USA
Logan, Jim, USA Msheik, Hamdan, Canada Predenkoski, Mary, USA
Long, Carol, United Kingdom Mularz, Diane, USA Prescott, Allen, USA
Lounis, Hakim, Canada Mullens, David, USA Pressman, Roger, USA
Low, Graham, Australia Müllerburg, Monika, Germany Price, Art, USA
Lutz, Michael, USA Murali, Nagarajan, Australia Price, Margaretha, USA
Lynch, Gary, USA Murphy, Mike, USA Pullum, Laura, USA
Machado, Cristina, Brazil Napier, John, USA Purser, Keith, USA
MacKay, Stephen, Canada Narasimhadevara, Sudha, Purssey, John, Australia
MacKenzie, Garth, USA Canada Pustaver, John, USA
MacNeil, Paul, USA Narawane, Ranjana, India Quinn, Anne, USA
Magel, Kenneth, USA Narayanan, Ramanathan, India Radnell, David, Australia
Mains, Harold, USA Navarro Ramirez, Daniel, Rae, Andrew, United Kingdom
Malak, Renee, USA Mexico Rafea, Ahmed, Egypt
Maldonado, José Carlos, Brazil Navas Plano, Francisco, Spain Ramsden, Patrick, Australia
Marcos, Esperanza, Spain Navrat, Pavol, Slovakia Rao, N.Vyaghrewara, India
Marinescu, Radu, Romania Neumann, Dolly, USA Rawsthorne, Dan, USA
Marm, Waldo, Peru Nguyen-Kim, Hong, Canada Reader, Katherine, USA
Marusca, Ioan, Canada Nikandros, George, Australia Reddy, Vijay,USA
Matlen, Duane, USA Nishiyama, Tetsuto, Japan Redwine, Samuel, USA
Matsumoto, Yoshihiro, Japan Nunn, David, USA Reed, Karl, Australia
McBride, Tom, Australia O'Donoghue, David, Ireland Reedy, Ann, USA
McCarthy, Glenn, USA Oliver, David John, Australia Reeker, Larry, USA
McChesney, Ian, UK Olson, Keith, USA Rethard, Tom, USA
McCormick, Thomas, Canada Oskarsson, Östen, Sweden Reussner, Ralf, Germany
McCown, Christian, USA Ostrom, Donald, USA Rios, Joaquin, Spain
McDonald, Jim, USA Oudshoorn, Michael, Australia Risbec, Philippe, France
McGrath Carroll, Sue, USA Owen, Cherry, USA Roach, Steve, USA
McHutchison, Diane, USA Pai, Hsueh-Ieng, Canada Robillard, Pierre, Canada
McKinnell, Brian, Canada Parrish, Lee, USA Rocha, Zalkind, Brazil
McMichael, Robert, USA Parsons, Samuel, USA Rodeiro Iglesias, Javier, Spain
McMillan, William, USA Patel, Dilip, UK Rodriguez-Dapena, Patricia,
McQuaid, Patricia, USA Paulk, Mark, USA Spain
Mead, Nancy, USA Pavelka, Jan, Czech Republic Rogoway, Paul, Israel
Meeuse, Jaap, The Netherlands Pavlov, Vladimir, Ukraine Rontondi, Guido, Italy
Meier, Michael, USA Pawlyszyn, Blanche, USA Roose, Philippe, France
Meisenzahl, Christopher, USA Pecceu, Didier, France Rosca, Daniela, USA
Melhart, Bonnie, USA Perisic, Branko, Yugoslavia Rosenberg, Linda, USA
Mengel, Susan, USA Perry, Dale, USA Rourke, Michael, Australia
Meredith, Denis, USA Peters, Dennis, Canada Rout, Terry, Australia
Meyerhoff, Dirk, Germany Petersen, Erik, Australia Rufer, Russ, USA
Mili, Hafedh, Canada Pfahl, Dietmar, Germany Ruiz, Francisco, Spain
Miller, Chris, Netherlands Pfeiffer, Martin, Germany Ruocco, Anthony, USA
Miller, Keith, USA Phillips, Dwayne, USA Rutherfoord, Rebecca, USA
© IEEE – 2004 Version xv

16. Ryan, Michael, Ireland Sorensen, Reed, USA Urbanowicz, Theodore, USA
Salustri, Filippo, Canada Soundarajan, Neelam, USA Van Duine, Dan, USA
Salustri, Filippo, Canada Sousa Santos, Frederico, Van Ekris, Jaap, Netherlands
Salwin, Arthur, USA Portugal Van Oosterhout, Bram, Australia
Sanden, Bo, USA Spillers, Mark, USA Vander Plaats, Jim, USA
Sandmayr, Helmut, Switzerland Spinellis, Diomidis, Greece Vegas, Sira, Spain
Santana Filho, Ozeas Vieira, Splaine, Steve, USA Verner, June, USA
Brazil Springer, Donald, USA Villas-Boas, André, Brazil
Sato, Tomonobu, Japan Staiger, John, USA Vollman, Thomas, USA
satyadas, antony, USA Starai, Thomas, USA Walker, Richard, Australia
Satyadas, Antony, USA Steurs, Stefan, Belgium Walsh, Bucky, USA
Schaaf, Robert, USA St-Pierre, Denis, Canada Wang, Yingxu, Sweden
Scheper, Charlotte, USA Stroulia, Eleni, Canada Wear, Larry, USA
Schiffel, Jeffrey, USA Subramanian, K.S., India Weigel, richard, USA
Schlicht, Bill, USA Sundaram, Sai, UK Weinstock, Charles, USA
Schrott, William, USA Swanek, James, USA Wenyin, Liu, China
Schwarm, Stephen, USA Swearingen, Sandra, USA Werner, Linda, USA
Schweppe, Edmund, USA Szymkowiak , Paul, Canada Wheeler, David, USA
Sebern, Mark, USA Tamai, Tetsuo, Japan White, Nathan, USA
Seffah, Ahmed, Canada Tasker, Dan, New Zealand White, Stephanie, USA
Selby, Nancy, USA Taylor, Stanford, USA Whitmire, Scott, USA
Selph, William, USA Terekhov, Andrey A., Russian Wijbrans, Klaas, The
Sen, Dhruba, USA Federation, Netherlands
Senechal, Raymond, USA Terski, Matt, USA Wijbrans-Roodbergen, Margot,
Sepulveda, Christian, USA Thayer, Richard, USA The Netherlands
Setlur, Atul, USA Thomas, Michael, USA Wilkie, Frederick, UK
Sharp, David, USA Thompson, A. Allan, Australia Wille, Cornelius, Germany
Shepard, Terry, Canada Thompson, John Barrie, UK Wilson, Charles, USA
Shepherd, Alan, Germany Titus, Jason, USA Wilson, Leon, USA
Shillato, Rrobert W, USA Tockey, Steve, USA Wilson, Russell, USA
Shintani, Katsutoshi, Japan Tovar, Edmundo, Spain Woechan, Kenneth, USA
Silva, Andres, Spain Towhidnejad, Massood, USA Woit , Denise, Canada
Silva, Andres, Spain Trellue, Patricia, USA Yadin, Aharon, Israel
Singer, Carl, USA Trèves, Nicolas, France Yih, Swu, Taiwan
Sinnett, Paul, UK Troy, Elliot, USA Young, Michal, USA
Sintzoff, André, France Tsui, Frank, USA Yrivarren, Jorge, Peru
Sitte, Renate, Australia Tsuneo, Furuyama, Japan Znotka, Juergen, Germany
Sky, Richard, USA Tuohy, Kenney, USA Zuser, Wolfgang, Austria
Smilie, Kevin, USA Tuohy, Marsha P., USA Zvegintzov, Nicholas, USA
Smith, David, USA Turczyn, Stephen, USA Zweben, Stu, USA
Sophatsathit, Peraphon, Thailand Upchurch, Richard, USA
xvi © IEEE – 2004 Version

17. The following motion was unanimously adopted by the Industrial Advisory Board
on February 6, 2004.
The Industrial Advisory Board finds that the Software Engineering Body of Knowledge project initiated
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 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 Professional
Practices Committee to proceed with printing.
© IEEE – 2004 Version xvii

18. xviii © IEEE – 2004 Version

19. PREFACE
Software engineering is an emerging discipline and has long offered a certification for computing
there are unmistakable trends indicating an increasing professionals.
level of maturity: All of these efforts are based upon the presumption
Several universities throughout the world offer that there is a Body of Knowledge that should be
undergraduate degrees in software engineering. mastered by practicing software engineers. The Body
For example, such degrees are offered at the of Knowledge exists in the literature that has
University of New South Wales (Australia), accumulated over the past thirty years. This book
McMaster University (Canada), the Rochester provides a Guide to that Body of Knowledge.
Institute of Technology (US), the University of
PURPOSE
Sheffield (UK) and other universities.
In the US, the Engineering Accreditation The purpose of the Guide to the Software Engineering
Commission of the Accreditation Board for Body of Knowledge is to provide a consensually-
Engineering and Technology (ABET) is validated characterization of the bounds of the
responsible for the accreditation of undergraduate software engineering discipline and to provide a
software engineering programs. topical access to the Body of Knowledge supporting
that discipline. The Body of Knowledge is subdivided
The Canadian Information Processing Society has
into ten software engineering Knowledge Areas (KA)
published criteria to accredit software engineering
plus an additional chapter providing an overview of the
undergraduate university programs.
Knowledge Areas of strongly related disciplines. The
The Software Engineering Institute’s Capability descriptions of the KAs are designed to discriminate
Maturity Model for Software (SW CMM) and the among the various important concepts, permitting
new Capability Maturity Model Integration readers to find their way quickly to subjects of interest.
(CMMI) are used to assess organizational Upon finding a subject, readers are referred to key
capability for software engineering. The famous papers or book chapters selected because they
ISO 9000 quality management standards have succinctly present the knowledge.
been applied to software engineering by the new
In browsing the Guide, readers will note that the
ISO/IEC 90003.
content is markedly different from Computer Science.
The Texas Board of Professional Engineers has Just as electrical engineering is based upon the science
begun to license professional software engineers. of physics, software engineering should be based,
The Association of Professional Engineers and among others, upon computer science. In both cases,
Geoscientists of British Columbia (APEGBC) has though, the emphasis is necessarily different. Scientists
begun registering software professional engineers extend our knowledge of the laws of nature while
and the Professional Engineers of Ontario (PEO) engineers apply those laws of nature to build useful
has also announced requirements for licensing. artifacts, under a number of constraints. Therefore, the
emphasis of the Guide is placed upon the construction
The Association for Computing Machinery
of useful software artifacts.
(ACM) and the Computer Society of the Institute
of Electrical and Electronics Engineers (IEEE) Readers will also notice that many important aspects of
have jointly developed and adopted a Code of information technology, that may constitute important
Ethics and Professional Practice for software software engineering knowledge, are not covered in
engineering professionals1. the Guide; they include: specific programming
languages, relational databases and networks. This is a
The IEEE Computer Society offers the Certified
consequence of an engineering-based approach. In all
Software Development Professional certification
fields—not only computing—the designers of
for software engineering. The Institute for
engineering curricula have realized that specific
Certification of Computing Professionals (ICCP)
technologies are replaced much more rapidly than the
engineering work force. An engineer must be equipped
with the essential knowledge that supports the
1
The ACM/CS Software Engineering Code of Ethics and selection of the appropriate technology at the
Professional Practice can be found at: appropriate time in the appropriate circumstance. For
http://www.computer.org/certification/ethics.htm
© IEEE – 2004 Version xix

20. example, software might be built in Fortran using engineering for defining education and training
functional decomposition or in C++ using object- requirements, classifying jobs, developing
oriented techniques. The techniques for software performance evaluation policies or specifying software
configuring instances of those systems would be quite development tasks. It also addresses practicing, or
different. But, the principles and objectives of managing, software engineers and the officials
configuration management remain the same. The responsible for making public policy regarding
Guide therefore does not focus on the rapidly changing licensing and professional guidelines. In addition,
technologies, although their general principles are professional societies and educators defining the
described in relevant Knowledge Areas. certification rules, accreditation policies for university
These exclusions demonstrate that this Guide is curricula, and guidelines for professional practice will
necessarily incomplete. The Guide covers software benefit from SWEBOK, as well as the students
engineering knowledge that is necessary, but not learning the software engineering profession and
sufficient for a software engineer. Practicing software educators and trainers engaged in defining curricula
engineers will need to know many things about and course content.
computer science, project management and systems EVOLUTION OF THE GUIDE
engineering—to name a few—that fall outside the
Body of Knowledge characterized by this Guide. From 1993 to 2000, the IEEE Computer Society and
However, stating that this information should be the Association for Computing Machinery (ACM)
known by software engineers is not the same as stating cooperated in promoting the professionalization of
that this knowledge falls within the bounds of the software engineering through their joint Software
software engineering discipline. Instead, it should be Engineering Coordinating Committee (SWECC). The
stated that software engineers need to know some Code of Ethics was completed under stewardship of
things taken from other disciplines—and that is the the SWECC primarily through volunteer efforts. The
approach adopted by this Guide. So, this Guide SWEBOK project was initiated by the SWECC in
characterizes the Body of Knowledge falling within the 1998.
scope of software engineering and provides references The SWEBOK project’s scope, the variety of
to relevant information from other disciplines. A communities involved, and the need for broad
chapter of the Guide provides a taxonomical overview participation suggested a need for full-time rather than
of the related disciplines derived from authoritative volunteer management. For this purpose, the IEEE-
sources. Computer Society contracted the Software Engineering
The emphasis on engineering practice leads the Guide Management Research Laboratory at the Université du
toward a strong relationship with the normative Québec à Montréal (UQAM) to manage the effort. In
literature. Most of the computer science, information recent years, UQAM has been joined by the École de
technology and software engineering literature technologie supérieure, Montréal, Québec.
provides information useful to software engineers, but The project plan comprised three successive phases:
a relatively small portion is normative. A normative Strawman, Stoneman and Ironman. An early prototype,
document prescribes what an engineer should do in a Strawman, demonstrated how the project might be
specified situation rather than providing information organized. The publication of the widely circulated
that might be helpful. The normative literature is Trial Version of the Guide in 2001 marked the end of
validated by consensus formed among practitioners the Stoneman phase of the project and initiated a
and is concentrated in standards and related period of trial usage. The current Guide marks the end
documents. From the beginning, the SWEBOK project of the Ironman period by providing a Guide that has
was conceived as having a strong relationship to the achieved consensus through broad review and trial
normative literature of software engineering. The two application.
major standards bodies for software engineering (IEEE
Computer Society Software Engineering Standards The project team developed two important principles
Committee and ISO/IEC JTC1/SC7) are represented in for guiding the project: transparency and consensus.
the project. Ultimately, we hope that software By transparency, we mean that the development
engineering practice standards will contain principles process is itself documented, published, and publicized
directly traceable to the Guide. so that important decisions and status are visible to all
concerned parties. By consensus, we mean that the
INTENDED AUDIENCE only practical method for legitimizing a statement of
this kind is through broad participation and agreement
The Guide is oriented toward a variety of audiences, by all significant sectors of the relevant community.
all over the world. It aims to serve public and private Literally hundreds of contributors, reviewers, and trial
organizations in need of a consistent view of software
xx © IEEE – 2004 Version

21. users have played a part in producing the current the earlier consensus process. We updated the
document. reference list so that it would be easier to obtain the
Like any software project, the SWEBOK project has references.
many stakeholders—some of which are formally Trial usage resulted in the recommendation that three
represented. An Industrial Advisory Board, composed Knowledge Areas should be rewritten. Practitioners
of representatives from industry (Boeing, Construx remarked that the Construction KA was difficult to
Software, the MITRE Corporation, Rational Software, apply in a practical context. The Management KA was
Raytheon Systems, and SAP Labs-Canada), research perceived as being too close to general management
agencies (National Institute of Standards and and not sufficiently specific to software engineering
Technology, National Research Council of Canada), concerns. The Quality KA was viewed as an
the Canadian Council of Professional Engineers, and uncomfortable mix of process quality and product
the IEEE Computer Society, have provided financial quality; it was revised to emphasize the latter.
support for the project. The IAB’s generous support Finally, some KAs were revised to remove material
permits us to make the products of the SWEBOK duplicating that of other KAs.
project publicly available without any charge (visit
http://www.swebok.org). IAB membership is LIMITATIONS
supplemented with the chairs of ISO/IEC JTC1/SC7
and the related Computing Curricula 2001 initiative. Even though the Guide has gone through an elaborate
The IAB reviews and approves the project plans, development and review process, the following
oversees consensus building and review processes, limitations of this process must be recognized and
promotes the project, and lends credibility to the effort. stated:
In general, it ensures the relevance of the effort to real- Software engineering continues to be infused
world needs. with new technology and new practices.
The Trial Version of the Guide was the product of Acceptance of new techniques grows and older
extensive review and comment. In three public review techniques are discarded. The topics listed as
cycles, a total of roughly 500 reviewers from 42 “generally accepted” in this Guide are carefully
countries provided roughly 9,000 comments, all of selected at this time. Inevitably, though, the
which are available at www.swebok.org. To produce selection will need to evolve.
the current version, we released the Trial Version for The amount of literature that has been published
extensive trial usage. Trial application in specialized on software engineering is considerable and the
studies resulted in 17 papers describing good aspects reference material included in this Guide should
of the Guide, as well as aspects needing improvement. not be seen as a definitive selection but rather as a
A web-based survey captured additional experience: reasonable selection. Obviously, there are other
573 individuals from 55 countries registered for the excellent authors and excellent references than
survey; 124 reviewers from 21 countries actually those included in the Guide. In the case of the
provided comments—1020 of them. Additional Guide, references were selected because they are
suggestions for improvement resulted from liaison written in English, readily available, recent, easily
with related organizations and efforts: IEEE-CS/ACM readable, and—taken as a group—provide
Computing Curricula Software Engineering; the IEEE- coverage of the topics within the KA
CS Certified Software Development Professional Important and highly relevant reference material
project; ISO/IEC JTC1/SC7 (software and systems
written in other languages than English have been
engineering standards), the IEEE Software omitted from the selected reference material.
Engineering Standards Committee; the American
Society for Quality, Software Division; and an Additionally, one must consider that
engineering professional society, the Canadian Council Software engineering is an emerging discipline.
of Professional Engineers. This is especially true if you compare it to certain
more established engineering disciplines. This
CHANGES SINCE THE TRIAL VERSION means notably that the boundaries between the
The overall goal of the current revision was to improve Knowledge Areas of software engineering and
the readability, consistency, and usability of the Guide. between software engineering and its Related
This implied a general rewrite of the entire text to Disciplines remain a matter for continued
make the style consistent throughout the document. In evolution.
several cases, the topical breakdown of the KA was The contents of this Guide must therefore be viewed as
rearranged to make it more usable, but we were careful an “informed and reasonable” characterization of the
to include the same information that was approved by software engineering Body of Knowledge and as
© IEEE – 2004 Version xxi

22. baseline for future evolution. Additionally, please note policy makers around the world regarding the practice
that the Guide is not attempting nor does it claim to and definition of engineering and software engineering
replace or amend in any way laws, rules and in particular.
procedures that have been defined by official public
xxii © IEEE – 2004 Version

23. Alain Abran Executive Editors of the James W. Moore
École de technologie supérieure Guide to the Software The MITRE Corporation
Engineering Body of
Knowledge
Pierre Bourque Editors of the Guide to Robert Dupuis
École de Technologie Supérieure the Software Engineering Université du Québec à Montréal
Body of Knowledge
Leonard Tripp Chair of the Professional
1999 President Practices Committee,
IEEE Computer Society IEEE Computer Society
(2001-2003)
2004
The SWEBOK project web site is http://www.swebok.org/
acknowledge the indispensable contribution of
ACKNOWLEDGMENTS
the hundreds of reviewers.
The SWEBOK editorial team gratefully The editorial team also wishes to thank the
acknowledges the support provided by the following people who contributed to the project
members of the Industrial Advisory Board. in various manners: Mark Ardis, Yussef
Funding for this project has been provided by the Belkebir, Michel Boivin, Julie Bonneau, Simon
ACM, Boeing, the Canadian Council of Bouchard, François Cossette, Vinh Duong, Gilles
Professional Engineers, Construx Software, the Gauthier, Michèle Hébert, Paula Hawthorn,
IEEE Computer Society, the MITRE Richard W. Heiman, Julie Hudon, Idrissa
corporation, the National Institute of Standards Konkobo, Rene Köppel, Lucette Lapointe,
and Technology, the National Research Council Claude Laporte, Luis Molinié, Hamdan Msheik,
of Canada, Rational Software, Raytheon Iphigénie N’Diyae, Serge Oligny, Suzanne
Company, and SAP Labs (Canada). The team is Paquette, Keith Paton, Dave Rayford, Normand
thankful for the counsel provided by the Panel of Séguin, Paul Sinnett, Denis St-Pierre, Dale Strok,
Experts. The team also appreciates the important Pascale Tardif, Louise Thibaudeau, Dolores
work performed by the Associate Editors. We Wallace, Évariste Valery Bevo Wandji, and
would also like to express our gratitude for initial Michal Young.
work on the Knowledge Area Descriptions
Finally, there are surely other people who have
completed by Imants Freibergs, Stephen Frezza,
contributed to this Guide, either directly or
Andrew Gray, Vinh T. Ho, Michael Lutz, Larry
indirectly, whose names we have inadvertently
Reeker, Guy Tremblay, Chris Verhoef, and
omitted. To those people, we offer our tacit
Sybille Wolff. The editorial team must also
appreciation and apologize for having omitted
explicit recognition here.
© IEEE – 2004 Version xxiii

24. xxiv © IEEE – 2004 Version

25. CHAPTER 1
INTRODUCTION TO THE GUIDE
In spite of the millions of software professionals
worldwide and the ubiquitous presence of software in our WHAT ARE THE CHARACTERISTICS OF A PROFESSION ?
society, software engineering has only recently reached
Gary Ford and Norman Gibbs studied several recognized
the status of a legitimate engineering discipline and a
recognized profession. professions, including medicine, law, engineering, and
accounting.3 They concluded that an engineering
Achieving consensus by the profession on a core body of profession is characterized by several components:
knowledge is a key milestone in all disciplines and had
An initial professional education in a curriculum
been identified by the IEEE Computer Society as crucial
for the evolution of software engineering towards validated by society through accreditation
professional status. This Guide, written under the auspices Registration of fitness to practice via voluntary
of the Professional Practices Committee, is part of a certification or mandatory licensing
multi-year project designed to reach such a consensus. Specialized skill development and continuing
professional education
WHAT IS SOFTWARE ENGINEERING? Communal support via a professional society
The IEEE Computer Society defines software engineering A commitment to norms of conduct often prescribed
as: in a code of ethics
“(1) The application of a systematic, disciplined, This Guide contributes to the first three of these
quantifiable approach to the development, operation, and components. Articulating a Body of Knowledge is an
maintenance of software; that is, the application of essential step toward developing a profession because it
engineering to software. represents a broad consensus regarding what a software
(2) The study of approaches as in (1).”1 engineering professional should know. Without such a
consensus, no licensing examination can be validated, no
curriculum can prepare an individual for an examination,
WHAT IS A RECOGNIZED PROFESSION?
and no criteria can be formulated for accrediting a
For software engineering to be fully known as a curriculum. The development of consensus is also a
legitimate engineering discipline and a recognized prerequisite to the adoption of coherent skills
profession, consensus on a core body of knowledge is development and continuing professional education
imperative. This fact is well illustrated by Starr when he programs in organizations.
defines what can be considered a legitimate discipline and
a recognized profession. In his Pulitzer Prize-winning WHAT ARE THE OBJECTIVES OF THE SWEBOK
book on the history of the medical profession in the USA, PROJECT?
he states that:
The Guide should not be confused with the Body of
“The legitimization of professional authority involves Knowledge itself, which already exists in the published
three distinctive claims: first, that the knowledge and literature. The purpose of the Guide is to describe what
competence of the professional have been validated by a portion of the Body of Knowledge is generally accepted,
community of his or her peers; second, that this to organize that portion, and to provide a topical access to
consensually validated knowledge rests on rational, it. Additional information on the meaning given to
scientific grounds; and third, that the professional’s “generally accepted” can be found below and in Appendix
judgment and advice are oriented toward a set of A.
substantive values, such as health. These aspects of
legitimacy correspond to the kinds of attributes–collegial, The Guide to the Software Engineering Body of
cognitive, and moral–usually embodied in the term
“profession.”2
Books, 1982. p. 15.
3
1
G. Ford and N. E. Gibbs, “A Mature Profession of Software
“IEEE Standard Glossary of Software Engineering Terminology,” Engineering,” Software Engineering Institute, Carnegie Mellon
IEEE, Piscataway, NJ std 610.12-1990, 1990. University, Pittsburgh, Pennsylvania, Technical CMU/SEI-96-TR-
2
P. Starr, The Social Transformation of American Medicine: Basic 004, January 1996.
© IEEE – 2004 Version 1-1

26. Knowledge (SWEBOK) was established with the In establishing a boundary, it is also important to identify
following five objectives: what disciplines share that boundary, and often a common
1. To promote a consistent view of software intersection, with software engineering. To this end, the
engineering worldwide Guide also recognizes eight related disciplines, listed in
Table 2 (see chapter 12, Related Disciplines of Software
2. To clarify the place–and set the boundary–of Engineering). Software engineers should, of course, have
software engineering with respect to other knowledge of material from these fields (and the KA
disciplines such as computer science, project descriptions may make reference to them). It is not,
management, computer engineering, and however, an objective of the SWEBOK Guide to
mathematics characterize the knowledge of the related disciplines, but
3. To characterize the contents of the software rather what knowledge is viewed as specific to software
engineering discipline engineering.
4. To provide a topical access to the Software Table 2 Related disciplines.
Engineering Body of Knowledge
Computer engineering Project management
5. To provide a foundation for curriculum development
Computer science Quality management
and for individual certification and licensing
material Management Software ergonomics
The first of these objectives, a consistent worldwide view Mathematics Systems engineering
of software engineering, was supported by a development
process which engaged approximately 500 reviewers from HIERARCHICAL ORGANIZATION
42 countries in the Stoneman phase (1998-2001) leading
to the Trial version, and over 120 reviewers from 21 The organization of the KA descriptions or chapters
countries in the Ironman phase (2003) leading to the 2004 supports the third of the project’s objectives–a
version. More information regarding the development characterization of the contents of software engineering.
process can be found in the Preface and on the Web site The detailed specifications provided by the project’s
(www.swebok.org). Professional and learned societies editorial team to the associate editors regarding the
and public agencies involved in software engineering contents of the KA descriptions can be found in Appendix
were officially contacted, made aware of this project, and A.
invited to participate in the review process. Associate The Guide uses a hierarchical organization to decompose
editors were recruited from North America, the Pacific each KA into a set of topics with recognizable labels. A
Rim, and Europe. Presentations on the project were made two- or three-level breakdown provides a reasonable way
at various international venues and more are scheduled for to find topics of interest. The Guide treats the selected
the upcoming year. topics in a manner compatible with major schools of
The second of the objectives, the desire to set a boundary thought and with breakdowns generally found in industry
for software engineering, motivates the fundamental and in software engineering literature and standards. The
organization of the Guide. The material that is recognized breakdowns of topics do not presume particular
as being within this discipline is organized into the first application domains, business uses, management
ten Knowledge Areas (KAs) listed in Table 1. Each of philosophies, development methods, and so forth. The
these KAs is treated as a chapter in this Guide. extent of each topic’s description is only that needed to
understand the generally accepted nature of the topics and
Table 1 The SWEBOK Knowledge Areas (KAs). for the reader to successfully find reference material.
Software requirements After all, the Body of Knowledge is found in the
Software design reference material themselves, and not in the Guide.
Software construction
REFERENCE MATERIAL AND MATRIX
Software testing
Software maintenance To provide a topical access to the knowledge–the fourth
Software configuration management of the project’s objectives–the Guide identifies reference
material for each KA, including book chapters, refereed
Software engineering management
papers, or other recognized sources of authoritative
Software engineering process information. Each KA description also includes a matrix
Software engineering tools and methods relating the reference material to the listed topics. The
Software quality total volume of cited literature is intended to be suitable
for mastery through the completion of an undergraduate
education plus four years of experience.
In this edition of the Guide, all KAs were allocated
1–2 © IEEE – 2004 Version

27. around 500 pages of reference material, and this was the included in the study material for the software
specification the associate editors were invited to apply. It engineering licensing examination that graduates would
may be argued that some KAs, such as software design take after gaining four years of work experience.
for instance, deserve more pages of reference material Although this criterion is specific to the U.S. style of
than others. Such modulation may be applied in future education and does not necessarily apply to other
editions of the Guide. countries, we deem it useful. However, the two
It should be noted that the Guide does not attempt to be definitions of generally accepted knowledge should be
comprehensive in its citations. Much material that is both seen as complementary.
suitable and excellent is not referenced. Material was
selected in part because–taken as a collection–it provides LIMITATIONS RELATED TO THE BOOK FORMAT
coverage of the topics described.
The book format for which this edition was conceived has
DEPTH OF TREATMENT its limitations. The nature of the contents would be better
served using a hypertext structure, where a topic would be
From the outset, the question arose as to the depth of linked to topics other than the ones immediately
treatment the Guide should provide. The project team preceding and following it in a list.
adopted an approach which supports the fifth of the Some boundaries between KAs, sub-areas, and so on, are
project’s objectives–providing a foundation for also sometimes relatively arbitrary. These boundaries are
curriculum development, certification, and licensing. The not to be given too much importance. As much as
editorial team applied the criterion of generally accepted possible, pointers and links have been given in the text
knowledge, to be distinguished from advanced and where relevant and useful.
research knowledge (on the grounds of maturity) and
from specialized knowledge (on the grounds of generality Links between KAs are not of the input-output type. The
of application). The definition comes from the Project KAs are meant to be views on the knowledge one should
Management Institute: “The generally accepted possess in software engineering with respect to the KA in
knowledge applies to most projects most of the time, and question. The decomposition of the discipline within KAs
widespread consensus validates its value and and the order in which the KAs are presented are not to be
effectiveness”.4 assimilated with any particular method or model. The
methods are described in the appropriate KA in the Guide,
and the Guide itself is not one of them.
Generally Accepted
Practices used only for certain types
Established traditional practices
recommended by many organizations THE KNOWLEDGE AREAS
Figure 1 maps out the eleven chapters and the important
topics incorporated within them. The first five KAs are
Specialized
of software
presented in traditional waterfall life cycle sequence.
However, this does not imply that the Guide adopts or
Advanced and Research encourages the waterfall model, or any other model. The
Innovative practices tested and used subsequent KAs are presented in alphabetical order, and
only by some organizations and those of the related disciplines are presented in the last
concepts still being developed and chapter. This is identical to the sequence in which they
tested in research organizations are presented in this Guide.
STRUCTURE OF THE KA DESCRIPTIONS
Figure 1 Categories of knowledge The KA descriptions are structured as follows.
However, the term “generally accepted” does not imply In the introduction, a brief definition of the KA, and an
that the designated knowledge should be uniformly overview of its scope and of its relationship with other
applied to all software engineering endeavors–each KAs are presented.
project’s needs determine that–but it does imply that The breakdown of topics constitutes the core of each KA
competent, capable software engineers should be description, describing the decomposition of the KA into
equipped with this knowledge for potential application. sub-areas, topics, and sub-topics. For each topic or sub-
More precisely, generally accepted knowledge should be topic, a short description is given, along with one or more
references.
4
The reference material was chosen because it is
A Guide to the Project Management Body of Knowledge, 2000
Edition, Project Management Institute, Newport Square, PA.
considered to constitute the best presentation of the
www.pmi.org. knowledge relative to the topic, taking into account the
© IEEE – 2004 Version 1-3

28. limitations imposed on the choice of references (see involving substantial non-software components, as many
above). A matrix links the topics to the reference material. as three different types of documents are produced:
The last part of the KA description is the list of system definition, system requirements specification, and
recommended references. Appendix A of each KA software requirements specification. The sub-area
includes suggestions for further reading for those users describes all three documents and the underlying
who wish to learn more about the KA topics. Appendix B activities.
presents the list of standards most relevant to the KA. The sixth sub-area is requirements validation, the aim of
Note that citations enclosed in square brackets “[ ]” in the which is to pick up any problems before resources are
text identify recommended references, while those committed to addressing the requirements. Requirements
enclosed in parentheses “( )” identify the usual references validation is concerned with the process of examining the
used to write or justify the text. The former are to be requirements documents to ensure that they are defining
found in the corresponding section of the KA and the the right system (that is, the system that the user expects).
latter in Appendix A of the KA. It is subdivided into descriptions of the conduct of
Brief summaries of the KA descriptions and Appendices requirements reviews, prototyping, and model validation
are given next. and acceptance tests.
The seventh and last sub-area is practical considerations.
Software Requirements KA (see Figure 2, column a) It describes topics which need to be understood in
practice. The first topic is the iterative nature of the
A requirement is defined as a property that must be requirements process. The next three topics are
exhibited in order to solve some real-world problem. fundamentally about change management and the
The first knowledge sub-area is software requirements maintenance of the requirements in a state which
fundamentals. It includes definitions of software accurately mirrors the software to be built, or that has
requirements themselves, but also of the major types of already been built. It includes change management,
requirements: product vs. process, functional vs. non- requirements attributes, and requirements tracing. The
functional, emergent properties. The sub-area also final topic is requirements measurement.
describes the importance of quantifiable requirements and
distinguishes between systems and software requirements. Software Design KA (see Figure 2, column b)
The second knowledge sub-area is the requirements According to the IEEE definition [IEEE610.12-90],
process, which introduces the process itself, orienting the design is both “the process of defining the architecture,
remaining five sub-areas and showing how requirements components, interfaces, and other characteristics of a
engineering dovetails with the other software engineering system or component” and “the result of [that] process.”
processes. It describes process models, process actors, The KA is divided into six sub-areas.
process support and management, and process quality and
improvement. The first sub-area presents the software design
fundamentals, which form an underlying basis to the
The third sub-area is requirements elicitation, which is understanding of the role and scope of software design.
concerned with where software requirements come from These are general software concepts, the context of
and how the software engineer can collect them. It software design, the software design process, and the
includes requirement sources and elicitation techniques. enabling techniques for software design.
The fourth sub-area, requirements analysis, is concerned
The second sub-area groups together the key issues in
with the process of analyzing requirements to:
software design. They include concurrency, control and
detect and resolve conflicts between requirements handling of events, distribution of components, error and
discover the bounds of the software and how it must exception handling and fault tolerance, interaction and
interact with its environment presentation, and data persistence.
elaborate system requirements to software The third sub-area is software structure and architecture,
requirements the topics of which are architectural structures and
Requirements analysis includes requirements viewpoints, architectural styles, design patterns, and,
classification, conceptual modeling, architectural design finally, families of programs and frameworks.
and requirements allocation, and requirements The fourth sub-area describes software design quality
negotiation. analysis and evaluation. While there is a entire KA
The fifth sub-area is requirements specification. devoted to software quality, this sub-area presents the
Requirements specification typically refers to the topics specifically related to software design. These
production of a document, or its electronic equivalent, aspects are quality attributes, quality analysis, and
that can be systematically reviewed, evaluated, and evaluation techniques and measures.
approved. For complex systems, particularly those The fifth sub-area is software design notations, which are
1–4 © IEEE – 2004 Version

29. divided into structural and behavioral descriptions. practical considerations and the test activities.
The last sub-area describes software design strategies and
methods. First, general strategies are described, followed Software Maintenance (see Figure 2, column e)
by function-oriented design methods, object-oriented
design methods, data-structure centered design, Once in operation, anomalies are uncovered, operating
component-based design, and others. environments change, and new user requirements surface.
The maintenance phase of the lifecycle commences upon
delivery but maintenance activities occur much earlier.
Software Construction KA (see Figure 2, column c) The Software Maintenance KA is divided into four sub-
Software construction refers to the detailed creation of areas.
working, meaningful software through a combination of The first one presents software maintenance
coding, verification, unit testing, integration testing, and fundamentals: definitions and terminology, the nature of
debugging. The KA includes three sub-areas. maintenance, the need for maintenance, the majority of
The first sub-area is software construction fundamentals. maintenance costs, the evolution of software, and the
The first three topics are basic principles of construction: categories of maintenance.
minimizing complexity, anticipating change, and The second sub-area groups together the key issues in
constructing for verification. The last topic discusses software maintenance. These are the technical issues, the
standards for construction. management issues, maintenance cost estimation, and
The second sub-area describes managing construction. software maintenance measurement.
The topics are construction models, construction The third sub-area describes the maintenance process.
planning, and construction measurement. The topics here are the maintenance processes and
The third sub-area covers practical considerations. The maintenance activities.
topics are construction design, construction languages, Techniques for maintenance constitute the fourth sub-
coding, construction testing, reuse, construction quality, area. These include program comprehension, re-
and integration. engineering, and reverse engineering.
Software Testing (see Figure 2, column d) Software Configuration Management (see Figure 3,
column f)
Software Testing consists of the dynamic verification of
the behavior of a program on a finite set of test cases, Software Configuration Management (SCM) is the
suitably selected from the usually infinite executions discipline of identifying the configuration of software at
domain, against the expected behavior. It includes five distinct points in time for the purpose of systematically
sub-areas. controlling changes to the configuration and of
It begins with a description of software testing maintaining the integrity and traceability of the
fundamentals. First, the testing-related terminology is configuration throughout the system life cycle. This KA
presented, then key issues of testing are described, and includes six sub-areas.
finally the relationship of testing to other activities is The first sub-area is management of the SCM process. It
covered. covers the topics of the organizational context for SCM,
The second sub-area is test levels. These are divided constraints and guidance for SCM, planning for SCM, the
between the targets of the tests and the objectives of the SCM plan itself, and surveillance of SCM.
tests. The second sub-area is software configuration
The third sub-area is test techniques. The first category identification, which identifies items to be controlled,
includes the tests based on the tester’s intuition and establishes identification schemes for the items and their
experience. A second group comprises specification- versions, and establishes the tools and techniques to be
based techniques, followed by code-based techniques, used in acquiring and managing controlled items. The
fault-based techniques, usage-based techniques, and first topics in this sub-area are identification of the items
techniques relative to the nature of the application. A to be controlled and the software library.
discussion of how to select and combine the appropriate The third sub-area is software configuration control,
techniques is also presented. which is the management of changes during the software
The fourth sub-area covers test related measures. The life cycle. The topics are: first, requesting, evaluating, and
measures are grouped into those related to the evaluation approving software changes; second, implementing
of the program under test and the evaluation of the tests software changes; and third, deviations, and waivers.
performed. The fourth sub-area is software configuration status
The last sub-area describes the test process, and includes accounting. Its topics are software configuration status
information and software configuration status reporting.
© IEEE – 2004 Version 1-5

30. The fifth sub-area is software configuration auditing. It change. The topics here are process infrastructure, the
consists of software functional configuration auditing, software process management cycle, models for process
software physical configuration auditing, and in-process implementation and change, and practical considerations.
audits of a software baseline. The second sub-area deals with process definition. It
The last sub-area is software release management and includes the topics of software life cycle models, software
delivery, covering software building and software release life-cycle processes, notations for process definitions,
management. process adaptation, and automation
The third sub-area is process assessment. The topics here
Software Engineering Management (see Figure 3, include process assessment models and process
column g) assessment methods.
The Software Engineering Management KA addresses the The fourth sub-area describes process and product
management and measurement of software engineering. measurements. The software engineering process covers
While measurement is an important aspect of all KAs, it general product measurement, as well as process
is here that the topic of measurement programs is measurement in general. Measurements specific to KAs
presented. There are six sub-areas for software are described in the relevant KA. The topics are process
engineering management. The first five cover software measurement, software product measurement, quality of
project management and the sixth describes the software measurement results, software information models, and
measurement programs. process measurement techniques.
The first sub-area is initiation and scope definition, which
comprises determination and negotiation of requirements, Software Engineering Tools and Methods (see Figure
feasibility analysis, and process for the review and 3, column i)
revision of requirements. The Software Engineering Tools and Methods KA
The second sub-area is software project planning, and includes both software engineering tools and software
includes process planning, determining deliverables, engineering methods.
effort, schedule and cost estimation, resource allocation, The software engineering tools sub-area uses the same
risk management, quality management, and plan structure as the Guide itself, with one topic for each of the
management. other nine software engineering KAs. An additional topic
The third sub-area is software project enactment. The is provided: miscellaneous tools issues, such as tool
topics here are implementation of plans, supplier contract integration techniques, which are potentially applicable to
management, implementation of measurement process, all classes of tools.
monitor process, control process,? and reporting. The software engineering methods sub-area is divided
The fourth sub-area is review and evaluation, which into four subsections: heuristic methods dealing with
includes the topics of determining satisfaction of informal approaches, formal methods dealing with
requirements and reviewing and evaluating performance. mathematically based approaches, and prototyping
The fifth sub-area describes closure: determining closure methods dealing with software development approaches
and closure activities. based on various forms of prototyping.
Finally, the sixth sub-area describes software engineering
Software Quality (see Figure 3, column j)
measurement, more specifically, measurement programs.
Product and process measures are described in the The Software Quality KA deals with software quality
Software Engineering Process KA. Many of the other considerations which transcend the software life cycle
KAs also describe measures specific to their KA. The processes. Since software quality is a ubiquitous concern
topics of this sub-area are: establish and sustain in software engineering, it is also considered in many of
measurement commitment, plan the measurement the other Kas, and the reader will notice pointers to those
process, perform the measurement process, and evaluate KAs throughout this KA. The description of this KA
measurement. covers three sub-areas.
The first sub-area describes the software quality
Software Engineering Process (see Figure 3, column h) fundamentals such as software engineering culture and
The Software Engineering Process KA is concerned with ethics, the value and costs of quality, models and quality
the definition, implementation, assessment, measurement, characteristics, and quality improvement.
management, change, and improvement of the software The second sub-area covers software quality management
engineering process itself. It is divided into four sub- processes. The topics here are software quality assurance,
areas. verification and validation, and reviews and audits.
The first sub-area presents process implementation and The third and final sub-area describes practical
1–6 © IEEE – 2004 Version