1. Emergence of Software Engineering In the software industry, we have seen the complexity of computer-based systems increase dramatically over the past decades along with advances in technology. This new technology has increased the demand for computer-based systems to control many infrastructures with software. As a result, designing and building cost-effective, reliable, and high-quality software has become the focus of software engineering in the computer industry. In the past the processes used for designing and developing software were very informal, which contributed to the rise in development and maintenance costs. The results of ad hoc development processes contributed to a higher percentage of unreliable and lesser quality products entering the marketplace. Many accidents resulted from failures in computer-based systems with hardware devices that were controlled with software. At the time, the industry was considered to be in a crisis state, which then led to the emergence of new practices and methods in software engineering. Technological advances have had a big impact on the complexity level required in software systems. The emergence of new communication protocols, hardware devices, and graphical user interface components have placed a greater demand on software engineers to design quality, reliable, and safe software. A Brief History of Software Engineering In the 1950s and the early 1960s, the various engineering disciplines were beginning to analyze how aspects of the engineering field could be applied to methods used in developing software products. As computing power evolved over the decades, the demand increased along with the complexity of the problems that needed to be addressed in the design of software. The term software engineering was introduced in 1968 at the first international software engineering conference, held by the North Atlantic Treaty Organization (NATO) Science Committee (Mahoney 2004). Many practitioners believe this is the milestone that marked the emergence of the software engineering discipline. Software was developed to control critical hardware devices in the mid- to late-1960s and early 1970s. During this time, cases emerged that involved operational errors and accidents resulting in the loss of human lives and damage to property. Defects in software were uncovered, which heightened public awareness to the need for better quality and reliability of software. The escalating cost of building quality and reliable software was on the rise in the computer industry and the demand for skilled programmers could not be met. The state of software development was viewed by practitioners as being in a "crisis" state and was commonly referred to as the software crisis. In response to the software crisis, researchers and practitioners have been trying to develop a set of methodologies, processes, and tools as the "silver bullet" for building software. The combination of these methodologies, processes, and tools i ...

1. 1. Emergence of Software Engineering
In the software industry, we have seen the complexity of
computer-based systems increase dramatically over the past
decades along with advances in technology. This new
technology has increased the demand for computer-based
systems to control many infrastructures with software. As a
result, designing and building cost-effective, reliable, and high-
quality software has become the focus of software engineering
in the computer industry.
In the past the processes used for designing and developing
software were very informal, which contributed to the rise in
development and maintenance costs. The results of ad hoc
development processes contributed to a higher percentage of
unreliable and lesser quality products entering the marketplace.
Many accidents resulted from failures in computer-based
systems with hardware devices that were controlled with
software. At the time, the industry was considered to be in a
crisis state, which then led to the emergence of new practices
and methods in software engineering.
Technological advances have had a big impact on the
complexity level required in software systems. The emergence
of new communication protocols, hardware devices, and
graphical user interface components have placed a greater
demand on software engineers to design quality, reliable, and
safe software.
A Brief History of Software Engineering
In the 1950s and the early 1960s, the various engineering
disciplines were beginning to analyze how aspects of the
engineering field could be applied to methods used in
developing software products. As computing power evolved
over the decades, the demand increased along with the
complexity of the problems that needed to be addressed in the
design of software. The term software engineering was
introduced in 1968 at the first international software

2. engineering conference, held by the North Atlantic Treaty
Organization (NATO) Science Committee (Mahoney 2004).
Many practitioners believe this is the milestone that marked the
emergence of the software engineering discipline.
Software was developed to control critical hardware devices in
the mid- to late-1960s and early 1970s. During this time, cases
emerged that involved operational errors and accidents resulting
in the loss of human lives and damage to property. Defects in
software were uncovered, which heightened public awareness to
the need for better quality and reliability of software. The
escalating cost of building quality and reliable software was on
the rise in the computer industry and the demand for skilled
programmers could not be met. The state of software
development was viewed by practitioners as being in a "crisis"
state and was commonly referred to as the software crisis.
In response to the software crisis, researchers and practitioners
have been trying to develop a set of methodologies, processes,
and tools as the "silver bullet" for building software. The
combination of these methodologies, processes, and tools is
what comprises the field of software engineering, which
continues to emerge today.
The software crisis can be summed up in economic terminology:
there is a greater demand for software than there is a supply.
The software in question is custom software written to solve
large, unique data-processing problems. Usually, the small
ubiquitous problems can be addressed by some combination of
commercially available software products, such as word
processing programs, spreadsheets, and so on. But these types
of problems are not the focus of this course. Our focus instead
is on large, unique problems that require custom software
solutions.
Software Engineering Defined
To fully understand the definition of software engineering, we
need to define what is meant by the term software. Software is
much more than just the code of a computer program. Software
is accompanied by a set of documentation that is necessary to

3. describe the details of the requirements, design, and any
external aspects of the software that are necessary for it to
execute successfully. These documents include any
configuration files and any aspects of the external environment
that surround the building and use of the software. We can refer
to these items as a collective whole, the software system or the
software configuration.
Software has unique characteristics that differ from hardware,
which is manufactured and tangible. Software is abstract and
intangible and is not manufactured or governed by physical
laws. Creative programming solutions are required by humans
because software is developed from a conceptual idea. There are
four characteristics that best describe software: its
maintainability, dependability, efficiency, and usability. These
characteristics are inherent of the design process that was used
to build the software. The uniqueness of programming solutions
makes these characteristics difficult to measure.
In order to build software, we use processes to address a unique
problem to be solved or a particular need to be satisfied.
Software engineering focuses on improving these processes to
build a better quality and more reliable product. In early times
these processes were often ad hoc and chaotic and resulted in
poor quality and unreliable software that was expensive to
maintain after deployment. The rising cost of maintaining
software was very expensive and unacceptable by software
companies. The ultimate goal of good software engineering
methodologies is to reduce these maintenance costs by building
a better product earlier in the development phases of the life
cycle.
To define software engineering, we can look at the definition
provided by the Institute of Electrical and Electronics Engineers
(IEEE, 1993)
1. The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is the application of engineering to software.
2. The study of approaches as in 1.

4. The IEEE refers to a "systematic, disciplined, and quantifiable"
approach to developing software that can be measured for
effectiveness to allow for continuous improvement. As we
mentioned earlier, software is intangible and developed from a
conceptual idea. However, not all software teams may be
receptive and suitable to follow a strict disciplined process.
Pressman (2005) stresses that a process needs to be designed to
foster creativity and to be adaptable and agile to change.
It should be noted that the IEEE definition does not provide the
technical "how tos" to build software. In order to build quality
software, companies need to be committed to developing sound
processes, which requires the establishment of a set of methods
and tools. When we develop these processes we also need to
consider support for the business needs of the organization or
company.
If you search the Internet you can find a variety of automated
tools that have been developed to provide support for software
processes and methods. These tools are referred to as computer-
aided software engineering (CASE) tools. CASE tools have
been designed to ease software development and to allow for
integration of information from one process to another. It is
important to understand that complex processes rely on
individuals' judgment and creativity, so not every process can
be automated by using a CASE tool. We will elaborate more on
CASE tools in section 3.
Social and Ethical Responsibility
Software engineering is a respected profession and engineers
are expected to use good judgment when developing software
products. Software engineering is no different than any other
engineering discipline. Software engineers are bound by the
constraints of the legal and social framework when developing
software (Sommerville, 2004).
Software engineers possess technical skills and they need to use
them in an honest and moral way when developing software
products. Applications to solve a wide range of problems are
created and used in society, and society expects the software to

5. be correct and of high quality. Companies entrust engineers
with their assets and private data. It is the responsibility of the
software engineer to maintain professionalism in the areas of
confidentiality, competence, intellectual property rights, and
computer misuse (Sommerville, 2004).
Professional software engineers are encouraged to join
organizations in which ethical standards are established. The
Association for Computing Machinery (ACM) and IEEE are
known for establishing rules of professional conduct and ethics.
2. Introduction to Systems Engineering
In this section we will define system engineering and list some
of its distinct characteristics. To help you understand the
development of the software component within the system
framework, we will introduce the basic system life cycle model.
Because software requirements are derived from system
requirements, we will introduce the System Specifications
document.
Definition of System Engineering
The basic definition of system engineering (Blanchard, 1998, p.
12) is:
… the effective application of scientific and engineering efforts
to transform an operational need into a defined system
configuration through a top-down iterative process of
requirements analysis, functional analysis and allocation,
synthesis, design optimization, test and evaluation, and
validation.
This definition highlights the various phases in the life cycle of
a system, which we will discuss further in the next section.
The Department of Defense (1996) defines system engineering
as the … process that shall:
· Transform operational needs and requirements into an
integrated system design solution through concurrent
considerations of all life-cycle needs (i.e., development,
manufacturing, test, and evaluation, verification, deployment,
operations, support, training, and disposal).
· Ensure the compatibility, interoperability, and integration of

