SlideShare ist ein Scribd-Unternehmen logo
1 von 47
Quality Function Deployment

 QFD for Software Requirements
         Management

           Guy Davis
         Carmen Zannier
          Adam Geras
Quality Function Deployment

 QFD for Software Requirements
         Management

           Guy Davis
         Carmen Zannier
          Adam Geras
Objectives

Upon completion of this chapter, students will:
       Understand what Quality Function Deployment (QFD) is
   

       Understand how QFD compares to other software
   

       development life cycles
       Be able to identify the primary QFD tools and concepts
   

       Be able to identify the QFD practices that might be
   

       useful in non-QFD working environments




                                                          of 46
1. Introduction to QFD




                         of 46
1(a) QFD - Definition




                        of 46
1(a) QFD – Definition (Cont.)




 [ASI, 2000]

                            of 46
1(b) QFD - Benefits




[ASI, 2000]

                                of 46
1(c) QFD - History




                     of 46
1(d) Software Engineering Context




                               of 46
1(e) Requirements Engineering
           Context




                                of 46
2. QFD Life Cycle Considerations

 QFD Process
 SQFD Process




                                 of 46
2(a) Traditional QFD Phases




                          of 46
2(b) Adapting QFD to Software




                            of 46
2(b) SQFD Process




                    of 46
3. The House of Quality




                          of 46
3(a) Customer Requirements




                             of 46
3(b) Affinity and Tree
      Diagrams




                         of 46
Exercise 1 – Affinity Workshop




                            of 46
3(c) The Planning Matrix

 Quantifies Customer Requirements.
 Quantifies Perceptions of Existing Products.
 Allows adjustment based on design team.




                                                 of 46
3(c) The Planning Matrix

Customer Satisfaction – existing products fulfilling
  specified requirements.
Improvement Ratio = Planned Performance / Existing
  Performance

Sales Point – weight for marketability
Overall Weighting = Importance Weighting x
  Improvement Ratio X Sales Point

                                                  of 46
3(c) The Planning Matrix




                           of 46
3(d) Technical
               Requirements
 Engineering Characteristics, Voice of the Company.

 Identify Measurable Characteristics related to
  Customer Requirements.

 Direction of change included to lead to
  improvement of product performance.


                                                   of 46
3(e) Interrelationships

 Between customer requirements and technical
  requirements
 Translation and correlation step
 Critical to generate consensus between
  development team and customers.
Critical Question:
How significant is technical requirement A in
satisfying customer requirement B?

                                                of 46
3(e) Interrelationships




                          of 46
3(f) “The Roof”

 Considers impact of technical requirements on each
  other
 Feature to feature comparison
 Augment or impede?

Critical Question:
 Does improving one requirement cause a
  deterioration or improvement in another
  requirement?


                                                  of 46
3(f) “The Roof”




                  of 46
3(g) Targets

                                  Results from previous
        Summarize previous
        steps                       steps:
                                         Customer requirements
        Draw conclusions            

                                         Prioritized customer
                                     
       Consists of:                     requirements
          Technical Priorities
    
                                         Technical requirements
                                     
          Competitive
    
                                         Correlated requirements
                                     
          Benchmarks
                                         Feature
                                     
          Final Product Targets
    
                                         interdependencies


                                                             of 46
3(h) Technical Priorities




                            of 46
3(i) Competitive Benchmarks




                          of 46
Target System
                        Meets standards


                        Harness weight

                        Webbing strength


                        Padding thickness
                                            3(j) Final Product Targets




                        # of buckles
of 46
3(k) House of Quality Summary

 Inputs:
       Customer requirements
   

       Technical requirements
   

       Customer priorities
   

       Market reality / competitive analysis
   

        Organization’s strengths & weaknesses
   

 Outputs
       Prioritized technical requirements
   

       Measurable, testable goals
   




                                                of 46
Exercise 2 – Build a House of
           Quality




                                of 46
3(l) House of Quality Pros and
                      Cons
 Pros:
       Generates specific technical requirements
   

       Requirements are traceable
   

       Follows a repeatable, quantitative process
   

       Effectively translates Voice of the Customer
   

       Records rationale for each technical requirement
   




 Cons:
       Time-consuming process for >10 requirements
   

       Data storage, manipulation and maintenance costs
   

       Very dependent on customer requirement gathering
   

       Inflexible to changing requirements; must recalculate
   




                                                               of 46
4. QFD Life Cycle Comparisons




                            of 46
4(a) QFD and Cleanroom




                [SAIC, 2001]



                               of 46
4(b) QFD and SASD




                    of 46
4(c) QFD vs. JAD




                   of 46
4(d) QFD and PD




                  of 46
4(e) QFD vs. RAD




                   of 46
4(f) QFD vs. SSM




[Wilson, 2001]

                           of 46
4(g) QFD and RUP




[Ronin, 2001]

                            of 46
4(h) QFD and XP




[Wells, 2001]
                                  of 46
5. Conclusions




                 of 46
5. Conclusions (Cont.)




                         of 46
5. Conclusions (Cont.)




                         of 46
QFD Designer

 QFD Designer Business Improvement
  Software
 Templates to define various aspects of QFD
 Icons, graphs, simplify add/delete




                                           of 46
References




             of 46

Weitere ähnliche Inhalte

Was ist angesagt? (20)

Quality function deployment
Quality function deploymentQuality function deployment
Quality function deployment
 
QFD
QFDQFD
QFD
 
Quality Function Deployment PPT Slide Template
Quality Function Deployment PPT Slide TemplateQuality Function Deployment PPT Slide Template
Quality Function Deployment PPT Slide Template
 
QFD (Quality Function Deployment)
QFD (Quality Function Deployment)QFD (Quality Function Deployment)
QFD (Quality Function Deployment)
 
