Software Requirement Specification

(SRS)
(UNIT-2-part1)
Compiled By
Dr. Vandana Agarwal
 Requirement Engineering
• A systematic and strict approach to the
definition, creation and verification of
requirements for a software system is known
as requirements engineering.
• In order to guarantee the effective creation of
a software product, the requirements
engineering process entails a number of tasks
that help in understanding, recording and
managing the demands of stakeholders.
Requirements Engineering Process
Feasibility Study:
• The objective behind the feasibility study is to create the reasons
for developing the software that is acceptable to users, flexible to
change and conformable to established standards.
Types of Feasibility:
• Technical Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer
requirements within the time and budget.
• Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve
business problems and customer requirements.
• Economic Feasibility - Economic feasibility decides whether the
necessary software can generate financial profits for an
organization.
 Steps in Requirements Engineering
Process
• Requirements Elicitation
– This is the process of gathering information about the needs and expectations of stakeholders
for the software system. This step involves interviews, surveys, focus groups, and other
techniques to gather information from stakeholders.
• Requirements Analysis
– This step involves analyzing the information gathered in the requirements elicitation step to
identify the high-level goals and objectives of the software system. It also involves identifying
any constraints or limitations that may affect the development of the software system.
• Requirements Specification
– This step involves documenting the requirements identified in the analysis step in a clear,
consistent, and unambiguous manner. This step also involves prioritizing and grouping the
requirements into manageable chunks.
• Requirements Validation
– This step involves checking that the requirements are complete, consistent, and accurate. It
also involves checking that the requirements are testable and that they meet the needs and
expectations of stakeholders.
• Requirements Management
– This step involves managing the requirements throughout the software development life
cycle, including tracking and controlling changes, and ensuring that the requirements are still
valid and relevant.
Requirement Engineering Process
 Requirements Elicitation

There are several techniques that can be used to elicit requirements, including:
• Interviews: These are one-on-one conversations with stakeholders to gather
information about their needs and expectations.
• Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
• Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
• Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
• Prototyping: This technique involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to validate
requirements.
• It’s important to document, organize and prioritize the requirements obtained
from all these techniques to ensure that they are complete, consistent and
accurate
 Requirements specification
There are several types of requirements that are commonly specified in this step, including
• Functional Requirements: These describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data storage, and user
interface.
• Non-Functional Requirements: These describe how well the software system should do it. They
specify the quality attributes of the system, such as performance, reliability, usability, and security.
• Constraints: These describe any limitations or restrictions that must be considered when
developing the software system.
• Acceptance Criteria: These describe the conditions that must be met for the software system to be
considered complete and ready for release.
• In order to make the requirements specification clear, the requirements should be written in a
natural language and use simple terms, avoiding technical jargon, and using a consistent format
throughout the document. It is also important to use diagrams, models, and other visual aids to
help communicate the requirements effectively.
• Once the requirements are specified, they must be reviewed and validated by the stakeholders and
development team to ensure that they are complete, consistent, and accurate.
• Functional Requirements: Functional requirements define a
function that a system or system element must be qualified
to perform and must be documented in different forms.
The functional requirements are describing the behavior of
the system as it correlates to the system's functionality.
• 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.
• Non-functional requirements are divided into two main
categories:
– Execution qualities like security and usability, which are
observable at run time.
– Evolution qualities like testability, maintainability, extensibility,
and scalability that embodied in the static structure of the
software system.
 Requirements Verification and
Validation
• Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
• Validation: It refers to a different set of tasks that ensures that the software that
has been built is traceable to customer requirements. If requirements are not
validated, errors in the requirement definitions would propagate to the successive
stages resulting in a lot of modification and rework. The main steps for this process
include:
– 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.
– Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
• Requirements verification and validation (V&V) is the process of checking that the
requirements for a software system are complete, consistent, and accurate, and
that they meet the needs and expectations of the stakeholders. The goal of V&V is
to ensure that the software system being developed meets the requirements and
that it is developed on time, within budget, and to the required quality.
 Requirements Management

