CHAPTER 4 SOFTWARE CONSTRUCTION

ACRONYMS
OMG: Object Management Group
UML: Unified Modeling Language

The term software construction refers to the detailed creation of working, meaningful software through a
combination of coding, verification, unit testing, integration testing, and debugging. The Software Construction Knowledge Area is linked to all the other KAs, most strongly to Software Design and Software Testing. This is because the software construction process itself involves significant software design and test activity. It also uses the output of design and provides one of the inputs to testing, both design and testing being the activities, not the KAs in this case. Detailed boundaries between design, construction, and testing (if any) will vary depending upon the software life cycle processes that are used in a project.

1. Software Construction Fundamentals

1.1. Minimizing Complexity

A major factor in how people convey intent to computers is the severely limited ability of people to hold complex structures and information in their working memories, especially over long periods of time. This leads to one of the strongest drivers in software construction: minimizing complexity. The need to reduce complexity applies to essentially every aspect of software construction, and is particularly critical to the process of verification and testing of software constructions. In software construction, reduced complexity is achieved through emphasizing the creation of code that is simple and readable rather than clever.

1.2. Anticipating Change
Most software will change over time, and the anticipation of change drives many aspects of software construction. Software is unavoidably part of changing external environments, and changes in those outside environments affect software in diverse ways. Anticipating change is supported by many specific techniques.

1.3. Constructing for Verification
Constructing for verification means building software in such a way that faults can be ferreted out readily by the software engineers writing the software, as well as during independent testing and operational activities. Specific techniques that support constructing for verification include following coding standards to support code reviews, unit testing, organizing code to support automated testing, and restricted use of complex or hard-to-understand language structures, among others.

1.4. Standards in Construction
Standards that directly affect construction issues include
- Communication methods (for example, standards for document formats and contents)
- Programming languages (for example, language standards for languages like Java and C++)
- Platforms (for example, programmer interface standards for operating system calls)
- Tools (for example, diagrammatic standards for notations like UML (Unified Modeling Language))

Use of external standards. Construction depends on the use of external standards for construction languages,
construction tools, technical interfaces, and interactions between Software Construction and other KAs. Standards come from numerous sources, including hardware and software interface specifications such as the Object Management Group (OMG) and international organizations such as the IEEE or ISO.
Use of internal standards. Standards may also be created on an organizational basis at the corporate level or for use on specific projects. These standards support coordination of group activities, minimizing complexity, anticipating change, and constructing for verification.

2. Managing Construction
2.1. Construction Models 
Numerous models have been created to develop software, some of which emphasize construction more than others. Some models are more linear from the construction point of view, such as the waterfall and staged-delivery life cycle models. These models treat construction as an activity which occurs only after significant prerequisite work has been completed—including detailed requirements work, extensive design work, and detailed planning. The more linear approaches tend to emphasize the activities that precede construction (requirements and design), and tend to create more distinct separations between the activities. In these models, the main emphasis of construction may be coding. Other models are more iterative, such as evolutionary prototyping, Extreme Programming, and Scrum. These approaches tend to treat construction as an activity that occurs concurrently with other software development activities, including requirements, design, and planning, or overlaps them. These approaches tend to mix design, coding, and testing activities, and they often treat the combination of activities as construction. Consequently, what is considered to be “construction”
depends to some degree on the life cycle model used.

2.2. Construction Planning
The choice of construction method is a key aspect of the construction planning activity. The choice of construction method affects the extent to which construction prerequisites are performed, the order in which they are performed, and the degree to which they are expected to be completed before construction work begins. The approach to construction affects the project’s ability to reduce complexity, anticipate change, and construct for verification. Each of these objectives may also be addressed at the process, requirements, and design levels—but they will also be influenced by the choice of construction method.
Construction planning also defines the order in which components are created and integrated, the software  quality management processes, the allocation of task assignments to specific software engineers, and the other tasks, according to the chosen method.

2.3. Construction Measurement
Numerous construction activities and artifacts can be measured, including code developed, code modified, code reused, code destroyed, code complexity, code inspection statistics, fault-fix and fault-find rates, effort, and scheduling. These measurements can be useful for purposes of managing construction, ensuring quality during construction,improving the construction process, as well as for other reasons. See the Software Engineering Process KA for more on measurements.

3. Practical considerations
Construction is an activity in which the software has to come to terms with arbitrary and chaotic real-world
constraints, and to do so exactly. Due to its proximity to real-world constraints, construction is more driven by practical considerations than some other KAs, and software engineering is perhaps most craft-like in the construction area.

3.1. Construction Design
Some projects allocate more design activity to construction; others to a phase explicitly focused on design. Regardless of the exact allocation, some detailed design work will occur at the construction level, and that design work tends to be dictated by immovable constraints imposed by the real-world problem that is being addressed by the software. Just as construction workers building a physical structure must make small-scale modifications to account for unanticipated gaps in the builder’s plans, software construction workers must make modifications on a smaller or larger scale to flesh out details of the software design during construction.
The details of the design activity at the construction level are essentially the same as described in the Software
Design KA, but they are applied on a smaller scale.