Qfd ppt
Qfd pptQfd ppt
Qfd ppt
 
Product Operation Planning & Control
Product Operation Planning & ControlProduct Operation Planning & Control
Product Operation Planning & Control
 
Quality Function Deployment
Quality Function DeploymentQuality Function Deployment
Quality Function Deployment
 
Quality Function Deployment presentation
Quality Function Deployment presentationQuality Function Deployment presentation
Quality Function Deployment presentation
 
Qfd house of quality
Qfd house of qualityQfd house of quality
Qfd house of quality
 
Quality Function Deployment
Quality Function DeploymentQuality Function Deployment
Quality Function Deployment
 
QFD
QFDQFD
QFD
 
Concurrent engineering
Concurrent engineeringConcurrent engineering
Concurrent engineering
 
Quality function deployment (qfd)
Quality function deployment (qfd) Quality function deployment (qfd)
Quality function deployment (qfd)
 
Introduction to Quality Engineering / Quality Control
Introduction to Quality Engineering / Quality ControlIntroduction to Quality Engineering / Quality Control
Introduction to Quality Engineering / Quality Control
 
House of quality
House  of  qualityHouse  of  quality
House of quality
 
Manufacturing strategy
Manufacturing strategy Manufacturing strategy
Manufacturing strategy
 
Process planning (lesson 1)
Process planning (lesson 1)Process planning (lesson 1)
Process planning (lesson 1)
 
QUALITY FUNCTION DEPLOYMENT
QUALITY FUNCTION DEPLOYMENT QUALITY FUNCTION DEPLOYMENT
QUALITY FUNCTION DEPLOYMENT
 
Product design and development ch2
Product design and development ch2Product design and development ch2
Product design and development ch2
 
Quality awards
Quality awardsQuality awards
Quality awards
 

Ähnlich wie Quality Function Deployment

Project backup repository and avoiding requirements creep
Project backup repository and avoiding requirements creepProject backup repository and avoiding requirements creep
Project backup repository and avoiding requirements creepAswin Vijayakumar
 
INCOSE 2011 - Tool Vendor Challenge - Visure Solutions
INCOSE 2011 - Tool Vendor Challenge - Visure SolutionsINCOSE 2011 - Tool Vendor Challenge - Visure Solutions
INCOSE 2011 - Tool Vendor Challenge - Visure SolutionsVisure Solutions
 
Eight deadly defects in systems engineering and how to fix them
Eight deadly defects in systems engineering and how to fix themEight deadly defects in systems engineering and how to fix them
Eight deadly defects in systems engineering and how to fix themJoseph KAsser
 
Software project management
Software project managementSoftware project management
Software project managementSaumya Sahu
 
Ch03 the requirements_specification
Ch03 the requirements_specificationCh03 the requirements_specification
Ch03 the requirements_specificationNapex Terra
 
Omnext Source2VALUE
Omnext Source2VALUEOmnext Source2VALUE
Omnext Source2VALUEmeijerandre
 
Source2VALUE
Source2VALUESource2VALUE
Source2VALUEcoenburki
 
GaBi DfX - For compliance and sustainable product design
GaBi DfX - For compliance and sustainable product designGaBi DfX - For compliance and sustainable product design
GaBi DfX - For compliance and sustainable product designPE INTERNATIONAL
 
2011 RAMS Tutorial Effective Reliability Program Traits and Management
2011 RAMS Tutorial Effective Reliability Program Traits and Management2011 RAMS Tutorial Effective Reliability Program Traits and Management
2011 RAMS Tutorial Effective Reliability Program Traits and ManagementAccendo Reliability
 
Apqp+english+version[1]
Apqp+english+version[1]Apqp+english+version[1]
Apqp+english+version[1]Murat Terzi
 
QFD-COVID TEST KIT updated-converted.pdf
QFD-COVID TEST KIT updated-converted.pdfQFD-COVID TEST KIT updated-converted.pdf
QFD-COVID TEST KIT updated-converted.pdfSachinShishodia4
 
A Successful Improvement Process With Measurable Results
A Successful Improvement Process With  Measurable ResultsA Successful Improvement Process With  Measurable Results
A Successful Improvement Process With Measurable ResultsRam Yonish
 
A successful improvement process with measurable results
A successful improvement process with  measurable resultsA successful improvement process with  measurable results
A successful improvement process with measurable resultsRam Yonish
 
