UNIT 2

Software Requirement
Specification
Topics to be covered
• What are Software Requirements? Types of S/W Requirements.
• Requirement Engineering Process: Elicitation, Analysis, Documentation,
Review and Management of User Needs, Feasibility Study
• Information Modelling,
• Data Flow Diagrams,
• Entity Relationship Diagrams,
• Decision Tables,
• SRS Document,
• IEEE Standards for SRS.
• Software Quality Assurance (SQA): Verification and Validation, SQA Plans,
Software Quality Frameworks, ISO 9000 Models, SEI-CMM Model.
Classification of Software
Requirements
• According to IEEE standard 729, a requirement is defined as follows:
• A condition or capability needed by a user to solve a problem or achieve an
objective
• A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification or other
formally imposed documents
• A documented representation of a condition or capability as in 1 and 2.
• A software requirement can be of :
• Functional requirements
• Non-functional requirements
• Interface Requirements
• Inverse Requirements
• Design and Constraints Requirements
Functional Requirements
• These are the requirements that the end user specifically demands as
basic facilities that the system should offer.
• All these functionalities need to be necessarily incorporated into the
system as a part of the contract.
• These are represented or stated in the form of input to be given to the
system, the operation performed, and the output expected.
• They are basically the requirements stated by the user which one can
see directly in the final product, unlike the non-functional requirements.
• Each high-level functional requirement may involve several interactions
or dialogues between the system and the outside world. In order to
accurately describe the functional requirements, all scenarios must be
enumerated.
• There are many ways of expressing functional requirements e.g., natural
language, a structured or formatted language with no rigorous syntax
and formal specification language with proper syntax.
Non-Functional Requirements
• These are basically the quality constraints that the system must satisfy
according to the project contract. The priority or extent to which these
factors are implemented varies from one project to other. They are also
called non-behavioral requirements.
They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Non-Functional Requirements
• NFR’s are classified into following types:
• Interface constraints
• Performance constraints: response time, security, storage space, etc.
• Operating constraints
• Life cycle constraints: maintainability,
Click to add text portability, etc.
• Economic constraints
• The process of specifying non-functional requirements requires the knowledge
of the functionality of the system, as well as the knowledge of the context
within which the system will operate.
Difference between Functional Requirement
and Non-functional Requirement
Interface Requirements
•Systems must operate with other systems and the operating interfaces must be specified as
part of requirements. It includes:
1. User Interface
2. Communication Interface
3. Software Interface
4. Hardware Interface
1. User Interface: Describe the logical characteristics of each user interface that the system
needs. Example includes GUI, CLI (Command line Interface), API (Application Program
Interface) etc.
2. Communication Interface: State the requirements for any communication functions the
product will use, including e-mail, Web browser, network communications protocols, and
electronic forms. Define any pertinent message formatting. Specify communication security
or encryption issues, data transfer rates, and synchronization mechanisms.
Interface Requirements
3. Software Interface: Describe the connections between this product and other software components
(identified by name and version), including databases, operating systems, tools, libraries, and
integrated commercial components. State the purpose of the messages, data, and control items
exchanged between the software components. Describe the services needed by external software
components and the nature of the inter-component communications. Identify data that will be shared
across software components. If the data-sharing mechanism must be implemented in a specific way,
such as a global data area, specify this as a constraint.
4. Hardware Interface: Describe the characteristics of each interface between the software and
hardware components of the system. This description might include the supported device types, the
data and control interactions between the software and the hardware, and the communication
protocols to be used.
Interface Requirements
5. Inverse Requirements
•Inverse requirements specify the constraints on allowable behavior. Software safety and security
requirements are usually stated in this manner. Inverse requirements can be functional and
nonfunctional. For example: When a customer specifies that something must not be done. For
example, User ID should only contain digits.
Design and Implementation
Requirements
6. Design and Implementation Requirements

Design constraints and implementation constraints are boundary conditions on how the required
software is to be constructed and implemented. Examples of design constraints include the fact that
the software must run using a certain database system or that the software must fit into the
memory of a 512 Kbyte machine.
WORST NIGHTMARE:A Customer walks into your office , sits
down, looks you straight in the eye, and says, “I know you
think you understand what I said, but what you don’t
understand is what I said is not what I mean”

If my nightmare becomes true then……

Reputation is on stake…
Hard earned Money will go….

What shall I do!!!!

