SOFTWARE ENGINEERING

(KCS 601)

Lecture Notes

UNIT II – SOFTWARE
REQUIREMENT SPECIFICATIONS
(SRS)
 Unit-2 Syllabus
Software Requirement Specifications (SRS): Requirement Engineering Process: Elicitation, Analysis,
Documentation, Review and Management of User Needs, Feasibility Study, Information Modelling,
Data Flow Diagrams, Entity 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.
REQUIREMENT-

We define requirement as:

• Conduction of capability needed by a user to solve a problem or achieve an objective

• A Condition or capability that must be met or possess by a system to satisfy a

contract, standard, specification or other formally imposed document.

SRS (SOFTWARE REQUIREMENT SPECIFICATION) –

• It is a document that completely describes what the proposed software should do

without describing what the proposed software should do without describing how
the software will do it.
REQUIREMENT ENGINEERING –

• It can be defined as the “Systematic process of documenting requirement

through an interactive cooperative process of analyzing the problem,
documenting the resulting observations in a variety of representation format
& checking the accuracy of the understanding gained”

OR

 It is defines as “ the systematic use of proven principles techniques , tools &

languages for the cost effective analysis, documentation and ongoing evolution of
user needs & the specification of the external behaviors of the system in order to
satisfy these needs.

INFORMAL & REQUIREMENT WELL DEFINED COMPLETE

FUZZY &CONSISTENT
REQUIREMENT
ENGINEERING REQUIREMENTS

Requirement engineering is a crucial phase in software development that involves understanding,

documenting, validating, and managing the requirements of a system. It's a systematic approach to
identifying what a software system should do and how it should behave to meet the needs of its users
and stakeholders. Here's an overview of the requirement engineering process, including its phases:
Elicitation:
 Elicitation involves gathering requirements from stakeholders, including end-users, customers,
domain experts, and other relevant parties.
 Techniques such as interviews, questionnaires, workshops, and observations are commonly used
to elicit requirements.
 The goal is to understand the needs, expectations, constraints, and objectives of the
stakeholders.
Analysis:
 Once requirements are gathered, they need to be analyzed to ensure they are complete,
consistent, and feasible.
 Requirements analysis involves refining and prioritizing requirements, resolving conflicts, and
identifying dependencies.
 Techniques like requirements prioritization, feasibility analysis, and requirements modeling are
used in this phase.
Documentation:
 Requirements need to be documented in a clear and concise manner to ensure mutual
understanding among stakeholders and serve as a basis for system design and implementation.
 Requirement documents typically include functional requirements (what the system should do)
and non-functional requirements (quality attributes like performance, security, and usability).
 Diagrams, use cases, user stories, and formal specification languages are commonly used for
documenting requirements.
Review:
 Requirements review involves validating the documented requirements with stakeholders to
ensure accuracy, completeness, and consistency.
 Reviews can be conducted through meetings, presentations, walkthroughs, or formal inspections.
 Feedback from stakeholders is gathered and incorporated into the requirements documentation
as necessary.
Management of User Needs:
 Requirements management involves tracking changes to requirements throughout the software
development lifecycle.
 A version-controlled repository is maintained to store and manage requirements documents.
 Change control procedures are established to assess the impact of proposed changes, obtain
approval from stakeholders, and update relevant documentation.
 Traceability matrices are used to track the relationships between requirements and other
artifacts (e.g., design elements, test cases) to ensure alignment throughout the development
process.

CLASSIFICATION OF REQUIREMENTS –

• Functional Requirements

• Non Functional Requirements

• Domain Requirements

 FUNCTIONAL REQUIREMENTS-

• They focus on the functionality of the software components that build the system.

• Functional requirements are the services which are the end users expect the final
product to provide.

• There are many ways of expressing functional requirements e.g. Natural language
structured or formatted language. With no rigorous syntax, formal specification
language with proper syntax.
 NON FUNCTIONAL REQUIREMENTS (NFRs) –
• These are constraints imposed on the system and deal with issues like maintainability, security,
performance reliability etc.

• Other terms used to specify NFRs are –

• Quality attributes

• Constraints

• Goals

• Non behavioral Requirement

 NFRs can be classified as:

• Interface constraints

• Performance Constraints: response time, security, reliability storage space etc.

• Operating constraints.

• Life cycle Constraints: maintainability, reusability, portability, flexibility etc.

• Economic Constraints.

 DOMAIN REQUIREMENTS-

• These are the requirements that are specific to an application domain e.g. Banking, Hospital
etc.

• These requirements are therefore identified from domain model and are not user specific.
NEED OF SRS –

• A Basic purpose of software requirements specification is to bridge the

communication gap between user & developer.

• To help the clients to understand their own needs as it forces the client and users
to think, visualize, interact & discuss with others.

• An SRS establishes the basis for agreement between the client & the supplier on
what the software product will do this basis for agreement is frequently
formalized into a legal contract between the client and the developer. So
through SRS, the client clearly describes what it expects from the supplier, & the
developer clearly understands what capabilities to build in the software.

• An SRS provides a reference for validation of the final product.

• A high quality SRS is prerequisite to high quality software.

• A high Quality SRS reduces the development Cost. Hence the Quality of the SRS
impacts customer satisfaction, system validation quality of the final Software &
software development cost.

CHARACTERISTICS OF A GOOD SRS-

i. Correctness-
• An SRS is said to be correct if every requirement stated in the document is correct.
• For ensuring Correctness users may be asked to review the document
• Further, it can be compared with some proceedings documents or with applicable standards.

ii. Completeness-
• It is said to be complete if –

• All the significant functional & non-functional requirements to be

satisfied by the software are included in the SRS.

• Response to all valid and invalid class of data is included. It means for every valid and
invalid inputs defined in SRS, appropriate output is also mentioned.

• All figures, tables & pages are numbered. They are also properly named and
referenced.

• Sections in the SRS should avoid the label “to be determined” as far as possible.
 iii. Consistency –
• It is said to be consistent if there is no conflict between the requirements in the documents.

• Different types of conflict may exist between the requirements. Some of them are:

• Conflicts between characteristics of real world entities.

• Temporal or logical Conflicts between two items

• Conflicts can also arise if different terminology is used to describe same

real world object or event.

iv. Unambiguousness-

• Unambiguousness in the SRS document is supported only if each and every

requirement started in it has only one interpretation.

• It can be best achieved by using requirements specification languages,

requirements analysis & modelling techniques & reviewing the document
written in natural language by a third process.

v. Modifiability-

• Requirements keep changing and changes must be reflected properly in the SRS
• An SRS is said to be modifiable if changes can be made to the requirements
easily, completely and consistently while retaining its structure & style.

vi. Verifiability-

• An SRS is said to be verifiable if for each requirement written in SRS, there exists
some cost effective process using which a person or tool can ensure that software
meets the requirements.

vii. Traceability –

• It can be further classified into 2 types:

• Forward Traceability- Which is achieved by assigning a unique name or

number to each requirement.

• Backward Traceability- Which is achieved by each requirement referring explicitly

to its source in previous documents.

viii. Design Independent –

• It is said to be design independent if it does not include any implementation details.

REQUIREMENT PROCESS-

• It is the sequence of activities that need to be performed in the requirements in

the requirements phase and that culminate in producing high quality document
containing the software requirements specification (SRS).

• Requirements Phase consists of 4 basic activities :

• Requirements Elicitation.

• Problem or Requirement Analysis

• Requirement Specification.

• Requirement Validation.

1. REQUIREMENT ELICITATION-

• Requirement elicitation is the process of collecting information from stakeholders. It

serves as a foundation in documenting the requirements for application development.

• Requirements elicitation is one of the most complex, error-prone, communication-

intensive, and challenging stages of the software development process, as it is pivotal in
determining the budget, time estimate, and scope of a project.

There are a number of elicitation techniques to gather requirements or to collect the

information from the stakeholders. Some of the requirement elicitation techniques are as
follows.

a. Interviews:

• Objective of conducting an interview is to understand the customer’s expectations from

the software.

• It is impossible to interview every stakeholder hence representatives from groups are

selected based on their expertise and credibility.

• Interviews may be open-ended or structured.

• In open-ended interviews there is no pre-set agenda. Context free questions may be

