Unit 2

SOFTWARE REQUIREMENTS ANALYSIS AND SPECIFICATION

Before we start to develop our software, it becomes quite essential for us to understand and document the
exact requirement of the customer. Experienced members of the development team carry out this job. They
are called as system analysts.

system analysts get the answers of the following questions during requirement engineering:

• What is the problem?

• Why is it important to solve the problem?
• What are the possible solutions to the problem?
• What exactly is the data input to the system and what exactly are the data output by the system?
• What are the likely complexities that might arise while solving the problem?
• If there is external software or hardware with which the developed software has to interface, then what
exactly would the data interchange formats with the external system be?

Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of
gathering and defining service provided by the system. Requirements Engineering Process consists of the following
main activities:
Requirements Elicitation:

● It is also known as gathering of requirements.

● Here, requirements are identified with the help of customers and existing system processes.

Requirements analysis:

● After the requirement elicitation, requirements are analysed. The requirements are analyzed to identify
inconsistencies, defects, omission, etc.
● The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.

Requirements specification and documentation:

● Software requirement specification (SRS) is a kind of document which is created after removing
inconsistencies, defects from the requirements.
● This activity is used to produce formal software requirement models.
● All the requirements including the functional as well as the non-functional requirements and the constraints are
specified by these models.

Requirements review and management:

 ● This process is carried out to improve the quality of SRS.
● The requirements should be consistent with all the other requirements i.e no two requirements should
conflict with each other.
● The requirements should be complete in every sense.
● The requirements should be practically achievable.
● Prioritization of requirements is done.
● It is ensured that the SRS is as modifiable as possible so as to incorporate changes in requirements specified by
the end users at later stages too.

Requirements Elicitation Methods:

There are a number of requirements elicitation methods. Few of them are listed below –

1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach

1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations from the software.
Interviews may be open-ended or structured.

1. In open-ended interviews there is no pre-set agenda. Context free questions may be asked to understand the
problem.
2. In a structured interview, an agenda of fairly open questions is prepared. Sometimes a proper questionnaire
is designed for the interview.

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

3. 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 participant prepares his/her list, different lists are then combined, redundant (duplicate) entries are
eliminated, team is divided into smaller sub-teams to develop mini-specifications, a list of issues is also
prepared to be discussed and finally a draft of specifications is written down using all the inputs from the
meeting.

4. Quality Function Deployment (QFD):

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 –

1. Identify all the stakeholders, eg. Users, developers, customers etc

2. List out all requirements from customers.
3. A value indicating degree of importance is assigned to each requirement on a scale of 1 to 5:
 ○ 5 points: Very important
○ 4 points: Important
○ 3 points: Not Important, but nice to have
○ 2 points: Not Important
○ 1 point: Unrealistic, requires further exploration
4. In the end the final list of requirements is categorized as –
○ It is possible to achieve
○ It should be deferred (postpone) and the reason for it
○ It is impossible to achieve and should be dropped off

5. 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 includes three major things – Actor, Use cases, use case diagram.

1. 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.
2. 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.
3. 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.
Requirements Analysis: It consists of the following 4 steps:

(i) Draw the context diagram: The context diagram is a simple model that defines the boundaries and interfaces of the
proposed systems with the external world. It identifies the entities outside the proposed system that interact with the system.
The context diagram of student result management system is given below:

(ii) Development of a Prototype: the prototype helps the client to visualize the proposed system and increase the
understanding of the requirements. We can use their feedback to modify the prototype until the customer is satisfied
continuously.
(iii) Model the requirements: This process usually consists of various graphical representations of the functions, data
entities, external entities, and the relationships between them. The graphical view may help to find incorrect, inconsistent,
missing, and superfluous requirements. Such models include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries etc.

(iv) Finalise the requirements: After modeling the requirements, now we finalize the analyzed requirements, and the next
step is to document these requirements in a prescribed format.

Data Flow Diagrams:

DFDs show the flow of data through the system.

Few observations about DFDs:

--All names should be unique
-- It is not a flow chart
-- Suppress logical decisions
-- Defer error conditions & handling until the end of the analysis
Levels in Data Flow Diagrams (DFD) / Leveling
DFD represents a system or software at any level of abstraction.

LEVELLING

0-level DFD:

It is also known as fundamental system model, or context diagram represents the entire software requirement as a single
bubble with input and output data denoted by incoming and outgoing arrows.
1-level DFD

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this level, we highlight the main
objectives of the system and breakdown the high-level process of 0-level DFD into subprocesses.
2-Level DFD

A 2-level DFD goes one process deeper into parts of a 1-level DFD. It can be used to project or record the specific/necessary
detail about the system's functioning.
Data Dictionaries
A data dictionary is a file or a set of files that includes a database's metadata. The data dictionary holds

records about other objects in the database, such as data ownership, data relationships to other objects, and

other data.

The data dictionary, in general, includes information about the following:

● Name of the data item

● Aliases (ANOTHER NAME)

● Description/purpose

● Related data items

● Range of values

● Data structure definition/Forms

The name of the data item is self-explanatory.

Aliases include other names by which this data item is called DEO for Data Entry Operator and DR for

Deputy Registrar.

Description/purpose is a textual description of what the data item is used for or why it exists.

Related data items capture relationships between data items e.g., total_marks must always equal to

internal_marks plus external_marks.

Range of values records all possible values, e.g. total marks must be positive and between 0 to 100.

Data structure Forms: Data flows capture the name of processes that generate or receive the data items. If

the data item is primitive, then data structure form captures the physical structures of the data item. If the

data is itself a data aggregate, then data structure form capture the composition of the data items in terms of

other data items.

The mathematical operators used within the data dictionary are defined in the table:
Entity-Relationship Diagrams

ER-modeling is a data modeling method used in software engineering to produce a conceptual data model of

an information system. Diagrams created using this ER-modeling method are called Entity-Relationship

Diagrams or ER diagrams or ERDs.

Purpose of ERD

● The database analyst gains a better understanding of the data to be contained in the database

through the step of constructing the ERD.

● The ERD serves as a documentation tool.

● Finally, the ERD is used to connect the logical structure of the database to users. In particular, the

ERD effectively communicates the logic of the database to users.

Components of an ER Diagrams
1. Entity
An entity can be a real-world object, either animate or inanimate, that can be merely identifiable. An entity

is denoted as a rectangle in an ER diagram. For example, in a school database, students, teachers, classes,

and courses offered can be treated as entities. All these entities have some attributes or properties that give

them their identity.

Entity Set

An entity set is a collection of related types of entities. An entity set may include entities with attribute

sharing similar values. For example, a Student set may contain all the students of a school; likewise, a

Teacher set may include all the teachers of a school from all faculties. Entity set need not be disjoint.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have values. For example, a

student entity may have name, class, and age as attributes.

There exists a domain or range of values that can be assigned to attributes. For example, a student's name
cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc.

There are five types of Attributes:

1. Key attribute

2. Composite attribute

3. Single-valued attribute

4. Multi-valued attribute

5. Derived attribute

1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity among the

entity set. For example, the roll_number of a student makes him identifiable among students.

There are mainly three types of keys:

1. Super key: A set of attributes that collectively identifies an entity in the entity set.

2. Candidate key: A minimal super key is known as a candidate key. An entity set may have more
 than one candidate key.

3. Primary key: A primary key is one of the candidate keys chosen by the database designer to

uniquely identify the entity set.

2. Composite attribute: An attribute that is a combination of other attributes is called a composite attribute.

For example, In a student entity, the student address is a composite attribute as an address is composed of

other characteristics such as pin code, state, country.

3. Single-valued attribute: Single-valued attribute contains a single value. For example,

Social_Security_Number.

4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a multi-valued

attribute. Multi-valued attributes are depicted by the double ellipse. For example, a person can have more

than one phone number, email-address, etc.

5. Derived attribute: Derived attributes are the attribute that does not exist in the physical database, but

their values are derived from other attributes present in the database. For example, age can be derived from

date_of_birth. In the ER diagram, Derived attributes are depicted by the dashed ellipse.
3. Relationships
The association among entities is known as relationship. Relationships are represented by the diamond-

shaped box. 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 a similar type is known as a relationship set. Like entities, a relationship too can

have attributes. These attributes are called descriptive attributes.

Degree of a relationship set

The number of participating entities in a relationship describes the degree of the relationship. The three most

common relationships in E-R models are:

 1. Unary (degree1)

2. Binary (degree2)

3. Ternary (degree3)

1. Unary relationship: This is also called recursive relationships. It is a relationship between the instances

of one entity type. For example, one person is married to only one person.

2. Binary relationship: It is a relationship between the instances of two entity types. For example, the

