Software Requirements: Functional and Non-Functional, User requirements, System requirements, Software Requirements Document – Requirement Engineering Process: Feasibility Studies, Requirements elicitation and analysis, requirements validation, requirements management-Classical analysis: Structured system Analysis, Petri Nets- Data Dictionary

1. Software Engineering
KCS-601, Unit-II
Dr APJ Abdul Kalam Technical
University, Lucknow
By
Dr Anuranjan Misra
1
Dr Anuranjan Misra
innovation
Ambassador
Ministry of Education,
Government of India
& Professor & Dean,
GNIOT, Greater
Noida

2. UNIT –II Syllabus
Software Requirement Specifications (SRS):
Requirement Engineering Process: Elicitation,
Analysis, Documentation, Review and
Management of User Needs, Feasibility Study,
Information Modelling, Data Flow Diagrams,
Entity Relationship Diagrams, Decision Tables,
SRS Document, IEEE Standards for SRS.
Software Quality Assurance (SQA): Verification
Software Quality Assurance (SQA): Verification
and Validation, SQA Plans, Software Quality
Frameworks, ISO 9000 Models, SEI-CMM Model.

3. Requirements Engineering
• The process of eliciting, analyzing,
documenting, and validating the services
required of a system and the constraints
under which it will be developed and
operated.
operated.
• Descriptions of these services and
constraints are the requirements for the
system.
• Requirements may be high-level and
abstract, or detailed and mathematical. (or
somewhere in between)

4. Requirements Engineering
The hardest single part of building a
software system is deciding precisely
what to build. No other part of the
what to build. No other part of the
conceptual work is as difficult… No
other part of the work so cripples the
resulting system if done wrong. No
other part is more difficult to rectify later.
– Fred Brooks, “No Silver Bullet…”

5. RE Includes
• Discovery/Identification.
• Refinement/Analysis: Identify inconsistencies,
omissions, defects etc.
• Modeling: Functional (DFD), Behavioral (STD),
Informational (DD), Other.
Informational (DD), Other.
• Specifications (SRS Document).
• Without well documented SRS
– Developers do not know what to build.
– Customers do not know what to expect.
– No way to validate whether build system
satisfies the requirements.

6. Requirements Engineering
Process
Feasibility
study
Requirements
elicitation and
analysis
Requirements
specification
specification
Requirements
validation
Feasibility
report
System
models
User andsystem
requirements
Requirements
document

7. SRS must delineate
• Inputs.
• Outputs.
• Functional Requirements.
• Non-functional Requirements.
• Non-functional Requirements.
• SRS should be/have
– Internally consistent.
– Consistent with existing documents.
– Correct & complete w.r.t. satisfying customer needs.
– Understandable to the users, customers, designers,
& testers.
– Capable of serving as a base for design & test.

8. Requirements Analysis
• Software engineering task that bridges the gap
between system requirements engineering and
software design.
• Provides software designer with a model of
– system information
– system information
– function
– behavior
• Model can be translated to data, architectural,
and component-level designs.
• Expect to do a little bit of design during analysis
and a little bit of analysis during design.

9. Software Requirements Analysis
Phases
• Problem recognition.
• Evaluation and synthesis: focus is on
what not how.
what not how.
• Modeling.
• Specification.
• Review.

10. Feasibility Study
• Economic feasibility
– cost/benefit analysis
• Technical feasibility
• Technical feasibility
– hardware/software/people, etc.
• Legal feasibility
• Alternatives
– there is always more than one way to do it.

11. Requirements
• Requirements
– features of system or system functions
used to fulfill system purpose.
• Focus on customer’s needs and
problem, not on solutions.
– Requirements definition document .
(written for customer).
– Requirements specification document.
(written for programmer; technical staff).

12. Types of Requirements
• Functional requirements:
– input/output
– processing.
– error handling.
• Non-functional requirements:
– Physical environment (equipment locations, multiple sites, etc.).
– Physical environment (equipment locations, multiple sites, etc.).
– Interfaces (data medium etc.).
– User & human factors (who are the users, their skill level etc.).
– Performance (how well is system functioning).
– Documentation.
– Data (qualitative stuff).
– Resources (finding, physical space).
– Security (backup, firewall).
– Quality assurance (max. down time, MTBF, etc.).

