Software Quality Function Deployment
Modifying the "House Of Quality" for Software

	Bookmark This Page Email This Page Format for Printing Cite This Article Submit an Article Read More Articles
	Related Tools & Articles Software Defect Prevention - In a Nutshell Six Sigma Software Development Case Study Combining CMMI®, PSP, TSP, and Six Sigma for Software
	Discussion Forum "Has anyone had success using QFD to cascade business requirements into coding. If so, what were your QFD phases (i.e. product, part, manufacturing)?" Software QFD

Download Products Calibration System Software - Calibro Design For Six Sigma (DFSS) E-Book or Print Business Process Management Power Tools

By Dan Zrymiak ASQ-CQMgr, CSQE, CQE, CQA

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.

Quality Function Deployment 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.

Quality Function Deployment 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 Preferences. 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.

Figure 1: Software Quality Function Deployment

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 Software; 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 reference for this information was available on the Internet at www.cse.dcu.ie/essiscope/sm2/9126ref.html

The foundation of this ISO 9126 standard is structured along six primary product characteristics:

1. Functionality: Are the required functions available in the software?
2. Reliability: How reliable is the software?
3. Usability: Is the software easy to use?
4. Efficiency: How efficient is the software?
5. Maintainability: How easy is it to modify the software?
6. 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 or means 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 Quality Function Deployment 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 over 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 (www.gomez.com), 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 4AM 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 on-line 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-60% of the software defects originate in the requirements phase. Quality Function Deployment 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.

About The Author
Dan Zrymiak is a Software Quality Management practitioner, author, and educator with 10+ years experience, most recently within the Financial Services industry. Prior experience includes Medical Devices, Manufacturing, and Business Services. Dan is a Senior Member of ASQ and a recipient of the Feigenbaum Medal in 2001. His credentials include ASQ CQMgr, CSQE, CQE, and CQA, as well as extensive training in software engineering, six sigma, medical regulatory affairs, and quality assurance. Dan is available at dzss@shaw.ca for comments and feedback.

References
[1] Lessons Learned in Software Testing, 2002, Cem Kaner, James Bach, Bret Pettichord (Wiley).
[2] Certified Six Sigma Black Belt Primer, 2001, Bill Wortman, Quality Council of Indiana.
[3] 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.
[4] IEEE 830:1998 - Guideline for Software Requirements.

BEST SELLING PRODUCTS (iSixSigma Publications) Six Sigma Black Belt (DMAIC) Training Slides - 2009 Version! The 2009 Six Sigma Black Belt course includes over 40 more slides than the 2008 version. Contents include: 1,220 PowerPo... Certified Lean Six Sigma Black Belt Assessment Exam Interested in assessing your knowledge of Lean Six Sigma? Preparing for certifications? Testing your students and traine... Certified Lean Six Sigma Green Belt Assessment Exam This assessment exam is useful for students interested in assessing their knowledge of Lean Six Sigma on the Green Belt ... Kaizen Workshop E-book This 150+ page ebook teaches key tools and techniques of Kaizen, as well as real application to enhance learning. Kaizen... Certified Lean Six Sigma Black Belt E-book In 670 pages learn everything within the Lean Six Sigma DMAIC body of knowledge to successfully achieve Black Belt certi... Process Management Training Slides The 2008 Process Management course is designed in two phases comprised of:352 Powerpoint slidesInstructor notesSlide exp... Design For Six Sigma (DFSS) E-Book or Print Need an "encyclopedia" consisting of many of the tools you’ll study? Need a helpful refresher to apply the DFSS process?... Sell Your Products