LECTURE NOTES ON

SUBJECT: SOFTWARE ENGINEERING

SUBJECT CODE: KCS-601

Unit-2
[Link]
BRANCH: CSE & IT
YEAR- 3RD SEMESTER- 6th

(AKTU)

Rohit Mishra
(Assistant Professor)

Department of Computer Science & Engineering and

Information Technology

United Institute of Technology (284), Naini, Prayagraj

Unit Topic Proposed

Lecture
Software Requirement Specification (SRS): Requirement Engineering Process:
Elicitation, Analysis, Documentation, Review and Management of User Needs,
II Feasibility Study, Information Modelling, Data Flow Diagrams, Entity 8
Relationship Diagrams, Decision Tables, SRS Document, IEEE Standards for
SRS. Software Quality Assurance (SQA): Verification and Validation, SQA Plans,
Software Quality Frameworks, ISO 9000 Models, SEI-CMM Model.
 Unit-2
Software Requirement Specifications
2.1 Software Requirement
1. A condition of capability needed by a user to solve a problem or achieve an objective
2. A condition or a capability that must be met or possessed by a system ... to satisfy a contract,
standard, specification, or other formally imposed document."

1. Known Requirements:- Something a stakeholder believes to be implemented

2. Unknown requirements:-Forgotten by the stakeholder because they are not
needed right now or needed only by another stakeholder
3. Undreamt requirements:- stakeholder may not be able to think of new
requirement due to limited knowledge
A Known, Unknown and Undreamt requirements may functional or non functional.

• Functional requirements: - describe what the software has to do. They are often called
product features. It depends on the type of software, expected users and the type of system
where the software is used.
• Non Functional requirements: - are mostly quality requirements. That stipulate how well
the software does, what it has to [Link] define system properties and constraints e.g.
reliability, response time and storage requirements. Constraints are I/O device capability,
system representations, etc.
• User requirements:- Statements in natural language plus diagrams of the services the
system provides and its operational constraints.
• System requirements: - A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines what should be
implemented so may be part of a contract between client and contractor.
2.2 Requirements engineering Process
• The process of finding out, analyzing, documenting and checking these services and
constraints called requirement engineering.
• RE produces one large document, written in a natural language, contains a
description of what the system will do without how it will do
• Input to RE is problem statement prepared by the customer and the output is SRS
prepared by the developer.
• The requirements themselves are the descriptions of the system services and constraints
that are generated during the requirements engineering process.
Requirements engineering processes:-
The processes used for RE vary widely depending on the application domain, the people involved and
the organisation developing the requirements. However, there are a number of generic activities
common to all processes
• Requirement’s elicitation
• Requirement’s analysis
• Requirement’s documentation
Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
1
 • Requirements review

Crucial process steps of Requirement

Problem
Statement or
Engineering
feasibility study

Requirement
Elicitation

Requirement Requirement
Engineering analysis

Requirement
documentation

Requirement
Review
SRS

• Requirement Elicitation: - known as gathering of requirement. Here requirement are identified

with the help of customer and exiting system processes, if they are available.
• Requirement Analysis: - analysis of requirement stars with Requirement Elicitation.
Requirements are analyzed in order to identify inconstancy, defects etc.
• Requirement Documentation:- this is the end product of requirement elicitation and analysis.
Documentation is very important as it will be the foundation for the design of the software. The
documentation is known as SRS.
• Requirement Review:-review process is carried out to improve the quality of the SRS. it may
also called verification. It should be a continuous activity that is incorporated into the
elicitation, analysis, documentation.
The primary output of requirement engineering process is requirement specification (SRS).

2.1.1 Feasibility Study: - It is the process of evaluation or analysis of the potential impact of a
propose project or program.
Five common factors (TELOS)
 Technical feasibility: - Is it technically feasible to provide direct communication
connectivity through space from one location of globe to another location?
 Economic feasibility:-Are the project’s cost assumption realistic?
 Legal feasibility: - Does the business model realistic?
 Operational feasibility: - Is there any market for the product?
 Schedule feasibility: - Are the project’s schedule assumption realistic?

