UNIT – 1

INTRODUCTION TO SOFTWARE
ENGINEERING
 Unit I Syllabus
INTRODUCTION
• Software Engineering paradigms –
Waterfall Life cycle model – Spiral Model
– Prototype Model – Fourth Generation
Techniques – Planning – Software
Project Scheduling, – Risk analysis and
management – Requirements and
Specification – Case Study for Project
Plan and SRS.
 Session - 1
Objective
- To understand the subtle introductory
concepts in software engineering
terminology
 INTRODUCTION
What is Software ?
- That which encompasses
a) Instructions
b) Data Structures &
c) Documentation
Features of Software ?
- Not manufactured but developed and
engineered
- Does’nt wear-out but deteriorates over time
- Most of the software are custom-built
 INTRODUCTION

Figure 1 - Wear-out Vs Deterioration

 INTRODUCTION
Enter Software Engineering
Seminal definition of SE
- The establishment and use of sound
engineering principles in order to obtain
economically software that is reliable and
works efficiently on real machines.
IEEE CS definition
- (1)The application of a systematic, disciplined,
quantifiable approach to the development,
operation and maintenance of software; (2)
The study of approaches as in (1).
 INTRODUCTION
• Software engineering covers not only
the technical aspects of building
software systems, but also
management issues, such as directing
programming teams, scheduling, and
budgeting.
• Software engineering is a discipline
whose aim is the production of fault-
free software, that is delivered on
time, within budget, and satisfies the
user’s needs.
 INTRODUCTION

tools

methods

process model

a “quality” focus

Figure 2 – A Layered Technology

 INTRODUCTION

- Engineering approach to software

development
(Construction example)
- Systematic collection of past experience
a) Techniques
b) Methodologies &
c) Guidelines
 Introduction
The height of Software Engineering

Engineering

Technology
Esoteric Past
Experience Craft
Systematic Use of Past
Experience and Scientific Basis
Unorganized Use of
Past Experience
Art
Time
 Why Software Engineering ?
[1] Acquiring skills to build large
programs and systems
a) Growth in size, complexity and
difficulty level of an exponential
nature
b) When the size of software increases,
the ad-hoc approach breaks down
 Why Software Engineering ?
[2] Able to solve complex problems
a) Breaking problems into smaller and
manageable parts
b) Practicing techniques like
specification, design, interface
development, testing, project
management etc.
 Why Software Engineering ?

[3] Acquiring skills to become a

better programmer
a) Higher productivity
b) Using quality procedures,
techniques and programs
 Why Software Engineering ?
Challenges in SE today ?
a) Effort Intensive activity
b) High Cost
c) Long development time
d) Changing needs of users
e) High risk of failure, user acceptance,
performance, quality parameters
etc…
 Why Software Engineering ?
Reasons for software failure
1) Schedule Slippages
2) Cost overruns
3) Does not solve user’s problem
4) Poor quality of software
5) Poor maintainability
 Why Software Engineering ?
What leads to failures as identified
earlier
a) Ad-hoc approaches
b) No proper planning
c) Deliverables not taken care of
d) Poor understanding of user’s
requirements
e) No control or review
f) Poor understanding of cost and effort by
both developer and user
 Session - 2
Objective
- To understand what a software process
framework does, and the generic phases
in software development
- To know the use of a process model, the
different process models that can be
used while developing effective quality
software
 A Software Process

A series of steps involving activities,

constraints, and resources that
produce an intended output of some
kind.
 A Software Process

INPUT OUTPUT
Process is Set of activities

Activities of a Software Process

a) Process Framework
b) Framework activities
c) Umbrella activities
 The Software Process
Framework
Common process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

Note : Refer Fig 2.2 on Page 55 in Pressman 6th edition

 A Software Process
Framework Activities
1) Work tasks
2) Work Products
3) Quality Assurance points
4) Project Milestones
 A Software Process
Generic Framework Activities
1) Communication
2) Planning
3) Modeling
4) Construction &
5) Deployment
 A Software Process
Umbrella activities
1) Software Project Management
2) Formal Technical Reviews
3) Software Quality Assurance
4) Software Configuration Management
5) Document Preparation and Production
6) Reusability Management
7) Measurement &
8) Risk Management
The Systematic Process

Analysis
Problem

Design Models

Development

Solution
Testing
 Generic Phases
1) Definition Phase
- Focusing on “what” the software is
2) Development Phase
- Focusing on “how” the software
works
3) Maintenance Phase
- Focusing on “changes” to the software
 Process Models
