SOFTWARE ENGINEERING

BCS 601
UNIT II – SOFTWARE REQUIREMENT
SPECIFICATIONS(SRS)
SYLLABUS -
REQUIREMENT-

• We define requirement as :
• Conduction of capability needed by a user to solve a problem
or achieve an objective
• A Condition or capability that must be met or posses by a
system to satisfy a contract, standard, specification or other
formally imposed document.
SRS(SOFTWARE REQUIREMENT
SPECIFICATION) –

It is a document that completely describes what the

proposed software should do without describing what
the proposed software should do without describing
how the software will do it.
Requirement Engineering –
It can be defined as the “Systematic process of documenting
requirement through an interactive co operative process of
analyzing the problem, documenting the resulting observations
in a variety of representation format & checking the accuracy of
the understanding gained”
or
It is defines as “ the systematic use of proven principles
techniques , tools & languages for the cost effective analysis,
documentation and ongoing evolution of user needs & the
specification of the external behaviors of the system in order to
satisfy these needs.
REQUIREMENT ENGINEERING ACTIVITY-
WELL DEFINED
INFORMAL &
REQUIREMENT COMPLETE &
FUZZY
ENGINEERING CONSISTENT
REQUIREMENT
REQUIREMENTS

There are wide variety of methodologies which are proposed for

expressing requirements specification.
Eg. Natural Language descriptions. Structured Analysis
techniques. Object oriented , requirements analysis Techniques
etc.
Classification of Requirements -
• Functional Requirements
• Non Functional Requirements
• Domain Requirements
FUNCTIONAL REQUIREMENTS-
• They focus on the functionality of the software components
that build the system.
• Functional requirements are the services which are the end
users expect the final product to provide.
• There are many ways of expressing functional requirements eg.
Natural language, structured or formatted language. With no
rigorous syntax, formal specification language with proper
syntax.

•
NON FUNCTIONAL REQUIREMENTS -
• These are constraints imposed on the system and deal with issues
like maintainability , security, performance reliability etc.
• Other terms used to specify NFRs are –
• Quality attributes
• Constraints
• Goals
• Non behavioral Requirement
• NFRs can be classified as:
• Interface constraints
• Performance Constraints : response time, security , reliability storage
space etc.
• Operating constraints.
• Life cycle Constraints : maintainability , reusability ,portability, flexibility etc.
• Economic Constraints.
DOMAIN REQUIREMENTS-
• These are the requirements that are specific to an application
domain eg. Banking , Hospital etc.
• These requirements are therefore identified from domain
model and are not user specific.
NEED OF SRS -
• A Basic purpose of software requirements specification is to bridge
the communication gap between user & developer.
• To help the clients to understand their own needs as it forces the
client and users to think, visualize , interact & discuss with others.
• An SRS establishes the basis for agreement between the client &
the supplier on what the software product will do this basis for
agreement is frequently formalized into a legal contract between
the client and the developer. So through SRS, the client clearly
describes what it expects from the supplier, & the developer clearly
understands what capabilities to build in the software.
NEED OF SRS -
• An SRS provides a reference for validation of the final product.
• A high quality SRS is prerequisite to high quality software.
• A high Quality SRS reduces the development Cost. Hence the
Quality of the SRS impacts customer satisfaction , system
validation quality of the final Software & software development
cost.
Characteristics of a SRS-
Correctness-
• An SRS is said to be correct if every requirement stated in the
document is correct.
• For ensuring Correctness users may be asked to review the
document
• Further, it can be compared with some proceedings
documents or with applicable standards.
Completeness-
• It is said to be complete if –
• All the significant functional & non functional requirements to be
satisfied by the software are included in the SRS.
• Response to all valid and invalid class of data is included. It means for
every valid and invalid inputs defined in SRS, appropriate output is
also mentioned.
• All figures , tables & pages are numbered. They are also properly
named and referenced.
• Sections in the SRS should avoid the label ”to be determined” as far
as possible.
Consistency -
• It is said to be consistent if there is no conflict between the
requirements in the documents.
• Different types of conflict may exist between the requirements.
Some of them are:
• Conflicts between characteristics of real world entities.
• Temporal or logical Conflicts between two items
• Conflicts can also arise if different terminology is used to describe
same real world object or event.
Unambiguousness-
• Unambiguousness in the SRS document is supported only if
each and every requirement started in it has only one
interpretation.
• It can be best achieved by using requirements specification
languages, requirements analysis & modelling techniques &
reviewing the document written in natural language by a third
process.
Modifiability-
• Requirements keep changing and changes must be reflected
properly in the SRS.
• An SRS is said to be modifiable if changes can be made to the
requirements easily, completely and consistently while
retaining its structure & style.
Verifiability-
• An SRS is said to be verifiable if for each requirement written in
SRS, there exists some cost effective process using which a
person or tool can ensure that software meets the
requirements.
Traceability -
• It can be further classified into 2 types:
• a) Forward Traceability – Which is achieved by assigning a
unique name or number to each requirement.
• b) Backward Traceability – Which is achieved by each
requirement referring explicitly to its source in previous
documents.
 Design Independent -
