Types of Metrics

• Size—Function Points 

1. A major problem after requirements are done is to estimate the effort and for the project. For this, some metrics are needed that can be extracted from the requirements and used to estimate cost and schedule (through the use of some model).
2. As the primary factor that determines the cost (and schedule) of a software project is its size and functionality of the system

•  Size-Oriented Metrics

1. Size-oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced.
2. The size could be in number of pages, number of paragraphs, number of functional requirements, etc.

• Function-Oriented Metrics
• Function-oriented software metrics use a measure of the functionality, that is, what the system performs, is the measure of the system size.
• Since ‘functionality’ cannot be measured directly, it must be derived indirectly using other direct measures.
• Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity.
• The system functionality is calculated in terms of the number of functions it implements, the number of inputs, the number of outputs, etc.—parameters that can be obtained after requirements analysis and thatare independent of the specification (and implementation) language.
• The original formulation for computing the function points uses the count of five different parameters, namely, external input types, external output types, logical internal file types, external interface file types, and external inquiry types.
• To account for complexity, each parameter in a type is classified as simple, average, or complex.
• Drawback of the function point or function- oriented metrics approach is that the process of computing the function points involves subjective evaluation at various points, may not be unique and can depend on the analyst.
• Some of the places where subjectivity enters are:
• (1) different interpretations of the SRS (e.g., whether something should count as an external input type or an external interface type; whether or not something constitutes a logical internal file; if two reports differ in a very minor way should they be counted as two or one);
• (2) complexity estimation of a user function is totally subjective and depends entirely on the analyst (an analyst may classify something as complex while someone else may classify it as average)
• The main advantage of function points over the size metric of KLOC, is that the definition of DFP depends only on information available from the specifications, whereas the size in KLOC cannot be directly determined from specifications.
• The DFP count is independent of the language in which the project is implemented.

•  Quality Metrics

1. the quality of the SRS has direct impact on the cost of the project. Hence, it is important to ensure that the SRS is of good quality.
2. Quality of an SRS can be assessed either directly by evaluating the quality of the document by estimating the value of one or more of the quality attributes of the SRS, or indirectly, by assessing the effectiveness of the quality control measures used in the development process during the requirements phase.
3. Quality attributes of the SRS are generally hard to quantify and determining correlation with project parameters. Hence, the use of these metrics is still limited.
4. Process-based metrics are better understood and used more widely for monitoring and controlling the requirements phase of a project.

• Number of errors found is a process metric that is useful for assessing the quality of requirement specifications.
• Once the number of errors of different categories found during the requirement review of the project is known, some assessment can be made about the SRS from the size of the project and historical data.
• The error distribution during requirement reviews of a project will show a pattern similar to other projects executed following the same development process.
• For example, if much fewer than expected errors were detected, it means that either the SRS was of very high quality or the requirement reviews were not careful.
• Further analysis can reveal the true situation. If too many clerical errors were detected and too few omission type errors were detected, it might mean that the SRS was written poorly or that the requirements review meeting could not focus on "larger issues" and spent too much effort on "minor" issues.
• Again, further analysis will reveal the true situation. a large number of errors that reflect ambiguities in the SRS can imply that the problem analysis has not been done properly.
• Some project management decision to control this can then be taken (e.g., build a prototype or do further analysis).
• Change request frequency can be used as a metric to assess the stability of the requirements and how many changes in requirements to expect during the later stages.
• The frequency of changes can also be plotted against time. For most projects, the frequency decreases with time.
• For a project, if the change requests are not decreasing with time, it could mean that the requirements analysis has not been done properly. Frequency of change requests can also be used to "freeze" the requirements—when the frequency goes below an acceptable threshold, the requirements can be considered frozen and the design can proceed. The threshold has to be determined based on experience and historical data.