• Requirement management is the process of analyzing, documenting,

tracking, prioritizing and agreeing on the requirement and controlling the
communication to relevant stakeholders.
• This stage takes care of the changing nature of requirements. It should be
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.
• Being able to modify the software as per requirements in a systematic and
controlled manner is an extremely important part of the requirements
engineering process.
• Requirements management is the process of managing the requirements
throughout the software development life cycle, including tracking and
controlling changes, and ensuring that the requirements are still valid and
relevant.
• The goal of requirements management is to ensure that the software
system being developed meets the needs and expectations of the
stakeholders and that it is developed on time, within budget, and to the
required quality.
 Requirement Elicitation and Analysis
• This is also known as the gathering of requirements.
Here, requirements are identified with the help of
customers and existing systems processes, if available.

• Analysis of requirements starts with requirement

elicitation. The requirements are analyzed to identify
inconsistencies, defects, omission, etc
• Problems of Elicitation and Analysis

– Stakeholders often don't know what they want

– Stakeholders express requirements in their terms.
– Stakeholders may have conflicting requirements.
– Requirement change during the analysis process.
 requirement reviews
• Requirement review is the practice of scanning the
software errors to make the industry user-friendly for
all.

The performance of requirement review helps to

radiate the precise and correct data to the consumers
and users.
• It helps to have a quick tour of the Existing project to
see whether or not it is going in the right direction.
• It helps to provide practical instructions and helps
make decisions accordingly
 Methods of performing requirement
review
• 1. Team consultation :
Suggestion matters also matter the way of performance. Teamwork goes hand in
hand. When there are people to offer suggestions, give appropriate guidelines,
and supervise in a team. There is no doubt about the project getting mismanaged.
Reaching out to the team/individual who has better insights into requirement
review works the best way.
2. Understanding the user’s requirement :
Recognize the user’s needs and go all out in understanding them. Requirements
keep on changing with time. So, When you have collected a list of things that a
user requires in the current time. There you found a way to go about it. To get
exact information on their requirements, Asking for feedback is Important.
3. Finding measures to software problem :
The occurrence of software problems is predictable. Errors and defects are bound
to take place in software development. In this context, Rather than making a fuss
about the Problems, developers should find solutions to satisfy the requirements.
The requirement review not only meets the expectations of users but also the
standard of the entire industry.
 Advantages of performing
requirement reviews
• Requirement reviews accord the developers a
motive and structure to carry out the project
further.
• Group collaboration is the highlight. Group work
saves time.
• Therefore, the developers can utilize the saved
time in rechecking and reconfirming the
processing work to take it ahead.
•
 Disadvantages of performing
requirement reviews :
• Lack of attention acts as a hindrance. When a
team does not listen to each other in a meeting
room because of disagreement on matters, it
emerges as a sign of unprofessional and
uncoordinated work.
• At times, the Review cannot be accurate. So, If
you fail in assembling the precise information, it
can be an obstacle for the developers and the
industry.
•
 Software Engineering
System Requirement Specification
(Unit-2 )Part-2

Compiled By
Dr. Vandana Agarwal
 Information Modeling
• It is a non technical but formal description of
the information needs of a group of users .
• Usually it consist of a diagram describing all
the core business object,their properties and
their interrelationships.
 SYSTEM MODELLING
System modelling helps the analyst to understand
the functionality of the system and models are
used to communicate with customers.
• Different models present the system from
different perspectives o
– Behavioural perspective showing the behaviour of the
system;
– Structural perspective showing the system or data
architecture
 BEHAVIOURAL MODELS:

• Behavioural models are used to describe the overall

behaviour of a system.
• Two types of behavioural model are:
– Data processing models that show how data is processed
as it moves through the system;
– State machine models that show the systems response to
events.

• These models show different perspectives so both of

them are required to describe the system’s behaviour.
 Data-processing models:

• Data flow diagrams (DFDs) may be used to model