Solution: REQUIREMENT ENGINEERING
Quick look
What is it?
Set of tasks that lead to proper definition of project requirements
Who does it?
Software engineer/System engineer/Analyst. Manager, Customer, end-users can act as
participants
Why is it important?
To avoid aforementioned nightmares 
What are the steps?
(7 steps) Inception---Elicitation---Elaboration----Negotiation---Specification—Validation
—Requirements Management
What is the work product?
Many documents explaining user scenarios, functions and features list, analysis model,
specification
How do I ensure that I have done it right?
By getting it reviewed.
Requirement engineering steps
IEEE format for SRS
1. Introduction
• 1.1. Purpose
• 1.2. Scope
• 1.3. Definitions, acronyms & abbreviations
• 1.4. References
• 1.5. Overview
• 2. Overall description
• 2.1.Product perspective
• 2.1.1. System interfaces
• 2.1.2. User interfaces
• 2.1.3. Hardware interfaces
IEEE format for srs
• 2.1.4. Software interfaces
• 2.1.5. Communications interfaces
• 2.1.6. Memory constraints
• 2.1.7. Operations
• 2.1.8. Site adaptation requirements
• 2.2. Product functions
• 2.3. User characteristics
• 2.4. Constraints
• 2.5. Assumptions and dependencies
• 2.6. Apportioning of requirements
IEEE format for srs
• 3. Specific Requirements
• 3.1 External interface requirements
• 3.1.1 User interfaces
• 3.1.2 Hardware interfaces
• 3.1.3 Software interfaces
• 3.1.4 Communication interfaces
• 3.2 Specific requirements
• 3.2.1 Sequence diagrams
• 3.2.2 Classes for classification of specific requirements
IEEE format for srs
• 3.3 Performance requirements
• 3.4 Design constraints
• 3.5 Software system attributes
• 3.5.1 Reliability
• 3.5.2 Availability
• 3.5.3 Security
• 3.5.4 Maintainability
• 3.6 Other requirements
• 4. Supporting information
• 4.1 Table of contents and index
• 4.2 Appendixes
Feasibility Study

• Traditional Engineering Feasibility Study

• Traditional engineering designs, e. g., building as bridge, go through distinct
phases:
• The feasibility study.
• The preliminary design.
• The detailed design.
The feasibility study is an investigation that results in a written document that:
• Defines the scope of the problem.
• Identifies the elements of the problem.
• Identifies the evaluative criteria. Possible criteria include: the impact on
the environment, safety and manufacturability; the political climate; the
possible difficulties in the design phase; and appraisal of the return
(profit) on investment.
• Identifies possible alternative solutions.
• Evaluate each solution with the criteria
Software Engineering Feasibility Study
• Software developers have learned that the traditional engineering feasibility
study is not usually appropriate for software development. For example, software
rarely has impact on the environment in the same manner as a chemical plant.
Manufacturability is usually a non-issue. How much does it cost to copy a
diskette? Therefore, software companies have developed their own variety of the
feasibility study.
• From painful experience, managers of software development find scarcity of
resources (all kinds including human, hardware and software) and difficult
delivery dates to be two critical reasons for the failure of a project.
“All projects are feasible -- given unlimited resources and infinite time!
Unfortunately, the development of a computer-based system or product is more
likely plagued by a scarcity of resources and difficult (if not downright unrealistic)
delivery dates. It is both necessary and prudent to evaluate the feasibility of a
project at the earliest possible time. Months or years of effort, thousands of
millions of dollars, and untold professional embarrassment can be averted if an ill-
conceived system is recognized early in the definition phase." Pressman
• The feasibility of a project is related to the risks involved.
Software Engineering Feasibility Study
• In a feasibility study, Pressman states we need to concentrate our attention
on four primary areas of interest:
• Economic feasibility. An evaluation of development cost weighed against
the ultimate income or benefit derived from the developed system or
product.
• Technical feasibility. A study of function, performance, and constraints that
may affect the ability to achieve an acceptable system.
• Legal feasibility. A determination of any infringements, violation, or liability
that could result from development of the system.
• Alternatives. An evaluation of alternative approaches to the development
of the system or product.
• The feasibility study results in a written document called the Feasibility
Report
 Feasibility Report Outline
• Cover Sheet

• Executive Summary - Management Summary and Recommendations