• It is said to be design independent if it does not include any
implementation details.
REQUIREMENT PROCESS(SRS)

Pallavi Shukla
Asst. Professor
REQUIREMENT PROCESS-
• It is the sequence of activities that need to be performed in the
requirements in the requirements phase nad that culminate in
producing high quality document containing the software
requirements specification(SRS).
• Requirements Phase consists of 3 basic activities :
• Problem or Requirement Analysis /Requirements Elicitation.
• Requirement Specification.
• Requirement Validation.
Requirement Analysis / Requirement
Elicitation-
• It is concerned with understanding of problem domain at the
beginning of the project because requirements are fuzzy and
are not clearly understood by the analyst.
• This process of acquiring information/ knowledge about a
specific problem domain through various techniques to build
the requirements model is called Requirement Elicitation.
• This activity of requirement elicitation helps the analyst to gain
knowledge about the problem domain which in turn is used to
produce formal specification of software to be developed to
meet the customer.
Requirement Specification -
• The purpose is to produce formal software requirements
model.
• These models specify the functional and non functional
properties of the system along with the constraints imposed on
the system.
Requirement Validation -
• It is defined as process to ensure the consistency of
requirements model with respect to customers' needs.
• The validation is done not only for the final model but also for
all intermediate models generated.
• If requirements are not validated , errors in the requirements
definition would propagate to the successive stages resulting
into lot of modification & rework.
• Following steps should be followed while validating
requirements
• Ensure that requirements are consistent. They are not conflicting with
other requirements.
• Ensure that requirements are complete in all respect.
• Ensure that requirements are realistic and realizable.
Client/User
Needs

Problem Analysis

Product Description

Validation

VALIDATED SRS
• Requirement process is seen as linear sequence of 3 activities , but it
is not so to most real activities, there is considerable overlap and
feedback between these activities.
REQUIREMENT ELICITATION
TECHNIQUES
Pallavi Shukla
Asst. Professor
INTERVIEWS -
• It is popular technique for understanding the problem domain
and quite successful.
• It may take the form of questionnaire , open ended interviews &
focus groups.
• Structured Interview- Analysist can simplify ask the users
about their expectations from the system but the main
problem is that users can bypass their limitations so analysts
can probe the user through a set of questions thus avoiding the
above mentioned problem this tyoe of interview is called
Structured Interview.
Focus Group -
• It is a kind of group interview where groups are brought
together to discuss some topic of research to the researcher &
allow more natural interactions than open ended interviews.
• Steps for interviews are :
a) Create the Questions
b) Select the interviews
c) Plan Contracts
d) Conduct the interview
e) Close the meeting
f) Determine where to go next
Brainstorming -
• It is a group technique to promote creative thinking and can eb
used during requirements elicitation process to generate new
ideas.
Task Analysis -
• It is a technique of decomposing the problem domain into a
hierarchy of tasks & subtasks.
• It is an effective technique for elicititating requirements
concerned with Human – Computer Interaction (HCI)
Form Analysis -
• Forms plan an important role in any organization and contain
lot of meaningful information about data objects of the
domain.
• Forms are important source of information for modeling the
static view or data aspect of the system.
Delphi Technique -
• In this session , participants are made to write the
requirements .
• These requirements are then exchanged among participants
who give their comments to get a revised set of requirements .
• This process is repeated till a final consensus is reached.
Use Scenario and Use Case Based
Requirements Elicitation-
• Use Scenario are unstructured descriptions of the user
requirements.
• Use Cases are structured descriptions of the user
requirements
• Use case diagrams are graphical representation to show the
system at different levels of abstraction.
Domain Analysis -
• This technique focuses on reuse of requirements from similar
domain.
• Therefore starting from one or more existing systems requirements
for the new system can be formulated.
• This is just like representing the requirements at another higher
level of abstraction called Meta Level.