6. all functional and physical interfaces and ensure that system
definitions and design reflect the requirements for all systems
elements (i.e., hardware, software, facilities, people, data).
· Characterize and manage technical risks.
The Department of Defense's definition is similar to the one
provided by Blanchard in mentioning the life cycle, but it also
stresses risk-management activities as a separate process.
System Engineering Characteristics
System engineering has distinct characteristics (Stevens, n.d.)
that make its life cycle unique from software engineering:
· handles communication among disparate disciplines, each with
its own technical language
· is primarily a project management activity
· deals with multiple semi-independent subsystems
· deals with engineering requirements, constraints for hardware
· is difficult to change
· has mechanics and architecture that make progress easier to
measure
· is unlikely to require taking as many risks
· has a concrete working environment dependent on hardware
· has components that are manufactured or replicated and that
can be damaged
· has upgrades requiring physical contact to implement because
systems contain tangible components
· has development costs that are easier to determine
· has the primary maintenance goal of returning to its original
state by repairing units
If we think of system engineering from the perspective of
hardware, these characteristics can be easily understood. After
all, hardware is tangible, and it can be manufactured.
System Boundaries and Environment
Before we discuss the life cycle of a system, we need to define
what is meant by a system that involves one or more computers
and software. The term system is used loosely in society to
define systems that emerge from organizations and institutions,
systems that consist of hardware components, and systems that

7. consist of hardware and software components. Local and federal
governments are often referred to as a system. We also refer to
various institutions, the educational system, and the financial or
banking system. Hardware systems involve mechanical parts
that work together to perform a specific task; power tools are
good examples. Systems that contain both hardware and
software components are best described as integrated
subsystems that work together to accomplish an objective.
Sommerville (2004, p. 21) defines a system as "a purposeful
collection of interrelated components that work together to
achieve some objective." The focus of our systems engineering
discussion will be on systems that contain hardware and
software components, or subsystems, which are interrelated. An
example is a self-service checkout system that is used in stores
by customers to purchase items.
A system operates within a set of boundaries and limitations
unique to its overall environment. These are not considered part
of the overall system itself, but the mechanisms and constraints
can affect the system state at any given time. Anything that
crosses the system boundary is defined as the system's distinct
set of inputs and outputs. The following diagram demonstrates
these relationships.
Click on each item in figure 1.1 to read its description and see
some examples.
Figure 1.1
The System Environment
As you review the contents of this diagram, remember that a
system has a designated purpose and it responds to an identified
need. Further analysis of any system will result in a unique set
of inputs, outputs, and external constraints that are imposed on
the system, as well as the required mechanisms to achieve the
desired results. This system framework contains all the
necessary products and processes to fulfill the intended need.
Systems are functionally dependent on their physical and
organizational environment. It may also be the intent of the

8. system to change its environment.
System Components or Subsystems
Functionality within a system is performed at the component
level. A component can also be referred to as a subsystem.
Components require the involvement of engineers from different
disciplines working together to perform all the necessary
functions required within the entire system. Interdisciplinary
involvement consists of engineers from the software,
electronics, mechanical, structural, civil, human factors,
environmental, and architectural disciplines. Domain specialists
and representatives from the user community should work with
the engineers. The complexity level of the system, required to
satisfy the functionality, determines both the number of
subsystems and the interrelationships of the disciplines
necessary to satisfy the system requirements.
The diagram below shows the various components of a system.
Figure 1.2
Components of a System
Relationships between subsystems are defined in their
interfaces. These interfaces need to be defined at the system
level.
System Life Cycle
Now that we have defined a system as integrated hardware and
software components working together in its environment to
fulfill an objective, we will discuss its life cycle. The basic life
cycle of a system begins with identification of a need to be
fulfilled through the system's development, implementation, and
retirement phases. The various stages of the system life cycle
are identified in figure 1.3.
Figure 1.3
System Life Cycle
In order to develop software, it is necessary to understand how
the software interacts with the hardware to fulfill the need or
objective of the system. The role and boundaries of the software

9. subsystem need to be well-defined within the system
framework.
To satisfy the need for the system, a solution is established and
presented to the customer in a document called the system
specifications (SS). The SS describes what is needed by the
system, its subsystems, and the interfaces that need to exist
between the subsystems and other systems. When the SS is
complete it is submitted to the customer for approval. Once the
SS is approved by the customer, the life cycle for each
subsystem can independently commence. In figure 1.4, we
illustrate the parallel development cycle of hardware and
software subsystems.
Figure 1.4
Parallel Development of Hardware and Software Subsystems
System Specifications
In figure 1.4, we can see that the SS outlines the "top-level"
requirements for the overall system. Defining the requirements
for the software subsystem can commence after the system
requirements are agreed upon by the stakeholders and the
engineers. Subsequent development phases of software and
hardware can continue in parallel and then be integrated for
testing on a scheduled date as a whole working system.
Integration of software and hardware can take months, even
years, depending on the size and complexity of the system.
Development of a project begins at the system level by stating
its desired function. The functionality of the system is relayed
to designers as a set of requirements that address the question
"What is this system supposed to do?" At this point in the
development life cycle, the system is viewed as a whole
working unit encompassing the software and the hardware.
System engineers are responsible for defining the requirements
and the interfaces for the whole system and designing the
components of the system operations. The System
Specifications document is prepared by the engineers, and it
defines the architecture, the functional and non-functional

10. requirements, and defines the necessary interfaces between all
the components. We will concentrate on the required interfaces
between the software and hardware components in the
architecture for a self-service checkout system.
We view a system as a conceptual model. Consistency and
communication are the goals of the specifications phase in the
system life cycle. General guidelines for the SS include:
· stating the goals of the system
· defining the system boundary, which includes any constraints
imposed on the system
· specifying the inputs and outputs
· identifying the various components
· defining the structure
· specifying any interactions between the components
· identifying any safety concerns
Upon its completion, the SS document is submitted, reviewed,
revised, and approved by all of the stakeholders and serves as
the basis for the top-level design that defines the system
architecture.
Architectural Diagram
The basic process for gathering system requirements consists of
effective communications between the customer and the
technical community and a thorough understanding of the
environment in which the system is to operate. To illustrate the
system and its environment, a top-level architectural diagram is
used. Pressman (2005) describes the architectural context
diagram (ACD) as a block diagram that represents the flow of
information into and out of the system. Refer to the following
diagram to view a graphical representation of a self-service
checkout system as seen in Wal-Mart and major grocery store
chains.
Figure 1.5
Architectural Context Diagram of Self-Service Checkout System
Figure 1.5 represents all the external entities (shown as
rectangles) or terminators and the necessary relationships to

11. produce a working checkout system. The proposed software
subsystem is placed in the middle of the diagram (shown as a
circle) surrounded by the external entities. The software
subsystem is treated as a black box, without regard for the
internal workings. The connecting lines with directional arrows
reflect the expected flow of data inputs and outputs between the
external entities and the software component. You should note
that each directional line has a label describing the data flow or
object. Proper labeling of all inputs and outputs at the system
specifications stage will form the foundation for subsequent
definition of the operational scenarios and data objects during
software requirements development. We will discuss operational
scenarios later in this module and data objects in modules 2 and
3.
IEEE Guide for Developing System Requirements
Specifications
The IEEE has provided some guidelines for writing a System
Specifications document in the IEEE Guide for Developing
System Requirements Specifications, IEEE Standard 1223a-
1998. Later in this module we will discuss diagrams that can be
used to graphically represent information that needs to be
included in the SS. The use of diagrams is recommended in
technical documents and all diagrams should be supplemented
with a textual description.
3. Software Process and Product
In this section we will study the discipline of software
engineering by reviewing the development process and the
software product. There are many software products, with code
being just one of them. Process and product are really two sides
of the same coin. The goal of the process is the product, and
there's no product without the process. To accommodate the
differing roles of software products, we will study several
process models that vary the sequence and frequency of the
basic tasks of software development. The basic tasks, however,
are invariant and are illustrated below in one of the predominant
software development processes, linear-sequential:

12. Roger Pressman defines a software process as "the approach
that is taken as software is engineered" (Pressman, 2005, p. 21).
This approach includes all the technical methods and automated
tools that create the process used to make a complex software
product. You should keep in mind that a well-designed process
is customized to be applicable to the developer's work culture
and to stimulate creativity and support business decision
making. One process does not fit all projects.
As you can imagine, many activities are involved in engineering
software products. These activities include more than just the
development cycle of software, analysis, design, code, and test.
To convey these activities, Pressman outlines a framework to
form a foundation for a complete software process for any
project (Pressman, 2005, pp. 22-23). This common process
framework provides support for umbrella activities and is
outlined below in figure 1.6; it is applicable to all types and
sizes of projects.
Figure 1.6
Process Framework with Umbrella Activities
You should note that the most important element of this
framework is communications. It is essential for effective
communication to be present in all activities used in the phases
of the life cycle of software.
Process Improvement
Organizations that develop software products need to improve
their development process for several reasons. The demand for
software today requires high-quality systems to be delivered to
the customer at a low cost and within a specified time frame.
The organization is faced with challenges to meet this demand
and to produce software products within tight constraints. A
greater challenge exists for the development of the safety-
related system because software and project risk factors can
impede the completion of the final product. There is no
guarantee that a software system can be 100 percent safe and