A summary of important findings and recommendations for further system development. Should be maximum of one page
and self contained, i. e., no references to tables or figures.
• Introduction
A brief statement of the problem, the computing environment in which the system is to be implemented and constraints
that affect the project. The scope of the problem should be defined.
• Background
Discuss what others have done in relation to the problem. Define terms and other information which will be needed as
background in order for the reader to understand the report.
• Alternatives
A presentation of alternative system configurations; state the criteria that were used in selecting the final approach.
• System Description
An abbreviated statement of scope of the system. Feasibility of allocated elements.
• Cost-Benefit Analysis
An economic justification for the system.
• Evaluation of Technical Risk
A presentation of technical feasibility.
Information(requirement) Modeling
• Information modeling is a technique for specifying the data
requirements that are needed within the application domain.
• Following are the requirement modeling strategies:
1. Flow Oriented Modeling :It shows how data objects are
transformed by processing the function. These are:
• Data flow model
• Use-case diagrams
• State Diagrams
• Activity Diagrams
2. Class-based Modeling
 E-R Diagram
 Class Diagram
Use Case Approach
• Given by Ivar Jacobson
• Initially use case were developed for Object Oriented Software
Development world, however they can be applied to any project.
• Use Cases describe ‘what’ of a system with the help of a combination
of text and pictures
• They only give functional view/requirement of the system.
• Each use case represents a discrete goal for the user
Use Case Diagrams
• Use Case Diagrams provide a visual way to document user goals and
explore possible functionality
• Three primary modeling components:
• Actors
• Use Cases
• Relationship between actors and use case and/or between the use cases
Actor
• Actors are people or external systems that need to interact with our system

Finding Actors

 Who or what will use the main functionality of the system?

 Who or what will provide input to this system?
 Who or what will use output from this system?
 Who will need support from the system to do their work?
 Are there any other software systems with which this one needs to interact
 Are there any hardware devices used or controlled by this system?
How to identify use cases
• Ask these questions:
• What are the goals of actor(s)
• What are the main task /function performed by the actor(s)
• What system information actor desire from the system, change or
produce?
• Will the actor have to inform the system about the changes in the
external environment?
• Does the actor wish to be informed about unexpected changes?
Use Case of Student result
management system
Data Flow Diagram
• A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a
system. A neat and clear DFD can depict the right amount of the system requirement graphically.
It can be manual, automated, or a combination of both.
• It shows how data enters and leaves the system, what changes the information, and where data is
stored.
• The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be
used as a communication tool between a system analyst and any person who plays a part in the
order that acts as a starting point for redesigning a system. The DFD is also called as a data flow
graph or bubble chart.
Data Flow Diagram
• The following observations about DFDs are essential:
1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order of
events; arrows in DFD represents flowing data. A DFD does not involve any order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD,
suppress that urge! A diamond-shaped box is used in flow charts to represents decision points
with multiple exists paths of which the only one is taken. This implies an ordering of events,
which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling until the end
of the analysis.
Symbols used in DFD
Levels in Data Flow Diagrams (DFD)
• The DFD may be used to perform a system or software at any level of abstraction. Infact, DFDs
may be partitioned into levels that represent increasing information flow and functional detail.
Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily three levels in the data
flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.
0-level DFD
• It is also known as context diagram represents the entire software requirement as a single bubble
with input and output data denoted by incoming and outgoing arrows.
• Then the system is decomposed and described as a DFD with multiple bubbles.
• Parts of the system represented by each of these bubbles are then decomposed and documented
as more and more detailed DFDs.
• This process may be repeated at as many levels as necessary until the program at hand is well
understood.
• It is essential to preserve the number of inputs and outputs between levels, this concept is called
leveling by DeMacro. Thus, if bubble "A" has two inputs x1 and x2 and one output y, then the
expanded DFD, that represents "A" should have exactly two external inputs and one external
output as shown in fig:
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
• 2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or record
the specific/necessary detail about the system's functioning.
Questions
• Draw overall DFD for Issue/Return of a books in a library
Zero level DFD
ER model

• ER model stands for an Entity-Relationship model.