Facilitated Application Specification Techniques(FAST)-

• FAST was developed specifically for collecting requirements & is similar

to brainstorming.
ELICITING REQUIREMENTS

Pallavi Shukla
Asst. Professor
DATA FLOW DIAGRAM

Pallavi Shukla
Asst. Professor
DATA FLOW DIAGRAM(DFD) -
• It is a modelling tool used to model the functional view of the
system in terms of processes & flow of data between these
processes.
• The techniques for modelling flow of data between processes
is also called Process Modeling.
PROCESS-
• It is used to show some kind of transformations on data.
• It is represented by a circle with name of process written inside
it.
• Process names should be meaningful verb object phrases not
nouns.

Compute
Salary
Data Flow
• Data flows show data in motion between different processes ,
process and store or external agent or process.
• They are represented by arrows which are labelled
• A data flow represents –
• 1) Data input to a process
• 2) Output form a process
• 3) Insertion of new data in the store or retrieval of existing data
• 4) Updating existing data in the store.
• 5) Deletion of existing data form the store
 Emp_id
Salary Salary slip

No. of Hours

Compute Print
Salary Report
• A data flow can be further classified as
• Convergent Data Flow- It is formed by merging multiple data
flows into a single data flow.
• Divergent Data Flow – it is one which breaks up into multiple
data flows.
Customer_id

Item_List Order

Converging Data Flow

Vendor _id

Street

Addresses Zipcode Diverging Data flow

City
STORE -
• It represent data at rest and can be shown graphically by the
symbol.

• Normally stores correspond to entities in the ER diagram.

• They are named as plural of corresponding data model
entities,
• It means that if in ER diagram an entity student exists , there
must be a store called students in the DFD.
Employees
Employees
EXTERNAL AGENT-
• They are also called Terminators and represent people,
organization or other systems external to the system being
development.
• They are represented graphically by a rectangular box.
• External Agents provide input to the system & also receive
output from the system.

BANK
CONTEXT DIAGRAM:
• Context Diagram is also called a level 0 data flow diagram.
• It is a diagram in which working of the whole organization is represented by a
single process and its interaction with external agents is shown through exchange
of data.
DATA DICTIONARY-
• It is the most important part of structured analysis model.
• It is the organized listing of all data elements of the system with their precise and unambiguous
definitions.
• Data dictionary contains information about.
o Meaning of aggregate item with comments.
o Units of elementary items
o Definition of data/control flows.
o Definition of data stores
o Definition of entities, relationships , attributes, external agents.
o Definition of external control /data flows.
o Local data elements used in writing process specifications any more.
• = is defined as / composed of
• + and
• { } iteration (0 or more occurrences)
• Min { } max iteration with min & max values specified.
• ( ) optional data elements
• [ ] selection of one data from several choices separated by |
• @ store identifier
• ** Comment
• SOME EXAMPLES ARE: =

a) Order = Company_ name + Address + 1 {ordered item} 10

• Order is composed of Company_Name, address and minimum one and maximum 10
ordered_items.
•
b) Student = [Undergraduate| post graduate ]
• Student is an undergraduate or post graduate student.

c) Student_name = first_name + (middle_name)+last_name.

APPROACHES TO BUILD DFDs-

• 1)Classical Approach –

• In this analyst starts with level 0 DFD or context diagram and using top down decomposition arrives at
level 1.

• Function decomposition diagram is also used for identifying process at various levels.

• Problem with this approach is that there is no guidelines to decompose a process at nth level of DFD at
(n+1) th level.

• As a result the whole process is very time consuming.

2) Event Partitioning Approach –

