UNIT 2: Software Requirement Specification:

Requirements describe “What” of a system, not the “How”. Requirement engineering produces
one large document, written in a natural language, contains a description of what the system will
do without describing how it will do. The input of requirement engineering is the problem
statement which gives an overview of the existing system along with broad expectations from the
new system.

Requirement engineering is most crucial activity in software development. Without well written
requirement specification, developers do not know what to build, customers do not know what to
expect, and there is no way to validate the system to satisfy the requirement.

Requirement engineering consists of four steps which are:

1. Requirement Elicitation: This is also known as requirement gathering. Here requirements

are identified with the help of customer and existing system processes. 2. Requirement
Analysis: The requirements are analyzed in order to identify inconsistencies, defects etc. We
describe the requirements in terms of module relationships and resolve conflicts.
3. Requirements Documentation: This is end product of requirement elicitation and analysis.
The documentation is very important to start the development activities like design. This
document is known as Software Requirement Specification (SRS).
4. Requirement Review: The review process is carried out to improve the quality of the SRS.
It may also be called as requirement verification.

If specification describes the both hardware and software, it is a system requirement specification.
If it describes only software, it is a software requirement specification.

Role of System Analyst:

The analyst starts requirements gathering and analysis activity by collecting all information from
the customer which could be used to develop the system. He then analyzes the collected
information to obtain a clear and thorough understanding of the product to be developed, with a
view to removing all ambiguities and inconsistencies from the initial customer perception of the
problem. The following basic questions can be asked to clearly understand the requirement of
project:

• What is Problem?

• Why is it important to solve the problem?

• What exactly are the data input to the system and what exactly are the data output by the
system?
• What are the possible solutions to the problem?
System analyst must have good interaction and communication skills. They must be a creative
and having good imagination and experience to understand the user needs and remove
inconsistencies and ambiguities.

Types of Requirements:

Requirements are of two types which are:

1. Functional Requirements: that describe what the software has to do. They are often
called product features.
2. Non Functional Requirements: That are mostly quality related requirements that help to
measure how well the software does what it has to do like availability, reliability,
usability, flexibility etc.
Requirement Elicitation:

Requirement elicitation is the most difficult, critical, error prone and most communication aspect
of software development. The important goal of elicitation is to find out exactly what the
customer wants from the system.

Some of the requirement elicitation methods are interview, brain storming, questioners etc. the
process of requirement elicitation is:

1. Identify all the stakeholders who should be sources of requirement those may be actual user,
customer or domain experts.
2. Ask formal questions as interview to get the understanding of the problem, issues and
constraints.
3. Analyze the information to remove the inconsistencies, ambiguities or unresolved issues. 4.
Conform the understanding of requirements to the stakeholders.
5. After customer satisfaction with requirement elicitation, we develop a requirement document.

Requirement Analysis:

Requirement analysis is very important and essential activity after elicitation. We analyze, refine
and scrutinize the gathered requirements in order to make consistent and unambiguous
requirements. This activity reviews all requirements and may provide graphical view of the entire
system. After the completion of analysis, it is expected that the understandability of the project
may improve. Here, we may also interact with the customer to clarify points of confusion and to
understand which requirements are more important than others. The various steps of requirement
analysis are:

1. Draw the context diagram: The context diagram is a simple model that defines the
boundaries and interfaces of proposed system with the external world.
2. Develop a prototype: This activity is optional. This is an effective way to understand what
the customer really wants from the system.
3. Model the requirements: This process usually consist of various graphical representations
of functions, data entities, external entities and the relationship
between them. Such model includes data flow diagrams, entity relationship diagrams,
data dictionaries etc.
4. Finalize the requirements: After modeling the requirements, we will have better
understanding of the system behavior. The inconsistencies and ambiguities have been
identified and corrected. In this step, we document the final requirements in a prescribed
format.

Requirement Specification:

Requirement documentation is very important activity after the requirement elicitation and
analysis. This document is known as Software Requirement Specification (SRS). SRS is used to
define the needs and expectations of the users. It also serve as a contract document between
customer and developer.

Review Requirements:

Requirement validation is the activity during which requirements are checked by the analyst to
remove the inconsistencies, ambiguities, extra requirements etc and by the customer to
understand what the system will provide. If any changes are requested then again elicitation and
analysis process if carried out otherwise the requirement document is undersign by both analyst
and customer.