asked to understand the problem.

• In structured interview, agenda of fairly open questions is prepared. Sometimes a proper

questionnaire is designed for the interview.

b. Brainstorming Sessions:

• It is a group technique

• It is intended to generate lots of new ideas hence providing a platform to share views

• A highly trained facilitator is required to handle group bias and group conflicts.

• Every idea is documented so that everyone can see it.

• Finally, a document is prepared which consists of the list of requirements and their
priority if possible.
 c. Facilitated Application Specification Technique (FAST):

• It’s objective is to bridge the expectation gap – difference between what the developers
think they are supposed to build and what customers think they are going to get.

• A team oriented approach is developed for requirements gathering.

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

• Part of the environment that surrounds the system

• Produced by the system

• Used by the system

• Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, team is divided into smaller sub-teams to develop mini-
specifications and finally a draft of specifications is written down using all the inputs
from the meeting.

d. Quality Function Deployment:

• In this technique customer satisfaction is of prime concern, hence it emphasizes on the

requirements which are valuable to the customer.

• 3 types of requirements are identified –

Normal requirements –

In this the objective and goals of the proposed software are discussed with the customer.
Example – normal requirements for a result management system may be entry of marks,
calculation of results, etc.

Expected requirements –

These requirements are so obvious that the customer need not explicitly state them. Example –
protection from unauthorized access.

Exciting requirements –

It includes features that are beyond customer’s expectations and prove to be very satisfying
when present. Example – when unauthorized access is detected, it should backup and shutdown
all processes.

The major steps involved in this procedure are –

• Identify all the stakeholders, e.g. Users, developers, customers etc.

• List out all requirements from customer.

• A value indicating degree of importance is assigned to each requirement.

• In the end the final list of requirements is categorized as –

 It is possible to achieve

 It should be deferred and the reason for it

 It is impossible to achieve and should be dropped off

 e. Use Case Approach:

• This technique combines text and pictures to provide a better understanding of the
requirements.

• The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system.

• The components of the use case design include three major things – Actor, Use cases, use
case diagram.

Actor –

 It is the external agent that lies outside the system but interacts with it in some way. An
actor maybe a person, machine etc. It is represented as a stick figure. Actors can be
primary actors or secondary actors.

 Primary actors – It requires assistance from the system to achieve a goal.

 Secondary actor – It is an actor from which the system needs assistance.

Use cases –

 They describe the sequence of interactions between actors and the system. They capture
who (actors) do what (interaction) with the system. A complete set of use cases specifies
all possible ways to use the system.

Use case diagram –

 A use case diagram graphically represents what happens when an actor interacts with a
system. It captures the functional aspect of the system.

 A stick figure is used to represent an actor.

 An oval is used to represent a use case.

 A line is used to represent a relationship between an actor and a use case.

 ADVANTAGES OF REQUIREMENTS ELICITATION:

• Helps to clarify and refine the customer requirements.

• Improves communication and collaboration between stakeholders.

• Increases the chances of developing a software system that meets the customer needs.

• Avoids misunderstandings and helps to manage expectations.

• Supports the identification of potential risks and problems early in the development cycle.

• Facilitates the development of a comprehensive and accurate project plan.

• Increases user and stakeholder confidence in the software development process.

• Supports the identification of new business opportunities and revenue streams.

DISADVANTAGES OF REQUIREMENTS ELICITATION:

• Can be time-consuming and expensive.

• Requires specialized skills and expertise.

• May be impacted by changing business needs and requirements.

• Can be impacted by political and organizational factors.

• Can result in a lack of buy-in and commitment from stakeholders.

• Can be impacted by conflicting priorities and competing interests.

• May result in incomplete or inaccurate requirements if not properly managed.

• Can lead to increased development costs and decreased efficiency if requirements are not
well-defined.

2. REQUIREMENT ANALYSIS-

• It is concerned with understanding of problem domain at the beginning of

the project because requirements are fuzzy and are not clearly understood
by the analyst.
• This process of acquiring information/ knowledge about a specific problem
domain through various techniques to build the requirements model is called
Requirement Elicitation.

• This activity of requirement elicitation helps the analyst to gain knowledge about
the problem domain which in turn is used to produce formal specification of
software to be developed to meet the customer.