• This approach tries to streamline the process drawing DFDs.

• The focus of the whole approach is the notion of event because events play very important role in any
organization.

• Steps followed are:

➢ Identify and the compile the list of events taking place in the organization.
➢ For each event draw a event response process model consisting of single process.
➢ Join the event response models to arrive at level1
➢ If necessary perform upward /downward levelling.
EVENTS –

• It is anything which happens in the system & causes system to change state.

• Flow Oriented Events – they are accompanied by some kind of data. Customer places Order in this event
accompanies data about the order placed by the customer.
• Temporal Events – They occur on a fixed date and time. Ex every Friday at 5 PM, a report is to be
generated to view the weekly sales.
• System Events – these events are internal to the system and occur based on the system [Link].
whenever the inventory level goes below certain value, event is generated to place order with the
supplier.
GUIDELINES FOR DRAWING DFDs –
PROCESS –

• All the processes must be numbered.

• Use meaningful verb object phrases for process names eg Compute salary, generate Reports.
• Avoid processes with only inputs, They are called Sinks .
• Avoid processes with the outputs
• If necessary redraw the DFD as many times as required.
DATA FLOW -
1) Make sure that all data flows are labelled.
2) Data flows cannot move from a store to another store or store to an external [Link] must mov through a
process.
3) A data flow does not move back to the same process it leaves.
4) A fork can be shown in a data flow to indicate that same data is going from a location to one or more
destinations.
 EXTERNAL AGENT-
• Use noun phrases to label external agents
• External agents cannot interact directly with a store or any other external agent
through data flows.

DATA STORE –
• Use Meaningful noun phrases to label data stores.
• Data cannot move directly from data stores to other data stores or external
agents . it must move through process.
STATE TRANSITION DIAGRAM (STD) -
• It models the dynamic view i.e time dependent behaviour of the system

• Major components of the diagram are :

➢ State
➢ Action
➢ Arrow
➢ Condition
State – A state is described by a set of attribute values at a particular instant
of time and is represented by a rectangle or an oval sign.

• Ex – Person depending upon his age can be in one of the following states - infant, child , adult , middle
age.
• State can be either initial / start date, end/final state or in between state.

• A system can have only one initial state and single or multiple final states.

INFANT ADULT
Action –
• Whenever system changes state in response to a condition it performs one or more actions.

• It is also possible that it may not perform any action

• Some of the actions can be displaying a message.

Arrows - Arrows connect two or more states indicating that S1 changes to state s2 as a result of some
condition c being satisfied.

S1 s2
Arrows –
• Arrows connect two or more states indicating that S1 changes to state s2 as a result of some condition
c being satisfied.

S1 S2
Condition
• A condition is some event in the external environment which causes the system to change from say
state s1 to s2.

• This event can be anything, say an interrupt , signal or arrival of some data.

age = 18
years
Child Adult
PROCESS SPECIFICATIONS-
• In a DFD processes are shown as black boxes.

• Logic Modelling pr process Specification is used to give the description of logic contained ina process
at the lowest level of decomposition.
• Higher level processes which are decomposed into detailed DFD’s do not have Process specification

• Process Specification can be written using

a) Structured Language
b) Pre/ Post Conditions
c) Decision Tables
d) Decision Trees
e) Flow charts
f) Nessi Sheindermann Diagrams etc.
STRUCTURED LANGUAGE
• It is a subset of English language that supports language constructs to represent sequence, repetition
and conditional statements in order to specify the process details.

• It can be called Structured English.

• Alternate names for Structured English are Program Design Language (PDL)

• Program statement / Specification Language (PSL)

• SENTENCE – A sentence in the structured English can be a simple verb object phrase or it can take the
form of an algebraic equation.

• VERBS – They are normally chosen from a small set of action oriented verbs & vary fron organization.

• Ex – ADD, DELETE, GET, READM UPDATE, SORT, VALIDATE etc.