the system’s data processing.
• These show the processing steps as data flows
through a system.
• DFDs are an intrinsic part of many analysis
methods.
– Simple and intuitive notation that customers can
understand.
– Show end-to-end processing of data.
Order processing DFD:
 Data Flow Diagrams
• 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 diagrams:

• DFDs model the system from a functional

perspective.
• Tracking and documenting how the data
associated with a process is helpful to develop
an overall understanding of the system.
• Data flow diagrams may also be used in
showing the data exchange between a system
and other systems in its environment.
 Symbols (DFD)
• Circle: A circle (bubble) shows a
process that transforms data inputs
into data outputs.
• Data Flow: A curved line shows the
flow of data into or out of a process
or data store.
• Data Store: A set of parallel lines
shows a place for the collection of
data items. A data store indicates
that the data is stored which can be
used at a later stage or by the other
processes in a different order. The
data store can have an element or
group of elements.
• Source or Sink: Source or Sink is an
external entity and acts as a source of
system inputs or sink of system
outputs.
 Three levels in the Data Flow Diagram
0-Level
• 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.
• 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.
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 sub processes.
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.
Data can flow from
Data can not flow from
• External entity to process • External entity to External
• Process to External entity entity
• Process to store • External entity to store
• Store to process • Store to External entity
• Process to process • Store to store
 Entity Relationship Diagram
(E-R Diagram)
• It depicts the relationship between data objects and is used
in conducting data modeling activities. The attributes of
each object in the Entity-Relationship Diagram can be
described using Data object description. It provides the
basis for activity related to data design.

• 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
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.
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.
 types of Attributes

• Key attribute
• Composite attribute
• Single-valued attribute
• Multi-valued attribute
• Derived attribute
• Composite attribute: An
attribute that is a
combination of other
attributes is called a
composite attribute. For
example, In student
entity, the student
address is a composite
attribute as an address is
composed of other
characteristics such as pin
code, state, country.
Single-valued attribute: Single-
valued attribute contain a single
value. For example,Aadhar
number.
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 person can
have more than one phone
number etc.
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
 Relationships
The association among entities is known as
relationship. Relationships are
represented by the diamond-shaped box
are called relationships. EMP SUPERVISES

Degree of a relationship set

The number of participating entities in a
relationship describes the degree of the
relationship
1. Unary relationship: This is also called
recursive relationships. It is a relationship
between the instances of one entity type.
2. Binary relationship: It is a relationship
between the instances of two entity
types..
3. Ternary relationship: It is a relationship
amongst instances of three entity types
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 set.

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.

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

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.

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.
 decision table
• A decision table is a brief visual representation for
specifying which actions to perform depending on given
conditions.
• A decision table is a good way to settle different
combination inputs with their corresponding outputs and is
also called a cause-effect table.
• 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.
• 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.

• 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.
• 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.
• 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.
• Used in testing: A decision table is basically an outstanding technique
used in both testing and requirements management.
• Helps to prepare requirements: It is a structured exercise to prepare
requirements when dealing with complex business rules.
• Helps to model complicated logic: It is also used to model complicated
logic.
 Advantages of Decision Table

• 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.
• 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.
• Simple to understand: Simple to understand and everyone can use this
method to design the test scenarios & test cases.
• Provides complete test case coverage: It provides complete coverage of
test cases which helps to reduce the rework on writing test scenarios &
test cases.
• Guarantees every combination is considered: These tables guarantee that
we consider every possible combination of condition values. This is known
as its completeness property.
•
ExampleHow to Create a Login Screen
Decision Base Table
Software Requirement Specification
SRS Document
&
Software Quality Assurance
Compiled by
Dr. Vandana Agarwal
 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.
 IEEE requirements standard defines a generic
structure for a requirements document that must be
instantiated for each specific system.
1.Introduction.
i) Purpose of the requirements document
ii) Scope of the project
iii) Definitions, acronyms and abbreviations
iv) References
v) Overview of the remainder of the document

2. General Description.
i) Product perspective
ii) Product functions
iii) User characteristics
iv) General constraints
v) Assumptions and dependencies

