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 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 ,
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
 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
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
 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

74
 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

83
 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 continously 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 –

a) Data flow Diagrams

b) Data Dictionaries

c) ER Diagrams

87
 a) 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.

.
 contd….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
89
 Contd…Data Flow Diagrams

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 .

91
 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.

92
DFD for Result management Sytem

93
 b) 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.
 Contd….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
95
 Contd..Data dictionaries

Example :

weekly timesheet = employee_name + Employee_Id + { Regular_Hours +

Overtime_hours }

Pay_rate = {hourly | daily | weekly } + Dollar_amount

96
 c) ER Diagram

• 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.

97
 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.

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

99
 ER Model

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

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
0
 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
1
 Types of Attributes

There are total six types of attributes :-

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

10
2
 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

• Composite attribute:

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

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

10
3
 Types of attributes

•Derived attribute:
Attribute values are derived from another attribute.
Denoted by dotted oval
Ex - Age

10
4
 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.

10
5
 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

10
6
Graphical Representation in E-R diagram

10
7
 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)

May
Student course
have

Teacher

10
8
 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.

10
9
 Cardinality constraints

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

11
0
 Cardinality constraints

one-to-one

EMPLOYEE MANAGES DEPARTMENT

1 1

11
1
 Cardinality constraints

one to many

WORKS-
EMPLOYEE DEPARTMENT
FOR
1 M

11
2
 Cardinality constraints

many-to-one

WORKS-
EMPLOYEE DEPARTMENT
FOR

11
3
 Cardinality constraints

many-to-many

WORKS-
EMPLOYEE PROJECT
ON
M N

11
4
STUDENT MANAGEMENT
SYSTEM
Step 4 : Finalise the requirements :Finalise the
analyzed requirements and proceed for next step i.e
Documentation
 3. 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

--Defines the customer’s requirements in terms of :

Function
Performance
External interfaces
Design constraints
--It Serves as contract between customer & developer.
---It is a reference document.
 Contd....SRS

• The requirements at this stage

– written using end-user terminology.
• If necessary:
– later a formal requirement specification may
be developed from it.
 Contd..SRS

• The SRS document is known as black-box specification:

– system is considered as a black box whose internal details are
not known.
– only its visible external (i.e. input/output) behavior is
documented.
Input Data Output Data

• SRS document concentrates on: S

what needs to be done
Carefully avoids the solution (“how to do”) aspects.
 Contd.. What is not included in an SRS ?

Project requirements
– cost, delivery schedules, staffing, reporting
procedures
Design solutions
– partitioning of SW into modules, choosing data
structures
Product assurance plans
– Quality Assurance procedures, Configuration
Management procedures, Verification &
Validation procedures
 Contd..

• 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.
 Contd..SRS
Purpose of SRS
– communication between the Customer, Analyst,
system developers, maintainers, ...
– contract between developer and customer
– firm foundation for the design phase
– support system testing activities
– support project management and control
– controlling the evolution of the system
 SRS Prototype Outline

[ IEEE SRS Standard ]

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview
 SRS - Introduction Section
• Purpose
– delineate the purpose of the particular SRS
– specify the intended audience for the SRS
• Scope
– identify the Software products to be produced by name
– explain what the Software product will do, and if necessary,
what it will not do
– describe the application of the Software being specified. i.e.
benefits, objectives, goals as precisely as possible
• Overview
– describe what the rest of the SRS contains
– how the SRS is organized
 Contd…SRS Prototype Outline

[ IEEE SRS Standard ]

2. General description
2.1 Product perspective
2.2 Product function summary
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
 Product Perspective

• State whether the product is independent and totally

self contained
• If the product is component of a larger system then:
– describe the functions of each component of the
larger system and identify interfaces
– overview of the principal external interfaces of this
product
– overview of HW and peripheral equipment to be
used
• Give a block diagram showing the major components
of the product, interconnections, and external
interfaces.
Product Functions

• Provide a summary of functions the Software will

perform
• The functions should be organized in such a way
that they are understandable by the user

User Characteristics
• Describe the general characteristics of the eventual
users of the product. (such as educational level,
experience and technical expertise )
General Constraints

• Regulatory policies
• Hardware limitations
• Interfaces to other applications
• Parallel operation
• Audit functions
• Control functions
• Criticality of the application
• Safety and security considerations
 Contd…SRS Prototype Outline

3. Specific Requirements
- Functional requirements
- External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability, maintainability
- Other requirements
Appendices
Index
Functional Requirements

• Introduction
– describe purpose of the function and the
approaches and techniques employed
• Inputs and Outputs
– sources of inputs and destination of outputs
– quantities, units of measure, ranges of valid
inputs and outputs
– timing
Contd..Functional Requirements

• Processing
– validation of input data
– exact sequence of operations
– responses to abnormal situations
– any methods (eg. equations, algorithms) to be used
to transform inputs to outputs
External Interface Requirements

• User interfaces
• Hardware interfaces
• Software interfaces
• Communications interfaces
• Other requirements
– database: frequency of use, accessing capabilities,
static and dynamic organization, retention
requirements for data
– operations: periods of interactive and unattended
operations, backup, recovery operations
– site adaptation requirements
 Appendices

• Not always necessary

