UNIT - 2

SOFTWARE
REQUIREMENTS
ANALYSIS AND
SPECIFICATIONS
 1. Requirements and Specification

Requirements – The statements of needs that triggers the

development of program or system
or
These are the features or expectations given by the user
for a new or a modified product

Requirements describe:

• What not How

 Contd..

Specifications : Exact requirement of particular

needs to be satisfied, or essential
characterstics that a customer requires which
must be delivered.
• Specifications are written usually in a manner
that enables both parties to measure the degree
of conformance.
 1.1 Who gives the requirements

• Stakeholders: It is used to refer to any person or

group who will be affected by the system, directly
or indirectly.
• Stakeholders include end-users who interact with
the system and everyone else in an organization that
may be affected by its installation.
• Other system stakeholders may be engineers who
are developing or maintaining related systems,
business managers, domain experts, and trade union
representatives.
 2. Role of requirements
Requirements play a central role

planning

Software
tracking
document
ation

Requirements

coding
testing
3. Importance of Requirements
3.1 Any mistake at this phase leads to high cost

cost
14
12
10
8
cost
6
4
2
0
feasibilty requirement design coding testing
analysis
 4. Types of Requirements

• Levels of Business
requirements
requirements
User System
requirements requirements

Functional Non functional

Requirements Requirements

Specification
Document
 Contd…Types of Requirements

Business Requirements :
- Top level requirements
- It focus on vision
User Requirement or High level requirements
- It derives from business requirements
- It defines the requirements by which the objective of business
will be achieved
- It describes the services that the system should provide and the
constrains under which it must operate. we don’t expect to see
any level of detail, or what exactly the system will do, It’s
more of generic requirements.
- It’s usually written in a natural language and supplied by
diagrams.
 Contd..
System requirements
It mean a more detailed description of the system
services and the operational constrains such as how
the system will be used, and development constrains
such as the programming languages.
- This level of detail is needed by those who are
involved in the system development, like engineers,
system architects, testers, etc.
 Difference between user and system requirements

• user and system requirements, where user need a

high-level statements of the requirements, while
system developers need a more detailed system
specification. So, user and system requirements are
just refer to different level of detail.
• end-users will not be concerned with the detail, they
need a generic, abstracted written requirement.
• While the people who are involved in the
development, they need what exactly the system
should do.
 Contd..

Functional Requirements :
• It is same as user requirements only the difference is ,it defines
user’s view while functional requirements defines what
functionality is to be added in the software so that user
perform those activities
• It focus on system’s view(What system has to perform)
• It covers the main functions that should be provided by the
system.
• When expressed as user requirement, they are usually descried
in an abstract way. However more specific
functional system requirement describe the system functions,
it’s inputs, processing; how it’s going to react to a particular
input, and what’s the expected output.
 Contd..

• Non functional requirements: It defines the constraints under which

system has to perform its functionality .

• The constrains, like how many process the system can handle
(performance), what are the (security) issues the system needs to
take care of such as SQL injections …

• The rate of failure (reliability), what are the languages and tools will
be used (development), what are the rules you need to follow to
ensure the system operates within the law of the organization
(legislative).
 Examples of levels of requirements :

• Business Requirements : user will be able to

correct spelling errors in a document efficiently and it
will be integrated with the existing system.
• User Requirement:
Finding spellings errors in the document and
decide whether to replace each misspelled
word with one chosen from a list of suggested
words.
 Contd..

Functional Requirements :
• Find and highlight misspelled words.
• Display a dialog box with suggested
replacements.
• Making global replacements.
 Contd..

• Non – functional Requirement

It must be integrated into the existing word
processor which runs on windows.
 Contd..
Reliability
Usability For users
Flexibility

Maintainability
Portability For developers
Testability
Contd..
Non functional Requirements are sensitive…
• Non-functional requirements are often critical than
individual functional requirements. Users can usually
find ways to work around a system function that doesn’t
really meet their needs. However, failing to meet a non-
functional requirement can mean that the whole system
is unusable.
• For example, if an aircraft doesn’t mean meet it’s
reliability requirements, it won’t be safe for operation,
or if an embedded control system fails to meet it’s
performance requirements, the control functions won’t
operate correctly.
Contd..
Non-functional requirements should be
measurable
Contd…4.1 Another type of requirements:-
--Known Requirements Functional
--Unknown Requirements
--Undreamt Requirements Non Functional

Known Requirements : something a stakeholder believes to

be implemented
Unknown requirements: forgotten by stakeholders because
they are not needed right now
Undreamt requirement : stakeholder may not be able to think
of new requirements due to limited domain knowledge.
5. Problems or risk associated with requirements

1. Insufficient user involvement leads to unacceptable product

2. Creeping user requirements – contribute to over runs and degrade
product quality.
3. Gold plating done by developers and users adds uneccesary
features
4. Minimal specification leads to missing key requirements
5. Requirements completeness and consistency :
- incomplete requirements leads to dissatisfied customer
- Ambiguous requirements lead to ill spent time and re work
6. Requirements imprecision
7. Each user has different intention
8. Developer interpretation
 6. Requirement Engineering

It is a process of gathering the requirements, analyzing and documenting

the requirements
It is process of:
- Establishing the services that the customer requires from the system
And the constraints under which it operates and is developed.

We can define Requirement Engineering is the disciplined application of

proven principles, methods, tools, and notations to describe a proposed
system’s intended behavior and its associated
constraints.

.
 Contd..
Input to Requirement engineering – Problem
statement of an existing system along with broad
expectations from the new system.
Output from Requirement engineering- It produces one
large document, written in a natural language
contains the description of what the system will do
without describing how it will do
Without well written document
•-- Developers do not know what to build
•-- Customers do not know what to expect
•-- What to validate
 Problem Statement
as input

Requirement SRS as a
Engineering output

Requirement Requirement
Development Management

Elicitation Analysis Specification documentation review

 Contd..
• Requirement Engineering process
 Feasibility Study

• The purpose of feasibility study is not to solve the

problem, but to determine whether the problem is
worth solving.
• The study analyses whether the product can be
practically materialized in terms of implementation,
contribution of project to organization , cost
constraint as per values and objectives of
organization.
 Contd..

