UNIT 7 SPECIFICATION OF QUALITY REQUIREMENTS Flashcards
What is the definition of “software quality” and what does entail?
In a general sense, the standard ISO defines software quality as “the capability of a software product to satisfy stated and implied needs when used under specified conditions”. Software must therefore be reviewed to determine whether
the delivered product meets the previously defined requirements or needs. The standard stresses the importance of specification in this connection, stating that software quality cannot be determined without explicitly stated needs. This poses the challenge of how to specify quality. The earlier identification of requirements often includes only very generalized quality requirements, if at all. Examples might be: “The system must offer good usability,” “the system must be secure,” or “the system must be easy to maintain.” While all these statements concern the system’s quality, they are too general and too abstract for the software architect or developer to derive specific system requirements. Furthermore, these requirements are not suitable for use as the basis for preparing test cases with which to document the required quality. As well as the functional requirements placed on a system or component, it is equally important to specify its quality requirements.
What are Quality Requirements and how could you check if they were accurately described?
Quality requirements define which qualitative properties the system must fulfill. They do not describe new functions but add qualitative and quantitative requirements to concep-
tual functions.
The conceptual/technical specification must refine quality requirements, firstly to reflect the stated needs of users, and secondly to define the system’s specific, measurable properties. The totality of quality requirements ultimately describes a software system’s quality objective.
The SMART model used in project management and human resources development is ideal for gauging whether quality requirements have been adequately described. Both of these industries agree targets and then review their achievement. The definition of quality requirements for software systems is well-suited to the SMART technique. SMART is an acronym coined by Schiersmann and Thiel (2000) as follows:
* S = specific. Quality requirements should be clearly described and defined.
* M = measurable (qualitative, quantitative). It must be possible to verify implementation of the quality requirements.
* A = acceptable. The quality requirements, including the testing methods used, must be accepted by the project’s stakeholders.
* R = realistic. Quality requirements must be achievable, with due regard for functional and organizational framework conditions.
* T = time-bound. Quality requirements must be implemented within a set time frame, e.g., in a certain release.
What are Quality Models?
Quality models, particularly software quality models, are a way of making the abstract concept of “quality” more tangible. The basic precept of a quality model is that the more abstract, general concept of quality is broken down into various sub-concepts. These subconcepts, in turn, are broken down further until it becomes possible to formulate a specific, measurable quality characteristic. Quality models comprise a hierarchy of concepts used to specify more tangible quality requirements.
The term quality is broken down into eight sub-features, which, in turn, are sub-divided further. This type of quality model is also known as an FCM model: factor (in this case, feature), criteria (in this case, sub-feature), and metrics (in this case, indicators). It references the inner structure of the quality model.
Organization-specific quality models often exist and describe those features and sub-features which the company considers particularly important. Quality models are just one
tool for the structured, methodical specification of quality requirements.
What are factors, criteria and metrics in the FCM Quality Model?
- Factor (in this case, feature): A factor uses a single term to
summarize various aspects of quality. It is the first layer of the FCM model. - Criteria (in this case, sub-feature): A criterion focuses on one aspect of a quality feature. If necessary, sub-features may be broken down further into individual aspects (sub-sub-features).
- Metrics (in this case, indicators): An indicator is a specific,
observable feature of a software system. Indicators allow statements to be made on whether a required sub-feature is fulfilled.
What is the GQM Method and what does it do?
The goal/question/metric method (GQM method) is a model for specifying verifiable quality requirements and performing measurements. The GQM aims to develop quality requirements that are tailored to a specific software system. The quality requirements placed on the system will vary depending on the nature of the project. The specification of quality requirements for industrial information systems tends to be very selective and confined to very specific aspects of the system.
It is not generally possible to specify every conceivable quality requirement for an information system. When specifying quality, therefore, the key is to focus on the most important functions for that particular sector, and to limit yourself to specifying two to three quality requirements
initially, only incorporating additional quality requirements where necessary.
Name the 7 steps that are part of the GQM Method.
- Define the evaluation goals.
- Refine the evaluation goals with a quality model.
- Derive questions.
- Derive metrics.
- Define the specific measurements required.
- Define the measurement procedure and mechanisms.
- Formulate verifiable quality requirements.
Define the first step of GQM Method (Define evaluation goals).
The first step when specifying quality is to define specific goals. A goal is formulated using a fixed sentence structure and is sub-divided into the following aspects:
* purpose. What do I want to achieve? (e.g., improve, monitor, and evaluate)
* quality requirement. Which requirement is under scrutiny here?
* object. Which specific element of the system (e.g., component, graphical user interface [GUI], or interface) is under scrutiny?
* perspective. Which stakeholder perspective am I considering?
This sharpens the focus for subsequent analysis of the requirement “user-friendliness.”
Define the second and third step of the GQM Method (Refine the evaluation goals with a quality model and derive questions).
Despite having sharpened the focus on identified quality requirements in step one, the formulated goals are usually still too abstract for the derivation of specific metrics, so step two refines these quality requirements further until specific questions can be asked. The quality model helps us to derive sub-features as precisely as possible. Identifying and defining the relevant sub-features of sub-features is a creative process. The sub-features are continuously refined until they reach the point where specific questions can be formulated.
In this instance, the stakeholders rate clarity and efficient operation as particularly important. In stage three of the
GQM method, the questions should be formulated in a way that allows compliance with the quality goal to be verified from the answers. As such, the formulated questions should invite yes or no answers wherever possible. Once the questions have been formulated, their connection to the aspired evaluation goal formulated in step one should be checked.
Define the fourth and fifth step of the GQM Method (Derive indicators and specify the metrics).
Step four should define the indicator for answering the question. The first thing to do is to define the yardstick or metric used for measuring, independently from the actual measurements.
In other words, the “unit” of measurement. As a general rule, both objective and subjective metrics are supported. Objective metrics can be measured directly on the system. Subjective metrics are obtained from surveys or tests with individuals who work on or with the system.
When formulating the indicators, a target measurement is not yet defined at this stage.
The target values are defined in step five; see the following table for an example. The values defined here provide the development team with guidance when designing the system. Later when the system undergoes quality assurance testing, these values will be checked. The definition of target measurements is essentially a quantification of quality requirements. In other words, the defined system quality is determined from the totality of all defined target values.
Define the sixth step of the GQM Method (Define the measurement procedure and mechanisms).
As well as determining the metrics for measuring values, it is necessary to specify how the measurement should be conducted. With subjective metrics in particular, the quality of the description of measurement is largely determined by the technique employed.
Specifying the measurement technique simultaneously serves to gauge the testability of the quality characteristic. If the measurement cannot be calculated, or if a reliable calculation cannot be made for technical or financial reasons, steps four and five should be repeated until a feasible measurement technique has been identified.
Define the seventh step of the GQM Method (Formulate verifiable quality requirements).
Based on the questions and values identified in steps one to six, it is now possible to specify precise, verifiable quality requirements. To this end, the results from steps one to six are reformulated into a requirement incorporating the metrics, the object to be measured, and the target measurements. With subjective metrics, the measurement technique should likewise be taken into account.
