The document discusses metrics for evaluating the quality of software specifications. It defines key terms like measures, metrics, and indicators. It then provides examples of metrics that can measure the completeness, lack of ambiguity, and other qualities of a software specification. These include calculating the total number of requirements and the number that are unambiguous. The document also discusses using metrics in small organizations and provides an example where metrics are used to analyze efforts to reduce the time taken to implement change requests.

1. PRESENTATION NO: 2
TOPIC: METRICS FOR SPECIFICATION QUALITY
SUBJECT: SOFTWARE ENGINEERING II
BY: RAHAT ULLAH
&
MINHAJ-UD-DIN

2. METRICS FOR SPECIFICATION QUALITY
• Definition:
software matrix can be defined as “the continuous
application of measurement based techniques to the
software development process and its products to
supply meaningful and timely management
information, together with the use of those techniques
to improve the process and its products”.

3. MEASURES, METRICS, AND INDICATORS
• These three terms are often used interchangeably, but they can
have subtle differences
• Measure
• Provides a quantitative indication of the extent, amount, dimension,
capacity, or size of some attribute of a product or process
• Measurement
• The act of determining a measure
• Metric
• (IEEE) A quantitative measure of the degree to which a system,
component, or process possesses a given attribute
• Indicator
• A metric or combination of metrics that provides insight into the
software process, a software project, or the product itself

4. METRICS FOR SPECIFICATION QUALITY
•As mentioned in earlier lectures , the quality of
the software specification is of extreme
importance as the entire building of software is
built on this foundation
•A requirement specification document is
measured in terms of lack of completeness,
consistency, correctness, understand ability,
verifiability, achievability, concision and

5. HISTORY
• Metrics to assess the quality of the analysis models
and the corresponding software specification were
proposed by Davis in 1993 for these
seemingly qualitative characteristics.

6. AREAS OF APPLICATIONS
• The most established areas of software metrics is cost
and size estimation techniques
• The predication of quality levels for software is often
in terms of reliability , is another area where software
metrics have an important role to play
• The use of software matrix to provide quantitative
checks on software design is also well established
area.

7. EXAMPLES
•The numbers of requirements are calculated as:
nr=nf+nnf
Where
• nr = total number of requirements
• Nf= functional requirements
• nnf = non-functional requirements

8. EXAMPLES(CONT……)
• Now lack of ambiguity in the requirements is
calculated as:
Q1 = nui/nr
Where
• nui = number of requirements for which all
reviewers had identical interpretation (i.e.
unambiguous requirements)

9. EXAMPLES(CONT…)
Similarly
Completeness
Q2 = Nu / [Ni*Ns]
U=unique function
i=input
S=number of states

10. BASELINE:
• In order to use the data for estitmation and drawing
conclusions, it must be base-lined.
• In the baseline, data from past projects is collected,
cleaned and put in a database.
• To be effective…
Data must be reasonably accurate
Should be collected over many projects
Same techniques for data collection will be used etc.

11. METRICS FOR SMALL ORGANIZATION
• The metrics program can be quite complex and extensive.
• However, it is important to appreciate that a metrics program
of even a smaller scale would also be of immense value.
• Metrics for small organization…i.e round about 20 people.
• In order for it to be effective, it should be simple and
value oriented and should focus on result rather then
measurement
• It is important to establish the objectives of
measurement.

12. EXAMPLE
Let us assume that we wanted to reduce the time to evaluate and
implement change request in our organization. In order to achieve
this objective, we need to measure the following.
Effort to perform evaluation _____W eval
Time elapsed from completion of assignment of change
order_______T evla
Effort required to make change_______W change
Time required to make change________T change
Errors uncovered during work_________E change
Defects uncoverd during work_________D change

13. Someone want to reduce the time to evaluate and implement
change requests in an organization
Proje
ct
Size
(FP)
Effort
(PM)
Cost
(RS)
Pages of
documentatio
n
Pre-
shipment
errors
Post
shipment
errors
people
X 120 24 168000 365 134 29 3
y 270 62 440000 1224 321 86 5
Z 200 43 314000 1050 256 64 6

14. The data is then normalized on per
function-point basis as follows
Proje
ct
Size
(FP)
Effort
(PM)
Cost
(RS)
Pages of
documentatio
n
Pre
shipment
errors
Post
shipment
errors
people
X 120 0.2 1400 3.04 1.12 0.24 3
y 270 0.23 1629 4.53 1.19 0.32 5
Z 200 0.22 1570 5.25 1.28 0.32 6

15. • Now use that data to analyze the results
of process change in and their impact on
the time to implement change request
• In order to do that, we need to employ
some statistical techniques and plot the
result graphically. This is known as
statistical control techniques.

16. WHY HAVE SOFTWARE PRODUCT METRICS?
• Help software engineers to better understand the attributes of
models and assess the quality of the software
• Help software engineers to gain insight into the design and
construction of the software
• Focus on specific attributes of software engineering work
products resulting from analysis, design, coding, and testing
• Provide a systematic way to assess quality based on a set of
clearly defined rules
• Provide an “on-the-spot” rather than “after-the-fact” insight
into the software development

18. THE END
Thank you for attention….

19. COMPONENTS OF MATRIX
• Size kloc
• Effort person/month
• Productivity kloc/person month
• Quality no of faults/kloc
• Cost doller/KLOC
• Documentation page of documents/KLOC
• LOC
• Project
• Direct matric
• Indirect metric
• Fault
• Error
• defect