It is a high-level data model. This model is used to
define the data elements and relationship for a
specified system.
• It develops a conceptual design for the database. It
also develops a very simple and easy to design
view of data.
• In ER modeling, the database structure is
portrayed as a diagram called an entity-
relationship diagram.
• For example, Suppose we design a school database. In this
database, the student will be an entity with attributes like
address, name, id, age, etc. The address can be another entity
with attributes like city, street name, pin code, etc and there
will be a relationship between them.
Component of ER Diagram
• Entity: may be any object, class, person or place. (Rectangle)
• Weak Entity: An entity that depends on another entity called a weak entity.(double rectangle)
• Attribute: used to describe the property of an entity.(Eclipse)
• Key Attribute: represents a primary key.(ellipse with the text underlined.)
• Composite Attribute: attribute that composed of many other attributes (an ellipse connected with related
attribute ellipses)
• Multivalued Attribute: attribute having more than one value.(double oval)
• Derived Attribute: attribute that can be derived from other attribute.(dashed ellipse.)
• Relationship: describe the relation between entitie(s).(Diamond or rhombus)
• Types of relationship
• Unary
• Binary
• Ternary
• 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 set
• One-to-One: only one instance of an entity is associated with the relationship(1:1)
• One-to-many: only one instance of the entity on the left, and more than one instance of an entity
on the right associates with the relationship (1:N)
• Many-to-one: more than one instance of the entity on the left, and only one instance of an entity
on the right associates with the relationship (N:1)
• Many-to-many: more than one instance of the entity on the left, and more than one instance of an
entity on the right associates with the relationship (N:N)
E-R Model

• Entity
• Entity Type
• Entity Set
• 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.
• An Entity is an object of Entity Type and set of all entities is called as entity
set. e.g.; E1 is an entity having Entity Type Student and set of all students is
called Entity Set. In ER diagram, Entity Type is represented as:
E-R Model
• Attributes are the properties which define the entity type. For
example, Roll_No, Name, DOB, Age, Address, Mobile_No are the
attributes which defines entity type Student. In ER diagram, attribute is
represented by an oval.

• An attribute which uniquely identifies each entity in the entity set is

called key attribute. For example, Roll_No will be unique for each
student. In ER diagram, key attribute is represented by an oval with
underlying lines.

• The multi-valued attribute consisting more than one value for a given
entity. For example, Phone_No (can be more than one for a given
student). In ER diagram, multivalued attribute is represented by double
oval.
E-R Model
• An attribute composed of many other attribute is called as composite
attribute. For example, Address attribute of student Entity type consists of
Street, City, State, and Country. In ER diagram, composite attribute is
represented by an oval comprising of ovals.
E-R Model
• An attribute which can be derived from other attributes of the entity type
is known as derived attribute. e.g.; Age (can be derived from DOB). In ER
diagram, derived attribute is represented by dashed oval.

• The complete entity type Student with its attributes can be represented as:
Relationships in E-R Model
• 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: A unary relationship, also called recursive, is one in which a

relationship exists between occurrences of the same entity set. In this relationship, the
primary and foreign keys are the same, but they represent two entities with different roles.
Relationships in E-R Model
• Binary relationship: It is a relationship between the
instances of two entity types. For example, the Teacher
teaches the subject:
Relationships in E-R Model
• Ternary Relationships
• A ternary relationship is a relationship type that involves
many to many relationships between three tables.
Relationships in E-R Model
• 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 set.
• Types of Cardinalities
(i) 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.
Relationships in E-R Model
ii. One to Many: When a single instance of an entity is associated with more than one instances of
another entity then it is called one to many relationships. For example, a client can place many
orders; a order cannot be placed by many customers.
Relationships in E-R Model
ii. Many to Many : One entity from A can be associated with more than one entity
from B and vice-versa.
• Assume we have the following application that models soccer teams, the games they play, and
the players in each team. In the design, we want to capture the following:
• We have a set of teams, each team has an ID (unique identifier), name, main stadium, and to
which city this team belongs.
• Each team has many players, and each player belongs to one team. Each player has a number
(unique identifier), name, DoB, start year, and shirt number that he uses.
• Teams play matches, in each match there is a host team and a guest team. The match takes place
in the stadium of the host team.
• For each match we need to keep track of the following: o The date on which the game is played o
The final result of the match o The players participated in the match. For each player, how many
goals he scored, whether or not he took yellow card, and whether or not he took red card. o
During the match, one player may substitute another player. We want to capture this substitution
and the time at which it took place.
• Each match has exactly three referees. For each referee we have an ID (unique identifier), name,
DoB, years of experience. One referee is the main referee and the other two are assistant referee.
• Design an ER diagram to capture the above requirements. State any assumptions you have that
affects your design (use the back of the page if needed). Make sure cardinalities and primary keys
are clear.
Reference for ER Diagram
• Refer this link to model ER Diagram in Visual Paradigm:
• https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-
relationship-diagram/#:~:text=Cardinality,one%2Dto%2Dmany
%20relationship.
Decision Table
• Decision table 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.
• Decision tables specify:
• Which variables are to be tested
• What actions are to be taken if the conditions are true,
• The order in which decision making is performed.
• A Decision table is a table of rows and columns, separated into four quadrants and is
designed to illustrate complex decision rules
• Condition Stub – upper left quadrant
• Rules Stub – upper right quadrant
• Action Stub – bottom left quadrant
• Entries Stub - bottom right quadrant
Decision Table Layout
• Standard format used for presenting decision tables.