ER Model
o ER model stands for an Entity-Relationship model. It is a high-level data model. This
model is used to define the data elements and relationship for a specified system.
o It develops a conceptual design for the database. It also develops a very simple
andeasy to design view of data.
o In ER modeling, the database structure is portrayed as a diagram called an
entity-relationship diagram.
For example, suppose we design a school database. In this database, the student
will be an entity with attributes like address, name, id, age, etc. The address can be
another entity with attributes like city, street name, pin code, etc. and there will be
a relationship between them.

Component of ER Diagram
i. Entity:
• An entity may be any object, class, person or place. In the ER diagram,
an entity can berepresented as rectangles.

• Consider an organization as an example- manager, product, employee,

department etc. can betaken as an entity.

Weak Entity
• An entity that depends on another entity called a weak entity. The weak entity
doesn't containany key attribute of its own. The weak entity is represented by a
double rectangle.

ii. Attribute

• The attribute is used to describe the property of an entity. Eclipse is used to

represent anattribute.

For example, id, age, contact number, name, etc. can be attributes of a student.

a. Key Attribute

The key attribute is used to represent the main characteristics of an entity. It

represents a primary key. The key attribute is represented by an ellipse with
the text underlined.

b. Composite Attribute

An attribute that composed of many other attributes is known as a

composite attribute. The composite attribute is represented by an ellipse,
and those ellipses are connected with an ellipse.

c. Multivalued Attribute

An attribute can have more than one value. These attributes are known as a
multivalued attribute. The double oval is used to represent multivalued
attribute.

For example, a student can have more than one phone number.

d. Derived Attribute

An attribute that can be derived from other attribute is known as a derived

attribute. It can berepresented by a dashed ellipse.

For example, A person's age changes over time and can be derived from
another attributelike Date of birth.
 iii. Relationship
• The association among entities is called a relationship. For example, an
employee works_at a department, a student enrolls in a course. Here,
Works_at and Enrolls are called relationships.
Relationship Set
A set of relationships of similar type is called a relationship set. Like
entities, a relationship too can have attributes. These attributes are called
descriptive attributes.

Degree of Relationship
The number of participating entities in a relationship defines the degree of the
relationship.

 Binary = degree 2
 Ternary = degree 3
 n-ary = degree
ER Model is represented by means of an ER diagram. Any object, for example,
entities, attributes of an entity, relationship sets, and attributes of
relationship sets, can be represented with the help of an ER diagram.
Entity
Entities are represented by means of rectangles. Rectangles are named with the entity set
they represent.

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

If the attributes are composite, they are further divided in a tree like structure. Every node is
then connected to its attribute. That is, composite attributes are represented by ellipses that
are connected with an ellipse.
Multivalued attributes are depicted by double ellipse.

Derived attributes are depicted by dashed ellipse.

Relationship
Relationships are represented by diamond-shaped box. Name of the relationship is written
inside the diamond-box. All the entities (rectangles) participating in a relationship, are
connected to it by a line.
Binary Relationship and Cardinality
A relationship where two entities are participating is called a binary relationship. Cardinality
is the number of instance of an entity from a relation that can be associated with the
relation.
 One-to-one − When only one instance of an entity is associated with the relationship,
it is marked as '1:1'. The following image reflects that only one instance of each entity
should be associated with the relationship. It depicts one-to-one relationship.

 One-to-many − When more than one instance of an entity is associated with a

relationship, it is marked as '1:N'. The following image reflects that only one
instance of entity on the left and more than one instance of an entity on the right can
be associated with the relationship. It depicts one-to-many relationship.

 Many-to-one − When more than one instance of entity is associated with the
 relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.
 Many-to-many − The following image reflects that more than one instance of an
entity on the left and more than one instance of an entity on the right can be
associated with the relationship. It depicts many-to-many relationship.

Participation Constraints
 Total Participation − Each entity is involved in the relationship. Total participation is
represented by double lines.
 Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.

Keys
o Keys play an important role in the relational database.
o It is used to uniquely identify any record or row of data from the table. It is also
usedto establish and identify relationships between tables.