Teacher teaches the subject.

3. Ternary relationship: It is a relationship amongst instances of three entity types. In fig, the relationships

"may have" provide the association of three entities, i.e., TEACHER, STUDENT, and SUBJECT. All three

entities are many-to-many participants. There may be one or many participants in a ternary relationship.

In general, "n" entities can be related by the same relationship and is known as n-ary relationship.
Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with the number of

entities of other sets via relationship sets.

Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of entity set B and vice

versa. Let us assume that each student has only one student ID, and each student ID is assigned to only one

person. So, the relationship will be one to one.

Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with more than one instance of another

entity then it is called one to many relationships. For example, a client can place many orders; an order

cannot be placed by many customers.

Using Sets, it can be represented as:

3. Many to One: More than one entity from entity set A can be associated with at most one entity of entity

set B, however an entity from entity set B can be associated with more than one entity from entity set A. For

example - many students can study in a single college, but a student cannot study in many colleges at the

same time.

Using Sets, it can be represented as:

4. Many to Many: One entity from A can be associated with more than one entity from B and vice-versa.

For example, the student can be assigned to many projects, and a project can be assigned to many students.

Using Sets, it can be represented as:

Approaches to problem analysis:

1. List all inputs, outputs and functions.

2. List all functions and then list all inputs and outputs associated with each function.

Structured requirements definition (SRD)

Step1 Define a user level DFD / ERD / DD. Record the inputs and outputs for each individual in a DFD /

ERD / DD.

Step2 Define a combined user level DFD / ERD / DD.

Step3 Define application level DFD / ERD / DD.

Step4 Define application level functions.

Decision table
It is a brief visual representation for specifying which actions to perform depending on given
conditions. 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.
A decision table is a good way to settle with different combination inputs with their corresponding
outputs and also called the cause-effect table. Reason to call a cause-effect table is a related logical
diagramming technique called cause-effect graphing that is basically used to obtain the decision table.

Importance of Decision Table:

1. Decision tables are very much helpful in test design technique.
2. It helps testers to search the effects of combinations of different inputs and other software
states that must correctly implement business rules.
3. It provides a regular way of stating complex business rules, that is helpful for developers as
well as for testers.
4. It assists in the development process with developers to do a better job.
5. A decision table is basically an outstanding technique used in both testing and requirements
 management.
6. It is a structured exercise to prepare requirements when dealing with complex business
rules.
7. It is also used to model complicated logic.

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. Any complex business flow can be easily converted into the test scenarios & test cases
using this technique.
2. Decision tables work iteratively that means the table created at the first iteration is used as
an input table for next tables. The iteration is done only if the initial table is not
satisfactory.
3. Simple to understand and everyone can use this method to design the test scenarios & test
cases.
4. It provides complete coverage of test cases which help to reduce the rework on writing test
scenarios & test cases.
5. These tables guarantee that we consider every possible combination of condition values.
This is known as its completeness property.

Requirements Documentation
This is a very important activity after requirements elicitation and analysis. Requirements document is called Software
Requirements Specification (SRS).

SRS is a specification for a particular software product, program or set of programs that performs certain functions in a
specific environment.

Parts / Components of a SRS document

The important parts of SRS document are:

1. Functional requirements of the system

2. Non-functional requirements of the system
3. Goals of implementation

1. Functional requirements describe the functions that the software is to execute. They are sometimes known as

capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can

be written to validate its behavior.

2. Non-functional Requirements: This can be the necessities that specify the criteria that can be used to decide the

operation instead of specific behaviors of the system, such as :

● reliability issues,
● performance issues,
● human - computer interface issues,
● interface with other external systems,
● security
● maintainability of the system

3. Goals of implementation:-
The goals of the implementation section might document issues such as:
● revisions to the system functionalities that may be required in the future,
● new devices to be supported in the future,
● reusability issues, etc.

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

1. Functionality: What the software is supposed to do?

2. External Interfaces: How does the software interact with people, system's hardware, other hardware and
other software?
3. Performance: What is the speed, availability, response time, recovery time etc.
4. Attributes: What are the considerations for portability, correctness, maintainability, security, reliability etc.
5. Design Constraints Imposed on an Implementation: Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, operating environment etc.

Goals of SRS:
● Provide feedback to the customer, ensuring that the IT company understands the issues the software system
should solve and how to address those issues.
● Help to break a problem down into smaller components just by writing down the requirements.
 ● Speed up the testing and validation processes.
