Software Engineering

Dr. Luxmi Sapra

Associate Professor
School of Computing
 Syllabus
• UNIT-1: Introduction: Introduction to software engineering, Importance of
software, The evolving role of software, Software Characteristics, Software
Components, Software Applications, Software Crisis, Software engineering
problems.
Software Development Life Cycle Models: Water Fall Model, Incremental
Model, RAD, Prototyping, Spiral Model, comparisons, advantages and
disadvantages of models.

• UNIT-2 Software Requirement Engineering: Requirements elicitation, Problem

Analysis, Requirement specifications characteristics, Components of SRS, SRS
Document.

• Software-Design: Design principles, problem partitioning, abstraction, top down

and bottom up-design, Structured approach, functional versus object oriented

approach, design specifications and verification, Monitoring and Control,

Cohesiveness, coupling, Fourth generation techniques, Functional independence.
 Syllabus
UNIT-3: Coding: Top-Down and Bottom –Up programming, Structured Programming,
Information hiding, programming style and internal documentation.
Testing: Testing principles, Levels of testing, functional testing, structural testing, test
plane, test case specification, reliability assessment, software testing strategies, Verification
& validation, Unit testing, Integration Testing, Alpha & Beta testing, system testing and
debugging, Software Maintenance.

UNIT-4: Software Reliability & Quality Assurance: Reliability issues, Reliability

metrics, Role of matrices and measurement, Reliability growth modeling, Software quality,
ISO 9000 certification for software industry, SEI capability maturity model, and comparison
between ISO & SEI CMM.
UNIT-5: Software Project Management: The Management spectrum- (The people, the
product, the process, the project), cost estimation, project scheduling, staffing, software
configuration management, quality assurance, project monitoring, risk management, Role of
management in software development.
CASE (Computer Aided Software Engineering): CASE and its Scope, CASE support in
software life cycle, Documentation, Project Management, internal interface, Reverse
Software Engineering, Architecture of CASE environment.
 Introduction to Software Engineering

• The era of electronic computers started in

1940s. The initial efforts of improvement were
mainly focused on hardware.

• With the improvement in the field of electronics,

hardware became very effective by 1960s. At
this time, programming techniques available
were not very effective and so, we were not
exploiting hardware capabilities fully.
• The software development techniques were
adhoc and programming-centered. These
adhoc or programming-centered approach may
work for small problems, but for the large and
complex problems/projects, these techniques
generally do not work.

• As a result of this, computing world found

itself in a crisis, which is known as “software
crisis”.
 Software Crisis

Software Crisis:-
• A set of problems encountered in the
development of computer software during
1960s.
• Poor quality s/w developed.
• Schedules & cost estimates were often grossly
inaccurate.
 Software Crisis
A number of large size projects failed called software runaways because of
following reasons:

• Development teams exceeding the budget

• Late delivery of software
• Poor quality
• User requirements not completely supported by the software
• Difficult maintenance
• Unreliable software
• Lack of communication between s/w developers and users.
• Lack of understanding of the problem
 Software Crisis
Statistics show that :
•only 2% of the projects were used as they were delivered,
• 3% of the projects used after modifications,
•47% of the software was never used only delivered,
•19% of the software rejected or reworked and
• 29% was not even delivered.

The problems increased because of increased dependence of

business on software and lack of systematic approach to build
the software.

Developers and researchers realized that development of

software was not an easy and straight forward task, instead it
required lot of engineering principles.
• To control this software crisis, some scientific
and systematic approach is needed for
software development.

• To overcome this problem of software crisis,

NATO science committee held two conferences
in the 1960s in Europe. This is where the term
‘software engineering’ was coined.
Definition Software Engineering
•Apply Engineering Concepts to developing Software.

• Challenge for Software Engineers is to produce high

quality software with finite amount of resources & within
a predicted schedule.

• Definition of Engineering
-Application of science, tools and methods to find cost
effective solution to problems

Definition of SOFTWARE ENGINEERING

- SE is defined as systematic, disciplined and quantifiable
approach for the development, operation and maintenance
of software
 Software
•Software can be defined as a set of instructions which when executed on a
computer accepts the inputs and after doing required computations produces the
output or result as per users requirements. Additionally it is also accompanied by
the user manual so as to understand the features and working of the software.
Software consist of the following:
Source Code
Executables
User manuals
Requirement analysis and design documents
 Installation manuals
Software Components
 Software Characteristics

• When hardware is built, the human creative