• OBJECTS – Objects in these verb object phrases are the data elements already defined in the data
dictionary.
Some of the constructs are • REPEAT
Sentence 2
– Until Condition
• IF Condition • DO CASE
Sentence 1 Case variable = value 1:
Sentence 1;
ELSE Case variable = value 2:
Sentence 2 Sentence 2;
Case variable = value n :
End if Sentence _n;
• DO WHILE Condition Default:
Sentence n+1;
Sentence 1 END CASE
End do
DECISION TABLE
• When the process logic is very complicated , involving multiple conditions , it is not possible to
represent the process logic efficiently with structured English . In such type of scenario, decision tables
are used to represent the logic.

• Main parts of Decision Table are –

1) Condition Stubs
2) Action Stubs
3) Rules
• CONDITION STUBS - It list all the conditions relevant to the decision

• ACTION STUBS – Action stubs are part of the table lists all possible actions that will take place for a
valid set of conditions.

• RULES – Rules part of the table specifies which set of conditions will trigger which action.
• STEPS FOLLWOED TO CONSTRUCT DECISION TABLES ARE :

1) List all conditions and the values conditions can have

2) List all possible actions
3) List all possible rules in terms of combination of various conditions
• For each rule define the action.
 1 2 3 4 5

C1 N N Y Y Y

C2 N N Y Y

C3 N Y N

A1 X

A2 X X

A3 X

C1 – Account number is Correct

C2 – Signature Matches
C3 – There is enough money in the account
A1 – Give Money
A2 – Give statement that not enough money is there
A3 – Call the vigilance department to check for fraud

Y – YES
N – NO
Challenges in Eliciting Requirements -
• Understanding large/ complex system requirements.
• Undefined System Boundaries
• Users not clear about their needs
• Representing requirements in suitable form
• Conflicting requirements.
• Requirements changing quite often.
• Resolving TBD( To be determined)
• Partitioning the system suitably in order to reduce complexity
• Validating & tracing requirements
• Proper documentation of the requirements.
• Meeting the time and budget , constraints of the customer.
• Identifying the critical requirements
Basic Principle -
• Used in analysis or elicitation is the same as in any complete
task: Divide and Conquer.
• Partition the problem into subproblems and then try to
understand each subproblem and its relationship to other
subproblems in an effort to understand the total problem.
• This is an applied recursively by treating each subsystem as a
system in its own right.
• During analysis Partitioning is done with respect to objects or
functions.
Object -
• It is an entity in the real world that has clearly defined boundaries
and an independent existence . By considering real world objects ,
the focus of the analysis stays on the problem domain , rather than
the solution domain.

Function -
• It is a task, service, process ,mathematical function, or activity that is
now being performed in the real world has to be performed by the system
that will be built to solve the real world problem.
State -
• A state of a system represents some conditions about the
system.
• When using state , a system is first viewed as operating in one if
the several possible states , and then object based or function
based analysis is performed for each state. This approach is
sometimes used in real time software or process control
software.
 Projection -
• A system is defined form multiple points of view projecting a 3
dimensional object on the 3 different 2 dimensional planes is a
similar process.
• While using projection , different viewpoints of the system are
defined and the system is analyzed from these different
perspectives separately using an object based or function based
approach.
Basic Approaches to Problem Analysis -
• 1) Informal Approach – Based on Structured Communication
• 2) Conceptual Modelling Based Approach
• 3) Prototyping
Informal Approach -
• It is one where no defined methodology is used.
• The information about the system is obtained by interaction with the
client , end users, Questionnaires , study of existing documents ,
brainstorming etc.
• In such an approach, the analyst will have a series of meetings with the
clients & end users.
• In the early meetings , the clients & end users will explain to the analyst
about their work, their environment & their needs as they perceive them.
• Any documents describing the work or the organization may be given,
along with outputs of the existing methods of performing the task.
• Once the analyst understands the system to some extent, he uses the
new few meetings to seek clarifications of the parts he does not
understand.
Informal Approach -
• In the final few meetings , the analyst essentially explains to the
client what he understands the system should do & uses the
meetings as a means of verifying if what he proposes the system
should do is indeed consistent with the objectives of the clients.
Structured Analysis -
• Structured Analysis Techniques uses function based
decomposition while modeling the problem domain & the data
consumed & produced by these functions.
• The structured analysis ,method helps an analyst decide what
type of information to obtain at different points in analysis & it
helps organize information so that the analyst is not
overwhelmed by the complexity of the problem.
• It is a top down refinement approach , which was originally
called Structured Analysis & Specifications.
• Structured Analysis Techniques result in graphical
representation of the software system development.
• 1) Entity Relationship Diagram
• 2) Function Decomposition Diagram
• 3) Data Flow Diagram
• 4) State Transition Diagram
• 5) Data Dictionary
• 6) Process Specifications
• 7) Context Diagram
• 8) Decision Trees
 IEEE SOFTWARE PROJECT