Management of User Needs:

The purpose of requirement management is to establish a common understanding between the
customer and their requirements. It establish and maintain an agreement with the customer on the
requirements for the software project. It also refer to managing the changes of requirements
during the development of project.

SRS Document:

The SRS document stated in precise manner and explain all the functionalities that developing
software must provide. It also explains any constraint that must be take care at the time of
development of software. SRS document contains all types of requirements i.e. functional and
non-funcitonal that will be used for validation of software functionalities.

Properties of Good SRS Document / Characteristics of SRS Document:

There are following quality characteristics of good SRS document;

1. It should be Complete
2. It should specify what the system must do
3. Easy to change
4. It should be consistent
5. It should be complete
6. It should be Traceable
7. It should be Verifiable
8. It should not be over-specified
Problems without SRS Document:

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

• Without developing the SRS document, the system would not be implemented according to
the customer needs.
• Software developers would not know whether what they are developing is what exactly
required by the customer.
• Without SRS document, it will be very much difficult for the maintenance engineers to
understand the functionality of the system.
• It will be very much difficult for user document writer to write the user manuals properly
without understanding of SRS document.

IEEE Standard of SRS Document:

The Institute of Electrical and Electronics Engineers has published guidelines and standards to
organize an SRS document. Different projects may require their requirements organized
differently. There no one method that is suitable for all the projects. The first two sections of that
SRS document are the same in all of them. The general organization of SRS documents which is
as per the standard of IEEE standard 830-1993 are as follows:

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. The overall Description
 2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance Requirements
3.4 Database Requirements
3.5 Design Constrains
3.6 Non Functional Requirements
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability
4. Change Management Process
5. Document Approvals
6. Supporting Information

Functional Requirements:

These requirements are statement of service that software should provide. These requirements are
stated to understand how the software should react to particular input and how the software
should behave in a particular situation. The functional requirements are:

• These requirements are stated explicitly by the customer to understand the requirements
clearly by the development team so that they can understand what they suppose to deliver.
• Each high level functional requirement may involve a series of interaction between the
software and actual user.
• It should be complete and consistent.

Non-Functional Requirements:

Non-functional requirements are not directly concern with the specific functions delivered by the
software. These requirements are not stated by the customer. They may relate to the software
properties such as reliability, quality, response time, security, portability etc. They also define the
constraints for the software.

The types of non-functional requirements are:

1. Product Requirements: These requirements specify the product behavior such as

performance to check the execution time and consumed memory of software. We also the
check the failure rate for reliability.
 2. Organizational Requirements: These requirements are derived from policies and
procedure according to the customer and developer organizations.
3. External Requirements: This requirement covers all the requirements that are derived
from external factor to the software and its development process. These requirements
include interoperability requirements that define how the software interact with software
in other organization

Data Flow Diagrams:

Data flow diagrams are used widely for modeling the requirements. DFDs show the flow of data
through a system. DFD is a graphical technique that describes information flow and the
transformation of data from input to output.

The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows
the different processing activities or functions that the system performs and the data interchange
among these functions. Each function is considered as a process that consumes some input data
and produces some output data. The system is represented in terms of the input data to the
system, various processing carried out on these data, and the output data generated by the system.
A DFD model uses a very limited number of primitive to represent the functions performed by a
system and the data flow among these functions.

Symbols used for Constructing DFDs:

We have total of 5 primitive symbols used for constructing DFDs. The meaning of each of these
symbols is explained as:

1. Function Symbol: A function symbol is represented using a circle. This symbol is called a
process or a bubble. Bubbles are annotated with the names of the corresponding
functions.
2. External Entity Symbol: An external entity such as user is represented by a rectangle.
The external entities are essentially those physical entities external to the software system
which interact with the system by inputting data to the system or by consuming the data
produced by the system. These symbols can also be used to represent external hardware
and software such as application software.
3. Data Flow Symbol: a directed arc or an arrow is used as a data flow symbol. A data flow
symbol represents the data flow occurring between two processes or between an external
entity or a process. Data flow symbols are usually annotated with the corresponding data
names.
4. Data Store Symbol: A data store represents a logical file. It is represented using two
parallel lines. A logical file can represent either a data store symbol which can represent
either a data structure or a physical file on disk. Each data store is connected to a process
by means of data flow symbol. The direction of data flow arrow shows whether data is
being read from or written into a data store.
5. Output Symbol: the output symbol is used when a hard copy is produced and the user of
the copies cannot be clearly specified or there are several users of the output.