process (analysis, design, construction, testing) is
ultimately translated into a physical form.

• If we build a new computer, our initial sketches,

formal design drawings, and bread boarded
prototype evolve into a physical product (chips,
circuit boards, power supplies, etc.).
 Software Characteristics

Since software is purely logical rather than a physical system

element, it therefore, has characteristics that are entirely different
than those of hardware:
 Software is developed or engineered but it is not manufactured
in the classical sense:

Hardware Failure Curve

When a hardware component wears out, it is replaced by a spare part.

 Software Products: Failure curve for Software

• Software Idealized and Actual Failure Curves

Figure : Software Idealized and Actual Failure Curves

There are no software spare parts. Every software failure indicates an

error in design or in the process through which design was translated
into machine executable code. Therefore, software maintenance involves
considerably more complexity
  Software Products: Manufacturing vs.
Development
• Once a hardware product has been manufactured, it is
difficult or impossible to modify. In contrast, software
products are routinely modified and upgraded.

• In hardware, hiring more people allows you to

accomplish more work, but the same does not
necessarily hold true in software engineering.
  Software Products: Component Based vs.
Custom Built

• Hardware products typically employ many

standardized design components.

• Most software continues to be custom built.

 Software Products: Hardware vs.
Software
Hardware Software

 Manufactured  Developed/ engineered

 wear out  deteriorate
 Built using  Custom built
components  Complex
 Relatively simple
 Summary Software
Characteristic
• Software is developed or engineered, it is not
manufactured in the classical sense.
• Software doesn't "wear out
• Reusability of Component
• Software is flexible
 Evolving Role of Software

Software is a product
• Transforms information - produces, manages, acquires,
modifies, displays, or transmits information
• Delivers computing potential of hardware and networks
Software is a vehicle for delivering a product
• Controls other programs (operating system)
• Effects communications (networking software)
• Helps build other software (software tools & environments)
 Software Applications
• System Software:
• System software: System software is a collection of programs
and utilities for providing service to other programs. Other
system applications (e.g., operating system components,
drivers, telecommunications processors) process largely
indeterminate data.
• In either case, the system software area 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; and multiple external interfaces.
Ex. Compilers, operating system, drivers etc.
Engineering /Scientific software:

Engineering and scientific software: Engineering and scientific software

have been characterized by "number crunching" algorithms. Applications
range from astronomy to volcanology, from automotive stress analysis to
space shuttle orbital dynamics, and from molecular biology to automated
manufacturing.

However, modern applications within the engineering/scientific area are

moving away from conventional numerical algorithms.

Computer-aided design, system simulation, and other interactive

applications have begun to take on real-time and even system software
characteristics.
Ex. Computer Aided Design (CAD), system stimulation etc.
• Embedded Software:
• Embedded software: Embedded software resides in read-only
memory and is used to control products and systems for the
consumer and industrial markets. Embedded software can
perform very limited and esoteric functions (e.g., keypad
control for a microwave oven) or provide significant function
and control capability (e.g., digital functions in an automobile
such as fuel control, dashboard displays, and braking systems).
• Personal computer software:
• The personal computer is the type of computer,
which gave revolution to the information
technology.
• The personal computer software market has flourish
over the past two decades. Word processing,
spreadsheets, computer graphics, multimedia,
entertainment, database management, personal and
business financial applications, external network,
and database access are only a few of hundreds of
applications.
• Artificial Intelligence software
• Artificial intelligence (AI) software is the software, which thinks and behaves
like a human. AI software makes use of non-numerical algorithms to solve
complex problems that are not amenable to computation or straightforward
analysis. Expert systems, also called knowledge-based systems, pattern
recognition (image and voice), artificial neural networks, theorem proving, and
game playing are representative of applications within this category.
Ex. Robotics, expert system, game playing, etc.
• Web based Software
• Web-based software: The Web pages processed by the browser are the software
that incorporates executable instructions (e.g., CGI, HTML, PERL, or Java), and
data (e.g. hypertext and a variety of visual and audio formats). In essence, the
network becomes a massive computer providing an almost unlimited software
resource that can be accessed by anyone with a modem.
Real-time software: Software for the
monitors/analyzes/controls real-world events as they occur is
called real time.

Elements of real-time software include a data-gathering

component that collects and formats information from an
external environment, an analysis component that transforms
information as required by the application, a control/output
component that responds to the external environment, and a
monitoring component that coordinates all other components
so that real-time response can be maintained.
Business software: Business information processing is the largest
single software application area. In a broad sense, business software is
an integrated software and has many components related to a
particular field of the business.

