Lecture 5 & 6: Case Study and Metrics for Nonfunctional Requirements

Objective:
Highlight the importance of converting NFR into quantifiable form
Provide examples of Metrics which be used to quantify requirements or to derive customized metrics.

Goals and Nonfunctional Requirement
Non-functional requirements are sometimes written as general goals, which are difficult to verify. They should be expressed quantitatively using metrics (measures) that can be objectively tested

• Goal (unverifiable)
– The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized

• Non-functional requirement (verifiable)
– Experienced controllers shall be able to use all the system functions after a total of two hours’ training. After this training, the average number of errors made by experienced users shall not exceed two per day

With the help of following metrics the NFRs can be verified quantitatively. It should also be noted that the cost of quantitatively verifying each NFR may be very high

It must also be kept in mind that there may be other metrics for various non functional requirements and the following list just provides you some examples so that you are able to understand that how various NFRs can be made quantifiable.

Metrics for Non-Functional Requirements
Before moving ahead it is important that we understand the difference between terms, measure, measurement and metrics
Measure refers to an individual value where as Measurement refers to the process of calculating the value i.e. Measure. Metrics relate measures so that some conclusion or decision is made. For example there are two measures, LOC(Line of Code) and Total errors. If we combine these two (Total Errors/Kilo Loc) then we may be able to judge the skills of development team.

Speed
• Processed transactions/second (For Transaction Oriented Systems, e.g. POS Systems)
• Response time (Can be used for systems that perform very lengthy and complex tasks. For example a software to recover contents of hard drive )
• Screen refresh time. (For games)

Ease of use
1. Training time
2. Number of help frames

Reliability
1. Mean time to failure (For non repairable systems)
2. Mean time between failure (For repairable systems)
3. Probability of unavailability
4. Rate of failure occurrence
5. Availability

Robustness
It is the capability of system to function correctly in unexpected or abnormal situations
1. Time to restart after failure
2. Percentage of events causing failure
3. Probability of data corruption on failure

Portability
1. Percentage of target-dependent statements
2. Number of target systems

Reference: Lecture # 3 By Dr. Ghulam Ahmed Farrukh, Virtual University Pakistan