<commit_before>[[Qualitative-Analysis]]
==== [pattern]#Qualitative Analysis# 

===== Intent

Find out (analyze):


* wether quality requirements can be met by the system, 
* which specific quality requirements are risks with respect to the current architecture,
* which specific quality requirements are currently non-risks 


===== Description

. <<Capture-Quality-Requirements, Capture quality requirements>> to ensure you have explicit, specific, valid and current _quality requirements_ available - preferably in form of _scenarios_.
. Prioritize these scenarios with respect to business value or importance for the authoritative stakeholders.
. For every important scenario: 
.. analyze the architectural approach the system takes,
.. decide wether this approach seems appropriate or risky   

===== Experiences

* Conducting workshops with a variety of stakeholders often leads to intense and productive communication.

===== Applicability

Use qualitative analysis to support in the following situations:

* You need to analyze which specific quality requirements are at risk and which will most likely be met by the system.

* You have a variety of different stakeholders or groups which can all impose quality requiements - but have not yet agreed on a common set of such requirements.

* A current and understandable collection of specific quality requirements for the system is missing.

===== Consequences


==== Also Known As
* <<ATAM>>

===== Related Patterns


===== References

* <<ATAM>>. Published by the Software Engineering Institute in numerous whitepapers and books, especially <<Clements-ATAM>>.
 <commit_msg>removed empty sections<commit_after>[[Qualitative-Analysis]]
==== [pattern]#Qualitative Analysis# 

===== Intent

Find out (analyze):


* wether quality requirements can be met by the system, 
* which specific quality requirements are risks with respect to the current architecture,
* which specific quality requirements are currently non-risks 


===== Description

. <<Capture-Quality-Requirements, Capture quality requirements>> to ensure you have explicit, specific, valid and current _quality requirements_ available - preferably in form of _scenarios_.
. Prioritize these scenarios with respect to business value or importance for the authoritative stakeholders.
. For every important scenario: 
.. analyze the architectural approach the system takes,
.. decide wether this approach seems appropriate or risky   

===== Experiences

* Conducting workshops with a variety of stakeholders often leads to intense and productive communication.

===== Applicability

Use qualitative analysis to support in the following situations:

* You need to analyze which specific quality requirements are at risk and which will most likely be met by the system.

* You have a variety of different stakeholders or groups which can all impose quality requiements - but have not yet agreed on a common set of such requirements.

* A current and understandable collection of specific quality requirements for the system is missing.


==== Also Known As
* <<ATAM>>


===== References

* <<ATAM>>. Published by the Software Engineering Institute in numerous whitepapers and books, especially <<Clements-ATAM>>.
 
{'fraction_non_alphanumeric': 0.06689377516258904, 'fraction_numerical': 0.0, 'mean_word_length': 4.915750915750916, 'pattern_counts': {'":': 0, '<': 19, '<?xml version=': 0, '>': 19, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6034771', 'n_tokens_mistral': 748, 'n_tokens_neox': 692, 'n_words': 397}