• The input to the feasibility study is a set of

business requirements and outline description
of system and how the system is intended to
support business processes
• The result of feasibility study is system should
be a report that recommends whether or not it
is worth carrying on with the requirements
engineering and system development process.
 Contd..
Feasibility study aims to answer a number of questions :
1. Does system contribute to the overall objectives of the
organization ?
2. Can the system be implemented using current technology and
within given cost and schedule constraints?
3. Can the system be integrated with other systems which are
already in place?
4. How would organization cope if the system were not
implemented?
5. What are the problems with current processes and how
would a new system help alleviate these problems?
 Contd..

• It concentrates on the following area :-

1. Organizational Feasibility
2. Technical Feasibility
3. Economic Feasibility
4. Legal feasibility
 Contd..

• Organizational Feasibility: In organizational

feasibility developers get the information about man
power resources and work culture of organization
• Technical Feasibility: Evaluation of the technical
feasibilities is to focus on:
-- Understand the different technologies involved in
proposed system
--Find out whether the necessary expertise exists to
use the techniques and technologies
 Contd..

•Economic Feasibility
It focus on economic justification on new system
Legal feasibility : it focus on whether new
system may result in any infringement,
violation , contracts or liabilities
 Contd..
1.Requirements Elicitation

It Means– Gathering of requirements or discovery of

the requirements
It is most difficult, critical, error prone and most
communication intensive activity.

This involves various activities:

- Knowledge of the general area where the systems
is applied.
- Interaction of system with external environment
- Detailed investigation of user needs.
- Define constraints of the system
 Contd..
Requirements elicitation Process
- Identify all stakeholders
- List out requirements- Ask the relevant
questions in order to gain an understanding of
the problem, issues and constraints.
- Confirm your understanding of requirements
with the stake holders
- Create requirements statements
 Techniques for Requirement elicitation

1. Interviews
2. Brainstorming
3. FAST(Facilitated Application specification
Technique)
4. Quality function deployment
5. User scenario and use case approach
6. Delphi technique
 1. Interviews

• The objective of interview is to understand the

customer’s expectation from the software
• Both parties have different feelings, goals ,
opinions , understanding , but
Both parties have a common goal

Success of the
project
 Contd..

•Selection of stakeholder: Groups to be considered for

interviews:-
1. Entry level personnel :- don’t have sufficient domain knowledge
2. Middle level stakeholder :- better domain knowledge and
experience of the project.
3. Managers : higher level management officers like Marketing
managers
4. Users of the software (Most important)
 Contd..

• Interviews can be
1. open ended: There is no pre-set agenda.
Context free questions may be asked to
understand the problem and to have an
overview of situation .
 Types of questions for result management systems :

• 1. Who is the controller of examination?

• 2. Who will use this software.
• 3. Possible reasons for malfunctioning of existing system
• 4. No. of Student Enrolled.
• 5.Are there any problem with existing system.
• 6.Have you faced any calculation error in the past.
• 7.How many stakeholders are computer friendly.
• 8.Satisfied with current policies.
• 9 How are you maintaining the records of previous students?
• 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.
2. Structured interviews : a proper questions are prepared. It
may started with simple questions to set people make at ease.
--After making atmosphere comfortable and calm , specific
questions may be asked to understand requirements.
Types of questions they may ask :

1. Are there any problem with existing system?

2. Have you faced calculation errors in past?
3. What are possible reasons of malfunctioning?
4. What data , required by you , exists in other systems?
5. What problems do you want this systems to solve?
 2. Brainstorming
•It is a group technique used for requirement elicitation to understand the
requirements.

group discussions

New ideas Quickly Creative Thinking

 Contd..
• Group technique may be carried out with specialized like
actual users, middle level managers etc or with other
stakeholders
• A Facilitator may handle group bias, conflicts carefully.

• All participants are encouraged to say whatever ideas come to

mind, whether they seem relevant or not. Every idea will be
documented in a way that everyone can see it. White boards or
computer projections systems can be used to make it visible to
every participant. A detailed report is prepared.
 3. Facilitated Application
specification Techniques (FAST)
Objective is to bridge the expectation gap a difference between what
developers think they are supposed to build and what customers
think they are going to get.

-- Similar to brainstorming sessions.

-- Team oriented approach
-- Creation of joint team of customers and developers.
 Its Guidelines
1. Arrange a meeting at a neutral site.
2. Establish rules for participation.
3. Informal agenda to encourage free flow of ideas.
4. Appoint a facilitator.
5. Prepare definition mechanism board,
worksheets, wall stickier.
6. Participants should not criticize or debate.
FAST session Preparations

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

1. Part of environment that surrounds the system.

2. Produced by the system.
3. Used by the system.
4. List of services
5. List of constraints.
6. Functions
7. Performance criteria( speed, accuracy)
 Contd.. Activities of FAST session

1. Every participant presents his/her list of objects, services , constraints ,

and performance for discussion
2. Combine list for each topic are prepared by eliminating redundant
enteries and adding new ideas.
3. Combined lists are again discussed and consensus lists are finalized by the
facilitator.
4. Once the Consensus list have been completed , team is divided into
smaller subteams for mini specifications
5. Presentations of mini-specifications
6. Each attendee prepares a list of validation criteria for the product and
presents the list to team
7. A sub team may be asked to write complete draft specifications using all
inputs from the FAST meeting
 4. Quality Function Deployment
• -- Incorporate voice of the customer

• Technical requirements.

• Documented

--Prime concern is customer satisfaction

--What is important for customer?
 Contd..

• -- Normal requirements : It involves goals of proposed software

are discussed with customer.
• Eg: related to result management systems might be : entry of marks ,
calculations of results , merit list reports , failed students report etc.
• -- Expected requirements : Requirement are implicit to the
software product.
• Eg : protection from unauthorized access , some warning
systems etc
• -- Exciting requirements : Features go beyond the customers
expectation and prove to very satisfying when present .
Eg: unauthorized access is noticed by software
 Contd..