• Waterfall model
• Software automation
• V-Model
• Rapid Application Development Model RAD
• Spiral Model
• WIN – WIN Spiral Model
• Iteration model
• Incremental model
• Component-based software engineering
• Prototyping
• Rapid prototyping
• Fourth Generation Techniques
• Concurrent Development Model
• Formal Methods Model
• Combining paradigms
 Process Models
Waterfall Model – Classic Life Cycle
 Waterfall Model - Highlights
• Oldest and most widely used paradigm
• Activities ‘flow’ from one phase to
another
• If there are corrections, return to a
previous phase and ‘flow’ from there
again
 Waterfall Model - Advantages
• Good for planning and well-defined /repeated
projects
Pitfalls :
• Real-time projects often do not follow the
sequence
• All requirements may not be stated explicitly
by customer
• Customer only sees the results after some
time
• Developers are often delayed at certain phases
Spiral Model
 Spiral Model - Highlights
• Originally proposed by Boehm, couples
iterative nature of prototyping and the
systematic aspects of the waterfall
model
• Software is developed in series of
incremental releases
• Each iteration produces a more complete
product
• Better management through risk
analysis
 Spiral Model – Pitfalls
• May be difficult to convince customers
that evolution is controllable
• Demands risk assessment expertise -
major risk will cause problems if not
identified
• Relatively new and not widely used -
cannot determine performance
Note: An alternate spiral model is the
“Win-Win Spiral Model”
 Prototyping Model
What is software/system prototyping ?
- Rapid software development to validate
requirements
- In the past, the developed system was
normally thought of as inferior in some
way to the required system so further
development was required
- Now, the boundary between prototyping
and normal system development is
blurred and many systems are developed
using an evolutionary approach
 Prototyping Model
Uses of System Prototypes
• The principal use is to help customers and
developers understand the requirements for
the system
– Requirements elicitation. Users can experiment
with a prototype to see how the system supports
their work
– Requirements validation. The prototype can
reveal errors and omissions in the requirements
• Prototyping can be considered as a risk
reduction activity which reduces requirements
risks
 Prototyping Model
Benefits of Prototyping
• Misunderstandings between software
users and developers are exposed
• Missing services may be detected and
confusing services may be identified
• A working system is available early in
the process
• The prototype may serve as a basis for
deriving a system specification
• The system can support user training
and system testing
 Prototyping Model
The Prototyping Process

Establish Define
Develop Evaluate
prototype prototype
prototype prototype
objectives functionality

Prototyping Outline Executable Evaluation

plan definition prototype report
 Prototyping Model

Prototyping benefits in a nutshell

• Improved system usability
• Closer match to the system needed
• Improved design quality
• Improved maintainability
• Reduced overall development effort
 Prototyping Model
Start

Requirements Quick Building

gathering and
refinement design prototype

Engineer Refining Customer

product prototype evaluation

Stop
 Prototyping Model - Highlights
• Developer and customer determine
objectives and draft requirements
• Prototype quickly produced and
evaluated by customer
• Prototype then refined, and re-evaluated
• Process iterated, before final product
development
Advantages: Customer participation and
better requirements
 Prototyping Model - Pitfalls

• Problem 1: Customer may see

prototype as working model and expects
fast results
• Problem 2: Developer compromised
when producing prototype quickly, e.g.
different operating system or
programming language
Fourth Generation Techniques
• Use of software tools that allow
software engineer to specify s/w
characteristics at higher level
• The tools generate codes based on the
specification given
• More time in design and testing -
increase productivity
• Tools may not be easy to use, codes
generated may not be efficient
Fourth Generation Techniques

Requirements
gathering

"Design"
Strategy

Implementation
using 4GL

Testing
 Fourth Generation Techniques
Features of 4GL Tools
• Non-procedural languages for Database query

• Report generation

• Data manipulation

• Screen interaction and definition

• Code generation

• Graphics/spreadsheets and High-level graphics

Fourth Generation Techniques
Advantages
• Dramatic reduction in software
development time.
• Improved productivity for software
developers.
Disadvantages
• Not much easier to use as compared
to programming languages
Fourth Generation Techniques
- A fourth-generation programming
language(1970s-1990) (abbreviated
4GL) is a programming language or
programming environment designed
with a specific purpose in mind, such
as the development of commercial
business software
Fourth Generation Techniques