13. reliable, but studies have shown that implementing a good
technical and management process in the development life cycle
can help reduce the chance of software and project failures.
At this point in our discussion, let's define a process and its
maturity in the context of the development of a software
product. A process is best described as the means used to bring
together the necessary knowledge that is integrated into the
final product (Pressman, 2005). This definition includes the
means of communication and the software tools used to aid in
this knowledge integration. Maturity of a process describes the
effectiveness of the means that are being used.
Process Improvement Models
Organizations can improve their technical and management
process and lower their risk factors by following the guidelines
of the Capability Maturity Model Integrated (CMMI) process
improvement model. We will discuss how this model can help
organizations achieve a higher level of process maturity.
A process improvement model offers a framework for assessing
the current state of an organization's way of developing
software. This blueprint of effective activities is used to
evaluate the current state of the process and to offer a baseline
for improvement to reach a higher level of maturity.
The underlying premise of process improvement is based on
Total Quality Management principles that were taught by
Shewhart, Juran, Deming, and Humphrey (1989). These
principles stress the importance of the process that is used to
develop and maintain a product. The process used to develop
the product will determine its overall quality; if a high-quality
process is used in software development, the product will also
be of high quality.
Figure 1.7 illustrates the relationship between process
improvement and a process model.
Figure 1.7
Achieving Process Improvement
Phillips (2003) provides several reasons why process models

14. should be used by an organization or company that develops
software:
· to set process improvement objectives and priorities
· to improve the current process
· to provide guidance to achieve a mature process
A process model can only offer guidance on what to do to
improve maturity of the process. No specific direction is given
on how to actually do it (Phillips, 2003). Each organization
must customize its activities according to its business objectives
and the type of product it produces. It should be noted that
process models vary and not all guidelines may be applicable to
a particular project or application.
To help select a process model, Pressman (2005) recommends
making the process model decision based on several factors:
· the nature of the project and application
· the methods and tools to be used
· the required controls and deliverables
Humphrey (1989) further defines a software process as all the
tools, methods, and practices that are used in the creation of the
software product. Some examples of activities that are used in a
process during the development life cycle are:
· software quality assurance
· configuration management
· project management
· subcontract management
· requirements management
You will notice Humphrey has highlighted activities in the
software process that are relative to managing the software
system or software configuration.
A summary of benefits (Phillips, 2003) derived from studies on
organizations that have followed process models are categorized
as improvements in the following areas:
· predictability of schedules and budgets
· development cycle time
· productivity levels
· quality (measured by the number of defects)

15. · customer satisfaction
· employee morale
· return on investment
· cost factor of quality
Process Assessment
To assess an organization's software process, all activities used
in building the product must be evaluated against a set of
standards. These standards provide guidance because the
process used in defining the standards has been proven effective
over time. Successful evaluation of process maturity is achieved
by following a framework that can offer direction to the
organization and its internal operations. Standards provide a
gauge that can be used to determine whether the process is in
compliance with the standard.
Process assessment is used by organizations and companies in
different ways:
· to determine the capability of a development organization in
the selection process
· to determine the organization's capability to keep in line with
its business aims
To summarize our discussion on process improvement,
companies can use process assessment as an evaluation tool or
incorporate it into their internal operation. The selection of a
development organization to build software is a very important
task, especially for systems that contain safety-critical
components. Companies can also adopt process assessment to
determine their capability to stay in line with their business
aims, to stay marketable.
Capability Maturity Model
In 1984, Carnegie Mellon University, in response to software
needs in the Department of Defense (DOD), formed the
Software Engineering Institute (SEI). The SEI developed the
Software Process Maturity Model as part of its early work at the
DOD. In 1986, the SEI initiated the Software Capability
Evaluation (SCE) project as requested by the United States Air
Force (Humphrey, 1992). After several more years of

16. refinement, in 1991, the SEI developed the Capability Maturity
Model (CMM) at Carnegie Mellon to denote a class of maturity
models.
Over the years, the SEI has revised the CMM based on new
knowledge acquired from studies conducted on private industry
and government. This new knowledge was compiled based on
process assessments, capability evaluations, and feedback
submitted by the participants in the studies. The conceptual
framework for the CMM was developed by Watts Humphrey,
who acted as the advisor during the refinement process of the
model (Paulk et al., 1993).
In December 2001, the Software Engineering Institute released
the Capability Maturity Model Integrated (CMMI), which was
an upgrade from the CMM. The CMMI is currently being
supported by the SEI and followed by organizations and
companies in the computer industry.
In module 5 we will discuss project management issues,
continue our discussion on process improvement, and take a
closer look at the key activities involved in CMMI.
Computer-Aided Software Engineering (CASE)
In this section we will introduce computer-aided software
engineering tools (CASE) that were developed to support
process activities. We will discuss the different types of CASE
tools that are available to automate process activities by
classifying them according to functionality. It should be noted
that many tools exist in the marketplace and some of these
packages contain a full set of tools to support multiple
functions.
Types of CASE Tools
The software development process is information-intensive. The
information generated takes different formats as software
development progresses through the tasks of analysis, design,
code, and test. Much of the information is textual, e.g.,
requirements, design descriptions, source code, test case
descriptions, and so on. The remainder of the information is
either graphical or binary, e.g., data flow diagrams (DFDs),

17. entity-relationship (E-R) diagrams, state-transition diagrams
(STDs), flowcharts, executable code, and so on.
For large systems, the amount of information that must be
created, managed, controlled, and evaluated is far too great for
developers to manage with paper and pencil. For this reason, the
use of automated tools to assist in the development of software
is crucial. Tools used for this purpose are called CASE
(computer-aided software engineering) tools.
If you search the Internet you will discover that CASE tools are
available for nearly every aspect of software development. To
keep them straight, it is useful to view them in taxonomy.
Sommerville (2004, p. 87) organizes tools by their specific
function or utility. Read through these descriptions and identify
their different roles in development. Note that these functions
cover the range from documentation to support for testing. The
sale of such tools is an active and important marketplace,
essential for modern development projects. Care must be
exercised to select those tools most suitable for the project at
hand. An inappropriate tool can do more harm than good by
diverting effort from development.
Figure 1.8
CASE Tools Classified by Functionality
Most CASE tools available today handle one or more different
formats and support one or more development tasks, but fall
short of supporting all tasks across the life cycle. For example,
several commercial database front-end application programs
assist in developing schema code. The software engineer defines
the data schema (i.e., data model) either textually or
graphically. The CASE tool will automatically generate the
executable code to implement that schema. This CASE tool
manages both textual and binary information formats, but only
for the design and coding tasks, not for analysis or test.
One common perception is that the selection and use of a CASE
tool will solve any problems associated with development.
Unfortunately, nothing could be further from the truth.

18. Although a tool can help to develop a product, and whereas not
using tools can doom a project to failure (particularly if the
system under development is large and complex), simply
providing tools, by itself, is not sufficient to ensure success.
The tools must be properly used in conjunction with a
disciplined process.
In module 5, we will discuss CASE tools and how they can be
used to support project management activities.
Integrated CASE Environments
The use of individual CASE tools can provide significant help
to the software engineer, but the process of getting the tools to
work together can sometimes be a difficult and frustrating task.
If the tools work with different file formats, perform different
functions, and execute on different machines, the engineer is
left with having to expend extra effort just to coordinate the
tools and their outputs. If, however, the tools can be integrated
in some way so that they work together seamlessly, with
compatible interfaces, then the engineer's job is made much
easier and he or she can focus on the creative aspects of
development. Specifically, the challenge is to integrate the
various CASE tools together into a single capability, i.e.,
integrated case (I-CASE).
CASE tool interface protocols and input and output data formats
must be standardized to permit individual CASE tools to
communicate with each other. Integrating frameworks has
evolved as an answer to the CASE tool communication problem,
but the actual data formats and interface protocols have not yet
been fully defined and standardized.
One key concept that is necessary to achieve I-CASE is that of
the CASE repository. For individual CASE tools to share
information during the software development process, each tool
will require access to the outputs of the other CASE tools. One
potentially effective approach to achieving this goal is to store
the outputs of the CASE tools in a central location called a
repository.
If, in addition to the collocation of CASE tool data, the CASE

19. repository can be built with common protocols and data
formats/conversions, then the CASE repository will serve as an
integrating framework and be of even more assistance to the
developers. Current industry publications that discuss "object
repositories" and "object-bases" are really referring to the
concept of CASE repository, in which information in different
formats is stored centrally for access by any interested
application program. For this discussion, the interested
application program is the CASE tool.
4. Software Process Models
So far in our discussion we have introduced the concept of
producing a high-quality software product by improving the
activities used in the development process. In this section we
will look closer at the various process models being used today
in the computer industry. These process models have formed the
basis for emerging process models, for example agile
methodology, which we will discuss separately in section 5. As
you read through this section, you should notice that all the
process models have a variation of the basic tasks used in
development: analysis, design, code, and test.
Life Cycle of Software
The full life cycle of a software system begins with its initial
concept and ends with its retirement from service. Each step of
this life cycle requires one or more activities to occur for the
product to be completed successfully. To direct the processes
within the development life cycle, the project manager selects a
model that best describes the flow of the tasks needed within
the project.
The IEEE (1996) generically describes a software life cycle
model as a "framework that contains all the necessary
processes, activities, and tasks to develop, to operate, and to
maintain a software product" from the point of conception to
termination of its use.
All life cycle models used in software development contain the
following core components, as outlined by Christensen and
Thayer (2001):