For example: In Student table, ID is used as a key because it is unique for each
student. In PERSON table, passport_number, license_number, SSN are keys since
they are unique for each person

Types of key:
1. Primary key
o It is the first key which is used to identify one and only one instance of an entity
uniquely. An entity can contain multiple keys as we saw in PERSON table. The key
which is most suitable from those lists become a primary key.
o In the EMPLOYEE table, ID can be primary key since it is unique for each employee.In
the EMPLOYEE table, we can even select License_Number and Passport_Number as
primary key since they are also unique.
o For each entity, selection of the primary key is based on requirement and developers.

2. Candidate key
o A candidate key is an attribute or set of an attribute which can uniquely identify
atuple.
o The remaining attributes except for primary key are considered as a candidate
key.The candidate keys are as strong as the primary key.
For example: In the EMPLOYEE table, id is best suited for the primary key. Rest of the
attributes like SSN, Passport_Number, and License_Number, etc. are considered as a
candidate key.
3. Super Key

Super key is a set of an attribute which can uniquely identify a tuple. Super key is a superset
of a candidate key.

For example: In the above EMPLOYEE table, for(EMPLOEE_ID, EMPLOYEE_NAME) the

name of two employees can be the same, but their EMPLYEE_ID can't be the same.
Hence, this combination can also be a key.

The super key would be EMPLOYEE-ID, (EMPLOYEE_ID, EMPLOYEE-NAME), etc.

4. Foreign key
o Foreign keys are the column of the table which is used to point to the primary key
ofanother table.
o In a company, every employee works in a specific department, and employee
and department are two different entities. So we can't store the information of
the department in the employee table. That's why we link these two tables
through theprimary key of one table.
o We add the primary key of the DEPARTMENT table, Department_Id as a new
attribute in the EMPLOYEE table.
o Now in the EMPLOYEE table, Department_Id is the foreign key, and both the tables
are related.

Reduction of ER diagram to Table

The database can be represented using the notations, and these notations can be reduced
to acollection of tables.

In the database, every entity set or relationship set can be represented in tabular form.

The ER diagram is given below:

There are some points for converting the ER diagram to the table:

o Entity type becomes a table.

In the given ER diagram, LECTURE, STUDENT, SUBJECT and COURSE forms individual tables.
 o All single-valued attribute becomes a column for the table.

In the STUDENT entity, STUDENT_NAME and STUDENT_ID form the column of

STUDENT table. Similarly, COURSE_NAME and COURSE_ID form the column of
COURSE table and so on.

o A key attribute of the entity type represented by the primary key.

In the given ER diagram, COURSE_ID, STUDENT_ID, SUBJECT_ID, and LECTURE_IDare the key
attribute of the entity.

o The multivalued attribute is represented by a separate table.

In the student table, a hobby is a multivalued attribute. So it is not possible to represent

multiple values in a single column of STUDENT table. Hence we create a table STUD_HOBBY
with column name STUDENT_ID and HOBBY. Using both the column, we create a composite
key.

o Composite attribute represented by components.

In the given ER diagram, student address is a composite attribute. It contains CITY, PIN,
DOOR#, STREET, and STATE. In the STUDENT table, these attributes can merge as an
individual column.

o Derived attributes are not considered in the table.

In the STUDENT table, Age is the derived attribute. It can be calculated at any point of time
by calculating the difference between current date and Date of Birth.

Using these rules, you can convert the ER diagram to tables and columns and assign the
mapping between the tables. Table structure for the given ER diagram is as below:
More techniques for data Analysis

a. Data Dictionary
A data dictionary is a structured repository of data elements in the system. It stores the
descriptions of all DFD data elements that is, details and definitions of data flows, data stores,
data stored in data stores, and the processes.

A data dictionary improves the communication between the analyst and the user. It plays an
important role in building a database. Most DBMSs have a data dictionary as a standard feature.
For example, refer the following table −

b. Decision Trees
Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.

Decision trees depict the relationship of each condition and their permissible actions. A square
node indicates an action and a circle indicates a condition. It forces analysts to consider the
sequence of decisions and identifies the actual decision that must be made.

c. Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise manner which is
easily understandable.
It is useful in situations where the resulting actions depend on the occurrence of one or several
combinations of independent conditions.
It is a matrix containing row or columns for defining a problem and the actions.
Components of a Decision Table
Condition Stub − It is in the upper left quadrant which lists all the condition to be checked.
Action Stub − It is in the lower left quadrant which outlines all the action to be carried out to meet such
condition.
Condition Entry − It is in upper right quadrant which provides answers to questions asked in condition
stub quadrant.
Action Entry − It is in lower right quadrant which indicates the appropriate action resulting from the
answers to the conditions in the condition entry quadrant.

3. REQUIREMENT SPECIFICATION –

• The purpose is to produce formal software requirements model.

• These models specify the functional and non-functional properties of the

system along with the constraints imposed on the system.
Table of Contents

1. Introduction:
1.1 Purpose: Explains the intention or goal of the document.
1.2 Scope: Defines what the software system will and will not do.
1.3 Definitions, acronyms, and abbreviations: Provides a list of specialized terms
used throughout the document.
1.4 References: Lists any sources or documents referred to in the SRS.
1.5 Overview: Gives a brief overview of what the document will cover.

2. Overall description:
2.1 Product perspective: Describes how the software system relates to other systems
or components.
2.2 Product functions: Lists the functions the software system will perform.
2.3 User characteristics: Describes the types of users who will interact with the
system.
2.4 Constraints: Outlines any limitations or restrictions affecting the development or
use of the system.
2.5 Assumptions and dependencies: States any assumptions made during the
development process and dependencies on external factors.
 3. Specific Requirements:
3.1 Functional requirements: Details the specific functions or features the software
system must provide.
3.2 Non-functional requirements: Describes quality attributes such as performance,
usability, reliability, etc.
3.3 External interface requirements: Specifies how the system will interact with
external entities, such as users or other systems.
3.4 Performance requirements: Defines the performance criteria the system must
meet.
3.5 Database constraints: Describes constraints related to the database used by the
system.
3.6 Design constraints: Specifies any constraints on the design of the system.

4. Change Management Process:

Outlines the process for managing changes to the requirements or the software
itself.

5. Appendices:
Contains additional information or documents that support the content of the SRS.

6. Other supporting Documents/Information:

Refers to any additional documents or information that may be relevant to the
project but are not included in the main body of the SRS.

4. REQUIREMENT VALIDATION –

• It is defined as process to ensure the consistency of requirements model with

respect to customers' needs.

• The validation is done not only for the final model but also for all intermediate models
generated.

• If requirements are not validated, errors in the requirements definition would propagate to
the successive stages resulting into lot of modification & rework.

• Following steps should be followed while validating requirements

• Ensure that requirements are consistent. They are not conflicting with other
requirements.

• Ensure that requirements are complete in all respect. Ensure that requirements are
realistic and realizable.

 Requirements Validation Techniques

• Requirements reviews/inspections: systematic manual analysis of the requirements.

• Prototyping: Using an executable model of the system to check requirements.
• Test-case generation: Developing tests for requirements to check testability.
• Automated consistency analysis: checking for the consistency of structured
requirements descriptions.
  SOFTWARE REQUIREMENT MANAGEMENT:

• Requirement management is the process of managing changing requirements during the

requirements engineering process and system development.

• New requirements emerge during the process as business needs a change, and a better
understanding of the system is developed.

• The priority of requirements from different viewpoints changes during development process.

• The business and technical environment of the system changes during the development.

QUALITY ASSURANCE (QA)

Quality
Quality is extremely hard to define, and it is simply stated: “Fit for use or purpose.” It is all about meeting
the needs and expectations of customers with respect to functionality, design, reliability, durability, &
price of the product.

Assurance
Assurance is nothing but a positive declaration on a product or service, which gives confidence. It is
certainty of a product or a service, which it will work well. It provides a guarantee that the product will
work without any problems as per the expectations or requirements.

Software Quality Assurance (SQA)

SQA is simply a way to assure quality in the software. It is the set of activities which ensure processes,
procedures as well as standards are suitable for the project and implemented correctly.

Software Quality Assurance is a process which works parallel to development of software. It focuses on
improving the process of development of software so that problems can be prevented before they
become a major issue. Software Quality Assurance is a kind of Umbrella activity that is applied throughout
the software process.

