UNIT-I

INTRODUCTION TO SOFTWARE ENGINEERING

Software: Software is
(1) Instructions (computer programs) that provide desired features, function, and performance,
when executed
(2) Data structures that enable the programs to adequately manipulateinformation,
(3) Documents that describe the operation and use of the programs.
Characteristics of Software:
(1) Software is developed or engineered; it is not manufactured in the classical sense.
(2) Software does not “wear out”
(3) Although the industry is moving toward component-based construction, most software continuesto
be custom built.

Software Engineering:
(1) The 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)

EVOLVING ROLE OF SOFTWARE:

Software takes dual role. It is both a product and a vehicle for delivering a product.
As a product: It delivers the computing potential embodied by computer Hardware or by a
network of computers.
As a vehicle: Itis information transformer-producing, managing, acquiring, modifying, displaying,
or transmitting information that can be as simple as single bit or as complex as a multimedia presentation.
Software delivers the most important product of our time-information.
- It transforms personal data
- It manages business information to enhance competitiveness
- It provides a gateway to worldwide information networks
- It provides the means for acquiring information

The role of computer software has undergone significant change over a span of little more than 50 years
- Dramatic Improvements in hardware performance
- Vast increases in memory and storage capacity
- A wide variety of exotic input and output options

1970s and 1980s:

 Osborne characterized a “new industrial revolution”
 Toffler called the advent of microelectronics part of “the third wave of change” in human history
 Naisbitt predicted the transformation from an industrial society to an “information society”
Feigenbaum and McCorduck suggested that information and knowledge would be the focal
point for power in the twenty-first century
 Stoll argued that the “electronic community” created by networks and software was the key
to knowledge interchange throughout the world
1990s began:
 Toffier described a “power shift” in which old power structures disintegrate as computersand
software lead to a “democratization of knowledge”.
 Yourdon worried that U.S companies might lose their competitive edge in software
related business and predicted “the decline and fall of the American programmer”.
 Hammer and Champy argued that information technologies were to play a pivotal role in
the “reengineering of the corporation”.
Mid-1990s:
The pervasiveness of computers and software spawned a rash of books by neo-luddites.

.
Later 1990s:
 Yourdon reevaluated the prospects of the software professional and suggested “the rise
and resurrection” of the American programmer.
 The impact of the Y2K “time bomb” was at the end of 20th century

2000s progressed:
 Johnson discussed the power of “emergence” a phenomenon that explains what happens when
interconnections among relatively simple entities result in a system that “self-organizes to form
more intelligent, more adaptive behavior”.
Yourdon revisited the tragic events of 9/11 to discuss the continuing impact of global terrorism
on the IT community
 Wolfram presented a treatise on a “new kind of science” that posits a unifying theory
based primarily on sophisticated software simulations
 Daconta and his colleagues discussed the evolution of “the semantic web”.

Today a huge software industry has become a dominant factor in the economies of the industrialized world.

THE CHANGING NATURE OF SOFTWARE:

The 7 broad categories of computer software present continuing challenges for software engineers:
1) System software
2) Application software
3) Engineering/scientific software
4) Embedded software
5) Product-line software
6) Web-applications
7) Artificial intelligence software.
System software: System software is a collection of programs written to service other programs.
The systems software is characterized by
- heavy interaction with computer hardware
- heavy usage by multiple users
- concurrent operation that requires scheduling, resource sharing, and sophisticated
process management
- complex data structures
- multiple external interfaces
E.g. compilers, editors and file management utilities.
Application software:
- Application software consists of standalone programs that solve a specific business need.
- It facilitates business operations or management/technical decision making.
- It is used to control business functions in real-time
E.g. point-of-sale transaction processing, real-time manufacturing process control.

Engineering/Scientific software: Engineering and scientific applications range

- from astronomy to volcanology
- from automotive stress analysis to space shuttle orbital dynamics
- from molecular biology to automated manufacturing
computer aided design, system simulation and other interactive applications.
Embedded software:
- Embedded software resides within a product or system and is used to implement
and control features and functions for the end-user and for the system itself.
- It can perform limited and esoteric functions or provide significant function and
control capability.

.
 E.g. Digital functions in automobile, dashboard displays, braking systems etc.
Product-line software: Designed to provide a specific capability for use by many different
customers, product-line software can focus on a limited and esoteric market place or address mass
consumer markets
E.g. Word processing, spreadsheets, computer graphics, multimedia, entertainment,
database management, personal and business financial applications
Web-applications: WebApps are evolving into sophisticated computing environments that not
only provide standalone features, computing functions, and content to the end user, but also are
integrated with corporate databases and business applications.
Artificial intelligence software: AI software makes use of nonnumerical algorithms to solve
complex problems that are not amenable to computation or straightforward analysis. Application
within this area includes robotics, expert systems, pattern recognition, artificial neural networks,
theorem proving, and game playing.

The following are the new challenges on the horizon:

Ubiquitous computing
Netsourcing
Open source
 The “new economy”

Ubiquitous computing: The challenge for software engineers will be to develop systems and application
software that will allow small devices, personal computers and enterprise system to communicate across
vast networks.
Net sourcing: The challenge for software engineers is to architect simple and sophisticated applications
that provide benefit to targeted end-user market worldwide.
Open Source: The challenge for software engineers is to build source that is self descriptive but more
importantly to develop techniques that will enable both customers and developers to know what changes
have been made and how those changes manifest themselves within the software.
The “new economy”: The challenge for software engineers is to build applications that will facilitate mass
communication and mass product distribution.

SOFTWARE MYTHS

Beliefs about software and the process used to build it- can be traced to the earliest days of computing
myths have a number of attributes that have made them insidious.
Management myths: Manages with software responsibility, like managers in most disciplines, are often
under pressure to maintain budgets, keep schedules from slipping, and improve quality.
Myth: We already have a book that’s full of standards and procedures for building software - Wont that
provide my people with everything they need to know?
Reality: The book of standards may very well exist but, is it used? Are software practitioners aware of its
existence? Does it reflect modern software engineering practice?
Myth: If we get behind schedule, we can add more programmers and catch up.
Reality: Software development is not a mechanistic process like manufacturing. As new people are added,
people who were working must spend time educating the new comers, thereby reducing the amount of time
spend on productive development effort. People can be added but only in a planned and well coordinated
manner.
Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm built it.
Reality: If an organization does not understand how to manage and control software projects internally, it
will invariably struggle when it outsources software projects.

.
Customer myths: The customer believes myths about software because software managers and
practitioners do little to correct misinformation. Myths lead to false expectations and ultimately,
dissatisfaction with the developer.

Myth: A general statement of objectives is sufficient to begin with writing programs - we can fill in the
details later.

Reality: Although a comprehensive and stable statement of requirements is not always possible, an
ambiguous statement of objectives is recipe for disaster.

Myth: Project requirements continually change, but change can be easily accommodated because software
is flexible.

Reality: It is true that software requirements change, but the impact of change varies with the time at which
it is introduced and change can cause upheaval that requires additional resources and major design
modification.

Practitioner’s myths: Myths that are still believed by software practitioners: during the early days of
software, programming was viewed as an art from old ways and attitudes die hard.

Myth: Once we write the program and get it to work, our jobs are done.

Reality: Someone once said that the sooner you begin writing code, the longer it’ll take you to get done.
Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended
after it is delivered to the customer for the first time.

Myth: The only deliverable work product for a successful project is the working program.

Reality: A working program is only one part of a software configuration that includes many elements.
Documentation provides guidance for software support.

Myth: software engineering will make us create voluminous and unnecessary documentation and will
invariably slows down.

Reality: software engineering is not about creating documents. It is about creating quality. Better quality
leads to reduced rework. And reduced rework results in faster delivery times.

A GENERIC VIEW OF PROCESS

SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY:

Tools

Method
s

A quality

Software Engineering Layers

.
Software engineering is a layered technology. Any engineering approach must rest on an organizational
commitment to quality. The bedrock that supports software engineering is a quality focus.

The foundation for software engineering is the process layer. Software engineering process is the glue that
holds the technology layers. Process defines a framework that must be established for effective
delivery of software engineering technology.

The software forms the basis for management control of software projects and establishes the context
in which
- technical methods are applied,
- work products are produced,
- milestones are established,
- quality is ensured,
- And change is properly managed.

Software engineering methods rely on a set of basic principles that govern area of the technology and
include modeling activities.

Methods encompass a broad array of tasks that include

 communication,
 requirements analysis,
 design modeling,
 program construction,
 Testing and support.