20. · a description of the major development phases
· a detailed description of the major processes and activities for
each phase
· a specification of the products and inputs for each phase
· a mapping of the activities to a framework
Basic Life Cycle Models
There are different types of life cycle models that exist for the
development of software. The basic ones are listed below. Move
your mouse over the highlighted words to see a brief
description.
· linear sequential
· prototyping
· evolutionary
· rapid application development
· component-based
To complete this section we will expand our process model
discussion and look at some specific models. You are
encouraged to do research on the Internet to learn more about
the various development models in software engineering.
Waterfall Model
The classic linear-sequential life-cycle model for software
engineering is sometimes referred to as the waterfall model. The
basis of the waterfall model originated in the late 1960s to
address needs for a complex military software development
(Baird, 2002). The waterfall model consists of a systematic
sequential approach to software development that begins at the
system level and progresses through several phases or steps. At
each phase or step it is recommended that one or more technical
documents be produced as products that are completed and
"signed off" before continuing on to the next phase
(Sommerville, 2004). In 1970, Royce introduced the model
following an iterative approach to software development in
which he stressed the importance of documentation at each step.
In Royce's paper, he also argued that the waterfall model was
flawed and needed strengthening by providing additional
supporting development steps to make it less risky.

21. In figure 1.9, we can trace through the phases of the life cycle
and view the major supporting technical documentation
proposed by Royce. You should note there can be several
documents produced at each phase. We have only mentioned the
major documents to help guide you through the phases in the
life cycle and to guide you through your course assignment. We
will discuss the software requirements specification, design
document, and test specifications throughout the subsequent
modules in this course.
Figure 1.9
Waterfall Model and Major Technical Documents
The lack of feedback between each phase and in getting the
approval for each document of the life cycle has proved to be
costly and has required a significant amount of rework when
changes were introduced during later phases. For these reasons,
the waterfall model is best suited for projects in which
requirements are stable and well-defined (Sommerville, 2004, p.
67). Introducing changes late in the life cycle is difficult due to
the sequential nature and dependency of phases followed in the
waterfall model.
The waterfall model is the oldest and most widely used
paradigm in the industry and is known to have inherent
deficiencies. To address the deficiencies in the waterfall model,
hybrids have been emerging over the decades that address:
· iteration of phases
· difficulty in getting all the requirements up front
· lateness of working product
Boehm's Spiral Model
In this section we will discuss the evolutionary process model
called Boehm's Spiral Model. The spiral model is highly
recommended to guide the development processes necessary to
produce high-quality, safety-critical software.
Dr. Barry Boehm was the founder of the spiral model that
emerged in the software industry in 1988. A major feature of
the spiral model is its iterative development and linear

22. sequential nature. Each cycle of the development process is
fully evolved and results in a new software release or build
before the next cycle commences.
The basic philosophy of each cycle in the development process
is based upon the principles of problem solving as outlined in
Polya's (1957) approach and as summarized in figure 1.10.
Figure 1.10
Polya's Approach to Problem Solving
Boehm identifies four phases in the spiral model to encompass
the basic principles of Polya's problem-solving approach. Each
phase of the model is entered multiple times in a sequential
fashion as the spiral continues to revolve. The activities within
each iteration or cycle are completed and used as the foundation
for the next iteration. Refer to figure 1.11 to see the basic
layout of Boehm’s spiral model (1988).
Click on each phase label to review its relevant activities.
Figure 1.11
Basic Layout of Boehm's Spiral Model
Phase IDetermine Objectives, Alternatives,
and
Constraints
Phase IVPlan
Phase IIEvaluate Alternatives
Phase IIIDevelop
and Verify
The spiral model is especially applicable for safety-critical
software development because it provides a risk evaluation and
analysis phase that is periodically visited throughout the
development life cycle.
The spiral model can be used to perform periodic risk
identification through the development and analysis of
prototypes. The function-oriented nature of the spiral model
supports parallel development of software modules by a team of
programmers. The underlying concept of developing prototypes

23. minimizes the overall risk factors by ensuring that the software
requirements are stable.
The spiral model offers a workable framework to support the
development of the system's hardware and the software
components. Addressing risk periodically throughout their
development cycles supports the elimination of unattractive
alternatives early in the project, which will help keep the
associated project costs down.
We have outlined the various phases of the spiral. The spiral
model has been used extensively in the development of defense
systems, but because of the high cost and time factors, it hasn't
been used extensively in private industry. Therefore, the spiral
model is being proposed only for extreme cases in which the
customer is willing to pay the cost of developing a secure
safety-critical system.
Rapid Application Development (RAD) Model
The Rapid Application Development approach to building
software stresses incremental development and a short time to
market. The concept of incremental software releases is used to
deliver a product to the customer for evaluation and to plan for
the next software release.
To gain a better understanding of a RAD approach, we can
examine evolutionary prototyping, which delivers a system with
functionality that can be used by the end-users. In order to build
the initial prototype, parts of the system's requirements need to
be clearly understood by the customer, developer, and the end-
user. The prototype's functionality evolves with each release as
the requirements for new features become fully defined.
Prototypes can be used by the customer to discover new
requirements for additional functionality or features. The main
advantage of the evolutionary approach is to provide a means
for the end-users to try out the system. The software engineers
can also benefit because the prototype provides insight on how
the end-user will use the system.
The evolutionary prototyping model stresses incremental
software releases. A software release, sometimes referred to as

24. a build in the industry, is identified with a version number. The
version number is assigned sequentially to identify the
difference in functionality from the previous release. Each
version refines the requirements for additional functionality. It
should be noted that the system following the evolutionary
model is not complete when first released to the end-user until
the requirements are finalized between the developer and
customer.
Gradually building the system is suitable for systems in which
specifications are difficult to fully define at the beginning of
the life cycle. The evolutionary prototyping model stresses
making changes quickly and demonstrating them to the
customer and the end user in several revisions.
Rational Unified Process (RUP)
As you learn more about software engineering you will
encounter many different processes and methodologies being
used in the industry. In this section we briefly mention one
methodology, the Rational Unified Process (RUP). RUP is a
popular process that was developed to provide a disciplined
approach to software development in large organizations. RUP
is incorporated into IBM's Rational software (IBM Rational
Unified Process), which uses the Unified Modeling Language
extensively as a tool for supporting communications throughout
the life cycle of software. RUP can be noted for its focus on
risk reduction in projects by using an iterative development
methodology (Baird, 2002). RUP portrays a flavor of the
traditional waterfall model because support documentation plays
an important role in its processes.
Code-Fix Approach
To complete our discussion of common approaches used in
software development, we will mention the code-fix approach,
sometimes referred to as the build-and-fix approach. The code-
fix approach is not recognized as a software engineering
methodology (Baird, 2002) but it does exist in the computer
industry and you should be able to recognize it.
The code-fix approach commences from an ill-defined set of

25. requirements received from the customer. The developer
attempts to satisfy the requirements in a quick fashion by
coding software that is presented to the customer for feedback.
The developer proceeds in the development by providing fixes
to the software and repeating this cycle until the customer is
satisfied with the software product. Practitioners question the
quality and scalability of the final product (Baird, 2002). Often
"spaghetti" code results from the code-fix approach and the
code is often not documented and is difficult to maintain or
change.
5. Agile Approach to Software Development
In this section we will discuss a new approach to software
development. The agile approach was conceived in response to
weaknesses discovered in earlier software development
practices and was spurred by the Internet. The growing trend for
web applications heavily influenced the need for agility in a
development approach. The nature of web programming requires
flexibility to adapt and respond to continuous and quick changes
in requirements and design. In our discussion on the traditional
waterfall model, we mentioned that stability in requirements
was necessary and changes were hard to accommodate.
Therefore, this inflexibility to allow change has led researchers
to develop a more agile model to accommodate development of
applications for the web.
The next section of this module will discuss a popular agile
process model, Extreme Programming, which can be used for
projects that require flexibility to adapt to a changing
requirement environment.
Extreme Programming (XP)
Extreme Programming (XP) has been emerging since the late
1990s as a proposed solution for small- to medium-sized teams
developing projects with continuously changing requirements.
The basic philosophy of XP is built from a set of values,
principles, practices, and activities (Baird, 2002) that are
outlined in figure 1.12 to produce high-quality software
products.

26. Figure 1.12
Extreme Programming Philosophy
In figure 1.12 we can see a set of values that is used to establish
the overall tone throughout the XP development process. The
focus of XP is to keep the design and structure as simple as
possible to avoid adding unnecessary features to the software
and to limit documentation. Because support documentation is
kept at a minimum, it's necessary to establish two-way
communication between all involved parties. It is preferred that
the customer be located on-site so that the means of
communication can be oral. Informal means of communications,
such as daily stand-up meetings, are used to transfer
information between parties. Written documents, reports, and
plans are kept at a minimum to save time and effort. Quick and
constructive feedback from the customer is encouraged, which
builds confidence among the team members. The confidence
level of the team fosters quick redevelopment when needed to
keep activity moving forward.
The strength of the XP methodology is found in several
principles that are used to direct developmental activities. We
mentioned feedback and simplicity in XP values but now we
will extend these to include short feedback loops and to limit
the design to a current iteration. The way in which changes in
requirements are handled is the most notable difference in XP
as compared to traditional approaches to development. XP
encourages small and frequent changes to address and resolve
problems as they occur. It’s easy to understand how this
philosophy plays an important role in developing applications
for the web, because the Internet environment is constantly
changing. The principles of XP contrast with the traditional
philosophies but the focus is the same – to produce a quality
product. XP focuses on quality of work by concentrating on the
coding and testing activities.
We will now turn the focus of our discussion to how these
values and principles are implemented in the actual activities of