3.2 Construction Languages
Construction languages include all forms of communication by which a human can specify an
executable problem solution to a computer. The simplest type of construction language is a configuration language, in which software engineers choose from a limited set of predefined options to create new or custom software installations. The text-based configuration files used in both the Windows and Unix operating systems are examples of this, and the menu style selection lists of some program generators constitute another.
Toolkit languages are used to build applications out of toolkits (integrated sets of application-specific reusable
parts), and are more complex than configuration languages. Toolkit languages may be explicitly defined as application programming languages (for example, scripts), or may simply be implied by the set of interfaces of a toolkit. Programming languages are the most flexible type of construction languages. They also contain the least amount of information about specific application areas and development processes, and so require the most training and skill to use effectively. There are three general kinds of notation used for
programming languages, namely:
- Linguistic: Linguistic notations are distinguished in particular by the use of word-like strings of text to represent complex software constructions, and the combination of such wordlike strings into patterns that have a sentence-like syntax. Properly used, each such string should have a strong semantic connotation providing an immediate intuitive understanding of what will happen when the underlying software construction is executed.
- Formal: Formal notations rely less on intuitive, everyday meanings of words and text strings and more on definitions backed up by precise, unambiguous, and formal (or mathematical) definitions. Formal construction notations and formal methods are at the heart of most forms of system programming, where accuracy, time behavior, and testability are more important than ease of mapping into natural language. Formal constructions also use precisely defined ways of combining symbols that avoid the ambiguity of many natural language constructions.
- Visual: Visual notations rely much less on the text-oriented notations of both linguistic and formal construction, and instead rely on direct visual interpretation and placement of visual entities that represent the underlying software. Visual construction tends to be somewhat limited by the difficulty of making “complex“ statements using only movement of visual entities on a display. However, it can also be a powerful tool in cases where the primary programming task is simply to build and “adjust“ a visual interface to a program, the detailed behavior of which has been defined earlier.


3.2. Coding
The following considerations apply to the software construction coding activity:
- Techniques for creating understandable source code, including naming and source code layout
- Use of classes, enumerated types, variables, named constants, and other similar entities
- Use of control structures
- Handling of error conditions—both planned errors and exceptions (input of bad data, for example)
- Prevention of code-level security breaches (buffer overruns or array index overflows, for example)
- Resource usage via use of exclusion mechanisms and discipline in accessing serially reusable resources
(including threads or database locks)
- Source code organization (into statements, routines, classes, packages, or other structures)
- Code documentation
- Code tuning


3.3. Construction Testing
Construction involves two forms of testing, which are often performed by the software engineer who wrote the code:
- Unit testing
- Integration testing

The purpose of construction testing is to reduce the gap between the time at which faults are inserted into the code and the time those faults are detected. In some cases, construction testing is performed after code has been written. In other cases, test cases may be created before code is written. Construction testing typically involves a subset of types of testing, which are described in the Software Testing KA. For instance, construction testing does not typically include system testing, alpha testing, beta testing, stress testing, configuration testing, usability testing, or other, more specialized kinds of testing.


3.4. Reuse
As stated in the introduction of (IEEE1517-99): “Implementing software reuse entails more than creating
and using libraries of assets. It requires formalizing the practice of reuse by integrating reuse processes and
activities into the software life cycle.“ However, reuse is important enough in software construction that it is
included here as a topic. The tasks related to reuse in software construction during coding and testing are:
- The selection of the reusable units, databases, test procedures, or test data
- The evaluation of code or test reusability
- The reporting of reuse information on new code, test procedures, or test data

3.5. Construction Quality
Numerous techniques exist to ensure the quality of code as it is constructed. The primary techniques used for
construction include
- Unit testing and integration testing
- Test-first development
- Code stepping
- Use of assertions
- Debugging
- Technical reviews
- Static analysis

The specific technique or techniques selected depend on the nature of the software being constructed, as well as on the skills set of the software engineers performing the construction.
Construction quality activities are differentiated from other quality activities by their focus. Construction quality
activities focus on code and on artifacts that are closely related to code: small-scale designs—as opposed to other artifacts that are less directly connected to the code, such as requirements, high-level designs, and plans.

3.7 Integration
A key activity during construction is the integration of separately constructed routines, classes, components, and subsystems. In addition, a particular software system may need to be integrated with other software or hardware systems. Concerns related to construction integration include planning the sequence in which components will be integrated, creating scaffolding to support interim versions of the software, determining the degree of testing and quality work performed on components before they are integrated, and determining points in the project at which interim versions of the software are tested.

CHAPTER 3 SOFTWARE DESIGN Second Part

This is the second part  of the chapter.

4. Software Design Quality Analysis and Evaluation
This section includes a number of quality and evaluation topics that are specifically related to software design. Most are covered in a general manner in the Software Quality KA.

4.1. Quality Attributes
Various attributes are generally considered important for obtaining a software design of good quality—various
“ilities” (maintainability, portability, testability, traceability), various “nesses” (correctness, robustness), including “fitness of purpose.” An interesting distinction is the one between quality attributes discernable at run-time (performance, security, availability, functionality, usability), those not discernable at run-time (modifiability, portability, reusability, integrability, and testability), and those related to the architecture’s intrinsic qualities (conceptual integrity, correctness, and completeness, buildability).