2.1.2 Elicitation: - It is also called requirement [Link] are identified with the help
of customer and exiting system processes, if they are available. Requirement Elicitation is most
difficult is perhaps most critical most error prone most communication intensive aspect of
software development.
Various methods of Requirements Elicitation
1. Interviews
• After receiving the problem statement from the customer, the first step is to arrange a
meeting with the customer.
• During the meeting or interview, both the parties would like to understand each other.
• The objective of conducting an interview is to understand the customer’s expectation
from the software
Selection of stakeholder
1. Entry level personnel
2. Middle level stakeholder
3. Managers
Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
2
 4. Users of the software (Most important)
2. Brainstorming Sessions
• Brainstormy is a group technique that may be used during requirement elicitation to
understand the requirement
• Every idea will be documented in a way that every can see it
• After brainstormy session a detailed report will be prepared and reviewed by the
facilitator
3. Facilitated Application specification approach (FAST)
• FAST is similar to brainstormy session and the objective is to bridge the expectation
gap-a difference what the developers think they are suppose to build and what the
customer think they are going to get
• In order to reduce the gap a team oriented approach is developed for requirement
gathering and is called FAST
4. Quality function deployment (QFT)
• It incorporates the voice of the customer and converts it in to the document.
5. Use case Approach:
• Combination of text & picture to improve understanding. There are three term: use
case, use case scenario, use case diagram. Use case diagram: use the following
components for design.
o Actor (External Agent)- lies out side the system(ex: person, M/C, Info)
o Use case: describe the sequence of interaction B/W actor and system.
o Association (Arrow)
2.1.3 Analysis
Requirement analysis phase analyze, refine and scrutinize requirements to make consistent &
unambiguous requirements.

1. Draw the context diagram

The context diagram is a simple model that defines the boundaries and interface of the
proposed system.
2. Development of prototype
Prototype helps the client to visualize the proposed system and increase the understanding of
requirement. Prototype may help the parties to take final decision.
3. Model the requirement
This process usually consists of various graphical representations of function, data entities,
external entities and their relationship between them. It graphical view may help to find
incorrect, inconsistent, missing requirements. Such models include data flow diagram, entity
relationship diagram, data dictionary, state transition diagram.
4. Finalize the requirement

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
3
 After modeling the requirement inconsistencies and ambiguities have been identified and
corrected. Flow of data among various modules has been analyzed. Now Finalize and
analyzes requirements and next step is to document these requirements in prescribed format.

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

[Link] Software requirement specification

Requirements specification is a complete description of the behavior of a system to be
developed. It includes a set of use cases that describe all the interactions the users will
have with the software. Use cases are also known as functional requirements. In
addition to use cases, the SRS also contains non-functional (or supplementary)
requirements. Non- functional requirements are requirements which impose
constraints on the design or implementation (such as performance engineering
requirements, quality standards, or design constraints).

Need for Software Requirement Specification (SRS)

• The problem is that the client usually does not understand software or the software
development process, and the developer often does not understand the client's
problem and application area.
• This causes a communication gap between the parties involved in the
development project. A basic purpose of software requirements specification
is to bridge this communication gap.

Characteristics of good SRS document: - Some of the identified desirable qualities of the
SRS documents are the following-
Concise- The SRS document should be concise and at the same time unambiguous,
consistent, and complete. An SRS is unambiguous if and only if every requirement stated
has one and only one interpretation.
Structured- The SRS document should be well-structured. A well-structured document is
easy to understand and modify. In practice, the SRS document undergoes several revisions
to cope with the customer requirements.

Black-box view- It should only specify what the system should do and refrain from stating
how to do. This means that the SRS document should specify the external behaviour of the
system and not discuss the implementation issues.

Conceptual integrity- The SRS document should exhibit conceptual integrity so that the
reader can easily understand the contents.

Verifiable- All requirements of the system as documented in the SRs document should be
verifiable. This means that it should be possible to determine whether or not requirements
have been met in an implementation.

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
4
2.1.5 Requirements Validation
Requirement Validation is used for checking the document:-
• Completeness & consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements

2.3 Review and Management of User Needs:

The User Requirement Document (URD) is a document used in software engineering that
specify the requirements of user’s aspect from software to be constructed in a software project.
An important and difficult step of designing a software is determining what the
customer actually want it to do. This is because the customer is often not able to communicate
their needs and want it to do. The information they provide may also be incomplete, may
inaccurate and self-conflicting. The responsibility is completely understanding what the
customer wants then falls on the provider of the product. Hence we can broadly classify request
in two categories.
a. Enduring Requirement: are core request and are related to main activity of the organization.
They are stable and don’t change easily.
b. Volatile Requirement: are likely to change during software development life cycle or even
after delivery of the produce. The reason for changes are:
• Change in the requirement
• Change in technology
• Change in policies
• Change in customer’s expectation