MANAGEMENT PLAN(SPMP)
• Introduction
• Project Overview
• Project Deliverables
• Evolution of the software Project Management Plans
• Reference Materials
• Definitions and Acronyms
• Project Organization
• Process Model
• Organizational Structure
• Organizational Boundaries & Interfaces
• Project Responsibilities
• Managerial Process
• Management Objectives & Priorities
• Assumptions , Dependencies & Constraints
• Risk Management
• Monitoring & Controlling Mechanisms
• Staffing Plans
• Technical Process
• Methods, Tools & Techniques
• Software Documentation
• Project Support Functions
• Work Packages , Schedule & Budget
• Work Packages
• Dependencies
• Resource Requirement
• Budget & Resource Allocation
• Schedule
• Additional Components
• Index
• Appendices
INTRODUCTION :
• Project Overview : Brief description is given of the project objectives,
the product to be delivered , the activities & their resulting work
products.
• Project Deliverables : All the items to be delivered to the client are
listed here together with the delivery dates.
• Evolution of the software Project Management Plan: The SPMP
requires continual updating in the light of experience and of change
within both the client organization and the software development
organization.
• Reference Materials: All documents referenced in the SPMP are listed
here.
• Definitions and Acronyms: this information ensures that the SPMP
will be understood the same way by everyone.
PROJECT ORGANISATION
• It specifies how the product is to be developed both from the viewpoint of the software process & the organization structure of developers
• Process Model – It is specified in terms of the activities such as designing the product or performing product testing , and the project functions , such as Project
Management or configuration Management
• Organizational Structure : Management structure of the development organization is described.
• Organizational Boundaries & Interfaces – Project Members have to interact with the client organization & with other members of this own organization Administrative &
Managerial Boundaries between the project itself and other entities must be laid down.
• Project Responsibilities – for each project function such as SQA and for each activity such as Product testing , the responsible individual must be identified.
• S/W Documentation – Contains the documentation requirements
• Project Support Functions – It details plans for the supportive functions such as Configuration Management & Quality Assurance , Including Test plans.
• It specifies how the product is to be developed both from the viewpoint of the software process & the organization structure of developers
• Process Model – It is specified in terms of the activities such as designing the product or performing product testing , and the project functions , such as Project
Management or configuration Management
• Organizational Structure : Management structure of the development organization is described.
• Organizational Boundaries & Interfaces – Project Members have to interact with the client organization & with other members of this own organization Administrative &
Managerial Boundaries between the project itself and other entities must be laid down.
• Project Responsibilities – for each project function such as SQA and for each activity such as Product testing , the responsible individual must be identified.
• S/W Documentation – Contains the documentation requirements
• Project Support Functions – It details plans for the supportive functions such as Configuration Management & Quality Assurance , Including Test plans.
WORK PACKAGES , SCHEDULE AND BUDGET –

• Work Packages- Work Packages are specified , with their associated

work products broken down into activities & tasks.
• Dependencies- Dependencies between packages & external events
are specified.
• Resource Requirements- To complete the project , a wide variety of
resources will be required.
• Budget & resource Allocation – the allocation of resources & budget
to the various project functions, activities & task is presented.
• Schedule – A detailed schedule is given for each component of the
project. This master plan will then be followed, it is hoped that the
project will be completed on time & within budget.
MANAGERIAL PROCESS –

• Management Objectives and priorities- The philosophy , goals & priorities

for management are described. This include frequency & mechanisms of
reporting , relative priorities among requirements , schedule & budget for the
project , Risk management procedures.
• Assumptions, Dependencies & Constraints - Any assumptions &
Constraints in the specification document appear here.
• Risk Management – Various risks factors associated with the project are
listed in this subsection as well as the mechanisms used for tracking these
risk factors.
• Monitoring & Controlling Mechanisms – Reporting Mechanisms for the
project are described in detail, including review and audit mechanisms.
• Staffing Plan – the numbers and type of Personnel required are listed ,
together with the durations for which they will be needed.
TECHNICAL PROCESS –