4.2. Quality Analysis and Evaluation Techniques
Various tools and techniques can help ensure a software design’s quality.
- Software design reviews: informal or semiformal, often group-based, techniques to verify and ensure the
quality of design artifacts (for example, architecture reviews, design reviews, and inspections, scenario-based techniques, requirements tracing)
- Static analysis: formal or semiformal static (nonexecutable) analysis that can be used to evaluate a
design (for example, fault-tree analysis or automated cross-checking)
- Simulation and prototyping: dynamic techniques to evaluate a design (for example, performance
simulation or feasibility prototype

4.3. Measures
Measures can be used to assess or to quantitatively estimate various aspects of a software design’s size, structure, or quality. Most measures that have been proposed generally depend on the approach used for producing the design. These measures are classified in two broad categories:
- Function-oriented (structured) design measures: the design’s structure, obtained mostly through functional
decomposition; generally represented as a structure chart (sometimes called a hierarchical diagram) on
which various measures can be computed
- Object-oriented design measures: the design’s overall structure is often represented as a class diagram, on
which various measures can be computed. Measures on the properties of each class’s internal content can also be computed

5. Software Design Notations
Many notations and languages exist to represent software design artifacts. Some are used mainly to describe a
design’s structural organization, 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 in both steps. In addition, some notations are used mostly in the context of specific methods (see the Software Design Strategies and Methods subarea). Here, they are categorized into notations for describing the structural (static) view vs. the behavioral (dynamic) view.

5.1. Structural Descriptions (static view)
The following notations, mostly (but not always) graphical, describe and represent the structural aspects of a software design—that is, they describe the major components and how they are interconnected (static view): - Architecture description languages (ADLs): textual, often formal, languages used to describe a software
architecture in terms of components and connectors Class and object diagrams: used to represent a set of
classes (and objects) and their interrelationships
- Component diagrams: used to represent a set of components (“physical and replaceable part[s] of a
system that [conform] to and [provide] the realization of a set of interfaces”) and their interrelationships
- Class responsibility collaborator cards (CRCs): used to denote the names of components (class), their
responsibilities, and their collaborating components’ names
- Deployment diagrams: used to represent a set of (physical) nodes and their interrelationships, and, thus,
to model the physical aspects of a system
- Entity-relationship diagrams (ERDs): used to represent conceptual models of data stored in information
systems
- Interface description languages (IDLs): programminglike languages used to define the interfaces (names and
types of exported operations) of software components
- Jackson structure diagrams: used to describe the data structures in terms of sequence, selection, and iteration
- Structure charts: used to describe the calling structure of programs (which module calls, and is called by,
which other module)

5.2. Behavioral Descriptions (dynamic view)
The following notations and languages, some graphical and some textual, are used to describe the dynamic behavior of software and components. Many of these notations are useful mostly, but not exclusively, during detailed design.
- Activity diagrams: used to show the control flow from activity (“ongoing non-atomic execution within a state
machine”) to activity
- Collaboration diagrams: used to show the interactions that occur among a group of objects, where the
emphasis is on the objects, their links, and the messages they exchange on these links
- Data flow diagrams (DFDs): used to show data flow among a set of processes
- Decision tables and diagrams: used to represent complex combinations of conditions and actions
- Flowcharts and structured flowcharts: used to represent the flow of control and the associated actions
to be performed
- Sequence diagrams: used to show the interactions among a group of objects, with emphasis on the timeordering of messages
- State transition and statechart diagrams: used to show the control flow from state to state in a state machine
- Formal specification languages: textual languages that use basic notions from mathematics (for example,
logic, set, sequence) to rigorously and abstractly define software component interfaces and behavior, often in
terms of pre- and post-conditions
- Pseudocode and program design languages (PDLs): structured-programming-like languages used to
describe, generally at the detailed design stage, the behavior of a procedure or method

6. Software Design Strategies and Methods
There exist various general strategies to help guide the design process. In contrast with general strategies, methods are more specific in that they generally suggest and 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 in using
the method. Such methods are useful as a means of transferring knowledge and as a common
framework for teams of software engineers.

6.1. General Strategies
Some often-cited examples of general strategies useful in the design process are divide-and-conquer and stepwise refinement, top-down vs. bottom-up strategies, data abstraction and information hiding, use of heuristics, use of patterns and pattern languages use of an iterative and incremental approach.

6.2. Function-Oriented (Structured) Design
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 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.

6.3. Object-Oriented Design
Numerous software design methods based on objects have been proposed. The field has evolved from the early objectbased design of the mid-1980s (noun = object; verb = method; adjective = attribute) through OO design, where inheritance and polymorphism play a key role, to the field of component-based design, where meta-information 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 also been proposed as an alternative approach to OO design.

6.4. Data-Structure-Centered Design
Data-structure-centered design (for example, Jackson, Warnier-Orr) 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 (using Jackson’s structure diagrams, for instance) 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.

6.5. Component-Based Design (CBD)
A software component is an independent unit, having welldefined 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.

6.6. Other Methods
Other interesting but less mainstream approaches also exist: formal and rigorous methods and transformational methods.

Chapter 3. SOFTWARE DESIGN

ACRONYMS
ADL: Architecture Description Languages
CRC: Class Responsibility Collaborator card
ERD: Entity-Relationship Diagram
IDL: Interface Description Language
DFD: Data Flow Diagram
PDL: Pseudo-Code and Program Design Language
CBD: Component-Based design

Design is defined in [IEEE610.12-90] 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. More precisely, a software design (the result) must describe the software architecture—that is, how software is decomposed and organized into components—and the interfaces between those components. It must also describe the components at a level of detail that enable their construction. Software design plays an important role in developing software: it allows software engineers to 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 various alternative solutions and trade-offs. Finally, we can use the resulting models to plan the subsequent development activities, in addition to using them as input and the starting point of construction and testing.

Software design consists of two activities that fit between software requirements analysis and software construction:
- Software architectural design (sometimes called toplevel design): describing software’s top-level structure
and organization and identifying the various components
- Software detailed design: describing each component sufficiently to allow for its construction.

The Software Design KA description is related specifically to Software Requirements, Software Construction, Software Engineering Management, Software Quality, and Related Disciplines of Software Engineering.

1. Software Design Fundamentals
The concepts, notions, and terminology introduced here form an underlying basis for understanding the role and scope of software design.

1.1. General Design Concepts
Software is not the only field where design is involved. In the general sense, we can view design as a form of problemsolving. 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.

1.2. Context of Software Design
To understand the role of software design, it is important to understand the context in which it fits, the software engineering life cycle. Thus, it is important to understand the major characteristics of software requirements analysis vs. software design vs. software construction vs. software testing.

1.3. Software Design Process
Software design is generally considered a two-step process:
1.3.1. Architectural design
Architectural design describes how software is decomposed and organized into components (the software architecture)
1.3.2. Detailed design
Detailed design describes the specific behavior of these components. The output of this process is a set of models and artifacts that record the major decisions that have been taken.

1.4. Enabling Techniques
According to the Oxford English Dictionary, a principle is “a basic truth or a general law … that is used as a basis of reasoning or a guide to action.” Software design principles, also called enabling techniques, are key notions considered fundamental to many different software design approaches and concepts. The enabling techniques are the following:
1.4.1. Abstraction
Abstraction is “the process of forgetting information so that things that are different can be treated as if

they were the same.” In the context of software design, two key abstraction mechanisms are parameterization and specification. Abstraction by specification leads to three major kinds of abstraction: procedural abstraction, data abstraction, and control (iteration) abstraction. 

1.4.2. Coupling and cohesion

Coupling is defined as the strength of the relationships between modules, whereas cohesion is defined by how the elements making up a module are related.
1.4.3. Decomposition and modularization
Decomposing and modularizing large software into a number of smaller independent ones, usually with
the goal of placing different functionalities or responsibilities in different components.
1.4.4. Encapsulation/information hiding
Encapsulation/information hiding means grouping and packaging the elements and internal details of an
abstraction and making those details inaccessible.
1.4.5. Separation of interface and implementation
Separating interface and implementation involves defining a component by specifying a public
interface, known to the clients, separate from the details of how the component is realized.

1.4.6. Sufficiency, completeness and primitiveness

Achieving sufficiency, completeness, and primitiveness means ensuring that a software component captures all the important characteristics of an abstraction, and nothing more.

2. Key Issues in Software Design
A number of key issues must be dealt with when designing software. Some are quality concerns that all software must address—for example, performance. Another important issue is how to decompose, organize, and package software components. This is so fundamental that all design approaches must address it in one way or another. 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 cross-cut the system’s functionality, have been referred to as aspects: “[aspects] 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, cross-cutting issues are the following (presented in alphabetical order):
2.1. Concurrency
How to decompose the software into processes, tasks, and threads and deal with related efficiency, atomicity, synchronization, and scheduling issues.
2.2. Control and Handling of Events
How to organize data and control flow, how to handle reactive and temporal events through various mechanisms such as implicit invocation and call-backs.
2.3. Distribution of Components
How to distribute the software across the hardware, how the components communicate, how middleware can be used to deal with heterogeneous software.
2.4. Error and Exception Handling and Fault Tolerance
How to prevent and tolerate faults and deal with exceptional conditions.
2.5. Interaction and Presentation
How to structure and organize the interactions with users and the presentation of information (for example,
separation of presentation and business logic using the Model-View-Controller approach). It is to be noted that this topic is not about specifying user interface details, which is the task of user interface design (a part of Software Ergonomics); see Related Disciplines of Software Engineering.
2.6. Data Persistence
How long-lived data are to be handled.

3. Software Structure and Architecture
In its strict sense, a software architecture is “a description of the subsystems and components of a software system and the relationships between them.” Architecture thus attempts to define the internal structure
— according to the Oxford English Dictionary, “the way in which something is constructed or organized” — of the resulting software. During the mid-1990s, however, software architecture started to emerge as a broader discipline involving the study of software structures and architectures in a more generic way. This gave rise to a number of interesting ideas about software design at different levels of abstraction. Some of these concepts can be useful during the architectural design (for example, architectural style) of specific software, as well as during its detailed design (for example, lower-level design patterns). But they can also be useful for designing generic systems, leading to the design of families of programs (also known as product lines). Interestingly, most of these concepts can be seen as attempts to describe, and thus reuse, generic design knowledge.

3.1. Architectural Structures and Viewpoints
Different high-level facets of a software design can and should 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”. These distinct 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). Other authors use different terminologies, like behavioral vs. functional vs. structural vs. data modeling views. In summary, a software design is a multi-faceted artifact produced by the design process and generally composed of relatively independent and orthogonal views.
Architectural Styles (macroarchitectural patterns) An architectural style is “a set of constraints on an
architecture [that] defines a set or family of architectures that satisfies them”. An architectural style can thus be seen as a meta-model which can provide software’s high-level organization (its macroarchitecture). Various authors have identified a number of major architectural styles.
- General structure (for example, layers, pipes, and filters, blackboard).
- Distributed systems (for example, client-server, threetiers, broker)
- Interactive systems (for example, Model-View-Controller, Presentation-Abstraction-Control)
- Adaptable systems (for example, micro-kernel, reflection)
- Others (for example, batch, interpreters, process control, rule-based).