Steps
1. Identify stakeholders
2. List out requirements
3. Degree of importance to each requirement.
5 Points : V. Important
4 Points : Important
3 Points : Not Important but nice to have
2 Points : Not important
1 Points : Unrealistic, required further
 Contd.

Requirement Engineer may categorize like:

(i) It is possible to achieve
(ii) It should be deferred & Why
(iii) It is impossible and should be dropped from consideration

First Category requirements will be implemented as per

priority assigned with every requirement.
 5. Use case Diagram

• Use Case model is used to specify the functionality

of a system from the point of view of the business
users.
• It is an graphical approach to requirements
elicitation and modeling.
• It depicts the functionality of the system, when
system is analyzed to gather its functionalities use
case are prepared and actors are identified.
• They are considered as for high level requirement
analysis of the system.
 Contd..
The purpose of use case diagram is to capture the
dynamic aspect of a system.
• Use case diagrams are usually referred to
as behavior diagrams used to describe a set of
actions (use cases) that some system or systems
(subject) should or can perform in collaboration with
one or more external users of the system (actors).
Each use case should provide some observable and
valuable result to the actors or other stakeholders of
the system.
 Components of Use Case Diagram

• Actor
• Use case
• Link
• System Boundary(Optional)
 Contd.. 1. Actor

•An actor or external agent, lies outside the system model, but
interacts with it in some way.
•Notations used for Actor :

•Actors are simply the entities that interact with a system.

•An actor may be people, computer hardware, other systems,
machine etc.
•Although in most cases, actors are used to represent the users of
system, actors can actually be anything that needs to exchange
information with the system.
 2. Use case

A use case is initiated by a user with a particular goal in mind,

and completes successfully when that goal is satisfied.
•Notation used for Use case :

•A use case represents a user goal that can be achieved by accessing the
system or software application.
•It describes the sequence of interactions between actors and the
system necessary to deliver the services that satisfies the goal. it
also includes the possible variants of this sequence . i.e alternative
flow.
•A complete set of use cases specifies all the different ways to use the
system.
•Each use case has a description which describes the functionality that
will be built in the proposed system.
 3. Link

• It is a solid line between an actor and each use case in which

other actor participates.
• It depicts a communication between an actor and a use
case.
• Notation use for it :

• An association is the relationship between an actor and a

business use case. It indicates that an actor can use a certain
functionality of the business system—the business use case:
 4. System Boundary

You can draw a rectangle around the use cases, called

the system boundary box, to indicates the scope of
your system. Anything within the box represents
functionality that is in scope and anything outside the
box is not.
 Contd..

There can be 5 relationship types in a use case

diagram.
• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case
1. Association between actor and use case

• This one is straightforward and present in every use case

diagram.
• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.
2. Generalization of an actor

Generalization of an actor means that one actor can inherit the

role of an other actor. The descendant inherits all the use
cases of the ancestor. The descendant have one or more use
cases that are specific to that role. Lets expand the previous
use case diagram to show the generalization of an actor.
 3. Extends

• Extend is a directed relationship that specifies how and

when the behavior defined in usually supplementary
(optional) extending use case can be inserted into
the behavior defined in the extended use case.
• Extended use case is meaningful on its own, it
is independent of the extending use case. Extending use
case typically defines optional behavior that is not
necessarily meaningful by itself. The extend relationship
is owned by the extending use case. The same extending
use case can extend more than one use case, and extending
use case may itself be extended.
• The extension takes place at one or more extension
points defined in the extended use case.
 Contd..
• Extend relationship is shown as a dashed line
with an open arrowhead directed from
the extending use case to the extended (base)
use case.
• It Simply extends the base use case and adds
more functionality to the system

• The arrow is labeled with the

keyword «extend».
 Contd.. Example:
• The extending use case is dependent on the extended (base) use case. In
the below diagram the “Calculate Bonus” use case doesn’t make much
sense without the “Deposit Funds” use case.
• The extending use case is usually optional and can be triggered
conditionally. In the diagram you can see that the extending use case is
triggered only for deposits over 10,000 or when the age is over 55.
• The extended (base) use case must be meaningful on its own. This
means it should be independent and must not rely on the behavior of the
extending use case.
•
 4. Include
• Use case include is a directed relationship between two use
cases which is used to show that behavior of the included use case (the
addition) is inserted into the behavior of the including (the base) use
case.
The include relationship could be used:
- To simplify large use case by splitting it into several use cases,
- To extract common parts of the behaviors of two or more use cases.

• The base use case is incomplete without the included use case.
• The included use case is mandatory and not optional.

A large use case could have some behaviors which might be detached
into distinct smaller use cases to be included back into the base use case
using the UML include relationship. The purpose of this action is
modularization of behaviors, making them more manageable.
 Example

• Include :
 Contd… include
• Example 2:
 5. Generalization of use case

• Generalization of a Use Case

• This is similar to the generalization of an actor. The behavior
of the ancestor is inherited by the descendant. This is used
when there are common behavior between two use cases and
also specialized behavior specific to each use case.
• For example in the previous banking example there might
be an use case called “Pay Bills”. This can be generalized
to “Pay by Credit Card”, “Pay by Bank Balance” etc.
Differences between generalization ,extend and include
Example 1: Use case diagram for Hotel Management
System
Example 2 : use case diagram
Example 3 : use case diagram
Example 4 : use case diagram
Example 5 : use case diagram
Example 6 : use case diagram
Example 7 : use case diagram
 Use case Guidelines

1. Identify all different users of system

2. Create a user profile for each category of users
including all roles of the users play that are relevant to the
system.
3. Create a use case for each goal, following the use
case template maintain the same level of abstraction
throughout the use case. Steps in higher level use
cases may be treated as goals for lower level (i.e.
more detailed), sub- use cases.
4. Structure the use cases
5. Review and validate with users
 Template for writing Use cases as shown below:
1. Introduction
Describe a quick background of the use case.

2.Actors
List the actors that interact and participate in the
use cases.

3.Pre Conditions
Pre conditions that need to be satisfied for the use
case to perform.

4. Post Conditions
Define the different states in which we expect the system
to be in, after the use case executes.
5. Flow of events