Software Engineering as the Next Level Up from Programming (Oracle Groundbrea...
Software Engineering as the Next Level Up from Programming (Oracle Groundbrea...Software Engineering as the Next Level Up from Programming (Oracle Groundbrea...
Software Engineering as the Next Level Up from Programming (Oracle Groundbrea...Lucas Jellema
 

Ähnlich wie Quality Function Deployment (20)

Project backup repository and avoiding requirements creep
Project backup repository and avoiding requirements creepProject backup repository and avoiding requirements creep
Project backup repository and avoiding requirements creep
 
Operation management
Operation managementOperation management
Operation management
 
Qfd Yr
Qfd YrQfd Yr
Qfd Yr
 
INCOSE 2011 - Tool Vendor Challenge - Visure Solutions
INCOSE 2011 - Tool Vendor Challenge - Visure SolutionsINCOSE 2011 - Tool Vendor Challenge - Visure Solutions
INCOSE 2011 - Tool Vendor Challenge - Visure Solutions
 
Eight deadly defects in systems engineering and how to fix them
Eight deadly defects in systems engineering and how to fix themEight deadly defects in systems engineering and how to fix them
Eight deadly defects in systems engineering and how to fix them
 
Software project management
Software project managementSoftware project management
Software project management
 
Tqm ch 06
Tqm ch 06Tqm ch 06
Tqm ch 06
 
Ch03 the requirements_specification
Ch03 the requirements_specificationCh03 the requirements_specification
Ch03 the requirements_specification
 
Omnext Source2VALUE
Omnext Source2VALUEOmnext Source2VALUE
Omnext Source2VALUE
 
Source2VALUE
Source2VALUESource2VALUE
Source2VALUE
 
How to Organize and Prioritize Requirements
How to Organize and Prioritize RequirementsHow to Organize and Prioritize Requirements
How to Organize and Prioritize Requirements
 
GaBi DfX - For compliance and sustainable product design
GaBi DfX - For compliance and sustainable product designGaBi DfX - For compliance and sustainable product design
GaBi DfX - For compliance and sustainable product design
 
2011 RAMS Tutorial Effective Reliability Program Traits and Management
2011 RAMS Tutorial Effective Reliability Program Traits and Management2011 RAMS Tutorial Effective Reliability Program Traits and Management
2011 RAMS Tutorial Effective Reliability Program Traits and Management
 
Apqp+english+version[1]
Apqp+english+version[1]Apqp+english+version[1]
Apqp+english+version[1]
 
ITS-Fidel
ITS-FidelITS-Fidel
ITS-Fidel
 
QFD-COVID TEST KIT updated-converted.pdf
QFD-COVID TEST KIT updated-converted.pdfQFD-COVID TEST KIT updated-converted.pdf
QFD-COVID TEST KIT updated-converted.pdf
 
A Successful Improvement Process With Measurable Results
A Successful Improvement Process With  Measurable ResultsA Successful Improvement Process With  Measurable Results
A Successful Improvement Process With Measurable Results
 
A successful improvement process with measurable results
A successful improvement process with  measurable resultsA successful improvement process with  measurable results
A successful improvement process with measurable results
 
Software Engineering as the Next Level Up from Programming (Oracle Groundbrea...
Software Engineering as the Next Level Up from Programming (Oracle Groundbrea...Software Engineering as the Next Level Up from Programming (Oracle Groundbrea...
Software Engineering as the Next Level Up from Programming (Oracle Groundbrea...
 
Apqp la
Apqp laApqp la
Apqp la
 

Mehr von guy_davis

Adopting Scrum and Agile
Adopting Scrum and AgileAdopting Scrum and Agile
Adopting Scrum and Agileguy_davis
 
Pragmatic Programmer
Pragmatic ProgrammerPragmatic Programmer
Pragmatic Programmerguy_davis
 
Content Caching with Rails
Content Caching with RailsContent Caching with Rails
Content Caching with Railsguy_davis
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Developmentguy_davis
 
Unit Testing in Java
Unit Testing in JavaUnit Testing in Java
Unit Testing in Javaguy_davis
 
Agile Software Development Methodologies
Agile Software Development MethodologiesAgile Software Development Methodologies
Agile Software Development Methodologiesguy_davis
 
Project Monitoring and Control
Project Monitoring and ControlProject Monitoring and Control
Project Monitoring and Controlguy_davis
 
The Human Side of Software Development
The Human Side of Software DevelopmentThe Human Side of Software Development
The Human Side of Software Developmentguy_davis
 
Adapter Design Pattern
Adapter Design PatternAdapter Design Pattern
Adapter Design Patternguy_davis
 
Software Quality Plan
Software Quality PlanSoftware Quality Plan
Software Quality Planguy_davis
 
Unified Process
Unified ProcessUnified Process
Unified Processguy_davis
 
Software Configuration Management
Software Configuration ManagementSoftware Configuration Management
Software Configuration Managementguy_davis
 

Mehr von guy_davis (12)

Adopting Scrum and Agile
Adopting Scrum and AgileAdopting Scrum and Agile
Adopting Scrum and Agile
 
Pragmatic Programmer
Pragmatic ProgrammerPragmatic Programmer
Pragmatic Programmer
 
Content Caching with Rails
Content Caching with RailsContent Caching with Rails
Content Caching with Rails
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Unit Testing in Java
Unit Testing in JavaUnit Testing in Java
Unit Testing in Java
 
Agile Software Development Methodologies
Agile Software Development MethodologiesAgile Software Development Methodologies
Agile Software Development Methodologies
 
Project Monitoring and Control
Project Monitoring and ControlProject Monitoring and Control
Project Monitoring and Control
 
The Human Side of Software Development
The Human Side of Software DevelopmentThe Human Side of Software Development
The Human Side of Software Development
 
Adapter Design Pattern
Adapter Design PatternAdapter Design Pattern
Adapter Design Pattern
 
Software Quality Plan
Software Quality PlanSoftware Quality Plan
Software Quality Plan
 
Unified Process
Unified ProcessUnified Process
Unified Process
 
Software Configuration Management
Software Configuration ManagementSoftware Configuration Management
Software Configuration Management
 

Kürzlich hochgeladen

Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 365Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 3652toLead Limited
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfAlex Barbosa Coqueiro
 
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationBeyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationSafe Software
 
DevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsDevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsSergiu Bodiu
 
Story boards and shot lists for my a level piece
Story boards and shot lists for my a level pieceStory boards and shot lists for my a level piece
Story boards and shot lists for my a level piececharlottematthew16
 
Human Factors of XR: Using Human Factors to Design XR Systems
Human Factors of XR: Using Human Factors to Design XR SystemsHuman Factors of XR: Using Human Factors to Design XR Systems
Human Factors of XR: Using Human Factors to Design XR SystemsMark Billinghurst
 
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmaticsKotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmaticscarlostorres15106
 
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek SchlawackFwdays
 
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks..."LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...Fwdays
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Commit University
 
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr LapshynFwdays
 
Unleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubUnleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubKalema Edgar
 
Powerpoint exploring the locations used in television show Time Clash
Powerpoint exploring the locations used in television show Time ClashPowerpoint exploring the locations used in television show Time Clash
Powerpoint exploring the locations used in television show Time Clashcharlottematthew16
 
Training state-of-the-art general text embedding
Training state-of-the-art general text embeddingTraining state-of-the-art general text embedding
Training state-of-the-art general text embeddingZilliz
 
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Enterprise Knowledge
 
CloudStudio User manual (basic edition):
CloudStudio User manual (basic edition):CloudStudio User manual (basic edition):
CloudStudio User manual (basic edition):comworks
 
SAP Build Work Zone - Overview L2-L3.pptx
SAP Build Work Zone - Overview L2-L3.pptxSAP Build Work Zone - Overview L2-L3.pptx
SAP Build Work Zone - Overview L2-L3.pptxNavinnSomaal
 
Install Stable Diffusion in windows machine
Install Stable Diffusion in windows machineInstall Stable Diffusion in windows machine
Install Stable Diffusion in windows machinePadma Pradeep
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024Lorenzo Miniero
 

Kürzlich hochgeladen (20)

Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 365Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 365
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdf
 
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationBeyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
 
DevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsDevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platforms
 
Story boards and shot lists for my a level piece
Story boards and shot lists for my a level pieceStory boards and shot lists for my a level piece
Story boards and shot lists for my a level piece
 
Human Factors of XR: Using Human Factors to Design XR Systems
Human Factors of XR: Using Human Factors to Design XR SystemsHuman Factors of XR: Using Human Factors to Design XR Systems
Human Factors of XR: Using Human Factors to Design XR Systems
 
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmaticsKotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
 
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
 
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks..."LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
 
DMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special EditionDMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special Edition
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!
 
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
 
Unleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubUnleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding Club
 
Powerpoint exploring the locations used in television show Time Clash
Powerpoint exploring the locations used in television show Time ClashPowerpoint exploring the locations used in television show Time Clash
Powerpoint exploring the locations used in television show Time Clash
 
Training state-of-the-art general text embedding
Training state-of-the-art general text embeddingTraining state-of-the-art general text embedding
Training state-of-the-art general text embedding
 
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024
 
CloudStudio User manual (basic edition):
CloudStudio User manual (basic edition):CloudStudio User manual (basic edition):
CloudStudio User manual (basic edition):
 
SAP Build Work Zone - Overview L2-L3.pptx
SAP Build Work Zone - Overview L2-L3.pptxSAP Build Work Zone - Overview L2-L3.pptx
SAP Build Work Zone - Overview L2-L3.pptx
 
Install Stable Diffusion in windows machine
Install Stable Diffusion in windows machineInstall Stable Diffusion in windows machine
Install Stable Diffusion in windows machine
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024
 

Quality Function Deployment

  • 1. Quality Function Deployment QFD for Software Requirements Management Guy Davis Carmen Zannier Adam Geras
  • 2. Quality Function Deployment QFD for Software Requirements Management Guy Davis Carmen Zannier Adam Geras
  • 3. Objectives Upon completion of this chapter, students will: Understand what Quality Function Deployment (QFD) is  Understand how QFD compares to other software  development life cycles Be able to identify the primary QFD tools and concepts  Be able to identify the QFD practices that might be  useful in non-QFD working environments of 46
  • 4. 1. Introduction to QFD of 46
  • 5. 1(a) QFD - Definition of 46
  • 6. 1(a) QFD – Definition (Cont.) [ASI, 2000] of 46
  • 7. 1(b) QFD - Benefits [ASI, 2000] of 46
  • 8. 1(c) QFD - History of 46
  • 11. 2. QFD Life Cycle Considerations  QFD Process  SQFD Process of 46
  • 12. 2(a) Traditional QFD Phases of 46
  • 13. 2(b) Adapting QFD to Software of 46
  • 15. 3. The House of Quality of 46
  • 17. 3(b) Affinity and Tree Diagrams of 46
  • 18. Exercise 1 – Affinity Workshop of 46
  • 19. 3(c) The Planning Matrix  Quantifies Customer Requirements.  Quantifies Perceptions of Existing Products.  Allows adjustment based on design team. of 46
  • 20. 3(c) The Planning Matrix Customer Satisfaction – existing products fulfilling specified requirements. Improvement Ratio = Planned Performance / Existing Performance Sales Point – weight for marketability Overall Weighting = Importance Weighting x Improvement Ratio X Sales Point of 46
  • 21. 3(c) The Planning Matrix of 46
  • 22. 3(d) Technical Requirements  Engineering Characteristics, Voice of the Company.  Identify Measurable Characteristics related to Customer Requirements.  Direction of change included to lead to improvement of product performance. of 46
  • 23. 3(e) Interrelationships  Between customer requirements and technical requirements  Translation and correlation step  Critical to generate consensus between development team and customers. Critical Question: How significant is technical requirement A in satisfying customer requirement B? of 46
  • 25. 3(f) “The Roof”  Considers impact of technical requirements on each other  Feature to feature comparison  Augment or impede? Critical Question:  Does improving one requirement cause a deterioration or improvement in another requirement? of 46
  • 27. 3(g) Targets   Results from previous Summarize previous steps steps: Customer requirements  Draw conclusions  Prioritized customer   Consists of: requirements Technical Priorities  Technical requirements  Competitive  Correlated requirements  Benchmarks Feature  Final Product Targets  interdependencies of 46
  • 30. Target System Meets standards Harness weight Webbing strength Padding thickness 3(j) Final Product Targets # of buckles of 46
  • 31. 3(k) House of Quality Summary  Inputs: Customer requirements  Technical requirements  Customer priorities  Market reality / competitive analysis  Organization’s strengths & weaknesses   Outputs Prioritized technical requirements  Measurable, testable goals  of 46
  • 32. Exercise 2 – Build a House of Quality of 46
  • 33. 3(l) House of Quality Pros and Cons  Pros: Generates specific technical requirements  Requirements are traceable  Follows a repeatable, quantitative process  Effectively translates Voice of the Customer  Records rationale for each technical requirement   Cons: Time-consuming process for >10 requirements  Data storage, manipulation and maintenance costs  Very dependent on customer requirement gathering  Inflexible to changing requirements; must recalculate  of 46
  • 34. 4. QFD Life Cycle Comparisons of 46
  • 35. 4(a) QFD and Cleanroom [SAIC, 2001] of 46
  • 36. 4(b) QFD and SASD of 46
  • 37. 4(c) QFD vs. JAD of 46
  • 38. 4(d) QFD and PD of 46
  • 39. 4(e) QFD vs. RAD of 46
  • 40. 4(f) QFD vs. SSM [Wilson, 2001] of 46
  • 41. 4(g) QFD and RUP [Ronin, 2001] of 46
  • 42. 4(h) QFD and XP [Wells, 2001] of 46
  • 43. 5. Conclusions of 46
  • 46. QFD Designer  QFD Designer Business Improvement Software  Templates to define various aspects of QFD  Icons, graphs, simplify add/delete of 46
  • 47. References of 46

Hinweis der Redaktion

  1. Quality Function Deployment (QFD) is a technique for requirements engineering borne out of the quality movement in the 1980’s. It didn’t originate as a requirements engineering technique. It originated in Mitsubishi’s Heavy Industries Kobe shipyard in Japan in the late 1960’s [Madu, 1999] and since then, expanded into use in other industries and for various purposes. This chapter introduces the “original” QFD concepts and applies them to software requirements engineering processes. To do this, we rely on research and original work from various sources around the world – attesting to QFD’s popularity. The key concept behind QFD is satisfying the customer – and that concept still applies today, in fact, we can hardly believe that there was a time when we wouldn’t try to satisfy the customer as the first and most critical priority.
  2. Quality Function Deployment (QFD) is a technique for requirements engineering borne out of the quality movement in the 1980’s. It didn’t originate as a requirements engineering technique. It originated in Mitsubishi’s Heavy Industries Kobe shipyard in Japan in the late 1960’s [Madu, 1999] and since then, expanded into use in other industries and for various purposes. This chapter introduces the “original” QFD concepts and applies them to software requirements engineering processes. To do this, we rely on research and original work from various sources around the world – attesting to QFD’s popularity. The key concept behind QFD is satisfying the customer – and that concept still applies today, in fact, we can hardly believe that there was a time when we wouldn’t try to satisfy the customer as the first and most critical priority.
  3. These objectives stem from our belief that few software organizations actually practice “complete” QFD – it is more likely that they will use concepts or even some tools from QFD to help them perform specific requirements engineering tasks. What are those concepts and tools that software people find useful? To answer this question, we have to start at the ground level and learn the basics of QFD first. Then we can learn how to apply those concepts and tools to software and specifically to requirements engineering.
  4. Our basic intent is to support your work as a requirements engineer with concepts and practices from QFD, in other words, to take what we can from QFD and apply it in our requirements engineering practice. In order to do this, we will briefly review the following: Definition – what is QFD? Benefits – why QFD? History – where did QFD come from? Software Engineering Context – how does QFD fit into SE? Requirements Engineering Context – how does QFD fit into RE?
  5. Since it’s been used in a wide variety of industries and over a number of decades, QFD has several definitions. Whatever you do, don’t interpret QFD as being solely the House of Quality. There is more to it than that: American Supplier Institute: “A system for translating consumer requirements into appropriate company requirements at each stage from research and development to engineering and manufacturing to marketing/sales and distribution.” [ASI, 1989]. Akao: “A method for developing a design quality aimed at satisfying the consumer and then translating the consumer’s demand into design targets and major quality assurance points to be used throughout the production phase.” [Akao, 1990]. Note that both definitions (as well as any others that you will read) mention the term “consumer”, also known as the “customer.” QFD is part of the quality revolution, but also part of the customer revolution in the 1980’s. The bottom line: QFD includes methods, tools, and techniques to support satisfying your customer.
  6. The main benefits of QFD are: Improved Customer Satisfaction Reduced Development Time Improved Internal Communications Better Documentation of Key Issues Save Money Some additional benefits are: Improved morale, organizational harmony Improved efficiency Reduction in design changes Increased competitiveness High market acceptance Problems are easier to identify
  7. 1966 – Bridgestone Tire Corporation, process assurance items table 1967 – Akao writes about QFD 1972 – Mitsubishi’s Heavy Industries Kobe shipyard – quality chart (evolved into the House of Quality) 1978 – Toyota Autobody 1983 – First QFD Seminar (Japan) 1990’s – American automotive industry adopts QFD 1996 – survey indicates that QFD is used more in the U.S. than in Japan, based on surveying companies that participated in QFD seminars and conferences. There were several core ideas that evolved into QFD, over a number of years. Many people assume that QFD started at Mitsubishi, or that it was an invention of Toyota Motor Corp, however, according to [Akao, 1997] this isn’t quite true.
  8. QFD relates to software engineering just like it would any other engineering discipline. Software engineering requires the same emphasis on customer satisfaction, benefits the same way from having cross-functional teams, and suffers from the same issues with quality. Organizations that embraced Total Quality Management (TQM) were more likely to also embrace Software Quality Function Deployment, or SQFD [Haag et al, 1996]. SQFD is primarily a requirements engineering technique as opposed to a complete life cycle, although Betts speculated on translating the traditional QFD phases to phases in the software life cycle. [Betts, 1995]. We will investigate the QFD traditional phases and Betts’ idea on a subsequent slide.
  9. In a requirements engineering context, the primary benefit of using SQFD concepts is that you gain the “voice of the customer” early in the development process. Any foundational software development life cycle depends on solid requirements, so you can see how valuable this might be. In addition, concepts borrowed from the QFD “customer value” concept lead Wiegers to optimize his requirements prioritization scheme (a variant of AHS) [Wiegers, 1999]. We conclude that SQFD is all about requirements engineering, even though QFD itself is more of a holistic view of a product development process.
  10. In order to gain another perspective on QFD, it makes sense that we place QFD in context of other software development life cycles, life cycles that are more common in software organizations. “Few software organizations seem to be willing to undertake the rigor of QFD or TQM.” [Wiegers, 1999]. This section introduces the 4 phases of QFD and then goes into SQFD in more detail.
  11. “Quality function deployment is a process of listening to the ‘voice of the customer,’ identifying the customer’s needs, and incorporating those needs in the design and production of goods and services” [Madu, 1999]. This quote emphasizes the role of QFD in the entire production scheme, not just at the beginning. QFD is NOT equal to the House of Quality! We will, however, focus on the House of Quality since it is most relevant to requirements engineering. But as a take-away message, be remindful of the fact that QFD revises the design and production stages of product and service delivery. Note how the “hows” from one phase become the “whats” of the subsequent phase. Think of these phases as more iterative than waterfall. The House of Quality (HOQ) – The HOQ is a blueprint for product development [Madu, 1999]. It’s called a “house” because of it’s physical appearance. Note that the HOQ goes by the name “quality chart” outside of North America [Akao, 1997]. Customer requirements, technical requirements, requirements prioritization, design targets, all merge onto the HOQ through a multi-step process. The HOQ is the focus of section 3 in this presentation.
  12. This represents Betts’ attempt at translating the four phases of QFD to software. This is NOT the SQFD approach but rather tries to match the holistic spirit of the original QFD to come up with a complete life cycle for software development based on QFD principles. In this approach, the customer voice drives the determination of measurable objectives, and in turn the measurable objectives drive the high level design, etc. This way, the customer voice ultimately drives the entire software development process. Note that “process planning” is one of the phases in this approach. This is remindful of Zultner’s approach for using TQM/QFD in software development projects. Zultner emphasizes that project teams should identify their own process improvement goals and design targets, in the greater context of the organization’s goals for improvement [Zultner, 1993].
  13. This diagram represents the QFD House of Quality concepts applied to requirements engineering, or SQFD. “SQFD is a front-end requirements elicitation technique, adaptable to any software engineering methodology, that quantifiably solicits and defines critical customer requirements” [Haag, 1996]. Step 1 – Customer requirements are solicited and recorded Step 2 – Customer requirements are converted to technical and measurable statements and recorded Step 3 – Customers identify the correlations between technical requirements and their own verbatim statements of requirement Step 4 – Customer requirement priorities are established Step 5 – Applying weights and priorities to determine the technical product specification priorities (this is a calculation)
  14. The House of Quality is a central tool of QFD, it translates customer requirements, market research and benchmarking data into prioritized engineering targets to be met by a new product design. Benchmarking: comparing performance in market of your own and other products against design measures helps define the real level of performance in relationship to the desired level. The HOQ is broken into 6 steps shown above.
  15. Customer Requirements – HOWS 1st & most important; documents a structured list of a product’s customers requirements described in their own words – Voice of Customer Information is gathered through conversations with the customer. They describe their needs and problems as they pertain to the desired product. Use an Affinity and Tree Diagram to structure the requirements before placing them into the Customer Requirements section of the HOQ.
  16. Affinity Diagram – each customer statement is written on to a separate card, cards are arranged into groups with perceived associations From each group a title card is chosen which encapsulates the meaning contained within that group and those titles are sorted again. Completed affinity diagram can then be used as the basis of a tree diagram, constructed from the top down. Structure is documented in the customer requirement part of the HOQ. In this example, the blue grouping falls under Usability, the orange grouping falls under Performance and the Attractive card is left in a category by itself
  17. Planning Matrix 1)quantifies the customer’s requirements priorities 2)quantifies perceptions of the performance of existing products 3)allows priorities to be adjusted based on the issues that concern the design team Measures used are gathered from customer’s using a questionnaire and shown in a column alongside the customer requirement description. One of the better methods (but more involved) for prioritizing is the Analytical Hierarchy Process (SENG 611) where requirements are paired and the customer picks the most important of the pair. Requirement Importance Weighting - shows the relative importance of each of the customer’s requirements from their perspective – most important measure
  18. Customer Satisfaction – how existing products fulfill their requirements Planned Satisfaction Rating – illustrates the desired satisfaction of customer requirements to be achieved by the desired product Improvement Ratio – divide planned performance by performance core of existing product Sales Point - a weight added to the requirements that can be used to help market the product Overall Weighting – multiplication of importance weight by improvement ratio by sales point
  19. Customer Satisfaction should be shown for the existing product and competitors’ products. It should be noted… upon looking at different examples of the planning matrix there were different formulas for computing the improvement ratio. Two example formulas found were: Improvement Ratio = Planned Satisfaction / Customer Satisfaction (a.k.a)Planned Performance / Existing Performance OR Improvement Ratio = (Planned Satisfaction / Customer Satisfaction) * .2 + 1 The sales point is given as a value between 1.0 and 1.5, although the justification for this has not been determined. As long as the values are consistent across all computations, it is merely a scale to add weight to a priority.
  20. Technical Requirements – WHATS A.K.A. Engineering characteristics, Voice of the Company. It describes the product in terms of the company. Structured set of relevant & measurable product characteristics. QFD design team identifies all measurable characteristics of the product which they consider are related to meeting the specified customer requirements. May have more than one technical requirement to convey one customer requirement. Also may use affinity and tree diagrams to interpret the characteristics. Include an additional row to illustrate direction of change which is considered to result in improvement of product performance.
  21. Goal : To translate customer requirements into technical requirements for the new product. Description This section is the central portion of the House of Quality. It can be very time consuming to complete as one must make m * n comparisons where m is the number of customer requirements and n is the number of technical requirements. For each combination, the QFD team must ask “How significant is technical requirement A in satisfying customer requirement B?”
  22. Steps: For each combination of customer and technical requirement, the level of interrelationship is recorded. Use a relative scale of high, medium, low, and none. Each ranking is assigned a numeric value such as high – 9, medium – 3, low – 1, none – 0.
  23. Step 5: Roof – Feature to feature comparison The triangular “roof” matrix of the House of Quality is used to determine the effects that the technical requirements have on each other. This is most important for identifying engineering trade-offs. These are situations where the improvement in one requirement results in the detoriation of another. Taking these situations into account during the requirements stage is crucial for a successful system design.
  24. Roof Steps: Determine whether an improvement in a requirement would require increasing or decreasing it’s measure. For each combination, determine whether improving one requirement will be supporting or a tradeoff for the other requirement This step also provides the QFD team with places where a focused design improvement could lead to gains in a number of different requirements. As well, by revealing the presence of engineering trade-offs, it offers opportunities for innovations to avoid the compromise entirely.
  25. Goal: The purpose of the last step is to integrate the results from all the previous steps into a set of useable targets to be used during design and implementation. The crucial difference between QFD and more traditional approaches is that QFD generates targets based on a repeatable, statistical analysis.
  26. Technical Priorities A prioritization of the technical requirements can be accomplished by summing the product of the interrelationship weightings with the overall weighting assigned during the Planning step. Steps For each technical requirement’s column, sum the product of the customer requirement’s overall weighting with the interrelation value(0-9).
  27. Competitive Benchmarking Each of the important technical requirements can be evaluated against the existing product system (if previous version exists) and against competitor systems. Matrix values are simply the measure of the technical requirement. This could be a binary or numeric descriptor. The goal is to determine the relative positions of existing products with regard to each of the identified technical requirements.
  28. Final Targets The output from the House of Quality is a set of targets for the important technical requirements. The results from all the stages of the House of Quality are used to generate these targets. QFD team draws on customer’s needs, competition’s performance, and organization’s current performance to determine these targets.
  29. These are really the advantages and disadvantages of QFD itself, at least from requirements management perspective. The general criticism of QFD is that it is a costly approach, required a “big requirements up-front” phase; this has the effect of pushing the team to use a waterfall software development life cycle as opposed to an iterative one.
  30. Our last topic is a brief comparison between QFD and the rest of the life cycles that we will discuss in this class. Note the acronyms – isn’t that a sign of intelligence? The more acronyms you use the more intelligence you have?  Here’s an explanation of each acronym: XP – Extreme Programming SASD – Structured Analysis and Structured Design SSM – Software Systems Method. PD – Participatory Design RAD – Rapid Application Development JAD – Joint Application Design RUP – Rational Unified Process CLEANROOM – That’s not an acronym, but thanks for asking And just in case you missed our presentation, QFD – Quality Function Deployment
  31. What they share: Emphasis on quality Emphasis on statistical process control Emphasis on customer feedback Emphasis on quantitative methods What differs: Mathematical emphasis in Cleanroom QFD requires cross-functional teams
  32. What QFD and SASD share: Philosophy of identifying “what” the system must do before describing “how” it will do it The idea of structuring requirements What differs: Plethora of possible notations for SASD (Gane-Sarson, Yourdon/DeMarco, SSADM IV, etc. while QFD doesn’t require models other than the HOQ QFD is iterative, while SASD tends to be practiced using a waterfall life cycle QFD is mostly a group session technique, focusing on cross-functional teams, while SASD doesn’t require cross-functional teams (although an organization could apply it that way)
  33. What QFD and JAD share: Both are group session techniques Both require facilitators Both require the project team to work with the customer What differs: JAD is not a quality-focused technique but a communication-focused technique, there is a subtle difference there To use JAD, the customer has to be able to visualize the software since they participate directly. This isn’t necessarily true for QFD.
  34. Participatory design is a group session where developers, business representatives, and users work together to design a solution. There is a strong emphasis on usability in most participatory design sessions. What QFD and PD share: Emphasis on end users (customers) What differs: PD has a social context – initially developed so that unions could have input into technology introduced into the workplace PD has a usability focus, while QFD treats usability as a requirement if the customer voice says it is a requirement
  35. A way of developing a system by completing a working part, implementing it, and adding more working parts every few months, instead of waiting to finish the entire project before putting the system into use. Otherwise, changes take place so fast in the computer industry that an application can be obsolete by the time it is implemented. Development tools such as visual programming and computer-assisted software engineering help with Rapid Application Development [computeruser.com, 2001] What QFD and RAD share: They are both group sessions What differs: Quality versus speed RAD uses time-boxing to prevent scope creep, QFD has no such counterpart
  36. “Soft Systems Methodology (S.S.M.) is, in reality, a set of methodologies. Each methodology is represented by a set of ideas (concepts) structured in such a way that their use is appropriate to the situation being analyzed. The use of Soft Systems Methodology as a powerful problem-solving tool requires this flexibility. Each situation is unique and hence methodology must be tailored to fit the situation and also the style of the analyst using it.” [Wilson, 2001]. What QFD and SSM share: Emphasis on the problem They are both group session techniques They are both iterative Where they differ: There is a problem-solving orientation to SSM as opposed to product-development orientation to QFD There is a knowledge capture/knowledge management undertone to SSM that doesn’t exist in QFD
  37. RUP stands for Rational Unified Process™, a commercial methodology available from Rational Corporation (makers of Rational Rose™). We’re including this comparison here simply because it is a methodology that you will most likely come across in your career. What QFD and RUP share: Both rely on iterative development process RUP relies on customer requirements as the basis for the remainder of the project Many different roles (types of personnel) involved in the project at the same time What differs: RUP is configurable to being either more lightweight or more heavyweight, depending on your needs, even to the point of going waterfall if necessary RUP relies on use cases as the framework for managing requirements, nothing like the HOQ RUP requires the use of the Unified Modeling Language (UML) while QFD doesn’t require any models
  38. XP, or eXtreme Programming, is a lightweight development methodology aimed at delivering high-quality software by de-emphasizing documentation and modeling for the sake of face-to-face communications with the customer, and numerous short iterations to deliver the desired application. What QFD and XP share: Emphasis on the customer, and the customer’s role in the project Release planning in XP feels like an affinity analysis exercise (tactile process; they actually use index cards) Emphasis on prioritizing requirements User stories – verbatim customer requirements? Both are iterative What differs: HOQ, and the ensuing calculations; never heard of in an XP project After the customer voice is captured, customers have little to do with the rest of the process; while in XP, customers remain involved as testing resources Release timing; QFD delivers the product in a big bang, while XP demands that teams release software early and often
  39. Back to our original question, then. To what extent will QFD improve your requirements engineering and requirement management practices? Here are some questions from Wieger’s requirements practice self-assessment that we believe you could answer in a more positive manner if you used QFD concepts and tools: 3. How are sources for obtaining voice-of-the-customer input identified? [Chapter 7] a) Development already knows what to build. b) Marketing feels they can provide the user’s perspective. c) Focus groups of typical users are surveyed or interviewed. d) Specific individuals who can represent different user classes participate on the project, with agreed-upon responsibilities and authority.
  40. 11.How are priorities for individual features or requirements established? [Chapter 13] a) All of them are important, or we wouldn’t have written them down in the first place. b) The customers tell us which requirements are most important to them. c) All requirements are labeled as high, medium, or low priority by consensus among customers. d) We use an analytical process to evaluate the value, cost, and risk associated with each use case, feature, or functional requirement and help us make priority decisions. 15.How are software requirements traced back to their origin? [Chapter 19] a) They aren’t. b) We know where many of the requirements came from. c) All requirements have an identified origin. d) We have full two-way tracing between every software requirement and some voice-of-the-customer statement, system requirement, use case, standard, regulation, architectural need, or other origin.
  41. 17.How are the requirements used as a basis for design? [Chapter 15] (a) If we had requirements, we might refer to them during programming. (b) The requirements documents describe the solution we intend to implement. (c) Each functional requirement is traced into a design element. (d) Designers inspect the SRS to make sure it can be used as the basis for design. We have full two-way traceability between individual functional requirements and design elements.
  42. The tool we looked at was called QFD Designer Business Improvement Software. It consists templates to create: House Of Quality : 4 different templates including different parts of the house. Voice of the Customer : Market Segment Analysis including demographics, customer use cases, verbatim statements. Product or Service Department Business Planning Six Sigma (best practices) Failure Analysis Includes icons to better represent relationships. Capability to add or delete requirements under a given segment. Capability to add or delete computations based on user needs & wants. Graphs required improvement.
  43. References [Akao, 1990] Akao, Yoji (1990). Quality Function Deployment: Integrating Customer Requirements into Product Design. [Akao, 1997] Akao, Yoji (1997). QFD: Past, Present and Future. Available on-line at http://www.qfdi.org/QFD_History.pdf. [ASI, 2000] American Supplier Institute (2000) http://www.amsup.com/qfd/index.htm. [computeruser.com, 2001] ComputerUser.com Inc. High-Tech Dictionary Definition http://www.computeruser.com/resources/dictionary/definition.html? lookup=4256. [Haag et al., 1996] Haag, S., Raja, M.K., and Schkade, L.L. (1996). Quality Function Deployment Usage in Software Development. Communications of the ACM , 39(1). Available on-line through the University of Calgary portal to the ACM Digital Library. [Macauley, 1996] Macaulay, L.A. (1996). Requirements Engineering. Springer-Verlag Limited: London, 1996. [Madu, 1999] Madu, Christian M. (1999). House of Quality in a Minute. Fairfield, CT: Chi Publishers. [Mazur, 2001] Mazur, Glen (2001). http://www.mazur.net. [Ronin, 2001] Ronin International Corporation. Enterprise Unified Process Available on-line at http://www.ronin-intl.com/publications/unifiedProcess.htm. [SAIC, 2001] SAIC, Inc. (2001). The DoD Software Technology for Adaptable, Reliable Systems ( STARS ) program. Cleanroom Software Engineering Tutorial. Available at http://www.asset.com/stars/loral/cleanroom/tutorial/cleanroom.html. [Wells, 2001] Wells, Don (2001). Extreme programming web site. Available on-line at http://www.extremeprogramming.org/. [Wiegers, 1999]. Wiegers, Karl (1999). Software Requirements . Redmond, WA: Microsoft Press. [Wilson, 2001] Wilson, B (2001) Soft Systems Methodology web pages. Available on-line at http://www.softsystemsmethodology.co.uk/overview.htm. [Zultner, 1987] Zultner, R. E. (1987) Software Quality Deployment – Adapting QFD to Software, Proceeedings of 13th Rocky Mountain Quality Conference.