Discrete "systems" for example, payroll, accounts receivable/payable,

inventory have evolved into management information system (MIS)
software that accesses one or more large databases containing business
information. Applications in this area restructure existing data in a way
that facilitates business operations or management decision-making. In
addition to conventional data processing application, business software
applications also encompass interactive computing
 Applications

These are various ranges of applications of software.

Software Development Life Cycle
 Software Development Life Cycle

•The various activities that are undertaken when developing software are
commonly modeled as a software development life cycle (SDLC).

•The SDLC begins with the identification of requirements for software and
ends with the retirement of the software.

•Developers should be able to deliver good quality software to the end users
using a well defined, well managed, consistent and cost-effective process.

•A software life cycle model is a type of process that represents the order also in
which the activities will take place. It describes the sequence of activities
graphically to build the final product. As different phases may follow one
another, repeat themselves or even run concurrently, the sequence may or may
not be linearly sequential.
Software Development Life Cycle
 Software Development Life Cycle

•Each of these phases will have different activities to meet its objectives. The process starts by
collecting the user requirements and representing them in a suitable form which must be
understandable by developers, analyst, users, testers and all other stake holders of the project.

•This stage is called the requirements analysis stage and the output of this stage is a document
called Requirement Specification Document (RSD) or Software Requirement
Specification(SRS).

•System design stage focuses on high level design of software.

•In program implementation stage actual coding is done and thereafter product is tested to
ensure an error free product.

•Once the product is delivered, it’s maintenance is done by the organization.

 Software Life Cycle Models/
SOFTWARE PROCESS MODELS
• Help in the software development

• Guide the software team through a set of

framework activities

• Process Models may be linear, incremental or

evolutionary
 THE WATERFALL
MODEL
• Used when requirements are well understood
in the beginning
• Also called classic life cycle
• A systematic, sequential approach to Software
development
• Begins with customer specification of
Requirements and progresses through
planning, modeling, construction and
deployment
Sequential model encompasses the following activities:
• System/information engineering and modeling.
Because software is always part of a larger system (or business), work begins by
establishing requirements for all system elements and then allocating some subset of
these requirements to software.
This system view is essential when software must interact with other elements such as
hardware, people, and databases.

• System engineering and analysis encompass requirements gathering at the system

level with a small amount of top level design and analysis. Information engineering
encompasses requirements gathering at the strategic business level and at the
business area level.

• Software requirements analysis.

The requirements gathering process is intensified and focused specifically on
software. To understand the nature of the program(s) to be built, the software engineer
("analyst") must understand the information domain
for the software, as well as required function, behavior, performance,
and interface. Requirements for both the system and the software are documented and
reviewed with the customer.
Design
Software design is actually a multistep process that
focuses on four distinct attributes of a program: data
structure, software architecture, interface representations,
and procedural (algorithmic) detail. The design process
translates requirements into a representation of the
software that can be assessed for quality before coding
begins. Like requirements, the design is documented and
becomes part of the software configuration.

Code generation
The design must be translated into a machine-readable
form. The code generation step performs this task. If
design is performed in a detailed manner, code generation
can be accomplished mechanistically.
Testing
Once code has been generated, program testing begins. The testing
process focuses on the logical internals of the software, ensuring that all
statements have been tested, and on the functional externals; that is,
conducting tests to uncover errors and ensure that defined input will
produce actual results that agree with required results.

Support
Software will undoubtedly undergo change after it is delivered to the
customer (a possible exception is embedded software). Change will occur
because errors have been encountered, because the software must be
adapted to accommodate changes in its external environment (e.g., a
change required because of a new operating system or peripheral device),
or because the customer requires functional or performance
enhancements. Software support/maintenance reapplies each of the
preceding phases to an existing program rather than a new one.
 The model implies that you should attempt to
complete a given stage before moving on to the next
stage
 Does not account for the fact that requirements
constantly change.
 It also means that customers can not use anything
until the entire system is complete.
 Surprises at the end are very expensive
 Therefore, this model is only appropriate when the
requirements are well-understood and changes will
be fairly limited during the design process.
 Limitations of the
waterfall model
• Problems:
1. Real projects are rarely follow the sequential model.
2. Difficult for the customer to state all the requirement
explicitly.
3. Assumes patience from customer - working version of
program will not available until programs not getting change
fully.
When to use the waterfall model
 This model is used only when the requirements are very well known,
clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely and The
project is short.

In Waterfall model, very less customer interaction is involved during the

development of the product. Once the product is ready then only it can
be demonstrated to the end users.
Once the product is developed and if any failure occurs then the cost of
fixing such issues are very high, because we need to update everything
from document till the logic.
 Evolutionary Process
Model
• Produce an increasingly more complete
version of the software with each iteration.
• Evolutionary Models are iterative.
• Evolutionary models are:
– Prototyping
– Spiral Model
Evolutionary Process
Models : Prototyping
 Prototyping
• Prototyping start with communication, between a
customer and software engineer to define overall
objective, identify requirements and make a boundary.
• Going ahead, planned quickly and modeling (software
layout visible to the customers/end-user) occurs.
• Quick design leads to prototype construction.
• Prototype is deployed and evaluated by the customer/user.
• Feedback from customer/end user will refine requirement
and that is how iteration occurs during prototype to satisfy
the needs of the customer.
• Best approach when:
– Objectives defines by customer are general but does not
have details like input, processing, or output
 Prototyping (cont..)
 Prototype can be serve as “the first system”.
 Both customers and developers like the prototyping paradigm.
 Customer/End user gets a feel for the actual system
 Developer get to build something immediately.

Problem Areas:
 Customer cries foul and demand that “a few fixes” be applied to
make the prototype a working product, due to that software
quality suffers as a result.
 Developer often makes implementation in order to get a
prototype working quickly without considering other factors in
mind like OS, Programming language, etc.

Customer and developer both must be agree that the prototype is

built to serve as a mechanism for defining requirement.
 Spiral Model

• Spiral models uses prototyping as a risk reduction mechanism but, more

important, enables the developer to apply the prototyping approach at each
stage in the evolution of the product.

• It maintains the systematic stepwise approach suggested by the classic life

cycle but also incorporates it into an iterative framework activity.
• If risks cannot be resolved, project is immediately terminated
Problem Area:
• It may be difficult to convince customers (particularly in contract
situations) that the evolutionary approach is controllable.
• If a major risk is not uncovered and managed, problems will undoubtedly
occur.
 Spiral Model
Couples iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model

• It provide potential for rapid development of increasingly

more complete version of the software.
• Using spiral, software developed in as series of evolutionary
release.
– Early iteration, release might be on paper or prototype.
– Later iteration, more complete version of software.
• Evolutionary process begins in a clockwise direction,
beginning at the center risk.
• First circuit around the spiral might result in development of a
product specification. Subsequently, develop a prototype and
then progressively more sophisticated version of software.
• Unlike other process models that end when software is
delivered.
• It can be adapted to apply throughout the life of software.
 Spiralmodel
Spiral modelsectors
of the
software process
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analysis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
 Spiral model sectors
• Objective setting
– Specific objectives for the phase are identified
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the
key risks
• Development and validation
– A development model for the system is chosen which can
be any of the generic models
• Planning
– The project is reviewed and the next phase of the spiral is
planned
 The Incremental Model
• The incremental model combines elements of the linear
sequential model (applied repetitively) with the iterative
philosophy of prototyping
• 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. It should be
noted that the process flow for any increment can
incorporate the prototyping paradigm.
 Incremental Process
Model

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

Delivers software in small but usable pieces, each piece builds on pieces
already delivered
 The Incremental Model
• Rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment delivering
part of the required functionality.
• First Increment is often core product
– Includes basic requirement
– Many supplementary features (known & unknown) remain undelivered
• A plan of next increment is prepared
– Modifications of the first increment
– Additional features of the first increment
• It is particularly useful when enough staffing is not available for the whole
project
• Increment can be planned to manage technical risks.
• Incremental model focus more on delivery of operation product with each
increment.
 The Incremental Model

• User requirements are prioritised and the highest priority requirements

are included in early increments.
• Once the development of an increment is started, the requirements are
frozen though requirements for later increments can continue to evolve.
• Customer value can be delivered with each increment so system
functionality is available earlier.
• Early increments act as a prototype to help elicit requirements for later
increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most testing.
 Advantages of Incremental model:

• Generates working software quickly and early during the

software life cycle.
• This model is more flexible – less costly to change
scope and requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified
and handled during it’d iteration
 Disadvantages of Incremental model:

• Needs good planning and design.