Software engineering tools provide automated or semi automated support for the process and the
methods. When tools are integrated so that information created by one tool can be used by another, a
system for the support of software development, called computer-aided software engineering, is
established.

A PROCESS FRAMEWORK:
 Software process must be established for effective delivery of software engineering technology.
 A process framework establishes the foundation for a complete software process by identifying a
small number of framework activities that are applicable to all software projects, regardless of
their size or complexity.
 The process framework encompasses a set of umbrella activities that are applicable acrossthe
entire software process.
 Each framework activity is populated by a set of software engineering actions
 Each software engineering action is represented by a number of different task sets- each a
collection of software engineering work tasks, related work products, quality assurance points, and
project milestones.

In brief
"A process defines who is doing what, when, and how to reach a certain goal."

A Process Framework
- establishes the foundation for a complete software process
- identifies a small number of framework activities
- applies to all s/w projects, regardless of size/complexity.
- also, set of umbrella activities
- applicable across entire s/w process.
- Each framework activity has
- set of s/w engineering actions.
- Each s/w engineering action (e.g., design) has

.
 - collection of related tasks (called task

sets): work tasks

work products (deliverables)

quality assurance points

project milestones.

Software process

Process framework
Umbrella activities
Framework activity #1 Softwareengineeringaction
Task sets

Work tasks Work products

Quality assurance points Project milestones

Work tasks
Software engineering action T
ask
Work products
Quality assurance points Project milestones

Framework activity #n Softwareengineeringaction

Task sets
Work tasks Work products
Quality assurance points Project milestones

Work tasks Work products

Quality assurance points Project milestones
Software engineeringaction

\
 Generic Process Framework: It is applicable to the vast majority of software projects
- Communication activity
- Planning activity
- Modeling activity
- analysis action
- requirements gathering work task
- elaboration work task
- negotiation work task
- specification work task
- validation work task
- design action
- data design work task
- architectural design work task
- interface design work task
- component-level design work task
- Construction activity
- Deployment activity

1) Communication: This framework activity involves heavy communication and collaboration with
the customer and encompasses requirements gathering and other related activities.
2) Planning: This activity establishes a plan for the software engineering work that follows. It
describes the technical tasks to be conducted, the risks that are likely, the resources that will be
required, the work products to be produced, and a work schedule.
3) Modeling: This activity encompasses the creation of models that allow the developer and
customer to better understand software requirements and the design that will achieve those
requirements. The modeling activity is composed of 2 software engineering actions- analysis and
design.
 Analysis encompasses a set of work tasks.
 Design encompasses work tasks that create a design model.
4) Construction: This activity combines core generation and the testing that is required to uncover
the errors in the code.
5) Deployment: The software is delivered to the customer who evaluates the delivered product
and provides feedback based on the evolution.
These 5 generic framework activities can be used during the development of small programs, the creation
of large web applications, and for the engineering of large, complex computer-based systems.

The following are the set of Umbrella Activities.

1) Software project tracking and control – allows the software team to assess progress against
the project plan and take necessary action to maintain schedule.
2) Risk Management - assesses risks that may effect the outcome of the project or the quality ofthe
product.
3) Software Quality Assurance - defines and conducts the activities required to ensure
software quality.
4) Formal Technical Reviews - assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next action or activity.

j
 5) Measurement - define and collects process, project and product measures that assist the team in
delivering software that needs customer’s needs, can be used in conjunction with all other
framework and umbrella activities.

6) Software configuration management - manages the effects of change throughout thesoftware

process.

7) Reusability management - defines criteria for work product reuse and establishes mechanisms
to achieve reusable components.

8) Work Product preparation and production - encompasses the activities required to creatework
products such as models, document, logs, forms and lists.

Intelligent application of any software process model must recognize that adaption is essential for success
but process models do differ fundamentally in:
 The overall flow of activities and tasks and the interdependencies among activities andtasks.
 The degree through which work tasks are defined within each frame work activity.
 The degree through which work products are identified and required.
 The manner which quality assurance activities are applied.
 The manner in which project tracking and control activities are applied.
 The overall degree of the detailed and rigor with which the process is described.
 The degree through which the customer and other stakeholders are involved with the project.
 The level of autonomy given to the software project team.
 The degree to which team organization and roles are prescribed.

THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI):

The CMMI represents a process meta-model in two different ways:

 As a continuous model
 As a staged model.
Each process area is formally assessed against specific goals and practices and is rated according to the
following capability levels.
Level 0: Incomplete. The process area is either not performed or does not achieve all goals and objectives
defined by CMMI for level 1 capability.
Level 1: Performed. All of the specific goals of the process area have been satisfied. Work tasks required
to produce defined work products are being conducted.
Level 2: Managed. All level 1 criteria have been satisfied. In addition, all work associated with the process
area conforms to an organizationally defined policy; all people doing the work have access to adequate
resources to get the job done; stakeholders are actively involved in the process area as required; all work
tasks and work products are “monitored, controlled, and reviewed;
Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is “tailored from the
organizations set of standard processes according to the organizations tailoring guidelines, and contributes
and work products, measures and other process-improvement information to the organizational process
assets”.
Level 4: Quantitatively managed. All level 3 criteria have been achieved. In addition, the process area is
controlled and improved using measurement and quantitative assessment.”Quantitative objectives for
quality and process performance are established and used as criteria in managing the process”
Level 5: Optimized. All level 4 criteria have been achieved. In addition, the process area is adapted and
optimized using quantitative means to meet changing customer needs and to continually improve the
efficacy of the process area under consideration”

j
 The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to
achieve these goals. Specific practices refine a goal into a set of process-related activities.

The specific goals (SG) and the associated specific practices(SP) defined for project planning are

SG 1 Establish estimates
SP 1.1 Estimate the scope of the project
SP 1.2 Establish estimates of work product and task attributes
SP 1.3 Define project life cycle
SP 1.4 Determine estimates of effort and cost
SG 2 Develop a Project Plan
SP 2.1 Establish the budget and schedule
SP 2.2 Identify project risks
SP 2.3 Plan for data management
SP 2.4 Plan for needed knowledge and skills
SP 2.5 Plan stakeholder involvement
SP 2.6 Establish the project plan
SG 3 Obtain commitment to the plan
SP 3.1 Review plans that affect the project
SP 3.2 Reconcile work and resource levels
SP 3.3 Obtain plan commitment
In addition to specific goals and practices, the CMMI also defines a set of five generic goals and related
practices for each process area. Each of the five generic goals corresponds to one of the five capability
levels. Hence to achieve a particular capability level, the generic goal for that level and the generic
practices that correspond to that goal must be achieved. To illustrate, the generic goals (GG) and
practices (GP) for the project planning process area are

GG 1 Achieve specific goals

GP 1.1 Perform base practices
GG 2 Institutionalize a managed process
GP 2.1 Establish and organizational policy
GP 2.2 Plan the process
GP 2.3 Provide resources
GP 2.4 Assign
responsibility GP 2.5 Train
people
GP 2.6 Manage configurations
GP 2.7 Identify and involve relevant stakeholders
GP 2.8 Monitor and control the process
GP 2.9 Objectively evaluate adherence
GP 2.10 Review status with higher level management
GG 3 Institutionalize a defined process
GP 3.1 Establish a defined process
GP 3.2 Collect improvement information
GG 4 Institutionalize a quantitatively managed process
GP 4.1 Establish quantitative objectives for the process

j
 GP 4.2 Stabilize sub process performance
GG 5 Institutionalize and optimizing process
GP 5.1 Ensure continuous process improvement
GP 5.2 Correct root causes of problems

PROCESS PATTERNS
The software process can be defined as a collection patterns that define a set of activities, actions,
work tasks, work products and/or related behaviors required to develop computer software.
A process pattern provides us with a template- a consistent method for describing an important
characteristic of the software process. A pattern might be used to describe a complete process and a task
within a framework activity.

Pattern Name: The pattern is given a meaningful name that describes its function within the software
process.

Intent: The objective of the pattern is described briefly.

Type: The pattern type is specified. There are three types

1. Task patterns define a software engineering action or work task that is part of the
process and relevant to successful software engineering practice. Example: Requirement
Gathering
2. Stage Patterns define a framework activity for the process. This pattern incorporates
multiple task patterns that are relevant to the stage.
Example: Communication
3. Phase patterns define the sequence of framework activities that occur with the process,
even when the overall flow of activities is iterative in nature.
Example: Spiral model or prototyping.