2.4 Information Modelling:

The term information modelling is generally used for model of individual themes such as
facilities, building, processes, plans etc. In this case the concept is specialized to facility information
model, building information model, plan information model etc.
Such an information model is an integration of a model of facility with the data & document
about the facility. Within the field of data software engineering and data modelling an information
model is an abstract, formal representation of entity types. It includes their properties, relationship and
operation that can be perform on them. An information model in software engineering is a
representation of concept, relationship, constraint, rules and operation to specify data systematic for a
chosen domain of disclose. It can provide stable and organised structure of information requirement
for the domain constraint.

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
5
2.4.1. Data Flow Diagram:
A DFD is also known as “bubble Chart” has the purpose of clarifying system requirements
and identifying major transformation.
• It shows the flow of data through a system.
• It is a graphical tool because it present a picture.
• It present a system or software at any level of abstraction.
Four simple notation are used to complete a DFD-
I. Data Flow-The data flow is used to describe the movement of information from a
part of system to another part.
II. Process-A circle or bubble represents a process that transform incoming data to
outgoing data.
III. External Entity- A square defines a source or destination of system data. External
entities represents any entity that supplies information from the system.
IV. Data Store- The data store is used to collect data at rest or a temporary repository of
data.
Standard Symbols for DFD’s

Symbol Name Function

Data flow Used to connect processes to each other

Process Performs some transformation

of input data to yield output data
Source or sink A source of system inputs or sink of
System outputs
Data Store A repository of data, the arrowheads
Indicate net inputs and net outputs
to store.

DFD for QUIZ SOFTWARE

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
6
DFD for UNIVERSITY COURSE REGISTRATION SYSTEM

Data Dictionaries
Data Dictionaries are simply repositories to store information about all data items defines in
DFD.
At the requirement stage, the data dictionary should at least define customer data items, to
ensure that the customer and developer use, the same definitions and terminologies.
Typical information stored include –
• Name of the data item
• Aliases
• Description/Purpose
• Related data items
• Range of Values
• Data Structure Definition
The data dictionary has two different kinds of items: composite data and elemental data.
• Higher-level (composite) elements may be defined in terms of lower-level items.
• Elemental data are items that cannot be reduced any further and are defined in terms
of the values that it can assume or some other unambiguous base type.
The general format of a data dictionary is similar to a standard dictionary; it contains an
alphabetically ordered list of entries.
Each entry consists of a formal definition and verbal description

COMPOSITE DATA
Composite data can be constructed in three ways: sequence, repetition, or selection of other
data types.
sequence:
+ A plus sign indicates one element is followed by or concatenated with another element.
repetition:
[ ] Square brackets are used to enclose one or more optional elements.
| A vertical line stands for "or" and is used to indicate alternatives.
selection:
{} Curly braces indicate that the element being defined is made up of a series of repetitions of
the element(s) enclosed in the brackets.
{ }y The upper limit on the number of allowable repetitions can be indicated by including an
integer superscript on the right bracket. Here y represents an integer and indicates that the
number of repetitions cannot be greater than y.

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
7
Examples of COMPOSITE DATA
sequence:
Mailing-address = name + address + city + zip-code
* The address at which the customer can receive mail *

repetition:
Completed-order = [ item-ordered ]
* A complete customer order *

selection:
Atm-transaction = { deposit | withdrawal }
* An customer transaction at an automated teller machine *
In these examples asterisks are used to delimit the comment or verbal description of the item, but
other notations can be used as well.

Examples of ELEMENTAL DATA

Elemental data is described in terms of a data type or by listing the values that the item can assume.
desired-temperature = floating point
*Desired-temperature is the value the user sets for desired water temperature in the pool. It is a
floating point number in the range from 0.0 to 100.0, inclusive. The units are Celsius.*
age = non-negative integer
*Age is how old the customer is in years. Age is a whole number greater than or equal to zero.*
performances-attended = counter
* Performances-attended is the number of performances this customer has attended.*
counter = positive integer
*Counter is a whole number greater than zero that can only be incremented by one and never
decremented.*

Mathematical Operator used within DD

