Unit II

II 1. Software Requirement Specifications (SRS): 08

2. Requirement Engineering Process:
3. Elicitation,
4. Analysis,
5. Documentation,
6. Review and Management of User Needs
7. Feasibility Study, Information Modelling,
8. Data Flow Diagrams,
9. Entity Relationship Diagrams,
10. Decision Tables,
11. SRS Document,
12. IEEE Standards for SRS.
13. Software Quality Assurance (SQA):
14. Verification and Validation,
15. SQA Plans,
16. Software Quality Frameworks,
17. ISO 9000 Models,
18. SEI-CMM Model.

SRS Document
Software Requirement Specification (SRS) Format as the name suggests, is a complete specification
and description of requirements of the software that need to be fulfilled for the successful development
of the software system. These requirements can be functional as well as non-functional depending upon
the type of requirement. The interaction between different customers and contractors is done because it

is necessary to fully unders tand the needs of customers.

Depending upon information gathered after interaction, SRS is developed which describes requirements
of software that may include changes and modifications that is needed to be done to increase quality of
product and to satisfy customer’s demand.
Introduction
 Purpose of this Document – At first, main aim of why this document is necessary and what’s
purpose of document is explained and described.
 Scope of this document – In this, overall working and main objective of document and what value
it will provide to customer is described and explained. It also includes a description of development
cost and time required.
 Overview – In this, description of product is explained. It’s simply summary or overall review of
product.
 General description
In this, general functions of product which includes objective of user, a user characteristic, features,
benefits, about why its importance is mentioned. It also describes features of user community.
Functional Requirements
In this, possible outcome of software system which includes effects due to operation of program is fully
explained. All functional requirements which may include calculations, data processing, etc. are placed
in a ranked order. Functional requirements specify the expected behavior of the system-which outputs
should be produced from the given inputs. They describe the relationship between the input and output
of the system. For each functional requirement, detailed description all the data inputs and their source,
the units of measure, and the range of valid inputs must be specified.
Interface Requirements
In this, software interfaces which mean how software program communicates with each other or users
either in form of any language, code, or message are fully described and explained. Examples can be
shared memory, data streams, etc.
Performance Requirements
In this, how a software system performs desired functions under specific condition is explained. It also
explains required time, required memory, maximum error rate, etc. The performance requirements part
of an SRS specifies the performance constraints on the software system. All the requirements relating
to the performance characteristics of the system must be clearly specified. There are two types of
performance requirements: static and dynamic. Static requirements are those that do not impose
constraint on the execution characteristics of the system. Dynamic requirements specify constraints on
the execution behaviour of the system.
Design Constraints
In this, constraints which simply means limitation or restriction are specified and explained for design
team. Examples may include use of a particular algorithm, hardware and software limitations, etc.
There are a number of factors in the client’s environment that may restrict the choices of a designer
leading to design constraints such factors include standards that must be followed resource limits,
operating environment, reliability and security requirements and policies that may have an impact on
the design of the system. An SRS should identify and specify all such constraints.
Non-Functional Attributes
In this, non-functional attributes are explained that are required by software system for better
performance. An example may include Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.
Preliminary Schedule and Budget
In this, initial version and budget of project plan are explained which include overall time duration
required and overall cost required for development of project.
Appendices
In this, additional information like references from where information is gathered, definitions of some
specific terms, acronyms, abbreviations, etc. are given and explained.
Uses of SRS document
 Development team require it for developing product according to the need.
 Test plans are generated by testing group based on the describe external behaviour.
 Maintenance and support staff need it to understand what the software product is supposed to do.
 Project manager base their plans and estimates of schedule, effort and resources on it.
 customer rely on it to know that product they can expect.
 As a contract between developer and customer.
 in documentation purpose.
Parts of a SRS document – Software Engineering





The important parts of the Software Requirements Specification (SRS) document are:
1. Functional requirements of the system
2. Non-functional requirements of the system, and
3. Goals of implementation
These are explained as follows.
Functional Requirements
The purposeful requirements part discusses the functionalities needed from the system.
1. The system is taken into account to perform a group of high-level functions Fi. The functional view
of the system is shown in the below diagram
2. Each function Fi of the system can be considered as a transformation of a set of input data Ii to the
corresponding set of output knowledge Oi.
The user will get some purposeful piece of labor done employing a high-level operation.

Non-functional Requirements
Non-functional necessities accommodate the characteristics of the system which may not be expressed as
functions – like the maintainability of the system, mobility of the system, the usability of the system, etc.
Non-functional requirements may include:
1. Reliability issues
2. Accuracy of results
3. Human-computer interface issues
4. Constraints on the system implementation, etc.
Goals of Implementation
The goals of implementation part documents some general suggestions relating to development. These
suggestions guide trade-off among style goals.
1. The goals of the implementation section would possibly document problems like revisions to the
system functionalities that will be needed within the future, new devices to be supported within the
future, reusability problems, etc.
2. These are the things that the developers would possibly detain their mind throughout development in
order that the developed system may meet some aspects that don’t seem to be needed straightaway.
What is Requirement Engineering?
Requirements engineering is a broad domain that focuses on being the connector between modeling,
analysis, design, and construction. It is the process that defines, identifies, manages, and develops
requirements in a software engineering design process. This process uses tools, methods, and principles
to describe the system’s behavior and the constraints that come along with it.
Requirements engineering is the most important part every business must follow, in order to build and
release a project successfully, as it is the foundation to key planning and implementation.

Requirement Engineering Process

Following are the Requirement Engineering Process
1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management

Requirements Engineering Process

Requirements Engineering Tasks

The software requirements engineering process includes the following steps of activities:
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management
Let’s discuss each of these steps in detail.
1. Inception
This is the first phase of the requirements analysis process. This phase gives an outline of how to get
started on a project. In the inception phase, all the basic questions are asked on how to go about a task
or the steps required to accomplish a task. A basic understanding of the problem is gained and the
nature of the solution is addressed. Effective communication is very important in this stage, as this
phase is the foundation as to what has to be done further. Overall in the inception phase, the following
criteria have to be addressed by the software engineers:
 Understanding of the problem.
 The people who want a solution.
 Nature of the solution.
 Communication and collaboration between the customer and developer.

2. Elicitation
This is the second phase of the requirements analysis process. This phase focuses on gathering the
requirements from the stakeholders. One should be careful in this phase, as the requirements are what
establishes the key purpose of a project. Understanding the kind of requirements needed from the
customer is very crucial for a developer. In this process, mistakes can happen in regard to, not
implementing the right requirements or forgetting a part. The right people must be involved in this
phase. The following problems can occur in the elicitation phase:
 Problem of Scope: The requirements given are of unnecessary detail, ill-defined, or not possible to
implement.
 Problem of Understanding: Not having a clear-cut understanding between the developer and
customer when putting out the requirements needed. Sometimes the customer might not know what
they want or the developer might misunderstand one requirement for another.
 Problem of Volatility: Requirements changing over time can cause difficulty in leading a project.
It can lead to loss and wastage of resources and time.

3. Elaboration
This is the third phase of the requirements analysis process. This phase is the result of the inception and
elicitation phase. In the elaboration process, it takes the requirements that have been stated and
gathered in the first two phases and refines them. Expansion and looking into it further are done as
well. The main task in this phase is to indulge in modeling activities and develop a prototype that
elaborates on the features and constraints using the necessary tools and functions.

4. Negotiation
This is the fourth phase of the requirements analysis process. This phase emphasizes discussion and
exchanging conversation on what is needed and what is to be eliminated. In the negotiation phase,
negotiation is between the developer and the customer and they dwell on how to go about the project
with limited business resources. Customers are asked to prioritize the requirements and make
guesstimates on the conflicts that may arise along with it. Risks of all the requirements are taken into
consideration and negotiated in a way where the customer and developer are both satisfied with
reference to the further implementation. The following are discussed in the negotiation phase:
 Availability of Resources.
 Delivery Time.
 Scope of requirements.
 Project Cost.
 Estimations on development.