13. Requirement Validation
• Correct?
• Consistent?
• Complete?
• Each requirement describes something
• Each requirement describes something
actually needed by the customer.
• Requirements are verifiable (testable) ?
• Requirements are traceable.

14. Requirements Definition Document
• General purpose of document.
• System background and objectives.
• Description of approach.
• Detailed characteristics of proposed
• Detailed characteristics of proposed
system (data & functionality).
• Description of operating environment.

15. Software Requirement Elicitation
• Most difficult, critical, error-prone, and communication
intensive aspect of s/w development.
• Requirements actually reside in the minds of the users.
• Developers and users have different mind set, expertise,
and vocabularies.
and vocabularies.
• Communication gap between customers and developers
may lead to inconsistencies, misunderstanding and
omissions of requirements.
• Customers have solid background in their domain but
have a little knowledge of s/w development process.
• Developers have experience of developing s/w but have
little knowledge of everyday environment of the customer.

16. Software Requirements Elicitation
Techniques
• Customer meetings are the most commonly used
technique.
• Meetings/Interviews may be open ended or
structured.
• Use context free questions to find out
– customer's goals and benefits
– customer's goals and benefits
– identify stakeholders
– gain understanding of problem
– determine customer reactions to proposed
solutions
– assess meeting effectiveness
• Interview cross section of users when many users
are anticipated.

17. Interviews

19. Brainstorming