• Needs a clear and complete definition of the
whole system before it can be broken down
and built incrementally.
 Rapid Application Development (RAD) Model

Makes heavy use of reusable software components with an extremely short

development cycle
 Rapid application development (RAD)

Rapid application development (RAD) is an incremental software

development process model that emphasizes an extremely short
development cycle.

The RAD model is a “high-speed” adaptation of the linear

sequential model in which rapid development is achieved by
using component-based construction.

If requirements are well understood and project scope is

constrained, the RAD process enables a development team to
create a “fully functional system” within very short time periods
(e.g., 60 to 90 days) Used primarily for information systems
applications, the RAD approach encompasses the following
phases
 RAD model Phases
• Business modeling. The information flow among business functions is
modeled in a way that answers the following questions: What information
drives the business process? What information is generated? Who
generates it? Where does the information go? Who processes it?
Business modeling – Information flow among business is working.
Ex. What kind of information drives?
Who is going to generate information?
From where information comes and goes?

• Data modeling. The information flow defined as part of the business modeling phase
is refined into a set of data objects that are needed to support the business. The characteristics
(called attributes) of each object are identified and the relationships between
these objects defined.

Data modeling – Information refine into set of data objects that are needed to support business.
Process modeling. The data objects defined in the data modeling
phase are transformed to achieve the information flow necessary to
implement a business function. Processing descriptions are created for
adding, modifying, deleting, or retrieving a data object.

Application generation. RAD assumes the use of fourth generation

techniques Rather than creating software using conventional third
generation programming languages the RAD process works to reuse
existing program components (when possible) or create reusable
components (when necessary). In all cases, automated tools are used to
facilitate construction of the software.

Testing and turnover. Since the RAD process emphasizes reuse,

many of the program components have already been tested. This
reduces overall testing time. However,
new components must be tested and all interfaces must be fully exercised.
 RAD model
– Process modeling – Data object transforms to information flow necessary to
implement business.

• If requirement are well understood and project scope is

constrained then it enable development team to create “ fully
functional system” within a very short time period.
 Advantages of the RAD model

• Reduced development time.

• Increases reusability of components
• Quick initial reviews occur Encourages
customer feedback
• Integration from very beginning solves a lot of
integration issues.
 Disadvantages of RAD model
• Depends on strong team and individual
performances for identifying business
requirements.
• Only system that can be modularized can be
built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of
modeling and automated code generation is very
high
MODELS STRENGTH WEAKNESS TYPES OF PROJECT
For well-understood
Simple approach.
problem.
Simple. Do not allow changes.
Waterfall Short duration project.
Easy to execute. Cycle time is too long.
Model Automation of
Intuitive & logical. User feedback is not
adjusting manual
allowed.
system.
Helps in requirement System With massive
Possibly higher cost.
Prototyping elicitation. users.
Do not allow labour
Model Reduce the risk. Uncertainty in
charges.
Lead to a better system. requirement.
Each Iteration Can
Have Planning Over
Head.
Regular/Quick Cost may increase as For a business where
delivery. work done in one time is of the essence.
Iterative Enhancement
Reduces risk. iteration may have to Where the risk of the
Model
accumulate Changes. be undone later. long project can be
prioritizes requirement. System design & taken.
structure may suffer as
frequent changes are
made.
No strict standard for
Control project risk. software development.
Spiral Project build on
Very flexible. No particular began
Model untested assumptions
Less document needed. and ending of the
particular phase
 UNIT-2

Software Requirement Engineering:

Requirements elicitation, Problem Analysis,
Requirement specifications characteristics,
Components of SRS
Software-Design: Design principles, problem
partitioning, abstraction, top down and bottom up-
design, Structured approach, functional versus object
oriented approach, design specifications and
verification, Monitoring and Control, Cohesiveness,
coupling, Fourth generation techniques, Functional
independence
Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer.

All these functionalities need to be necessarily incorporated into the system

as a part of the contract.

These are represented or stated in the form of input to be given to the system,
the operation performed and the output expected.

They are basically the requirements stated by the user which one can see
directly in the final product, unlike the non-functional requirements.

For example, in a hospital management system, a doctor should be able to

retrieve the information of his patients. Each high-level functional requirement
may involve several interactions or dialogues between the system and the
outside world. In order to accurately describe the functional requirements, all
scenarios must be enumerated.
Non-functional requirements: These are basically the quality constraints that
the system must satisfy according to the project contract. The priority or extent
to which these factors are implemented varies from one project to other. They
are also called non-behavioral requirements.