1. Basic Flow
List the primary events that will occur when this use case is executed.

2. Alternative Flows
Any Subsidiary events that can occur in the use case should be
separately listed. List each such event as an alternative flow.
A use case can have many alternative flows as required.
6.Special Requirements

Business rules should be listed for basic & information flows as special
requirements in the use case narration .These rules will also be used for writing
test cases. Both success and failures scenarios should be described.
7. Related use cases

77
 Refer Example 6

1. Maintain student Details

Add/Modify/update students details like name, address.
2. Maintain subject Details
• Add/Modify/Update Subject information semester wise
3. Maintain Result Details
• Include entry of marks and assignment of credit points for each
• paper.
4. Login
• Use to Provide way to enter through user id & password.
5. Generate Result Report
• Use to print various reports
6. View Result
• According to course code
• According to Enrollment number/roll number
Contd.. Refer example 6 ………
use case template for Login use case
• Login
1.1 Introduction : This use case describes how a user
logs into the Result Management System.
1.2 Actors :
(i) Data Entry Operator, marks entry operator
(ii) Administrator/Deputy Registrar
1.3 Pre Conditions : All users must have User Account
1.4 Post Conditions : If the use case is successful, the
actor is logged into the system. If not, the system state
is unchanged.
 Contd…..Example 6 : Login use case
1.5 Basic Flow : This use case starts when the actor wishes to
login to the Result Management system.
(i) System requests that the actor enter his/her name and
password.
(ii) The actor enters his/her name & password.
(iii) System validates name & password, and if finds correct
allow the actor to logs into the system.
1.6 Alternate Flows
1.6.1 Invalid name & password
If in the basic flow, the actor enters an invalid name
and/or password, the system displays an error message. The
actor can choose to either return to the beginning of the basic
flow or cancel the login, at that point, the use case ends.
 Example 6 : login use case

1.7 Special Requirements: None

1.8 any related use cases : None

Similarly make template for remaining use cases ….refer k k aggarawal chapter 3

Use cases should not be used to capture all the details of the system.
Only significant aspects of the required functionality
No design issues
Use Cases are for “what” the system is , not “how” the system will be designed
free of design characteristics
 6. Delphi Technique
The Delphi technique involves circulating questionnaires on a specific
problem among group members, sharing the questionnaire results with them,
and then continuing to re circulate and refine individual responses until a
consensus regarding the problem is reached.
In contrast to the brainstorming, the Delphi technique does not
have group members meet face to face. The formal steps followed in the Delphi
Technique are:
STEP 1: A problem is identified.
STEP 2: Group members are asked to offer solutions to the problem by
providing anonymous responses to a carefully designed questionnaires.
STEP 3: Responses of all group members are compiled and sent out to all group
members.
STEP 4: Individual group members are asked to generate a new individual
solution to the problem after they have studied the individual responses of all
other group members.
STEP 5: Step 3 and 4 are repeated until a consensus problem solutions is reached.
 Contd………Delphi Technique

--- Brainstorming offers the advantage of encouraging the expression of as

many useful ideas as possible, but the disadvantage of wasting the group's time
on ideas that are wildly impractical.

The advantage of the Delhi Technique :

1. The ideas can be gathered from group members who are
too geogrpahically separated or busy to meet face to face.
2. It simply address the problem of dominant people
3. It handles noise
4. It is easier to maintain confidentiality

---Usually all participants remain anonymous. Their identity is not revealed,

even after the completion of the final report. This prevents the authority,
personality, or reputation of some participants from dominating others in the
process. Arguably, it also frees participants (to some extent) from their
personal biases, allows free expression of opinions, encourages open
critique, and facilitates admission of errors when revising earlier
judgments.
 Delphi Technique

The advantage of the Delhi Technique :

1. Prime disadvantage is response time may be late
 2. Requirements analysis

The process of refining user’ s needs and constraints.

Requirements analysis consists of following tasks are to be performed:
--Requirements are categorized and then organized into respective
subsets.
-- The relationship among requirements are established.
--The requirements are further examined for checking their
consistency.
-- Finally requirements are ranked as per user needs
contd…..STEPS IN REQUIREMENT ANALYSIS

86
 Step 1. Draw the Context Diagram(0 Level DFD)
• This is also called as Fundamental System Model or Level-0 DFD.
• It shows :
- data input to the system
- output data generated by the system
- external entities.

It captures data flow occuring between the system and

external entities.

For example: if bubble A has two inputs x1 and x2, and one output y that
represents A should have exactly two external inputs and one external output
.
Context Diagram of Result Mgmt System
 Step 2. Development of prototype(optional)

---Prototyping is used to find out what actually the

customer really wants .
---Prototype looks like a system and we use customers’s
feedback to continuously modify the prototype until the
customer is satisfied.
 Step 3.. Model the Requirements
This process usually consists of various graphical representations of the
functions, data entities, external entities and the relationships between
them.

This graphical view may help to find incorrect, inconsistent, and

missing requirements.

Such models include –

• Data flow Diagrams

• Data Dictionaries

• ER Diagrams