Initial Context: The conditions under which the pattern applies are described prior to the initiation of the
pattern, we ask
(1) What organizational or team related activities have already occurred.
(2) What is the entry state for the process
(3) What software engineering information or project information already exists

Problem: The problem to be solved by the pattern is described.

Solution: The implementation of the pattern is described.
This section describes how the initial state of the process is modified as a consequence the initiation of the
pattern.
It also describes how software engineering information or project information that is available before the
initiation of the pattern is transformed as a consequence of the successful execution of the pattern

Resulting Context: The conditions that will result once the pattern has been successfully implemented are
described. Upon completion of the pattern we ask
(1) What organizational or team-related activities must have occurred
(2) What is the exit state for the process
(3) What software engineering information or project information has been developed?

Known Uses: The specific instances in which the pattern is applicable are indicated
Process patterns provide and effective mechanism for describing any software process.
The patterns enable a software engineering organization to develop a hierarchical process description that
begins at a high-level of abstraction.
Once process pattern have been developed, they can be reused for the definition of process variants-that is,
a customized process model can be defined by a software team using the pattern as building blocks for the
process models.

j
 PROCESS ASSESSMENT
The existence of a software process is no guarantee that software will be delivered on time, that it
will meet the customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term
quality characteristics. In addition, the process itself should be assessed to be essential to ensure that it
meets a set of basic process criteria that have been shown to be essential for a successful software
engineering.

Software

Identifies Identifies capabilities andrisk

Software
Lead
Motivat

Software Capabilit
A Number of different approaches to software process assessment have been proposed over the past few
y
decades.

Standards CMMI Assessment Method for Process Improvement (SCAMPI) provides a five step
process assessment model that incorporates initiating, diagnosing, establishing, acting & learning. The
SCAMPI method uses the SEI CMMI as the basis for assessment.
CMM Based Appraisal for Internal Process Improvement (CBA IPI) provides a diagnostic technique
for assessing the relative maturity of a software organization, using the SEI CMM as the basis for the
assessment.
SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessments. The
intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any
defined software process.
ISO 9001:2000 for Software is a generic standard that applies to any organization that wants to improve
the overall quality of the products, system, or services that it provides. Therefore, the standard is directly
applicable to software organizations &companies.

PERSONAL AND TEAM PROCESS MODELS:

The best software process is one that is close to the people who will be doing the work.Each software
engineer would create a process that best fits his or her needs, and at the same time meets the broader needs
of the team and the organization. Alternatively, the team itself would create its own process, and at the
same time meet the narrower needs of individuals and the broader needs of the organization.

Personal software process (PSP)

The personal software process (PSP) emphasizes personal measurement of both the work product that is
produced and the resultant quality of the work product.

j
 The PSP process model defines five framework activities: planning, high-level design, high level design
review, development, and postmortem.

Planning: This activity isolates requirements and, base on these develops both size and resource estimates.
In addition, a defect estimate is made. All metrics are recorded on worksheets or templates. Finally,
development tasks are identified and a project schedule is created.
High level design: External specifications for each component to be constructed are developed and a
component design is created. Prototypes are built when uncertainty exists. All issues are recorded and
tracked.
High level design review: Formal verification methods are applied to uncover errors in the design.
Metrics are maintained for all important tasks and work results.
Development: The component level design is refined and reviewed. Code is generated, reviewed,
compiled, and tested. Metrics are maintained for all important task and work results.
Postmortem: Using the measures and metrics collected the effectiveness of the process is determined.
Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
PSP stresses the need for each software engineer to identify errors early and, as important, to understand
the types of errors that he is likely to make.

PSP represents a disciplined, metrics-based approach to software engineering.

Team software process (TSP): The goal of TSP is to build a “self-directed project team that organizes
itself to produce high-quality software. The following are the objectives for TSP:
 Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams(IPT) of 3 to
about 20 engineers.
 Show managers how to coach and motivate their teams and how to help them sustain
peak performance.
 Accelerate software process improvement by making CMM level 5 behavior normal and expected.
 Provide improvement guidance to high-maturity organizations.
 Facilitate university teaching of industrial-grade teamskills.
A self-directed team defines
- roles and responsibilities for each team member
- tracks quantitative project data
- identifies a team process that is appropriate for the project
- a strategy for implementing the process
- defines local standards that are applicable to the teams software engineering work;
- continually assesses risk and reacts to it
- Tracks, manages, and reports project status.
-
TSP defines the following framework activities: launch, high-level design, implementation, integration and
test, and postmortem.
TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members in their
work.
Scripts define specific process activities and other more detailed work functions that are part of the team
process.
Each project is “launched” using a sequence of tasks.

The following launch script is recommended

 Review project objectives with management and agree on and document team goals
 Establish team roles
 Define the teams development process
 Make a quality plan and set quality targets
 Plan for the needed support facilities

j
 PROCESS MODELS
Prescriptive process models define a set of activities, actions, tasks, milestones, and work products that
are required to engineer high-quality software. These process models are not perfect, but they do provide a
useful roadmap for software engineering work.

A prescriptive process model populates a process framework with explicit task sets for software
engineering actions.

THE WATERFALL MODEL:

The waterfall model, sometimes called the classic life cycle, suggests a systematic sequential approach to
software development that begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment.

Context: Used when requirements are reasonably well understood.

Advantage:
It can serve as a useful process model in situations where requirements are fixed and work is to
proceed to complete in a linear manner.

The problems that are sometimes encountered when the waterfall model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes. Although the linear model
can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the
project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The waterfall model
requires this and has difficulty accommodating the natural uncertainty that exist at the beginning
of many projects.
3. The customer must have patience. A working version of the programs will not be available until
late in the project time-span. If a major blunder is undetected then it can be disastrous until the
program is reviewed.

INCREMENTAL PROCESS MODELS:

1) The incremental model

2) The RAD model

THE INCREMENTAL MODEL:

Context: Incremental development is particularly useful when staffing is unavailable for a

complete implementation by the business deadline that has been established for the project. Early
increments can be implemented with fewer people. If the core product is well received, additional staff can
be added to implement the next increment. In addition, increments can be planned to manage technical
risks.

j
 increment # n
Planning
ion
Modeling
a n a ly s i s d e s ig n
Communica Constructi n
Dep l o y m e n tdelivery
feedback

c odetest

deliv ery of
nt h increment
increment # 2

Planning

Communication C o n s t r c t io n
c odetest
D e p l o y m e n tdelivery
feedback

deliv ery of 2nd increment

Modeling
a n a l y s i sd e s i g n

increment # 1
i on
Planning

Modelinganalysisdesign

Communica Constructio
c odetest n

deliv ery of 1st increment

D e p l o y m e n tdelivery
feedback

project calendar t ime

 The incremental model combines elements of the waterfall model applied in an iterative fashion.
 The incremental model delivers a series of releases called increments that provide progressively
more functionality for the customer as each increment is delivered.
 When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed. The core product is used by the customer. As a result, a plan is
developed for the next increment.
 The plan addresses the modification of the core product to better meet the needs of the customer
and the delivery of additional features and functionality.
 This process is repeated following the delivery of each increment, until the complete product is
produced.
For example, word-processing software developed using the incremental paradigm might deliver basic file
management editing, and document production functions in the first increment; more sophisticated editing,
and document production capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment.

Difference: The incremental process model, like prototyping and other evolutionary approaches,
is iterative in nature. But unlike prototyping, the incremental model focuses on delivery of an operational
product with each increment

THE RAD MODEL:

Rapid Application Development (RAD) is an incremental software process model that

emphasizes a short development cycle. The RAD model is a “high-speed” adaption of the waterfall model,
in which rapid development is achieved by using a component base construction approach.
Context: If requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a “fully functional system” within a very short time period.

j
 Team # n

M o d e lin g business m odeling dat a m odeling process m odeling

Co n st ru ct io n com ponent reuse autom at ic code

generation test ing
Team # 2
Communicat ion Mo d e
business m odeling dat a m odeling process m odeling

ling

Planning
Co nst ruct io n De ployme nt
com ponent reuse aut om at ic code generat ion t int egrat ion deliv ery feedback
Team est ing
#1
Mode ling
business modeling dat a modeling process modeling

Const ruct ion

component reuse aut omat ic code generat ion
t est ing

6 0 - 9 0 days

The RAD approach maps into the generic framework activities.