Types of 4GLs
a) Report Generators
b) Forms Generators
c) Ambitious 4GLs (Fourth Generation
Systems)
Fourth Generation Techniques
Successful 4GLs
a) Forte TOOL
b) PowerBuilder
c) DataFlex…

Database Query Languages

a) FOCUS
b) Informix-4GL
c) Progress-4GL…
Fourth Generation Techniques
Report Generators
a) BuildProfessional
b) Oracle Reports
c) PostScript etc…

GUI Creators
a) MATLAB’s GUIDE
b) Omni’s Studio
c) OpenROAD…
 Session - 3
Objective
- To highlight the importance of planning
in the software systems life cycle
- To know the different types of software
planning and its overall benefits
 Planning
1) Vital Inputs
• This is the most important ingredient in
software development
• Proper planning procedures to track the
progress of the project
• Role of a Project/Technical Manager
• Drafting an initial plan
• Revising a plan as the project
progresses
 Planning
2) The Project Plan
- Looking for resources required for the
project
- Outlining the WBS (Work Breakdown
Structure) and the schedule
Items that need to be included in a Project
Plan
a) Introduction
b) Project Organisation
 Planning
c) Risk Analysis
d) Hardware and Software requirements
e) Work Breakdown
f) Project Schedule
g) Monitoring and reporting mechanisms
Note:
Regular revision of the project plan to be
done as the project progresses
 Planning
Plan Description
Quality plan Describes the quality procedures and standards that will be
used in a project. See Chapter 27.
Validation plan Describes the approach, resources and schedule used for
system validation. See Chapter 22.
Configuration Describes the configuration management procedures and
management plan structures to be used. See Chapter 29.
Maintenance plan Predicts the maintenance requirements of the system,
maintenance costs and effort required. See Chapter 21.
Staffdevelopment plan. Describes how the skills and experience of the project team
members will be developed. See Chapter 25.

Table – Types of Plan

 Planning
3) Milestones and deliverables
- Need for data and documents for
project mangers to update and revise
schedules
- Developing milestone reports at the
end of every process activity
- Deliverables are the artifacts that
are given to the customer
- Deliverables are always the
milestones. The vice-versa is not true.
Questions on topics covered till
now
Session 4 - Project Scheduling
Objective
- To understand how project schedules
need to be drafted
- To know the different ways by which
project tasks can be tracked
 Project Scheduling
Vital Reasons for delivering a
software late
1) Unrealistic deadlines
2) Changing customer requirements
3) Honest underestimates of the amount
of effort and total resources required to
complete the project
4) Predictable and Unpredictable risks not
taken into account
5) Not able to foresee technical difficulties
 Project Scheduling
6) Not also able to foresee human
difficulties
7) Miscommunication among project staff
8) Failure by the project management
team to rescue a project going behind
schedule
 Project Scheduling
How to handle unrealistic deadlines
- Perform a detailed estimate using
historical data from past projects
- Delivering the critical functionality at the
earliest and other functionality later
- Convince the client that the imposed
deadline is unrealistic
- Use an incremental approach that gives
the following suggestions
 Project Scheduling
a) Increasing the budget and bringing on
additional resources
b) Removing certain other low-level
functionalities
c) Convince the client about post-project
delivery disaster
 Project Scheduling
Objectives of the Project Manager
1) Defining all the project tasks
2) Building an activity network and identifying
the interdependencies
3) Identifying critical tasks within the activity
network
4) Generating a timeline that shows the actual
and planned progress of each task
5) Track the task’s progress one day at a time
6) The schedule should allow the project to be
controlled and the progress to be monitored
 Project Scheduling
Basic Principles of Project Scheduling
a) Compartmentalization
b) Interdependency
c) Time allocation
d) Effort validation
e) Defined Responsibilities
f) Defined Outcomes &
g) Defined Milestones
 Project Scheduling
Table – Example of a Project Schedule
Table – Example of a task in a
project schedule
 Project Scheduling

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities charts

Software Activity charts

requirements and bar charts
 Project Scheduling
Important items used in a Scheduling
Process
a) Tables – holds the task summary
b) Bar Charts – Schedule Vs Time
c) Activity Charts – Graphical items that
show the task dependencies and critical
path(longest path in the activity graph)
 Project Scheduling
Example of a Table
Task Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
 Project Scheduling
Activity Chart - Example
1 4 /7 /0 3 15 da y s
15 da y s
M1 T3
8 day s T9
T1 5 day s 4 /8/ 03 2 5 /8/ 03
2 5 /7 /0 3
4 /7 /0 3 T6 M4 M6
M3
st art 2 0 day s 7 day s
15 day s
T7 T 11
T2
25 /7 /0 3 11 /8/ 03 5 /9/ 03
10 da y s 10 day s
M2 M7 M8
T4 T5 15 da y s

