anchor.diff:  Let them write _quality scenarios_ to describe their specific quality requirements for the system. Moderate this workshop.
   
   * Use _scenarios_ to formulate specific quality requirements.
  -* Order those scenarios within a mostly hierachical quality tree, similar to <<ISO-9126>>.
  +* Order those scenarios within a mostly hierarchical quality tree, similar to <<ISO-9126>>.
   
   ////
   TODO (https://github.com/aim42/aim42/issues/94)
   
  -* example scenarios
   * explain quality tree
   * explain brainstorming session, moderated workshop
   
  
positive.code: 
  ====== Scenario-based Quality Description
  
  Scenario:: describes the reaction of a system to a certain event (or type of event). 
  
  
  image::quality-scenario.png["quality scenario", title="Structure of Quality Scenarios", id="quality-scenario-diagram"]
  
  Although this definition is concise, it needs some explanation to become understandable. See figure <<quality-scenario-diagram>>:
  
  * An _event_ can be a user clicking a button, an administrator starting or stopping the system, or a hacker trying to get unauthorized access. An _event_ can also be a manager needing another feature, another manager wanting to reduce operation costs, or some government agency requiring financial data to be tamper-proof. 
  
  ===== Experiences
  
  * *Needs moderation*: Brainstorming quality requirements usually works well in moderated workshops. If given (even trivial) examples, every stakeholder will most likely write down several scenarios. We often received 80-120 different scenarios in one-day workshops.
  * *Uncovers problems and risks*: Scenarios collected within brainstorming sessions often contain _hidden_ problem descriptions, risks or problems with the current systems.
  * *Covers organization and process*: Scenarios sometimes cover process or organizational aspects (like: release cycles should be faster than they are now). Move those to your <<Improvement-Backlog>>.
  * *Improves human communication*: Different stakeholders often start communicating about the systeme or their requirements during such workshops. This kind of interaction _should_ have happened long before...
  
  
  ===== Applicability
  
negative.code: The workshop-based collection of quality requirements has been described by
  <<Clements-ATAM>>.
  
  * Real-world examples of software quality requirements (currently available only in German): https://github.com/arc42/quality-requirements
  * <<Clements-ATAM>> contains a brief description of scenario-based quality description and details on how to set up such workshops.
  
  