27. the life cycle. The basis for all practices in XP is verbal
communications; practitioners therefore must master good
listening skills. Another interesting concept in XP is on testing
activities. Test cases are continually written as the requirements
emerge before any code is actually developed. This school of
thought is based on building quality into the code instead of
catching errors at a later stage in development. Another
prominent feature of XP is the pair programming concept. Two
programmers are selected for compatibility and assigned to
work on a code module to produce better quality code quickly
with fewer errors.
We have finished our discussion on the core of XP
methodology. You should now be able to apply the values,
principles, and activities as outlined in figure 1.12 to the XP
practices. We encourage you to conduct research on the Internet
to read more about XP practices and its success stories in the
computer industry.
6. Unified Modeling Language (UML)
In this section we will take a brief look at the history of the
Unified Modeling Language (UML) and how it can be applied to
the life cycle phases of software development. We introduce
UML at this point in our discussion to assist you in preparing
diagrams to represent your ideas in the system specifications
document.
A. History of Unified Modeling Language
UML has emerged in the software industry and has steadily
matured over the decades to become a standard. As a modeling
language, UML represents best practices in analysis and design
of large-scale software systems.
We can trace the roots of UML to the beginnings of object-
oriented languages. With the onset of early object-oriented
languages, Stimula-67 and Smalltalk, Objective-C, techniques
for object-oriented analysis and design began to appear in
software engineering. In the early 1990s, a variety of
diagramming techniques began to appear in publications written
by common authors Coad, Yourdon, Booch, Rumbaugh,

28. Premerlini, Eddy, Lorensen, Jacobsen, Christerson, Jonsson, and
Overgaard (Bennet et al, 2001). You may have purchased or
seen books on object-oriented analysis and design in your
favorite bookstore or library that were written by one or more of
these authors. If you scan through a few of these books you will
notice that each approach outlines a slightly different
diagramming notation and method to represent classes, objects,
and relationships. The difference in these notations and methods
was very confusing to developers when sharing designs. To
effectively communicate an object-oriented design, a visual
language with an established set of rules was needed in the
industry. UML attempts to provide this commonality of methods
in the software industry and to become the standard notation
language used among designers and developers.
B. Unified Modeling Language
The Unified Modeling Language provides a definition of a set
of elements and a set of rules on how to define these elements
to make programs (Bennet et al, 2001). The elements in UML
are defined by using a set of symbols, lines, rectangles, ovals,
and other shapes, which are grouped together to create a
graphical representation of a conceptual idea. These visual
representations increase understanding among all interested
parties involved in the design model.
In the current version of UML, there are different types of
diagrams that are defined and divided into three major
categories: structure, behavior, and interaction.
As we proceed through the phases of the life cycle you will
learn and practice with a few of these diagrams to present your
ideas for your project. You will be developing a set of technical
documents for a proposed system as a required assignment for
this course. The diagrams we will present in the subsequent
modules are summarized in table 1.1 and mapped to the
documents where you can use them throughout the life cycle.
Before you start to work on your first assignment, the SS
document, make sure you review the notes and examples on Use
Case and State diagrams. Click on the highlighted text in the

29. table below.
Table 1.1
Maps the UML Diagrams to Technical Documents
UML Diagram
Document(s)
Representation
Operational or Use Case Diagram
System Specifications
Software Requirements Specifications
Scenarios describing how the
system will be used by actors
of the system.
Statechart or State Transition Diagram
System Specifications
States of system operation and
the events to trigger these
different states.
Activity Diagram
System Specifications
Software Requirements Specifications
Activity flow of the various processes
needed to accomplish the task.
Class Diagram
Software Requirements Specifications
Software Design
Define classes and the necessary
relationships between classes.
Object Diagram
Software Design
Class instances and relationships
among these instances.
Component Diagram
Software Design
Code module breakdown of the
processes.
A variety of drawing tools exist on the market that provide the

30. symbol set necessary to draw UML diagrams. You can
download a trial version of SmartDraw software from the
Internet to create the required diagrams for your project
assignment. You are encouraged to perform a search on the
Internet for other available drawing tools.
Case Tools and UML
We mentioned earlier in this module that there are many CASE
tools available on the market to automate the tedious tasks
involved in software development. UML provides a
specification written for members of the Object Management
Group who develop CASE tools used in the industry to provide
standardization of notation. You are encouraged to search the
Internet and become familiar with the availability of CASE
tools that support UML features.
1. Problem Analysis
At the beginning of a project, the software engineer needs to
define the problem before establishing the requirements for the
software. In this section we will describe the scientific method
that can be used to clarify the problem in order to develop a
solution. In problem analysis, software engineers need to
include all the stakeholders who have different perspectives on
the proposed software. We will discuss the role of stakeholders
in requirements development and how their views of the
proposed software will affect deriving the different categories
of requirements.
Understanding the Problem
Defining requirements requires the software engineer to fully
comprehend the problem before trying to solve it. As with other
engineering disciplines, the software engineer can begin by
following the scientific method to uncover the facts of the
problem and to develop a hypothesis that can be used to solve
the problem.
The scientific method is the standard way in which all scientists
and engineers tackle problems, and the software engineer

31. practices the scientific method in developing software. The
solutions to the problems that the software engineer solves are
the programs that he or she develops to execute on computers in
a runtime environment.
There are three steps to the scientific method:
Analysis, the first task of software development, corresponds to
the first step of the scientific method—observing the problem.
The analysis step in software development involves partitioning
the problem in order to understand its essential parts so that a
solution can be proposed.
Analysis begins with a problem statement from the customer.
Ideally, the problem statement will be an exhaustive laundry list
of requirements that the customer has expressed for the solution
to their problem. Customers, however, typically have difficulty
expressing their requirements clearly. Clarifying customer
requirements is one of the software engineer's most important
tasks.
Here is an abbreviated example of a customer's problem
statement:
· The self-service checkout system should ensure that store
customers scan their products and pay their bill.
· All types of payment should be handled by the self-service
checkout system.
Try to clarify this problem statement yourself and then look at
our clarified problem statement. The software engineer then
allocates the clarified customer's requirements to a proposed
system as indicated in the following illustration:
There are different categories of requirements that are needed
for the varying components of a system. We will discuss the
different requirement categories in section 2 of this module.
Once the allocation of requirements to system components is
complete, the software engineer focuses on designing, building,
and testing the software component of the system. As we
already discussed in module 1, the system specification (SS)

32. records the allocation of requirements to system components
and forms the basis of all subsequent software engineering
activities.
Software engineers use a model to verify that their
comprehension of the software requirements is complete and
coherent. These models typically are arrow-and-bubble
diagrams, textual notations, or mathematical expressions, and
are powerful tools for verifying completeness and
communicating the required behavior of the software.
The software requirements analysis culminates with the
composition of a requirement specifications document. For our
discussion we will refer to the ANSI/IEEE Standard 830-1998
Recommended Practice for Software Requirements
Specifications (SRS). The SRS is referred to as a design-to
specification and is the definitive statement on the expected
behavior of the software component of the system. We will
discuss the contents of various sections of the SRS throughout
the remainder of this module.
Identifying the Stakeholders
Stakeholders play an important role in determining requirements
for a computing system. Each stakeholder has a different
viewpoint on what the software is supposed to do and the
software engineer needs to involve them when deriving the
requirements. A stakeholder can be defined as any individual, or
group of individuals, "who will be affected by the system
directly or indirectly" (Sommerville, 2004, p. 146). The effects
of software can be described as any stakeholders who "request,
pay for, select, specify, use, or receive the output generated by
a software product" Weigers (2003, p. 29). In figure 2.1 below,
we have outlined an example list of stakeholders and their
potential interest in the product that will form the foundation
for requirements elicitation.
Figure 2.1
Stakeholders and Their Viewpoints
The interest of each stakeholder will assist in defining

33. categories of requirements for the proposed software. For
example, the business manager may be concerned that the
product is being developed with budget limitations, which
restrict the number of features and the time allotted to develop
the software. The end user is concerned with the ease of use of
the software, which will affect the user interface requirements.
The software engineer must consider each stakeholder's
viewpoint when deriving a set of requirements. In section 2 we
will discuss the different categories of requirements in more
detail.
Pressman (2005, p. 102) categorizes stakeholders into two
groups: customers and end users. We have provided the outline
of functions in table 2.1 that are used to distinguish the role of a
customer and an end user. It is common for the customer to be
the end user and to perform all the functions. The customers and
end users have a significant impact on the technical aspects of
the software. As we continue our discussion, we will use the
terms customer and end user according to their functional role
as outlined by Pressman.
Table 2.1
Role of Customer and End User in Software Development
Customer
End user
1) requests software
2) defines overall business objectives
1) uses software to achieve business objectives
3) provides product requirements
2) defines operational details
4) coordinates funding
Getting to Know the Business
In order to provide a solution to a customer's problem, the
software engineer must become familiar with the customer's

