STEP 2: IDENTIFY PRODUCT QUALITY NEEDS 3-13
Survey product quality needs Activity
2-1
• Identify product stakeholders
• Schedule and invite representatives of stakeholders to an interview
• Hold interviews
• Document interviews
Identify and invite product stakeholders
After collecting preliminary product improvement needs in Step 1, more information can be obtained by interviewing product ‘users’. The term
‘user’ not only refers to the actual users of the product, but also to anyone who is involved in specifying requirements, such as people from marketing, development, manufactur ing, etc. We call them ‘stakeholders’.
This survey must be organized in such a way that all stakeholders interested in the product are either consulted or repre sented. Some form of business or domain model ling is applied to deter mine all the stakeholders for a product.
‘Internal’ stakeholders should also be included, i.e. stakeholders within the organization that have specific demands for a product. For example, the manufacturing department that installs software in the product has demands regarding the release of the software and the corresponding installation documentation. Maintenance and operation support people should also be considered, as they have specific demands regarding product quality, and are often also very familiar with user preferences and requirements.
Each selected stakeholder is sent an invitation to an interview. This invitation may indicate the topics for discussion beforehand.
Hold interviews
In the open interviews for the survey, there are are basically five topics for discussion:
• List the exact tasks performed
STEP 2: IDENTIFY PRODUCT QUALITY NEEDS 3-15
This first topic is discussed to gain more insight into how ‘users’ works with the product. Interviewees are asked to list the exact tasks performed when handling the product. This provides an overview of the product’s con text of use.
• Effort needed for each task
The effort spent on these tasks is determined to provide an overview of the amount of time required.
• Previous quality problems
Interviewees are asked to recall any quality problems with the product, previous versions of the product, or other similar product types.
• Expected quality problems
Based on their experience and current understanding of the product, interviewees are asked whether they expect specific quality problems.
• Existing high quality products
The final topic deals with the product’s specifically good characteristics.
Interviewees are asked to give examples of good qualities that the product should possess. This is done simply to counterbalance the preceding questions, which discuss ‘bad’ quality in need of improvement. ‘Good’
quality must also be dealt with, in order to make sure that its level of quality is maintained.
Document interviews
Users express their wishes and requirements in their own terms, and rate them in order of importance. We want them to express their wishes in their own terms so that it must be quite clear what those needs are for specific contexts of use. Translating these requirements into more generic terms is another matter, and will be addressed later. A second point of discussion is for providing quantifiable criteria to create metrics for each wish that determine how well a product meets its requirements. It is not sufficient to simply state a demand, as whether or not it has been met is difficult to check. Users sometimes also speak in ‘solutions’, and ask for specific process solutions. However, it is better for users to speak in ‘problems’ or
‘product goals’ and leave the solving of these problems to the designers.
Their solutions have to be sufficient, and therefore we need to have measurable criteria that can be checked and managed. Metrics can be collected to evaluate a specific requirement, which must be guided by a wanted value. This indicates the value that the metric must have in order to fulfil the requirement. Metrics and wanted values should be retrieved from the interview and confirmed by the interviewee when reviewing the interview report.
Document product quality needs Activity
2-2
• Translate stakeholder wishes into generic terms
• Make a product quality profile
Interviews conducted with all the selected representa tives of typical and/or the most important users result in a list of wishes and require ments in the users’ own language. They must then be translated into generic terms that developers can work with. PROFES suggests using the ISO 9126 terms enhanced with cost and time-to-market. ISO 9126 classifies product quality by six product quality characteristics: functionality, reliability, usability, maintainability, efficiency, and portability. Furthermore, each characteristic is further refined into several sub-charac teristics.
Firstly, for each user wish/requirement the quality characteristic referred to should be identified and secondly, the respective quality sub-charac-teristics. This translation into ISO9126 terminology is an important step towards a generic product quality model, and is also not very difficult once the ISO9126 definitions have become fully familiar.
The ISO9126 definitions are:
Functionality – the capability of the software to provide functions that meet stated and implied needs when the software is used under specified conditions.
Reliability – the capability of the software to maintain the level of system performance when used under specified conditions
Usability – the capability of the software to be understood, learned, used, and liked by the user when used under specified conditions.
Efficiency – the capability of the software to provide the required performance relative to the amount of resources used under stated conditions.
Maintainability – the capability of the software to be modified.
Portability – the capability of software to be transferred from one environment to another.
STEP 2: IDENTIFY PRODUCT QUALITY NEEDS 3-17
Next, each stakeholder requirement has to be evaluated by the project manager, as everything can not be realized, as other objectives such as time and cost-effectiveness also play a part. A meeting should be held during which all product are discussed with the project manager, and all requirements are either accepted, rejected, or held pending.
These requirements and their target values need to be documented. We recommend visualizing these product quality targets in a product quality profile, which displays the targets according to ISO9126 dimensions. A product quality profile example is shown in Figure 3.2. In this example figure, ‘wanted value’ indicates the product quality requirements that were stated by all stakeholders. ‘Target value’ indicates the target that the project manager has set for the project. The scale in the figure is a modified ordinal scale of increasing requirements for reliability ranging from “D” to “A”. The project manager also recorded “wanted value” and
“target value” for cost and time-to-market.
D C B A Functionality
Reliability
Usability
Efficiency Maintainability
Portability
Wanted Value Target Value
Figure 3.2. Example product quality profile
Set preliminary product quality goals Activity
2-3
• Identify the product quality areas that require improvement
• Prioritize the product improvement areas
• Select the preliminary product quality goals
Product quality needs are transferred to preliminary product quality goals that reflect possible areas for further improvement. Based on the product quality targets classified according to ISO9126 (sub)-charac teristics, those areas requiring further attention should be prioritized, and made the responsibility of the project manager. With this list of priorities assigned to the product quality characteristics, a set of preliminary product quality goals is made available.