Notations Meaning
x=a+b x consists of data elements a & b
x=[a|b] x consists of either data element a or b
x=a x consists of data element a
x=y{a} x consists of y or more occurrences of data element a
x = {a}z x consists of z or fewer occurrences of data element a
x=y{a}z x consists of some occurrences of data element a which are between y and z.

2.4.2 Entity Relationship Diagram

• The entity relationship data model is based on a perception of a real word that consist of a
basic objects, called entity, and of relationships among these objects.
• 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.
• An entity is a object or thing in the real world that is distinguishable from other objects.
• An entity have a set of attributes. A relationship is an association among several entities. ER
diagram consist of following major component-
i. Rectangle-which represent entity sets.
ii. Ellipse-which represent attributes.
iii. Diamond-which represent relationship sets.
iv. Lines-which link attributes to entity set and to relationship sets.

Symbols used in E-R Diagram

Entity – rectangle
Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
8
Attribute -oval
Relationship – diamond
Link - line

Advantages of E-R Model-

▪ It is easy and simple to understand with minimal training. Therefore the model can be
used by the db designer to communicate design to end user.
▪ It has explicitly linkages between entities.
▪ In the ER model it is possible to find a connection from one node to all the other nodes.
Disadvantages of E-R Model-
▪ Limited constraint representation.
▪ Limited relationship representation.
▪ No representation of data.
▪ Loss of information.
TYPES OF ATTRIBUTES
There are total six types of attributes :-
1. Simple attribute
1. Composite attribute
2. Derived attribute
3. Stored attribute
4. Single valued attribute
5. Multi valued attribute
Simple attribute:
Cannot be split in to further attributes(indivisible). Also known as Atomic attribute. Ex:
Ssn(Social Security Number) or Roll No

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
9
Composite attribute:
Can be divided in to smaller subparts which represent more basic attributes with independent
meaning Even form hierarchy Ex: Address, Name

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

Stored attribute:
Attributes from which the values of other attributes are derived. For example, ‘Date of birth’
of a person is a stored attribute.

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

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

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
10
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.

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

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.

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.

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.

Graphical Representation in E-R diagram

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
11
More techniques for data analysis
There are two main techniques available to analyze and represent complex processing logic:
1. Decision trees and
2. Decision tables.

2.5 DECISION TREES

A decision tree gives a graphic view of the processing logic involved in decision making and
the corresponding actions taken.
The edges of a decision tree represent conditions and the leaf nodes represent the actions to
be performed depending on the outcome of testing the condition.
EXAMPLE
Consider Library Membership Automation Software (LMS) where it should support the following
three options:

1. New member
2. Renewal
3. Cancel membership

New member option

Decision: When the 'new member' option is selected, the software asks details about the
member like member's name, address, phone number etc.
Action: If proper information is entered, then a membership record for the member is created
and a bill is printed for the annual membership charge plus the security deposit payable.
Renewal option
Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and his
membership number to check whether he is a valid member or not.
Action: If the membership is valid then membership expiry date is updated and the annual
membership bill is printed, otherwise an error message is displayed.
Cancel membership option
Decision: If the 'cancel membership' option is selected, then the software asks for member's
name and his membership number.
Action: The membership is cancelled, a cheque for the balance amount due to the member is
printed and finally the membership record is deleted from the database.

Decision Tree Representation

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
12
DECISION TABLES
A major drawback to decision tree is the lack of information in its format to tell us what other
combination of conditions of test. To overcome from this drawback decision table is used.
▪ A decision table is a table of contingencies for defining a problem and the action to be
taken.
▪ It is a single representation of the relationships between conditions and action.
Decision tables are used mainly because of their visibility, clearness, coverage capabilities, low
maintenance and automation fitness.
A Decision table consist two parts:-
i. Stub- The stub part is divided into “upper quadrant” and “lower quadrant” called condition
and action stub.
ii. Entry- The entry part are also divided into “upper quadrant” and “lower
quadrant”.
STRUCTURE
The four quadrants
Conditions Condition alternatives
Actions Action entries

Decision Table for LMS

Suppose a technical support company writes a decision table to diagnose printer problems based
upon symptoms described to them over the phone from their clients.

BENEFITS
• Decision tables, especially when coupled with the use of a domain-specific language,
allow developers and policy experts to work from the same information, the decision
tables themselves.

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
13
 • Tools to render nested if statements from traditional programming languages into decision
tables can also be used as a debugging tool.
• Decision tables have proven to be easier to understand and review than code, and have
been used extensively and successfully to produce specifications for complex systems.