Complete Process of Quality Assurance

Quality Assurance methodology has a defined cycle called PDCA cycle or Deming cycle. The phases of this
cycle are:
• Plan
• Do
• Check
• Act

Quality Assurance Process

These above steps are repeated to ensure that processes followed in the organization are evaluated and
improved on a periodic basis. Let’s look into the above QA Process steps in detail –
 • Plan – Organization should plan and establish the process related objectives and determine the
processes that are required to deliver a high-Quality end product.
• Do – Development and testing of Processes and also “do” changes in the processes
• Check – Monitoring of processes, modify the processes, and check whether it meets the
predetermined objectives
• Act – A Quality Assurance tester should implement actions that are necessary to achieve
improvements in the processes

An organization must use Quality Assurance to ensure that the product is designed and implemented with
correct procedures. This helps reduce problems and errors, in the final product.

Quality Control

Quality control popularly abbreviated as QC. It is a Software Engineering process used to ensure quality in
a product or a service. It does not deal with the processes used to create a product; rather it examines the
quality of the “end products” and the final outcome.

The main aim of Quality control is to check whether the products meet the specifications and
requirements of the customer. If an issue or problem is identified, it needs to be fixed before delivery to
the customer.

QC also evaluates people on their quality level skill sets and imparts training and certifications. This
evaluation is required for the service based organization and helps provide “perfect” service to the
customers.

Difference between Quality Control and Quality Assurance

Sometimes, QC is confused with the QA. Quality control is to examine the product or service and check for
the result. Quality Assurance in Software Engineering is to examine the processes and make changes to
the processes which led to the end-product.

Quality Control Vs Quality Assurance

Examples of QC and QA activities are as follows:

Quality Control Activities Quality Assurance Activities
Walkthrough Quality Audit
Testing Defining Process
Inspection Tool Identification and selection
Checkpoint review Training of Quality Standards and Processes
The above activities are concerned with Quality Assurance and Control mechanisms for any product
and not essentially software. With respect to software

QA becomes SQA (Software Quality Assurance)

QC becomes Software Testing.

Differences between SQA and Software Testing

SQA Software Testing

Software Quality Assurance is about engineering
process that ensures quality
Involves activities related to the implementation of
processes, procedures, and standards. Example –
Audits Training
Process focused
Preventive technique
Proactive measure
The scope of SQA applied to all products that will
be created by the organization
Software Testing is to test a product for problems
before the product goes live
Involves actives concerning verification of product
Example – Review Testing
Product focused
Corrective technique
Reactive measure
The scope of Software Testing applies to a
particular product being tested.

Best practices for Quality Assurance:

• Create a Robust Testing Environment
• Select release criteria carefully
• Apply automated testing to high-risk areas to save money. It helps to fasten the entire process.
• Allocate Time Appropriately for each process
• It is important to prioritize bugs fixes based on software usage
• Form dedicated security and performance testing team
• Simulate customer accounts similar to a production environment

Quality Assurance Functions:

There are 5 primary Quality Assurance Functions:

• Technology transfer: This function involves getting a product design document as well as trial and
error data and its evaluation. The documents are distributed, checked and approved
• Validation: Here validation master plan for the entire system is prepared. Approval of test criteria for
validating product and process is set. Resource planning for execution of a validation plan is done.
• Documentation: This function controls the distribution and archiving of documents. Any change in a
document is made by adopting the proper change control procedure. Approval of all types of
documents.
• Assuring Quality of products
• Quality improvement plans
QUALITY ASSURANCE CERTIFICATIONS:
There are several certifications available in the industry to ensure that Organizations follow Standards
Quality Processes. Customers make this as qualifying criteria while selecting a software vendor.

ISO 9000
This standard was first established in 1987, and it is related to Quality Management Systems. This helps
the organization ensure quality to their customers and other stakeholders. An organization who wishes to
be certified as ISO 9000 is audited based on their functions, products, services and their processes. The
main objective is to review and verify whether the organization is following the process as expected and
check whether existing processes need improvement.

This certification helps –

• Increase the profit of the organization