Communication works to understand the business problem and the information characteristics that the
software must accommodate.
Planning is essential because multiple software teams works in parallel on different system functions.
Modeling encompasses three major phases- business modeling, data modeling and process modeling- and
establishes design representation that serve existing software components and the application of automatic
code generation.
Deployment establishes a basis for subsequent iterations.
The RAD approach has drawbacks:
For large, but scalable projects, RAD requires sufficient human resources to create the right number of
RAD teams.
If developers and customers are not committed to the rapid-fire activities necessary to complete the system
in a much abbreviated time frame, RAD projects will fail
If a system cannot be properly modularized, building the components necessary for RAD will be
problematic
If high performance is an issue, and performance is to be achieved through tuning the interfaces to system
components, the RAD approach may not work; and
RAD may not be appropriate when technical risks are high.

EVOLUTIONARY PROCESS MODELS:

Evolutionary process models produce with each iteration produce an increasingly more complete version of
the software with every iteration.

Evolutionary models are iterative. They are characterized in a manner that enables software engineers to
develop increasingly more complete versions of the software.

j
 PROTOTYPING:

Prototyping is more commonly used as a technique that can be implemented within the context of anyone
of the process model.
The prototyping paradigm begins with communication. The software engineer and customer meet and
define the overall objectives for the software, identify whatever requirements are known, and outline areas
where further definition is mandatory.
Prototyping iteration is planned quickly and modeling occurs. The quick design leads to the construction of
a prototype. The prototype is deployed and then evaluated by the customer/user.
Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time
enabling the developer to better understand what needs to be done.

Qu ick p lan

Com municat ion

Mo d e lin g
Qu ick d e sig n

Deployment
De live r y Const ruct ion of
& Fe e dback prot ot ype

Context:
If a customer defines a set of general objectives for software, but does not identify detailed input,
processing, or output requirements, in such situation prototyping paradigm is best approach.
If a developer may be unsure of the efficiency of an algorithm, the adaptability of an operating
system then he can go for this prototyping method.

Advantages:
The prototyping paradigm assists the software engineer and the customer to better understand what is
to be built when requirements are fuzzy.
The prototype serves as a mechanism for identifying software requirements. If a working prototype is
built, the developer attempts to make use of existing program fragments or applies tools.

Prototyping can be problematic for the following reasons:

1. The customer sees what appears to be a working version of the software, unaware that the
prototype is held together “with chewing gum and baling wire”, unaware that in the rush to get it
working we haven’t considered overall software quality or long-term maintainability. When
informed that the product must be rebuilt so that high-levels of quality can be maintained, the
customer cries foul and demands that “a few fixes” be applied to make the prototype a working
product. Too often, software development relents.
2. The developer often makes implementation compromises in order to get a prototype working
quickly. An inappropriate operating system or programming language may be used simply
because it is available and known; an inefficient algorithm may be implemented simply to

j
 demonstrate capability. After a time, the developer may become comfortable with these choices
and forget all the reasons why they were inappropriate. The less-than-ideal choice has now
become an integral part of the system.

THE SPIRAL MODEL

 The spiral model, originally proposed by Boehm, is an evolutionary software process model that
couples the iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model.
 The spiral model can be adapted to apply throughout the entire life cycle of an application, from
concept development to maintenance.
 Using the spiral model, software is developed in a series of evolutionary releases. During early
iterations, the release might be a paper model or prototype. During later iterations, increasingly
morecomplete versions of the engineered system are
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback test
produced.

 Anchor point milestones- a combination of work products and conditions that are attained along
the path of the spiral- are noted for each evolutionary pass.
 The first circuit around the spiral might result in the development of product specification;
subsequent passes around the spiral might be used to develop a prototype and then progressively
more sophisticated versions of the software.
 Each pass through the planning region results in adjustments to the project plan. Cost and schedule
are adjusted based on feedback derived from the customer after delivery. In addition, the project
manager adjusts the planned number of iterations required to complete the software.
 It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it
into an iterative framework that more realistically reflects the real world.
 The first circuit around the spiral might represent a “concept development project” which starts
at the core of the spiral and continues for multiple iterations until concept development is
complete.
 If the concept is to be developed into an actual product, the process proceeds outward on the spiral
and a “new product development project” commences.
 Later, a circuit around the spiral might be used to represent a “product enhancement project.” In
essence, the spiral, when characterized in this way, remains operative until the software is retired.

Context: The spiral model can be adopted to apply throughout the entire life cycle of an application, from
concept development to maintenance.

Advantages:
It provides the potential for rapid development of increasingly more complete versions of the software.

j
 The spiral model is a realistic approach to the development of large-scale systems and software. The spiral
model uses prototyping as a risk reduction mechanism but, more importantly enables the developer to apply
the prototyping approach at any stage in the evolution of the product.

Draw Backs:
The spiral model is not a panacea. It may be difficult to convince customers that the evolutionary approach
is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If
a major risk is not uncovered and managed, problems will undoubtedly occur.

THE CONCURRENT DEVELOPMENT MODEL:

The concurrent development model, sometimes called concurrent engineering, can be represented
schematically as a series of framework activities, software engineering actions and tasks, and their
associated states.

none

Modeling act ivit y

represents the state

Under of a software engineering
activity or task
development

Await ing
changes

Under review

Under
revision

Baselined

Done

The activity modeling may be in anyone of the states noted at any given time. Similarly, other
activities or tasks can be represented in an analogous manner. All activities exist concurrently but reside in
different states.

Any of the activities of a project may be in a particular state at any one time:
- under development
- awaiting changes
- under revision
- under review

In a project the communication activity has completed its first iteration and exists in the awaiting
changes state. The modeling activity which existed in the none state while initial communication was

j
 completed, now makes a transition into the under development state. If, however, the customer indicates
that changes in requirements must be made, the modeling activity moves from the under development
state into the awaiting changes state.

The concurrent process model defines a series of events that will trigger transitions from state to
state for each of the software engineering activities, actions, or tasks.

The event analysis model correction which will trigger the analysis action from the done state into
the awaiting changes state.

Context: The concurrent model is often more appropriate for system engineering projects where different
engineering teams are involved.

Advantages:
 The concurrent process model is applicable to all types of software development and provides
an accurate picture of the current state of a project.
 It defines a network of activities rather than each activity, action, or task on the network exists
simultaneously with other activities, action and tasks.
A FINAL COMMENT ON EVOLUTIONARY PROCESSES:

 The concerns of evolutionary software processes are:

 The first concern is that prototyping poses a problem to project planning because of the uncertain
number of cycles required to construct the product.
 Second, evolutionary software process do not establish the maximum speed of the evolution. If the
evolution occurs too fast, without a period of relaxation, it is certain that the process will fall into
chaos.
 Third, software processes should be focused on flexibility and extensibility rather than on high
quality.

THE UNIFIED PROCESS:

The unified process (UP) is an attempt to draw on the best features and characteristics of conventional
software process models, but characterize them in a way that implements many of the best principles of
agile software development.
The Unified process recognizes the importance of customer communication and streamlined methods for
describing the customer’s view of a system. It emphasizes the important role of software architecture and
“helps the architect focus on the right goals, such as understandability, reliance to future changes, and
reuse“. If suggests a process flow that is iterative and incremental, providing the evolutionary feel that is
essential in modern software development.

A BRIEF HISTORY:
During the 1980s and into early 1990s, object-oriented (OO) methods and programming languages
gained a widespread audience throughout the software engineering community. A wide variety of object-
oriented analysis (OOA) and design (OOD) methods were proposed during the same time period.
During the early 1990s James Rumbaugh, Grady Booch, and Ival Jacobsom began working on a
“Unified method” that would combine the best features of each of OOD & OOA. The result was UML- a
unified modeling language that contains a robust notation fot the modeling and development of OO
systems.
By 1997, UML became an industry standard for object-oriented software development. At the
same time, the Rational Corporation and other vendors developed automated tools to support UML
methods.
Over the next few years, Jacobson, Rumbugh, and Booch developed the Unified process, a
framework for object-oriented software engineering using UML. Today, the Unified process and UML are
widely used on OO projects of all kinds. The iterative, incremental model proposed by the UP can and
should be adapted to meet specific project needs.

j
 PHASES OF THE UNIFIED PROCESS:

The inception phase of the UP encompasses both customer communication and planning
activities. By collaborating with the customer and end-users, business requirements for the software are
identified, a rough architecture for the system is proposed and a plan for the iterative, incremental nature of
the ensuing project is developed.
The elaboration phase encompasses the customer communication and modeling activities of the
generic process model. Elaboration refines and expands the preliminary use-cases that were developed as
part of the inception phase and expands the architectural representation to include five different views of
the software- the use-case model, the analysis model, the design model, the implementation model, and the
deployment model.
The construction phase of the UP is identical to the construction activity defined for the generic
software process. Using the architectural model as input, the construction phase develops or acquires the
software components that will make each use-case operational for end-users. To accomplish this, analysis
and design models that were started during the elaboration phase are completed to reflect the final version
of the software increment.
The transition phase of the UP encompasses the latter stages of the generic construction activity
and the first part of the generic deployment activity. Software given to end-users for beta testing, and user
feedback reports both defects and necessary changes.
The production phase of the UP coincides with the deployment activity of the generic process.
During this phase, the on-going use of the software is monitored, support for the operating environment is
provided, and defect reports and requests for changes are submitted and evaluated.
Elaborat ion

Incept ion

const ruc t ion

Release
soft ware increment t ransit ion

product ion

A software engineering workflow is distributed across all UP phases. In the context of UP, a workflow is
analogous to a task set. That is, a workflow identifies the tasks required to accomplish an important
software engineering action and the work products that are produced as a consequence of successfully
completing the tasks.

UNIFIED PROCESS WORK PRODUCTS:

During the inception phase, the intent is to establish an overall “vision” for the project,
- identify a set of business requirements,
- make a business case for the software, and
- define project and business risks that may represent a threat to success.

j
 The most important work product produced during the inception is the use-case modell-a collection of
use-cases that describe how outside actors interact with the system and gain value from it. The use-case
model is a collection of software features and functions by describing a set of preconditions, a flow of
events and a set of post-conditions for the interaction that is depicted.

The use-case model is refined and elaborated as each UP phase is conducted and serves as an
important input for the creation of subsequent work products. During the inception phase only 10 to 20
percent of the use-case model is completed. After elaboration, between 80 to 90 percent of the model has
been created.

The elaboration phase produces a set of work products that elaborate requirements and produce
and architectural description and a preliminary design. The UP analysis model is the work product that
is developed as a consequence of this activity. The classes and analysis packages defined as part of the
analysis model are refined further into a design model which identifies design classes, subsystems, and
the interfaces between subsystems. Both the analysis and design models expand and refine an evolving
representation of software architecture. In addition the elaboration phase revisits risks and the project
plan to ensure that each remains valid.

The construction phase produces an implementation model that translates design classes into
software components into the physical computing environment. Finally, a test model describes tests
that are used to ensure that use cases are properly reflected in the software that has beenconstructed.

The transition phase delivers the software increment and assesses work products that are
produced as end-users work with the software. Feedback from beta testing and qualitative requests for
change is produced at this time.

Inception phase

Elaboration phase
Vision document
Init ial use-case
model Init ial project Construct ion phase
Use-case model
glossary Init ial Supplement ary
business case Init ial requirement s including Transition phase
Design model
risk assessment . non-funct ional Soft ware
Project plan, Analy sis model component s Int Deliv ered soft ware
phases and it erat ions. Soft ware archit ect egrat ed soft ware increment Bet a t est report
Business ure Descript ion. increment s
model, if Execut able archit ect Test plan and procedure General user feedback
necessary . ural prot ot ype.
Test cases
One or more prot ot ypes Preliminary design Support document at ion
model Revised risk list user manuals
Project plan including
inst allat ion
it erat ion plan manuals descript
adapt ed ion of current
workflows milest increment
ones
t echnical work
product s Preliminary
user manual

j
 UNIT-II

SOFTWARE REQUIREMENTS

Software requirements are necessary

 To introduce the concepts of user and system requirements
 To describe functional and non-functional requirements
 To explain how software requirements may be organised in a requirements document
What is a requirement?
 The requirements for the system are the description of the services provided by the system and
its operational constraints
 It may range from a high-level abstract statement of a service or of a system constraint to
a detailed mathematical functional specification.
 This is inevitable as requirements may serve a dual function
o May be the basis for a bid for a contract - therefore must be open to interpretation;
o May be the basis for the contract itself - therefore must be defined in
detail; Both these statements may be called requirements
Requirements engineering:
 The process of finding out, analysing documenting and checking these services and constraints
is called requirement engineering.
 The process of establishing the services that the customer requires from a system and
the constraints under which it operates and is developed.
 The requirements themselves are the descriptions ofthe system services and constraints that
are generated during the requirements engineering process.

Requirements abstraction (Davis):

If a company wishes to let a contract for a large software development project, it must define its
needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be
written so that several contractors can bid for the contract, offering, perhaps, different ways of
meeting the client organisation’s needs. Once a contract has been awarded, the contractor must
write a system definition for the client in more detail so that the client understands and can
validate what the software will do. Both of these documents may be called the requirements
document for the system.”

Types of requirement:
 User requirements
o Statements in natural language plus diagrams ofthe services the system provides and
its operational constraints. Written for customers.
 System requirements
o A structured document setting out detailed descriptions of the system’s functions,
services and operational constraints. Defines what should be implemented so may be
part of a contract between client and contractor.

Definitions and specifications:

User Requirement Definition:

The software must provide the means of representing and accessing external files created by other
tools.

j
 System Requirement specification:
 The user should be provided with facilities to define the type of external files.
 Each external file type may have an associated tool which may be applied to the file.
 Each external file type may be represented as a specific icon on the user’s display.
 Facilities should be provided for the icon representing an external file type to be defined bythe
user.
 When an user selects an icon representing an external file, the effect of that selection is to
apply the tool associated with the type of the external file to the file represented by the
selected icon.
Requirements readers:

1) Functional and non-functional

requirements: Functional requirements
• Statements of services the system should provide how the system should react
to particular inputs and how the system should behave in particular situations.
Non-functional requirements
• Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
Domain requirements
• Requirements that come from the application domain of the system and that
reflect characteristics of that domain.

FUNCTIONAL REQUIREMENTS:
 Describe functionality or system services.
 Depend on the type of software, expected users and the type of system where the softwareis
used.
 Functional user requirements may be high-level statements of what the system should do
but functional system requirements should describe the system services indetail.
The functional requirements for The LIBSYS system:
 A library system that provides a single interface to a number of databases of articles in
different libraries.
 Users can search for, download and print these articles for personal study.
Examples of functional requirements
 The user shall be able to search either all ofthe initial set of databases or select a subset from it.
 The system shall provide appropriate viewers for the user to read documents in thedocument
store.

j
  Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able
to copy to the account’s permanent storage area.
Requirements imprecision
 Problems arise when requirements are not precisely stated.
 Ambiguous requirements may be interpreted in different ways by developers and users.
 Consider the term ‘appropriate viewers’
o User intention - special purpose viewer for each different document type;
o Developer interpretation - Provide a text viewer that shows the contents of the document.
Requirements completeness and consistency:
In principle, requirements should be both complete and consistent.
Complete
 They should include descriptions of all facilities
required. Consistent
 There should be no conflicts or contradictions in the descriptions of the system
facilities. In practice, it is impossible to produce a complete and consistent
requirementsdocument.

NON-FUNCTIONAL REQUIREMENTS
 These define system properties and constraints e.g. reliability, response time andstorage
requirements. Constraints are I/O device capability, system representations, etc.
 Process requirements may also be specified mandating a particular CASE system, programming
language or development method.
 Non-functional requirements may be more critical than functional requirements. If these are
not met, the system is useless.
Non-functional requirement types:

Non-functional requirements :
Product requirements

j
 • Requirements which specify that the delivered product must behave in a particular way
e.g. execution speed, reliability, etc.
• Eg:The user interface for LIBSYS shall be implemented as simple HTML without
frames or Java applets.
Organisational requirements
• Requirements which are a consequence of organisational policies and procedures
e.g. process standards used, implementation requirements, etc.
• Eg: The system development process and deliverable documents shall conform to
the process and deliverables defined in XYZCo-SP-STAN-95.
External requirements
• Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc.
• Eg: The system shall not disclose any personal information about customers apart
from their name and reference number to the operators of the system.

Goals and requirements:

 Non-functional requirements may be very difficult to state precisely and imprecise
requirements may be difficult to verify.
 Goal
- A general intention of the user such as ease of use.
- The system should be easy to use by experienced controllers and should be organised in
such a way that user errors are minimised.
 Verifiable non-functional requirement
- A statement using some measure that can be objectively tested.
- Experienced controllers shall be able to use all the system functions after a total of two hours
training. After this training, the average number of errors made by experienced users shall not
exceed two per day.
 Goals are helpful to developers as they convey the intentions of the system users.

Requirements measures:
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure

j
 Portability Percentage of target dependent statements
Number of target systems