Condition
Stub Rules
Stub

Action Entries
Stub Stub
 Developing Decision Tables

• Process requires the determination of the number of conditions

(inputs) that affect the decision.
• The set of possible actions (outputs) must likewise be determined
• The number of rules is computed
• Each rule must specify one or more actions
Number of Rules
• Each condition generally has two possible alternatives (outcomes):
Yes or No
• In more advanced tables, multiple outcomes for each condition are permitted
• The total number of rules is equal to
• no. of condition1 values * no. of condition2 values
• If no of values for each condition is T/F, then 2 no. of conditions
• Thus, if there are four conditions, there will be sixteen possible rules
Constructing a Decision
Table
• PART 1. FRAME THE PROBLEM.
• Identify the conditions (decision criteria). These are the factors that will influence the decision.
• E.g., We want to know the total cost of a student’s tuition. What factors are important?
• Identify the range of values for each condition or criteria.
• E.g. What are they for each factor identified above?
• Identify all possible actions that can occur.
• E.g. What types of calculations would be necessary?
• PART 2. CREATE THE TABLE.
• Create a table with 4 quadrants.
• Put the conditions in the upper left quadrant. One row per condition.
• Put the actions in the lower left quadrant. One row per action.
• List all possible rules.
• Alternate values for first condition. Repeat for all values of second condition. Keep repeating
this process for all conditions.
• Put the rules in the upper right quadrant.
• Enter actions for each rule
• In the lower right quadrant, determine what, if any, appropriate actions should be taken for
each rule.
• Reduce table as necessary.
Example

• If you are a new customer and you want to open a

credit card account then there are three conditions
first you will get a 15% discount on all your purchases
today, second if you are an existing customer and you
hold a loyalty card, you get a 10% discount and third if
you have a coupon, you can get 20% off today (but it
can’t be used with the ‘new customer’ discount).
Discount amounts are added, if applicable.
Conditions Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6
New Y Y N N N N
Customer
(15%)

Loyality N N Y Y N N
Card (10%)

Coupon Y N Y N Y N
(20%)

ACTIONS
NO X
DISCOUN
T
20% X
15% X
30% X
10% X
20% X
Another Example
• In this example a company is trying to maintain a meaningful mailing
list of customers. The objective is to send out only the catalogs from
which customers will buy merchandise.
• The managers realize that certain loyal customers order from every
catalog and that some people on the mailing list never order. These
ordering patterns are easy to observe, but deciding which catalogs to
send customers who order only from selected catalogs is more difficult.
Once these decisions are made, a decision table is constructed for
three conditions (C1: customer ordered from Fall catalog; C2: customer
ordered from Christmas catalog; and C3: customer ordered from
specialty catalog), each having two alternatives (Y or N).
Solution
 Decision Table
For example: A bookstore get a trade discount of
25% for order more then 6 books; for order from
libraries and individuals, 5% allowed on orders
of 6-19 copies per book title; 10% on orders for
20-49 copies per book title; 15% on orders for 50
copies or more per book title.
Cleaning Things Up
• Check the table for any impossible situations, contradictions, and
redundancies and eliminate such rules

• Rewrite the decision table with the most reduced set of rules;
rearranging the rule order is permissible if it improves user
understanding
Decision Table example:
combine and reduce

Conditions and Actions 1 2 3 4 5 6 7 8

Order from Fall Catalog Y Y Y Y N N N N

Order from Christmas Catalog Y Y N N Y Y N N
Order from Special Catalog Y N Y N Y N Y N
Mail Christmas Catalog X X X X
Mail Special Catalog X X
Mail Both Catalogs X X

The four gray columns can In addition, Rules 1&5 and

be combined into a single Rules 3&7 can be combined.
rule. Note that four each, Each pair produces the same
there was NO order placed action and each pair shares two
from the Special Catalog. common conditions.
1 5 1&5 2 4 2&4 3 7 3&7 6 8 6&8

Y N Y Y Y N N N

Y Y Y N N N Y N

Y Y N N Y Y N N
1 5 1&5 2 4 2&4 3 7 3&7 6 8 6&8

Y N - Y Y Y Y N - N N N

Y Y Y Y N - N N N Y N -