2.6 REQUIREMENTS DOCUMENTATION

This is the way of representing requirements in a consistent format.
It is called Software Requirement Specification(SRS).
SRS serves many purpose depending upon who is writing it.
• written by customer
• written by developer
Serves as contract between customer & 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.

2.7 IEEE Standards of SRS

The SRS development is a collaborative effort for designing a software project which is
further converted into SRS document. Several organizations have a proposed their basic
structure and the components for SRS. IEEE has given basic structure for software
development.
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
1.5 Overview
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
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.1 External Interfaces
Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
14
 3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design Constraints
3.6 Software System attributes
3.7 Organization of specific requirements
3.8 Additional Comments.
4. Change Management Process
5. Document Approvals
6. Supporting Information

2.8 REQUIREMENTS VALIDATION

After the completion of SRS document, we would like to check the document for:
• Completeness & consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements
The objective of requirements validation is to certify that the SRS document is an
acceptable document of the system to be implemented.

VALIDATION TECHNIQUES
There are two requirements validation techniques:-
1. Requirements Reviews
2. Prototyping

REQUIREMENTS REVIEWS

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
15
REQUIREMENTS VALIDATION
Problem actions
• 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

REQUIREMENT MANAGEMENT
Process of understanding and controlling changes to system requirements.
ENDURING & VOLATILE REQUIREMENTS
• Enduring requirements: They are core requirements & are related to main
activity of the organization. Example: issue/return of a book, cataloging etc.
• Volatile requirements: likely to change during software development life cycle
or after delivery of the product

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
• Requirement’s traceability
• Communication of change
• Establishment of baseline

2.9 SOFTWARE QUALITY ASSURANCE

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. Software Quality assurance plan is a standard activity which ensure the
quality goals of the organization.
• It gives details and template on all activities, which have become part of the
standard implementation.

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
16
Software quality assurance (SQA) consists of a means of monitoring the software
engineering processes and methods used to ensure quality. The SQA plan include the following:
• Project planning
• Models of data, classes and object, processes, design architecture
• SRS
• Test plans for testing SRS
• User manuals online help etc.
• Audit & Review
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."
In SQA plan 3 kinds of activities performed:
• Organization specific
• Software specific
• Customer Specific
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 requirements, software quality is suspect.

2.9.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.
Software verification refers to a set of activities that ensure that software correctly
implements a specific function i.e.
“Are we building the product right”.
Software validation is concerned with showing that the requirements actually define the
system that the customer wants. It refers to a set of activities that ensure that the software that
is going to be build is traceable to customer requirements.
“Are we building the right product”.
Traditionally software verification & validation is defined as system engineering methodology
to ensure that quality is built into software during development. The analysis and test
activities are performed by V & V evaluates and assess the software product.

Verification Validation
Are we building the product right? Are we building the right product?
Ensure that the software system meets all the Ensure that the functionalities meet the intended
functionality behavior.
Verifications take place first and include the Validation occurs after verification and mainly
checking for documentation, code etc involves the checking of the overall product.
Done by developers Done by testers
Have static activities as it includes the reviews, Have dynamic activities as it includes executing
walk-throughs and inspections to verify that the software against the requirements.
software is correct or not

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
17
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

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

2.9.3 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
[Link] ISO 9000
ISO” in greek means “equal”, so the association wanted to convey the idea of equality. The
ISO 9000 standard specifies the guidelines for maintaining for a quality system.
• The ISO standard mainly addresses operational aspects and organizational aspects.
Such as responsibility, reporting, etc.
• It is important to realize that ISO 9000 standard is a set of guidelines for the
production process and is not directly concerned with product itself.
“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 problems 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.

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

ISO 9000 certification serves as reference for contact between independent parties.
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

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
18
ISO 9000 Series
ISO 9000 is a series of three standards:
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

[Link] 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. The capability maturity model is not
a software life cycle model. Instead it is a strategy for improving the software process,
irrespective of actual life cycle model used.
There are five level of maturity:
i. Initial
ii. Repeatable
iii. Define
iv. Manage
v. Optimizing

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
Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
19
 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.
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 Quantitative Process Metrics
quality 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 achievement to the next. Even at the highest
level of maturity, the focus is on continuous improvement.

Prepared By:
Mr. Rohit Mishra
Assistant Professor (UIT)
20