Synchronous and Asynchronous Operations:

If two processes are connected directly by a data flow arrow, then they are synchronous. This
means they can operate at the same speed. As example shows in figure: . Here the validate
number bubble can start processing only after the read number bubble has supplied data to it. And
the read number bubble has to wait until the validate number bubble has consumed its data.

However, if two bubbles are connected through a data store as shown in figure, then the speeds of
operation of the bubbles are independent. The data produced by a producer bubble gets stored in
the data store. The producer bubble may store several pieces of data items in the data store before
the consumer bubble consumes any of them. This is called asynchronous operation of two
processes.

Developing a DFD Model of a System:

A DFD Model of a system graphically depicts the transformation of the data input to the system
to the final result through a hierarchy of levels. A DFD starts with the most abstract definition of
the system at lower level and at each higher level DFD, more details are successively introduced.
To develop a higher level DFD model, processes are decomposed into their sub processes and the
data flow among these sub processes are identified.

To develop the data flow model of a system, first the most abstract representation of the problem
is worked out. The most abstract representation of the problem is also called the context diagram.
After, developing the context diagram, the higher level DFDs are developed.

Context Diagram:

The context diagram is the most abstract data flow representation of a system. It represents the
entire system as a single bubble. This bubble is labeled according to the main function of the
system. The various external entities with which the system interacts and the data flow occurring
between the system and the external entities are also represented. The data input to the system
and the data output from the system are represented as incoming and outgoing arrows. These data
flow arrows should be annotated with the corresponding data names. The name ‘context diagram’
is well justified because it represents the context in which the system is to exist, i.e. the external
entities who would interact with the system and the specific data items they would be supplying
the system and the data items they would be receiving from the system. The context diagram is
also called as the level 0 DFD.

To develop the context diagram of the system, it is required to analyze the SRS document to
identify the different types of users who would be using the system and the kinds of data they
would be inputting to the system and the data they would be receiving the system. Here, the
term “users of the system” also includes the external systems which supply data to or receive data
from the system.

The bubble in the context diagram is annotated with the name of the software system being
developed (usually a noun). This is in contrast with the bubbles in all other levels which are
annotated with verbs. This is expected since the purpose of the context diagram is to capture the
context of the system rather than its functionality.

Example#1: RMS Calculating Software.

A software system called RMS calculating software would read three integral numbers from the
user in the range of -1000 and +1000 and then determine the root mean square (rms) of the three
input numbers and display it. In this example, the context diagram is simple to draw. The system
accepts three integers from the user and returns the result to him.

Example#2: Tic-Tac-Toe Computer Game

The level 0 DFD shown in Figure is the context diagram for this problem.

Level 1 DFD:

To develop the level 1 DFD, examine the high-level functional requirements. If there are between
3 to 7 high-level functional requirements, then these can be directly represented as bubbles in the
level 1 DFD. We can then examine the input data to these functions and the data output by these
functions and represent them appropriately in the diagram.

If a system has more than 7 high-level functional requirements, then some of the related
requirements have to be combined and represented in the form of a bubble in the level 1 DFD.
Such a bubble can be split in the lower DFD levels. If a system has less than three high-level
functional requirements, then some of them need to be split into their sub
functions so that we have roughly about 5 to 7 bubbles on the diagram.

Level 2: In this level we further decompose the functions which can be decompose further. For
example, in the level 1 DFD only computer RMS can be further divisible. So we can further
decompose this in level 2.
The level of Tic Toe Game is

Example: A supermarket needs to develop the following software to encourage regular

customers. For this, the customer needs to supply his/her residence address, telephone number,
and the driving license number. Each customer who registers for this scheme is assigned a unique
customer number (CN) by the computer. A customer can present his CN to the check out staff
when he makes any purchase. In this case, the value of his purchase is credited against his CN. At
the end of each year, the supermarket intends to award surprise gifts to 10 customers who make
the highest total purchase over the year. Also, it intends to award a 22 caret gold coin to every
customer whose purchase exceeded Rs.10,000. The entries against the CN are the reset on the day
of every year after the prize winners’ lists are generated.