3.2. Design Patterns (microarchitectural patterns)
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 (their
macroarchitecture), other design patterns can be used to describe details at a lower, more local level (their
microarchitecture).
- Creational patterns (for example, builder, factory, prototype, and singleton)
- Structural patterns (for example, adapter, bridge, composite, decorator, façade, flyweight, and proxy)
- Behavioral patterns (for example, command, interpreter, iterator, mediator, memento, observer, state,
strategy, template, visitor)

3.3. Families of Programs and Frameworks
One possible approach to allow the reuse of software designs and components is to design families of software, also known as software product lines. This can be done by identifying the commonalities among members of such families and by using reusable and customizable components to account for the variability among family members. In OO programming, a key related notion is that of the framework: a partially complete software subsystem that can be extended by appropriately instantiating specific plug-ins (also known as hot spots).

CHAPTER 2 SOFTWARE REQUIREMENTS Second Part

This is the second part of the chapter two.

5. Requirements Specification
Typical software has a large number of requirements, and the emphasis is shared between performing the numerical quantification and managing the complexity of interaction among the large number of requirements. So, in software engineering jargon, “software requirements specification” typically refers to the production of a document, or its electronic equivalent, which can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software 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.

5.1. The System Definition Document
This document (sometimes known as the user requirements document or concept of operations) 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 non-functional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios and the principal domain entities, as well as data, information, and workflows.