They basically deal with issues like:

• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Steps of Requirements
Engineering

71
 Requirements Engineering Processes
• Requirements elicitation;
– What services do the end-users require of the system?
• Requirements analysis;
– How do we classify, prioritise and negotiate requirements?
• Requirements validation;
– Does the proposed system do what the users require?
• Requirements management.
– How do we manage the (sometimes inevitable) changes to the requirements
document?

72
 Example
Patient records system
(Elicitation) 1. Talk to patients, doctors, nurses, receptionists, managers to
find out
Current system practise, legal restrictions , problems with current system, needs for
improvement, security issues, costs
(Elicitation) 2. Develop draft documentation and review what is most
important, what will it cost, what is the timescale, is new hardware required
(Validation) 3. Send requirements to end users. Present them with Q&A.
Go back to step 1, discuss requirements again
(Management) 4. Have a yearly review of requirements between all
stakeholders. Have a system of reviewing the cost and feasability of change
to system

73
 Elicitation and analysis
• Requirement elicitation is the process of gathering the
requirement. In this process the technical professional in the
organization, like softwae developers and the system
engineers, work together with the users of the system and the
customers. This process is useful in finding the problems that
has to be solved. The problems include
• 1. What the proposed system should provide?
• 2. What are the expected services from the system?
• 3. What are the required characteristics of the system?
• 4. What are the required hardware and software constrains of
the system?
 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, domain experts,
trade unions, etc. These are called stakeholders
 Requirement Elicitation
Techniques

• Interviews
• Brainstorming session (Group Discussion)
• FAST
• Use Case
 Interviews
Interviews are the commonly used and most popular methods for
requirement elicitation. In this method the analyst and the
engineers of the requirements engineering process discuss with
the different types of stakeholders to understand the requirements
of the system and the objective they have to fulfill in the system.

Interview techniques should be used for building strong

relationships between business analysts and stakeholders. In this
technique, the interviewer directs the question to stakeholders to
obtain information

If the interviewer has a predefined set of questions then it’s

called a structured interview.

If the interviewer is not having any particular format or any specific

questions then it’s called an unstructured interview.
 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 of issues are explored with
stakeholders.
• Ideally, interviewers should be open-minded, willing
to listen to stakeholders and should not have pre-
conceived ideas. 78
Basic Rules:
• The overall purpose of performing the interviews
should be clear.
• Identify the interviewees in advance.
• Interview goals should be communicated to the
interviewee.
• Interview questions should be prepared before the
interview.
• The location of the interview should be predefined.
• The time limit should be described.
• The interviewer should organize the information and
confirm the results with the interviewees as soon as
possible after the interview.
Brainstorming

The requirements elicitation process begins with brainstorming. To facilitate

focused and fruitful brainstorming sessions, business analysts should set up a
team with representatives of all stakeholders for capturing new ideas. Suggestions
coming out of brainstorming sessions should be properly documented in order to
draft the plan of action.

• It is a group technique
• It is intended to generate lots of new ideas hence providing a platform to share
views
• A highly trained facilitator is required to handle group bias and group conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of requirements and
their priority if possible.
This technique is used to generate new ideas and find a solution for a specific
issue. The members included for brainstorming can be domain experts, subject
matter experts. Multiple ideas and information give you a repository of knowledge
and you can choose from different ideas.

This session is generally conducted around the table discussion. All participants
should be given an equal amount of time to express their ideas

Brainstorming technique is used to answer the below questions:

• What is the expectation of a system?
• What are the risk factors that affect the proposed system development and
what to do to avoid that?
• What are the business and organization rules required to follow?
• What are the options available to resolve the current issues?
• What should we do so that this particular issue does not happen in the future?
 FAST (Facilitated Application
Specification Technique)
It’s objective is to bridge the expectation gap – difference between what the
developers think they are supposed to build and what customers think they are
going to get.

A team oriented approach is developed for requirements gathering.

Each attendee is asked to make a list of objects that are-

• Part of the environment that surrounds the system
• Produced by the system
• Used by the system

Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, team is divided into smaller sub-teams to develop mini-
specifications and finally a draft of specifications is written down using all the
inputs from the meeting.
 Use Case apporach

• This technique combines text and pictures to

provide a better understanding of the
requirements.
• The use cases describe the ‘what’, of a system
and not ‘how’.
• Hence, they only give a functional view of the
system. The components of the use case
design includes three major things – Actor,
Use cases, use case diagram.
 Use Cases