3. Specific Requirements
i. Functional, non-functional and interface requirements.
ii. describe system functionality and performance,
iii. specify logical database requirements,
iv. design constraints,
v. emergent system properties and quality characteristics.

4.Approval

5. Appendices.
 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.
 Specific Requirements
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.
 Conclusion

• Software development requires a well-structured

Software Requirement Specification (SRS).
• It helps stakeholders communicate, provides a
roadmap for development teams, guides testers in
creating effective test plans, guides maintenance and
support employees, informs project management
decisions, and sets customer expectations.
• The SRS document helps ensure that the software
meets functional and non-functional requirements,
resulting in a quality product on time and within
budget.
 SOFTWARE QUALITY
• Objective of software engineering is to produce good
quality maintainable software in time and within budget.
• Here, quality is very important.

Different people understand different meaning of quality like:

• Conformance to requirements
• Fitness for the purpose
• Level of satisfaction
When user uses the product, and finds the product fit for its
purpose, he/she feels that product is of good quality.
Software Quality Factors
 Software Quality Assurance
• Software quality assurance consist of a means of
monitoring the software engineering processes and
methods used to ensure quality.
• The definition serves to emphazise three important
points
– Software requirements are the foundation from which quality
is measured. Lack of conformance to requirements is lack of
quality
– Specified standards define a set of development criteria that
guide the manner in which software is engineered. If the
criteria are not followed, lack of quality will almost surely
result
– A set of implicit requirement often goes unmentioned .If
software confirms to its explicit requirements but fails to
meet its implicit requirements, software quality if suspect.
Kinds of Quality
• Quality of Design: Quality of
Design refers to the
characteristics that designers
specify for an item. The grade of
materials, tolerances, and
performance specifications that
all contribute to the quality of
design.
• Quality of conformance: Quality
of conformance is the degree to
which the design specifications
are followed during
manufacturing. Greater the
degree of conformance, the
higher is the level of quality of
conformance
• Software Quality: Software Quality is defined as the conformance
to explicitly state functional and performance requirements,
explicitly documented development standards, and inherent
characteristics that are expected of all professionally developed
software.
• Quality Control: Quality Control involves a series of inspections,
reviews, and tests used throughout the software process to ensure
each work product meets the requirements place upon it. Quality
control includes a feedback loop to the process that created the
work product.
• Quality Assurance: Quality Assurance is the preventive set of
activities that provide greater confidence that the project will be
completed successfully.
– Quality Assurance focuses on how the engineering and management
activity will be done?
– As anyone is interested in the quality of the final product, it should be
assured that we are building the right product.
– It can be assured only when we do inspection & review of
intermediate products, if there are any bugs, then it is debugged. This
quality can be enhanced.
 Verification & Validation
• It is the name given to the checking and analysis
process
• The purpose is to ensure that the software
confirms to its specifications and meets the need
of the customer
• Verification represents the set of activities that
are carried out to confirm that the software
correctly implements the specific functionality
• Validation represents the set of activities that
ensure that the software that has built is
satisfying the customer requirements.
 Key Differences
Verification Validation
• Are we building the product • Are we building the right
right ? product ?
• Ensure the at the software • Ensure that the functionalities
system meets all the meet the intended behaviour
functionality • Validation occurs after
• Verification takes place first verification and mainly
and include the checking for involves the checking of the
documentation, code , etc. overall product
• Done by developers • Done by tester
• Have static activities as it • Have dynamic activities as it
includes the review and included executing the
inspections to verify that software against the
software is correct or not requirements
 Software Quality Assurance

• Software quality assurance is a planned and

systematic plan of all actions necessary to
provide adequate confidence that an item or
product conforms to establish technical
requirements.
• A set of activities designed to calculate the
process by which the products are developed
or manufactured
 SQA Activities

• Software quality assurance is composed of a