T 10 10 da ys
1 8 /7 /0 3
T 12
M5
2 5 day s
T8 Fini sh
19 /9/ 03
 Project Scheduling
4 /7 11 /7 1 8/7 2 5/7 1 /8 8 /8 1 5/8 2 2/8 2 9/8 5 /9 1 2/9 1 9/9
St art
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T 11
M8
T12
Fini sh
 Project Scheduling
Staff Allocation Chart
 Project Scheduling
Gantt Charts
Session 5 - Risk Management
Agenda
- Risk identification
- Risk projection (estimation)
- Risk mitigation, monitoring, and
management
 Risk Management
• A risk is a potential problem – it might happen
or not
• Conceptual definition of risk
– Risk concerns future happenings
– Risk involves change in mind, opinion, actions,
places, etc.
• Two characteristics of risk
– Uncertainty – the risk may or may not happen,
that is, there are no 100% risks (those, instead, are
called constraints)
– Loss – the risk becomes a reality and unwanted
consequences or losses occur
 Risk Management
Categorization of Risks – One way to do it
1) Project risks
– Threaten the project plan
– If they become real, it is likely that the project
schedule will slip and that costs will increase
2) Technical risks
– They threaten the quality and timeliness of the
software to be produced
– If they become real, implementation may become
difficult or impossible
3) Business risks
– They threaten the viability of the software to be built
– If they become real, they jeopardize the project or
the product
 Risk Management
Sub-categories of Business risks
1) Market risk – building an excellent product or
system that no one really wants
2) Strategic risk – building a product that no longer
fits into the overall business strategy for the
company
3) Sales risk – building a product that the sales
force doesn't understand how to sell
4) Management risk – losing the support of senior
management due to a change in focus or a
change in people
5) Budget risk – losing budgetary or personnel
commitment
 Risk Management
RISK IDENTIFICATION

RISK ASSESSMENT RISK ANALYSIS

RISK PRIORITIZATION
RISK
MANAGEMENT RISK MANAGEMENT
PLANNING

RISK CONTROL RISK RESOLUTION

RISK MONITORING
Fig : Risk Management Tasks
 Risk Management
Two Risk Strategies – Proactive and
Reactive
a) Reactive risk strategies
– "Don't worry, I'll think of something"
– The majority of software teams and managers rely on this
approach
– Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the
problem rapidly (fire fighting)
– Crisis management is the choice of management techniques
b) Proactive risk strategies
– Steps for risk management are followed
– Primary objective is to avoid risk and to have a contingency
plan in place to handle unavoidable risks in a controlled and
effective manner
 Risk Management
Steps to follow in Risk Management
1) Identify possible risks; recognize what can
go wrong
2) Analyze each risk to estimate the probability
that it will occur and the impact
(i.e., damage) that it will do if it
does occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal,
critical, and catastrophic
4) Develop a contingency plan to manage
those risks having high probability
and high impact
 Risk Management
Risk Item Checklist
• Used as one way to identify risks
• Focuses on known and predictable risks
in specific subcategories
• Can be organized in several ways
– A list of characteristics relevant to each risk
subcategory
– Questionnaire that leads to an estimate on
the impact of each risk
– A list containing a set of risk component and
drivers and their probability of occurrence
 Risk Management
Questionnaire on Project Risk
1) Have top software and customer managers
formally committed to support the project?
2) Are end-users enthusiastically committed to
the project and the system/product to be
built?
3) Are requirements fully understood by the
software engineering team and its
customers?
4) Have customers been involved fully in the
definition of requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?
 Risk Management
• The impact of each risk driver on the risk
component is divided into one of four
impact levels
– Negligible, marginal, critical, and
catastrophic
• Risk drivers can be assessed as
impossible, improbable, probable, and
frequent
 Risk Management
Contents of a Risk Table
• A table that provides a project manager with a
simple technique for risk projection
• It consists of five columns
– Risk Summary(short description of the risk)
– Risk Category(one of seven risk categories)
– Probability – estimation of risk occurrence based on
group input
– Impact – (1) catastrophic (2) critical (3) marginal
(4) negligible
– RMMM – Pointer to a paragraph in the Risk
Mitigation, Monitoring, and Management Plan
Risk Management

Table : Contents of a Risk Table

 Risk Management
