Quality function deployment (QFD) is a process used to determine product development characteristics that combine technical requirements with customer preferences. Using an integrated matrix known as the “house of quality,” QFD considers the different influences bearing on the design to promote concurrent engineering, resulting in increased product acceptance. The basic QFD methodology can also be utilized with common software quality considerations to create a hybrid software requirements elicitation model. This is consistent with Design for Six Sigma practices and can be applied in a high-reliability context compliant with ISO 9001, capability maturity models and other software industry standards.
QFD is the process used in product design to identify the priorities for customer needs and expectations and to transfer these priorities into the technical design of the product. The benefits of such an approach include such deliverables as increased coverage of explicit and implicit requirements; improved acceptance of product; establishment of priority product characteristics to support design, development, and testing; and increased efficiency of product development. This is particularly important if the organization has to follow a protocol like Six Sigma or a controlled design methodology as mandated in ISO 9001:2000 and its derivative standards.
QFD uses the house of quality as a visual model. The house of quality is a matrix that aligns the customer needs (business priorities), the design features (technical priorities) and the customer oreferences. The factor of these inputs is represented in the benchmarked target values. From these target values, the product designers can establish objective metrics to indicate acceptance and fulfillment.
The intent of this article is to apply this model to software design. Software design presents interesting challenges for several reasons. Software is an intangible product that is not always conducive to explicit acceptance measures. Design elements are coupled and interdependent, which is different from physical designs that can be deconstructed into independent but functional sub-assemblies, parts and components. Software is not so easily divisible, creating additional design challenges.
For the purpose of elaboration, the software house of quality will address the considerations involved in the design of Internet banking software. This is a general product with readily available industry metrics and a wide range of deployment options. By no means is this model exclusive to Internet banking sSoftware; like QFD, it is intended to be applicable to any domain.
The first modification needed to make QFD applicable to software is the establishment of relevant and tangible customer needs. As a starting point, a recommended reference is the ISO 9126 standard (ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use – 1991). This reference defines a model for evaluating software.
The foundation of this ISO 9126 standard is structured along six primary product characteristics:
- Functionality: Are the required functions available in the software?
- Reliability: How reliable is the software?
- Usability: Is the software easy to use?
- Efficiency: How efficient is the software?
- Maintainability: How easy is it to modify the software?
- Portability: How easy is it to transfer the software to another environment?
These six items are sufficient for a high-level design, but for the determination of specific technical requirements, the user needs to apply the sub-characteristics. In this article, the issues pertaining to Internet banking will be applied to each sub-characteristic.
| Characteristic | Sub-characteristic | Definition | Applicability to Internet Banking |
| Functionality | Suitability | Attributes of software that bear on the presence and appropriateness of a set of functions for specified tasks. | The software can transact deposits, withdrawals, transfers and bill payments. |
| Functionality | Accurateness | Attributes of software that bear on the provision of right or agreed results or effects. | The software can correctly calculate and display interest payments. |
| Functionality | Interoperability | Attributes of software that bear on its ability to interact with specified systems. | The software can work on client PCs using different Windows operating systems. |
| Functionality | Compliance | Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions. | The software can forward transaction information to the appropriate clearinghouse for reconciliation. |
| Functionality | Security | Attributes of software that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs or data. | The software can secure customer information according to established protocols. |
| Reliability | Maturity | Attributes of software that bear on the frequency of failure by faults in the software | The software can complete the entire transaction cycle without runtime errors. |
| Reliability | Fault Tolerance | Attributes of software that bear on its ability to maintain a specified level of performance in case of software faults or of infringement of its specified interface. | The software continues to operate if data is missing or incorrectly interpreted, without a critical failure event. |
| Reliability | Recoverability | Attributes of software that bear on the capability to re-establish its level of performance and recover the data directly affected in case of a failure and on the time and effort needed for it. | The software can resume a partially completed loan application after disconnect from a power outage. |
| Usability | Understandability | Attributes of software that bear on the users’ effort for recognizing the logical concept and its applicability. | Software allows customer to use product independently after participating in 20-minute online tutorial. |
| Usability | Learnability | Attributes of software that bear on the users’ effort for learning its application. | Software provides tips or assistance to continually extend exposure to product functions. |
| Usability | Operability | Attributes of software that bear on the users’ effort for operation and operation control. | Software can provide users with ability to configure privilege setting to restrict functions (i.e. so teenage children can’t withdraw family savings to purchase a sports car). |
| Efficiency | Time Behavior | Attributes of software that bear on response and processing times and on throughput rates in performance and function. | Software can complete a withdrawal or deposit transaction within 3 minutes from origination to confirmation. |
| Efficiency | Resource Behavior | Attributes of software that bear on the amount of resource used and the duration of such use in performing its function. | Software can be used in client system with less than 5% available memory without disruption of other processes or operations. |
| Maintainability | Analyzability | Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of failures, or for identification of parts to be modified. | Software malfunctions by incorrectly calculating year-end totals resulting in integrity errors. Software should reveal how calculations occurred, dependencies, and effects. |
| Maintainability | Changeability | Attributes of software that bear on the effort needed for modification, fault removal or for environmental change. | Software can take on international banking functions (i.e., offshore accounts with different tax requirements). |
| Maintainability | Stability | Attributes of software that bear on the risk of unexpected effect of modifications. | Software can be adapted to work with wireless devices, but smaller screen size changes display characteristics. |
| Maintainability | Testability | Attributes of software that bear on the effort needed for validating the modified software. | Software can be tested to ensure sustained functionality under conditions of load and stress. |
| Portability | Adaptability | Attributes of software that bear on the opportunity for its adaptation to different specified environments without applying other actions ormeans than those provided for this purpose for the software considered. | Software can work in conjunction with third party applications for check ordering, bill payments, loan decisioning, and data aggregation. |
| Installability | Attributes of software that bear on the effort needed to install the software in a specified environment. | Software can be installed as part of an embedded system or as a stand-alone application. | |
| Conformance | Attributes of software that make the software adhere to standards or conventions relating to portability. | Software permits health insurance transactions in a manner that complies with Health Information Portability and Accountability Act (HIPAA). | |
| Replaceability | Attributes of software that bear on opportunity and effort using it in the place of specified other software in the environment of that software. | Software can effectively replace the legacy systems installed on mainframe computers 20 years ago without disrupting operations. |
Having established explicit customer needs for consideration, the next step is to identify design features. Software takes on a broad range of design approaches. It is beyond the scope of this article to address the choices of software architecture and object-oriented design, or to compare the relative merits of different software development life cycles and their impact on determining product requirements.
In the context of this article, design features relate to those choices that aid in determining product acceptance standards and provide a basis for software testing, verification and validation. An excellent resource is Lessons Learned in Software Testing: A Context Driven Approach (C.Kaner, J.Bach, B.Pettichord 2001), which provides a portfolio of testing techniques. Since QFD is based on the premise of design for acceptance, it is consistent with this approach to use evaluation methods as design criteria.
| Category | Design Feature Considerations | Definition | Relation to Internet Banking |
| People-based | User | Product design for user profile. | Software can be used by adult with minimal prior computer training and 8th grade reading level. |
| People-based | Subject-Matter Expert | Product design for consistency with expert opinion. | Software aligns with deliverable for personal service representative. |
| People-based | Designer | Reflection of product | Software provides configurability with is competitive trait of software provider. |
| People-based | Customer | Reflection of customer preferences beyond product. | Internet banking software projects stability and trustworthiness of established financial institution. |
| Coverage-based | Functionality | Individual independent tasks performed by the product. | Select a deposit account for depositing money. |
| Coverage-based | Integrated Functions | Combined tasks necessary to complete a transaction or other function. | Select a deposit account, deposit the money, confirm the deposit and print out the confirmation. |
| Coverage-based | Menu | User interface display permitting access to features. | Menu permits access to different features without having to manually enter URL address. |
| Coverage-based | Domain | Coverage of specific information. | Internet banking information provides user with details of transaction types. |
| Coverage-based | Equivalence Classes | Determination of inputs generating a consistent product behavior. | Customers with good track record for bill payments (no defaults) are offered superior credit terms. |
| Coverage-based | Boundaries | Parameters where product behavior is altered. | Customers 65 years of age or older can apply for senior benefits. |
| Coverage-based | Logic | Sequence of actions following a consistent pattern. | Banking software qualifies customer by their net worth prior to providing opportunities to borrow money. |
| Coverage-based | State-Based | Use conditions indicating different function availability or product behavior. | Transactions are denoted by secured state, identified by different background and access to different functions. |
| Coverage-based | Configuration | Ability for product to work in different intended operating environments. | Software can work on web or wireless devices. |
| Problems-based | Input Constraints | Determine how user or system can enter data. | Money is entered using numbers only, no text or special characters. |
| Problems-based | Output Constraints | Determine how data or information is displayed. | Currency data is displayed to two digits after decimal place. |
| Problems-based | Computation Constraints | Determine how data is computed. | Data is truncated to 3 digits after decimal place. |
| Problems-based | Storage or Data Constraints | Determine limitations to data. | Individual banking data is purged each night to prevent unauthorized access. |
| Activity-based | Regression | Impact of incremental design changes on the product. | Software can adapt to international banking transactions seamlessly. |
| Activity-based | Scenario | Complex fulfillment of a particular set of tasks. | Software can accommodate newly married couple that joins deposit accounts, and jointly obtains a mortgage. |
| Activity-based | Business Cycle | Scenario intended to replicate product use for an entire business cycle. | Software demonstrates suitability for annual cycle of transactions to include interest, month end and year-end calculations. |
| Activity-based | Installation | Initial application of product in its intended operating environment. | Software can be deployed and immediately used without intervention or assistance from company specialists. |
| Activity-based | Load | Ability to handle excessive activity. | Software can handle more than 10,000 concurrent transactions. |
| Activity-based | Long Sequence | Sustained product use over an extended period. | Software can be used continually for 7 days without runtime or memory leak errors. |
| Activity-based | Performance | Speed and duration of product use. | Transactions can be completed and confirmed within 3 minutes. |
| Evaluation-based | Comparison with Results | Determination of variations to external references. | Software tax calculations match tax results from government agencies working independently. |
| Evaluation-based | Consistency | Determination of variances to internal product references. | Software annual balance matches to total of monthly balances. |
| Evaluation-based | Oracle | Comparison to common acceptance indicators. | Software can qualify user for a loan with results similar to diagnostic credit references. |
The competitive comparison can be obtained from independent research particular to the domain or industry affected. For Internet banking, frequently queried references include Gomez, Tower Group and Celent. These companies are representative of the hundreds of organizations dedicated to obtaining and independently evaluating the major industry participants, and reporting on the relative merits of the products offered. This can be used to highlight opportunities and determine gaps between unfulfilled customer priorities and competitive coverage.
The outcomes of the house of quality are the benchmarked target values. This aligns very closely with the software requirements as defined by IEEE 830:1998. In particular, the benchmarked target values should be representative of the following types of requirements:
| Requirement | Definition | Example for Internet Banking Software |
| Functional Requirement | Outline of what the product will do for the user. | Product permits user to transact deposits, withdrawals, fund transfers, bill payments and track their accounts. |
| Performance Requirement | Speed or duration of product use. | Internet pages will load within 10 seconds; transactions will be completed within 3 minutes. |
| Security Requirements | Steps taken to prevent improper or unauthorized use. | Users will be required to enter password to enter application, and to authorize each transaction. |
| Maintainability Requirements | Ability for product to be changed. | Service pack upgrades will be available a minimum of once per quarter by accessing the user web page. |
| Reliability Requirements | The statement of how this product prevents failure attributed to system defects. | No critical failure events, unplanned shutdowns, or runtime errors in span of 10,000 transactions, |
| Availability Requirements | Ability for product to be used in its intended manner. | System will be available for transactions between 4 a.m. and midnight 7 days per week. |
| Database Requirements | Requirements for managing, storing, retrieving and securing data from use. | Software will be compatible with ODBC interfaces. |
| Documentation Requirements | Supporting portions of products to enable user references. | Product includes online help, access to PDF user manuals and provision of hard copy manuals on request. |
| Additional Requirements | Can include many categories not covered in other sections. | Banking software will be compliant with W3 guidelines for language protocols. |
The house of quality can be applied to software design, and the resulting software requirements are diverse in their scope and coverage. The result is that product acceptance extends beyond basic functionality to serve as an indicator of reliability, usability, and other customer preferences and design considerations. In software, 50 percent to 60 percent of the software defects originate in the requirements phase. QFD is a proven technique that can reduce the number of defects, subsequently resulting in gains for product development and customer satisfaction. When this extended approach was applied to a customized Internet banking software project, the customer acceptance was on-time, within budget and the customer confirmed a zero defects” release. This approach does not guarantee flawless software, but it effectively raises awareness of potential problems early in the software product development cycle, which permits adequate and robust resolution.
References
- Lessons Learned in Software Testing, 2002, Cem Kaner, James Bach, Bret Pettichord (Wiley).
- Certified Six Sigma Black Belt Primer, 2001, Bill Wortman, Quality Council of Indiana.
- ISO/IEC 9126: Information technology – Software Product Evaluation – Quality characteristics and guidelines for their use – 1991 (obtained from ESSI-SCOPE webpage at www.cse.dcu.ie/essiscope/sm2/9126ref.html.
- IEEE 830:1998 – Guideline for Software Requirements.