90
 Data Flow Diagrams(DFDS

DFD is a heirarichal graphical method which depicts the different

functions of the system and data interchange among the processes.

--It is used for modelling the requirements in order to make consistent

and unambiguous requirements.

--It is useful to consider each function as a processing unit . Each

function consumes some input data and produces some output data.

.
 Standard Symbols for DFD’s
Symbol Name Function

Data flow Used to connect processes to each

other

Performs some transformation of

Process input data to yield output data

A source of system inputs or sink of

Source or sink
System outputs

A repository of data, the arrowheads

Indicate net inputs and net outputs
Data Store to store.
- It can be logical files or database
92
 Data Flow Diagrams(DFDS

Levelling :

The DFD is used to represent a system or software at any level of abstraction .

---It simply starts with 0 level and details are slowly added through
hierarchies(levels)
A 0 level DFD also called as context diagram which represents the entire
system as a single bubble with input and output data.
--Each process shown in level 1 represents the sub functions of overall systems
Each high level function is decomposed into sub functions.(Decomposition
of bubbles is called as factoring)
---Identify the sub functions of main function
---Identify the data inputs to each sub functions
---Identify the data output from each sub function.

---The number of levels can be increased until every process represents basic
functionality or problem at hand is well understood
 Designing Data Flow
Diagrams(DFDS

Rules for designing DFDS :

1. No process can have only outputs or only inputs. The process must have both
outputs and inputs.
2. The verb phrases in the problem description can be identified as processes in the
system
3. There should not be direct flow between data stores and external . This flow
should go through a process.
4. Data store labels should be noun phrases from problem description.
5. No data should have directly between external entities . The data flow should go
through a process.
6. Generally source and sink labels are noun phrases.
7. Interactions between external entities is outside scope of the system and therefore
not represented in DFD
8. Data flow from process to data store is for updation/deletion.
9. Data flow from data store to process is for reteriving or using the information.
10. Data flow labels are noun phrases from problem description .

94
 Level 1 and level 2 DFDs

Level 1: DFD depicts basic modules in the system and flow of data among various
modules. Level 1 DFD also mentions basic processes and sources of information.

Level 2 - At this level, DFD shows how data flows inside the modules mentioned in
Level 1.

Higher level DFDs can be transformed into more specific lower level DFDs with
deeper level of understanding unless the desired level of specification is achieved.

95
DFD for Result management Sytem

96
 Data Dictionaries

Data dictionary is the centralized collection of information about data.

It stores meaning and origin of data, its relationship with other data, data format for
usage etc.

Data dictionary is often referenced as meta-data (data about data) repository.

It is created along with DFD (Data Flow Diagram) model of software program and is
expected to be updated whenever DFD is changed or updated.

Requirement of Data Dictionary

The data is referenced via data dictionary while designing and implementing software.
Data dictionary removes any chances of ambiguity. It helps keeping work of
programmers and designers synchronized while using same object reference
everywhere in the program.
Data dictionary provides a way of documentation for the complete database system in
one place. Validation of DFD is carried out using data dictionary.
 Data Dictionaries

It Includes :

1. Name of data item

2. Aliases (other names for items)
3. Description/Purpose
4. Related data items
5. Range of values
6. Data structures

Meaning Notation

= Composed of
{} Repetition
() Optional
+ And
[/] Or
98
 Introduction

Example :

weekly timesheet = employee_name + Employee_Id + { Regular_Hours +

Overtime_hours }

Pay_rate = {hourly | daily | weekly } + Dollar_amount

99
Entity – Relationship
Model
(ER model)
10
0
 Introduction

• An Entity – Relationship model (ER model) is an abstract

way to describe a database.

• It is a visual representation of different data using

conventions that describe how these data are related to
each other.

10
1
 Basic elements in ER model

There are three basic elements in ER models:

Entities are the “things” about which we seek

information.

Attributes are the data we collect about the entities.

Relationships provide the structure needed to draw

information from multiple entities.

10
2
 Symbols used in E-R Diagram
Entity – rectangle
Attribute -oval
Relationship – diamond
Link - line

10
3
 ER Model
Entity
Entities are represented by means of rectangles. Rectangles are named with the
entity set they represent.

[Image: Entities in a school database]

Attributes
Attributes are properties of entities. Attributes are represented by means of
eclipses. Every eclipse represents one attribute and is directly connected to its
entity (rectangle).

10
4
 ER Model

Relationship

A relationship describes how entities interact. For example, the entity

“carpenter” may be related to the entity “table” by the relationship “builds” or
“makes”. Relationships are represented by diamond shapes.

10
5
 TYPES OF ATTRIBUTES

There are total six types of attributes :-

1. Simple attribute
2. Composite attribute
3. Derived attribute
4. Stored attribute
5. Single valued attribute
6. Multi valued attribute

10
6
 TYPES OF ATTRIBUTES

•Simple attribute: Cannot be split in to further attributes(indivisible). Also

known as Atomic attribute. Ex: Ssn(Social Security Number) or Roll No

10
7
 TYPES OF ATTRIBUTES

•Composite attribute:

Can be divided in to smaller subparts which represent more basic attributes

with independent meaning
Even form hierarchy
Ex: Address, Name

10
8
 TYPES OF ATTRIBUTES

•Derived attribute:

Attribute values are derived from another attribute.

Denoted by dotted oval
Ex - Age

10
9
 TYPES OF ATTRIBUTES

Stored attribute:

Attributes from which the values of other attributes are derived.

For example ‘Date of birth’ of a person is a stored attribute.

11
0
 TYPES OF ATTRIBUTES

Single-valued attribute:

A single valued attribute can have only a single value.

For example a person can have only one ‘date of birth’, ‘age’ ,
Social_Security_Number.etc.

That is a single valued attributes can have only single value. But
it can be simple or composite attribute.

That is ‘date of birth’ is a composite attribute , ‘age’ is a simple

attribute. But both are single valued attributes.

11
1
 TYPES OF ATTRIBUTES

Multi-value attribute:

Attribute may contain more than one values. Denoted by double circled oval
line connecting to the entity in the ER diagram.
Ex: Phone-number, College-degree, email addresses etc

11
2
 KEYS

Keys are of following types:-

1. Candidate Key
2. Composite Key
3. Primary key
4. Foreign Key

The name of each primary key attribute is

underlined.

11
3
 CANDIDATE KEY

• a simple or composite key that is unique and minimal

•unique – no two rows in a table may have the same value at

any time

•minimal – every column must be necessary for uniqueness

•For example, for the entity

Employee(EID, First Name, Last Name, SIN, Address, Phone,
BirthDate, Salary, DepartmentID)

•Possible candidate keys are EID, SIN

11
4
 COMPOSITE KEY

•Composed of more than one attribute

•For example, First Name and Last Name – assuming there is

no one else in the company with the same name, Last Name
and Department ID – assuming two people with the same last
name don’t work in the same department.

•A composite key can have two or more attributes, but it must

be minimal.

11
5
 PRIMARY KEY

•A candidate key is selected by the designer to uniquely

identify tuples in a table. It must not be null.

•A key is chosen by the database designer to be used as an

identifying mechanism for the whole entity set. This is
referred to as the primary key. This key is indicated by
underlining the attribute in the ER model.

•For example Employee(EID, First Name, Last Name, SIN,

Address, Phone, BirthDate, Salary, DepartmentID) – EID is
the Primary key.

11
6
 FOREIGN KEY

•An attribute in one table that references the primary key of

another table OR it can be null.

•Both foreign and primary keys must be of the same data type

•For example: Employee(EID, First Name, Last Name, SIN,

Address, Phone, BirthDate, Salary, DepartmentID) –
DepartmentID is the Foreign key.

11
7
Graphical Representation in E-R diagram

11
8
 DEGREE OF A RELATIONSHIP

It is the number of entity types that participate in a relationship

If there are two entity types involved it is a binary relationship type

If there are three entity types involved it is a ternary relationship type
It is possible to have a n-array relationship (quaternary)

SALESASSIST SELLS PRODUCT

CUSTOMER

11
9
 CARDINALITY CONSTRAINTS

The number of instances of one entity that can or must be

associated with each instance of another entity.

If we have two entity types A and B, the cardinality constraint

specifies the number of instances of entity B that can (or must) be
associated with entity A.

Four possible categories are

One to one (1:1) relationship
One to many (1:m) relationship
Many to one (m:1) relationship
Many to many (m:n) relationship

12
0
 CARDINALITY CONSTRAINTS

one-to-one

EMPLOYEE MANAGES DEPARTMENT

1 1

12
1
 CARDINALITY CONSTRAINTS

one to many

WORKS-
EMPLOYEE DEPARTMENT
FOR
1 M

12
2
 CARDINALITY CONSTRAINTS

many-to-one

WORKS-
EMPLOYEE DEPARTMENT
FOR

12
3
 CARDINALITY CONSTRAINTS

many-to-many

WORKS-
EMPLOYEE PROJECT
ON
M N

12
4
 Benefits of ER diagrams

ER diagrams constitute a very useful framework for creating and

manipulating databases.

First, ER diagrams are easy to understand and do not require a person to

undergo extensive training to be able to work with it efficiently and
accurately. This means that designers can use ER diagrams to easily
communicate with developers, customers, and end users, regardless of their
IT proficiency.

Second, ER diagrams are readily translatable into relational tables which can
be used to quickly build databases. In addition, ER diagrams can directly be
used by database developers as the blueprint for implementing data in
specific software applications.

Lastly, ER diagrams may be applied in other contexts such as describing the

different relationships and operations within an organization.
 Decision table
• Decision tables can be used by software program to model
complicated logic.
• In decision table complex conditions and corresponding actions are
stored in a tabular form .
• What is decision table?
• It is a tabular representation of conditions and actions .
• It consists 4 quadrants of :
Condition stub
Condition rules
Action stub
Action rule
 Condition stub contains the conditions being examined. Condition enteries are used to
combine conditions into decision rules. The action stub describes the actions to be taken
in response to decision rules and the action entry relates decision rules to actions
Decision table for triangle problem
 Advantages
• Easy to use
• Easier to modify in comparison to flowcharts.
• Communication is easier between manager
and analysts
• Decision rules are clearly understood
• Facilitate more compact documentation
• Documentation is easily prepared, changed or
updated
 Disadvantages
• Does not depict the flow
• Impose an extra burden
• Not easy to translate
Finalise the requirements: Finalise the analyzed
requirements and proceed for next step i.e
Documentation
REQUIREMENTS
DOCUMENTATION
 REQUIREMENTS DOCUMENTATION

It is process of documenting user needs and constraints

This is the way of representing requirements in a consistent
format.

It is called Software Requirement Specification(SRS).

The main aim of requirements specification is :
--Systematically organize the requirements arrived during
requirements analysis.
--Documents requirements properly

It Serves as contract between customer & developer.

It is a reference document.
The requirements written using end user terminology
• Once the SRS document is approved by the
customer , development team starts to
develop the product according to the
requirements recorded in the SRS document.
• Final product will be acceptable to the
customer , as long as it satisfies all the
requirements recorded in the srs document.
• SRS document concentrates on:
• what needs to be done
• Carefully avoids the solution (“how to do”)
aspects.
 Nature of the SRS

The basic issues that the SRS writer shall address are the
following:

a) Functionality
b) External Interfaces
c) Performance
d) Attributes
e) Design Constraints imposed on an implementation.

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