• In a use-case diagram, an actor is a user of the

system (i.e. Something external to the system;
can be human or non-human) acting in a
particular role.
• A use-case is a task which the actor needs to
perform with the help of the system, e.g., find
details of a book or print a copy of a receipt in a
bookshop.
84
 Use Case diagrams, basic UML notation
 Use Case: A Use Case is a description of a set of
interactions between a user and the system.
 Components of use case diagram:
 Actor
 Use case
use case name
 System boundary
 Relationship
use case name

use case name

 Introduction
Use-cases are descriptions of the functionality of a system
from a user perspective.
 Depict the behaviour of the system, as it appears to an outside
user.
 Describe the functionality and users (actors) of the system.
 Show the relationships between the actors that use the system,
the use cases (functionality) they use, and the relationship
between different use cases.
 Document the scope of the system.
 Illustrate the developer’s understanding of the user’s
requirements.
 ACTOR
 An actor is some one or something that must interact
with the system under development
 Actors can be human or automated systems.
 Actors are not part of the system.
 UML notation for actor is stickman, shown below.

Student Faculty Employee

 ACTOR (contd..)

• It is role a user plays with respect to system.

• Actors carry out use cases and a single actor

may perform more than one use cases.

• Actors are determined by observing the direct

uses of the system
 Primary and Secondary
Actors
• Primary Actor
– Acts on the system
– Initiates an interaction with the system
– Uses the system to fulfill his/her goal
– Events Something we don’t have control over
• Secondary Actor
– Is acted on/invoked/used by the system
– Helps the system to fulfills its goal
– Something the system uses to get its job done
 USE CASE
What is USE case?
 A use case is a pattern of behavior, the system exhibits
 The purpose of a use case is to define a piece of
coherent behavior without revealing the internal
structure of the system
 The use cases are sequence of actions that the user
takes on a system to get particular target
 USE CASE is dialogue between an actor and the system.
• Examples:
Add a course
 Contd..

• A use case typically represents a major piece of

functionality that is complete from beginning to end.
• Most of the use cases are generated in initial phase,
but may add some more after proceeding.
• A use case may be small or large. It captures a broad
view of a primary functionality of the system in a
manner that can be easily grasped by non technical
user.
 System Boundary
 It is shown as a rectangle.
 It helps to identify what is external versus internal, and
what the responsibilities of the system are.
 The external environment is represented only by actors.
 Relationship
• Relationship is an association between use case and actor.
• There are several Use Case relationships:

 Association

 Extend

 Generalization

 Uses

 Include
 Extend Relationship
 The extended relationship is used to indicate that use case
completely consists of the behavior of another use case at
one or specific point
• The insertion of additional behavior into a base use case
that does not know about it
 The base use case implicitly incorporates the behavior of
another use case at certain points called extension points
 It is shown as a dotted line with an arrow point and
labeled <<extend>>

<< extend>>
Register
Login
New User
 Generalization
 Generalization is a relationship between a
general use case and a more specific use case
that inherits and extends features to it
 use cases that are specialized versions of other
use cases
 It is shown as a solid line with a hollow arrow
point
 Include Relationship
• The insertion of additional behavior into a base use case
that explicitly describes the insertion
 The base use case explicitly incorporates the behavior of
another use case at a location specified in the base.
 They are shown as a dotted line with an open arrow and
the key word <<include>>
Reserve a ticket use case
 Example

place
place <<extend>>
conference
phone call
call
cellular
network receive
receive <<extend>>
additional
phone call
call

use
user scheduler
Cellular Telephone

98
 ATM machine

• Actors
– Customers
– Bank staff
– ATM service engineer
• Use cases
– Withdraw cash
– Check balance
– Add cash to machine
– Check security video recording
99
Example - ATM Use
Case Diagram

100
 Student Management
system
An organization wants to develop the system based on following
Requirements:

1. Students have to register first through fill up the registration form.

2. Faculty can prepare the grade sheet of concern subjects.
3. Student and faculty can see the result of each student.
4. Faculty can generate the report about registered students.
5. System can verify the students Registration Details First.
6. Student may have to fill up the hostel details during registration
process.
Design a use case where

Student can view the course, can enroll the course, can pay the fees,
can change the course, faculty can teach the course.

Non register students can only view the course

Student Management
System
 Food ordering system

