Guide to the Software Engineering Body of Knowledge Version 3.
A Project of the IEEE Computer Society
Guide to the Software Engineering Body of Knowledge
Pierre Bourque, École de technologie supérieure (ÉTS) Richard E. (Dick) Fairley, Software and Systems Engineering Associates (S2EA)
Copyright and Reprint Permissions. Educational or personal use of this material is permitted without fee provided such copies 1) are not made for profit or in lieu of purchasing copies for classes, and that this notice and a full citation to the original work appear on the first page of the copy and 2) do not imply IEEE endorsement of any third-party products or services.
Permission to reprint/republish this material for commercial, advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from IEEE by writing to the IEEE Intellectual Property Rights Office, 445 Hoes Lane, Piscataway, NJ 08854-4141 or firstname.lastname@example.org.
Reference to any specific commercial products, process, or service does not imply endorsement by IEEE. The views and opinions expressed in this work do not necessarily reflect those of IEEE.
IEEE makes this document available on an “as is” basis and makes no warranty, express or implied, as to the accuracy, 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.
Copyright © 2014 IEEE. All rights reserved.
Paperback ISBN-10: 0-7695-5166-
Paperback ISBN-13: 978-0-7695-5166-
Digital copies of SWEBOK Guide V3.0 may be downloaded free of charge for personal and academic use via http://www.swebok.org/.
IEEE Computer Society Staff for This Publication
IEEE Computer Society Products and Services.
The world-renowned IEEE Computer Society publishes, promotes, and distributes a wide variety of authoritative computer science and engineering journals, magazines, conference proceedings, and professional education products. Visit the Computer Society at http://www.computer.org for more information.
Every profession is based on a body of knowledge, although that knowledge is not always defined in a concise manner. In cases where no formality exists, the body of knowledge is “generally recognized” by practitioners and may be codified in a variety of ways for a variety of different uses. But in many cases, a guide to a body of knowledge is formally documented, usually in a form that permits it to be used for such purposes as development and accreditation of academic and training programs, certification of specialists, or professional licensing. Generally, a professional society or similar body maintains stewardship of the formal definition of a body of knowledge.
During the past forty-five years, software engi neering has evolved from a conference catch phrase into an engineering profession, characterized by 1) a professional society, 2) standards that specify generally accepted professional practices, 3) a code of ethics, 4) conference proceedings, 5) textbooks, 6) curriculum guidelines and curricula, 7) accreditation criteria and accredited degree programs, 8) certification and licensing, and 9) this Guide to the Body of Knowledge. In this Guide to the Software Engineering Body of Knowledge, the IEEE Computer Society pres ents a revised and updated version of the body of knowledge formerly documented as SWEBOK 2004; this revised and updated version is denoted SWEBOK V3. This work is in partial fulfillment of the Society’s responsibility to promote the advancement of both theory and practice for the profession of software engineering.
It should be noted that this Guide does not present the entire the body of knowledge for software engineering but rather serves as a guide to the body of knowledge that has been developed over more than four decades. The software engineering body of knowledge is constantly evolving. Nevertheless, this Guide constitutes a valuable characterization of the software engineering profession.
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, and a committee for developing software engineering standards was established within the IEEE Computer Society in 1976.
In 1990, planning was begun for an international standard to provide an overall view of software engineering. The standard was completed in 1995 with designation ISO/IEC 12207 and given the title of Standard for Software Life Cycle Processes. The IEEE version of 12207 was published in 1996 and provided a major foundation for the body of knowledge captured in SWEBOK 2004. The current version of 12207 is designated as ISO/IEC 12207:2008 and IEEE 12207-2008; it provides the basis for this SWEBOK V3.
This Guide to the Software Engineering Body of Knowledge is presented to you, the reader, as a mechanism for acquiring the knowledge you need in your lifelong career development as a software engineering professional.
Dick Fairley, Chair Software and Systems Engineering Committee IEEE Computer Society
Don Shafer, Vice President Professional Activities Board IEEE Computer Society
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 US DoD standard 2167A. The revision was eventually published as DoD Std. 498. The international standard was completed in 1995 with designation, ISO/IEC 12207, 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 cochairs. 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:
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.
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 toward 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)
Pierre Bourque, Department of Software and IT Engineering, École de technologie supérieure (ÉTS), Canada, email@example.com Richard E. (Dick) Fairley, Software and Systems Engineering Associates (S2EA), USA, firstname.lastname@example.org
Alain Abran, Department of Software and IT Engineering, École de technologie supérieure (ÉTS), Canada, email@example.com
Juan Garbajosa, Universidad Politecnica de Madrid (Technical University of Madrid, UPM), Spain, firstname.lastname@example.org
Gargi Keeni, Tata Consultancy Services, India, email@example.com Beijun Shen, School of Software, Shanghai Jiao Tong University, China, firstname.lastname@example.org
The following persons contributed to editing the SWEBOK Guide V3:
The following persons served on the SWEBOK Guide V3 Change Control Board:
Gerald Kotonya, School of Computing and Communications, Lancaster University, UK, email@example.com
Peter Sawyer, School of Computing and Communications, Lancaster University, UK, firstname.lastname@example.org
Yanchun Sun, School of Electronics Engineering and Computer Science, Peking University, China, email@example.com
Xin Peng, Software School, Fudan University, China, firstname.lastname@example.org
Antonia Bertolino, ISTI-CNR, Italy, email@example.com Eda Marchetti, ISTI-CNR, Italy, firstname.lastname@example.org
Alain April, École de technologie supérieure (ÉTS), Canada, email@example.com
Mira Kajko-Mattsson, School of Information and Communication Technology, KTH Royal Institute of Technology, firstname.lastname@example.org
Software Configuration Management
Roger Champagne, École de technologie supérieure (ÉTS), Canada, email@example.com
Alain April, École de technologie supérieure (ÉTS), Canada, firstname.lastname@example.org
Software Engineering Management
James McDonald, Department of Computer Science and Software Engineering, Monmouth University, USA, email@example.com
Software Engineering Process
Annette Reilly, Lockheed Martin Information Systems & Global Solutions, USA, firstname.lastname@example.org
Richard E. Fairley, Software and Systems Engineering Associates (S2EA), USA, email@example.com
Software Engineering Models and Methods
Michael F. Siok, Lockheed Martin Aeronautics Company, USA, firstname.lastname@example.org
J. David Blaine, USA, email@example.com Durba Biswas, Tata Consultancy Services, India, firstname.lastname@example.org
Software Engineering Professional Practice
Aura Sheffield, USA, email@example.com Hengming Zou, Shanghai Jiao Tong University, China, firstname.lastname@example.org
Software Engineering Economics
Christof Ebert, Vector Consulting Services, Germany, email@example.com
Hengming Zou, Shanghai Jiao Tong University, China, firstname.lastname@example.org
Nabendu Chaki, University of Calcutta, India, email@example.com
Amitava Bandyopadhayay, Indian Statistical Institute, India, firstname.lastname@example.org
Mary Jane Willshire, Software and Systems Engineering Associates (S2EA), USA, email@example.com
Appendix B: IEEE and ISO/IEC Standards Supporting SWEBOK
James W. Moore, USA, James.W.Moore@ieee.org
The following persons served as Associate Editors for either the Trial version published in 2001 or for the 2004 version.
Peter Sawyer, Computing Department, Lancaster University, UK Gerald Kotonya, Computing Department, Lancaster University, UK
Guy Tremblay, Département d’informatique, UQAM, Canada
Steve McConnell, Construx Software, USA Terry Bollinger, the MITRE Corporation, USA Philippe Gabrini, Département d’informatique, UQAM, Canada Louis Martin, Département d’informatique, UQAM, Canada
Antonia Bertolino, ISTI-CNR, Italy Eda Marchetti, ISTI-CNR, Italy
Thomas M. Pigoski, Techsoft Inc., USA Alain April, École de technologie supérieure, Canada
Software Configuration Management
John A. Scott, Lawrence Livermore National Laboratory, USA David Nisse, USA
Software Engineering Management
Dennis Frailey, Raytheon Company, USA Stephen G. MacDonell, Auckland University of Technology, New Zealand Andrew R. Gray, University of Otago, New Zealand
Software Engineering Process
Khaled El Emam, served while at the Canadian National Research Council, Canada
Software Engineering Tools and Methods
David Carrington, School of Information Technology and Electrical Engineering, The University of Queensland, Australia
Alain April, École de technologie supérieure, Canada Dolores Wallace, retired from the National Institute of Standards and Technology, USA Larry Reeker, NIST, USA
Marc Bouisset, Département d’informatique, UQAM
The people listed below participated in the public review process of SWEBOK Guide V3. Membership of the IEEE Computer Society was not a requirement to participate in this review process, and membership information was not requested from reviewers. Over 1500 individual comments were collected and duly adjudicated.
Carlos C. Amaro, USA Mark Ardis, USA Mora-Soto Arturo, Spain Ohad Barzilay, Israel Gianni Basaglia, Italy Denis J. Bergquist, USA Alexander Bogush, UK Christopher Bohn, USA Steve Bollweg, USA Reto Bonderer, Switzerland Alexei Botchkarev, Canada Pieter Botman, Canada Robert Bragner, USA Kevin Brune, USA Ogihara Bryan, USA Luigi Buglione, Italy Rick Cagle, USA Barbara Canody, USA Rogerio A. Carvalho, Brazil Daniel Cerys, USA Philippe Cohard, France Ricardo Colomo-Palacios, Spain Mauricio Coria, Argentina Marek Cruz, UK Stephen Danckert, USA Bipul K. Das, Canada James D. Davidson, USA Jon Dehn, USA Lincoln P. Djang, USA Andreas Doblander, Austria Yi-Ben Doo, USA Scott J. Dougherty, UK Regina DuBord, USA Fedor Dzerzhinskiy, Russia Ann M. Eblen, Australia David M. Endres, USA Marilyn Escue, USA Varuna Eswer, India Istvan Fay, Hungary Jose L. Fernandez-Sanchez, Spain Dennis J. Frailey, USA Tihana Galinac Grbac, Croatia Colin Garlick, New Zealand Garth J.G. Glynn, UK Jill Gostin, USA Christiane Gresse von Wangenheim, Brazil Thomas Gust, USA H.N. Mok, Singapore Jon D. Hagar, USA Anees Ahmed Haidary, India Duncan Hall, New Zealand James Hart, USA Jens H.J. Heidrich, Germany Rich Hilliard, USA Bob Hillier, Canada Norman M. Hines, USA Dave Hirst, USA Theresa L. Hunt, USA Kenneth Ingham, USA Masahiko Ishikawa, Japan Michael A. Jablonski, USA G. Jagadeesh, India Sebastian Justicia, Spain Umut Kahramankaptan, Belgium Pankaj Kamthan, Canada Perry Kapadia, USA Tarig A. Khalid, Sudan Michael K.A. Klaes, Germany Maged Koshty, Egypt Claude C. Laporte, Canada Dong Li, China Ben Linders, Netherlands Claire Lohr, USA Vladimir Mandic, Serbia Matt Mansell, New Zealand John Marien, USA Stephen P. Masticola, USA Nancy Mead, USA Fuensanta Medina-Dominguez, Spain Silvia Judith Meles, Argentina Oscar A. Mondragon, Mexico David W. Mutschler, USA Maria Nelson, Brazil John Noblin, USA Bryan G. Ogihara, USA Takehisa Okazaki, Japan Hanna Oktaba, Mexico Chin Hwee Ong, Hong Kong Venkateswar Oruganti, India Birgit Penzenstadler, Germany Larry Peters, USA S.K. Pillai, India Vaclav Rajlich, USA Kiron Rao, India Luis Reyes, USA Hassan Reza, USA Steve Roach, USA Teresa L. Roberts, USA Dennis Robi, USA Warren E. Robinson, USA Jorge L. Rodriguez, USA Alberto C. Sampaio, Portugal Ed Samuels, USA Maria-Isabel Sanchez-Segura, Spain Vineet Sawant, USA R. Schaaf, USA James C. Schatzman, USA Oscar A. Schivo, Argentina Florian Schneider, Germany Thom Schoeffling, USA Reinhard Schrage, Germany Neetu Sethia, India Cindy C. Shelton, USA Alan Shepherd, Germany Katsutoshi Shintani, Japan Erik Shreve, USA Jaguaraci Silva, Brazil M. Somasundaram, India Peraphon Sophatsathit, Thailand John Standen, UK Joyce Statz, USA Perdita P. Stevens, UK David Struble, USA Ohno Susumu, Japan Urcun Tanik, USA Talin Tasciyan, USA J. Barrie Thompson, UK Steve Tockey, USA Miguel Eduardo Torres Moreno, Colombia Dawid Trawczynski, USA Adam Trendowicz, Germany Norio Ueno, Japan Cenk Uyan, Turkey Chandra Sekar Veerappan, Singapore Oruganti Venkateswar, India Jochen Vogt, Germany Hironori Washizaki, Japan Ulf Westermann, Germany Don Wilson, USA Aharon Yadin, Israel Hong Zhou, UK
Funding for the development of SWEBOK Guide V3 has been provided by the IEEE Computer Society. The editors and coeditors appreciate the important work performed by the KA editors and the contributing editors as well as by the the members of the Change Control Board. The editorial team must also acknowledge the indispensable contribution of reviewers.
The editorial team also wishes to thank the following people who contributed to the project in various ways: Pieter Botman, Evan Butterfield, Carine Chauny, Pierce Gibbs, Diane Girard, John Keppler, Dorian McClenahan, Kenza Meridji, Samuel Redwine, Annette Reilly, and Pam Thompson. Finally, there are surely other people who have contributed to this Guide , either directly or indirectly, whose names we have inadvertently omitted. To those people, we offer our tacit appreciation and apologize for having omitted explicit recognition.
Dejan Milojicic, 2014 President David Alan Grier, 2013 President Thomas Conte, 2015 President
Donald F. Shafer, Chair Pieter Botman, CSDP Pierre Bourque Richard Fairley, CSDP Dennis Frailey S. Michael Gayle Phillip Laplante, CSDP Jim Moore, CSDP Linda Shafer, CSDP Steve Tockey, CSDP Charlene “Chuck” Walrad
The SWEBOK Guide V3.0 was submitted to ballot by verified IEEE Computer Society members in November 2013 with the following question: “Do you approve this manuscript of the SWEBOK Guide V3.0 to move forward to formatting and publication?”
The results of this ballot were 259 Yes votes and 5 No votes.
The following motion was unanimously adopted by the Professional Activities Board of the IEEE Computer Society in December 2013:
The Professional Activities Board of the IEEE Computer Society finds that the Guide to the Software Engineering Body of Knowledge Version 3.0 has been successfully completed; and endorses the Guide to the Software Engineering Body of Knowledge Version 3.0 and commends it to the IEEE Computer Society Board of Governors for their approval.
The following motion was adopted by the IEEE Computer Society Board of Governors in December 2013:
MOVED, that the Board of Governors of the IEEE Computer Society approves Version 3.0 of the Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Professional Activities Board to proceed with printing.
The following motion was unanimously adopted by the Industrial Advisory Board of the SWEBOK Guide project in February 2004:
The Industrial Advisory Board finds that the Software Engineering Body of Knowledge project 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 was adopted by the IEEE Computer Society Board of Governors in February 2004:
MOVED, that the Board of Governors of the IEEE Computer Society approves the 2004 Edition of the Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Professional Practices Committee to proceed with printing.
Please also note that the 2004 edition of the Guide to the Software Engineering Body of Knowledge was submitted by the IEEE Computer Society to ISO/IEC without any change and was recognized as Technical Report ISO/IEC TR 19759:2005.
Publication of the 2004 version of this Guide to the Software Engineering Body of Knowledge (SWEBOK 2004) was a major milestone in establishing software engineering as a recognized engineering discipline. The goal in developing this update to SWEBOK is to improve the currency, readability, consistency, and usability of the Guide.
All knowledge areas (KAs) have been updated to reflect changes in software engineering since publication of SWEBOK 2004. Four new foundation KAs and a Software Engineering Profes sional Practices KA have been added. The Software Engineering Tools and Methods KA has been revised as Software Engineering Models and Methods. Software engineering tools is now a topic in each of the KAs. Three appendices provide the specifications for the KA description, an annotated set of relevant standards for each KA, and a listing of the references cited in the Guide.
This Guide, written under the auspices of the Professional Activities Board of the IEEE Computer Society, represents a next step in the evolution of the software engineering profession.
What Is Software Engineering?
ISO/IEC/IEEE Systems and Software Engineering Vocabulary (SEVOCAB) defines software engineering as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software).”^1
What Are The Objectives Of The SWEBOK Guide?
The Guide should not be confused with the Body of Knowledge itself, which exists in the published
1 See http://www.computer.org/sevocab.
literature. The purpose of the Guide is to describe the portion of the Body of Knowledge that is generally accepted, to organize that portion, and to provide topical access to it.
The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) was established with the following five objectives:
The first of these objectives, a consistent worldwide view of software engineering, was supported by a development process which engaged approximately 150 reviewers from 33 countries. More information regarding the development process can be found on the website (www.swebok.org). Professional and learned societies and public agencies involved in software engineering were contacted, made aware of this project to update SWEBOK, and invited to participate in the review process. KA editors were recruited from North America, the Pacific Rim, and Europe. Presentations on the project were made at various international venues. The second of the objectives, the desire to specify the scope of software engineering, motivates the fundamental organization of the Guide. The material that is recognized as being within this discipline is organized into the fifteen KAs listed in Table I.1. Each of these KAs is treated in a chapter in this Guide.
Table I.1. The 15 SWEBOK KAs
Software Requirements Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Models and Methods Software Quality Software Engineering Professional Practice Software Engineering Economics Computing Foundations Mathematical Foundations Engineering Foundations
In specifying scope, it is also important to identify the disciplines that intersect with software engineering. To this end, SWEBOK V3 also recognizes seven related disciplines, listed in Table I.2. Software engineers should, of course, have knowledge of material from these disciplines (and the KA descriptions in this Guide may make reference to them). It is not, however, an objective of the SWEBOK Guide to characterize the knowledge of the related disciplines.
Table I.2. Related Disciplines
Computer Engineering Computer Science General Management Mathematics Project Management Quality Management Systems Engineering
The relevant elements of computer science and mathematics are presented in the Computing Foundations and Mathematical Foundations KAs of the Guide (Chapters 13 and 14).
The organization of the KA chapters supports the third of the project’s objectives - a characterization of the contents of software engineering. The detailed specifications provided by the project’s editorial team to the associate editors regarding the contents of the KA descriptions can be found in Appendix A.
The Guide uses a hierarchical organization to decompose each KA into a set of topics with recognizable labels. A two (sometime three) level breakdown provides a reasonable way to find topics of interest. The Guide treats the selected topics in a manner compatible with major schools of thought and with breakdowns generally found in industry and in software engineering literature and standards. The breakdowns of topics do not presume particular application domains, business uses, management philosophies, development methods, and so forth. The extent of each topic’s description is only that needed to understand the generally accepted nature of the topics and for the reader to successfully find reference material; the Body of Knowledge is found in the reference materials themselves, not in the Guide.
Reference Material And Matrix
To provide topical access to the knowledge-the fourth of the project’s objectives-the Guide identifies authoritative reference material for each KA. Appendix C provides a Consolidated Reference List for the Guide. Each KA includes relevant references from the Consolidated Reference List and also includes a matrix relating the reference material to the included topics. It should be noted that the Guide does not attempt to be comprehensive in its citations. Much material that is both suitable and excellent is not referenced. Material included in the Consolidated Reference List provides coverage of the topics described.
Depth Of Treatment
To achieve the SWEBOK fifth objective-providing a foundation for curriculum development, certification, and licensing, the criterion of generally accepted knowledge has been applied, to be distinguished from advanced and research knowledge (on the grounds of maturity) and from specialized knowledge (on the grounds of generality of application).
The equivalent term generally recognized comes from the Project Management Institute: “Generally recognized means the knowledge and practices described are applicable to most projects most of the time, and there is consensus about their value and usefulness.”^2 However, the terms “generally accepted” or “generally recognized” do not imply that the designated knowledge should be uniformly applied to all software engineering endeavors—each project’s needs determine that—but it does imply that competent, capable software engineers should be equipped with this knowledge for potential application. More precisely, generally accepted knowledge should be included in the study material for the software engineering licensing examination that graduates would take after gaining four years of work experience. Although this criterion is specific to the US style of education and does not necessarily apply to other countries, we deem it useful.
Structure Of The KA Descriptions
The KA descriptions are structured as follows. In the introduction, a brief definition of the KA and an overview of its scope and of its relationship with other KAs are presented.
A Guide to the Project Management Body of Knowledge, 5th ed., Project Management Institute, 2013; http://www.pmi.org/.
The breakdown of topics in each KA constitutes the core the KA description, describing the decomposition of the KA into subareas, topics, and sub-topics. For each topic or subtopic, a short description is given, along with one or more references.
The reference material was chosen because it is considered to constitute the best presentation of the knowledge relative to the topic. A matrix links the topics to the reference material. The last part of each KA description is the list of recommended references and (optionally) further readings. Relevant standards for each KA are presented in Appendix B of the Guide.
APPENDIX A. KA Description Specifications
Appendix A describes the specifications provided by the editorial team to the associate editors for the content, recommended references, format, and style of the KA descriptions.
APPENDIX B. Allocation Of Standards To KAS
Appendix B is an annotated list of the relevant standards, mostly from the IEEE and the ISO, for each of the KAs of the SWEBOK Guide.
APPENDIX C. Consolidated Reference List
Appendix C contains the consolidated list of recommended references cited in the KAs (these references are marked with an asterisk (*) in the text).
The Software Requirements knowledge area (KA) is concerned with the elicitation, analysis, specification, and validation of software requirements as well as the management of requirements during the whole life cycle of the software product. It is widely acknowledged amongst researchers and industry practitioners that software projects are critically vulnerable when the requirements-related activities are poorly performed.
Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.
The term “requirements engineering” is widely used in the field to denote the systematic handling of requirements. For reasons of consistency, the term “engineering” will not be used in this KA other than for software engineering per se.
For the same reason, “requirements engineer,” a term which appears in some of the literature, will not be used either. Instead, the term “software engineer” or, in some specific cases, “requirements specialist” will be used, the latter where the role in question is usually performed by an individual other than a software engineer. This does not imply, however, that a software engineer could not perform the function.
A risk inherent in the proposed breakdown is that a waterfall-like process may be inferred. To guard against this, topic 2, Requirements Process, is designed to provide a high-level overview of the requirements process by setting out the resources and constraints under which the process operates and which act to configure it.
An alternate decomposition could use a product-based structure (system requirements, software requirements, prototypes, use cases, and so on). The process-based breakdown reflects the fact that the requirements process, if it is to be successful, must be considered as a process involving complex, tightly coupled activities (both sequential and concurrent), rather than as a discrete, one-off activity performed at the outset of a software development project.
The Software Requirements KA is related closely to the Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Engineering Models and Methods, and Software Quality KAs.
Breakdown Of Topics For Software Requirements
The breakdown of topics for the Software Requirements KA is shown in Figure 1.1.
At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device to name just a few of the many problems for which software solutions are possible. The ways in which users, business processes, and devices function are typically complex. By extension, therefore, the requirements on particular software are typically a complex combination from various people at different levels of an organization, and who are in one way or another involved or connected with this feature from the environment in which the software will operate.
An essential property of all software requirements is that they be verifiable as an individual feature as a functional requirement or at the system level as a nonfunctional requirement. It may be difficult or costly to verify certain software requirements. For example, verification of the throughput requirement on a call center may necessitate the development of simulation software. Software requirements, software testing, and quality personnel must ensure that the requirements can be verified within available resource constraints.
Requirements have other attributes in addition to behavioral properties. Common examples include a priority rating to enable tradeoffs in the face of finite resources and a status value to enable project progress to be monitored. Typically, software requirements are uniquely identified so that they can be subjected to software configuration management over the entire life cycle of the feature and of the software.
A product requirement is a need or constraint on the software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course”). A process requirement is essentially a constraint on the development of the software (for example, “The software shall be developed using a RUP process”).
Some software requirements generate implicit process requirements. The choice of verification technique is one example. Another might be the use of particularly rigorous analysis techniques (such as formal specification methods) to reduce faults that can lead to inadequate reliability. Process requirements may also be imposed directly by the development organization, their customer, or a third party such as a safety regulator.
Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior.
Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements. They can be further classified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability requirements, security requirements, interoperability requirements or one of many other types of software requirements (see Models and Quality Characteristics in the Software Quality KA).
Some requirements represent emergent properties of software that is, requirements that cannot be addressed by a single component but that depend on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture.
Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague and unverifiable requirements that depend for their interpretation on subjective judgment (“the software shall be reliable”; “the software shall be user-friendly”). This is particularly important for nonfunctional requirements. Two examples of quantified requirements are the following: a call center’s software must increase the center’s throughput by 20%; and a system shall have a probability of generating a fatal error during any hour of operation of less than 1 * 10^-8. The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliability requirement will tightly constrain the system architecture.
In this topic, “system” means
an interacting combination of elements to accomplish a defined objective. These include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements,
as defined by the International Council on Software and Systems Engineering (INCOSE) .
System requirements are the requirements for the system as a whole. In a system containing software components, software requirements are derived from system requirements. This KA defines “user requirements” in a restricted way, as the requirements of the system’s customers or end users. System requirements, by contrast, encompass user requirements, requirements of other stakeholders (such as regulatory authorities), and requirements without an identifiable human source.
This section introduces the software requirements process, orienting the remaining five topics and showing how the requirements process dovetails with the overall software engineering process.
The objective of this topic is to provide an understanding that the requirements process
In particular, the topic is concerned with how the activities of elicitation, analysis, specification, and validation are configured for different types of projects and constraints. The topic also includes activities that provide input into the requirements process, such as marketing and feasibility studies.
This topic introduces the roles of the people who participate in the requirements process. This process is fundamentally interdisciplinary, and the requirements specialist needs to mediate between the domain of the stakeholder and that of software engineering. There are often many people involved besides the requirements specialist, each of whom has a stake in the software. The stakeholders will vary across projects, but will always include users/operators and customers (who need not be the same). Typical examples of software stakeholders include (but are not restricted to) the following:
It will not be possible to perfectly satisfy the requirements of every stakeholder, and it is the software engineer’s job to negotiate tradeoffs that are both acceptable to the principal stakeholders and within budgetary, technical, regulatory, and other constraints. A prerequisite for this is that all the stakeholders be identified, the nature of their “stake” analyzed, and their requirements elicited.
This section introduces the project management resources required and consumed by the requirements process. It establishes the context for the first topic (Initiation and Scope Definition) of the Software Engineering Management KA. Its principal purpose is to make the link between the process activities identified in 2.1 and the issues of cost, human resources, training, and tools.
This topic is concerned with the assessment of the quality and improvement of the requirements process. Its purpose is to emphasize the key role the requirements process plays in terms of the cost and timeliness of a software product and of the customer’s satisfaction with it. It will help to orient the requirements process with quality standards and process improvement models for software and systems. Process quality and improvement is closely related to both the Software Quality KA and Software Engineering Process KA, comprising
Requirements elicitation is concerned with the origins of software requirements and how the software engineer can collect them. It is the first stage in building an understanding of the problem the software is required to solve. It is fundamentally a human activity and is where the stakeholders are identified and relationships established between the development team and the customer. It is variously termed “requirements capture,” “requirements discovery,” and “requirements acquisition.”
One of the fundamental principles of a good requirements elicitation process is that of effective communication between the various stakeholders. This communication continues through the entire Software Development Life Cycle (SDLC) process with different stakeholders at different points in time. Before development begins, requirements specialists may form the conduit for this communication. They must mediate between the domain of the software users (and other stakeholders) and the technical world of the software engineer. A set of internally consistent models at different levels of abstraction facilitate communications between software users/stakeholders and software engineers.
A critical element of requirements elicitation is informing the project scope. This involves providing a description of the software being specified and its purpose and prioritizing the deliverables to ensure the customer’s most important business needs are satisfied first. This minimizes the risk of requirements specialists spending time eliciting requirements that are of low importance, or those that turn out to be no longer relevant when the software is delivered. On the other hand, the description must be scalable and extensible to accept further requirements not expressed in the first formal lists and compatible with the previous ones as contemplated in recursive methods.
Requirements have many sources in typical software, and it is essential that all potential sources be identified and evaluated. This topic is designed to promote awareness of the various sources of software requirements and of the frameworks for managing them. The main points covered are as follows:
Once the requirements sources have been identified, the software engineer can start eliciting requirements information from them. Note that requirements are seldom elicited ready-made. Rather, the software engineer elicits information from which he or she formulates requirements. This topic concentrates on techniques for getting human stakeholders to articulate requirements-relevant information. It is a very difficult task and the software engineer needs to be sensitized to the fact that (for example) users may have difficulty describing their tasks, may leave important information unstated, or may be unwilling or unable to cooperate. It is particularly important to understand that elicitation is not a passive activity and that, even if cooperative and articulate stakeholders are available, the software engineer has to work hard to elicit the right information. Many business or technical requirements are tacit or in feedback that has yet to be obtained from end users. The impor tance of planning, verification, and validation in requirements elicitation cannot be overstated. A number of techniques exist for requirements elicitation; the principal ones are these:
This topic is concerned with the process of analyzing requirements to
The traditional view of requirements analysis has been that it be reduced to conceptual modeling using one of a number of analysis methods, such as the structured analysis method. While conceptual modeling is important, we include the classification of requirements to help inform tradeoffs between requirements (requirements classification) and the process of establishing these tradeoffs (requirements negotiation). Care must be taken to describe requirements precisely enough to enable the requirements to be validated, their implementation to be verified, and their costs to be estimated.
Requirements can be classified on a number of dimensions. Examples include the following:
Other classifications may be appropriate, depending upon the organization’s normal practice and the application itself. There is a strong overlap between requirements classification and requirements attributes (see section 7.3, Requirements Attributes).
The development of models of a real-world problem is key to software requirements analysis. Their purpose is to aid in understanding the situation in which the problem occurs, as well as depicting a solution. Hence, conceptual models comprise models of entities from the problem domain, configured to reflect their real-world relationships and dependencies. This topic is closely related to the Software Engineering Models and Methods KA.
Several kinds of models can be developed. These include use case diagrams, data flow models, state models, goal-based models, user interactions, object models, data models, and many others. Many of these modeling notations are part of the Unified Modeling Language (UML). Use case diagrams, for example, are routinely used to depict scenarios where the boundary separates the actors (users or systems in the external environment) from the internal behavior where each use case depicts a functionality of the system. The factors that influence the choice of modeling notation include these:
Note that, in almost all cases, it is useful to start by building a model of the software context. The software context provides a connection between the intended software and its external environment.
This is crucial to understanding the software’s context in its operational environment and to identifying its interfaces with the environment. This subtopic does not seek to “teach” a particular modeling style or notation but rather provides guidance on the purpose and intent of modeling.
At some point, the solution architecture must be derived. Architectural design is the point at which the requirements process overlaps with software or systems design and illustrates how impossible it is to cleanly decouple the two tasks. This topic is closely related to Software Structure and Architecture in the Software Design KA. In many cases, the software engineer acts as software architect because the process of analyzing and elaborating the requirements demands that the architecture/design components that will be responsible for satisfying the requirements be identified. This is requirements allocation – the assignment to architecture components responsible for satisfying the requirements.
Allocation is important to permit detailed analysis of requirements. Hence, for example, once a set of requirements has been allocated to a component, the individual requirements can be further analyzed to discover further requirements on how the component needs to interact with other components in order to satisfy the allocated requirements. In large projects, allocation stimulates a new round of analysis for each subsystem. As an example, requirements for a particular braking performance for a car (braking distance, safety in poor driving conditions, smoothness of application, pedal pressure required, and so on) may be allocated to the braking hardware (mechanical and hydraulic assemblies) and an antilock braking system (ABS). Only when a requirement for an antilock braking system has been identified, and the requirements allocated to it, can the capabilities of the ABS, the braking hardware, and emergent properties (such as car weight) be used to identify the detailed ABS software requirements.
Architectural design is closely identified with conceptual modeling (see section 4.2, Conceptual Modeling).
Another term commonly used for this subtopic is “conflict resolution.” This concerns resolving problems with requirements where conflicts occur between two stakeholders requiring mutually incompatible features, between requirements and resources, or between functional and non-functional requirements, for example. In most cases, it is unwise for the software engineer to make a unilateral decision, so it becomes necessary to consult with the stakeholder(s) to reach a consensus on an appropriate tradeoff. It is often important, for contractual reasons, that such decisions be traceable back to the customer. We have classified this as a software requirements analysis topic because problems emerge as the result of analysis. However, a strong case can also be made for considering it a requirements validation topic (see topic 6, Requirements Validation).
Requirements prioritization is necessary, not only as a means to filter important requirements, but also in order to resolve conflicts and plan for staged deliveries, which means making complex decisions that require detailed domain knowledge and good estimation skills. However, it is often difficult to get real information that can act as a basis for such decisions. In addition, requirements often depend on each other, and priorities are relative. In practice, software engineers perform requirements prioritization frequently without knowing about all the requirements. Requirements prioritization may follow a cost-value approach that involves an analysis from the stakeholders defining in a scale the benefits or the aggregated value that the implementation of the requirement brings them, versus the penalties of not having implemented a particular requirement. It also involves an analysis from the software engineers estimating in a scale the cost of implementing each requirement, relative to other requirements. Another requirements prioritization approach called the analytic hierarchy process involves comparing all unique pairs of requirements to determine which of the two is of higher priority, and to what extent.
Formal analysis concerns not only topic 4, but also sections 5.3 and 6.3. This topic is also related to Formal Methods in the Software Engineering Models and Methods Knowledge Area.
Formal analysis has made an impact on some application domains, particularly those of high-integrity systems. The formal expression of requirements requires a language with formally defined semantics. The use of a formal analysis for requirements expression has two benefits. First, it enables requirements expressed in the language to be specified precisely and unambiguously, thus (in principle) avoiding the potential for misinterpretation. Secondly, requirements can be reasoned over, permitting desired properties of the specified software to be proven. Formal reasoning requires tool support to be practicable for anything other than trivial systems, and tools generally fall into two types: theorem provers or model checkers. In neither case can proof be fully automated, and the level of competence in formal reasoning needed in order to use the tools restricts the wider application of formal analysis.
Most formal analysis is focused on relatively late stages of requirements analysis. It is generally counterproductive to apply formalization until the business goals and user requirements have come into sharp focus through means such as those described elsewhere in section 4. However, once the requirements have stabilized and have been elaborated to specify concrete properties of the software, it may be beneficial to formalize at least the critical requirements. This permits static validation that the software specified by the requirements does indeed have the properties (for example, absence of deadlock) that the customer, users, and software engineer expect it to have.
For most engineering professions, the term “specification” refers to the assignment of numerical values or limits to a product’s design goals. In software engineering, “software requirements specification” typically refers to the production of a document that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial nonsoftware components, as many as three different types of documents are produced: system definition, system requirements, and software requirements. For simple software products, only the third of these is required. All three documents are described here, with the understanding that they may be combined as appropriate. A description of systems engineering can be found in the Related Disciplines of Software Engineering chapter of this Guide.
This document (sometimes known as the user requirements document or concept of operations document) records the system requirements. It defines the high-level system requirements from the domain perspective. Its readership includes representatives of the system users/customers (marketing may play these roles for market-driven software), so its content must be couched in terms of the domain. The document lists the system requirements along with background information about the overall objectives for the system, its target environment, and a statement of the constraints, assumptions, and nonfunctional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios, and the principal domain entities, as well as workflows.
Developers of systems with substantial software and nonsoftware components - a modern airliner, for example - often separate the description of system requirements from the description of software requirements. In this view, system requirements are specified, the software requirements are derived from the system requirements, and then the requirements for the software components are specified. Strictly speaking, system requirements specification is a systems engineering activity and falls outside the scope of this Guide.
Software requirements specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do.
Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules.
Organizations can also use a software requirements specification document as the basis for developing effective verification and validation plans.
Software requirements specification provides an informed basis for transferring a software product to new users or software platforms. Finally, it can provide a basis for software enhancement.
Software requirements are often written in natural language, but, in software requirements specification, this may be supplemented by formal or semiformal descriptions. Selection of appropriate notations permits particular requirements and aspects of the software architecture to be described more precisely and concisely than natural language. The general rule is that notations should be used that allow the requirements to be described as precisely as possible. This is particularly crucial for safety-critical, regulatory, and certain other types of dependable software. However, the choice of notation is often constrained by the training, skills, and preferences of the document’s authors and readers.
A number of quality indicators have been developed that can be used to relate the quality of software requirements specification to other project variables such as cost, acceptance, performance, schedule, and reproducibility. Quality indicators for individual software requirements specification statements include imperatives, directives, weak phrases, options, and continuances. Indicators for the entire software requirements specification document include size, readability, specification, depth, and text structure.
The requirements documents may be subject to validation and verification procedures. The requirements may be validated to ensure that the software engineer has understood the requirements; it is also important to verify that a requirements document conforms to company standards and that it is understandable, consistent, and complete. In cases where documented company standards or terminology are inconsistent with widely accepted standards, a mapping between the two should be agreed on and appended to the document. Formal notations offer the important advantage of permitting the last two properties to be proven (in a restricted sense, at least). Different stakeholders, including representatives of the customer and developer, should review the document(s). Requirements documents are subject to the same configuration management practices as the other deliverables of the software life cycle processes. When practical, the individual requirements are also subject to configuration management, generally using a requirements management tool (see topic 8, Software Requirements Tools). It is normal to explicitly schedule one or more points in the requirements process where the requirements are validated. The aim is to pick up any problems before resources are committed to addressing the requirements. Requirements validation is concerned with the process of examining the requirements document to ensure that it defines the right software (that is, the software that the users expect).
Perhaps the most common means of validation is by inspection or reviews of the requirements document(s). A group of reviewers is assigned a brief to look for errors, mistaken assumptions, lack of clarity, and deviation from standard practice. The composition of the group that conducts the review is important (at least one representative of the customer should be included for a customer-driven project, for example), and it may help to provide guidance on what to look for in the form of checklists.
Reviews may be constituted on completion of the system definition document, the system specification document, the software requirements specification document, the baseline specification for a new release, or at any other step in the process.
Prototyping is commonly a means for validating the software engineer’s interpretation of the software requirements, as well as for eliciting new requirements. As with elicitation, there is a range of prototyping techniques and a number of points in the process where prototype validation may be appropriate. The advantage of prototypes is that they can make it easier to interpret the software engineer’s assumptions and, where needed, give useful feedback on why they are wrong. For example, the dynamic behavior of a user interface can be better understood through an animated prototype than through textual description or graphical models. The volatility of a requirement that is defined after prototyping has been done is extremely low because there is agreement between the stakeholder and the software engineer - therefore, for safety-critical and crucial features prototyping would really help. There are also disadvantages, however. These include the danger of users’ attention being distracted from the core underlying functionality by cosmetic issues or quality problems with the prototype. For this reason, some advocate prototypes that avoid software, such as flip-chart-based mockups. Prototypes may be costly to develop. However, if they avoid the wastage of resources caused by trying to satisfy erroneous requirements, their cost can be more easily justified. Early prototypes may contain aspects of the final solution. Prototypes may be evolutionary as opposed to throwaway.
It is typically necessary to validate the quality of the models developed during analysis. For example, in object models, it is useful to perform a static analysis to verify that communication paths exist between objects that, in the stakeholders’ domain, exchange data. If formal analysis notations are used, it is possible to use formal reasoning to prove specification properties. This topic is closely related to the Software Engineering Models and Methods KA.
An essential property of a software requirement is that it should be possible to validate that the finished product satisfies it. Requirements that cannot be validated are really just “wishes.” An important task is therefore planning how to verify each requirement. In most cases, designing acceptance tests does this for how end-users typically conduct business using the system. Identifying and designing acceptance tests may be difficult for nonfunctional requirements (see section 1.3, Functional and Nonfunctional Requirements). To be validated, they must first be analyzed and decomposed to the point where they can be expressed quantitatively. Additional information can be found in Acceptance/Qualification/Conformance Testing in the Software Testing KA.
The first level of topic decomposition presented in this KA may seem to describe a linear sequence of activities. This is a simplified view of the process.
The requirements process spans the whole software life cycle. Change management and the maintenance of the requirements in a state that accurately mirrors the software to be built, or that has been built, are key to the success of the software engineering process.
Not every organization has a culture of documenting and managing requirements. It is common in dynamic start-up companies, driven by a strong “product vision” and limited resources, to view requirements documentation as unnecessary overhead. Most often, however, as these companies expand, as their customer base grows, and as their product starts to evolve, they discover that they need to recover the requirements that motivated product features in order to assess the impact of proposed changes. Hence, requirements documentation and change management are key to the success of any requirements process.
There is general pressure in the software industry for ever shorter development cycles, and this is particularly pronounced in highly competitive, market-driven sectors. Moreover, most projects are constrained in some way by their environment, and many are upgrades to, or revisions of, existing software where the architecture is a given. In practice, therefore, it is almost always impractical to implement the requirements process as a linear, deterministic process in which software requirements are elicited from the stakeholders, baselined, allocated, and handed over to the software development team. It is certainly a myth that the requirements for large software projects are ever perfectly understood or perfectly specified. Instead, requirements typically iterate towards a level of quality and detail that is sufficient to permit design and procurement decisions to be made. In some projects, this may result in the requirements being baselined before all their properties are fully understood. This risks expensive rework if problems emerge late in the soft- ware engineering process. However, software engineers are necessarily constrained by project management plans and must therefore take steps to ensure that the “quality” of the requirements is as high as possible given the available resources. They should, for example, make explicit any assumptions that underpin the requirements as well as any known problems. For software products that are developed iteratively, a project team may baseline only those requirements needed for the current iteration. The requirements specialist can continue to develop requirements for future iterations, while developers proceed with design and construction of the current iteration. This approach provides customers with business value quickly, while minimizing the cost of rework.
In almost all cases, requirements understanding continues to evolve as design and development proceeds. This often leads to the revision of requirements late in the life cycle. Perhaps the most crucial point in understanding software requirements is that a significant proportion of the requirements will change. This is sometimes due to errors in the analysis, but it is frequently an inevitable consequence of change in the “environment” - for example, the customer’s operating or business environment, regulatory processes imposed by the authorities, or the market into which software must sell. Whatever the cause, it is important to recognize the inevitability of change and take steps to mitigate its effects. Change has to be managed by ensuring that proposed changes go through a defined review and approval process and by applying careful requirements tracing, impact analysis, and software configuration management (see the Software Configuration Management KA). Hence, the requirements process is not merely a front-end task in software development, but spans the whole software life cycle. In a typical project, the software requirements activities evolve over time from elicitation to change management. A combination of top-down analysis and design methods and bottom-up implementation and refactoring methods that meet in the middle could provide the best of both worlds. However, this is difficult to achieve in practice, as it depends heavily upon the maturity and expertise of the software engineers.
Change management is central to the management of requirements. This topic describes the role of change management, the procedures that need to be in place, and the analysis that should be applied to proposed changes. It has strong links to the Software Configuration Management KA.
Requirements should consist not only of a specification of what is required, but also of ancillary information, which helps manage and interpret the requirements. Requirements attributes must be defined, recorded, and updated as the software under development or maintenance evolves. This should include the various classification dimensions of the requirement (see section 4.1, Requirements Classification) and the verification method or relevant acceptance test plan section. It may also include additional information, such as a summary rationale for each requirement, the source of each requirement, and a change history. The most important requirements attribute, however, is an identifier that allows the requirements to be uniquely and unambiguously identified.
Requirements tracing is concerned with recovering the source of requirements and predicting the effects of requirements. Tracing is fundamental to performing impact analysis when requirements change. A requirement should be traceable backward to the requirements and stakeholders that motivated it (from a software requirement back to the system requirement(s) that it helps satisfy, for example). Conversely, a requirement should be traceable forward into the requirements and design entities that satisfy it (for example, from a system requirement into the software requirements that have been elaborated from it, and on into the code modules that implement it, or the test cases related to that code and even a given section on the user manual which describes the actual functionality) and into the test case that verifies it.
The requirements tracing for a typical project will form a complex directed acyclic graph (DAG) (see Graphs in the Computing Foundations KA) of requirements. Maintaining an up-to-date graph or traceability matrix is an activity that must be considered during the whole life cycle of a product. If the traceability information is not updated as changes in the requirements continue to happen, the traceability information becomes unreliable for impact analysis.
As a practical matter, it is typically useful to have some concept of the “volume” of the requirements for a particular software product. This number is useful in evaluating the “size” of a change in requirements, in estimating the cost of a development or maintenance task, or simply for use as the denominator in other measurements. Functional size measurement (FSM) is a technique for evaluating the size of a body of functional requirements. Additional information on size measurement and standards will be found in the Software Engineering Process KA.
Tools for dealing with software requirements fall broadly into two categories: tools for modeling and tools for managing requirements. Requirements management tools typically support a range of activities - including documentation, tracing, and change management and have had a significant impact on practice. Indeed, tracing and change management are really only practicable if supported by a tool. Since requirements management is fundamental to good requirements practice, many organizations have invested in requirements management tools, although many more manage their requirements in more ad hoc and generally less satisfactory ways (e.g., using spreadsheets).
1. Software Requirements Fundamentals 1.1. Definition of a Software Requirement c4 c1 1.2. Product and Process Requirements c4s1 c1, c6 1.3. Functional and Nonfunctional Requirements c4s1 c12 1.4. Emergent Properties c10 s1 1.5. Quantifiable Requirements c1 1.6. System Requirements and Software Requirements c10s4 c1 2. Requirements Process 2.1. Process Models c4s4 c3 2.2. Process Actors c1, c2, c4, c6 2.3. Process Support and Management c3 2.4. Process Quality and Improvement c22, c23 3. Requirements Elicitation 3.1. Requirements Sources c4s5 c5, c6,c9 3.2. Elicitation Techniques c4s5 c6 4. Requirements Analysis 4.1. Requirements Classification c4s1 c12 4.2. Conceptual Modeling c4s5 c11 4.3. Architectural Design and Requirements Allocation c10s4 c17 4.4. Requirements Negotiation c4s5 c7 4.5. Formal Analysis c12s5 5. Requirements Specification 5.1. System Definition Document c4s2 c10 5.2. System Requirements Specification c4s2, c12s2, c12s3, c12s4, c12s5 c10 5.3. Software Requirements Specification c4s3 c10 6. Requirements Validation 6.1. Requirements Reviews c4s6 c15 6.2. Prototyping c4s6 c13 6.3. Model Validation c4s6 c15 6.4. Acceptance Tests c4s6 c15 7. Practical Considerations 7.1. Iterative Nature of the Requirements Process c4s4 c3, c16 7.2. Change Management c4s7 c18, c19 7.3. Requirements Attributes c4s1 c12, c14 7.4. Requirements Tracing c20 7.5. Measuring Requirements c4s6 c18 8. Software Requirements Tools c21
I. Alexander and L. Beus-Dukic, Discovering Requirements .
An easily digestible and practically oriented book on software requirements, this is perhaps the best of current textbooks on how the various elements of software requirements fit together. It is full of practical advice on (for example) how to identify the various system stakeholders and how to evaluate alternative solutions. Its coverage is exemplary and serves as a useful reference for key techniques such as use case modeling and requirements prioritization.
C. Potts, K. Takahashi, and A. Antón, “Inquiry-Based Requirements Analysis” .
This paper is an easily digested account of work that has proven to be very influential in the development of requirements handling. It describes how and why the elaboration of requirements cannot be a linear process by which the analyst simply transcribes and reformulates requirements elicited from the customer. The role of scenarios is described in a way that helps to define their use in discovering and describing requirements.
A. van Lamsweerde, Requirements Engineering: From System Goals to UML Models to Software Specifications .
Serves as a good introduction to requirements engineering but its unique value is as a reference book for the KAOS goal-oriented requirements modelling language. Explains why goal modelling is useful and shows how it can integrate with mainstream modelling techniques using UML.
O. Gotel and A. Finkelstein, “An Analysis of the Requirements Traceability Problem” .
This paper is a classic reference work on a key element of requirements management. Based on empirical studies, it sets out the reasons for and the barriers to the effective tracing of requirements. It is essential reading for an understanding of why requirements tracing is an essential element of an effective software process.
N. Maiden and C. Ncube, “Acquiring COTS Software Selection Requirements” .
This paper is significant because it recognises explicitly that software products often integrate third-party components. It offers insights into the problems of selecting off-the-shelf software to satisfy requirements: there is usually a mismatch. This challenges some of the assumptions underpinning much of traditional requirements handling, which tends to assume custom software.
 I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011.
 K.E. Wiegers, Software Requirements, 2nd ed., Microsoft Press, 2003.
 INCOSE, Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2, International Council on Systems Engineering, 2012.
 S. Friedenthal, A. Moore, and R. Steiner, A Practical Guide to SysML: The Systems Modeling Language, 2nd ed., Morgan Kaufmann, 2012.
 I. Alexander and L. Beus-Deukic, Discovering Requirements: How to Specify Products and Services, Wiley, 2009.
 C. Potts, K. Takahashi, and A.I. Antón, “Inquiry-Based Requirements Analysis,” IEEE Software, vol. 11, no. 2, Mar. 1994, pp. 21–32.
 A. van Lamsweerde, Requirements Engineering: From System Goals to UML Models to Software Specifications, Wiley, 2009.
 O. Gotel and C.W. Finkelstein, “An Analysis of the Requirements Traceability Problem,” Proc. 1st Int’l Conf. Requirements Eng., IEEE, 1994.
 N.A. Maiden and C. Ncube, “Acquiring COTS Software Selection Requirements,” IEEE Software, vol. 15, no. 2, Mar.–Apr. 1998, pp. 46–56.
