PAN African eNetwork Project

Course Name: PGDIT

Subject Name: Software Engineering
Semester - I

OP Sangwan
Copyright Amity University
1

Faculty Profile

M Sc (Computer Science)
M Tech (Computer Science)
CCNA (Cisco certified Network Associate)
CCNA (Cisco certified )
Ph D (CSE) (Thesis Submitted)

Publications
International/ National Journal = 8 (including ACM, ISJKE)
International/ National Conference = 9 (including Springer)

Conference/ Workshop Attended

Bangkok
Vietnam

Copyright Amity University

Patents filed provisionally

ANN model
Area of specialization
Software Engineering
Artificial Intelligence
Experience
5 + teaching
1 research
Member
Cisco (Academic Council, USA)
Cisco (Learning Institute, USA)

Copyright Amity University

Software Life Cycle Model

Waterfall Model
Prototype Model
Iterative Enhancement Model
Evolutionary Development Model
Spiral Model
Rapid Application Development (RAD) Model

Copyright Amity University

Waterfall Model
Requirement

Design
Implementation
andunittesting
Integr ationand
systemtesting
Operation &
Maintenance

Copyright Amity University

Problems with the Waterfall Model

It is difficult to define all requirements at the beginning of
a project
This model is not suitable for accommodating any
change
A working version of the system is not seen until late in
the projects life
It does not scale up well to large projects
Real projects are rarely sequential

Copyright Amity University

Prototype Model
It is also known as throw away model.
It is developed as per the current available
requirement.
The code for the prototype model is thrown
away; however the experience gathered from
developing the prototype helps in developing the
actual system.

Copyright Amity University

Prototype Model

Linear model
Rapid

Copyright Amity University

Iterative Enhancement Model

Requirements
specification

Architectural
design

Detailed

design

Implementation
and unit testing

Integration
and testing

Operation and
Maintenance
9

Evolutionary Process Models

Evolutionary process model resembles iterative enhancement model.
The same phases as defined for the waterfall model occur here in a
cyclical fashion. This model differs from iterative enhancement model in
the sense that this does not require a useable product at the end of each
cycle. In evolutionary development, requirements are implemented by
category rather than by priority.

This model is useful for projects using new technology that is not
well understood. This is also used for complex projects where all
functionality must be delivered at one time, but the requirements are
unstable or not well understood at the beginning.

10

Evolutionary Development Model

Concurr ent
activities

Outline
description

Copyright Amity University

Specification

Initial
version

Development

Intermediate
versions

Validation

Final
version

Spiral Model
Phases of Spiral Model
Planning: Determination of objectives, alternatives and
constraints.
Risk Analysis: Analyze alternatives and attempts to
indentify and resolve the risks involved
Development: Product development and testing
product.
Assessment: Customer evaluation
Copyright Amity University

Spiral Model

13

Rapid Application Development (RAD) Model

o

Build a rapid prototype

Prototype is refined

Give it to user for evaluation & obtain feedback

With active participation of users

Requirements
Planning

User
Description

Construction

Cut over

14

Rapid Application Development (RAD) Model

Not an appropriate model in the absence of user
participation.
Reusable components are required to reduce
development time.
Highly specialized & skilled developers are required
and such developers are not easily available.

15

Software Requirements
Analysis and Specification

Copyright Amity University

Requirement Engineering
Requirements describe
What

not

How

Produces one large document written in natural language

contains a description of what the system will do without
describing how it will do it.
Without well written document
-- Developers do not know what to build
-- Customers do not know what to expect
-- What to validate
Copyright Amity University

Problem Statement
Requirements
Elicitation

Requirement
Engineering

Requirements
Analysis

Requirements
Documentation

SRS

Requirements
Review

Crucial Process Steps of requirement engineering

18

Requirement Engineering
Requirement Engineering is the disciplined application of proven principles,
methods, tools, and notations to describe a proposed systems intended
behavior and its associated constraints.
SRS may act as a contract between developer and customer.

State of practice
Requirements are difficult to uncover
Requirements change
Over reliance on CASE Tools
Tight project Schedule
Communication barriers
Market driven software development
Lack of resources
19