SRS should be

1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Ranked for importance and/or stability
6. Verifiable
7. Modifiable
8. Traceable
• Correct : The SRS is correct if and only if, every
requirement stated therein is one that the
software shall meet.
• Unambiguous: every requirement has only
interpretation.
• Complete : SRS is complete if and only if it
includes all significant requirements relating
to functionality , performance, design,
constraints, attributes or external interfaces.
• Consistency : SRS is consistent if and only if, no
requirements are in conflicting situation.
Consistency is achieved by :
Use of standards terms or definitions
Use of data dictionary
• Ranked for importance or stability : SRS is ranked for
importance and/or stability if each requirement in it has an
identifier to indicate either the importance or stability of
that particular requirement.
• Verifiability : It should be verifiable
Eg: “system should be user friendly” is not 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.
Backward traceability : this depends upon each requirement explicitly
referencing its source in earlier documents.
Forward traceability : this depends upon each requirement in the SRS
having a unique name or reference number.
 Organization of the SRS
IEEE has published guidelines and standards to organize an SRS.

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, Acronyms and abbreviations
1.4 References
Overview
1.5
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
 Organization of the SRS

2.2 Product Functions

2.3 User Characteristics
2.4 Constraints
2.5 Assumptions for dependencies
2.6 Apportioning of requirements

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

4. Change Management Process

5. Document Approvals
6. Supporting Information
 Advantages of a SRS

Software SRS establishes the basic for agreement between the

client and the supplier on what the software product will do.

1. A SRS provides a reference for validation of the final product.

2. A high-quality SRS is a prerequisite to high-quality software.

3. A high-quality SRS reduces the development cost.

4. Provide a basis for estimating costs and schedules.