Y Y Y N N N Y Y Y N N N
2&4 6&8 2,4,6 & 8
Y N -
- - -
N N N
X X X
 Conditions and Actions 1& 5 3 & 7 2,4 6,8

Order from Fall Catalog - - Y N

Order from Christmas Catalog Y N - -
Order from Special Catalog Y Y N N
Mail Christmas Catalog X X
Mail Special Catalog X
Mail Both Catalogs X

Conditions and Actions 1& 5 3 & 7 2,4,6,8

Order from Fall Catalog - - -

Order from Christmas Catalog Y - -
Order from Special Catalog Y Y N
Mail Christmas Catalog X
Mail Special Catalog X
Mail Both Catalogs X
Decision Table example ~ Final Version

Conditions and Actions 1 2 3

Order from Fall Catalog -- -- --

Order from Christmas Catalog Y -- N
Order from Special Catalog Y N Y
Mail Christmas Catalog X
Mail Special Catalog X
Mail Both Catalogs X

Eliminates the need to check for every possible case.

 Importance of Decision
Tables
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 development process with developer to do a better job. Testing with
all combination might be impractical.
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 in model complicated logic.
Software Quality Assurance
• Software quality assurance (SQA) is a process which assures
that all software engineering processes, methods, activities
and work items are monitored and comply against the
defined standards. These defined standards could be one or
a combination of any like ISO 9000, CMMI model etc.
• SQA incorporates all software development processes
starting from defining requirements to coding until release.
Its prime goal is to ensure quality.
Verification and validation
• Verification (ARE WE BUILDING THE PRODUCT RIGHT?)
• Definition: The process of evaluating software to determine
whether the products of a given development phase satisfy the
conditions imposed at the start of that phase.
• Verification will help to determine whether the software is of
high quality, but it will not ensure that the system is useful.
Verification is concerned with whether the system is well
engineered and error-free.
• Methods of Verification: Static Testing
•  Walkthrough
•  Inspection
• Review
Validation (ARE WE BUILDING THE
RIGHT PRODUCT?)
• Definition: The process of evaluating software during or at the end of
the development process to determine whether it satisfies specified
requirements.
• Validation is the process of evaluating the final product to check
whether the software meets the customer expectations and
requirements. It is a dynamic mechanism of validating and testing the
actual product.
• Methods of Validation: Dynamic Testing
•  Testing according to End Users
 Difference between Verification and
Validation
• The distinction between the two terms is largely to do with the role of
specifications.
• Verification is the process of checking that the software meets the
specification. “Did I build what I need?”
• Validation is the process of checking whether the specification
captures the customer’s
• needs. “Did I build what I said I would?”
Cases etc.
Verfication vs validation
Software Quality Assurance Plan
• The software quality assurance plan comprises of 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).
• 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
Software Quality Assurance (SQA)
Activities)
1. Creating an SQA Management Plan:
• This is the first activity of SQA Plan to do a proper planning for SQA will be carried out for project.
Along with what SQA approach are going to follow, what engineering activities will be carried out,
and it also includes ensuring about the team.
2. Setting the Checkpoints:
• The SQA team sets up different checkpoints according to which it evaluates the quality of the
project activities at each checkpoint/project stage. This ensures regular quality inspection and
working as per the schedule.
3. Apply software Engineering Techniques:
• Applying some software engineering techniques aids a software designer in achieving high-quality
specification. For gathering information, a designer may use techniques such as interviews and
FAST (Functional Analysis System Technique).
Software Quality Assurance (SQA)
Activities)
4. Executing Formal Technical Reviews:
• An FTR is done to evaluate the quality and design of the prototype. In this process, a meeting is
conducted with the technical staff to discuss regarding 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. Having a Multi- Testing Strategy:
• By multi-testing strategy, we mean that one should not rely on any single testing approach,
instead, multiple types of testing should be performed so that the software product can be tested
well from all angles to ensure better quality.
 Software Quality Assurance (SQA)
Activities)
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 in detail:
(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.
Software Quality Assurance (SQA)
Activities)
8. Measure Change Impact:
• If any defect is reported by the QA team, then the concerned team fixes the defect. After this,
the QA team should determine the impact of the change which is brought by this defect fix. They
need to test not only if the change has fixed the defect, but also if the change is compatible with
the whole project.
• For this purpose, we use software quality metrics which allows managers and developers to
observe the activities and proposed changes from the beginning till the end of SDLC and initiate
corrective action wherever required.
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.
Software Quality Assurance (SQA)
Activities)
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 fact, it is very important to maintain harmony between the QA and the development team.
• We often hear that testers and developers often feel superior to each other. This should be
avoided as it can affect the overall project quality.
 SQA Techniques