5. Specification
This is the fifth phase of the requirements analysis process. This phase specifies the following:
 Written document.
 A set of models.
 A collection of use cases.
 A prototype.
In the specification phase, the requirements engineer gathers all the requirements and develops a
working model. This final working product will be the basis of any functions, features or constraints to
be observed. The models used in this phase include ER (Entity Relationship) diagrams, DFD (Data
Flow Diagram), FDD (Function Decomposition Diagrams), and Data Dictionaries.
A software specification document is submitted to the customer in a language that he/she will
understand, to give a glimpse of the working model.

6. Validation
This is the sixth phase of the requirements analysis process. This phase focuses on checking for errors
and debugging. In the validation phase, the developer scans the specification document and checks for
the following:
 All the requirements have been stated and met correctly
 Errors have been debugged and corrected.
 Work product is built according to the standards.
This requirements validation mechanism is known as the formal technical review. The review team that
works together and validates the requirements include software engineers, customers, users, and other
stakeholders. Everyone in this team takes part in checking the specification by examining for any
errors, missing information, or anything that has to be added or checking for any unrealistic and
problematic errors. Some of the validation techniques are the following-
 Requirements reviews/inspections.
 Prototyping.
 Test-case generation.
 Automated consistency analysis.

7. Requirements Management
This is the last phase of the requirements analysis process. Requirements management is a set of
activities where the entire team takes part in identifying, controlling, tracking, and establishing the
requirements for the successful and smooth implementation of the project.
In this phase, the team is responsible for managing any changes that may occur during the project. New
requirements emerge, and it is in this phase, responsibility should be taken to manage and prioritize as
to where its position is in the project and how this new change will affect the overall system, and how
to address and deal with the change. Based on this phase, the working model will be analyzed carefully
and ready to be delivered to the customer.
Conclusion
Requirements engineering tasks is crucial for successful software projects. It involves gathering,
refining, and documenting requirements, ensuring clarity and feasibility. To ensure feasibility and
clarity, requirements must be gathered, refined, and documented. This procedure makes sure that the
project goals align with those of the stakeholders. Effective requirements engineering reduces risks and
guides smooth project execution.
8. What is Data Flow Diagram (DFD)?
DFD is the abbreviation for Data Flow Diagram. The flow of data in a system or process is
represented by a Data Flow Diagram (DFD). It also gives insight into the inputs and outputs of each
entity and the process itself. Data Flow Diagram (DFD) does not have a control flow and no loops or
decision rules are present. Specific operations, depending on the type of data, can be explained by a
flowchart. It is a graphical tool, useful for communicating with users, managers and other personnel. it
is useful for analyzing existing as well as proposed systems.
It should be pointed out that a DFD is not a flowchart. In drawing the DFD, the designer has to specify
the major transforms in the path of the data flowing from the input to the output. DFDs can be
hierarchically organized, which helps in progressively partitioning and analyzing large systems.
It provides an overview of
 What data is system processes.
 What transformation are performed.
 What data are stored.
 What results are produced , etc.
Data Flow Diagram can be represented in several ways. The Data Flow Diagram (DFD) belongs to
structured-analysis modeling tools. Data Flow diagrams are very popular because they help us to
visualize the major steps and data involved in software-system processes.
Characteristics of Data Flow Diagram (DFD)
Below are some characteristics of Data Flow Diagram (DFD):
 Graphical Representation: Data Flow Diagram (DFD) use different symbols and notation to
represent data flow within system. That simplify the complex model.
 Problem Analysis: Data Flow Diagram (DFDs) are very useful in understanding a system and can
be effectively used during analysis. Data Flow Diagram (DFDs) are quite general and are not
limited to problem analysis for software requirements specification.
 Abstraction: Data Flow Diagram (DFD) provides a abstraction to complex model i.e. DFD hides
unnecessary implementation details and show only the flow of data and processes within
information system.
 Hierarchy: Data Flow Diagram (DFD) provides a hierarchy of a system. High- level diagram i.e.
0-level diagram provides an overview of entire system while lower-level diagram like 1-level DFD
and beyond provides a detailed data flow of individual process.
 Data Flow: The primary objective of Data Flow Diagram (DFD) is to visualize the data flow
between external entity, processes and data store. Data Flow is represented by an arrow Symbol.
 Ease of Understanding: Data Flow Diagram (DFD) can be easily understand by both technical and
non-technical stakeholders.
 Modularity: Modularity can be achieved using Data Flow Diagram (DFD) as it breaks the complex
system into smaller module or processes. This provides easily analysis and design of a system.
Types of Data Flow Diagram (DFD)
There are two types of Data Flow Diagram (DFD)
1. Logical Data Flow Diagram
2. Physical Data Flow Diagram
Logical Data Flow Diagram (DFD)
Logical data flow diagram mainly focuses on the system process. It illustrates how data flows in the
system. Logical Data Flow Diagram (DFD) mainly focuses on high level processes and data flow
without diving deep into technical implementation details. Logical DFD is used in various
organizations for the smooth running of system. Like in a Banking software system, it is used to
describe how data is moved from one entity to another.
Logical Data Flow Diagram of Online Grocery Store

Physical Data Flow Diagram

Physical data flow diagram shows how the data flow is actually implemented in the system. In the
Physical Data Flow Diagram (DFD), we include additional details such as data storage, data
transmission, and specific technology or system components. Physical DFD is more specific and close
to implementation.

Physical Data Flow Diagram of online Grocery Store

Components of Data Flow Diagrams (DFD)
The Data Flow Diagram has 4 components:
 Process: Input to output transformation in a system takes place because of process function. The
symbols of a process are rectangular with rounded corners, oval, rectangle or a circle. The process
is named a short sentence, in one word or a phrase to express its essence
 Data Flow: Data flow describes the information transferring between different parts of the systems.
The arrow symbol is the symbol of data flow. A relatable name should be given to the flow to
determine the information which is being moved. Data flow also represents material along with
information that is being moved. Material shifts are modeled in systems that are not merely
informative. A given flow should only transfer a single type of information. The direction of flow is
represented by the arrow which can also be bi-directional.
 Warehouse (Data Store) : The data is stored in the warehouse for later use. Two horizontal lines
represent the symbol of the store. The warehouse is simply not restricted to being a data file rather
it can be anything like a folder with documents, an optical disc, a filing cabinet. The data
warehouse can be viewed independent of its implementation. When the data flow from the
warehouse it is considered as data reading and when data flows to the warehouse it is called data
entry or data updating.
 Terminator (External Entity): The Terminator is an external entity that stands outside of the
system and communicates with the system. It can be, for example, organizations like banks, groups
of people like customers or different departments of the same organization, which is not a part of
the model system and is an external entity. Modeled systems also communicate with terminator.

Basic Structure of Data Flow Diagram (DFD)

What symbols and notations are used to represent Components of DFD?

In Data-Flow Diagrams (DFDs), symbols and notations vary depending on the methodology being
used. Here’s a summary of symbols and notations commonly associated with each methodology:
The different methodologies or approaches used for creating Data-Flow Diagrams (DFDs) are:
 Gane and Sarson
 Yourdon and De Marco
 SSADM
 UML
Each methodology provides its own set of guidelines, symbols, and notations for representing system
components and their interactions.

Data Flow Diagram Methods and Symbol

Levels of Data Flow Diagram (DFD)