Diagram from Paper

Commonly Made errors while constructing a DFD Model

It is helpful to understand the different types of mistakes that users usually make while
constructing the DFD model of systems.

• Many beginners commit the mistake of drawing more than one bubble in the context

diagram. A context diagram should depict the system as a single bubble. • Many beginners
have external entities appearing at all levels of DFDs. All external entities interacting with the
system should be represented only in the context diagram. The external entities should not
appear at other levels of the DFD
• It is a common oversight to have either too less or too many bubbles in a DFD. Only 3 to 7
bubbles per diagram should be allowed
• Many beginners leave different levels of DFD unbalanced

• A common mistake committed by many beginners while developing a DFD model is

attempting to represent control information in a DFD. It is important to realize that a DFD
is the data flow representation of a system, and it does not represent control information.
 • A data store should be connected only to bubbles through data arrows. A data store cannot
be connected to another data store or to an external entity.
• All the functionalities of the system must be captured by the DFD model. No function of the
system specified in its SRS document should be overlooked.
• The data and function names must be intuitive.
Shortcomings of DFD Model

DFD models suffer from several shortcomings. The important shortcomings of the DFD models
are the following:

• In the DFD model, the function performed by a bubble is judged from its label. However, a

short label may not capture the entire functionality of a bubble. • Control aspects are not
defined by a DFD. For instance, the order in which inputs are consumed and outputs are
produced by a bubble is not specified. A DFD model does not specify the order in which the
different bubbles are executed. Representation of such aspects is very important for modeling
real-time systems.
• Several alternative DFD representations are possible; so many times it is not possible to say

which DFD representation is superior or preferable to another one. • The data flow
diagramming technique does not provide any specific guidance as to how exactly to
decompose a given function into its sub-functions and we have to use subjective judgment to
carry out decomposition.

Information Modeling:

An information model is essential to provide the structure for information that is transferred in a
communication. An information model is a formal description of a portion of interest of the real
world and that provides explicit rules to enable the data items that populate the model to be
interpreted without ambiguity.

Information modeling starts with the definition of the scope of the model‘s applicability. The
scope specifies the domain of discourse and the processes that are to be supported by the
information model. It is a bounded collection of processes, information, and constraints that
satisfy some industry need.

The scope statements include the purpose as well as viewpoints of the model mentioned bellow:

type of product,
type of data requirements,
supporting manufacturing scenario,
supporting manufacturing activities,
supporting stage in the product life cycle.
After the scope is defined, the next phase is to conduct a requirements analysis. There is no
standard method for collecting information requirements. However, requirements analysis may
be accomplished by:

Literature surveys,
Standards surveys,
Domain experts’ interviews,
 Industrial data reviews,
State-of-the-art assessments.
Information modeling is a technique for specifying the data requirements that are needed within
the application domain.

There are different practices in developing an information model:

Entity Relationship Approach (ER)

Functional Modeling Approach
Object Oriented Approach (O-O)

Techniques for Representing Complex Logic

A good SRS document should properly characterize the condition under which different scenarios
of interaction occur. Sometimes such conditions are complex and several alternatives interaction
and processing sequences may exist. In such situations, a simple text description would be
difficult to analyze. In such situations, decision tree or decision table can be used to represent the
logic a processing involved.

There are two main techniques available to analyze and represent complex processing logic:
decision tree and decision table.

Decision Tree:

A decision tree gives a graphic view of the processing logic involved in decision making and the
corresponding actions taken. The edges of a decision tree represent conditions and the leaf nodes
represent the actions to be performed depending on the outcome of testing the condition.

Example:

Consider Library Membership Automation Software (LMS) where it should support the
following three options:

• New member

• Renewal

• Cancel Membership

New member option-

• Decision: When the 'new member' option is selected, the software asks details about the
member like the member's name, address, phone number etc.

• Action: If proper information is entered then a membership record for the member is
created and a bill is printed for the annual membership charge plus the security deposit
payable.
Renewal option-

• Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and his
membership number to check whether he is a valid member or not.

• Action: If the membership is valid then membership expiry date is updated and the annual
membership bill is printed, otherwise an error message is displayed.
Cancel membership option-
 • Decision: If the 'cancel membership' option is selected, then the software asks for member's