● Facilitate reviews.

Since SRS has a specific role to play in software development process, SRS writer should be
careful for following points :

1. SRS should correctly define all the software requirements. A software requirement may exist because of the nature of
the task to be solved or because of a specific characteristic of the project.
2. SRS should not describe any design or implementation details. These should be described in the design stage of the
project.
3. SRS should not impose additional constraints on the software. These are properly specified in other documents such
as software quality assurance plan.

Therefore, a properly written SRS limits the range of valid designs but does not specify any particular design.

Following are the characteristics of a good SRS document:

Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be correct if it covers all
the requirements that are actually expected from the system.
Completeness:
Completeness of SRS indicates every sense of completion including the numbering of all the pages, resolving the to be
determined parts to as much extent as possible as well as covering all the functional and non-functional requirements
properly.

Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements. Examples of
conflict include differences in terminologies used at separate places, logical conflicts like time period of report
generation, etc.
Unambiguousness:
A SRS is said to be unambiguous if all the requirements stated have only 1 interpretation. Some of the ways to prevent
unambiguousness include the use of modelling techniques like ER diagrams, proper reviews and buddy checks, etc.

Ranking for importance and stability:

There should be a criterion to classify the requirements as less or more important or more specifically as desirable or
essential. An identifier mark can be used with every requirement to indicate its rank or stability.

Modifiability:
SRS should be made as modifiable as possible and should be capable of easily accepting changes to the system to some
extent. Modifications should be properly indexed and cross-referenced.

Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably measure the extent to which every requirement is
met by the system. For example, a requirement stating that the system must be user-friendly is not verifiable and listing
such requirements should be avoided.

Traceability:
One should be able to trace a requirement to design components and then to code segments in the program. Similarly,
one should be able to trace a requirement to the corresponding test cases.

Design Independence:
There should be an option to choose from multiple design alternatives for the final system. More specifically, the SRS
should not include any implementation details.

Testability:
A SRS should be written in such a way that it is easy to generate test cases and test plans from the document.
Understandable by the customer:
An end user may be an expert in his/her specific domain but might not be an expert in computer science. Hence, the use
of formal notations and symbols should be avoided to as much extent as possible. The language should be kept easy and
clear.

Right level of abstraction:

If the SRS is written for the requirements phase, the details should be explained explicitly. Whereas, for a feasibility
study, fewer details can be used. Hence, the level of abstraction varies according to the purpose of the SRS.

Problems without a SRS document

• The important problems that an organization would face if it does not develop an SRS document are as follows:

Without developing the SRS document, the system would not be implemented according to customer needs.

Software developers would not know whether what they are developing is exactly required by the customer.

Without an SRS document, it will be very much difficult for the maintenance engineers to understand the functionality
of the system.

It will be very much difficult for user document writers to write the users’ manuals properly without understanding the
SRS document.

Problems with an unstructured specification:

• It would be very much difficult to understand that document.

• It would be very much difficult to modify that document.
• Conceptual integrity in that document would not be shown.
• The SRS document might be ambiguous and inconsistent.

SRS Template IEEE - Given as Separate Document

1. Purpose
2. Introduction
3. Scope
4. S/w & H/w requirements
5. Functional & Non-Functional Requirements
6. SDLC model
7. Various Diagrams - Use case, ER, DFD, DD, Activity, Sequence, Class, Flow Charts
8. Screenshots
 9. References

Software Requirements Validation:

It certifies that the requirements document is an acceptable description of the system to be implemented
Checks a requirements document for:
• Completeness and consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements

Validation Process:

Validation inputs
1. Requirements document - Should be a complete version of the document, not an unfinished draft. Formatted and
organized according to organizational standards
2. Organizational knowledge - Knowledge, often implicit, of the organization which may be used to judge the
realism of the requirements
3. Organizational standards - Every organization should have some quality standards for SRS documents and other
activities. These standards will be used for reviewing during validation.

Validation outputs

1. Problem list - List of discovered problems in the requirements document.

2. Agreed / Acceptable actions - List of agreed or acceptable actions in response to requirements problems. Some
problems may have several corrective actions; some problems may have no associated actions

Validation Techniques: 1. Review 2. Prototyping

 1. Requirements reviews - A group of people read and analyze the requirements, look for problems, meet and
discuss the problems and agree on actions to address these problems