• Auditing: Auditing involves inspection of the work products and its related information to determine if the set
of standard processes were followed or not.
• Reviewing: A meeting in which the software product is examined by both the internal and external
stakeholders to seek their comments and approval.
• Code Inspection: It is the most formal kind of review that does static testing to find bugs and avoid defect
growth in the later stages. It is done by a trained mediator/peer and is based on rules, checklist, entry and
exit criteria. The reviewer should not be the author of the code.
• Design Inspection: Design inspection is done using a checklist that inspects the below areas of software
design:
• General requirements and design
• Functional and Interface specifications
• Conventions
• Requirement traceability
• Structures and interfaces
• Logic
• Performance
• Error handling and recovery
• Testability, extensibility
• Coupling and cohesion
SQA Techniques
• Simulation: Simulation is a tool that models the real-life situation in order to virtually examine
the behavior of the system under study.
• Functional Testing: It is a QA technique which verifies what the system does without
considering how it does. This type of black box testing mainly focuses on testing the system
specifications or features.
• Standardization: Standardization plays a crucial role in quality assurance. It decreases the
ambiguity and guesswork, thus ensuring quality.
• Static Analysis: It is a software analysis that is done by an automated tool without actually
executing the program. This technique is highly used for quality assurance in medical, nuclear
and aviation software. Software metrics and reverse engineering are some popular forms of
static analysis.
SQA Techniques
• Walkthroughs: Software walkthrough or code walkthrough is a kind of peer review where the
developer guides the members of the development team to go through the product and raise
queries, suggest alternatives, make comments regarding possible errors, standard violations or
any other issues.
• Path Testing: It is a white box testing techniques where the complete branch coverage is ensured
by executing each independent path at least once.
• Stress Testing: This type of testing is done to check how robust a system is by testing it under
heavy load i.e. beyond normal conditions.
• Six Sigma: Six Sigma is a quality assurance approach that aims at nearly perfect products or
services. It is widely applied in many fields including software. The main objective of six sigma is
process improvement so that the produced software is 99.76 % defect free.
(define,measure,analyse,improve,control
ISO
• ISO 9000 is defined as a set of international standards on quality management
and quality assurance developed to help companies effectively document the
quality system elements needed to maintain an efficient quality system.
• Refer this link: ISO .
• They are not specific to any one industry and can be applied to organizations of
any size.
• ISO 9000 can help a company satisfy its customers, meet regulatory
requirements, and achieve continual improvement.
• It should be considered as first step or the base level of a quality system.
The ISO Approach to Quality
Assurance Systems
• ISO 9000 describes the elements of a quality assurance system in general terms.
• These elements include the organizational structure, procedures, processes, and resources
needed to implement quality planning, quality control, quality assurance, and quality
improvement.
• However, ISO 9000 does not describe how an organization should implement these quality system
elements.
• Consequently, the challenge lies in designing and implementing a quality assurance system that
meets the standard and fits the company’s products, services, and culture.
 The ISO 9001 Standard
• ISO 9001 is the quality assurance standard that applies to software engineering.
• The standard contains 20 requirements that must be present for an effective quality assurance system.
• Because the ISO 9001 standard is applicable to all engineering disciplines, a special set of ISO guidelines have
been developed to help interpret the standard for use in the software process.
• The requirements defined by ISO 9001 address topics such as
• management responsibility,
• quality system,
• contract review,
• design control,
• document and data control,
• product identification and
• traceability,
• process control,
• inspection and testing,
• corrective and preventive action,
• control of quality records,
• internal quality audits,
• training, servicing, and
• statistical techniques.
The ISO 9001 Standard
• The software organization registered to ISO 9001, it must establish policies and procedures to
address each of the requirements just noted (and others) and then be able to demonstrate that
these policies and procedures are being followed.
• ISO/IEC (International Electrotechnical Commission) 9126 Software engineering — Product quality was an
international standard for the evaluation of software quality. It has been replaced by
ISO/IEC 25010:2011.
Capability Maturity Model
• CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in
1987.
• It is not a software process model. It is a framework which is used to analyze the approach
and techniques followed by any organization to develop a software product.
• It also provides guidelines to further enhance the maturity of those software products.
• It is based on profound feedback and development practices adopted by the most successful
organizations worldwide.
• This model describes a strategy that should be followed by moving through 5 different levels.
• Each level of maturity shows a process capability level. All the levels except level-1 are
further described by Key Process Areas (KPA’s).
Key Process Area
• Each of these KPA’s defines the basic requirements that should be met by a software process in
order to satisfy the KPA and achieve that level of maturity.
• Conceptually, key process areas form the basis for management control of the software project
and establish a context in which technical methods are applied, work products like models,
documents, data, reports, etc. are produced, milestones are established, quality is ensured, and
change is properly managed.
• The 5 levels of CMM are as follows:
• Initial
• Repeatable
• Defined
• Managed
• Optimized
Level-1: Initial
• No KPA’s defined.
• Processes followed are ad hoc and immature and are
not well defined.
• Unstable environment for software development.
• No basis for predicting product quality, time for
completion, etc.
Level-2: Repeatable
• Focuses on establishing basic project management policies.
• Experience with earlier projects is used for managing new similar natured projects.
• KPA’s:
• Project Planning- It includes defining resources required, goals, constraints, etc. for the
project. It presents a detailed plan to be followed systematically for successful completion of
a good quality software.
• Configuration Management- The focus is on maintaining the performance of the software
product, including all its components, for the entire lifecycle.
• Requirements Management- It includes the management of customer reviews and feedback
which result in some changes in the requirement set. It also consists of accommodation of
those modified requirements.
• Subcontract Management- It focuses on the effective management of qualified software
contractors i.e. it manages the parts of the software which are developed by third parties.
• Software Quality Assurance- It guarantees a good quality software product by following
certain rules and quality standard guidelines while development.
Level-3: Defined
• At this level, documentation of the standard guidelines and procedures takes place.
• It is a well-defined integrated set of project specific software engineering and management
processes.
• KPA’s:
• Peer Reviews- In this method, defects are removed by using several review methods like
walkthroughs, inspections, buddy checks, etc.
• Intergroup Coordination- It consists of planned interactions between different development
teams to ensure efficient and proper fulfilment of customer needs.
• Organization Process Definition- It’s key focus is on the development and maintenance of the
standard development processes.
• Organization Process Focus- It includes activities and practices that should be followed to
improve the process capabilities of an organization.
• Training Programs- It focuses on the enhancement of knowledge and skills of the team
members including the developers and ensuring an increase in work efficiency.
Level-4: Managed
• At this stage, quantitative quality goals are set for the organization for software products as well
as software processes.
• The measurements made help the organization to predict the product and process quality within
some limits defined quantitatively.
• KPA’s:
• Software Quality Management- It includes the establishment of plans and strategies to
develop a quantitative analysis and understanding of the product’s quality.
• Quantitative Management- It focuses on controlling the project performance in a quantitative
manner.
Level-5: Optimizing
• This is the highest level of process maturity in CMM and focuses on continuous process
improvement in the organization using quantitative feedback.
• Use of new tools, techniques and evaluation of software processes is done to prevent recurrence
of known defects.
• KPA’s:
• Process Change Management- Its focus is on the continuous improvement of organization’s
software processes to improve productivity, quality and cycle time for the software product.
• Technology Change Management- It consists of identification and use of new technologies to
improve product quality and decrease the product development time.
• Defect Prevention- It focuses on identification of causes of defects and to prevent them from
recurring in future projects by improving project defined process.
 ISO CMM

ISO 9000 is a set of international standards on quality

SEI (Software Engineering Institute), Capability Maturity Model
management and quality assurance developed to help
(CMM) specifies an increasing series of levels of a software
companies effectively document the quality system elements
development organization.
needed to an efficient quality system.

Focus on the software supplier to improve its interval processes

Focus is customer supplier relationship, attempting to reduce
to achieve a higher quality product for the benefit of the
customer’s risk in choosing a supplier.
customer.
It is created for hard goods manufacturing industries. It is created for software industry.
ISO9000 is recognized and accepted in most of the countries. SEICMM is used in USA, less widely elsewhere.
It specifies concepts, principles and safeguards that should be CMM provides detailed and specific definition of what is
in place. required for given levels.
This establishes one acceptance level. It assesses on 5 levels.
Its certification is valid for three years. It has no limit on certification.
It focuses on inwardly processes. It focus outwardly.
It has 5 levels:(a). Initial (b). Repeatable (c). Defined (d).
It has no level.
Managed (e). Optimized
It is basically an audit. It is basically an appraisal.
It is open to multi sector. It is open to IT/ITES.
Follow set of standards to make success repeatable. It emphasizes a process of continuous improvement.