5. Provide a base line for validation and verification.
6. Establish the basis for agreement between customer and
developer.
 Problems without a SRS Document
The important problems that an organization would face if it does not
develop an SRS document are as follows:

• Without developing the SRS document, the system would not be

implemented according to customer needs.

• Software developers would not know whether what they are

developing is what exactly is required by the customer.

• Without SRS document, it will be very difficult for the maintenance

engineers to understand the functionality of the system.

• It will be very difficult for user document writers to write the users’
manuals properly without understanding the SRS document.
 For complex logic we have :
• Decision trees
• Decision table
REQUIREMENTS
VALIDATION
• It is a process of ensuring that system requirements are
complete, correct , consistent .
• After the completion of SRS document, we would like to
check the document for:
• Completeness & consistency check
• Validity checks
• Realism check
• Conformance to standards check
• Verifiability check
• Technical errors
• Ambiguous requirements
• Requirement Review process
Plan Distribute Read
SRS
review Document

Organize
review
meeting

Follow
Revise SRS
up
document
actions
• Plan review : The review team is selected and time and place for
review meeting is fixed.
• Distribute SRS document : SRS document is distributed to all the
members.
• Read SRS document : Each member should read the document
carefully to find conflicts, omissions, inconsistencies, etc
• Organize review meeting : each member presents his/her views and
identified problems . The problems are discussed and a set of
actions to address the problem is approved.
• Follow up actions : The chairperson of the team checks that the
approved actions have been carried out.
• Revise SRS : The SRS document is revised to reflect the approved
actions. At this stage , it may be accepted or may reviewed.
 REQUIREMENTS VALIDATION

Problem actions are :

• Requirements clarification

• Missing information (find this information from stakeholders)

• Requirements conflicts (Stakeholders must negotiate to resolve

this conflict)

• Unrealistic requirements

• Security issues
 REVIEW CHECKLISTS

Understandability
Redundancy
Completeness
Ambiguity
Consistency
Organization
Conformance to standards
Traceability
 VALIDATION TECHNIQUES

There are two requirements validation techniques:-

1. Requirements Reviews

2. Prototyping
REQUIREMENTS REVIEWS
 Requirement Management

Process of understanding and controlling changes to system

requirements. It should start as soon as SRS draft is made
available
It is continuous process throughout the development of
software.

ENDURING & VOLATILE REQUIREMENTS

o Enduring requirements: They are core requirements & are

related to main activity of the organization.
Example: issue/return of a book, cataloging etc.

o Volatile requirements: likely to change during software

development life cycle or after delivery of the product
• It involves :
• Requirement evolution
• Requirement Management plan
• Requirement change Management
• Evolution of requirements
• Induction to new requirements can happen during RE process or after system installation
Example : Adhering to Vasthu system for house .
• Requirements Assignment of responsibilities

Change Management
Management of changes

Documenting Requirement s

Requirements traceability

Communications of change

Establishment of baselines
1. Assignment of responsibilities : All changes
should be approved or rejecting by competent
authority designated for the project.
2. Management of changes : change request is
analyzed due to its impact on overall project
cost, resources allocated and delivery
schedule of the project. After implementation
of any change, formal notice is issued for the
information to all stakeholders
 Requirement Management planning

3. Documentation: documenting the

requirements
4. Requirements traceability : Traceability deals
with information about relationship between
requirements in order to manage the effect of
change and its impact on success of project
Requirement Traceability Matrix
Stake holder Req. Id Description
Manager 1.0 xxxxxxxxxxxx
Clerk 2.0 xxxxxxxxxxxxx
Admin 1.2 xxxxxxxxxxx
5. Communication of change
6. Establishment of baselines : after approval of
a change , it is communicated to all. If every
stakeholder agrees to the change , it is
implemented and tested.
Baseline is the tested version of a set of
requirements serve as a basis for further
development.
 Change management process
• An activity to check impact and cost of
changes

Problem analysis Change

Change analysis
and change Implementation
and costing
Specification

Revised
Requirements
 Requirement Management Planning

• Very critical.

• Important for the success of any

project.
 Requirement Change Management
Requirements change process should include the following activities to be
carried out when a change is needed in the requirements:-

•Assignment of responsibilities

• Management of changes

• Documentation

•Requirements traceability

• Communication of change

• Establishment of baseline
 Feasibility Study

A Feasibility Study is a study made before committing to a

project. It leads to a decision:
• go ahead
• do not go ahead
• think again

The main purpose of the feasibility study is to answer one

main question:

“Should we proceed with this project idea?”

11
 Feasibility Study

The purpose of feasibility study is not to solve the problem, but

to determine whether the problem is worth solving.

It concentrates on the following area :-

1. Organizational Feasibility
2. Technical Feasibility
3. Economic Feasibility
4. Legal feasibilty

12
 Elements of a good Feasibility Study

There are total six parts of any feasibility study :

• The Project Scope

• The Current Analysis

• Requirements

• Approach

• Evaluation
13

• Review
SOFTWARE QUALITY
ASSURANCE
 Software Quality

Our objective of software engineering is to produce good quality

maintainable software in time and within budget.

Here, quality is very important.

Different people understand different meaning of quality like:

•Conformance to requirements
•Fitness for the purpose
•Level of satisfaction

When user uses the product, and finds the product fit for its
purpose, he/she feels that product is of good quality. 1
6
9
 Software Quality Assurance

Software quality assurance (SQA) consists of a means of

monitoring the software engineering processes and methods
used to ensure quality.

Every software developers will agree that high-quality software is

an important goal. Once said, "Every program does something
right, it just may not be the thing that we want it to do."

1
7
0
 Software Quality Assurance

The definition serves to emphasize three important points:

1. Software requirements are the foundation from which quality

is measured. Lack of conformance to requirements is lack of
quality.

2. Specified standards define a set of development criteria that

guide the manner in which software is engineered. If the criteria
are not followed, lack of quality will almost surely result.

3. A set of implicit requirements often goes unmentioned (e.g.,

the desire for ease of use and good maintainability). If software
conforms to its explicit requirements but fails to meet implicit
1
7
requirements, software quality is suspect. 1
 Verification and Validation