Data Flow Diagram (DFD) uses hierarchy to maintain transparency thus multilevel Data Flow Diagram
(DFD’s) can be created. Levels of Data Flow Diagram (DFD) are as follows:
0-level DFD
It is also known as a context diagram. It’s designed to be an abstraction view, showing the system as a
single process with its relationship to external entities. It represents the entire system as a single bubble
with input and output data indicated by incoming/outgoing arrows.
Level 0 of Railway Reservation System

1-Level DFD
This level provides a more detailed view of the system by breaking down the major processes identified
in the level 0 DFD into sub-processes. Each sub-process is depicted as a separate process on the level 1
DFD. The data flows and data stores associated with each sub-process are also shown. In 1-level DFD,
the context diagram is decomposed into multiple bubbles/processes. In this level, we highlight the main
functions of the system and breakdown the high-level process of 0-level DFD into subprocesses.
Level 1 DFD of Railway Reservation System

2-level DFD
This level provides an even more detailed view of the system by breaking down the sub-processes
identified in the level 1 DFD into further sub-processes. Each sub-process is depicted as a separate
process on the level 2 DFD. The data flows and data stores associated with each sub-process are also
shown.
Rules for Data Flow Diagram (DFD)
Following are the rules of DFD:
 Data can flow from:
o Terminator or External Entity to Process
o Process to Terminator or External Entity
o Process to Data Store
o Data Store to Process
o Process to Process
 Data Cannot Flow From
o Terminator or External Entity to Terminator or External Entity
o Terminator or External Entity to Data Store
 o Data Store to Terminator or External Entity
o Data Store to Data Store
Advantages of Data Flow Diagram (DFD)
 It helps us to understand the functioning and the limits of a system.
 It is a graphical representation which is very easy to understand as it helps visualize contents.
 Data Flow Diagram represent detailed and well explained diagram of system components.
 It is used as the part of system documentation file.
 Data Flow Diagrams can be understood by both technical or nontechnical person because they are
very easy to understand.
Disadvantages of Data Flow Diagram (DFD)
 At times Data Flow Diagram (DFD) can confuse the programmers regarding the system.
 Data Flow Diagram takes long time to be generated, and many times due to this reasons analysts
are denied permission to work on it.
How to Draw Data Flow Diagram?
Following are the steps to Draw Data Flow Diagram
 Understand the System
 Identify External Entities
 Identify Processes
 Identify Data Stores
 Use Standard Symbols
 Create Level 0 Diagram
 Based on Complexity Draw Further Level Diagram like Level 1, 2 and so on.
 Identify Data Flows:
 Number Processes and Data Stores
 Review and Validate
Conclusion
Data Flow Diagram ( DFD) are visual maps that provides a clear understanding of how information
moves within a information system. Data Flow Diagrams (DFD) consist of four component i.e.
Processes that represent system’s functionality, External Entities that represent the end users, data store
that represent database or data ware house and data flow that represent how data are flow among these
three components. DFD help everyone, from computer experts to regular users, as it provide a clear
understanding of how a system works and how different parts of it interact. By using DFDs, people can
work together effectively to analyze, design, and communicate about systems.
The Entity Relationship Model is a model for identifying entities (like student, car or company) to be
represented in the database and representation of how those entities are related. The ER data model
specifies enterprise schema that represents the overall logical structure of a database graphically.

Why Use ER Diagrams In DBMS?

 ER diagrams represent the E-R model in a database, making them easy to convert into relations
(tables).
 ER diagrams provide the purpose of real-world modeling of objects which makes them intently
useful.
 ER diagrams require no technical knowledge of the underlying DBMS used.
 It gives a standard solution for visualizing the data logically.
Symbols Used in ER Model
ER Model is used to model the logical view of the system from a data perspective which consists of
these symbols:
Aiming for a top All India Rank in the GATE CS/IT or GATE DA 2026 exam but unsure about your
preparation level?
We've got you covered! Our GATE Courses for CSE & DA at GeeksforGeeks are designed to give you
the competitive edge you need. Get live classes from GATE experts (Khaleel Sir, Chandan Jha Sir,
Vijay Agarwal Sir, and many others), practice problems, doubt-support, previous year questions,
quizzes, all India mock tests, and much more - all in one place.
 Rectangles: Rectangles represent Entities in the ER Model.
 Ellipses: Ellipses represent Attributes in the ER Model.
 Diamond: Diamonds represent Relationships among Entities.
 Lines: Lines represent attributes to entities and entity sets with other relationship types.
 Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
 Double Rectangle: Double Rectangle represents a Weak Entity.

Symbols used in ER Diagram

Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.
Components of ER Diagram

What is Entity?
An Entity may be an object with a physical existence – a particular person, car, house, or employee – or
it may be an object with a conceptual existence – a company, a job, or a university course.
What is Entity Set?
An Entity is an object of Entity Type and a set of all entities is called an entity set. For Example, E1 is
an entity having Entity Type Student and the set of all students is called Entity Set. In ER diagram,
Entity Type is represented as:
Entity Set

We can represent the entity set in ER Diagram but can’t represent entity in ER Diagram because entity
is row and column in the relation and ER Diagram is graphical representation of data.
Types of Entity
There are two types of entity:
1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on other
Entity in the Schema. It has a primary key, that helps in identifying it uniquely, and it is represented by
a rectangle. These are called Strong Entity Types.
2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some entity
type exists for which key attributes can’t be defined. These are called Weak Entity types .
For Example, A company may store the information of dependents (Parents, Children, Spouse) of an
Employee. But the dependents can’t exist without the employee. So Dependent will be a Weak Entity
Type and Employee will be Identifying Entity type for Dependent, which means it is Strong Entity
Type .
A weak entity type is represented by a Double Rectangle. The participation of weak entity types is
always total. The relationship between the weak entity type and its identifying strong entity type is
called identifying relationship and it is represented by a double diamond.
Strong Entity and Weak Entity

What is Attributes?
Attributes are the properties that define the entity type. For example, Roll_No, Name, DOB, Age,
Address, and Mobile_No are the attributes that define entity type Student. In ER diagram, the attribute
is represented by an oval.

Attribute

Types of Attributes
1. Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the key attribute. For
example, Roll_No will be unique for each student. In ER diagram, the key attribute is represented by an
oval with underlying lines.

Key Attribute

2. Composite Attribute
An attribute composed of many other attributes is called a composite attribute. For example, the
Address attribute of the student Entity type consists of Street, City, State, and Country. In ER diagram,
the composite attribute is represented by an oval comprising of ovals.
Composite Attribute

3. Multivalued Attribute
An attribute consisting of more than one value for a given entity. For example, Phone_No (can be more
than one for a given student). In ER diagram, a multivalued attribute is represented by a double oval.

Multivalued Attribute

4. Derived Attribute
An attribute that can be derived from other attributes of the entity type is known as a derived attribute.
e.g.; Age (can be derived from DOB). In ER diagram, the derived attribute is represented by a dashed
oval.

Derived Attribute

The Complete Entity Type Student with its Attributes can be represented as:
Entity and Attributes

Relationship Type and Relationship Set

A Relationship Type represents the association between entity types. For example, ‘Enrolled in’ is a
relationship type that exists between entity type Student and Course. In ER diagram, the relationship
type is represented by a diamond and connecting the entities with lines.

Entity-Relationship Set

A set of relationships of the same type is known as a relationship set. The following relationship set
depicts S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in C3.
Relationship Set

Degree of a Relationship Set

The number of different entity sets participating in a relationship set is called the degree of a
relationship set.
1. Unary Relationship: When there is only ONE entity set participating in a relation, the relationship
is called a unary relationship. For example, one person is married to only one person.

Unary Relationship

2. Binary Relationship: When there are TWO entities set participating in a relationship, the
relationship is called a binary relationship. For example, a Student is enrolled in a Course.