Requirement Engineering
Example
A University wish to develop a software system for the student result
management of its PGDIT Programme. A problem statement is to be
prepared for the software

development company. The problem

statement may give an overview of the existing system and broad

expectations from the new software system.

20

Types of Requirements

Known
Requirements

Unknown
Requirements

Undreamed
Requirements

Stakeholder: Anyone who should have some direct or indirect

influence on the system requirements.
--- User
--- Affected persons

Requirements

Functional

Non-Functional
21

Types of Requirements
Functional requirements describe what the software has to do. They are often called
product features.
Non Functional requirements are mostly quality requirements. That stipulate how well the
software does, what it has to do.

Availability
Reliability
Usability
Flexibility

Maintainability
Portability
Testability

For Users

For Developers

22

Types of Requirements
User and system requirements

User requirement are written for the users and include functional
and non functional requirement.

System requirement are derived from user requirement.

The user
system requirements are the parts of software
requirement and specification (SRS) document.

Copyright Amity University

23

Types of Requirements
Interface Specification
Important for the customers.
TYPES OF INTERFACES

Procedural
interfaces
(also
Programming Interfaces (APIs)).

called

Application

Data structures
Representation of data.
24

Feasibility Study
Is cancellation of a project a bad news?
As per IBM report, 31% projects get cancelled before they are
completed, 53% over-run their cost estimates by an average of 189% &
for every 100 projects, there are 94 restarts.

How do we cancel a project with the least work?

CONDUCT A FEASIBILTY STUDY

25

Feasibility Study
Technical feasibility
Is it technically feasible to provide direct communication
connectivity through space from one location of globe to
another location?
Is it technically feasible to design a programming
language.
26

Feasibility Study
Feasibility depends upon non technical Issues like:
Are the projects cost and schedule assumption realistic?
Does the business model realistic?
Is there any market for the product?

27

Feasibility Study
Purpose of feasibility study
evaluation or analysis of the potential impact of a proposed project or
program.

Focus of feasibility studies

Is the product concept viable?
Will it be possible to develop a product that matches the projects
vision statement?
What are the current estimated cost and schedule for the project?
28

Feasibility Study
Focus of feasibility studies
How big is the gap between the original cost & schedule
targets & current estimates?
Is the business model for software justified when the
current cost & schedule estimate are considered?
Have the major risks to the project been identified & can
they be surmounted?
Is the specifications complete & stable enough to
support remaining development work?
29

Feasibility Study
Focus of feasibility studies
Have users & developers been able to agree on a
detailed user interface prototype? If not, are the
requirements really stable?
Is the software development plan complete & adequate
to support further development work?

30

Requirements Elicitation
Perhaps
Most difficult
Most critical
Most error prone
Most communication intensive
Succeed

effective customer developer partnership

Selection of any method
1. It is the only method that we know
2. It is our favorite method for all situations
3. We understand intuitively that the method is effective in the present
circumstances.
Normally we rely on first two reasons.

31

Requirements Elicitation
1. Interviews
2. Brainstorming Sessions
3. Quality Function Deployment
Normal Requirements
Expected Requirements
Exciting Requirements

1. The Use Case Approach

Use Case
Use Case Scenario

Often Interchanged
But they are different
32

Requirements Elicitation
Types of questions.
1.

Any problems with existing system

2.

Any Calculation errors

3.

Possible reasons for malfunctioning

4.

No. of Student Enrolled

33

Requirements Elicitation
5. Possible benefits
6. Satisfied with current policies
7.How are you maintaining the records of previous students?
8. Any requirement of data from other system
9. Any specific problems
10. Any additional functionality
11. Most important goal of the proposed development
At the end, we may have wide variety of expectations from the proposed
software.
34

Requirements Analysis

35

We analyze, refine and scrutinize requirements to make consistent &

unambiguous requirements.

Steps

Draw the context

Diagram

Develop prototype
(optional)

Model the
Requirements
Finalize the
Requirements

Requirements Analysis Steps

36

Administrator

Marks Entry
Operator

Subject Information
Entry

Student Information
Entry
Result Management
System