It is the name given to the checking and analysis process.

The purpose is to ensure that the software conforms to its

specifications and meets the need of the customer.

Verification represents the set of activities that are carried

out to confirm that the software correctly implements the
specific functionality.

Validation represents set of activities that ensure that the

software that has built is satisfying the customer
requirements. 1
7
2
 Verification and Validation
Verification Validation

Are we building the product right? Are we building the right product?

Ensure that the software system Ensure that the functionalities meet
meets all the functionality the intended behavior.

Verifications take place first and Validation occurs after verification and
include the checking for mainly involves the checking of the
documentation, code etc overall product.
Done by developers Done by testers

Have static activities as it includes the Have dynamic activities as it includes

reviews, walk-through and inspections executing the software against the
to verify that software is correct or not requirements.
1
7
3
 Verification and Validation

In the verification and validation, two techniques of system

checking and analysis may be used:-

1. Software Inspection

2. System testing
The testing can be carried out using following tests:-
i. Unit testing
ii. Module testing
iii. System testing
iv. Acceptance testing
1
7
4
 SQA Plans

The SQA Plan provides a road map for instituting software quality
assurance. Developed by the SQA group, the plan serves as a
template for SQA activities that are instituted for each software
project.

The documentation section describes (by reference) each of the

work products produced as part of the software process. These
include –

• project documents (e.g., project plan)

• models (e.g., ERDs, class hierarchies)
• technical documents (e.g., specifications, test plans)
• user documents (e.g., help files)
1
7
5
 Methods for SQA

The methods by which quality assurance

is accomplished are many and varied,
out of which, two are mentioned as
follows:

1. ISO 9000
2. Capability Maturity Model

1
7
6
 ISO 9000
• “ISO” in greek means “equal”, so the association wanted to
convey the idea of equality.
• It is an attempt to improve software quality based on ISO
9000 series standards.
• It has been adopted by over 130 countries including India
and Japan.
• One of the problem with ISO-9000 series standard is that it
is not industry specific.
• It can be interpreted by the developers to diverse projects
such as hair dryers, automobiles, televisions as well as
software.
 Notes
• ISO-9000 applies to all types of organizations.
• After adopting the standards, a country
typically permits only ISO registered companies
to supply goods and services to government
agencies and public utilities.
• ISO-9000 series is not just software standard,
but are applicable to a wide variety of industrial
activities including design/development,
production, installation and servicing.
 ISO 9000 Certification
This process consists of following stages:-

1. Application
2. Pre-assessment
3. Document review and adequacy of audit
4. Compliance audit
5. Registration
6. Continued surveillance
 ISO 9000 Series
The types of software industries to which the different ISO
standards apply are as follows:

ISO 9001 : This standard applies to the organization engaged in

design, development, production & servicing of goods. This is the
standard that is applicable to most software development
organization.

ISO 9002 : This standard applies to the organization which do not

design products but only involved in production. E.g, Car
manufacturing industries.

ISO 9003 : This standard applies to the organization involved only in

installation and testing of the products.
Benefits of ISO 9000 Certification
1. Continuous Improvement
2. Improved Customer Satisfaction
3. Eliminate Variations
4. Better product and Services
5. Improved Profit levels
6. Improved Communication
7. Reduced Cost
 Capability Maturity Model
• It was developed by Software Engineering
Institute (SEI) of Carnegie-Mellon University in
1986.
• It specifies an increasing series of levels of a
software development organization. The
higher the level, the better the software
development process.
• It can be used in two ways: Capability
evaluation and Software process assessment.
CMM Levels
 CMM Levels
• Level One :Initial - The software process is characterized as inconsistent, and
occasionally even chaotic. Defined processes and standard practices that
exist are abandoned during a crisis. Success of the organization majorly
depends on an individual effort, talent, and heroics. The heroes eventually
move on to other organizations taking their wealth of knowledge or lessons
learnt with them.
• Level Two: Repeatable - This level of Software Development Organization has
a basic and consistent project management processes to track cost, schedule,
and functionality. The process is in place to repeat the earlier successes on
projects with similar applications. Program management is a key
characteristic of a level two organization.
• Level Three: Defined - The software process for both management and
engineering activities are documented, standardized, and integrated into a
standard software process for the entire organization and all projects across
the organization use an approved, tailored version of the organization's
standard software process for developing, testing and maintaining the
application.
 CMM Levels
• Level Four: Managed - Management can effectively control the software
development effort using precise measurements. At this level, organization
set a quantitative quality goal for both software process and software
maintenance. At this maturity level, the performance of processes is
controlled using statistical and other quantitative techniques, and is
quantitatively predictable.

• Level Five: Optimizing - The Key characteristic of this level is focusing on

continually improving process performance through both incremental and
innovative technological improvements. At this level, changes to the process
are to improve the process performance and at the same time maintaining
statistical probability to achieve the established quantitative process-
improvement objectives.
 Key Process Areas of each Level
CMM Level Focus Key Process Areas
Initial Competent people -
Repeatable Project Management Software Project Planning
Software Configuration Management
Defined Definition of Processes Process Definition
Training Program
Peer Reviews
Managed Product and process quality Quantitative Process Metrics
Software Quality Management
Optimizing Continuous Process Defect Prevention
Improvement Process Change Management
Technology Change Management
 Comparison of ISO-9000 Certification & SEI-CMM
ISO focus on the “customer-supplier relationship”, whereas CMM focus on software
supplier to improve its processes to achieve a higher quality product for the benefit
of the customer.

ISO 9000 standard is written for a wide range of industries whereas CMM
framework is specifies for the software industry.

CMM is a five level framework for measuring software engineering practices, and
ISO 9000 defines a minimum level of attributes for a quality management program.

The ISO 9000’s concept is to follow a set of standards to make success repeatable.
The CMM emphasizes a process of continuous improvement.

Once an organization has met the criteria to be ISO certified by an independent

audit, the next step is only to maintain that level of certification. CMM is an on-
going process of evaluation and improvement, moving from one level of
1
achievement to the next. Even at the highest level of maturity, the focus8 is on
7
continuous improvement.
END