ADL Architecture Description Language CBD Component-Based Design CRC Class Responsibility Collaborator DFD Data Flow Diagram ERD Entity Relationship Diagram IDL Interface Description Language MVC Model View Controller OO Object-Oriented PDL Program Design Language
Design is defined as both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of [that] process” . Viewed as a process, software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction. A software design (the result) describes the software architecture - that is, how software is decomposed and organized into components - and the interfaces between those components. It should also describe the components at a level of detail that enables their construction.
Software design plays an important role in developing software: during software design, software engineers produce various models that form a kind of blueprint of the solution to be implemented. We can analyze and evaluate these models to determine whether or not they will allow us to fulfill the various requirements.
We can also examine and evaluate alternative solutions and tradeoffs. Finally, we can use the resulting models to plan subsequent development activities, such as system verification and validation, in addition to using them as inputs and as the starting point of construction and testing. In a standard list of software life cycle processes, such as that in ISO/IEC/IEEE Std. 12207, Software Life Cycle Processes , software design consists of two activities that fit between software requirements analysis and software construction:
This Software Design knowledge area (KA) does not discuss every topic that includes the word “design.” In Tom DeMarco’s terminology , the topics discussed in this KA deal mainly with D-design (decomposition design), the goal of which is to map software into component pieces. However, because of its importance in the field of software architecture, we will also address FP-design (family pattern design), the goal of which is to establish exploitable commonalities in a family of software products. This KA does not address I-design (invention design), which is usually performed during the software requirements process with the goal of conceptualizing and specifying software to satisfy discovered needs and requirements, since this topic is considered to be part of the requirements process (see the Software Requirements KA).
This Software Design KA is related specifically to the Software Requirements, Software Construction, Software Engineering Management, Software Engineering Models and Methods, Software Quality, and Computing Foundations KAs.
Breakdown Of Topics For Software Design
The breakdown of topics for the Software Design KA is shown in Figure 2.1.
The concepts, notions, and terminology introduced here form an underlying basis for understanding the role and scope of software design.
In the general sense, design can be viewed as a form of problem solving. For example, the concept of a wicked problem - a problem with no definitive solution - is interesting in terms of understanding the limits of design. A number of other notions and concepts are also of interest in understanding design in its general sense: goals, constraints, alternatives, representations, and solutions (see Problem Solving Techniques in the Computing Foundations KA).
Software design is an important part of the software development process. To understand the role of software design, we must see how it fits in the software development life cycle. Thus, it is important to understand the major characteristics of software requirements analysis, software design, software construction, software testing, and software maintenance.
Software design is generally considered a two-step process:
The output of these two processes is a set of models and artifacts that record the major decisions that have been taken, along with an explanation of the rationale for each nontrivial decision. By recording the rationale, long-term maintainability of the software product is enhanced.
A principle is “a comprehensive and fundamental law, doctrine, or assumption” . Software design principles are key notions that provide the basis for many different software design approaches and concepts. Software design principles include abstraction; coupling and cohesion; decomposition and modularization; encapsulation/information hiding; separation of interface and implementation; sufficiency, completeness, and primitiveness; and separation of concerns.
A number of key issues must be dealt with when designing software. Some are quality concerns that all software must address - for example, performance, security, reliability, usability, etc. Another important issue is how to decompose, organize, and package software components. This is so fundamental that all design approaches address it in one way or another (see section 1.4, Software Design Principles, and topic 7, Software Design Strategies and Methods). In contrast, other issues “deal with some aspect of software’s behavior that is not in the application domain, but which addresses some of the supporting domains” . Such issues, which often crosscut the system’s functionality, have been referred to as aspects, which “tend not to be units of software’s functional decomposition, but rather to be properties that affect the performance or semantics of the components in systemic ways” . A number of these key, crosscutting issues are discussed in the following sections (presented in alphabetical order).
Design for concurrency is concerned with decomposing software into processes, tasks, and threads and dealing with related issues of efficiency, atomicity, synchronization, and scheduling.
This design issue is concerned with how to organize data and control flow as well as how to handle reactive and temporal events through various mechanisms such as implicit invocation and call-backs.
This design issue is concerned with how to handle long-lived data.
This design issue is concerned with how to distribute the software across the hardware (including computer hardware and network hardware), how the components communicate, and how middleware can be used to deal with heterogeneous software.
This design issue is concerned with how to prevent, tolerate, and process errors and deal with exceptional conditions.
This design issue is concerned with how to structure and organize interactions with users as well as the presentation of information (for example, separation of presentation and business logic using the Model-View-Controller approach). Note that this topic does not specify user interface details, which is the task of user interface design (see topic 4, User Interface Design).
Design for security is concerned with how to prevent unauthorized disclosure, creation, change, deletion, or denial of access to information and other resources. It is also concerned with how to tolerate security-related attacks or violations by limiting damage, continuing service, speeding repair and recovery, and failing and recovering securely. Access control is a fundamental concept of security, and one should also ensure the proper use of cryptology.
In its strict sense, a software architecture is “the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both” . During the mid-1990s, however, software architecture started to emerge as a broader discipline that involved the study of software structures and architectures in a more generic way. This gave rise to a number of interesting concepts about software design at different levels of abstraction. Some of these concepts can be useful during the architectural design (for example, architectural styles) as well as during the detailed design (for example, design patterns). These design concepts can also be used to design families of programs (also known as product lines). Interestingly, most of these concepts can be seen as attempts to describe, and thus reuse, design knowledge.
Different high-level facets of a software design can be described and documented. These facets are often called views: “A view represents a partial aspect of a software architecture that shows specific properties of a software system” . Views pertain to distinct issues associated with software design - for example, the logical view (satisfying the functional requirements) vs. the process view (concurrency issues) vs. the physical view (distribution issues) vs. the development view (how the design is broken down into implementation units with explicit representation of the dependencies among the units). Various authors use different terminologies - like behavioral vs. functional vs. structural vs. data modeling views. In summary, a software design is a multifaceted artifact produced by the design process and generally composed of relatively independent and orthogonal views.
An architectural style is “a specialization of element and relation types, together with a set of constraints on how they can be used” . An architectural style can thus be seen as providing the software’s high-level organization. Various authors have identified a number of major architectural styles:
Succinctly described, a pattern is “a common solution to a common problem in a given context” . While architectural styles can be viewed as patterns describing the high-level organization of software, other design patterns can be used to describe details at a lower level. These lower level design patterns include the following:
Architectural design is a creative process. During the design process, software designers have to make a number of fundamental decisions that profoundly affect the software and the development process. It is useful to think of the archi- tectural design process from a decision-making perspective rather than from an activity perspective. Often, the impact on quality attributes and tradeoffs among competing quality attributes are the basis for design decisions.
One approach to providing for reuse of software designs and components is to design families of programs, also known as software product lines. This can be done by identifying the commonalities among members of such families and by designing reusable and customizable components to account for the variability among family members. In object-oriented (OO) programming, a key related notion is that of a framework : a partially completed software system that can be extended by appropriately instantiating specific extensions (such as plug-ins).
User interface design is an essential part of the software design process. User interface design should ensure that interaction between the human and the machine provides for effective operation and control of the machine. For software to achieve its full potential, the user interface should be designed to match the skills, experience, and expectations of its anticipated users.
User interface design should solve two key issues:
1 Chapter 29 is a web-based chapter available at http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/ WebChapters/.
User interface design must integrate user interaction and information presentation. User interface design should consider a compromise between the most appropriate styles of interaction and presentation for the software, the background and experience of the software users, and the available devices.
User interaction involves issuing commands and providing associated data to the software. User interaction styles can be classified into the following primary styles:
Information presentation may be textual or graphical in nature. A good design keeps the information presentation separate from the information itself. The MVC (Model-View-Controller) approach is an effective way to keep information presentation separating from the information being presented.
Software engineers also consider software response time and feedback in the design of information presentation. Response time is generally measured from the point at which a user executes a certain control action until the software responds with a response. An indication of progress is desirable while the software is preparing the response. Feedback can be provided by restating the user’s input while processing is being completed. Abstract visualizations can be used when large amounts of information are to be presented. According to the style of information presentation, designers can also use color to enhance the interface. There are several important guidelines:
User interface design is an iterative process; interface prototypes are often used to determine the features, organization, and look of the software user interface. This process includes three core activities:
User interface design often needs to consider internationalization and localization, which are means of adapting software to the different languages, regional differences, and the technical requirements of a target market. Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without major engineering changes. Localization is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating the text. Localization and internationalization should consider factors such as symbols, numbers, currency, time, and measurement units.
User interface designers can use metaphors and conceptual models to set up mappings between the software and some reference system known to the users in the real world, which can help the users to more readily learn and use the interface. For example, the operation “delete file” can be made into a metaphor using the icon of a trash can. When designing a user interface, software engineers should be careful to not use more than one metaphor for each concept. Metaphors also present potential problems with respect to internationalization, since not all metaphors are meaningful or are applied in the same way within all cultures.
This section includes a number of quality analysis and evaluation topics that are specifically related to software design. (See also the Software Quality KA.)
Various attributes contribute to the quality of a software design, including various “-ilities” (maintainability, portability, testability, usability) and “-nesses” (correctness, robustness). There is an interesting distinction between quality attributes discernible at runtime (for example, performance, security, availability, functionality, usability), those not discernible at runtime (for example, modifiability, portability, reusability, testability), and those related to the architecture’s intrinsic qualities (for example, conceptual integrity, correctness, completeness). (See also the Software Quality KA.)
Various tools and techniques can help in analyzing and evaluating software design quality.
Measures can be used to assess or to quantitatively estimate various aspects of a software design; for example, size, structure, or quality. Most measures that have been proposed depend on the approach used for producing the design. These measures are classified in two broad categories:
Many notations exist to represent software design artifacts. Some are used to describe the structural organization of a design, others to represent software behavior. Certain notations are used mostly during architectural design and others mainly during detailed design, although some notations can be used for both purposes. In addition, some notations are used mostly in the context of specific design methods (see topic 7, Software Design Strategies and Methods). Please note that software design is often accomplished using multiple notations. Here, they are categorized into notations for describing the structural (static) view vs. the behavioral (dynamic) view.
The following notations, mostly but not always graphical, describe and represent the structural aspects of a software design - that is, they are used to describe the major components and how they are interconnected (static view):
The following notations and languages, some graphical and some textual, are used to describe the dynamic behavior of software systems and components. Many of these notations are useful mostly, but not exclusively, during detailed design. Moreover, behavioral descriptions can include a rationale for design decision such as how a design will meet security requirements.
There exist various general strategies to help guide the design process. In contrast with general strategies, methods are more specific in that they generally provide a set of notations to be used with the method, a description of the process to be used when following the method, and a set of guidelines for using the method. Such methods are useful as a common framework for teams of software engineers. (See also the Software Engineering Models and Methods KA).
Some often-cited examples of general strategies useful in the design process include the divide-and-conquer and stepwise refinement strategies, top-down vs. bottom-up strategies, and strategies making use of heuristics, use of patterns and pattern languages, and use of an iterative and incremental approach.
This is one of the classical methods of software design, where decomposition centers on identifying the major software functions and then elaborating and refining them in a hierarchical top-down manner. Structured design is generally used after structured analysis, thus producing (among other things) data flow diagrams and associated process descriptions. Researchers have proposed various strategies (for example, transformation analysis, transaction analysis) and heuristics (for example, fan-in/fan-out, scope of effect vs. scope of control) to transform a DFD into a software architecture generally represented as a structure chart.
Numerous software design methods based on objects have been proposed. The field has evolved from the early object-oriented (OO) design of the mid-1980s (noun = object; verb = method; adjective = attribute), where inheritance and polymorphism play a key role, to the field of component-based design, where metainformation can be defined and accessed (through reflection, for example). Although OO design’s roots stem from the concept of data abstraction, responsibility-driven design has been proposed as an alternative approach to OO design.
Data structure-centered design starts from the data structures a program manipulates rather than from the function it performs. The software engineer first describes the input and output data structures and then develops the program’s control structure based on these data structure diagrams. Various heuristics have been proposed to deal with special cases - for example, when there is a mismatch between the input and output structures.
A software component is an independent unit, having well-defined interfaces and dependencies that can be composed and deployed independently. Component-based design addresses issues related to providing, developing, and integrating such components in order to improve reuse. Reused and off-the-shelf software components should meet the same security requirements as new software. Trust management is a design concern; components treated as having a certain degree of trustworthiness should not depend on less trustworthy components or services.
Other interesting approaches also exist (see the Software Engineering Models and Methods KA). Iterative and adaptive methods implement software increments and reduce emphasis on rigorous software requirement and design.
Software Design 2-11
Aspect-oriented design is a method by which software is constructed using aspects to implement the crosscutting concerns and extensions that are identified during the software requirements process. Service-oriented architecture is a way to build distributed software using web services executed on distributed computers. Software systems are often constructed by using services from different providers because standard protocols (such as HTTP, HTTPS, SOAP) have been designed to support service communication and service information exchange.
Software design tools can be used to support the creation of the software design artifacts during the software development process. They can support part or whole of the following activities:
Clements et al. 2010
Gamma et al. 1994
1. Software Design Fundamentals 1.1. General Design Concepts c1 1.2. The Context of Software Design c3 1.3. The Software Design Process c2 1.4. Software Design Principles c1 c6, c7, c21 c1, c8, c9 2. Key Issues in Software Design 2.1. Concurrency c18 2.2. Control and Handling of Events c21 2.3. Data Persistence c9 2.4. Distribution of Components c18 2.5. Error and Exception Handling and Fault Tolerance c18 2.6. Interaction and Presentation c16 2.7. Security c12, c18 c4 3. Software Structure and Architecture 3.1. Architectural Structures and Viewpoints c1 3.2. Architectural Styles c1, c2, c3, c4, c5 3.3. Design Patterns c3, c4, c5
Software Design 2-13
Clements et al. 2010
Gamma et al. 1994
3.4. Architecture Design Decisions c6 3.5. Families of Programs and Frameworks c6, c7, c16
4. User Interface Design 4.1. General User Interface Design Principle c29- web c2 4.2. User Interface Design Issues c29- web 4.3. The Design of User Interaction Modalities c29- web 4.4. The Design of Information Presentation c29- web 4.5. User Interface Design Process c29- web 4.6. Localization and Internationalization c8, c9 4.7. Metaphors and Conceptual Models c5 5. Software Design Quality Analysis and Evaluation 5.1. Quality Attributes c4 5.2. Quality Analysis and Evaluation Techniques c4 c24 5.3. Measures c4 c24
Clements et al. 2010
Gamma et al. 1994
6. Software Design Notations 6.1. Structural Descriptions (Static View) c7 c6, c7 c4, c5, c6, c7 c7 c7 6.2. Behavioral Descriptions (Dynamic View) c7, c13, c18 c6, c7 c4, c5, c6, c7 c8 7. Software Design Strategies and Methods 7.1. General Strategies c8, c9, c10 c7 7.2. Function-Oriented (Structured) Design c13 7.3. Object-Oriented Design c16 7.4. Data Structure-Centered Design c14, c15 7.5. Component-Based Design (CBD) c17 7.6. Other Methods c19, c21
8. Software Design Tools
c10, App. A
Software Design 2-15
Roger Pressman, Software Engineering: A Practitioner’s Approach (Seventh Edition) .
For roughly three decades, Roger Pressman’s Software Engineering: A Practitioner’s Approach has been one of the world’s leading textbooks in software engineering. Notably, this complemen- tary textbook to  comprehensively presents software design - including design concepts, architectural design, component-level design, user interface design, pattern-based design, and web application design.
“The 4+1 View Model of Architecture” .
The seminal paper “The 4+1 View Model” organizes a description of a software architecture using five concurrent views. The four views of the model are the logical view, the development view, the process view, and the physical view. In addition, selected use cases or scenarios are utilized to illustrate the architecture. Hence, the model contains 4+1 views. The views are used to describe the software as envisioned by different stakeholders - such as end-users, developers, and project managers.
Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice .
This book introduces the concepts and best practices of software architecture, meaning how software is structured and how the software’s components interact. Drawing on their own experience, the authors cover the essential technical topics for designing, specifying, and validating software architectures. They also emphasize the importance of the business context in which large software is designed. Their aim is to present software architecture in a real-world setting, reflecting both the opportunities and constraints that organizations encounter. This is one of the best books currently available on software architecture.
 ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary, ISO/ IEC/IEEE, 2010.
 IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes, IEEE, 2008.
 T. DeMarco, “The Paradox of Software Architecture and Design,” Stevens Prize Lecture, 1999.
 D. Budgen, Software Design, 2nd ed., Addison-Wesley, 2003.
 I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011.
 M. Page-Jones, Fundamentals of Object- Oriented Design in UML, 1st ed., Addison- Wesley, 1999.
 Merriam-Webster’s Collegiate Dictionary, 11th ed., 2003.
 IEEE Std. 1069-2009 Standard for Information Technology—Systems Design—Software Design Descriptions, IEEE, 2009.
 ISO/IEC 42010:2011 Systems and Software Engineering—Recommended Practice for Architectural Description of Software- Intensive Systems, ISO/IEC, 2011.
 J. Bosch, Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, ACM Press, 2000.
 G. Kiczales et al., “Aspect-Oriented Programming,” Proc. 11th European Conf. Object-Oriented Programming (ECOOP 97), Springer, 1997.
 J.G. Brookshear, Computer Science: An Overview, 10th ed., Addison-Wesley, 2008.
 J.H. Allen et al., Software Security Engineering: A Guide for Project Managers, Addison-Wesley, 2008.
 P. Clements et al., Documenting Software Architectures: Views and Beyond, 2nd ed., Pearson Education, 2010.
 E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1st ed., Addison-Wesley Professional, 1994.
 I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Software Development Process, Addison-Wesley Professional, 1999.
 J. Nielsen, Usability Engineering, Morgan Kaufmann, 1993.
 G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999.
 R.S. Pressman, Software Engineering: A Practitioner’s Approach, 7th ed., McGraw- Hill, 2010.
 P.B. Kruchten, “The 4+1 View Model of Architecture,” IEEE Software, vol. 12, no. 6, 1995, pp. 42–55.
 L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 3rd ed., Addison-Wesley Professional, 2013.