Requirements interaction:
• Conflicts between different non-functional requirements are common in complex systems.
• Spacecraft system
 To minimise weight, the number of separate chips in the system should
be minimised.
 To minimise power consumption, lower power chips should be used.
• However, using low power chips may mean that more chips have to be used. Which is the
most critical requirement?
A common problem with non-functional requirements is that they can be difficult to verify. Users
or customers often state these requirements as general goals such as ease of use, the ability of the system to
recover from failure or rapid user response. These vague goals cause problems for system developers as
they leave scope for interpretation and subsequent dispute once the system is delivered.

DOMAIN REQUIREMENTS
 Derived from the application domain and describe system characteristics and features that
reflect the domain.
 Domain requirements be new functional requirements, constraints on existing requirements
or define specific computations.
 If domain requirements are not satisfied, the system may beunworkable.

Library system domain requirements:

 There shall be a standard user interface to all databases which shall be based on the
Z39.50 standard.
 Because of copyright restrictions, some documents must be deleted immediately on arrival.
Depending on the user’s requirements, these documents will either be printed locally on the
system server for manually forwarding to the user or routed to a network printer.

Domain requirements problems

Understandability
• Requirements are expressed in the language of the application domain;
• This is often not understood by software engineers developing the system.
Implicitness
• Domain specialists understand the area so well that they do not think of makingthe
domain requirements explicit.

2) USER REQUIREMENTS
 Should describe functional and non-functional requirements in such a way that they
are understandable by system users who don’t have detailed technicalknowledge.
 User requirements are defined using natural language, tables and diagrams as these can
be understood by all users.

Problems with natural language

Lack of clarity
• Precision is difficult without making the document difficult to
read. Requirements confusion
• Functional and non-functional requirements tend to bemixed-up.
Requirements amalgamation
• Several different requirements may be expressed together.

Requirement problems
Database requirements includes both conceptual and detailed information
• Describes the concept of a financial accounting system that is to be included in LIBSYS;

j
 • However, it also includes the detail that managers can configure this system - this is
unnecessary at this level.
Grid requirement mixes three different kinds of requirement
• Conceptual functional requirement (the need for a grid);
• Non-functional requirement (grid units);
• Non-functional UI requirement (grid switching).
• Structured presentation
Guidelines for writing requirements
 Invent a standard format and use it for all requirements.
 Use language in a consistent way. Use shall for mandatory requirements, should for
desirable requirements.
 Use text highlighting to identify key parts of the requirement.
 Avoid the use of computer jargon.

3) SYSTEM REQUIREMENTS
 More detailed specifications of system functions, services and constraints than userrequirements.
 They are intended to be a basis for designing the system.
 They may be incorporated into the system contract.
 System requirements may be defined or illustrated using system models

Requirements and design

In principle, requirements should state what the system should do and the design should describe
how it does this.
In practice, requirements and design are inseparable
• A system architecture may be designed to structure the requirements;
• The system may inter-operate with other systems that generate design requirements;
• The use of a specific design may be a domain requirement.
Problems with NL(natural language) specification
Ambiguity
• The readers and writers of the requirement must interpret the same words in the
same way. NL is naturally ambiguous so this is very difficult.
Over-flexibility
• The same thing may be said in a number of different ways in thespecification.
Lack of modularisation
• NL structures are inadequate to structure system requirements.

Alternatives to NL specification:
Notation Description

Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.

Design description This approach uses a language like a programming language but with more abstract
languages features to specify the requirements by defining an operational model of the system.
This approach is not now widely used although it can be useful for interface
specifications.

j
 Graphical A graphical language, supplemented by text annotations is used to define the functional
notations requirements for the system. An early example of such a graphical language was SADT.
Now, use-case descriptions and sequence diagrams are commonly used .

Mathematical These are notations based on mathematical concepts such as finite-state machines or
specifications sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality. However, most customers don’t understand
formal specifications and are reluctant to accept it as a system contract.

Structured language specifications

 The freedom of the requirements writer is limited by a predefined template for requirements.
 All requirements are written in a standard way.
 The terminology used in the description may belimited.
 The advantage is that the most of the expressiveness of natural language is maintained but
a degree of uniformity is imposed on the specification.

Form-based specifications
 Definition of the function or entity.
 Description of inputs and where they come from.
 Description of outputs and where they go to.
 Indication of other entities required.
 Pre and post conditions (if appropriate).
 The side effects (if any) of the function.

Tabular specification
 Used to supplement natural language.
 Particularly useful when you have to define a number of possible alternative courses of action.

Graphical models
 Graphical models are most useful when you need to show how state changes or where you need
to describe a sequence of actions.

Sequence diagrams
 These show the sequence of events that take place during some user interaction with a system.
 You read them from top to bottom to see the order of the actions that take place.
 Cash withdrawal from an ATM
• Validate card;
• Handle request;
• Complete transaction.

j
 Sequence diagram of ATM withdrawal

System requirement specification using a standard form:

1. Function
2. Description
3. Inputs
j
 4. Source
5. Outputs
6. Destination
7. Action
8. Requires
9. Pre-condition
10. Post-condition
11. Side-effects

When a standard form is used for specifying functional requirements, the following information should be
included:
1. Description of the function or entity beingspecified
2. Description of its inputs and where these comefrom
3. Description of its outputs and where these go to
4. Indication of what other entities are used
5. Description of the action to be taken
6. If a functional approach is used, a pre-condition setting out what must be true before the function
is called and a post-condition specifying what is true after the function is called

j
 7. Description of the side effects of the operation.

4) INTERFACE SPECIFICATION
 Most systems must operate with other systems and the operating interfaces must be specified
as part of the requirements.
 Three types of interface may have to be defined
• Procedural interfaces where existing programs or sub-systems offer a range of services
that are accessed by calling interface procedures. These interfaces are sometimes called
Applicatin Programming Interfaces (APIs)
• Data structures that are exchanged that are passed from one sub-system to another.
Graphical data models are the best notations for this type of description
• Data representations that have been established for an existing sub-system
 Formal notations are an effective technique for interface specification.

5) THE SOFTWARE REQUIREMENTS DOCUMENT:

 The requirements document is the official statement of what is required of the system developers.
 Should include both a definition of user requirements and a specification of the
system requirements.
 It is NOT a design document. As far as possible, it should set of WHAT the system
shoulddo rather than HOW it should do it

Users of a requirements document:

j
 IEEE requirements standard defines a generic structure for a requirements document that must be
instantiated for each specific system.
1. Introduction.
i) Purpose of the requirements document
ii) Scope of the project
iii) Definitions, acronyms and abbreviations
iv) References
v) Overview of the remainder of the document
2. General description.
i) Product perspective
ii) Product functions
iii) User characteristics
iv) General constraints
v) Assumptions and dependencies
3. Specific requirements cover functional, non-functional and interface requirements. The
requirements may document external interfaces, describe system functionality and performance,
specify logical database requirements, design constraints, emergent system properties and
quality characteristics.
4. Appendices.
5. Index.

REQUIREMENTS ENGINEERING PROCESSES

The goal of requirements engineering process is to create and maintain a system requirements document.
The overall process includes four high-level requirement engineering sub-processes. These are concerned
with
 Assessing whether the system is useful to the business(feasibility study)
 Discovering requirements(elicitation and analysis)
 Converting these requirements into some standard form(specification)
 Checking that the requirements actually define the system that the customerwants(validation)
The process of managing the changes in the requirements is called requirementmanagement.

The requirements engineering process

Requirements engineering:

j
 The alternative perspective on the requirements engineering process presents the process as a three-stage
activity where the activities are organized as an iterative process around a spiral. The amount of time and
effort devoted to each activity in iteration depends on the stage of the overall process and the type of
system being developed. Early in the process, most effort will be spent on understanding high-level
business and non-functional requirements and the user requirements. Later in the process, in the outer rings
of the spiral, more effort will be devoted to system requirements engineering and systemmodeling.

This spiral model accommodates approaches to development in which the requirements are developed to
different levels of detail. The number of iterations around the spiral can vary, so the spiral can be exited
after some or all of the user requirements have been elicited.

Some people consider requirements engineering to be the process of applying a structured analysis method
such as object-oriented analysis. This involves analyzing the system and developing a set of graphical
system models, such as use-case models, that then serve as a system specification. The set of models
describes the behavior of the system and are annotated with additional information describing, for example,
its required performance or reliability.
Spiral model of requirements engineering processes