• It may include:
– sample I/O formats
– DFD, ERD documents
– results of user surveys, cost analysis studies
– supporting documents to help readers of SRS
 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
 Contd..

• 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 : A requirement is verifiable if and only if there exists some
finite cost effective process with which a person or machine can check that
the SW meets the requirement.
 Contd..

• 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..
 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 table
 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:- It contains the conditions being examined.

-Condition enteries:- Condition enteries are used to combine conditions into

decision rules.
-Action stub: It describes the actions to be taken in response to decision rules
-Action rule:- It relates decision rules to actions
Contd..
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
 Dis-advantages

• Does not depict the flow

• Impose an extra burden
• Not easy to translate
 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
4
5
 Verification and Validation
Verification Validation

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

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

1
4
6
 SQA(Software Quality Assurance)

• SQA : It is a process of defining how software quality can be

achieved and how the development organization knows that the
software has the required level of quality.

• It is an action taken to prevent quality problems from

occuring means devising systems for carrying out tasks
which directly affect product quality.

• Quality assurance is the set of support activities needed to

provide adequate confidence that processes are established and
continuously improved in order to products that meet
specifications and are fit for use.
 Contd..

• The first and foremost requirement in SQA is that it is a

separate group responsible for quality in the organization.
• They set the goals, standards and mechanisms (systems) for
SQA. The role of the SQA group is to assist the software
development team in managing the quality requirements of the
software.
• Every software has certain quality goals specified by the
customer. These quality goals are to be achieved by the
development team by introducing a set of activities or
ensuring the delivery of quality to the customer.
 The causes for not meeting the quality commonly are
Its causes:

• Lack of understanding of customer requirements

• Violation of standards (Design, Programming)
• Erroneous data representation
• Improper interface
• Faulty logic in rules and processes
• Erroneous testing
• Incomplete and defective documentation
• Hardware and software platforms not coping up to required
standards
• Lack of domain knowledge
There are a large number of tasks involved in SQA activities

•Formulating a quality management plan

•Applying software engineering techniques
•Conducting formal technical reviews
•Applying a multi-tiered testing strategy
•Enforcing process adherence
•Controlling change
•Measuring impact of change
•Performing SQA audits
•Keeping records and reporting
 SQA Plan

It is a roadmap for software quality assurance.

SQA plan is developed while planning the project .
It is a document created for summarizing all the SQA
activities conducted for the software project.
The plan specifies the goal and tasks that can be performed in
order to conduct all the SQA activities . Such plan should be
developed by SQA group
 Outline structure for quality plan includes:

1. Product introduction : A description of the product , its

intended markets and quality expectations for the product
2. Process descriptions : the development process should be used
for product development and management.
3. Quality goals :
4. Risks and risks management : the key risk areas might affect
product quality and the actions to address those risks.
 Capability Maturity Model (CMM)

• The Capability Maturity Model (CMM) is a methodology used to develop

and refine an organization's software development process. The model
describes a five-level evolutionary path of increasingly organized and
systematically more mature processes. CMM was developed and is
promoted by the Software Engineering Institute (SEI) , a research and
development center sponsored by the U.S. Department of Defense (DoD).

• SEI was founded in 1984 to address software engineering issues and, in a

broad sense, to advance software engineering methodologies. More
specifically, SEI was established to optimize the process of developing,
acquiring, and maintaining heavily software systems for the DoD. Because
the processes involved are equally applicable to the software industry as a
whole, SEI advocates industry-wide adoption of the CMM.
 SQA standards

• ISO 9000
• CMM
 ISO 9000(International organization for standardization)
“ISO” in greek means “equal”, so the association wanted to
convey the idea of equality
• The ISO 9000 standard:
• It is a set of quality standards determined by the International
Organization for Standardization to assure that businesses meet a high
level of quality with products, services, organizational processes and
ethics
– specifies guidelines for maintaining a quality system.
– It describes quality assurance elements in generic terms that can be
applied to any business regardless of the products or services offered.
.
 Contd..

• 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 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

• It gives an opportunity to increase value to their activities and to improve

their performance continuous by focusing on their major processes.
• It emphasis on quality management systems.
Basic benefits include:
1. Continuous improvement
2. Improved customer service
3. Highlights weekness and suggests corrective measures for improvements
4. It gives sign of customer confidence
5. Increased employee participation
6. Better product and services
 Software Engineering Institute (SEI) Capability Maturity Model

A software process is not a static

entity-it has to change so that
product produced using the process are of higher
quality.

Process management focus on improving the process which in

turn improves quality and high productivity for products
using the process.
 Contd..

• To improve the process first organization has to understand the

current status of process and then develop a plan to improve it.
• And if we agree the changes – we introduce the changes in
small increments not totally revolutionize the process totally.
CMM deals the improvement in the process to deliever high
quality and high productivity product
 Contd… Capability Maturity Model

• 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 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
• All projects across the organization use an approved, tailored version of the
organization's standard software process for developing, testing and
maintaining the application.
• In the process , each step is carefully defined with verifiable entry and exit
criteria
• At this level verifications for the output is defined
 CMM Levels
Level One : Initial
• The process at this level is adhoc and has no formalized method
• 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 process capability is unpredictable as the process constantly changes.
• Organization at this level can be improved by improving project management ,
quality assurance and change control
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.
 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 focus6 is on
7
continuous improvement.
END