• Improves Domestic and International trade
• Reduces waste and increase the productivity of the employees
• Provide Excellent customer satisfaction

The ISO 9000 series of standards is based on the assumption that if a proper stage is followed for
production, then good quality products are bound to follow automatically. The types of industries to
which the various ISO standards apply are as follows.

• ISO 9001: This standard applies to the organizations engaged in design, development, production,
and servicing of goods. This is the standard that applies to most software development
organizations.
• ISO 9002: This standard applies to those organizations which do not design products but are only
involved in the production. Examples of these category industries contain steel and car
manufacturing industries that buy the product and plants designs from external sources and are
engaged in only manufacturing those products. Therefore, ISO 9002 does not apply to software
development organizations.
• ISO 9003: This standard applies to organizations that are involved only in the installation and
testing of the products. For example, Gas companies.

There are various quality management principles included in ISO 9000:

i. Customer focus. Businesses must understand customer requirements and aim to exceed
customer expectations. Organizations should measure customer satisfaction with their product or
service as well.
ii. Leadership. Organizational leaders should establish a vision for the direction of the company and
empower employees to reach that goal. Leaders should establish trusted relationships with
employees and recognize their contributions.
iii. Engagement. Employees at every level should be involved.
iv. Process. Organizations should manage resources as a process. They should use process analysis
tools to measure what the organization is capable of, identify links between activities to
streamline processes and look for ways to improve processes.
v. Continuous improvement. Companies should take a continual improvement approach and
empower people to make improvements, measure improvement consistently and celebrate those
improvements.
vi. Evidence-based decision-making. Organizations should make decisions based on sound data
analysis, balanced with practical experience and qualitative evidence.
vii. Relationship management. Organizations should focus on fostering a mutually beneficial
relationship with partner organizations, including suppliers, service providers and contractors.
They should share resources, collaborate on development efforts and recognize successes to
achieve efficient supply chain management.
CMM level
The Capability Maturity Model (CMM) is a process improvement approach developed specially for
software process improvement. It is based on the process maturity framework and used as a general aid
in business processes in the Software Industry. This model is highly regarded and widely used in Software
Development Organizations.

CMM has 5 levels. An organization is certified at CMM level 1 to 5 based on the maturity of their Quality
Assurance Mechanisms.

Level 1 – Initial: In this stage the quality environment is unstable. Simply, no processes have been
followed or documented. The software process is characterized as inconsistent, and occasionally even
chaotic. Defined processes and standard practices that exist are abandoned during a crisis. Success of
the organization majorly depends on an individual effort, talent, and heroics. The heroes eventually
move on to other organizations taking their wealth of knowledge or lessons learnt with them.

Level 2 – Repeatable: Some processes are followed which are repeatable. This level ensures
processes are followed at the project level. 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 3 – Defined: Set of processes are defined and documented at the organizational level. Those
defined processes are subject to some degree of improvement. 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 4 – Managed: This level uses process metrics and effectively controls the processes that are
followed. 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 5 – Optimizing: This level focuses on the continuous improvements of the processes through
learning & innovation. 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.

Comparison of ISO-9000 Certification & SEI-CMM

Sr. No. Key ISO 9000 SEI-CMM.

ISO9000 is an international standard of SEI-CMM is specifically for

quality management and quality assurance. software organizations to
It certifies the companies that they are certify them at which level,
1 Definition
documenting the quality system elements they are following and
which are needed to run an efficient and maintaining the quality
quality system. standards.

Focus of ISO9000 is on customer supplier Focus of SEI-CMM is to

relationship, and to reduce the customer's improve the processes to
2 Focus
risk. deliver a quality software
product to the customer.
Sr. No. Key ISO 9000 SEI-CMM.

Target ISO9000 is used by manufacturing SEI-CMM is used by software

3
Industry industries. industry.

ISO9000 guides about concepts, principles SEI-CMM specifies what is to

4 Guidelines and safeguards to be in place in a be followed at what level of
workplace. maturity.

ISO9000 has one acceptance level. SEI-CMM has five acceptance

5 Levels
levels.

ISO9000 focuses on following a set of SEI-CMM focuses on improving

6 Outcome standards so that firms’ deliveries are the processes.
successful every time.