1) FEASIBILITY STUDIES
A feasibility study decides whether or not the proposed system is worthwhile. The input to the
feasibility study is a set of preliminary business requirements, an outline description of the system and how
the system is intended to support business processes. The results of the feasibility study should be a report
that recommends whether or not it worth carrying on with the requirements engineering and system
development process.
• A short focused study that checks
– If the system contributes to organisational objectives;
– If the system can be engineered using current technology and within budget;

j
 – If the system can be integrated with other systems that are used.

Feasibility study implementation:

• A feasibility study involves information assessment, information collection and report writing.
• Questions for people in the organisation
– What if the system wasn’t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed system?
In a feasibility study, you may consult information sources such as the managers of the
departments where the system will be used, software engineers who are familiar with the type of system
that is proposed, technology experts and end-users of the system. They should try to complete a feasibility
study in two or three weeks.
Once you have the information, you write the feasibility study report. You should make a
recommendation about whether or not the system development should continue. In the report, you may
propose changes to the scope, budget and schedule of the system and suggest further high-level
requirements for the system.

2) REQUIREMENT ELICITATION AND ANALYSIS:

The requirement engineering process is requirements elicitation and analysis.
• Sometimes called requirements elicitation or requirements discovery.
• Involves technical staff working with customers to find out about the application domain,
the services that the system should provide and the system’s operational constraints.
• May involve end-users, managers, engineers involved in maintenance, domainexperts, trade
unions, etc. These are called stakeholders.
•
Problems of requirements analysis
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders mayemerge and
the business environment change.

The requirements spiral

j
 Process activities
1. Requirements discovery
– Interacting with stakeholders to discover their requirements. Domain requirementsare
also discovered at this stage.
2. Requirements classification and organisation
– Groups related requirements and organises them into coherent clusters.
3. Prioritisation and negotiation
– Prioritising requirements and resolving requirements conflicts.
4. Requirements documentation
– Requirements are documented and input into the next round of the spiral.
The process cycle starts with requirements discovery and ends with requirements documentation. The
analyst’s understanding of the requirements improves with each round of the cycle.
Requirements classification and organization is primarily concerned with identifying overlapping
requirements from different stakeholders and grouping related requirements. The most common way of
grouping requirements is to use a model of the system architecture to identify subsystems and to associate
requirements with each sub-system.
Inevitably, stakeholders have different views on the importance and priority of requirements, and
sometimes these view conflict. During the process, you should organize regular stakeholder negotiations so
that compromises can be reached.
In the requirement documenting stage, the requirements that have been elicited are documented in such a
way that they can be used to help with further requirements discovery.

REQUIREMENTS DISCOVERY:
• Requirement discovery is the process of gathering information about the proposed and
existing systems and distilling the user and system requirements from this information.
• Sources of information include documentation, system stakeholders and the specifications
of similar systems.
• They interact with stakeholders through interview and observation and may use scenarios
and prototypes to help with the requirements discovery.
• Stakeholders range from system end-users through managers and external stakeholders such
as regulators who certify the acceptability of the system.
• For example, system stakeholder for a bank ATM include
1. Bank customers
2. Representatives of other banks
3. Bank managers
4. Counter staff
5. Database administrators
6. Security managers
7. Marketing department
8. Hardware and software maintenance engineers
9. Banking regulators
Requirements sources( stakeholders, domain, systems) can all be represented as system viewpoints, where
each viewpoints, where each viewpoint presents a sub-set of the requirements for the system.

Viewpoints:
• Viewpoints are a way of structuring the requirements to represent the perspectives
ofdifferent stakeholders. Stakeholders may be classified under different viewpoints.
• This multi-perspective analysis is important as there is no single correct way to analyse
system requirements.
•
Types of viewpoint:
1. Interactor viewpoints
– People or other systems that interact directly with the system. These viewpoints provide
detailed system requirements covering the system features and interfaces. In an ATM,
the customer’s and the account database are interactor VPs.
2. Indirect viewpoints

j
 – Stakeholders who do not use the system themselves but who influence the requirements.
These viewpoints are more likely to provide higher-level organisation requirements and
constraints. In an ATM, management and security staff are indirect viewpoints.
3. Domain viewpoints
– Domain characteristics and constraints that influence the requirements. These viewpoints
normally provide domain constraints that apply to the system. In an ATM, an example
would be standards for inter-bank communications.
Typically, these viewpoints provide different types of requirements.

Viewpoint identification:
• Identify viewpoints using
– Providers and receivers of system services;
– Systems that interact directly with the system being specified;
– Regulations and standards;
– Sources of business and non-functional requirements.
– Engineers who have to develop and maintain the system;
– Marketing and other business viewpoints.

LIBSYS viewpoint hierarchy

j
 Interviewing
In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they
use and the system to be developed.
There are two types of interview
- Closed interviews where a pre-defined set of questions are answered.
- Open interviews where there is no pre-defined agenda and a range ofissues are explored with
stakeholders.
-
Interviews in practice:
• Normally a mix of closed and open-ended interviewing.
• Interviews are good for getting an overall understanding of what stakeholders do and how
they might interact with the system.
• Interviews are not good for understanding domain requirements
– Requirements engineers cannot understand specific domain terminology;

j
 – Some domain knowledge is so familiar that people find it hard to articulate or think that
it isn’t worth articulating.

Effective interviewers:
• Interviewers should be open-minded, willing to listen to stakeholders and should not have
pre- conceived ideas about the requirements.
• They should prompt the interviewee with a question or a proposal and should not
simplyexpect them to respond to a question such as ‘what do you want’.
•
Scenarios:
Scenarios are real-life examples of how a system can be used.
• They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
– A description of the state when the scenario finishes.

Use cases
• Use-cases are a scenario based technique in the UML which identify the actors in an interaction
and which describe the interaction itself.
• A set of use cases should describe all possible interactions with the system.
• Sequence diagrams may be used to add detail to use-cases by showing the sequence ofevent
processing in the system.
•
Article printing use-case:

LIBSYS use cases:

j
 Article printing sequence:

Social and organisational factors

• Software systems are used in a social and organisational context. This can influence or
even dominate the system requirements.
• Social and organisational factors are not a single viewpoint but are influences on allviewpoints.
• Good analysts must be sensitive to these factors but currently no systematic way to tackle
their analysis.

ETHNOGRAPHY:
• A social scientists spends a considerable time observing and analysing how people actually work.
• People do not have to explain or articulate their work.
• Social and organisational factors of importance may be observed.
• Ethnographic studies have shown that work is usually richer and more complex than suggested
by simple system models.

Focused ethnography:
• Developed in a project studying the air traffic control process
j
 • Combines ethnography with prototyping
• Prototype development results in unanswered questions which focus the ethnographic analysis.
• The problem with ethnography is that it studies existing practices which may have some
historical basis which is no longer relevant.

Ethnography and prototyping

j
 Scope of ethnography:
• Requirements that are derived from the way that people actually work rather than the way I
which process definitions suggest that they ought to work.
• Requirements that are derived from cooperation and awareness of other people’s activities.

3) REQUIREMENTS VALIDATION
• Concerned with demonstrating that the requirements define the system that the customer
really wants.
• Requirements error costs are high so validation is very important
– Fixing a requirements error after delivery may cost up to 100 times the cost of fixing
an implementation error.

Requirements checking:
• Validity: Does the system provide the functions which best support the customer’s needs?
• Consistency: Are there any requirements conflicts?
• Completeness: Are all functions required by the customer included?
• Realism: Can the requirements be implemented given available budget and technology
• Verifiability: Can the requirements be checked?

Requirements validation techniques

• Requirements reviews
– Systematic manual analysis of the requirements.
• Prototyping
– Using an executable model of the system to check requirements. Covered in Chapter 17.
• Test-case generation
– Developing tests for requirements to check testability.

Requirements reviews:
• Regular reviews should be held while the requirements definition is being formulated.
• Both client and contractor staff should be involved in reviews.
• Reviews may be formal (with completed documents) or informal. Good communications
between developers, customers and users can resolve problems at an early stage.

Review checks:
• Verifiability: Is the requirement realistically testable?
• Comprehensibility: Is the requirement properlyunderstood?
• Traceability: Is the origin of the requirement clearlystated?
• Adaptability: Can the requirement be changed without a large impact on other requirements?

4) REQUIREMENTS MANAGEMENT
• Requirements management is the process of managing changing requirements during
the requirements engineering process and system development.
• Requirements are inevitably incomplete and inconsistent
– New requirements emerge during the process as business needs change and a
better understanding of the system is developed;
– Different viewpoints have different requirements and these are oftencontradictory.