Review activities
1. Plan review - The review team is selected and a time and place for the review meeting is chosen.
2. Distribute documents - The requirements document is distributed to the review team members
3. Prepare for review - Individual reviewers read the requirements to find conflicts, omissions, inconsistencies,
deviations from standards and other problems.
4. Hold review meeting - Individual comments and problems are discussed and a set of actions to address the
problems is agreed.
5. Follow-up actions - The chair of the review checks that the agreed actions have been carried out.
6. Revise document - The requirements document is revised to reflect the agreed actions. At this stage, it may be
accepted or it may be re-reviewed.

Problem actions
1. Requirements clarification - The requirement may be badly expressed or may have accidentally omitted
information which has been collected during requirements elicitation.
2. Missing information - Some information is missing from the requirements document. It is the responsibility of
the requirements engineers who are revising the document to discover this information from system
stakeholders.
3. Requirements conflict - There is a significant conflict between requirements. The stakeholders involved must
negotiate to resolve the conflict.
4. Unrealistic requirement - The requirement does not appear to be implementable with the technology available or
given other constraints on the system. Stakeholders must be consulted to decide how to make the requirement
more realistic.

Review checklists
1. Understandability - Can readers of the document understand what the requirements mean?
2. Redundancy - Is information unnecessarily repeated in the requirements document?
3. Completeness - Does the checker know of any missing requirements or is there any information missing from
individual requirement descriptions?
4. Ambiguity - Are the requirements expressed using terms which are clearly defined? Could readers from
different backgrounds make different interpretations of the requirements?
 5. Consistency - Do the descriptions of different requirements include contradictions? Are there contradictions
between individual requirements and overall system requirements?
6. Organization / Structuring - Is the document structured in a sensible way? Are the descriptions of requirements
organized so that related requirements are grouped?
7. Conformance to standards - Does the requirements document and individual requirements conform to defined
standards? Are departures from the standards, justified?
8. Traceability - Are requirements unambiguously identified, include links to related requirements and to the
reasons why these requirements have been included?
2. Prototyping -
1. Prototypes for requirements validation demonstrate the requirements and help stakeholders discover problems
2. Validation prototypes should be complete, reasonably efficient and robust. It should be possible to use them in
the same way as the required system
3. User documentation and training should be provided.

Requirements Management
It is the process of understanding and controlling changes to system requirements. Most of the time, requirements are
dependent on each other. Hence, one change may have implications on other dependent requirements and thus make the
task much more difficult and challenging.

ENDURING & VOLATILE REQUIREMENTS

o Enduring requirements: They are core requirements & are related to main activity of the organization. Example: For a
library management system, issue/return of a book, cataloging are core activities.

o Volatile requirements: These requirements are likely to change during software development life cycle (SDLC) or
even after delivery of the product. There are many reasons for such changes:
● Changes to the environment
● Changes in technology
● Changes in policy
● Changes in customer’s expectations

Requirements Change Management

The requirements change process should include the following activities to be carried out when a change is
needed in the requirement.

● Allocating adequate resources - Assignment of responsibilities

● Analysis of requirement changes - management of changes
● Documenting requirements - Documentation
● Requirements traceability - Creating requirements traces throughout the project life cycle from inception to the
final work products
● Establishing team communication - communication of change
● Establishment of baseline for requirements specification
 Unit 2
Software Quality Assurance (SQA)

