Requirements and Quality Function Deployment

Quality function deployment (QFD), also generally known as a way to represent the "voice of the customer" is a process for capturing customer requirements and translating them into requirements that can be used by designers, producers, and suppliers. As with many other topics mentioned in this section, there are several books, articles, consulting services, software, and Web sites devoted to QFD. It deserves mention in the context of requirements elicitation because the very first step in QFD is to "identify the customer's vital requirements for the product and translate them into design requirements". At this point in our software life cycle, we are not ready to translate customer requirements into design requirements - that comes later, after the SRS is written and analysis modeling occurs - but we are very interested in all methods of stakeholder requirements elicitation and capture.

The process of QFD can be found within methods of brainstorming, FAST, and JAD. With QFD, sharing of information is achieved through the efforts of a cross-functional team from various stakeholder groups such as marketing, sales, service, distribution, product engineering, process engineering, procurement, production, and of course, the end-user of the software system. A second QFD characteristic found throughout the requirements elicitation process has to do with capturing the requirements information in one place, in a compact form. Lastly, with QFD and other requirements elicitation methods, there is support for consensus and decision making, especially when complex relationships and trade-offs are involved to achieve the best overall solution. Such support is imperative, as we almost always deal with conflicting requirements when all stakeholders are represented.

The QFD method begins with these steps, which clarify the relationship with requirements elicitation:1. Identify the communities affected by the proposed system, e.g., customers, users, and developers. Also identify any initial constraints identified by the customer that affect requirements development.

2. Create high-level requirements from customer input, considering different viewpoints. Requirements are expressions of what the system will do, which is both perceptible and of value to customers. Because the needs or wishes are mostly thought of in customer language, developers often must help in adjusting them to be testable and measurable.

3. Assign a value, indicating a degree of importance rating, to each requirement. The customer determines if the requirement is: very important (5 points), important (4 points), not important, but nice to have (3 points), not important (2 points), or unimportant (1 point).

Some goals of QFD are parallel to the goals for requirements elicitation:

● Both endeavor to educate management on the importance of the elicitation phase and the benefits of promoting communication during this phase.

● Both strive to capture the "voice of the customer" allowing subsequent design decisions to be traced back to customer needs; the user community's views may be captured through the use of mock-ups and prototypes, as well as brainstorming, FAST, and JAD.

● Both promote group work to achieve the common goal of producing quality requirements and sharing ownership in them.

Advantages of using QFD during requirements elicitation include:

● Cross-functional communication and teamwork result in a more usable product.

● Prioritized requirements allow high-priority items to be undertaken early, and enhances resource allocation throughout the development cycle.

● Customer-focused activities lead to increased satisfaction with the product.

Quality function deployment reminds us that, in addition to functional and nonfunctional requirements, there are also: "normal" requirements that satisfy the customer; "expected" requirements that may not be explicitly stated by the customer, but their absence will cause significant dissatisfaction; and "exciting" requirements that go beyond the customer's expectations and prove to be very satisfying when present. Figure 1 points out that the range is from spoken requirements that please the customer when present, to unspoken requirements that displease the customer when absent.

On the other hand, requirements elicitators are not allowed to rest on their laurels. Over time, "delighting" requirements become "expected" requirements, and the customer will become dissatisfied if they are not present, spoken or otherwise (see Figure 2).

Prioritize Requirements

A theme throughout this blog, emphasized in "Software Size and Reuse Estimating" and "Estimating Duration and Cost" on software sizing and estimating, is that there are only so many degrees of freedom when planning and developing a software product. We can have fixed quality, fixed schedule, or fixed cost, but not all three. Most of the time, something has to give. Neither managers nor customers appreciate extended schedules or increasing costs, therefore we often plan for incremental deliveries, with only the most important features to be delivered first. (Of course, quality could be sacrificed, but that would rarely be a good idea.) This point in the product development cycle, when the requirements have been freshly gathered, is an ideal time to prioritize them. After this stage, deleting a requirement causes more consternation the further down the development process we travel. It is always expensive to develop software in a volatile requirements environment, but the worst dilemma of all is that the stakeholder's expectations will not be met.

When all stakeholder classes are identified and represented, as advised here, there are bound to be different, sometimes incompatible, goals for the project. Frequent communication with the customer and prioritization of the product's requirements will reduce project risk. As long as the important functions (so critical to mission success that they cannot be compromised) are delivered first, all functions are scheduled to be delivered at an agreed upon date, and the prioritization scheme is communicated to all stakeholders, there is diminished project angst.

Requirements prioritization can be a boon to many organizations relying on fiscal-year funding and can use remaining funds to acquire a scaled-down version of the product, as opposed to the optimal version, to meet budget constraints. The dialogue between stakeholders and developers should not stop at finding the topmost requirements, but continue to explore all meaningful options. When features of the product can be estimated for cost and schedule, stakeholders will have additional knowledge to aid decision-making.

Stakeholders will have their own unique set of criteria for determining the "importance" or value, of a requirement. It will be based on cost/benefit analysis particular to the project, and sets of requirements called feature sets. The importance of quality (the "-ilities") and constraints should be in the mix of requirements under consideration.

The process is to first group system functionality into feature sets, which are sets, or categories, of logically related requirements. The next step is for stakeholders to evaluate each requirement within each feature set to determine its value. A simple but often used scheme is:

3 = mission critical (very important, absolutely necessary)

2 = important, but not absolutely necessary

1 = nice to have, but optional

The third step is for developers and stakeholders to determine, for all of the requirements: if it is possible to achieve now; if it should be deferred, and why; or if it is impossible and should be dropped from consideration.

The evaluation process is not always an easy one - if a feature was not attractive to someone, then it probably wouldn't be on the list in the first place. More sessions in the mind mapping, JAD, or focus group format may be necessary to prioritize the requirements once they have been drawn out of the stakeholders' conscious and unconscious needs and desires. Those ranking the requirements are encouraged to remember intangible benefits (e.g., improved customer goodwill) as well as tangible benefits (e.g., increased sales).

Use cases may be helpful in the prioritization process by looking for the anticipated frequency or volume of usage, satisfying most favored user classes, implementation of core business processes, functions required by law, and so on. Critical success factors may be recalled to help determine "what must go right" in order for this application to be successful.

Table 1 shows a straightforward approach to documenting agreements for how and when prioritized requirements will be rolled out. It's simplified for the sake of example, but the format can work for any number of levels of priority (three in the example) and any number of feature sets (also three in the example). Once the requirements have been ranked by level of importance, they are grouped into cohesive feature sets. Combinations of the two may be released as versions of the software.

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.