name and his membership number.

• Action: The membership is cancelled, a cheque for the balance amount due to the member
is printed and finally the membership record is deleted from the database.

The decision tree representations are shown in figure:. After getting information from user, the
system makes a decision and then performs the corresponding actions.

Decision Table
A decision table is used to represent the complex processing logic in a tabular or a matrix form.
The upper rows of the table specify the variables or conditions to be evaluated. The lower rows of
the table specify the actions to be taken when the corresponding conditions are satisfied. A
column in a table is called a rule. A rule implies that if a condition is true, then the corresponding
action is to be executed.

Example:

Consider the previous example of LMS. The following decision table shows how to represent the
LMS problem into a tabular form. Here the table is divided into two parts, the upper part shows
the conditions and the lower part shows what actions are taken. Each column of table is a rule.

From the above table you can easily understand that, if the valid selection condition is false then
the action taken for this condition is 'display error message'. Similarly, the actions taken for other
conditions can be inferred from the table.

Capability Maturity Model

Capability Maturity Model was proposed by Software Engineering Institute, USA. SEI Capability
Maturity Model (SEI CMM) helped organizations to improve the quality of the software they
develop.

CMM is a reference model for inducting the software process maturity into different levels. It can
be used to predict the most likely outcome to be expected from the next project that the
organization undertakes. SEI CMM can be used two ways: capability evaluation and software
process assessment. Both differ in motivation, objective, and the final use of the result.

Capability evaluation provides a way to assess the software process capability of an organization.
The results of capability evaluation indicate the performance of an organization if the work is
awarded. Therefore, the results of software process capability assessment can be used to select an
organization.

On the other hand, software process assessment is used by an organization with the objective to
improve its process capability. Thus, this type of assessment is for purely internal use.

The different levels of SEI CMM have been designed so that it is easy for an organization to
slowly build its quality system starting from scratch. SEI CMM classifies software development
industries into the following five maturity levels.

Level 1: Initial
A software development organization at this level is characterized by ad hoc activities. Very few
or no processes are defined and followed. Since software production processes are not defined,
different engineers follow their own process and as a result development efforts become
confused/messy. The success of projects depends on individual efforts. When engineers leave,
then others have great difficulty in understanding the previous work and to complete that work.

Level 2: Repeatable

At this level, the basic project management practices such as tracking cost and schedule are
established. Size and cost estimation techniques like function point analysis, COCOMO, etc. are
used. Processes are repeated for earlier success projects with similar applications.

Level 3: Defined

At this level the processes for both management and development activities are defined and
documented. There is a common organization-wide understanding of activities, roles, and
responsibilities. The process and product qualities are not measured.

Level 4: Managed

At this level, the focus is on software metrics. Two types of metrics are collected i.e. Product
metrics and Process metrics. Quantitative quality goals are set for the products. The process
metrics are used to check if a project performed satisfactorily. Thus, the results of process
measurements are used to evaluate project performance rather than improve the process.

Level 5: Optimizing

Process and product measurement data are analyzed for continuous process improvement.
Continuous process improvement is achieved both by carefully analyzing the quantitative
feedback from the process measurements and also from application of innovative ideas and
technologies.
ISO 9000

ISO (International Standards Organization) is a consortium of 63 countries established to

formulate and foster standardization. ISO published its 9000 series of standards in 1987. ISO
certification serves as a reference for contract between independent parties. The ISO 9000
standard specifies the guidelines for maintaining a quality system. The ISO standard mainly
addresses operational aspects and organizational aspects such as responsibilities, reporting, etc.
ISO 9000 specifies a set of guidelines for repeatable and high quality product development. It is
important to realize that ISO 9000 standard is a set of guidelines for the production process and is
not directly concerned about the product itself.

ISO 9000 is a series of three standards: ISO 9001, ISO 9002, and ISO 9003. The ISO 9000 series
of standards is based on the basis that if a proper process is followed for production,
then good quality products are bound to follow automatically. The types of industries to which
the different ISO standards apply are as follows.

ISO 9001 applies to the organizations engaged in design, development, production, and servicing
of goods. This is the standard that is applicable to most software development organizations.