Assessing the Risk Impact
- This can be assessed by Risk Exposure given
as follows
RE = P * C where
P – The probability of occurrence of a risk
C – The cost to the project if the risk occurs
Example
A software application has got 60 components.
The project manager finds that there is a 90%
probability of the components i.e. 20 out of the
60 components will have to be re-developed
again. The total cost of developing one
component on an average is Rs 2000. Find RE ?
 Risk Management
Solution
P = 90% probability that 20 out of 60
software components will have to be
re-developed
C = Total cost of developing 20 components is
Rs. 40,000
RE = .90 x 40,000 = 36,000
 Risk Management
RMMM(Risk Mitigation, Monitoring and
Management) Plan
• An effective strategy for dealing with risk.
Three issues need to be considered.
- Risk mitigation (i.e., avoidance)
– Risk monitoring
– Risk management and contingency planning
• Risk mitigation (avoidance) is the primary
strategy and is achieved through a plan
– Example: Risk of high staff turnover
 Risk Management
The RMMM Plan
- A part of the software development plan
or can be a separate document
- Once RMMM becomes documented and
the project has begun, the risk
mitigation, and monitoring steps begin
– Risk mitigation is a problem avoidance
activity
– Risk monitoring is a project tracking activity
 Risk Management
• Risk monitoring has three objectives
– To assess whether predicted risks do, in
fact, occur
– To ensure that risk aversion steps defined
for the risk are being properly applied
– To collect information that can be used for
future risk analysis
• The findings from risk monitoring may
allow the project manager to ascertain
what risks caused which problems
throughout the project
 Risk Management
Examples of top risks
• Shortage of technically trained manpower
• Too many requirement changes
• Unclear requirements
• Not meeting performance requirements
• Unrealistic schedules
• Insufficient business knowledge
• Working on new technology
 Risk Management
Seven Principles of Risk Management
• Maintain a global perspective
– View software risks within the context of a system
and the business problem that is is intended to
solve
• Take a forward-looking view
– Think about risks that may arise in the future;
establish contingency plans
• Encourage open communication
– Encourage all stakeholders and users to point out
risks at any time
• Integrate risk management
– Integrate the consideration of risk into the software
process
 Risk Management
• Emphasize a continuous process of risk
management
– Modify identified risks as more becomes known and
add new risks as better insight is achieved
• Develop a shared product vision
– A shared vision by all stakeholders facilitates better
risk identification and assessment
• Encourage teamwork when managing risk
– Pool the skills and experience of all stakeholders
when conducting risk management activities
 Session 6 – Requirements and
Specification
Objective
- To understand the need for an
SRS(Software Requirements
Specification) and the structure of a
requirements document
- To know how the process of
requirements gathering should be done
for a software application, the
characteristics, components etc…
 Requirements and Specification
IEEE definition of requirement
“A condition of capability needed by a user
to solve a problem or achieve an
objective”
IEE definition of requirement(IEE87)
“A condition or capability that must be
met or possessed by a system … to
satisfy a contract, standard, specification,
or other formally imposed document …”
 Requirements and Specification
Problems in developing the SRS
a) Changing requirements with time
b) Not able to document the complete
needs of the project
c) Incorrect interpretation or specification
of the requirements
d) Creating an effective and stable SRS is
difficult
 Requirements and Specification
Need for SRS
- Communication gap between the client
and the developer. The SRS should
bridge this gap
- Helping clients understanding their own
needs
- Establishes the basis for agreement
between the client and the supplier on
what the software product will do
- A high-quality SRS reduces the
development cost
 Requirements and Specification
- Provides a reference for validation of the
final product
- The three desirable attributes for any
project i.e. cost, schedule and quality
can be formally estimated using the SRS
- Boehm’s investigation (Out of 54%
errors found during later stages of the
SDLC, 45% errors originated in the
requirements phase
- A high-quality SRS is a pre-requisite to
high quality software
Requirements and Specification
Phase Cost (person-
hours/man-hours)
Requirements 2
Design 5
Coding 15
Acceptance Test 50
Operation and 150
Maintenance
Table : Cost of fixing requirement errors
Requirements and Specification
Requirement Process
Client/
User needs

Analysis
Figure : The requirement
Specification process

Validation

Validated SRS
 Requirements and Specification
Concepts which can be used to
perform the RA in an effective manner
a) Divide and Conquer
b) Organizing large volumes of information
c) Using diagrams like data flow diagrams,
object diagrams etc…
Problem Analysis
- To gain an understanding of the needs,
requirements, and constraints on the
software
 Requirements and Specification