21. F.A.S.T. - 1
• Facilitated application specification
technique
• Meeting between customers and
developers at a neutral site (no home
developers at a neutral site (no home
advantage).
• Goals
– identify the problem
– propose elements of solution
– negotiate different approaches
– specify preliminary set of requirements

22. F.A.S.T. - 2
• Rules for participation and preparation
established ahead of time.
• Agenda suggested
• Agenda suggested
– brainstorming encouraged
• Facilitator appointed.
• Definition mechanism
– sheets, flipcharts, wallboards, stickers, etc.

23. F.A.S.T.-3
• Each FAST attendee is asked to prepare a list
of objects that are part of environment that
surrounds the system, produced by the system,
used by the system.
used by the system.
• Every attendee is asked to make a list of
services (processes or functions that
manipulate or interact with the objects) and a list
of constraints (cost, size) & performance
criteria (speed, accuracy, response etc.)

24. F.A.S.T.- 4
• Each attendee presents the list of objects,
services, constraints & performance.
• Prepare the common list.
• Discuss the common list & prepare a consensus
list.
list.
• Divide the whole team into sub-teams to prepare
mini specs. for one or more entries of the list.
• Present the mini specs. Addition/deletion is
permitted.
• Create a list of validation criteria.
• Designate a team to write complete draft specs.

25. Quality Function Deployment
(QFD)
• Is a quality management technique that translates
the needs of the customer into technical
requirements.
• Concentrates on maximizing customer satisfaction.
• Concentrates on maximizing customer satisfaction.
• Emphasizes on what is valuable to the customers
and then deploys these values during SE process.
• QFD generally identifies three types of
requirements.

26. QFD
• Customer’s needs imply technical requirements:
– Normal requirements: If these requirements are
present the customer is satisfied (minimal
functional & performance).
– Expected requirements: These are implicit and
– Expected requirements: These are implicit and
so fundamental in nature that customer does
not explicitly states them (important implicit
requirements, i.e. ease of use, learn, and
operate).
– Exciting requirements: Beyond the customers
expectation (may become normal requirements
in the future, highly prized & valued).

27. Q.F.D.
• Function Deployment:
– Determines value of required function.
• Information Deployment:
– Focuses on data objects and events
– Focuses on data objects and events
produced or consumed by the system.
• Task Deployment:
– product behavior and implied operating
environment.

28. QFD

29. Q.F.D.
• Value Analysis makes use of
– Customer interviews.
– Observations.
– Surveys.
– Historical data.
– Historical data.
• to create
– Customer Voice Table (Table of requirements).
– extract expected requirements
– derive exciting requirements

30. Use Case Diagrams
• Scenarios that describe how the product will be used in
specific situations.
• Use cases capture who (actor) does what (interaction) with
the system, for what purpose (goal), without dealing with
system internals.
• Written narratives that describe the role of an actor (user
• Written narratives that describe the role of an actor (user
or device) as it interacts with the system.
• Use-cases designed from the actor's (End user) point of
view.
• Not all actors can be identified during the first iteration of
requirements elicitation.
• But it is important to identify the primary actors before
developing the use-cases.

31. Use Case Diagrams

32. Use Case Diagrams

33. Use Case Diagrams

34. Use Case Diagrams

35. Use Case Template
• Brief Description: Background
• Actors that interact with the use case
• Flow of events
– Basic: Primary events that occur when use case is
executed.
executed.
– Alternative: Any subsidiary events that occur in use case.
• Preconditions
• Post conditions
• Special Requirements : Business rules for the basic and
alternative flows should be listed as special requirements. Both success
and failure scenarios should be described.
• Extension Points

36. Use Case Template

37. Use Case Template

38. Use Case Guidelines

39. Use Case Conventions

40. Use Case Conventions

42. Use Case Description
------- User Name, Role, Password

43. Use Case Description

44. Use Case Description

49. Information Domain
• Encompasses all data objects that contain
numbers, text, images, audio, or video.
• Information content or data model (ERD)
– shows the relationships among the data and
control objects that make up the system.
control objects that make up the system.
• Information flow (DFD)
– represents manner in which data and control
objects change as each moves through system.
• Information structure
– representations of the internal organizations of
various data and control items (DD).

50. Modeling
• Data model (ERD)
– shows relationships among system
objects.
• Functional model (DFD)
• Functional model (DFD)
– description of the functions that enable the
transformations of system objects.
• Behavioral model (STD)
– manner in which software responds to
events from the outside world.

51. Analysis Model Objectives
• Describe what the customer requires.
• Establish a basis for the creation of a
software design.
software design.
• Devise a set of requirements that can
be validated once the software is built.

52. Analysis Model Elements
• Data Dictionary (DD)
– contains the descriptions of all data objects
consumed or produced by the software.
• Entity Relationship Diagram (ERD)
– depicts relationships between data objects.
– depicts relationships between data objects.
• Data Flow Diagram (DFD)
– provides an indication of how data are transformed
as they move through the system; also depicts
functions that transform the data flow
– a function is represented in a DFD using a process
specification or PSPEC

53. Analysis Model Elements
• State Transition Diagram (STD)
– indicates how the system behaves as a
consequence of external events.
consequence of external events.
– states are used to represent behavior
modes.
– arcs are labeled with the events triggering
the transitions from one state to another.
– control information is contained in control
specification or CSPEC.

54. Data Dictionary
DD are repositories to store information about all
data items defined in DFD. Entities are
• Name: Primary name for each data or control item,
data store, or external entity
• Alias: Alternate names for each data object
• Where/How used : Listing of processes that use the
• Where/How used : Listing of processes that use the
data or control item and how it is used
• input to process
• output from process
• as a store
• as an external entity
• Content Description: Notations to represent content
• Supplementary information: Other data type
information, preset values, restrictions, limitations, etc.

56. Example
• name: telephone number
• aliases: none
• where used/how used: dial phone (input)
assess against set−up (output)
• description:
telephone number = [local number | long distance
telephone number = [local number | long distance
number]
local number = prefix + access number
long distance number = 1 + area code + local number
area code = [800 | 888 | 561]
prefix = *a three digit number that never starts with 0
or 1*
access number = *any four digit string*

58. ERD Elements
• Data object/Entity
– any person, organization, device, or software
product that produces or consumes information
• Attributes
– name a data object instance, describe its
characteristics, or make reference to another data
object
• Relationships
– indicate the manner in which data objects are
connected to one another

63. Cardinality and Modality
• Degree: Refers to the number of entities
participating in the relationship.
• Cardinality
– in data modeling, cardinality specifies how the
number of occurrences of one object are related to
number of occurrences of one object are related to
the number of occurrences of another object (1:1,
1:N, M:N)
• Modality
– zero (0) for an optional object relationship
– one (1) for a mandatory relationship

67. Creating ER Diagrams
• Customer is asked to list "things" that application
addresses.
• These things evolve into input objects, output
objects, and external entities.
• Analyst and customer define connections among
• Analyst and customer define connections among
the objects.
• One or more object-relationship pairs is created
for each connection.
• Cardinality and modality are determined for an
object-relationship pair.
• Attributes of each entity are defined.
• ERD is reviewed and refined.

68. Functional Modeling DFD
• Shows the relationships among external
entities, process or transforms, data items
and data stores.
• DFD’s only show the flow of data through the
software system and can’t show procedural
details like conditionals or loops.
details like conditionals or loops.
• Refinement from one DFD level to the next
should follow approx. 1:5 ratio.
• This ratio will reduce as the refinement proceeds.
• To model real-time systems, structured analysis
notation must be available for time continuous
data and event processing.

69. Creating DFD
• Level 0 DFD should depict the system as a
single bubble with Primary input and output.
• Refinement should begin by consolidating
candidate processes, data objects and data
stores to be represented at the next level.
stores to be represented at the next level.
• Label all arrows with meaningful names.
• Information flow must be maintained from one
level to the other.
• Refine/explore one bubble at a time.
• Write PSPEC for each bubble in the final
DFD.

70. Dataflow Diagram
Rectangle = information producer or consumer
Oval = software element that transforms information
Arrow = direction of data item flow
information repository (not shown)

71. Graphical Notation
–bubbles represent functions
–arcs represent data flows
–open boxes represent persistent store
–closed boxes represent I/O interaction
The function symbol
The data flow symbol
The data store symbol
The input device symbol
The output device symbol

72. Example
+ * +
a d
c
b
specifies evaluation of
(a + b) * (c + a * d)
*
(a + b) * (c + a * d)

73. A Construction “Method”
Input1 Output
1
1. Start from the “context” diagram
... ...
1
Input
2
Inputn
Output
1
Output
2
Output
m
information
system

74. A Construction “Method”
A
A1
A3
A4
I
O
I
H
J
2. Proceed by refinements until you reach
“elementary” functions (preserve balancing)
A1
A2
A4
A5
A6
A7
B1
B2
B3
B4
Ag
I
O
K
M
N
P Q
R
S
K
T
K1
K2
K3
K4
M
N

75. A Library Example
Shelves
List of Authors
Title and author
of requested book; name
of the user
Get a book
Book
Book title;
Book request
by the user
Book
reception
Book
Author
Title
List of titles
List of topics
List of books borrowed
Book title;
user name
Topic request
by the user
Search by
topics
Topic
List of titles
referring to the topic
Title
Display of
the list of titles
Topic

76. Refinement of
“Get a book”
Shelves
List of Authors
Book
Book
Book
Author Get
the book
List of titles
Title and author
of requested book;
name of the user
List of books borrowed
Book title;
user name
Book request
by the user
Book
reception
Title
Find
book
position
<shelf#, book#>

77. Patient monitoring systems
The purpose is to monitor the patients’vital factors--blood,
pressure, temperature, …--reading them at specified frequencies
from analog devices and storing readings in a DB. If readings fall
outside the range specified for patient or device fails an alarm
must be sent to a nurse. The system also provides reports.
Patient
Nurse
Patient
Monitoring
Nurse
Persistent data
Report
Alarm
Data
Clinical
Report
Request
Recent data
Data for report

78. A refinement
Nurse
Patient archive
Report
Request
Update
archive
Generate
Report
Data for
Report
Recent
Data
Formatted data
Report
Nurse
Limits for patient
Monitoring
Central
Limits
Formatted data
Alarm
Patient
Clinical
Data
Monitoring
Local
Patient data

79. More refinement
Limits
data
Patient
decode
Check
violations
limit
Temperature
Pulse
Pressure
Pressure, pulse…
Formatted data alarm
Result
Pressure, pulse…
Format
data clock
Date
Time
produce
message

80. Behavioral Modeling (STD)
• State transition diagrams represent the
system states and events that trigger state
transitions.
• STD's indicate actions taken as consequence
of a particular event.
• A state is any observable mode of behavior
• Control Flow Diagrams (CFD) can also be
used for behavioral modeling.

81. State Transition Diagram

82. STD Elements
• STD = { S, I, F, S0,  }
• Set of machine states S
• S  S start state
• S0  S start state
• F  S set of final state(s)
• I: set of input symbols
• Transition function
 (Si , Ij)  Sj

83. Example: a lamp
Push switch
On Off
Push switch

84. FSMs as recognizers
q
<letter>
<letter>
_
q q
0 1 2
<letter>
<digit>
<digit>
<letter>
Legend: is an abbreviation for a set of arrows
labeled a, b,..., z, A,..., Z,
respectively
is an abbreviation for a set of arrows
labeled 0, 1,..., 9, respectively
<digit>
<letter>

85. STD of Washing Machine
Idle
Filling Stop/Disable Washing
Stop/Disable Filling
Stop/Enable Filling
Washin
g
Spin-dry
Stop/Disable Washing
Washing Over/Enable Spin-dry
Washer Filled/Enable Wash
Spin-dry done/Disable Spin-
dry

86. Elements of Analysis Model
ERD
Data
Dictionary DFD
STD

87. Decision Table
•Notation that translates complex combination
of conditions and corresponding actions into
tabular form.
•It consists of condition stubs, condition rules
and action stubs, action rules.
Rules
Condition Stubs 1 2
Action Stubs 1 2

88. Condition Stubs Condition Rules
N not numeric T F F F
N <= 1 - T F F
N legal - - T F
N prime - - T F
Example
N prime - - T F
Action Stubs Action Rules
Print “N prime” X
Print “N not prime” X
Print error message X X
Print “Good bye” X X
Input new value for N X X
Stop X X

89. SRS Document Format
• INTRODUCTION
– System Reference
– Overall Description
– Software Project Constraints
– Software Project Constraints
• INFORMATION DESCRIPTION
– Information Flow Representation
• Data Flow
• Control Flow
– Information Content Representation (DD)
– System Interface Description

90. SRS Document Format
• FUNCTIONAL DESCRIPTION
– Functional Partitioning
– Functional Description
• Process Narrative
• Process Narrative
• Restrictions/Limitations
• Performance Requirements
• Design Constraints
• Supporting Diagrams

91. SRS Document Format
• CONTROL DESCRIPTION
– Control Specifications
– Design Constraints
• BEHAVIORAL DESCRIPTION
– System States
– System States
– Events and Actions
• VALIDATION CRITERIA
– Performance Bounds
– Classes of Tests
– Expected Software Response
– Special Considerations
• BIBLIOGRAPHY and APPENDIX

92. Software Quality
The narrowest sense of product quality is
commonly recognized as lack of “bugs” in
the product.
This definition is usually expressed in two
ways:
ways:
 defect rate (Number of defects per millions of
lines of source codes, per function point, or
other units)
 Reliability (Probability of failure-free operation
in a specified time and environment).

93. Software Quality
 In addition to overall customer satisfaction with
software product, satisfaction towards specific
attributes is also measured.
 IBM monitors the CUPRIMDSO (capability,
usability, performance, reliability, installability,
usability, performance, reliability, installability,
maintainability, documentation /information,
service, and overall)
 HP focuses on FURPS (Functionality, usability,
reliability, performance, and serviceability).

94. Defining Software Quality
• Two definitions of the quality, which are consistent
and have been adopted & used
– Quality is conformance to requirements
– Quality is fitness to use
• Because of the two perspectives of quality the de
• Because of the two perspectives of quality the de
facto definition of quality consists of two levels.
• The first is the intrinsic product quality, often
operationally limited to product defect rate and
reliability. This narrow definition is referred to as the
“small q” (Lack of bugs)
• The broader level of the definition of quality includes
product quality, process quality, customer satisfaction,
etc. and it is referred to as “big Q

95. Quality Concepts - 1
• Variation control is the heart of quality control
• Software engineers strive to control the
– process applied
– resources expended
– end product quality attributes
– end product quality attributes
• Quality of design
– refers to characteristics designers specify
for the end product to be constructed.
• Quality of conformance
– degree to which design specifications are
followed in manufacturing the product.

96. Quality Concepts - 2
• Quality control
– series of inspections, reviews, and tests
used to ensure conformance of a work
product to its specifications.
product to its specifications.
• Quality assurance
– auditing and reporting procedures used to
provide management with data needed to
make proactive decisions.

97. Quality Costs
• Prevention cost
– quality planning, formal technical reviews, test
equipment, training.
• Appraisal cost
– in-process and inter-process inspection,
equipment calibration and maintenance,
– in-process and inter-process inspection,
equipment calibration and maintenance,
testing.
• Failure cost
– rework, repair, failure mode analysis.
• External failure cost
– complaint resolution, product return and
replacement, help line support, warranty work.

98. Schematic Diagram of Quality
Assessment
Identifying quality attributes, quality
carrying properties, quality metrics, and
defining mapping that connects these
aspects by relating them together.
Identify
Quality
Attributes
Select
Quality
Properties
Select
Quality
Metrics
Total Quality Index

99. Software Quality Metrics
Factors assessing software quality come
from three distinct points of view (product
operation, product revision, product
modification).
Defect removal efficiency (DRE) is a
Defect removal efficiency (DRE) is a
measure of the filtering ability of the quality
assurance and control activities as they are
applied through out the process framework.
DRE = E / (E + D).
E = # of errors found before delivery
D = # of errors found after delivery

100. Software Quality Metrics
 Software quality factors requiring measures:
 correctness (defects per KLOC)
 maintainability
 mean time to change (MTTC)
 spoilage = (cost of change / total cost of
 spoilage = (cost of change / total cost of
system)
 integrity
threat = probability of attack (that causes failure)
security = probability that the attack is repelled
Integrity =  [1 - threat * (1 - security)]

101. Software Reviews
 Purpose is to find defects (errors) before they
are passed on to another software
engineering activity or released to the
customer.
 Software engineers (and others) conduct
 Software engineers (and others) conduct
formal technical reviews (FTR).
 Using formal technical reviews (walkthroughs,
Deskchecks, Code Review or inspections) is
an effective means for improving software
quality.

102. Why do Peer Reviews?
 To improve quality.
 Catches 80% of all errors if done
properly.
 Catches both coding errors and design
errors.
 Enforce the spirit of any organization
standards.
 Training and insurance.

105. Defect Prevention/ Removal
• S/w contains 200K lines
• Inspection time = 7053 Hrs.
• Defects prevented = 3112
• Programmer cost = 40.00 per hr.
• Programmer cost = 40.00 per hr.
• Total cost of defect prevention = 7053 x 40.00
= 282120.00
• Cost per defect prevention = 282120/3112
= 91.00

106. Defect Removal
• Defect escaped into product = 1 per 1K
• Total defects escaped = 200K/1000
= 200
= 200
• Cost of removal of single defect = 25000
• Total defect removal cost = 25000 x 200
= 5000000
• Ratio of defect removal to prevention = 18

107. Software Quality Assurance
(SQA)
• SQA is a collection of activities during software
development that focus on increasing the
quality of the software being produced
• SQA is often conducted by an independent
• SQA is often conducted by an independent
group in the organization
• Often this group has the final veto over the
release of a software product

108. SQA includes
• Analysis, design, coding and testing methods
and tools.
• Formal Technical reviews during software
development.
• A multi-tiered testing strategy.
• A multi-tiered testing strategy.
• Control of software documentation and the
changes made to it.
• Procedures to ensure compliance with software
development standards.
• Software measurement and reporting
mechanisms.

109. Statistical Quality Assurance
• Information about software defects is
collected and categorized.
• Each defect is traced back to its cause
• Using the Pareto principle (80% of the
• Using the Pareto principle (80% of the
defects can be traced to 20% of the
causes) isolate the "vital few" defect
causes.
• Move to correct the problems that
caused the defects.

110. Phase wise Statistics of Errors
Error
Causes
Total Serious Moderate Minor
# % # % # % # %
IES n1 p1 n11 p11 n12 p12 n13 p13
MCC n2 p2 n21 p21 n22 p22 n23 p23
MCC n2 p2 n21 p21 n22 p22 n23 p23
MIS n12 p12 n121 p121 n122 p122 n123 p123
Ei Si Mi Ti
Ei: Total number of errors Si: Number of serious
errors
Mi: Number of moderate errors Ti: Number of minor
errors

111. Quality Indicator
• S: Size of the product
• Weighing factors Ws=10, Wm=3, Wt=1 are
assigned to serious, moderate and minor errors
respectively
• Phase Index for ith phase (PIi) is
PIi = Ws(Si/Ei)+Wm(Mi/Ei)+Wt(Ti/Ei)
• Error Index (EI) is calculated by assigning
weights to different phases (Wi)
EI = Sum(Wi*PIi)/S
• Error index acts as an indicator for the quality of
the software

112. ISO 9126 Standard
• Another product oriented attempt to
define software quality attributes.
• A user view of software quality.
• A user view of software quality.
• Defines certain quality characteristics.
• ISO 9126 doesn’t address software
process issues.

113. ISO 9000
• A set of quality standards developed so that purchasers
of goods can have confidence that suppliers have
produced something of acceptable quality.
• ISO 9000 certification has become a widely required
international standard.
• Any supplier who is not ISO 9000 certified will find it
• Any supplier who is not ISO 9000 certified will find it
difficult to sell their goods.
• The ISO 9000-3 standard describes how to apply the
general ISO 9000 standard to the software industry.
• The ISO standard addresses design, development,
production, installation and maintenance issues.
• The emphasis in the ISO standard is on documentation of
the process and the managing of the process.

114. ISO 9001 Components
1. Management responsibility
2. Quality system
3. Contract review
4. Design control
4. Design control
5. Document and data control
6. Purchasing
7. Control of customer-supplied
8. Product identification
9. Process control
10. Inspection and testing

115. ISO 9001 Components
11. Control of inspection, measuring, test equipment
12. Inspection and test status
13. Control of non-conforming product
14. Corrective and preventive action
15. Handling, storage, packaging, preservation,
15. Handling, storage, packaging, preservation,
delivery
16. Control of Quality records
17. Internal Quality Audits product
18. Training and traceability
19. Servicing
20. Statistical techniques

116. ISO 9000 Registration
• The effort required to obtain ISO 9000 registration
varies directly with how closely an organization’s
process fits the ISO 9000 model.
• ISO 9000 registration is granted when an accredited
inspection organization certifies that the
inspection organization certifies that the
organization’s practices conform to the ISO
standard.
• Re-registration is required every 3 years and
surveillance audits are performed every 6 months.
• ISO registration can cost a lot of time, effort and
money to achieve. It requires continuing effort to
stay registered.

117. A Cynic’s View of ISO 9000
• ISO 9000 focuses on how well the processes are
documented, not on the quality of the process.
• Many companies do the minimum required to
achieve ISO 9000 for business reasons, but forget
about it as soon as the ISO 9000 inspectors have
about it as soon as the ISO 9000 inspectors have
signed off.
• ISO 9000 is based on the faulty premise that work is
best controlled by specifying and controlling
procedures.
• Your product and the processes used to produce it
can be absolutely terrible but you can get ISO 9000
as long as the processes are well documented.

118. The SEI’s Capability Maturity Model
The Capability Maturity Model for Software (CMM) is a
five level model laying out a generic path to process
improvement for a software organization.
1. Initial – ad hoc
2. Repeatable – basic management processes
3. Defined – management. and engineering
3. Defined – management. and engineering
processes documented, standardized,
integrated, and actually used.
4. Managed – measured and monitored and
controlled using measurements.
5. Optimizing – Continuous process improvement
is enabled by quantitative feedback from the
process and from piloting innovative ideas and
technologies.

119. CMM Levels and Key Process Areas
1. Initial level
– No formalized procedures, project plans, cost estimates.
– Tools not adequately integrated.
– Many problems overlooked/ignored.
– Maintenance very difficult
– Generally ad-hoc processes
– Generally ad-hoc processes
2. Repeatable level
– Requirements management
– Software Project planning
– Software project tracking and oversight
– Software subcontract management
– Software quality assurance
– Software configuration management

120. CMM Levels and Key Process Areas
3. Defined level
– Organization process focus
– Organization process definition
– Training Program
– Integration software management
– Software product engineering
– Inter group coordination
– Inter group coordination
– Peer reviews
4. Managed level
– Quantitative process management
– Software Quality management
5. Optimizing level
– Defect prevention
– Technology change management
– Process change management