anchor.diff:  +
   
   . [[Quality-Driven-Software-Architecture]]
  -Quality Driven Software Architecture (QDSA):: Derive (technical, structural or process-related) decisions based upon detailed quality requirements. QDSA requires <<Capture-Quality-Requirements, explicit quality requirements>>. See <<Quality-Function-Deployment>>.
  +[pattern]#Quality Driven Software Architecture# (QDSA):: Derive (technical, structural or process-related) decisions based upon detailed quality requirements. QDSA requires <<Capture-Quality-Requirements, explicit quality requirements>>. See <<Quality-Function-Deployment>>.
   Category: <<Improve>>
   +
   
   . [[Quality-Function-Deployment]]
  -Quality Function Deployment:: (QFD) Systematically translate customer requirements into technical requirements for  system development and maintenance. See <<Quality-Driven-Software-Architecture>>.
  +[pattern]#Quality Function Deployment#:: (QFD) Systematically translate customer requirements into technical requirements for  system development and maintenance. See <<Quality-Driven-Software-Architecture>>.
   +
   
   . [[Quantitative-Analysis]]
  -Quantitative Analysis:: Measure artifacts or processes within the system, e.g. source code. For example, see <<Static-Code-Analysis>>.
  +[pattern]#Quantitative Analysis#:: Measure artifacts or processes within the system, e.g. source code. For example, see <<Static-Code-Analysis>>.
   Category: <<Analyze>>
   +
   
   . [[Questionnaire]]
  -Questionnaire:: Written collection of questions presented to stakeholders. Can be addendum, preparation or replacement of <<Stakeholder-Interview>>.
  +[pattern]#Questionnaire#:: Written collection of questions presented to stakeholders. Can be addendum, preparation or replacement of <<Stakeholder-Interview>>.
   Category: <<Analyze>>
   +
   
   . [[Refactoring]]
  -Refactoring:: Source code transformation that does not change functionality of system. See <<Fowler-Refactoring>>.
  +[pattern]#Refactoring#:: Source code transformation that does not change functionality of system. See <<Fowler-Refactoring>>.
   Category: <<Improve>>
   +
   
   . [[Refactoring-Plan]]
  -Refactoring Plan:: The route of refactoring, as discussed within the development team. This plan should always be visible to every team member.
  +[pattern]#Refactoring Plan#:: The route of refactoring, as discussed within the development team. This plan should always be visible to every team member.
   Category: <<Improve>>
   +
   
   . [[Requirements-Analysis]]
  -Requirements Analysis:: Analyze (current) requirements: required features and required constraints
  +[pattern]#Requirements Analysis#:: Analyze (current) requirements: required features and required constraints
   Category: <<Analyze>>
   +
   
   . [[Remove-Nested-Control-Structures]]
  -Remove Nested Control Structures:: Re-structure code so that deeply nested or complicated control structures are replaced by semantically identical versions. Special case of <<Refactoring>>, similar to <<Untangle-Code>>.
  +[pattern]#Remove Nested Control Structures#:: Re-structure code so that deeply nested or complicated control structures are replaced by semantically identical versions. Special case of <<Refactoring>>, similar to <<Untangle-Code>>.
   Category: <<Improve>>
   +
   
  
positive.code: Systematically prepare and take decisions by finding appropriate options, check assumptions, overcome emotion and prepare to be wrong. See <<heath-decisive, Decisive (by C+D Heath)>>.
  Category: <<Crosscutting>>
   
  . [[System-Documentation]]
  System Documentation:: Document relevant structures, concepts, decisions, interfaces etc. of the system to increase. See <<arc42>>. 
  Category: <<Analyze>>
  +
  
  
negative.code: +
  
  . [[Toggle-Feature]]
  [pattern]#Toggle Feature#:: Simultaneously support evolved, competing or conflicting features at runtime by toggling feature flags.
  Category: <<Improve>>
  +
  
  