5.2. System Requirements Specification
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.

5.3. Software Requirements Specification
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. For non-technical readers, the software requirements specification document is often accompanied by a software requirements definition document.
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 to develop their own validation and verification plans more productively. Software requirements specification provides an informed
basis for transferring a software product to new users or new machines. 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 semi-formal 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 which allow the requirements to be
described as precisely as possible. This is particularly crucial for safety-critical 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 which can be used to relate the quality of software
requirements specification to other project variables such as cost, acceptance, performance, schedule,
reproducibility, etc. 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.

6. Requirements validation
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, and it is also important to
verify that a requirements document conforms to company standards, and that it is understandable, consistent, and complete. 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 software configuration management practices as the other deliverables of the software life cycle processes. 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).

6.1. Requirements Reviews
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.

6.2. Prototyping
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. 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, several people recommend prototypes which 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.

6.3. Model Validation
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 which, in the stakeholders’ domain, exchange data. If formal specification notations are used, it is possible to use
formal reasoning to prove specification properties.

6.4. Acceptance Tests
An essential property of a software requirement is that it should be possible to validate that the finished product satisfies it. Requirements which 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.
Identifying and designing acceptance tests may be difficult for non-functional requirements. To be validated, they must first be analyzed to the point where they can be expressed quantitatively.

7. Practical Considerations
The requirements process spans the whole software life cycle. Change management and the maintenance of the requirements in a state which 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 frequent in dynamic start-up companies, driven by a strong “product vision” and limited resources, to view requirements documentation as an 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.

7.1. Iterative Nature of the 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 which 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 software 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 which underpin the requirements, as well as any known problems.

7.2. Change Management
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.

7.3. Requirements Attributes
Requirements should consist not only of a specification of what is required, but also of ancillary information which helps manage and interpret the requirements. This should include the various classification dimensions of the requirement and the verification method or acceptance test plan. 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 which allows the requirements to be uniquely and unambiguously identified.

7.4. Requirements Tracing
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 backwards to the requirements and stakeholders which motivated it (from a software requirement back to the system requirement(s) that it helps satisfy, for example). Conversely, a requirement should be traceable forwards 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). The requirements tracing for a typical project will form a complex directed acyclic graph (DAG) of requirements.

7.5. Measuring Requirements
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. IEEE Std 14143.1 defines the concept of FSM. [IEEE14143.1-00] Standards from ISO/IEC and other sources describe particular FSM methods.

CHAPTER 2 SOFTWARE REQUIREMENTS

ACRONYMS
DAG: Directed Acyclic Graph
FSM: Functional Size Measurement
INCOSE: International Council on Systems Engineering
SADT: Structured Analysis and Design Technique
UML: Unified Modeling Language

The Software Requirements Knowledge Area (KA) is concerned with the elicitation, analysis, specification, and validation of software requirements. It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.
The Software Requirements KA is related closely to the Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, and Software Quality KAs.

1. Software Requirements Fundamentals

1.1. Definition of a Software Requirement
At its most basic, a software requirement is a property which must be exhibited in order to solve some problem in the real world. The Guide refers to requirements on “software” because it is concerned with problems to be addressed by software. Hence, a software requirement is a property which must be exhibited by software developed or adapted to solve a particular problem. The problem may be to automate part of a task of someone who will use the software, to support the business processes of the organization that has commissioned the software, to correct shortcomings of existing software, to control a device, and many more. The functioning of users, business processes, and devices is typically complex. By extension, therefore, the requirements on particular software are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the software will operate.

1.2. Product and Process Requirements
A distinction can be drawn between product parameters and process parameters. Product parameters are
requirements on software to be developed. A process parameter is essentially a constraint on the
development of the software. These are sometimes known as process requirements.

1.3. Functional and Nonfunctional Requirements
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.
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, or one of many other types of software requirements.

1.4. Emergent Properties
Some requirements represent emergent properties of software—that is, requirements which cannot be
addressed by a single component, but which depend for their satisfaction 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.

1.5. Quantifiable Requirements
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 which depend for their interpretation on subjective judgment. This is particularly important for nonfunctional requirements. 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.

1.6. System Requirements and Software Requirements
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 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.

2. Requirements Process