variety of functions associated with two
different constituencies
– The software engineers who do technical work
and
– an SQA group that has responsibility for quality
assurance planning, record keeping, analysis, and
reporting.
• Prepares an SQA plan for a project: The program is developed during project
planning and is reviewed by all stakeholders. The plan governs quality assurance
activities performed by the software engineering team and the SQA group. The
plan identifies calculation to be performed, audits and reviews to be performed,
standards that apply to the project, techniques for error reporting and tracking,
documents to be produced by the SQA team, and amount of feedback provided to
the software project team.
• Participates in the development of the project's software process
description: The software team selects a process for the work to be performed.
The SQA group reviews the process description for compliance with organizational
policy, internal software standards, externally imposed standards (e.g. ISO-9001),
and other parts of the software project plan.
• Reviews software engineering activities to verify compliance with the defined
software process: The SQA group identifies, reports, and tracks deviations from
the process and verifies that corrections have been made.
• Audits designated software work products to verify compliance with those
defined as a part of the software process: The SQA group reviews selected work
products, identifies, documents and tracks deviations, verify that corrections have
been made, and periodically reports the results of its work to the project manager.
• Ensures that deviations in software work and work products are documented and
handled according to a documented procedure: Deviations may be encountered
in the project method, process description, applicable standards, or technical work
products.
• Records any non compliance and reports to senior management: Non-
compliance items are tracked until they are resolved.
 SQA Plans
• The SQA plan provides a roadmap for instituting
software quality assurance
• developed by SQA group , the plan serves as a
template for SQA activates that are instituted for each
software project
• The documentation section describes each of the work
products produced as parts of the software process.
These includes
– Project documents
– Models
– Technical document( test plans)
– User documents(help files)
 SQA plan Advantages
• Used for large, widely distributed teams to
work on enterprise-level projects
• Supports the whole development cycle with :
– Integrated requirements management
– Change management
– Defect tracking
– Project and task management
• Offers project trend analysis and reporting
 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.
• The software product view describes the characteristics of a
product that bear on its ability to satisfy stated and implied needs.
• 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 fulfils its intended purpose.
• Validation checks that the product design satisfies the purposeful
usage and verification checks for errors in the software.
• The primary concern for developers is in the design and engineering
processes involved in producing software.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.
• While validation and verification are used by the developers to
improve the software, the two methods don’t represent a
quantifiable quality measurement. The developer’s view of
software quality and the customer’s view of software quality are
both different things.
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.
• In contradiction to end-user programming, professional programming has the goal
of producing software for others to use.
• 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.
• Users find software quality as a fit between their goals and software’s
functionality.
• The better the quality, the more likely the user will be satisfied with the soft-ware.

Therefore, the user understands quality as fitness for purpose. Avoiding complexity
and keeping software simple, considerably lessens the implementation risk of
software.
 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 fulfil given requirements.
• 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.
• According to the users, a high-quality product is one that satisfies
their expectations and preferences while meeting their
requirement.
• 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.
 ISO 9000 & SEI-CMM
Software Requirement Specifications
Unit-2(PART_4 )

Compiled By
Dr. Vandana Agarwal
 ISO 9000

• ISO in Greek means “Equal”, so the association wanted to convey

the idea of equality
• It is attempt to improve software quality based on ISO 9000series
standards
• It has been adopted by over 130 countries including India and Japan
• One of the problem with ISO-9000 series standard is that it is not
industry specific
• It can be interpreted by the developer to diverse projects such as
hair dryers, automobiles ,television as well as software
• It is just not software standard but are applicable to a wide variety
of industrial activities including design/development, production,
installation and servicing.
• It applies to all types of organizations
 ISO 9000 Certification

• ISO (International Standards Organization) is a group or

consortium of 63 countries established to plan and fosters
standardization. ISO declared its 9000 series of standards in
1987.
• It serves as a reference for the contract between
independent parties. The ISO 9000 standard determines
the guidelines for maintaining a quality system. The ISO
standard mainly addresses operational methods and
organizational methods such as responsibilities, reporting,
etc.
• ISO 9000 defines a set of guidelines for the production
process and is not directly concerned about the product
itself.
 Stages