Analysis involves the following
activities
a) Interviewing clients and users
b) Reading manuals
c) Studying current systems
d) Helping client/users understand new
possibilities
e) Like becoming a consultant
f) Must understand the working of the organization ,
client, and users
 Requirements and Specification
i) Basic principle: problem partition
j) Partition w.r.t what?
Object - OO analysis
Function - structural analysis
Events in the system – event partitioning

DFM (Data Flow Modeling)

- Focuses on functions performed in the
system
- Uses dataflow diagrams and functional
decomposition in modeling
 Requirements and Specification
• The Structured System Analysis and
Design (SSAD) methodology uses DFD to
organize information, and guide analysis
• A DFD shows flow of data through the system
– Views system as transforming inputs to
outputs
– Transformation done through transforms
– DFD captures how transformation occurs
from input to output as data moves through
the transforms
– Not limited to software
 Requirements and Specification
The DFD has four symbols:
1.Squares representing external entities,
which are sources or destinations of data.
2.Rounded rectangles
representing processes, which take data as
input, do something to it, and output it.
3.Arrows representing the data flows, which
can either be electronic data or physical
items.
4.Open-ended rectangles
representing data stores, including
electronic stores such as databases or XML
files and physical stores such as or filing
cabinets or stacks of paper.
Requirements and Specification
DFD Example
 Requirements and Specification
Characteristics of SRS
• Correct
• Complete
• Unambiguous
• Consistent
• Verifiable
• Traceable
• Modifiable
• Ranked for importance and/or stability
 Requirements and Specification
• Correctness
– Each requirement accurately represents some
desired feature in the final system
• Completeness
– All desired features/characteristics specified
– Hardest to satisfy
– Completeness and correctness strongly related
• Unambiguous
– Each requirement has exactly one meaning
– Without this errors will creep in
– Important as natural languages often used
• Verifiability
– There must exist a cost effective way of checking if the
s/w satisfies requirements
 Requirements and Specification
• Consistent
– two requirements don’t contradict each other
• Traceable
– The origin of the req, and how the req relates to
software elements can be determined
• Ranked for importance/stability
– Needed for prioritizing in construction
– To reduce risks due to changing requirements
 Requirements and Specification
Components of an SRS
• An SRS must specify requirements on
– Functionality
– Performance
– Design constraints
– External interfaces
 Requirements and Specification
Functional Requirements
• Heart of the SRS document; this forms the
bulk of the specs
• Specifies all the functionality that the
system should support
• Outputs for the given inputs and the
relationship between them
• All operations the system is to do
• Must specify behavior for invalid inputs too
 Requirements and Specification
Performance Requirements
• All the performance constraints on the
software system

• Generally on response time , throughput etc

=> dynamic

• Capacity requirements => static

• Must be in measurable terms (verifiability)

– Eg resp time should be xx 90% of the time
 Requirements and Specification
Design Constraints
• Factors in the client environment that
restrict the choices
• Some such restrictions
– Standard compliance and compatibility with
other systems
– Hardware Limitations
– Reliability, fault tolerance, backup req.
– Security
 Requirements and Specification
External Interface
• All interactions of the software with
people, hardware, and software
• User interface most important
• General requirements of “friendliness”
should be avoided
• These should also be verifiable
 Requirements and Specification
Structure of an SRS standardized by IEEE
• Introduction
– Purpose , the basic objective of the system
– Scope of what the system is to do , not to do
– Overview
• Overall description
– Product perspective
– Product functions
– User characteristics
– Assumptions
– Constraints
 Requirements and Specification
 Specific requirements
 External interfaces
 Functional requirements
 Performance requirements
 Design constraints
 Acceptable criteria
 desirable to specify this up front.
 Summary
• Having a good quality SRS would help in
understanding all the required components
for software development
• The requirement phase has 3 major sub
phases
– analysis , specification and validation
• Analysis
– for problem understanding and modeling
– Methods used: SSAD, OOA , Prototyping
• Key properties of an SRS: correctness,
completeness, consistency, traceability,
unambiguousness
 Summary
• Specification
– must contain functionality, performance
,interfaces and design constraints
– Mostly natural languages used
• Validation - through reviews
 Case Study – Project Plan
Example : Waste Management Inspection
Tracking System

Refer to pdf document and explain ?

 Case Study – SRS
Example : Waste Management
Inspection Tracking System

Refer to pdf document and explain ?