Binary Relationship

3. Ternary Relationship: When there are three entity sets participating in a relationship, the
relationship is called a ternary relationship.
4. N-ary Relationship: When there are n entities set participating in a relationship, the relationship is
called an n-ary relationship.
What is Cardinality?
The number of times an entity of an entity set participates in a relationship set is known as cardinality .
Cardinality can be of different types:
1. One-to-One: When each entity in each entity set can take part only once in the relationship, the
cardinality is one-to-one. Let us assume that a male can marry one female and a female can marry one
male. So the relationship will be one-to-one.
the total number of tables that can be used in this is 2.

one to one cardinality

Using Sets, it can be represented as:

Set Representation of One-to-One

2. One-to-Many: In one-to-many mapping as well where each entity can be related to more than one
entity and the total number of tables that can be used in this is 2. Let us assume that one surgeon
department can accommodate many doctors. So the Cardinality will be 1 to M. It means one
department has many Doctors.
total number of tables that can used is 3.
one to many cardinality

Using sets, one-to-many cardinality can be represented as:

Set Representation of One-to-Many

3. Many-to-One: When entities in one entity set can take part only once in the relationship set and
entities in other entity sets can take part more than once in the relationship set, cardinality is many to
one. Let us assume that a student can take only one course but one course can be taken by many
students. So the cardinality will be n to 1. It means that for one course there can be n students but for
one student, there will be only one course.
The total number of tables that can be used in this is 3.
many to one cardinality

Using Sets, it can be represented as:

Set Representation of Many-to-One

In this case, each student is taking only 1 course but 1 course has been taken by many students.
4. Many-to-Many: When entities in all entity sets can take part more than once in the relationship
cardinality is many to many. Let us assume that a student can take more than one course and one course
can be taken by many students. So the relationship will be many to many.
the total number of tables that can be used in this is 3.
many to many cardinality

Using Sets, it can be represented as:

Many-to-Many Set Representation

In this example, student S1 is enrolled in C1 and C3 and Course C3 is enrolled by S1, S3, and S4. So it
is many-to-many relationships.
Participation Constraint
Participation Constraint is applied to the entity participating in the relationship set.
1. Total Participation – Each entity in the entity set must participate in the relationship. If each
student must enroll in a course, the participation of students will be total. Total participation is shown
by a double line in the ER diagram.
2. Partial Participation – The entity in the entity set may or may NOT participate in the relationship.
If some courses are not enrolled by any of the students, the participation in the course will be partial.
The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set having total participation
and Course Entity set having partial participation.

Total Participation and Partial Participation

Using Set, it can be represented as,

Set representation of Total Participation and Partial Participation

Every student in the Student Entity set participates in a relationship but there exists a course C4 that is
not taking part in the relationship.
How to Draw ER Diagram?
 The very first step is Identifying all the Entities, and place them in a Rectangle, and labeling them
accordingly.
 The next step is to identify the relationship between them and place them accordingly using the
Diamond, and make sure that, Relationships are not connected to each other.
 Attach attributes to the entities properly.
 Remove redundant entities and relationships.
 Add proper colors to highlight the data present in the database.
Conclusion
An Entity-Relationship (ER) model is a way to visually represent the structure of a database. It shows
how different entities (like objects or concepts) are connected and interact with each other through
relationships. The model uses diagrams to represent entities as rectangles and relationships as
diamonds, making it easier to design and understand databases .

What is a Decision Table?

A decision table is a good way to settle different combination inputs with their corresponding outputs
and is also called a cause-effect table.
1. The reason to call the cause-effect table is a related logical diagramming technique called cause-
effect graphing that is used to obtain the decision table.
2. The information represented in decision tables can also be represented as decision trees or in a
programming language using if-then-else and switch-case statements.
Importance of Decision Table
Decision tables are very helpful in test design techniques.
1. Helps testers to search effects of combinations: It helps testers to search the effects of
combinations of different inputs and other software states that must correctly implement business
rules.
2. Helps to start complex business rules: It provides a regular way of starting complex business
rules, that is helpful for developers as well as for testers.
3. Helps in the development process: It assists in the development process with the developer to do
a better job. Testing with all combinations might be impractical.
4. Used in testing: A decision table is basically an outstanding technique used in both testing and
requirements management.
5. Helps to prepare requirements: It is a structured exercise to prepare requirements when dealing
with complex business rules.
6. Helps to model complicated logic: It is also used to model complicated logic.
Decision Table in Test Designing
Blank Decision Table
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1
Condition 2
Condition 3
Condition 4

Decision Table: Combinations

CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1 Y Y N N
Condition 2 Y N Y N
Condition 3 Y N N Y
Condition 4 N Y Y N

Advantages of Decision Table

1. Easy conversion of business flow to test case: Any complex business flow can be easily
converted into test scenarios and test cases using this technique.
2. Works iteratively: Decision tables work iteratively which means the table created at the first
iteration is used as input tables for the next tables. The iteration is done only if the initial table is
not satisfactory.
3. Simple to understand: Simple to understand and everyone can use this method to design the test
scenarios & test cases.
4. Provides complete test case coverage: It provides complete coverage of test cases which helps to
reduce the rework on writing test scenarios & test cases.
5. Guarantees every combination is considered: These tables guarantee that we consider every
possible combination of condition values. This is known as its completeness property.

6. IEEE standards for SRS.

