anchor.diff:  
   ====== Scenario-based Quality Description
   
  -Scenario:: describes the reaction of a system to a certain event (or type of event). 
  +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. 
  +* An _event_ can be
  +** a user clicking a button
  +** an administrator starting or stopping the system
  +** a hacker trying to get unauthorized access.
  +* An _event_ can also be
  +** a manager needing another feature
  +** another manager wanting to reduce operation costs
  +** some government agency requiring financial data to be tamper-proof
  +
  +.Example scenario "Mandatory changes to Business Processes"*
  +====
  +
  +[%autowidth,cols="2*"]
  +|===
  +|Context
  +|The individual processing step AB within use case XY is declared invalid by the regulatory authority and removed from the system. The data processed by the system is not affected.
  +
  +|Business Goal(s)
  +|The needed changes to the use case XY can be carried out at low cost and without negative effects.
  +
  +|Trigger
  +|The legislator, represented by the regulatory authority, prohibits the use of the AB processing step.
  +
  +|Reaction
  +|A developer or architect removes the AB processing step in the system (by deleting the corresponding calls or reconfiguring the process flows).
  +
  +|Target value
  +|The change requires a maximum of 24 hours with a maximum of 48 person-hours of effort. After this time, the system is fully working again.
  +
  +
  +|Constraints
  +|This change has no effect on the existing data of the users/customers in the system regarding the XY application case. An (automatic) migration of some data is permitted, but must not exceed the 24-hour limit.
  +
  +|===
  +====
  +
  +Such a scenario makes it clear to everyone that not only business functionality is needed to achieve the project's goals.
  +It makes technical requirements (in the example above: modifiability) visible to non-technical stakeholders by providing traceability from the business goal to the technical details.
  +
   
   ===== 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...
  +* *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 system or their requirements during such workshops. This kind of interaction _should_ have happened long before...
   
   
   ===== Applicability
  
positive.code: 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>>.
  
  ////
  TODO (https://github.com/aim42/aim42/issues/94)
  
  * example scenarios
  * explain quality tree
  * explain brainstorming session, moderated workshop
  
  
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.
  
  