The term software construction refers to the detailed creation of working software through a combination of coding, verification, unit testing, integration testing, and debugging. The Software Construction knowledge area (KA) is linked to all the other KAs, but it is most strongly linked to Software Design and Software Testing because the software construction process involves significant software design and testing. The process uses the design output and provides an input to testing (“design” and “testing” in this case referring to the activities, not the KAs). Boundaries between design, construction, and testing (if any) will vary depending on the software life cycle processes that are used in a project. Although some detailed design may be performed prior to construction, much design work is performed during the construction activity. Thus, the Software Construction KA is closely linked to the Software Design KA. Throughout construction, software engineers both unit test and integration test their work.
Thus, the Software Construction KA is closely linked to the Software Testing KA as well. Software construction typically produces the highest number of configuration items that need to be managed in a software project (source files, documentation, test cases, and so on). Thus, the Software Construction KA is also closely linked to the Software Configuration Management KA. While software quality is important in all the KAs, code is the ultimate deliverable of a software project, and thus the Software Quality KA is closely linked to the Software Construction KA. Since software construction requires knowledge of algorithms and of coding practices, it is closely related to the Computing Foundations KA, which is concerned with the computer science foundations that support the design and construction of software products. It is also related to project management, insofar as the management of construction can present considerable challenges.
Breakdown Of Topics For Software Construction
Figure 3.1 gives a graphical representation of the top-level decomposition of the breakdown for the Software Construction KA.
Software construction fundamentals include
The first four concepts apply to design as well as to construction. The following sections define these concepts and describe how they apply to construction.