Student Information
Reports generated

Marks Entry

Mark sheet generated

Student performance
Reports generated

37

Data Flow Diagrams

DFD show the flow of data through the system.
--All names should be unique
-- It is not a flow chart
-- Suppress logical decisions
-- Defer error conditions & handling until the end of
analysis
Symbol
Name
Function
Data Flow

Process

the

Connect process

Perform some transformation of its

input data to yield output data.
38

Symbol

Name
Source or sink

Data Store

Leveling

Function
A source of system inputs or
sink of system outputs
A repository of data, the
arrowhead indicate net
input and net outputs
to store

DFD represent a system or software at any level of abstraction.

A level 0 DFD is called fundamental system model or context model

represents entire software element as a single bubble with input and
output data indicating by incoming & outgoing arrows.
39

Data Dictionaries
Data Dictionaries are simply repositories to store
information about all data items defined in DFD.
Includes :
Name of data item
Aliases (other names for items)
Description/Purpose
Related data items
Range of values
Data flows
Data structure definition
40

Entity-Relationship Diagrams
Entity-Relationship Diagrams
It is a detailed logical representation of data for an organization and uses three
main constructs.
Entities

Relationships

Attributes

Entities
Fundamental thing about which data may be
maintained. Each entity has its own identity.
Entity Type is the description of all entities to which a
common definition and common relationships and attributes
apply.
41

Entity-Relationship Diagrams
Consider an insurance company that offers both home
and automobile insurance policies .These policies are
offered to individuals and businesses.
POLICY
home

Automobile
POLICY

CUSTOMER
individual

businesses

CUSTOMER

42

Relationships
A relationship is a reason for associating two entity types.
Binary relationships
involve two entity types
A CUSTOMER is insured by a POLICY. A POLICY CLAIM is made against a
POLICY.

Relationships are represented by diamond notation in a ER diagram.

CUSTOMER

Insured
by

POLICY

Made
Against

Relationships added to ERD

POLICY
CLAIM
43

A training department is interested in tracking which training courses

each of its employee has completed.

EMPLOYEE

completes

COURSE

Many-to Many relationship

Each employee may complete more than one course,and

each course may be completed by more than one
employee.
44

Degree of relationship
It is the number of entity types that participates in that relationship.

Unary

Binary

Ternary

Unary relationship
Is
Married
to

Person

One to One

Employee

Manages

One to many
45

Binary Relationship
EMPLOYEE

Is
assigned

PARKING
PLACE

One to One

PRODUCT
LINE

Contains

PRODUCT

Registers
for

COURSE

One to many

STUDENT

Many to many
46

Ternary relationship
Vendor

Part

Ships

Ware House

Cardinalities and optionality

Two entity types A,B, connected by a relationship.
The cardinality of a relationship is the number of instances of entity B that
can be associated with each instance of entity A

Movie

Is
Stocked
as

Video Tape

47

Attributes
Each entity type has a set of attributes associated with it.
An attribute is a property or characteristic of an entity that is
of interest to organization.

Attribute

48

A candidate key is an attribute or combination of attributes that

uniquely identifies each instance of an entity type.
Candidate Key
Student_ID
If there are more candidate keys, one of the key may be chosen
as the Identifier.
It is used as unique characteristic for an entity type.
Identifier

49

Address

Name

Student_ID

Phone_No

STUDENT

Vendors quote prices for several parts along with quantity of parts.
Draw an E-R diagram.

Vendor

Quoteprice

quantity

Parts

price

50

Approaches to problem analysis

1. List all inputs, outputs and functions.
2. List all functions and then list all inputs and outputs associated
with each function.

Structured requirements definition (SRD)

Step1
Define a user level DFD. Record the inputs and outputs for each
individual in a DFD.
Step2
Define a combined user level DFD.
Step3
Define application level DFD.
Step4
Define application level functions.
51

Requirements Documentation
This is the way of representing requirements in a
consistent format
SRS serves many purpose depending upon who is writing
it.
---

written by customer
written by developer

Serves as contract between customer & developer.

52

Requirements Documentation
Nature of SRS
Basic Issues