34. business and the objectives for the proposed software.
Commonplace business problems can often be solved with
commercial off-the-shelf products, but unique business
problems require creative solutions. Understanding the nature of
the customer's business will assist the software engineer in
clarifying the requirements needed for the proposed software.
For example, financial and medical institutions require secure,
accurate, and responsive transaction processing software. The
software engineer must research and become educated about the
customer's business in order to form the foundation for the
different categories of requirements that are needed to support
the application domain.
2. The Software Requirement
To fully understand how to derive requirements from different
perspectives at the software level, we need to define a
requirement and discuss the various types of requirements. It is
also important to understand that deriving complete and correct
requirements is the driving force for the success of the
subsequent development phases: design, code, and test.
Types of Requirements
Requirements can be classified into three basic types that exist
for software. To read the definition of each type, move your
mouse over the type.
· functional
· non-functional
· domain
Software engineers commonly use the acronym FURPS to
describe these requirement categories: functionality, usability,
reliability, performance, and supportability. In figure 2.2 we
have extended the basic types of requirements for software to
include data base, security, safety, and external interface.
Additional software requirement categories can exist for a
customer's problem in the areas of constraints and
implementation (Grady, 1992).
Figure 2.2
Categories of Software Requirements

35. Figure 2.2 depicts that all the categories of software
requirements are derived from the system requirements that
form the basis for all subsequent development. As we mentioned
in section 1, special consideration for the stakeholders' business
objectives and their interests must exist in defining all the
requirement categories for the proposed software product.
The primary focus of our requirements development discussion
will be on deriving the functional requirements for software. A
complete SRS will address all the categories that apply to the
customer's problem. It is common for software engineers to
create supplemental requirement documents and then reference
them in the SRS. For example, if a system involves a safety-
critical component, a separate specification containing only
safety-related requirements may be compiled and used as a
reference. After all the software requirements have been fully
understood and elaborated for the business domain and the
customer's problem, the analysis task is complete.
Requirement Definition
The Institute of Electrical and Electronics Engineers (IEEE)
generically defines a software requirement as a condition or
capability to which the system being built must conform to
operate correctly.
A more refined definition of a software requirement is provided
in the IEEE Standard 729 (1983) as:
· a software capability needed by the user to solve a problem or
achieve an objective
· a software capability that must be met or processed by a
system or system component to satisfy a contract, specification,
standard, or other formally imposed documentation
Davis (1993) adds that software requirements are used to:
· define an object, function or state,
· limit or control actions associated with an object, function, or
state
· define relationships among objects, functions, and states
Conflicting Requirements

36. When specifying requirements, there is a potential risk that one
requirement may conflict with another in a different category.
To avoid this conflict, it's necessary for the software engineer
to cross-check requirements with those in other categories. For
example, a functional requirement may specify that something
should be done and the non-functional requirement may specify
that it should not be done. Early identification of conflicting
requirements will avoid rework and the introduction of software
errors in later stages of the development life cycle.
Importance of Requirements
Requirements guide the planning, designing, coding, and testing
of software, and therefore need to be correctly and completely
defined by the software engineer. Correct and complete
requirements will reduce misinterpretation that can cause errors
in later stages of development. Latent errors in the requirements
can have a negative impact in the subsequent phases of software
development, in the following ways:
· expensive to fix or change
· does not satisfy the needs of the user(s)
· result in disagreements between the customer and the
developer
· cannot derive test cases
· result in wrong system and customer dissatisfaction
Software engineers, customers, and end users should spend an
adequate amount of time defining the requirements. Spending
more time during requirements development has proven to be
worth the investment. Blackburn et al (1996) reports in a study
that improvement was seen in the development speed of
companies when more time was spent during the software
requirements stage. Companies that developed faster actually
"spent less time and effort on average in all of the other stages
of development and significantly less time in the final
testing/integration stage." Blackburn et al concluded that the
development speed was increased due to less rework involved in
fixing errors discovered in the design, code, and test phases.
3. Requirements Development Model

37. In figure 2.3 we summarize the various phases and the activities
that occur at each phase of the basic requirements development
model (Wiegers, 2003). In subsequent sections we will discuss
several of the key activities contained in each phase.
Figure 2.3
Requirements Development Model
Requirements Elicitation
Requirements elicitation for a software product is the most
difficult phase in development. Understanding the application
domain, problem, and the needs of the customer and end user
requires various means of oral and written communication to
transfer this information among all parties. Any breakdown in
this communication process can lead to ill-defined, missing, and
incorrect requirements, which will result in the delivery of a
low-quality product or even the wrong software product.
In section 1 we discussed the importance of understanding the
problem, the stakeholders, and the business objectives.
Requirements elicitation begins with the customer who initiates
communication by contacting a software engineer with a
business-related problem. The software engineer responds to the
customer's problem by clarifying the needs by using effective
means of communication in a written description.
Effective Communication
Communication among the software engineer, customer, and end
user begins with a series of either informal or formal meetings,
preferably face to face. The software engineer should be
prepared with a list of well-formed questions before any
meeting. The responses to these questions provided by the
customer and end user will assist the software engineer in fully
understanding what functions need to be satisfied by the
proposed software. The following list outlines tips for effective
communication among the software engineer, customer, and end
user:
· listen carefully to the customers and end users of the proposed
system

38. · keep the language simple and free of technical terms
· prepare well-formed questions in advance
· perform research and gain understanding of the application's
domain
· draw diagrams or pictures to represent complex ideas
· take good notes
· use a facilitator, if necessary
The process of effective communication in translating the
customer's and end user's needs into requirements can break
down among all parties for a variety of reasons. The software
engineer, customer, and end user often see a communication gap
in the requirements phase, which has been commonly referred to
as the "user and the developer" syndrome (Leffingwell et al,
2003, p. 92). The customer and end user will often know exactly
what they want but have difficulty in articulating their needs in
language that the software engineer understands. The software
engineer must realize that the customer and end user are the
domain experts. An effective communication approach must be
established by the software engineer and be used during
requirements elicitation.
Effective communication can sometimes be preempted by the
different personalities among the involved parties. Conflicts
may result from misunderstandings in the use of language,
differing cultures, or personal agendas. The use of a facilitator
can greatly mitigate conflicts to keep a positive and productive
communication process flowing among all parties.
Use Case Model
Earlier in our discussion we stressed the importance of effective
communication among the software engineer, customers, and
end users in understanding the requirements of the proposed
software. We also highlighted that conveying this information
back to the customer and end user was important for directing
subsequent phases of development. At this point in our
discussion we will elaborate on a technique that can be used to
specify and model the expected behavior for software. Software
engineers refer to this behavioral model as the use case model.

39. The use case model defines use cases and scenarios that can
"easily capture a set of functional requirements" and "provide a
vehicle for organizing the software requirements in an easy-to-
manage way" (Bittner et al, 2003, p. 11). Following the use case
model during requirements development can ease the transition
from the analysis to the design phase.
About Use Cases
Our discussion on use cases will begin with a brief history. The
use case was introduced as part of an object-oriented
development methodology originated by Ivar Jacobson and
described in his book called Object-Oriented Software
Engineering: A Use Case Driven Approach (Addison-Wesley,
1992). Researchers Larry Constantine and others have extended
this concept into a general technique for requirements analysis
and user interface design. The Unified Modeling Language
provides support for modeling a use case.
Leffingwell et al (2003, p. 149) defines a use case as
"sequences of actions a system performs that yield an
observable result of value to a particular actor." A sequence of
actions refers to a "set of functions" or an "algorithmic
procedure" that is initiated and used by an actor. The use case
describes the input to the system and the response that is
necessary to satisfy the function that produces the intended
output.
A use case is best summarized as having the following
characteristics (Leffingwell et al, 2003; Weigers, 2003):
· provides the foundation for deriving scenarios in which an
actor interacts with the system
· encompasses several tasks with a common goal
· achieves a specific goal or accomplishes a particular task or
function
· describes an action in terminology relative to the actor's
domain and not terminology relative to the computer
· focuses on the simplicity of the use or action being performed
without regard to how it is implemented in the software or
alternate ways of accomplishing the same task

40. · provides a means to derive detailed requirements for
accomplishing the objective for each scenario by using a
software application
When forming a use case, you should think of all the various
external entities that interact with the system and the different
ways in which they may possibly use the system. Specifying use
cases is part of functional modeling of desired system behavior.
By modeling the expected behavior with use cases, we can
uncover required classes and associations that will be needed
during the construction phase of the object model. We
emphasize the necessary components for a complete use case in
the following list:
· actor, who initiates an event or events
· specific interaction that takes place between this actor and the
system
· expected response from the system
The steps to derive functional requirements following a use-
case approach are summarized below in figure 2.4.
Figure 2.4
Use-case Approach to Derive Functional Requirements
In the list below we summarize the benefits derived from
following a use case approach during requirements elicitation:
· determine system and software requirements
· determine actor profiles
· assist in identification of an initial set of classes and objects,
at the system and software level
· assist in identification of software subsystems according to
required functionality
When the software engineer meets with the potential end users
of the desired system during requirements elicitation, the
objective is to get answers to information-seeking questions
(Leffingwell et al, 2003) to form the components of a use case.
We have provided a list of sample questions that the software
engineer can use during meetings with the customers and end
users:

41. · What is the expected behavior of the system?
· How is the user supposed to use the system?
· What types of services is the system supposed to provide?
· What is the expected result/output of the system?
· Who will be using the system?
The software engineer composes a use case from the
information and then uses the use case as the foundation for
deriving one or more scenarios to carry out the functions.
Each use case scenario involves an actor, the system, and a
single function to be performed. Once all the use cases are
developed, they will assist you in identifying the data objects
needed to create the proposed software system. We will provide
an example of a use case and model the possible scenarios with
UML during our discussion on requirements analysis.
Requirements Analysis
During requirements elicitation, we discussed how to
communicate and gather the requirements from the customers
and end users for the proposed software. After we form a good
idea of what the customers and end users want the software to
do, we can expand our model of the expected behavior and
develop profiles for the actors of the system. In this section we
will discuss how to perform analysis that will result in detailed
requirements that will form the bulk of the specifications
document.
During requirements analysis, the software engineer elaborates
on the information gathered during elicitation. At this stage the
focus continues on the whats, rather than the hows, by defining
the top-level objects and their attributes, their relationships
with other objects, and the interfaces required with external
entities. We can begin to analyze and model the required flow
and transformation of data between the identified entities
(Pressman, 2005). There are several major data products that
can result from requirements analysis; these are listed as:
· behavioral diagrams (use case scenario, data flow, and state
transition)
· prototypes

42. · class identification
· data dictionary
Use Case and the Unified Modeling Language
The Unified Modeling Language (UML) provides a user model
and notation for the specification of the different ways an end
user will interact with the system, the use case. Models of
scenarios are created from the use case to depict the expected
behavior from the perspective of the actors. These scenarios
assist the software engineer with elicitation and analysis of the
requirements by describing the functionality that is required in
the software. A functional requirement and the corresponding
test case can be derived by the action that is modeled in the use
case. A test case is used later in development to verify that a
functional requirement has been met in the software product.
We will discuss scenario-based testing in module 4.
UML stresses the importance of textual documentation for each
use case to accompany each scenario illustration. Following is a
list of the items to be included in the use case documentation:
· unique name and number for the use case
· description of the role and purpose of the action
· description of the basic sequence of events
· description outlining any special requirements or conditions
· description stating the specific pre-conditions and post-
conditions
A descriptive name is selected and assigned to each use case
that best describes the function required by the software.
Nomenclature for use cases is very important in software
engineering, as it enhances documentation. When possible,
similar functions should be categorized in one use case. A
unique number or identifier is assigned to each use case to
enhance the traceability to the requirement, the software
component, and the test case. We will discuss requirements
traceability and its role in the development process later in this
module. In module 5, we will discuss traceability through the
development cycle as a project management activity.
Example Use Case

43. Let's take a look at a use case that we can define for the self-
service checkout system. The use case for the customer in a
retail store using the self-service checkout system to start a new
purchase order is outlined in table 2.2.
Table 2.2
Use Case to Start a New Purchase Order
Use Case 1.0: Start new purchase order
A customer selects one or more items to purchase in a retail
store. Once customers have completed selecting all the items,
they will walk up to the checkout counter and start a new
purchase order to prepare for scanning each item.
Precondition: The checkout system needs to be configured
properly and have access to the local area network and store
database. The system needs to be ready to accept a new
purchase order.
Post-condition: The system is ready to scan items for a new
purchase order.
Actor Profile: Customer shopping in a retail store who desires
to purchase one or more items. A customer can be new to the
system or be a frequent shopper familiar with the system.
Frequent customers may have a discount card. Many customers
will shop in the retail store.
Sequence of events:
1. Customer walks up to an available self-service checkout.
2. Customer reads instructions and selects either Spanish or
English language.
3. Customer selects the option to begin the order.
4. Customer scans frequent shopper discount card, if one exists.
5. Customer reads the directions for scanning an item.
User Scenarios
User scenarios, also referred to as user stories, describe a
unique theme for interacting with the system. Scenarios are
derived from the use case textual description. When creating
scenarios, you select the actors that interact with the system and
model different ways in which they will use the system to
accomplish the required tasks. As we mentioned earlier, a user

44. scenario consists of an actor, who initiates events, and an
explanation of the interaction that takes place between this actor
and the system. As a result of this interaction, the system will
generate a response. Refer to figure 2.5 below for a
representation of the various components of a user scenario.
Figure 2.5
Components of a User Scenario
It should be noted that an actor is any external entity that uses a
system in a particular way to perform a desired function to
accomplish a task. The actor can be a person, another software
system, a hardware device, or an organization. For example,
actors can be people who assume various roles (operator,
customer, manager, system administrator) or an external entity
(hardware device) that interacts with the system. The software
engineer must have a good understanding of the characteristics
of each actor or group of actors before composing a user
scenario. These characteristics are documented and referred to
as an actor profile.
For the self-service checkout system, we can write the
following scenarios presented in table 2.3 from the use case
presented in table 2.2.
Table 2.3
User Scenario for the Start of a New Purchase Order Use Case
User scenario 1: start the order
1. Customer selects either the English or Spanish language.
2. System displays the "Begin Order" option in the English or
Spanish language.
User scenario 2: set up the order
1. Customer selects the "Begin Order" option when ready to
start the order.
2. System responds by displaying a message with instructions to
scan frequent shopper discount card.
User scenario 3: scan discount card
1. Customer places the discount card over the scanner.
2. System responds by reading the barcode imprinted on the

45. card.
3. System displays welcome message and instructions to scan an
item.
Once the use case scenarios are written for the use case, we can
model them with a use case diagram as shown in figure 2.6.
Figure 2.6
Start a New Purchase Order Use Case Diagram
Identification of Objects and Classes
Data Objects
The use case can provide insight into the identification of
objects that can be grouped by similarity to form classes for
these objects. Objects are easily identifiable because the actors
of a system manipulate objects when they use the software to
perform a function to accomplish a task. Identifying the
commonality among the objects will help software engineers to
derive the base classes and establish attributes, needed
functionality, and relationships. Software engineers model
classes and their relationships with diagrams. UML is the
common notation language being used in today's software
industry for creating class diagrams.
Context Diagram
In module 1 we suggested the context diagram be used at the
system level for specifying requirements. We present the
context diagram for the self-service checkout system again as a
means of modeling the necessary flow of data items into and out
of the software system.
Figure 2.7
Context Diagram for the Self-service Checkout System
The context diagram represented in figure 2.7 shows a sketch of
the data items that are to be manipulated by the system's
external entities and actors. At this point, the view of the
software system is considered a black box and is represented by
the circle. During the design phase, we will refine the software
system to the process level to extend our view to the functional

46. level, which will yield the subsystems and components.
If an object-oriented development approach is to be followed,
each external entity and data item is a good candidate for an
object. For example, we can easily derive several objects for the
self-service checkout system by following the directional
arrows that flow in and out of the external entities.
Additionally, we can imagine objects for the external entities
that represent the hardware devices.
Class Diagrams
Once the potential objects are identified, they can be grouped
by similarity and used to determine base classes with a set of
attributes. A class describes a group of objects with similar
properties or attributes, common behaviors, relationships to
other objects, and semantics. For example, think of a person as
an object. Every person has the same set of common attributes,
including a name, gender, height, weight, eye color, nationality,
fingerprint, and social security number. These attributes are
used to identify an individual and distinguish one person from
another. A base class can be designed with these attributes and
the class can be used to create instances of different individuals
with a unique set of characteristics. Class instances are also
referred to as objects. An object is defined as a concept, idea, or
thing with crisp boundaries and meaning for the problem at
hand.
Once the software engineer establishes all the base classes, the
relationships between the classes are modeled using a class
diagram. A class diagram is a schema, pattern, or template used
for describing the class. Each class description contains a name,
a set of attributes, and a set of operations.
Bennett et al (2001, p. 49) outlines how creating a UML class
diagram can achieve several goals in modeling expected
behavior. The class diagram can be used to:
· document classes within a system or subsystem
· describe association, generalization, and aggregation between
classes
· show characteristics of the class

47. · show the operations and interfaces of objects
· direct activities throughout the development process
Class instances or objects collaborate with other objects through
message passing. An association between two classes is
described when a class instance or object passes a message to
another object and that message is received by the recipient
object. When drawing a class diagram, a connecting line is used
to depict the association. The association is assigned a
descriptive name. Software engineers can further define the
association existing between the two class instances by adding
its multiplicity, which indicates the possible number of
instances for the class. In table 2.4 we summarize the indicators
that can be placed at each end of the line in the class diagram to
show multiplicity.
Table 2.4
Multiplicity Indicators for Class Diagrams
Indicator
Meaning
0..1
Zero or one
1
One only
0..*
Zero or more
1..*
One or more
n
Only n, where n > 1
0..n
Zero to n, where n > 1
1..n
One to n, where n > 1
Refer to figure 2.8 for a class diagram that depicts the card
reader and the card objects that are necessary for the payment
transaction of the self-service checkout system.
Figure 2.8