Requirements change
• The priority of requirements from different viewpoints changes during the developmentprocess.
• System customers may specify requirements from a business perspective that conflict withend-user
requirements.
• The business and technical environment of the system changes during its development.

j
 Requirements evolution:

Enduring and volatile requirements:

• Enduring requirements: Stable requirements derived from the core activity of the customer
organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain
models
• Volatile requirements: Requirements which change during development or when the system is in
use. In a hospital, requirements derived from health-care policy
Requirements classification:
Requirement Description
Type
Mutable Requirements that change because of changes to the environment in which the
requirements organisation is operating. For example, in hospital systems, the funding of patient
care may change and thus require different treatment information to be collected.
Emergent Requirements that emerge as the customer's understanding of the system develops
requirements during the system development. The design process may reveal new emergent
requirements.
Consequential Requirements that result from the introduction of the computer system. Introducing
requirements the computer system may change the organisations processes and open up new ways
of working which generate new system requirements
Compatibility Requirements that depend on the particular systems or business processes within an
requirements organisation. As these change, the compatibility requirements on the commissioned
or delivered system may also have to evolve.

Requirements management planning:

• During the requirements engineering process, you have to plan:
– Requirements identification
• How requirements are individually identified;
– A change management process
• The process followed when analysing a requirements change;
– Traceability policies
• The amount of information about requirements relationships that is maintained;
– CASE tool support
• The tool support required to help manage requirements change;

Traceability:
Traceability is concerned with the relationships between requirements, their sources and the system design
• Source traceability
– Links from requirements to stakeholders who proposed these requirements;
• Requirements traceability
– Links between dependent requirements;
• Design traceability - Links from the requirements to the design;

j
 CASE tool support:
• Requirements storage
– Requirements should be managed in a secure, managed data store.
• Change management
– The process of change management is a workflow process whose stages can
bedefined and information flow between these stages partially automated.
• Traceability management
– Automated retrieval of the links between requirements.

Requirements change management:

• Should apply to all proposed changes to the requirements.
• Principal stages
– Problem analysis. Discuss requirements problem and propose change;
– Change analysis and costing. Assess effects of change on other requirements;
– Change implementation. Modify requirements document and other documents to
reflect change.

Change management:

SYSTEM MODELLING
System modelling helps the analyst to understand the functionality of the system and models are
used to communicate with customers.
 Different models present the system from different perspectives
o Behavioural perspective showing the behaviour of the system;
o Structural perspective showing the system or data architecture.
Model types
 Data processing model showing how the data is processed at different stages.
 Composition model showing how entities are composed of other entities.
 Architectural model showing principal sub-systems.
 Classification model showing how entities have common characteristics.
 Stimulus/response model showing the system’s reaction to events.

1) CONTEXT MODELS:
 Context models are used to illustrate the operational context of a system - they show what lies
outside the system boundaries.
 Social and organisational concerns may affect the decision on where to position
system boundaries.
 Architectural models show the system and its relationship with other systems.

j
 The context of an ATM system:

Process models:
 Process models show the overall process and the processes that are supported by the system.
 Data flow models may be used to show the processes and the flow of information from
one process to another.

2) BEHAVIOURAL MODELS:
 Behavioural models are used to describe the overall behaviour of a system.
 Two types of behavioural model are:
o Data processing models that show how data is processed as it moves through the system;
o State machine models that show the systems response to events.
 These models show different perspectives so both of them are required to describe the
system’s behaviour.

Data-processing models:
 Data flow diagrams (DFDs) may be used to model the system’s data processing.
 These show the processing steps as data flows through a system.
 DFDs are an intrinsic part of many analysis methods.
 Simple and intuitive notation that customers can understand.
 Show end-to-end processing of data.

Order processing DFD:

j
 Data flow diagrams:
 DFDs model the system from a functional perspective.
 Tracking and documenting how the data associated with a process is helpful to develop an
overall understanding of the system.
 Data flow diagrams may also be used in showing the data exchange between a system and
other systems in its environment.

State machine models:

 These model the behaviour of the system in response to external and internal events.
 They show the system’s responses to stimuli so are often used for modelling real-time systems.
 State machine models show system states as nodes and events as arcs between these nodes.
When an event occurs, the system moves from one state to another.
 Statecharts are an integral part of the UML and are used to represent state machine models.

Statecharts:
 Allow the decomposition of a model into sub-models (see following slide).
 A brief description of the actions is included following the ‘do’ in each state.
 Can be complemented by tables describing the states and the stimuli.

Microwave oven model:

Microwave oven state description:

State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows the cooking time
selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ‘Not
ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’.

j
 Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On
completion of cooking, the buzzer is sounded for 5 seconds. Oven light is on. Display
shows ‘Cooking complete’ while buzzer is sounding.

Microwave oven stimuli:

Stimulus Description
Half power The user has pressed the half power button
Full power The user has pressed the full power button
Timer The user has pressed one of the timer buttons
Number The user has pressed a numeric key
Door open The oven door switch is not closed
Door closed The oven door switch is closed
Start The user has pressed the start button
Cancel The user has pressed the cancel button

3) SEMANTIC DATA MODELS:

 Used to describe the logical structure of data processed by the system.
 An entity-relation-attribute model sets out the entities in the system, the relationships between
these entities and the entity attributes
 Widely used in database design. Can readily be implemented using relationaldatabases.
 No specific notation provided in the UML but objects and associations can be used.

Data dictionaries
 Data dictionaries are lists of all of the names used in the system models. Descriptions of
the entities, relationships and attributes are also included.
 Advantages
o Support name management and avoid duplication;
o Store of organisational knowledge linking analysis, design and implementation;
 Many CASE workbenches support data dictionaries.

4) OBJECT MODELS:
 Object models describe the system in terms of object classes and their associations.
 An object class is an abstraction over a set of objects with common attributes and theservices
(operations) provided by each object.
 Various object models may be produced
o Inheritance models;
o Aggregation models;
o Interaction models.
 Natural ways of reflecting the real-world entities manipulated by the system
 More abstract entities are more difficult to model using this approach
 Object class identification is recognised as a difficult process requiring a deep understanding
of the application domain
 Object classes reflecting domain entities are reusable across systems

Inheritance models:
 Organise the domain object classes into a hierarchy.
 Classes at the top of the hierarchy reflect the common features of allclasses.
 Object classes inherit their attributes and services from one or more super-classes. these may
then be specialised as necessary.

j
  Class hierarchy design can be a difficult process if duplication in different branches isto be
avoided.

Object models and the UML:

 The UML is a standard representation devised by the developers of widely used object-
oriented analysis and design methods.
 It has become an effective standard for object-oriented modelling.
 Notation
o Object classes are rectangles with the name at the top, attributes in the middle sectionand
operations in the bottom section;
o Relationships between object classes (known as associations) are shown as lines linking
objects;
o Inheritance is referred to as generalisation and is shown‘upwards’ rather than
‘downwards’ in a hierarchy.

Library class hierarchy:

User class hierarchy:

j
 Multiple inheritance:
 Rather than inheriting the attributes and services from a single parent class, a system which
supports multiple inheritance allows object classes to inherit from several super-classes.
 This can lead to semantic conflicts where attributes/services with the same name indifferent
super-classes have different semantics.
 Multiple inheritance makes class hierarchy reorganisation more complex.

Multiple inheritance

Object aggregation:
 An aggregation model shows how classes that are collections are composed of other classes.
 Aggregation models are similar to the part-of relationship in semantic data models.

Object aggregation

Object behaviour modelling

j
  A behavioural model shows the interactions between objects to produce some particular
system behaviour that is specified as a use-case.
 Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction
between objects.

5) STRUCTURED METHODS:
 Structured methods incorporate system modelling as an inherent part of the method.
 Methods define a set of models, a process for deriving these models and rules and guidelines
that should apply to the models.
 CASE tools support system modelling as part of a structured method.

Method weaknesses:
 They do not model non-functional system requirements.
 They do not usually include information about whether a method is appropriate for a
given problem.
 The may produce too much documentation.
 The system models are sometimes too detailed and difficult for users to understand.

CASE workbenches:
 A coherent set oftools that is designed to support related software process activities such as
analysis, design or testing.
 Analysis and design workbenches support system modelling during both requirements
engineering and system design.
 These workbenches may support a specific design method or may provide support for
acreating several different types of system model.

An analysis and design workbench

j
 Analysis workbench components:
 Diagram editors
 Model analysis and checking tools
 Repository and associated query language
 Data dictionary
 Report definition and generation tools
 Forms definition tools
 Import/export translators
 Code generation tools

j
j