ISO 9002 applies to those organizations which do not design products but are only involved in
production. Examples of these category industries include steel and car manufacturing industries
that buy the product and plant designs from external sources and are involved in only
manufacturing those products. Therefore, ISO 9002 is not applicable to software development
organizations.

ISO 9003 applies to organizations that are involved only in installation and testing of the
products.

Need for Obtaining ISO 9000 Certification

Difference Between CMM and ISO

ISO CMM

ISO is a generic Standard. It is applicable for CMM is software specific.

all industries.

ISO is a standard. It tells what needs to be CMM is a model. It does not mandate the
done in an organization. practices.

ISO focuses on the entire organization’s CMM is specific to software processes.

processes.

ISO Certification is followed by audit once in After CMM assessment, there are no such
6 months. checks. It is upto the organization to use it for
internal process improvement.

Internal audits are mandatory. Not Mandatory.

ISO certification can be used by an CMM assessment is purely for internal use.
organization in official documents for
communication with external parties.

ISO 9001 aims at level 3 of CMM model. CMM goes beyond quality assurance and
prepares an organization to ultimately
 achieve total quality management.

Verification and Validation

The term verification and validation are frequently used in software testing.
Criteria Verification Validation

Definition The process of evaluating The process of evaluating

work product of a software during or at the end

development phase, which is of the development process

not the actual final product, to determine whether it
to determine whether they satisfies specified business
meet the specified requirements.
requirements for that phase.

Objective To ensure that the product is To ensure that the product

being built according to the actually meets the user’s
requirements and design needs. In other words, to
specifications. In other demonstrate that the product
words, to ensure that work fulfills its intended use when
products meet their specified placed in its intended
requirements. environment.

Question Are we building the product Are we building the right

Right? product?

Evaluation Items Plans, Requirement The actual product or

Specifications, Design Software
Specifications, Code, Test
Cases.

Activities Reviews, Inspections, Testing

Walkthroughs

Software Quality Assurance

Software quality is defined as “Conformance to explicitly stated functional and performance

requirements, explicitly documented development standards, and implicit characteristics that are
expected of all professionally developed software”.

Quality assurance consists of the auditing and reporting functions of management. The goal of
quality assurance is to provide management with the data necessary to be informed about product
quality, thereby gaining confidence that product quality is meeting its goals.

SQA Activities

Software quality assurance is composed of a variety of tasks associated with two different
constituencies—the software engineers who do technical work and an SQA group that has
responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting.
SQA activities are performed (or facilitated) by an independent SQA group that:

• Prepares an SQA plan for a project: The plan is developed during project planning and is
reviewed by all interested parties. Quality assurance activities performed by the software
 engineering team and the SQA group are governed by the plan.
• 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, and other parts of the software project plan.
• Reviews software engineering activities to verify compliance with the defined software
process: The SQA group identifies, documents, and tracks deviations from the process
and verifies that corrections have been made.
• Audits designated software work products to verify compliance: The SQA group
reviews selected work products; identifies, documents, and tracks deviations; verifies 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
• Records any noncompliance and reports to senior management.

SQA Plan

The SQA Plan provides a road map for instituting software quality assurance. Developed by the
SQA group, the plan serves as a template for SQA activities that are instituted for each software
project.

A standard for SQA plans has been recommended by the IEEE [IEE94]. Initial sections describe
the purpose and scope of the document and indicate those software process activities that are
covered by quality assurance. All documents noted in the SQA Plan are listed and all applicable
standards are noted. The management section of the plan describes SQA’s place in the
organizational structure, SQA tasks and activities and their placement throughout the software
process, and the organizational roles and responsibilities relative to product quality.

The reviews and audits section of the plan identifies the reviews and audits to be conducted by
the software engineering team, the SQA group, and the customer. It provides an overview of the
approach for each review and audit.

The test section references the Software Test Plan and Procedure. It also defines test record
keeping requirements. Problem reporting and corrective action defines procedures for reporting,
tracking, and resolving errors and defects, and identifies the organizational responsibilities for
these activities.

The remainder of the SQA Plan identifies the tools and methods that support SQA activities and
tasks; references software configuration management procedures for controlling change; defines a
contract management approach; establishes methods for assembling, and maintaining all records;
identifies training required to meet the needs of the plan; and defines methods for identifying,
assessing, monitoring, and controlling risk.