• Methods, Tools & Techniques- Technical aspects of Hardware and

software sre described in detail.
• ADDITIONAL COMPONENTS :
• They includes –
• Subcontractor Management Plans
• Security Plans
• Independent Verification & validation plans
• Training Plans
• Hardware Procurement Plans
• Installation Plans
• Product Maintenance Plan
SOFTWARE QUALITY
It is the “Conformance to explicit stated functional &
performance requirements , explicitly documented
development standards, & implicit characteristics
that are expected of all professionally developed
software”
Software Product Quality –
The product Quality describes the attributes of the products of the
software process. It can be :
• Completeness of the design documents.
• Traceability of the design
• Reliability & Maintainability of the code.
• Coverage of the tests.
Software Process Quality –
Process quality describes the attributes of the software
development process itself, Following are software environment
elements that are present in all the software projects are :
• Process Quality mainly focuses in
• Correct implementation of a techniques.
• Productivity of a tool
• Abilities of a tool
• Communicativeness of an organization
• How well suited are the installation & facilities.
SOFTWARE QUALITY ASSURANCE (SQA) –
• It consists of those procedures , techniques and tools applied by
software professional to ensure that software product meets or
exceeds prespecified standards during a development cycle
• and without specific prescribed standards , Quality Assurance entails
ensuring that a software product meets or exceeds a minimal industrial
or commercially acceptable level of excellence.
• Purpose of SQA is to provide management with appropriate visibility
into the orocess being used by the software Project and of the products
being developed,
• SQA involves reviewing & auditing the software products & activities to
verufy that they comply with the applicable procedures & standards &
providing the software project and other appropriate managers with the
results of these reviews & audits.
OBJECTIVES OF SOFTWARE QAUALITY
ASSURANCE
• A Quality Management Approach
• Effective Software Engineering Technology
• Formal technical reviews that are applied throughout the software
process
• A multi testing startgey is drawn
• Control of software documentation & the changes made to it.
• A procedure to assure compliance with software development
standards when applicable.
• Measurement & reporting mechanisms.
GOALS OF SOFTWARE QUALITY
ASSURANCE –
• Software Quality Assurance Activities are planned.
• Adherence of software products & activities to the applicable
standards , procedures & requirements is verified objectively
• Affected groups & individuals are informed of software Quality
Assurance activities & results.
• Non Compliance issues that cannot be resolved within the
software project are addressed by senior management.
SQA Activities -
• Applications of Technical Methods- software quality is designed into the software
but not added after ward implies must have set of technical methods & tools to help
analyst generate high quality specifications & designs.
• Formal Technical Reviews – A formal technical review is a stylized meeting by
technical staff to uncover Quality Problems.
• Soaftware Testing – Appropriate strategies for software testing should be applicable.
• Enforcement of standards – There are several Quality standards such as ISO 9000,
SEI CMM etc meant for ensuring software quality if these standards are used, can be
applied by developers as a part of formal view.
• Control of change – Change control includes – Formalised Requests for change,
Evaluates the nature of the change, Controls the impact of the change,
• Measurement – Software metrices are needed to track Quality & access impact of
methodological and procedural changes.
• Record Keeping & Reporting – Collection & dissemination of software Quality
Assured information is required. Results of audits , reviews , change control, testing
and other SQA activities are part of record of the project.
ISO 9000 MODELS
• International Standards : International Standards are
documented agreements containing technical specifications or
other precise criteria can be used consistently as rules, guidelines
or definitions of characteristics , to ensure that materials ,
products , processes & services are fit for their purpose.
• they contribute to making life simpler and to increasing the
reliability & effectiveness of the goods & services we use.
• International standardization is well established for many
technologies in such diverse fields as information processing and
communications, textiles, packaging, distribution of goods,
energy production & utilization , ship building, banking and
financial services.
INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION(ISO) –
It is an international, non governmental organization that promotes
the development and implementation of voluntary international
standards. This is done through a cooperative , consensus building
process that results in the creation of product & process
management standards.
• ISO STANDARDS – ISO Standards are written specification and
guidance documents that establish internationally harmonized
conventions for the operation , design, performance or
management of products(technical standards) and processes
(management standards)
• ISO 9000 is a series of standards dealing with Quality
management systems.
• Conformance standards are ISO 9001, ISO 9002 & ISO 9003 and
state the requirements for an effective Quality System. Guidance
standards recommend how to use the series, develop Quality
systems, and apply the requirements in various industries.
ISO Standard Series –
• ISO 9000 – Quality Management & Quality Assurance standards
Guidelines for selection & use.
• ISO 9001 - Model for Quality assurance in design/development
production installation & servicing.
• ISO 9002 – Model for Quality Assurance in Production & Installation.
• ISO 9003 – Model for Quality Assurance in Final Inspection and Test.
• ISO 9004 – Generic Guidelines FOR Management & systems
• ISO 9004 – 2 – Guidelines for services
• ISO - 14001 – Environment Management Systems Guidelines
Principles, Systems & Supporting techniques.
BENEFITS OF ISO 9000 CERTIFICATION
• Improved Customer Satisfaction
• Greater Quality Awareness
• Higher Real & Perceived Quality
• Positive Cultural Change
• Competitive Edge
• Increased Market Share
• Increased Productivity
• REDUCED Costs
• Improved Communication
• Better Product & Services
• Increased Employee Participation
LIMITATIONS OF ISO 9000 CERTIFICATION
• ISO 9000 does not automatically leas to total Quality
Management i.e Continuous Improvement.
• ISO 9000 does not provide any guideline for defining an
appropriate process.
• ISO 9000 certification process is not foolproof & thus variations in
the certification norms may exist.
CAPABILITY MATURITY MODEL
• There are number of process improvement models for
organization attempting to mature their processes.
• The models are developed by the Software Engineering Institute
(SEI).
• Goal of SEI is to provide leadership in the state if Software
engineering to improve Quality of systems throughout the
lifecycle.
• Capability Maturity Model(CMM) provides the means to measure
an organization process maturity against a set of common feature
that are specified at each of the maturity levels.
• The SEI CMM is also used as a guideline for software process
Improvement (SPI) initiatives.
• The Capability Maturity Model is based on the following premises.
• Software Quality of an information technology system in large
stem from quantity of the processes used to create it.
• The level of technology used in information technology systems
must be appropriate to the maturity of the processes.
• System delivery is a process that can be managed, measured and
progressibvely improved
STRUCTURE OF SEI CMM –
he SEI CMM is a framework of key processes defines a 5 level of
evolutionary path of software process maturity.
• The level of maturity indicates the process capability of an
organization.
• Key processes Areas (KPAs) are defined for each of the maturity
levels from level 2 to level 5.
• Within each of the KPAs , a number of goals & activities are
defined.
• Within each of the KPAs the activities are grouped into 5 common
features.
• Commitment to perform
• Ability to perform
• Activities Performed
• Measurement & Analysis
• Verifying Documents
LEVELS OF SEI CMM –
• The CMM defines 5 levels of maturity for an Organization.
• Each of these levels focuses on a set of process goals.
• As an organization moves through the levels , the processes
introduced build on the maturity established in the previous
levels.
Level 1 : Initial -
• Processes are ad-hoc and success depends on individual heroics.
• As a result, organizations at level 1 are unlikely to be able to
accurately predict schedules , budgets , or quality.

Level 2: Repeatable -
• At level 2, basic management planning & tracking processes
are established at the project level.
• Process discipline is starting which enables the organization
to repeat successes.
Level 3 : Defined -
• Software process are defined at the organization level. Each project starts
with the organizations processes and tailors them for their specific needs.
• The software processes are integrated with the management processes.

Level 4 – Managed -
• When an organization reaches level 4 , the processes have been well established and measured.
• Metrices that have been gathered since level1 are analyzed to form the basis for setting of
quantitative quality goals.
• Level 5 – Optimized – Level 5 is the top level of Maturity and these
organizations are focused on continuous improvement.
Thank You