● Software Quality Assurance (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 suitable for the project and
implemented correctly.

● 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 an Umbrella activity that is applied throughout the software process.

Software Quality Assurance Plan

The software quality assurance plan comprises the procedures, techniques, and tools that are employed to make
sure that a product or service aligns with the requirements defined in the SRS (software requirement specification).

Major Software Quality Assurance Plan Activities:

1. SQA Management Plan:
Make a plan how you will carry out the SQA throughout the project. Think which set of software
engineering activities are the best for a project.
2. Set The Check Points:
SQA team should set checkpoints. Evaluate the performance of the project on the basis of collected data on
different checkpoints.
3. Apply software Engineering Techniques:
Applying some software engineering techniques aids a software designer in achieving high-quality
specification. For example, after gathering information, the software designer can prepare the project
estimation using techniques like WBS (work breakdown structure), SLOC (source line of codes), and
FP(functional point) estimation.
4. Executing Formal Technical Reviews:
In this process, a meeting is conducted with the technical staff to discuss the actual quality requirements of
the software and the design quality of the prototype. This activity helps in detecting errors in the early
phase of SDLC and reduces rework effort in the later phases.
 5. Multi testing Strategy:
Do not depend on a single testing approach. When you have a lot of testing approaches available, use them.

6. Enforcing Process Adherence:

This activity insists the need for process adherence during the software development process. The
development process should also stick to the defined procedures.
This activity is a blend of two sub-activities which are explained below:
(i) Product Evaluation:
This activity confirms that the software product is meeting the requirements that were discovered in the
project management plan. It ensures that the set standards for the project are followed correctly.
(ii) Process Monitoring:
This activity verifies if the correct steps were taken during software development. This is done by matching
the actually taken steps against the documented steps.

7. Controlling Change:
In this activity, we use a mix of manual procedures and automated tools to have a mechanism for change control.
By validating the change requests, evaluating the nature of change and controlling the change effect, it is ensured
that the software quality is maintained during the development and maintenance phases.

8. Measure Change Impact:

The changes for making the correction of an error sometimes re introduces more errors. So, keep the measure of
impact of change on the project. Reset the new change to check the compatibility of this fix with the whole
project.

9. Performing SQA Audits:

The SQA audit inspects the entire actual SDLC process followed by comparing it against the established process. It
also checks whatever reported by the team in the status reports were actually performed or not. This activity also
exposes any non-compliance issues.

10. Maintaining Records and Reports:

It is crucial to keep the necessary documentation related to SQA and share the required SQA information with the
stakeholders. The test results, audit results, review reports, change requests documentation, etc. should be kept for
future reference.
11. Manage Good Relations:
In the working environment managing the good relation with other teams involved in the project development is
mandatory. Bad relation of the SQA team with the programmers team will impact directly and badly on the project.
Don’t play politics.

The SQA plan document consists of the below sections:

1. Purpose section
2. Reference section
3. Software configuration management section
4. Problem reporting and corrective action section
5. Tools, technologies and methodologies section
6. Code control section
7. Records: Collection, maintenance and retention section
8. Testing methodology

Quality Assurance

Quality assurance can be defined as "part of quality management focused on providing confidence that quality requirements
will be fulfilled." The confidence provided by quality assurance is twofold—internally to management and externally to
customers, government agencies, regulators, certifiers, and third parties. An alternate definition is "all the planned and
systematic activities implemented within the quality system that can be demonstrated to provide confidence that a product or
service will fulfill requirements for quality."

Quality Control

Quality control can be defined as "part of quality management focused on fulfilling quality requirements." While quality
assurance relates to how a process is performed or how a product is made, quality control is more the inspection aspect of
quality management. An alternate definition is "the operational techniques and activities used to fulfill requirements for
quality."

Quality Assurance (QA) Quality Control (QC)

It focuses on providing assurance that quality

It focuses on fulfilling the quality requested.
requested will be achieved.
It is the technique of managing quality. It is the technique to verify quality.

It always includes the execution of the

It does not include the execution of the program.
program.

It is a managerial tool. It is a corrective tool.

It is process oriented. It is product oriented.

The aim of quality assurance is to prevent the The aim of quality control is to identify and
defects. improve the defects.

It is a preventive technique. It is a corrective technique.

It is a proactive measure. It is a reactive measure.

It is responsible for full software development life It is responsible for software testing life
cycle. cycle.

Example: Verification Example: Validation

Verification and Validation is the process of investigating that a software system satisfies specifications and
standards and it fulfills the required purpose. Barry Boehm described verification and validation as the following:

Verification: Are we building the product right?

Validation: Have we built the right product?

Verification is the process of evaluating a system or component to determine whether the products of a given
development phase satisfy the conditions imposed at the start of that phase.
Validation is the process of evaluating a system or component during or at the end of the development process to
determine whether it satisfies the specified requirements .

Verification Validation

It includes checking documents, design, It includes testing and validating the actual
codes and programs. product.

Verification is static testing. Validation is the dynamic testing.

It does not include the execution of the
It includes the execution of the code.
code.

Methods used in verification are reviews, Methods used in validation are Black Box
walkthroughs, inspections and desk- Testing, White Box Testing and non-functional
checking. testing.

It checks whether the software meets the

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

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

The goal of verification is application and

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

Quality assurance team does verification. Quality control team does validation.

It comes before validation. It comes after verification.

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

is performed by humans. performed by tools.