2.1. Process Models
The objective of this topic is to provide an understanding that the requirements process.
Is not a discrete front-end activity of the software life cycle, but rather a process initiated at the beginning of a project and continuing to be refined throughout the life cycle.
Identifies software requirements as configuration items, and manages them using the same software configuration management practices as other products of the software life cycle processes.
Needs to be adapted to the organization and project context.
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 which provide input into the requirements process, such as marketing and feasibility studies.

2.2. Process Actors
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 always  include users/operators and customers (who need not be the same).

2.3. Process Support and Management
This topic introduces the project management resources required and consumed by the requirements process. It establishes the context for the first subarea (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.

2.4. Process Quality and Improvement
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 the Software Engineering Process KA. Of particular interest are issues of software quality attributes and measurement, and software process definition. This topic covers:
- Requirements process coverage by process improvement standards and models
- Requirements process measures and benchmarking
- Improvement planning and implementation

3. Requirements Elicitation
Requirements elicitation is concerned with where software requirements come from 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 tenets of good software engineering is that there be good communication between
software users and software engineers. 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.

3.1. Requirements Sources
Requirements have many sources in typical software, and it is essential that all potential sources be identified and evaluated for their impact on it. 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 Goals, Domain knowledge, Stakeholders, The operational environment, The organizational environment.

3.2. Elicitation Techniques
Once the requirements sources have been identified, the software engineer can start eliciting requirements from them. This topic concentrates on techniques for getting human stakeholders to articulate their requirements. It is a very difficult area 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. A number of techniques exist for doing this, the principal ones being.
Interviews, Scenarios, Prototypes, Facilitated meetings, Observation.

4. Requirements Analysis
This topic is concerned with the process of analyzing requirements to:
- Detect and resolve conflicts between requirements
- Discover the bounds of the software and how it must interact with its environment
- Elaborate system requirements to derive software requirements

4.1. Requirements Classification
- Whether the requirement is functional or nonfunctional
- Whether the requirement is derived from one or more high-level requirements or an emergent property or is being imposed directly on the software by a stakeholder or some other source.
- Whether the requirement is on the product or the process. Requirements on the process can constrain the choice of contractor, the software engineering process to be adopted, or the standards to be adhered to.
- The requirement priority. In general, the higher the priority, the more essential the requirement is for meeting the overall goals of the software. Often classified on a fixed-point scale such as mandatory, highly desirable, desirable, or optional, the priority often has to be balanced against the cost of development and implementation.
- The scope of the requirement. Scope refers to the extent to which a requirement affects the software and software components. Some requirements, particularly certain nonfunctional ones, have a global scope in that their satisfaction cannot be allocated to a discrete component. Hence, a requirement with global scope may strongly affect the software architecture and the design of many components, whereas one with a narrow scope may offer a number of design choices and have little impact on the satisfaction of other requirements.
- Volatility/stability. Some requirements will change during the life cycle of the software, and even during the development process itself. It is useful if some estimate of the likelihood that a requirement change can be made. For example, in a banking application, requirements for functions to calculate and credit interest to customers’ accounts are likely to be more stable than a requirement to support a particular kind of tax-free account. The former reflect a fundamental feature of the banking domain (that accounts can earn interest), while the latter may be rendered obsolete by a change to government legislation. Flagging potentially volatile
requirements can help the software engineer establish a design which is more tolerant of change.

4.2. Conceptual Modeling
The development of models of a real-world problem is key to software requirements analysis. Their purpose is to aid in understanding the problem, rather than to initiate design of the solution. Hence, conceptual models
comprise models of entities from the problem domain configured to reflect their real-world relationships and
dependencies. Several kinds of models can be developed. These include data and control flows, state models, event traces, user interactions, object models, data models, and many others. The factors that influence the choice of model include:
- The nature of the problem. Some types of software demand that certain aspects be analyzed particularly
rigorously. For example, control flow and state models are likely to be more important for real-time software
than for management information software, while it would usually be the opposite for data models.
- The expertise of the software engineer. It is often more productive to adopt a modeling notation or method with which the software engineer has experience.
- The process requirements of the customer. Customers may impose their favored notation or method, or prohibit any with which they are unfamiliar. This factor can conflict with the previous factor.
- The availability of methods and tools. Notations or methods which are poorly supported by training and
tools may not achieve widespread acceptance even if they are suited to particular types of problems.

4.3. Architectural Design and Requirements Allocation
At some point, the architecture of the solution 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 the Software Structure and Architecture subarea 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 components that will be responsible for satisfying  the requirements be identified. This is requirements allocation–the assignment, to components, of the responsibility for satisfying requirements.
Architectural design is closely identified with conceptual modeling. The mapping from real-world domain entities to software components is not always obvious, so architectural design is identified as a separate topic. The requirements of notations and methods are broadly the same for both conceptual modeling and architectural design.

4.4. Requirements Negotiation
Another term commonly used for this sub-topic 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, and so it becomes necessary to consult with the stakeholder(s) to reach a consensus on an appropriate trade-off. 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.

Chapter 1. Introduction to the Guide Second Part

I cut the past post, because it was very long, then this is the second part with the other KAs

SOFTWARE CONFIGURATION MANAGEMENT KA

Software Configuration Management (SCM) is the discipline of identifying the configuration of software at distinct points in time for the purpose of systematically controlling changes to the configuration and of maintaining the integrity and traceability of the configuration throughout the system life cycle. This KA includes six subareas.
The first subarea is Management of the SCM Process. It covers the topics of the organizational context for SCM, constraints and guidance for SCM, planning for SCM, the SCM plan itself, and surveillance of SCM.
The second subarea is Software Configuration Identification, which identifies items to be controlled, establishes identification schemes for the items and their versions, and establishes the tools and techniques to be used in acquiring and managing controlled items. The first topics in this subarea are identification of the items to be controlled and the software library.
The third subarea is Software Configuration Control, which is the management of changes during the software life cycle. The topics are: first, requesting, evaluating, and approving software changes; second, implementing software changes; and third, deviations and waivers.
The fourth subarea is Software Configuration Status Accounting. Its topics are software configuration status information and software configuration status reporting.
The fifth subarea is Software Configuration Auditing. It consists of software functional configuration auditing, software physical configuration auditing, and in-process audits of a software baseline.
The last subarea is Software Release Management and Delivery, covering software building and software release management.

SOFTWARE ENGINEERING MANAGEMENT KA
The Software Engineering Management KA addresses the management and measurement of software engineering. While measurement is an important aspect of all KAs, it is here that the topic of measurement programs is presented. There are six subareas for software engineering management. The first five cover software project management and the sixth describes software measurement programs.
The first subarea is Initiation and Scope Definition, which comprises determination and negotiation of requirements, feasibility analysis, and process for the review and revision of requirements.
The second subarea is Software Project Planning and includes process planning, determining deliverables, effort, schedule and cost estimation, resource allocation, risk management, quality management, and plan management.
The third subarea is Software Project Enactment. The topics here are implementation of plans, supplier contract management, implementation of measurement process, monitor process, control process, and reporting.
The fourth subarea is Review and Evaluation, which includes the topics of determining satisfaction of requirements and reviewing and evaluating performance.
The fifth subarea describes Closure: determining closure and closure activities.
Finally, the sixth subarea describes Software Engineering Measurement, more specifically, measurement programs.Product and process measures are described in the Software Engineering Process KA. Many of the other KAs also describe measures specific to their KA. The topics of this subarea include establishing and sustaining measurement commitment, planning the measurement process, performing the measurement  process, and evaluating measurement.

SOFTWARE ENGINEERING PROCESS KA
The Software Engineering Process KA is concerned with the definition, implementation, assessment, measurement, management, change, and improvement of the software engineering process itself. It is divided into four subareas.
The first subarea presents Process Implementation and Change. The topics here are process infrastructure, the software process management cycle, models for process implementation and change, and practical considerations.
The second subarea deals with Process Definition. It includes the topics of software life cycle models, software life cycle processes, notations for process definitions, process adaptation, and automation.
The third subarea is Process Assessment. The topics here include process assessment models and process assessment methods.
The fourth subarea describes Process and Product Measurements. The software engineering process covers general product measurement, as well as process measurement in general. Measurements specific to KAs are described in the relevant KA. The topics are process measurement, software product measurement, quality of measurement results, software information models, and process measurement techniques.

SOFTWARE ENGINEERING TOOLS AND METHODS KA
The Software Engineering Tools and Methods KA includes both software engineering tools and software engineering methods.
The Software Engineering Tools subarea uses the same structure as the Guide itself, with one topic for each of the other nine software engineering KAs. An additional topic is provided: miscellaneous tools issues, such as tool integration techniques, which are potentially applicable to all classes of tools.
The Software Engineering Methods subarea is divided into four subsections: heuristic methods dealing with informal approaches, formal methods dealing with mathematically based approaches, and prototyping methods dealing with software development approaches based on various forms of prototyping.

SOFTWARE QUALITY KA
The Software Quality KA deals with software quality considerations which transcend the software life cycle
processes. Since software quality is a ubiquitous concern in software engineering, it is also considered in many of the other KAs, and the reader will notice pointers to those KAs throughout this KA. The description of this KA covers three subareas.
The first subarea describes the Software Quality Fundamentals such as software engineering culture and ethics, the value and costs of quality, models and quality characteristics, and quality improvement.
The second subarea covers Software Quality Management Processes. The topics here are software quality assurance, verification and validation, and reviews and audits.
The third and final subarea describes Practical Considerations related to software quality. The topics are software quality requirements, defect characterization, software quality management techniques, and software quality measurement.

Chapter 1. Introduction to the Guide

I am gonna put somethings about the first chapter, I hope that you can use it and take advantage with this material. You can see the full information in this link http://www.computer.org/portal/web/swebok/htmlformat

WHAT IS SOFTWARE ENGINEERING?
The IEEE Computer Society 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. The study of approaches as in .”

They concluded that an engineering profession is characterized by several components:
- An initial professional education in a curriculum validated by society through accreditation
- Registration of fitness to practice via voluntary certification or mandatory licensing
- Specialized skill development and continuing professional education
- Communal support via a professional society
- A commitment to norms of conduct often prescribed in a code of ethics

This Guide contributes to the first three of these components. Articulating a Body of Knowledge is an essential step toward developing a profession because it represents a broad consensus regarding what a software engineering professional should know.

The Guide to the Software Engineering Body of Knowledge (SWEBOK) was established with the following five objectives:
1. To promote a consistent view of software engineering worldwide
2. To clarify the place—and set the boundary—of software engineering with respect to other disciplines such as computer science, project management, computer engineering, and mathematics
3. To characterize the contents of the software engineering discipline
4. To provide a topical access to the Software Engineering Body of Knowledge
5. To provide a foundation for curriculum development and for individual certification and licensing material

The SWEBOK Knowledge Areas (KAs)
Software requirements
Software design
Software construction
Software testing
Software maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering tools and methods
Software quality

Related disciplines
Computer engineering
Project management
Computer science
Quality management
Management
Software ergonomics
Mathematics
Systems engineering


1. SOFTWARE REQUIREMENTS KA
A requirement is defined as a property that must be exhibited in order to solve some real-world problem.
The first knowledge subarea is Software Requirements Fundamentals. It includes definitions of software requirements themselves, but also of the major types of requirements: product vs. process, functional vs. nonfunctional, emergent properties. The subarea also describes the importance of quantifiable requirements and distinguishes between systems and software requirements.
The second knowledge subarea is the Requirements Process, which introduces the process itself, orienting the remaining five subareas and showing how requirements engineering dovetails with the other software engineering processes. It describes process models, process actors, process support and management, and process quality and improvement.
The third subarea is Requirements Elicitation, which is concerned with where software requirements come from and how the software engineer can collect them. It includes requirement sources and elicitation techniques.
The fourth subarea, Requirements Analysis, is concerned with the process of analyzing requirements to - Detect and resolve conflicts between requirements. - Discover the bounds of the software and how it must interact with its environment. - Elaborate system requirements to software requirements.
Requirements analysis includes requirements classification, conceptual modeling, architectural design and requirements allocation, and requirements negotiation.
The fifth subarea is Requirements Specification. Requirements specification typically refers to the production of a document, or its electronic equivalent, that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: system definition, system requirements specification, and software requirements specification. The subarea describes all three documents and the underlying activities.
The sixth subarea is Requirements Validation, the aim of which 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 documents to ensure that they are defining the right system (that is, the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, and model validation and acceptance tests.
The seventh and last subarea is Practical Considerations. It describes topics which need to be understood in practice. The first topic is the iterative nature of the requirements process. The next three topics are fundamentally about change management and the maintenance of requirements in a state which accurately mirrors the software to be built, or that has already been built. It includes change management, requirements attributes, and requirements tracing. The final topic is requirements measurement.

2. SOFTWARE DESIGN KA
According to the IEEE definition [IEEE 610.12-90], design is both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of [that] process.” The KA is divided into six subareas.
The first subarea presents Software Design Fundamentals, which form an underlying basis to the understanding of the role and scope of software design. These are general software concepts, the context of software design, the software design process, and the enabling techniques for software design.
The second subarea groups together the Key Issues in Software Design. They include concurrency, control and handling of events, distribution of components, error and exception handling and fault tolerance, interaction and presentation, and data persistence.
The third subarea is Software Structure and Architecture, the topics of which are architectural structures and viewpoints, architectural styles, design patterns, and, finally, families of programs and frameworks.
The fourth subarea describes Software Design Quality Analysis and Evaluation. While there is a entire KA devoted to software quality, this subarea presents the topics specifically related to software design. These aspects are quality attributes, quality analysis, and evaluation techniques and measures.
The fifth subarea is Software Design Notations, which are divided into structural and behavioral descriptions.
The last subarea describes Software Design Strategies and Methods. First, general strategies are described, followed by function-oriented design methods, object-oriented design methods, data-structure-centered design, component- based design, and others.

3. SOFTWARE CONSTRUCTION KA
Software construction refers to the detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. The KA includes three subareas.
The first subarea is Software Construction Fundamentals. The first three topics are basic principles of construction: minimizing complexity, anticipating change, and constructing for verification. The last topic discusses standards for construction.
The second subarea describes Managing Construction. The topics are construction models, construction planning, and construction measurement.
The third subarea covers Practical Considerations. The topics are construction design, construction languages, coding, construction testing, reuse, construction quality, and integration.

4. SOFTWARE TESTING KA
Software Testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior. It includes five subareas.
It begins with a description of Software Testing Fundamentals. First, the testing-related terminology is presented, then key issues of testing are described, and finally the relationship of testing to other activities is covered.
The second subarea is Test Levels. These are divided between the targets of the tests and the objectives of the tests.
The third subarea is Test Techniques. The first category includes the tests based on the tester’s intuition and
experience. A second group comprises specification-based techniques, followed by code-based techniques, fault-based techniques, usage-based techniques, and techniques relative to the nature of the application. A discussion of how to select and combine the appropriate techniques is also presented.
The fourth subarea covers Test-Related Measures. The measures are grouped into those related to the evaluation of the program under test and the evaluation of the tests performed.
The last subarea describes the Test Process and includes practical considerations and the test activities.

5. SOFTWARE MAINTENANCE KA
Once in operation, anomalies are uncovered, operating environments change, and new user requirements surface. The maintenance phase of the life cycle commences upon delivery, but maintenance activities occur much earlier. The Software Maintenance KA is divided into four subareas.
The first one presents Software Maintenance Fundamentals: definitions and terminology, the nature of maintenance, the need for maintenance, the majority of maintenance costs, the evolution of software, and the categories of maintenance.
The second subarea groups together the Key Issues in Software Maintenance. These are the technical issues, the management issues, maintenance cost estimation, and software maintenance measurement.
The third subarea describes the Maintenance Process. The topics here are the maintenance processes and maintenance activities.
Techniques for Maintenance constitute the fourth subarea. These include program comprehension, re-engineering, and reverse engineering.

SWEBOK

Debido a que es un libro de gran importancia para los que tienen que ver con desarrollo de software, voy a ir poniendo algunos apartes de éste.