7. IEEE defines software requirements specification as, ‘a document that clearly and
8. precisely describes each of the essential requirements (functions, performance, design
9. constraints and quality attributes) of the software and the external interfaces. Each
10. requirement is defined in such a way that its achievement can be objectively verified
11. by a prescribed method, for example, inspection, demonstration, analysis or test.’
12. Identify the responsibilities of a Software Project Manager?
13. Software project manager is the person who manages software projects. She or he will
14. be attached to the project from the beginning to the end and continue with the life
15. cycle of the software. It is impossible to write a standard list of responsibilities a
16. software project manager. The job varies with organization and product being
17. developed. However, following are the responsibilities most software project
18. managers have to deal with.
1 9 . 
Proposal writing
2 0 . 
Project planning and scheduling
2 1 . 
Estimating project cost
2 2 . 
Monitoring and reviewing
2 3 . 
Building team and evaluation
2 4 . 
Reporting
25. Define Software process model.
26. Software Processes is a coherent set of activities for specifying, designing,
27. implementing and testing software systems. A software process model is an abstract
28. representation of a process that presents a description of a process from some
29. particular perspective. There are many different software processes but all involve:
3 0 .  Specification – defining what the system should do;
3 1 .  Design and implementation – defining the
organization of the system and
32. implementing the system;
3 3 .  Validation – checking that it does what the customer
wants;
3 4 .  Evolution – changing the system in response to
changing customer needs.
35. Define Elicitation analysis.
36. Requirement elicitation process can be depicted using the folloiwng diagram:
3 7 .  Requirements gathering - The
developers discuss with the client and end
38. users and know their expectations from the software.
Software Quality Assurance (SQA
Software Quality Assurance (SQA) is a critical component of the software development process that
ensures the quality and reliability of software products. SQA encompasses methodologies and practices
designed to monitor the software engineering processes and methods used to ensure quality. The
emphasis is on preventing defects rather than detecting them after they have been introduced. This
introductory guide explores why SQA is indispensable in modern software development and how it can
be implemented effectively.

Fundamentals of Software Quality Assurance

Understanding the fundamentals of Software Quality Assurance (SQA) is crucial for developing software
that is robust, reliable, and meets user expectations. SQA encompasses various practices, methodologies,
and frameworks designed to ensure the quality of software products throughout the software development
lifecycle (SDLC). Here’s a detailed look at the core fundamentals of SQA:

1. Quality Planning
Quality planning involves defining specific quality standards for projects and determining the necessary
processes to achieve these standards. This stage sets the foundation for what the quality goals are and how
they will be measured. It includes establishing quality policies, objectives, and criteria for accepting
software products.

2. Quality Control (QC)

Quality control is the process of enforcing quality standards by inspecting and testing the software
product during and after development. QC activities involve:
Testing: Systematic execution of software to identify bugs and ensure that functionalities meet the
specified requirements.
Inspections and Reviews: Formal and informal reviews of the software, including code reviews, design
reviews, and requirement reviews to catch defects early in the process.
3. Quality Assurance
While quality control focuses on the output, quality assurance focuses on improving the processes used to
make the product. This includes:
Process Standardization: Developing and following standardized processes to reduce variability and
increase predictability.
Process Evaluation and Improvement: Continually evaluating processes for effectiveness and efficiency,
using models and standards such as CMMI (Capability Maturity Model Integration) and ISO 9001.

4. Quality Management

This encompasses all activities related to maintaining and enhancing the quality of the software. It
includes:

Leadership Engagement: Ensuring that the organization’s leadership understands and supports quality
initiatives.

Resource Management: Allocating and managing resources effectively to maintain quality standards.
Risk Management: Identifying, analyzing, and mitigating risks that could impact software quality.

5. Software Metrics and Measurement

Metrics and measurements are crucial for assessing the effectiveness of SQA activities. Common metrics
include:

Defect Density: The number of defects confirmed in software divided by the size of the software.

Code Coverage: A measure of how much code is executed during testing, which helps in understanding
the extent of testing.

Customer Satisfaction: Feedback from users about the software’s performance and features.

6. Preventive and Corrective Actions

Preventive Actions: Steps taken to eliminate the causes of potential nonconformities or defects.

Corrective Actions: Actions taken to eliminate the causes of detected nonconformities or defects.

7. Continuous Improvement

The principle of continuous improvement, often referred to by its Japanese name, "Kaizen," is integral to
SQA. This involves ongoing efforts to improve all processes, based on feedback and iterative learning.
Techniques like retrospectives, post-mortem analyses, and process refinement sessions are used to
analyze successes and failures and to implement lessons learned.

SQA Processes and Techniques

Software Quality Assurance (SQA) involves various processes and techniques that help ensure the quality
of software throughout the development lifecycle. These methodologies are designed to prevent defects,
ensure functionality meets specified requirements, and maintain a high standard of software performance.
Here’s an in-depth look at some key SQA processes and techniques:

1. Code Reviews

Code reviews are a critical SQA activity where other developers (peers) review the source code written
by a developer before it merges into the main branch. This practice aims to catch errors early in the
development phase, promote a higher code quality standard, and share knowledge across the team.
Benefits include:

Detecting bugs early in the software development process.

Improving the overall design and maintainability of the code.

Enhancing coding skills across the team through peer feedback.

2. Automated Testing

Automated testing uses software tools to run tests on the software automatically, checking for errors,
defects, and functional mismatches. This can include:

Unit Testing: Testing individual units or components of a software application.

Integration Testing: Testing combined parts of an application to determine if they function together
correctly.

System Testing: Testing the complete and integrated software product to evaluate the system’s
compliance with its specified requirements.

Automated testing is valuable because it can be executed quickly and repeatedly, which is crucial for
continuous integration and delivery pipelines.

3. Continuous Integration and Continuous Delivery (CI/CD)

CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of
app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery,
and continuous deployment. CI/CD is intended to:

Reduce risks in software development.

Ensure that software can be reliably released at any time.

Help developers to detect and locate errors quickly.

4. Static and Dynamic Analysis

Static Analysis: This technique involves analyzing the code without executing it. It’s used to detect
coding errors, security lapses, and compliances with coding guidelines.

Dynamic Analysis: Unlike static analysis, dynamic analysis involves executing code. It provides insights
into the system's behavior and verifies that the system performs expected tasks under varying conditions.
 5. Risk-Based Testing

Risk-based testing prioritizes testing of features and functions in the software application based on the
risk of failure, the importance and likelihood of failure, and the impact of failure. This approach helps to
optimize test efforts towards the most critical areas of the system.

6. Test-Driven Development (TDD)

TDD is a software development approach in which tests are written before the code that needs to be
tested. The process follows a simple cycle:

Write a test for a new function.

Run the test and see it fail.

Implement the function.

Run the test again and see it succeed.

Refactor the code for optimization.

This technique ensures that the software is tested at the function level and that all functionalities are
covered by the tests, which improves code quality.

7. Performance Testing

This type of testing is performed to determine how a system performs in terms of responsiveness and
stability under a particular workload. It can involve load testing, stress testing, and spike testing, among
others, to ensure the software application behaves as expected under varied conditions.

ISO Standards in Software Engineering





Prerequisite – ISO 9000 Certification in Software Engineering

Overview :
The mission of the International Standard Organization is to market the development of standardization
and its related activities to facilitate the international exchange of products and services. It also helps to
develop cooperation within the different activities like spheres of intellectual, scientific, technological,
and economic activity.
ISO 9000 Quality Standards :
It is defined as the quality assurance system in which quality components can be organizational structure,
responsibilities, procedures, processes, and resources for implementing quality management. Quality
assurance systems are created to help organizations ensure their products and services satisfy customer
expectations by meeting their specifications.
Different types of ISO standards :
Here, you will see different types of ISO standards as follows.
 ISO 9000: 2000 –
ISO 9000: 2000: contains Quality management systems, fundamentals, and vocabulary.

 ISO 9000-1: 1994 –

This series of standards includes Quality management systems and Quality assurance standards. It
also includes some guidelines for selection and use.

 ISO 9000-2: 1997 –

 This series of standards also includes Quality management systems and Quality assurance standards.
It also includes some guidelines for the application of ISO 9001, ISO 9002, and ISO 9003.

 ISO 9000-3: 1997 –

This series contains Quality management systems, Quality assurance standards and also includes
guidelines for the application of ISO 9001 to 1994 to the development, supply, installation, and
maintenance of computer installation.

 ISO 9001: 1994 –

This series of standards has Quality systems and a Quality assurance model. This model helps in
design, development, production, installation, and service.

 ISO 9001: 2000 –

This series of standards also includes Quality management systems.

 ISO 9002: 1994 –

This series of standards also includes some Quality systems. This Quality assurance model used in
production, installation, and servicing.

 ISO 9003: 1994 –

This series of standards also includes some Quality systems. This Quality assurance model used in the
final inspection and test.

 ISO 9004: 2000 –

This series of standards include some Quality management systems. It also includes some guidelines
for performance improvements.

 ISO 9039: 1994 –

This series of standards include some Optics and Optical Instruments. It includes quality evaluation
of optical systems and determination of distortion.

 ISO/IEC 9126-1: 2001 –

This series of standards has information technology. It also includes some software products, quality
models.

 ISO/IEC 9040: 1997 –

This series of standards has information technology. It also includes open system interconnection and
 Virtual terminal basic class service.

 ISO/IEC 9041-1: 1997 –

This series of standards has information technology. It also includes open system interconnection,
Virtual terminal basic class service protocol, and specification.

 ISO/IEC 9041-2: 1997 –

This series of standards include information technology, open system interconnection, Virtual
terminal basic class protocol, and Protocol implementation conformance statement (PICS) proforma.

 ISO/IEC 9075-9: 2001 –

This series of standards has information technology, Database languages, and
SQL/MED(Management of External Data).

 ISO/IEC 9075-10: 2000 -|

This series of standards has information technology, Database languages, and SQL/OLB (Object
Language Bindings).

 ISO/IEC 9075-13: 2002 –

This series of standards has information technology, Database languages, SQL routines, and Java
Programming language. (SQL/JRT).

Software Quality Frameworks are structured methodologies that guide the development process towards
achieving high-quality software. Here’s a breakdown of three prominent frameworks:
1. ISO 9000 Models:
 Focus: These are generic quality management standards developed by the International Organization for
Standardization (ISO). They are not specific to software development but can be adapted for this purpose.
 Core Principles: The ISO 9000 family emphasizes a process-oriented approach to quality management.
It focuses on establishing documented processes, continuous improvement, and customer satisfaction.
 Benefits: Implementing ISO 9000 standards can lead to improved software quality, consistency, and
efficiency in development processes. It can also demonstrate a commitment to quality to stakeholders.
 Limitations: ISO 9000 is not specifically designed for software development, and achieving certification
can be resource-intensive.

2. SEI Capability Maturity Model (SEI-CMM):

 Focus: Developed by the Software Engineering Institute (SEI) at Carnegie Mellon University, SEI-CMM
is a maturity model that assesses the capability of an organization’s software development processes.
 Maturity Levels: SEI-CMM defines five maturity levels, ranging from Initial (ad hoc processes) to
Optimized (continuous process improvement).
 Benefits: By identifying areas for improvement and providing a roadmap for process maturity, SEI-CMM
can lead to significant quality improvements in software development.
 Limitations: Implementing SEI-CMM can be complex and time-consuming. It requires a strong
commitment from management and resources for training and process improvement

Verification and Validation





Verification and Validation is the process of investigating whether a software system satisfies
specifications and standards and fulfills the required purpose. Verification and Validation both play an
important role in developing good software development. Verification helps in examining whether the
product is built right according to requirements, while validation helps in examining whether the right
product is built to meet user needs. In this article, we will learn the difference between Verification and
Validation.

Differences between Verification and Validation

What is Verification?
Verification is the process of checking that software achieves its goal without any bugs. It is the process
to ensure whether the product that is developed is right or not. It verifies whether the developed product
fulfills the requirements that we have. Verification is static testing. Verification means Are we building
the product right?
What is Validation?
Validation is the process of checking whether the software product is up to the mark or in other words
product has high-level requirements. It is the process of checking the validation of the product i.e. it
checks what we are developing is the right product. It is validation of the actual and expected products.
Validation is dynamic testing. Validation means Are we building the right product?
Differences between Verification and Validation
 Verification Validation

Validation refers to the set of activities

Verification refers to the set of activities
that ensure that the software that has been
that ensure software correctly
built is traceable to customer
implements the specific function
Definition requirements.

It includes checking documents, designs, It includes testing and validating the

codes, and programs. actual product.
Focus

Verification is the static testing. Validation is dynamic testing.

Type of Testing

It does not include the execution of the

It includes the execution of the code.
code.
Execution

Methods used in verification are Methods used in validation are Black

reviews, walkthroughs, inspections and Box Testing, White Box
desk-checking. Testing and non-functional testing.
Methods Used

It checks whether the software meets the

It checks whether the software conforms
requirements and expectations of a
to specifications or not.
customer or not.
Purpose

It can find the bugs in the early stage of It can only find the bugs that could not be
the development. found by the verification process.
Bug

The goal of verification is application

The goal of validation is an actual
and software architecture and
product.
specification.
Goal

Validation is executed on software code

Quality assurance team does verification.
with the help of testing team.
Responsibility
 Verification Validation

It comes before validation. It comes after verification.

Timing

It consists of checking of documents/files It consists of execution of program and is

Human or and is performed by human. performed by computer.
Computer

After a valid and complete specification Validation begins as soon as project

the verification starts. starts.
Lifecycle

Verification is for prevention of errors. Validation is for detection of errors.

Error Focus

Verification is also termed as white box Validation can be termed as black box
testing or static testing as work product testing or dynamic testing as work
Another goes through reviews. product is executed.
Terminology

Verification finds about 50 to 60% of the Validation finds about 20 to 30% of the
defects. defects.
Performance

Verification is based on the opinion of

Validation is based on the fact and is
reviewer and may change from person to
often stable.
person.
Stability

Real-World Example of Verification vs Validation

 Verification Example: Imagine a team is developing a new mobile banking app. During the
verification phase, they review the requirements and design documents. They check if all the
specified features like fund transfer, account balance check, and transaction history are included and
correctly detailed in the design. They also perform peer reviews and inspections to ensure the design
aligns with the requirements. This step ensures that the app is being built according to the initial plan
and specifications without actually running the app.
 Validation Example: In the validation phase, the team starts testing the mobile banking app on
actual devices. They check if users can log in, transfer money, and view their transaction history as
intended. Testers perform usability tests to ensure the app is user-friendly and functional tests to
ensure all features work correctly. They might also involve real users to provide feedback on the
app’s performance. This phase ensures that the app works as expected and meets user needs in real-
world scenarios.
Advantages of Differentiating Verification and Validation
Differentiating between verification and validation in software testing offers several advantages:
1. Clear Communication: It ensures that team members understand which aspects of the software
development process are focused on checking requirements (verification) and which are focused on
ensuring functionality (validation).
2. Efficiency: By clearly defining verification as checking documents and designs without executing
code, and validation as testing the actual software for functionality and usability, teams avoid
redundant efforts and streamline their testing processes.
3. Minimized Errors: It reduces the chances of overlooking critical requirements or functionalities
during testing, leading to a more thorough evaluation of the software’s capabilities.
4. Cost Savings: Optimizing resource allocation and focusing efforts on the right testing activities based
on whether they fall under verification or validation helps in managing costs effectively.
5. Client Satisfaction: Ensuring that software meets or exceeds client and user expectations by
conducting both verification and validation processes rigorously improves overall software quality
and user satisfaction.
6. Process Improvement: By distinguishing between verification and validation, organizations can
refine their testing methodologies, identify areas for improvement, and enhance the overall software
development lifecycle.
In essence, clear differentiation between verification and validation in software testing contributes to a
more structured, efficient, and successful software development process.
Conclusion
Verification is a static process focused on reviewing and analyzing documentation and design without
running the code. It ensures that the software is being built correctly according to specifications. In
contrast, validation is a dynamic process that involves executing the software to check its functionality,
usability, and suitability, ensuring the right product is built to meet user needs. Both processes are
essential for delivering a high-quality software product.

What is a Software Quality Assurance Plan?

A Quality Assurance Plan (QAP) is a document or set of documents that outlines the systematic
processes, procedures, and standards for ensuring the quality of a product or service. It is a key
component of quality management and is used in various industries to establish and maintain a
consistent level of quality in deliverables. For a software product or service, an SQA plan will be used
in conjunction with the typical development, prototyping, design, production, and release cycle. An
SQA plan will include several components, such as purpose, references, configuration and
management, tools, code controls, testing methodology, problem reporting and remedial measures, and
more, for easy documentation and referencing.
SQA-Plan

Importance of Software Quality Assurance Plan

 Quality Standards and Guidelines: The SQA Plan lays out the requirements and guidelines to
make sure the programme satisfies predetermined standards for quality.
 Risk management: It is the process of recognizing, evaluating and controlling risks in order to
reduce the possibility of errors and other problems with quality.
 Standardization and Consistency: The strategy guarantees consistent methods, processes, and
procedures, fostering a unified and well-structured approach to quality assurance.
 Customer Satisfaction: The SQA Plan helps to ensure that the finished product satisfies customer
needs, which in turn increases overall customer satisfaction.
 Resource optimization: It is the process of defining roles, responsibilities, and procedures in order
to maximize resource utilization and minimize needless rework.
 Early Issue Detection: SQA Plans help identify problems early on, which lowers the expense and
work involved in fixing them.
Objectives And Goals of Software Quality Assurance Plan:
The objectives and goals of a Quality Assurance Plan (QAP) are to ensure that the products or services
meet specified quality standards and requirements. The plan serves as a roadmap for implementing
quality assurance processes throughout a project or organizational activity. The specific objectives and
goals can vary depending on the nature of the project or industry, but common elements include:
Compliance with Standards and Regulations:
 Objective: Ensure that the project or product complies with relevant industry standards, regulatory
requirements, and any other applicable guidelines.
 Goal: Achieve and maintain adherence to established quality standards to meet legal and regulatory
obligations.
Customer Satisfaction:
 Objective: Enhance customer satisfaction by delivering products or services that meet or exceed
customer expectations.
 Goal: Identify and prioritize customer requirements, and incorporate them into the quality
assurance processes to create a positive customer experience.
Defect Prevention:
 Objective: Implement measures to prevent defects, errors, or issues in the early stages of the
project lifecycle.
 Goal: Identify potential sources of defects, analyze root causes, and take proactive steps to
eliminate or minimize the occurrence of defects.
Consistency and Reliability:
 Objective: Establish a consistent and reliable process for the development or delivery of products
and services.
 Goal: Ensure that the quality of deliverables is consistent over time and across different phases of
the project, promoting reliability and predictability.
Process Improvement:
 Objective: Continuously improve processes to enhance efficiency, effectiveness, and overall
quality.
 Goal: Implement feedback mechanisms, conduct regular process assessments, and identify
opportunities for improvement to optimize the quality assurance process.
Risk Management:
 Objective: Identify and manage risks that could impact the quality of the project or product.
 Goal: Develop strategies to assess, mitigate, and monitor risks that may affect the achievement of
quality objectives.
Clear Roles and Responsibilities:
 Objective: Clearly define roles and responsibilities related to quality assurance activities.
 Goal: Ensure that team members understand their roles in maintaining and improving quality,
fostering accountability and collaboration.
Documentation and Traceability:
 Objective: Establish a robust documentation process to track and trace quality-related activities
and decisions.
 Goal: Create comprehensive records that enable transparency, accountability, and the ability to
trace the development or production process.
Training and Competence:
 Objective: Ensure that team members are adequately trained and possess the necessary
competencies to perform quality assurance tasks.
 Goal: Provide ongoing training to enhance the skills and knowledge of individuals involved in
quality assurance.
Continuous Monitoring and Reporting:
 Objective: Monitor quality metrics and report on the status of quality assurance activities.
 Goal: Implement regular monitoring and reporting mechanisms to track progress, identify issues,
and make data-driven decisions to maintain or improve quality.
By aligning the Quality Assurance Plan with these objectives and goals, organizations can establish a
robust framework for consistently delivering high-quality products or services while adapting to
changes and opportunities for improvement.
Steps to Develop Software Quality Assurance Plan:
Developing a Quality Assurance Plan (QAP) involves a systematic process to ensure that the plan
effectively addresses the quality requirements of a project or process. Here are the steps to develop a
Quality Assurance Plan:
Define Project Objectives and Scope:
 Clearly articulate the objectives and scope of the project or process for which the Quality
Assurance Plan is being developed. Understand the goals, deliverables, and stakeholders involved.
Identify Quality Standards and Criteria:
 Determine the relevant quality standards, regulations, and criteria that are applicable to the project.
This may include industry standards, legal requirements, and internal organizational standards.
Identify Stakeholders:
 Identify and involve key stakeholders who have an interest in or will be affected by the quality of
the project or process. This includes project managers, team members, customers, and any
regulatory bodies.
Define Roles and Responsibilities:
 Clearly define the roles and responsibilities of individuals or teams involved in quality assurance
activities. This ensures accountability and clarity in the execution of quality-related tasks.
Conduct a Risk Assessment:
 Identify potential risks to the quality of the project. Assess the impact and likelihood of these risks
and develop strategies for risk mitigation and management.
Establish Quality Assurance Activities:
 Determine the specific activities and tasks that will be carried out to ensure quality throughout the
project lifecycle. This may include reviews, inspections, audits, testing, and other quality control
measures.
Develop Testing and Inspection Procedures:
 If applicable, create detailed testing and inspection procedures. This includes developing test plans,
test cases, and acceptance criteria to ensure that the product or service meets quality standards.
Document Processes and Procedures:
 Document the processes and procedures that will be followed to implement quality assurance
activities. This documentation serves as a reference for team members and provides a basis for
consistency.
Establish Documentation and Reporting Mechanisms:
 Define the documentation requirements for tracking and reporting quality-related information. This
may include reports, checklists, and records of quality assessments.
Allocate Resources and Training:
 Specify the resources, tools, and training that will be provided to team members to support quality
assurance efforts. Ensure that team members have the necessary skills and knowledge.
Define Change Control Processes:
 Establish a process for managing changes to the project or product to ensure that they do not
negatively impact quality. This includes a change control board and a structured process for
reviewing and approving changes.
Review and Approval:
 Seek input and feedback from relevant stakeholders on the draft Quality Assurance Plan. Revise the
plan based on feedback and obtain formal approval before implementation.
Monitoring and Continuous Improvement:
 Continuously monitor quality metrics, track progress, and identify opportunities for improvement.
Regularly review and update the Quality Assurance Plan to adapt to changes and enhance its
effectiveness.
Communication and Training:
 Communicate the Quality Assurance Plan to all relevant stakeholders and provide training as
necessary. Ensure that everyone involved understands their roles and responsibilities in maintaining
and improving quality.
SQA implementation phase:
Developers work with the SQA team to construct a development plan before beginning to build an
application. The Software Quality Assurance (SQA) team produces the Software Quality Assurance
plan, and the developers write the Software Development Life Cycle (SDLC) plan. If the
documentation created by the developers and the SQA are well-written and structured, the application
that is going to be developed is already 50% finished.
The SQA team's duty during this stage is to guarantee that the intended application's suggested features
are implemented. The application will monitor not only the implementation process but also the
development process. Certain design techniques, such language or framework, can be applied. In order
to assist the development team in choosing the appropriate framework language.
The software's documentation is reviewed by the SQA team. The purpose of the application is stated in
detail in the documentation.
Best Practices for Creating Software Quality Assurance Plan:
Creating a Software Quality Assurance (SQA) plan is essential to ensure the development of high-
quality software. Here are some best practices to consider when creating a Software Quality Assurance
Plan:
Understand Project Objectives:
 Clearly understand the objectives, goals, and scope of the software development project. This
understanding is critical for tailoring the SQA plan to the specific needs of the project.
Define Quality Standards:
 Identify and document the relevant quality standards, guidelines, and best practices that the
software must adhere to. This may include industry standards, regulatory requirements, and internal
organizational standards.
Involve Stakeholders:
 Engage key stakeholders, including developers, testers, project managers, and customers, in the
creation of the SQA plan. Ensure that their perspectives and requirements are considered.
Set Clear Roles and Responsibilities:
 Clearly define the roles and responsibilities of individuals or teams involved in SQA activities. This
includes roles such as SQA manager, testers, developers, and project managers.
Establish Testing Processes:
 Define the testing processes, including types of testing (e.g., unit testing, integration testing, system
testing, etc.), testing techniques, and tools to be used. Clearly articulate the criteria for success in
each testing phase.
Incorporate Automated Testing:
 Integrate automated testing into the testing processes where applicable. Automated testing can
improve efficiency, coverage, and the repeatability of tests, especially for repetitive and regression
testing.
Document Test Plans and Cases:
 Develop comprehensive test plans and test cases that cover the functional and non-functional
requirements of the software. Test documentation serves as a reference for testers and ensures
comprehensive coverage.
Implement Code Reviews:
 Integrate code reviews as part of the development process. Code reviews help identify defects early
in the development lifecycle, improving code quality and reducing the likelihood of defects
reaching later stages.
Utilize Continuous Integration (CI) and Continuous Deployment (CD):
 Implement CI/CD practices to automate the integration and deployment processes. This ensures
that changes are regularly and consistently tested, reducing the risk of integration issues and
improving overall software quality.
Implement Configuration Management:
 Use configuration management practices to manage changes to the software, including version
control, baseline management, and change control. This helps maintain consistency and traceability
in software development.
Why is SQA Plan Important for Software Companies?
A Software Quality Assurance (SQA) plan is crucial for software companies for several reasons, as it
helps ensure the delivery of high-quality software products and contributes to the overall success of the
company. Here are some key reasons why an SQA plan is important for software companies:
 Quality Assurance and Customer Satisfaction: An SQA plan establishes processes and standards
to ensure that software products meet or exceed customer expectations. High-quality software
contributes to customer satisfaction, enhances the company's reputation, and fosters customer
loyalty.
 Compliance with Standards and Regulations: Many industries have specific standards and
regulations that software products must adhere to. An SQA plan helps ensure compliance with
these standards, reducing the risk of legal issues and demonstrating the company's commitment to
quality.
 Early Detection and Prevention of Defects: The SQA plan includes processes for early detection
and prevention of defects. This involves activities such as code reviews, testing, and inspections,
which help identify and address issues in the early stages of the development lifecycle, reducing the
cost and impact of defects.
 Cost Reduction: Identifying and fixing defects early in the development process is more cost-
effective than addressing them in later stages or after the software is released. An SQA plan helps
minimize the number of defects that reach production, reducing maintenance costs and improving
overall efficiency.
 Improved Collaboration and Communication: The SQA plan defines roles, responsibilities, and
communication channels within the development team. This clarity fosters better collaboration
among team members, reducing misunderstandings and improving the overall efficiency of the
development process.
 Risk Management: An SQA plan includes risk management strategies to identify, assess, and
mitigate risks that could impact software quality. This proactive approach helps the company
address potential issues before they become significant problems.
 Enhanced Productivity and Efficiency: Standardized processes outlined in the SQA plan
contribute to improved productivity and efficiency. Consistent methodologies and practices help
streamline development, testing, and release processes, leading to faster and more reliable software
delivery.
Pros of Software Quality Assurance Plan:
 Early Defect Identification: SQA strategies lessen the possibility of expensive problems later in
the software development life cycle by facilitating the early discovery and resolution of flaws.
 Enhanced Quality of Product: SQA plans help to improve the overall quality of the software
product by setting quality standards and procedures, which raises customer satisfaction.
 Adherence to the standards: It plans guarantee adherence to industry norms, legal mandates, and
optimal methodologies, offering a structure for producing software of superior quality.
 Improved Cooperation Among Teams: The SQA plan's well-defined roles and duties encourage
productive teamwork and guarantee that everyone is on the same page with the quality goals.
Cons of Software Quality Assurance Plan:
 Overhead in Small Projects: The cost of developing and upholding a detailed SQA plan may be
excessive for small projects compared to their scope and complexity.
 Opposition to Change: An SQA strategy may involve changes that teams accustomed to their
current workflows find difficult to accept, which could result in a time of adjustment and
resistance.
 Documentation Complexity: SQA plans with high documentation requirements run the risk of
adding complexity and coming off as bureaucratic to teams, which makes it difficult to keep
documentation up to date.
 Reliance on Human Elements: An SQA plan's performance depends on human elements like
procedure adherence and attention to detail, which makes human mistake a possibility.
 Conclusion:
In conclusion, a Software Quality Assurance (SQA) plan is a fundamental and indispensable
component for software companies aiming to deliver high-quality products and maintain a competitive
edge in the market. The significance of an SQA plan lies in its ability to establish systematic processes,
standards, and practices that ensure software products meet or exceed customer expectations.
Want to learn Software Testing and Automation to help give a kickstart to your career? Any student
or professional looking to excel in Quality Assurance should enroll in our course, Complete Guide to
Software Testing and Automation, only on GeeksforGeeks. Get hands-on learning experience with
the latest testing methodologies, automation tools, and industry best practices through practical
projects and real-life scenarios. Whether you are a beginner or just looking to build on existing skills,
this course will give you the competence necessary to ensure the quality and reliability of software
products. Ready to be a Pro in Software Testing? Enroll now and Take Your Career to a Whole New
Level!

Software Quality Framework – Software Engineering





Software Quality Framework is a model for software quality that ensures quality by connecting and
integrating the different views of software quality. This article focuses on discussing the Software
Quality Framework.
What is a Software Quality Framework?
Software Quality Framework connects the customer view with the developer’s view of software quality
and it treats software as a product.
1. The software product view describes the characteristics of a product that bear on its ability to
satisfy stated and implied needs.
2. This is a framework that describes all the different concepts relating to quality in a common way
measured by a qualitative scale that can be understood and interpreted commonly.
Therefore, the most influential factor for the developers is the customer perception. This framework
connects the developer with the customer to derive a common interpretation of quality.
Developers View
Validation and verification are two independent methods used together to check that a software product
meets the requirements and that it fulfills its intended purpose. Validation checks that the product
design satisfies the purposeful usage and verification checks for errors in the software.
1. The primary concern for developers is in the design and engineering processes involved in
producing software.
2. Quality can be measured by the degree of conformance to predetermined requirements and
standards, and deviations from these standards can lead to poor quality and low reliability.
3. While validation and verification are used by the developers to improve the software, the two
methods don’t represent a quantifiable quality measurement.
4. The developer’s view of software quality and the customer’s view of software quality are both
different things.
For example, the customer understands or describes the quality of operation as meeting the requirement
while the developers use different factors to describe the software quality. The developer view of
quality in the software is influenced by many factors. This model stresses on 3 primary ones:
The code: It is measured by its correctness and reliability.
The data: The application integrity measures it.
Maintainability: It has different measures the simplest is the mean time to change.
Users View
When the user acquires software, he/she always expect a high-quality software. When end users
develop their software then quality is different. End-user programming, a phrase popularized by which
is programming to achieve the result of a program primarily for personal, rather than public use.
1. The important distinction here is that software itself is not primarily intended for use by many users
with varying needs.
2. For example, a teacher may write a spreadsheet to track student’s test scores.
3. In these end-user programming situations, the program is a means to an end that could be used to
accomplish a goal.
4. In contradiction to end-user programming, professional programming has the goal of producing
software for others to use.
5. For example, the moment a novice Web developer moves from designing a web page for himself to
designing a Web page for others, the nature of this activity has changed.
6. Users find software quality as a fit between their goals and software’s functionality.
7. The better the quality, the more likely the user will be satisfied with the soft-ware.
8. When the quality is bad, developers must meet user needs or face a diminishing demand for their
software.
Therefore, the user understands quality as fitness for purpose. Avoiding complexity and keeping
software simple, considerably lessens the implementation risk of software. In some instances, users
abandoned the implementation of a complex software because the software developers were expecting
the users to change their business and to go with the way the software works.
Product View
The product view describes quality as correlated to inherent characteristics of the product. Product
quality is defined as the set of characteristics and features of a product that gives contribution to its
ability to fulfill given requirements.
1. Product quality can be measured by the value-based view which sees the quality as dependent on
the amount a customer is willing to pay for it.
2. According to the users, a high-quality product is one that satisfies their expectations and
preferences while meeting their requirement.
3. Satisfaction of end users of the product represents craft to learn, use, upgrade the product and when
asked to participate in rating the product, a positive rating is given.