Functionality
External Interfaces
Performance
Attributes
Design constraints imposed on an Implementation
53

SRS Should
-- Correctly define all requirements
-- not describe any design details
-- not impose any additional constraints
Characteristics of a good SRS
An SRS Should be

Correct

Unambiguous

Complete

Consistent
54

Ranked for important and/or stability

Verifiable

Modifiable

Traceable

55

Requirements Documentation
Correct
An SRS is correct if and only if every requirement stated therein is one
that the software shall meet.

Unambiguous
An SRS is unambiguous if and only if, every requirement stated therein
has only one interpretation.

Complete
An SRS is complete if and only if, it includes the following elements
(i) All significant requirements, whether related to functionality,
performance, design constraints, attributes or external interfaces.

56

Requirements Documentatio
(ii) Responses to both valid & invalid inputs.
(iii) Full Label and references to all figures, tables and diagrams in the SRS and
definition of all terms and units of measure.

Consistent
An SRS is consistent if and only if, no subset of individual requirements
described in it conflict.

Ranked for importance and/or Stability

If an identifier is attached to every requirement to indicate either the
importance or stability of that particular requirement.

57

Requirements Documentation
Verifiable
An SRS is verifiable, if and only if, every requirement stated therein
is verifiable.

Modifiable
An SRS is modifiable, if and only if, its structure and style are such
that any changes to the requirements can be made easily, completely, and
consistently while retaining structure and style.

Traceable
An SRS is traceable, if the origin of each of the requirements is clear
and if it facilitates the referencing of each requirement in future development
or enhancement documentation.

58

Requirements Documentation
Organization of the SRS
IEEE has published guidelines and standards to organize an SRS.
First two sections are same. The specific tailoring occurs in section-3.
1. Introduction
1.1
Purpose
1.2 Scope
1.3 Definition, Acronyms and abbreviations
1.4 References
1.5 Overview

59

Requirements Documentation
2. The Overall Description
2.1

Product Perspective
2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
60

Requirements Documentation
2.2
2.3
2.4
2.5
2.6

Product Functions
User Characteristics
Constraints
Assumptions for dependencies
Apportioning of requirements

3. Specific Requirements
3.1
External Interfaces
3.2
Functions
3.3
Performance requirements
3.4
Logical database requirements
3.5
Design Constraints
3.6
Software System attributes
3.7
Organization of specific requirements
3.8
Additional Comments.
61

Requirements Validation
Check the document for:
Completeness & consistency
Conformance to standards
Requirements conflicts
Technical errors
Ambiguous requirements

62

SRS document

Organizational
standards

Organizational
knowledge

List of problems
Validation
process

Approved actions

63

Requirements Review Process

Plan
Planreview
review

Distribute
Distribute
SRS
SRS
documents
documents

Read
Read
documents
documents

Organize
Organize
review
review

Revise
Revise
document
document

Follow
Follow up
up
actions
actions
64

Requirements Validation
Problem actions
Requirements clarification
Missing information
find this information from stakeholders
Requirements conflicts
Stakeholders must negotiate to resolve this conflict
Unrealistic requirements
Stakeholders must be consulted
Security issues
Review the system in accordance to security standards
65

Review Checklists
Redundancy
Completeness
Ambiguity
Consistency
Organization
Conformance
Traceability

66

Multiple Choice Questions

Which one is not a step of requirement engineering?
(a) Requirements elicitation
(b) Requirements analysis
(c) Requirements design
(d) Requirements documentation
Requirements elicitation means
(a) Gathering of requirements
(b) Capturing of requirements
(c) Understanding of requirements
(d) All of the above
Copyright Amity University

Which one is not a type of requirements?

(a) Known requirements
(b) Unknown requirements
(c) Undreamt requirements
(d) Complex requirements
Which one is not a requirements elicitation technique?
(a) Interviews
(b) The use case approach
(c) FAST
(d) Data flow diagram
Which is not a type of requirements under quality function deployment
(a) Normal requirements
(b) Abnormal requirements
(c) Expected requirements
(d) Exciting requirements
68

Thank You
Please forward your query
To: [email protected]
CC:
[email protected]
69