• Application
• Pre-assessment
• Document Review and adequacy of Audit
• Compliance Audit
• Registration
• Continued surveillance
 ISO 9000 series
• The ISO 9000 series of standards is based on the assumption that if a
proper stage is followed for production, then good quality products are
bound to follow automatically. The types of industries to which the various
ISO standards apply are as follows.
• ISO 9001: This standard applies to the organizations engaged in design,
development, production, and servicing of goods. This is the standard
that applies to most software development organizations.
• ISO 9002: This standard applies to those organizations which do not
design products but are only involved in the production. Examples of
these category industries contain steel and car manufacturing industries
that buy the product and plants designs from external sources and are
engaged in only manufacturing those products. Therefore, ISO 9002 does
not apply to software development organizations.
• ISO 9003: This standard applies to organizations that are involved only in
the installation and testing of the products. For example, Gas companies.
 Benefits of ISO Certification
• Continuous improvement
• Improved customer satisfaction
• Eliminate variations
• Better product and services
• Improved profit levels
• Improved communication
• Reduced cost
 How to get ISO 9000 Certification?
• An organization determines to obtain ISO 9000 certification applies to ISO
registrar office for registration. The process consists of the following stages
• Application: Once an organization decided to go for ISO certification, it
applies to the registrar for registration.
• Pre-Assessment: During this stage, the registrar makes a rough
assessment of the organization.
• Document review and Adequacy of Audit: During this stage, the registrar
reviews the document submitted by the organization and suggest an
improvement.
• Compliance Audit: During this stage, the registrar checks whether the
organization has compiled the suggestion made by it during the review or
not.
• Registration: The Registrar awards the ISO certification after the
successful completion of all the phases.
• Continued Inspection: The registrar continued to monitor the organization
time by time.
 Software Engineering Institute
Capability Maturity Model (SEI-CMM)
• It was developed by Software Engineering
Institute (SEI) of Carnegie-Mellon University in
1986
• It specifies an increasing series of levels of a
software development organization. The higher
the level, the better the software development
process
• It can be used in two ways
– Capabilty evaluation and
– Software process assessment
 Software Engineering Institute
Capability Maturity Model (SEI-CMM)
• The Capability Maturity Model (CMM) is a
procedure/strategy used to develop and
refine/improve an organization's software
development process to generate quality software
• The model defines a five-level evolutionary stage of
increasingly organized and consistently more mature
processes.
• CMM was developed and is promoted by the Software
Engineering Institute (SEI), a research and development
center promote by the U.S. Department of Defence
(DOD)
• It is development model created after a study of
data collected from organization that contracted
with the U.S department of defence who funded
the research.
• The term maturity related to the degree of
optimization of processes from ad hoc practices
to formally defined steps.
• Capability Maturity Model is used as a
benchmark to measure the maturity of an
organization's software process
 Immature v/s Mature Organization

• Process improvised during • Inter-group communication

project and coordination
• Approved processes being • Work accomplished
ignored according to plan
• Reactive, not proactive • Practices consistent with
• Unrealistic budget and processes
schedule • Processes updated as
• Quality sacrificed for necessary
schedule • Well defined
• No objective measure of roles/responsibilities
quality • Management formally
commits
Capacity Maturity Model
• Capability Evaluation: Capability evaluation
provides a way to assess the software
process capability of an organization. The
results of capability evaluation indicate the
likely contractor performance if the
contractor is awarded a work. Therefore, the
results of the software process capability
assessment can be used to select a
contractor.
• Software Process Assessment: Software
process assessment is used by an
organization to improve its process
capability. Thus, this type of evaluation is for
purely internal use.
• SEI CMM categorized software development
industries into the following five maturity
levels. The various levels of SEICMM have
been designed so that it is easy for an
organization to build its quality system
starting from scratch slowly.
 Levels of CMM
• Optimizing Level 5

Managed Level 4

Defined Level 3

REpeatabl
e Level 2

Initial Level 1
 Levels of CMM