48. Example Class Diagram
Data Dictionary
We will mention the data dictionary during requirements
analysis because it can be used to store logical representations
of data objects. It is important to adopt a notation for a data
dictionary that provides for unambiguous and accurate
descriptions of the data. Such notations facilitate interpretation
and also allow for the use of CASE tools to assist in developing
and maintaining dictionaries.
Modern systems may require extremely large data dictionaries,
which may be practical only when a CASE tool is available to
reduce the human effort and manage the complexity. Such tools,
however, are useful for more than simple management of the
data objects. If a formalized notation is used to describe the
data, the tool can perform automated analyses of the data to
ensure consistency across the system. Such analyses would be
quite difficult if developers had to perform them by themselves.
We will extend our discussion on the data dictionary in module
3 when we look at the functional analysis model.
Requirement Specification
Software requirements are expressed in a simple and concise
language and compiled into a formal document. The
specification document should be easy for all the stakeholders
to understand.
A simple set of guidelines (IEEE, 1998) is provided to assist in
writing the software requirements specification. Each
requirement should:
· consist of one sentence
· be free of technical jargon, abbreviations, and acronyms
· contain no conditional logic (if A then B)
· use active voice
· contain no references
· be grammatically correct
A software requirement can be composed by following either
the "shall" or "shall not" format. Using the word shall in the

49. requirement indicates that the requirement is mandatory. Using
the self-service checkout system as an example, a requirement
for processing a debit card payment transaction is a four-digit
number. Here are two different and acceptable ways to write
this requirement.
The software shall require a four-digit code to be entered for a
debit card transaction.
The software shall not process a debit card transaction without a
four-digit code.
The preferable way to write a software requirement is to use the
"shall" format because the positive approach simplifies writing
the software test case. The Boolean "not" can be somewhat
tricky to code and test. The positive approach is commonly used
in preparing the formal requirement document; however, you
should be aware that both ways are acceptable to software
engineers.
Other words, such as should, will, and must, can be used
(Sommerville and Sawyer, 1997) if they are consistent with the
meanings provided in table 2.5.
Table 2.5
Words and Their Meanings Used for Writing Software
Requirements
Word
Meaning
shall
mandatory
should
desirable, but not mandatory
will
something that will be externally provided
must
best avoided; a synonym for "shall"
Writing a good set of requirements can be a challenging task
because many software engineers find it difficult to write clear
and concise natural language and have a tendency to write
requirements in an unnecessarily verbose way. Table 2.6

50. contains a list of attributes of a well-written software
requirement, and the do's and don'ts while writing the
specifications document.
Table 2.6
Summary of Attributes for a Software Requirement
Attribute
Description
Do
Don't
correct
meets a user need
communicate with customer and user
add unnecessary features
unambiguous
no interpretation variations
choose simple words
use technical jargon
complete
include everything
be precise
embellish
verifiable
provide method to verify
write a test case
use words like "usually," "often," "user friendly"
consistent
no conflicts with other requirements
cross check with other categories
use the word "don't"
modifiable
easy to reference
provide index or table of contents
traced
provide origin of each requirement
provide a traceability matrix

51. traceable
identify each requirement
provide a unique number for each requirement
design independent
no design constraints
imply a specific software architecture or algorithm
annotated
categories of requirements
group requirement by function or task
concise
overall length and understandability
keep it short and as simple as possible
organized
readability
use meaningful titles and category names
understandable by the customer
meaningful content to both customer and developer
use simple language
use technical terms, unless simply defined
In table 2.7 we have provided a set of requirements for the start
a new purchase order use case described in table 2.2 for our
self-service checkout system.
Table 2.7
Requirements for the Start a New Purchase Order Use Case
Requirement 1.0: Start a new purchase order
1.1 The system shall display a message with an option to select
the English or Spanish language.
1.1.1 If the English language option is selected, the system shall
select the English language to display text.
1.1.2 The Spanish language option is selected, the system shall

52. select the Spanish language to display text.
1.2 The system shall display an option to activate a new
purchase order.
1.2.1 The option to activate the purchase order is detected, the
system shall respond by displaying instructions to insert a
frequent shopper discount card.
1.3 The system shall display an option to cancel the current
session.
1.3.1 The cancel option is detected, the system shall respond by
setting up for a new purchase order.
1.4 The system shall detect a frequent shopper discount card.
1.5 The system shall read an imprinted barcode from the
frequent shopper discount card.
1.5.1 An error occurs while reading the barcode from a frequent
shopper discount card, the system shall eject the card and
display an error message.
1.5.2 The barcode is read without an error from the frequent
shopper discount card, the system shall request the customer
information from the store database.
1.6 The system shall use the barcode on the frequent shopper
discount card to query the database for customer information.
1.6.1 The customer information is successfully queried from the
database, the system shall display a welcome message with the
customer's name.
1.6.2 The customer information was not successfully queried
from the database, the system shall return a message "customer
not located in database."
1.7 The system shall display instructions for scanning an item
for purchase.
Traceability of Requirements
Each software requirement should be unique and traceable to
the corresponding system requirement, use case, and software
requirement. Traceability can be accomplished by creating a
traceability matrix.
We will extend the column headings in the traceability matrix
as we discuss the various phases of development. The

53. traceability matrix should be included as an appendix in the
specifications document, updated at each phase in development,
and included with each document created in that phase.
Specifications Document
The Software Requirements Specifications (SRS) document is
used as a communication tool and serves as a contract between
the customer and the software engineers. The SRS explains to
the customer what the software engineer's perception is and
what needs to be done in order to accomplish building the
correct system. The requirements are outlined and categorized
in simple language. In addition to satisfying communication
needs, the SRS is the basis for integrated system testing and
verification activities, and it also helps control the evolution of
the software system.
The SRS is a deliverable document that is reviewed and
accepted by the customer before design of the software actually
begins. The SRS is developed after the system specifications
and the system design documents are completed and accepted by
the customer. The SRS must be complete, concise, and accurate
to direct the subsequent phases of development. Roger Pressman
(2005) proposes following a "use case driven" design. In this
module, we discussed how to develop a use case and model
scenarios with UML as a tool for requirements elicitation and
analysis.
Once the SRS is approved by the customers, it serves as the
baseline for all software requirements. Any change or addition
to the requirements needs to be recorded, approved, and traced.
We will discuss managing software changes as an activity of
project management in module 5.
IEEE Recommended Practice for Software Requirements
Specifications
The Institute of Electrical and Electronics Engineers has
provided some guidelines for writing a Software Requirements
Specification (SRS) in the IEEE Recommended Practice for
Software Requirements Specifications, IEEE Standard 830-
1998. Annex A of the IEEE Recommended Practice for Software

54. Requirements Specifications provides guidelines for writing the
specific requirements for a complete SRS. The templates
outlined in Annex A organize specific requirements for a
proposed software solution by describing:
· system modes
· user classes
· objects
· features
· stimulus
· response
· functional hierarchy
Software engineers choose the best template, or combinations of
templates, that best describe the requirements for the proposed
software solution. Combinations of templates can also be used
to organize requirements.
In module 1 and in section 3 of this module, we have discussed
several diagrams that can be used to graphically represent
requirements for the SRS. The use of diagrams is recommended
in technical documents and all diagrams should be
supplemented with a textual description.
Requirements Validation
The final phase of the requirements development model is
validation. Validating the requirements is necessary to ensure
that the requirements are complete and unambiguous to build a
high-quality and correct product. Early in module 1 we
discussed how software engineering emerged in the computer
industry to address the legacy problems of poor quality and cost
overruns and to reduce maintenance costs after deployment of
software products. Many studies have been done by Boehm,
Grady, Kelly, Sherif, and Hops (Weigers, 2003) that have
supported that early discovery of errors during the requirements
development phase will reduce the cost and time to correct
them. Errors in requirements can lay dormant in software and
may not be discovered until system testing or by the customer
after delivery of the product. Correcting latent errors in
requirements requires significant rework by the software

55. engineers, which takes time and money. Software engineers can
validate the requirements by developing a set of preliminary test
cases and participating in a formal peer review or inspection.
Time spent validating the requirements can actually shorten the
delivery schedule because less rework will be required
(Blackburn et al, 1996) during this phase.
A preliminary set of test cases can easily be developed when the
use-case model is followed during requirements elicitation and
analysis. Writing test cases during the requirements validation
phase follows a scenario-based approach that will uncover
ambiguities in the functional requirements. These test cases are
extended during the test phase of development. We will discuss
how to write scenario-based test cases in module 4.
Another requirements validation method commonly used by
software engineers is to conduct and participate in a formal
review or inspection. A review committee is formed from the
stakeholders who represent varying perspectives and interests in
the proposed software product. A small team consisting of six
or fewer participants is formed. During the review, the software
engineer presents the categories of requirements to the team for
discussion. Any deficiency in a requirement identified by the
participants is included in a summary portfolio that consists of
one or more "requests for action." The software engineer
addresses each request and takes corrective action to revise or
clarify the requirement. The revisions to the requirements are
resubmitted to the reviewers for final approval.
Instructions
Scenario
You have been asked to lead a software development team to
build a system fulfilling the Statement of Need below. Your
team is employed by a small company. The customer wants a
project that balances reasonable development cost, timely
delivery, software quality, and functionality.