Draw use case diagram for food ordering system. Where a customer can order
food items after viewing the menu. For ordering the food customer needs to
register himself/herself. Further customer can track the order and can cancel
the order. On the other side the Manager can allocate the order and can plan
for delivery. Customer can pay in cash or through online
Design a usecase for Railway Ticket reservation system where a user
can search for available tickets, can book a ticket also he will able to
cancel the tickets and to check the status of the ticket. User is also able
to pay online through his bank after validating a credit card.

The ticket admin can issue the ticket after successful verification of the
payment and can also update the available tickets.
 Question

Consider a book store in a shopping mall. The customer selects the books from
racks to purchase. The customer brings selected books to cashier. The cashier
scans each item with checkout system to prepare an order. The cashier
requests to customer for payment. The customer gives credit card to cashier.
The verifier and checkout system scans the card. The verifier accepts the card
and payment is accepted. Customer signs the credit card slip. The purchased
books are handed over to customer.
 Requirement Analysis
IEEE defines requirements analysis as

“(1) the process of studying user needs to arrive at a definition of a system,

hardware, or software requirements. (2) the process of studying and refining
system, hardware, or software requirements”.

Requirements analysis helps to understand, interpret, classify, and organize the

software requirements in order to assess the feasibility, completeness, and
consistency of the requirements. Various other tasks performed using requirements
analysis are listed below:

 Detect and resolve conflicts that arise due to unclear and unstated
requirements.
 Determine operational characteristics of software and how it interacts with
its environment.
 Understand the problem for which software is to be developed.
 Develop analysis model to analyze the requirements in the software.
 Requirements Analysis and
Negotiation
Requirement analysis and negotiation follows requirement gathering
(eliciting). Analysis categorizes requirements and examines them for
consistency, coverage, necessity, ambiguity, confliction, achievability and
testability.

Analyzing requirements is the task of determining whether the stated

requirements are unclear, incomplete, or contradictory, and then
resolving these problems to make the requirements clear, complete,
non- contradictory.
As the requirements analysis activity commences, the following
questions are asked and answered:
• Is each requirement consistent with the overall objective for the
system/product?
• Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an
add-on feature that may not be essential to the objective of the
system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source
(generally, a
specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment
that will house the system or product?
• Is each requirement testable, once implemented?
Software Requirement Specification
This document is generated as output of requirement analysis. The
requirement analysis involves obtaining a clear and thorough understanding
of the product to be developed.

Thus, SRS should be consistent, correct, unambiguous & complete,

document. The developer of the system can prepare SRS after detailed
communication with the customer.

An SRS clearly defines the following:

 External Interfaces of the system: They identify the information which is to

flow „from and to’ to the system.

 Functional and non-functional requirements of the system. They stand for

the finding of run time requirements.

 Design constraints:
 Software Requirement
Specification:

• Software requirement specification is a kind of

document which is created by a software
analyst after the requirements collected from
the various sources - the requirement received
by the customer written in ordinary language.
It is the job of the analyst to write the
requirement in technical language so that they
can be understood and beneficial by the
development team.
 SRS Outline
1. Introduction
• 1.1 Purpose
• 1.2 Scope
• 1.3 Definitions, acronyms, and abbreviations 1.4 References
• 1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific requirements
• 3.1 External Interfaces
• 3.2 Functional requirements
• 3.3 Performance requirements
• 3.4 Logical Database requirements
• 3.5 Design Constraints
• 3.6 Software system attributes
• 3.7 Organising the specific requirements
• 3.8 Additional Comments
4. Supporting information
• 4.1 Table of contents and index
• 4.2 Appendixes
 Characteristics of good SRS

SRS is the way of representing requirement in a consistent format. SRS

Serves as contract between customer and developer

An SRS Should be

Correct – Each requirement must accurately describe the functionality to be

built.

Unambiguous – An SRS is unambiguous if and only if, every requirement

stated therin has only one interpretation
 Requirement
Documentation
Complete – A complete requirements specification must precisely define all
the real world situations that will be encountered and the capability’s
responses to them. It must not include situations that will not be encountered
or unnecessary capability features.

Consistent – An SRS is consistent if and only if, no subset of individual

requirements described in it conflict
Ranked for importance and/or stabiity – If an identifier is attached to every
requirement to indicate either the importance of stability of that particular
requirement.
Monitoring and control
Project Monitoring and Control is a
disparate set of processes to review,
analyze and report the progress and
performance of a project to the
baseline plan
Project
control
cycle