• Initial. At the initial level, processes are disorganized, ad hoc and even chaotic.
Success likely depends on individual efforts and is not considered to be repeatable.
This is because processes are not sufficiently defined and documented to enable
them to be replicated.
• Repeatable. At the repeatable level, requisite processes are established, defined
and documented. As a result, basic project management techniques are
established, and successes in key process areas are able to be repeated.
• Defined. At the defined level, an organization develops its own standard software
development process. These defined processes enable greater attention to
documentation, standardization and integration.
• Managed. At the managed level, an organization monitors and controls its own
processes through data collection and analysis.
• Optimizing. At the optimizing level, processes are constantly improved
through monitoring feedback from processes and introducing innovative processes
and functionality.
 Initial
• Initial ( process unpredictable and poorly
controlled)
• No engineering management, everything
done of ad hoc basis
• Software process is unpredictable with respect
to time and cost
• It depends on current staff , as staff change so
does the process
 Repeatable
Basic project Management
• This level of software development
organization has a basic and consistent project
management processes to track cost, schedule
and functionality
• Planning and managing of new projects are
based on the experience with the similar
projects
• Realistic plans based on the performance
based on previous projects
 Defined
process standardization
• Process of development and maintaining s/w across
the organization is documented including engineering
and management
• Integrated into a standard software process for the
entire organization
• Training programs are implemented to ensure that
concern team acquire skills and knowledge required
• All projects across the organization use an approved
,tailored version of the organization’s standard
software process for developing , testing and
maintaining the application
• Risk Management
 Managed
Quantitative Measurement
• Organization sets quantitative goals for both
product and process
• Here process is predictable both with respect
to time and cost
• At this maturity level, the performance of
processes is controlled using statistical and
other quantitative techniques
 Optimized
( Continuous process improvement)
• Here organization analysis defects, to
determine their causes and goals is to
preventing the occurrence of defects
• Here company continuously improve the
process performance through both
incremental and innovative technological
improvements
 Conclusion
• SEICMM provides a series of key areas on
which to focus to take an organization from
one level of maturity to the next.
• It provides a method for gradual quality
improvement over various stages. Each step
has been carefully designed such that one
step enhances the capability already built up.
 Key process areas of each level
CMM level Key Focus Key process area
Initial -
Competent People
Repetitive Project Management Software Project Planning
Software Configuration
Management
Defined Definition of Processes Process Definition
Training Program
Peer Review
Managed Product & Process Quality Quantitative Process
Metrics
Software quality
management
Optimized Continuous process Defect Prevention
Improvement Process Change
Management
Technology change
Management
 Advantages of SEICMM
• Quality deliverables
• Higher client contentment
• Easier Management
• Cost Effective
• Brings more business
 COMPARISION
ISO CMM
• Its concept is to follow a set of • It emphasizes a process of
standards to make success continuous improvement
repeatable
• After certified ,organization • Ongoing process of evaluation
has only to maintain that level and improvement moving from
one level of achievement to other
• Focus on customer –supplier
relationship • Focus on software supplier to
improve its processes to achieve
• Written for wide range of a higher quality product
industries • CMM framework is specific only
• Defines minimum attribute for for software industry
a quality management • It’s a five level framework for
program measuring software engineering
practices
 CMM vs. CMMI: What's the difference?

• CMMI is a newer, updated model of CMM. SEI developed CMMI to

integrate and standardize CMM, which has different models for
each function it covers. These models were not always in sync;
integrating them made the process more efficient and flexible.
• CMMI includes additional guidance on how to improve key
processes. It also incorporates ideas from Agile development, such
as continuous improvement.
• SEI released the first version of CMMI in 2002. In 2013, Carnegie
Mellon formed the CMMI Institute to oversee CMMI services and
future model development. ISACA, a professional organization for IT
governance, assurance and cyber security professionals, acquired
CMMI Institute in 2016. The most recent version -- CMMI V2.0 --
came out in 2018. It focuses on establishing business objectives and
tracking those objectives at every level of business maturity.