Utility trees and quality attributes in Architecture
There are two types of requirements for software projects: functional and non-functional requirements. Functional requirements are the requirements for what the solution must do (which are usually expressed as use cases or stories). The functional requirements are what the users (or systems) that interact with the system do with the system (fill in an order, update customer details, authorize a loan etc.).
Non-Functional requirements are attributes the system is expected to have or manifest. These usually include requirements in areas such as performance, security, availability etc. A better name for non-functional requirements is “Quality Attributes” . Below are some formal definitions from IEEE standad 1061 “Standard for a Software Quality Metrics Methodology” for quality attributes and related terms
Quality attribute: A characteristic of software, or a generic term applying to quality factors, quality sub factors, or metric values.
Quality factor: A management-oriented attribute of software that contributes to its quality.
Quality subfactor: A decomposition of a quality factor or quality sub factor to its technical components.
Metric value: A metric output or an element that is from the range of a metric.
Software quality metric A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality.
Most of the requirements that drive the design of a software architecture comes from system’s quality attributes. The reason for this is that that the effect of quality attributes is usually system-wide
One of the architect’s roles is to analyze the quality attributes and define an architecture that will enable delivering all the functional requirements while supporting the quality attributes. As can be expected ,sometimes quality attributes are in conflict with each other – the most obvious examples are performance vs. security or flexibility vs. simplicity and the architect’s role is to strike a balance between the different quality attributes (and the stakeholders) to make sure the overall quality of the system is maximized
Contextual solutions (e.g. patterns) can be devised to solve specific quality attributes need. However saying that a system needs to have “good performance” or that it needs to be “testable” doesn’t really help us know what to do. In order for us to be able to discern which patterns apply to specific quality attribute , we need a better understanding of quality attributes besides the formal definition, something that is more concrete.
The way to get that concrete understanding of the effect of quality attributes is to use scenarios. Scenarios are short, “user story”-like proses that demonstrate how a quality attribute is manifested in the system using a functional situation
The scenarios can be used as an input to make sure the quality attributes are actually met. Furthermore you can use the scenarios to help identify the strategies or patterns applicable to make the scenarios possible (and thus ensure the quality attributes are met) within the system. We usually group scenarios into a “utility tree” which is a representation of the total usefulness (“utility”) of a system . As you can see in the diagram below we have the key quality attributes (Performance, Security etc.). Each of the quality attributes has sub categories (e.g. Performance is broken into latency, data loss etc.). Each sub category is demonstrated by a scenario that we expect the system to manifest
The tree representation helps get the whole picture but the important bits here are the scenarios so let’s explore them some more. Scenarios are expressed as statements that have 3 parts: a stimulus, a context and a response. The stimulus is the action taken (by the system / user/ other system / any other person); response is how the system is expected to behave when the stimulus occur, and the context specifies the environment or conditions under which we expect the to get the response
Non-Functional requirements are attributes the system is expected to have or manifest. These usually include requirements in areas such as performance, security, availability etc. A better name for non-functional requirements is “Quality Attributes” . Below are some formal definitions from IEEE standad 1061 “Standard for a Software Quality Metrics Methodology” for quality attributes and related terms
Quality attribute: A characteristic of software, or a generic term applying to quality factors, quality sub factors, or metric values.
Quality factor: A management-oriented attribute of software that contributes to its quality.
Quality subfactor: A decomposition of a quality factor or quality sub factor to its technical components.
Metric value: A metric output or an element that is from the range of a metric.
Software quality metric A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality.
Most of the requirements that drive the design of a software architecture comes from system’s quality attributes. The reason for this is that that the effect of quality attributes is usually system-wide
One of the architect’s roles is to analyze the quality attributes and define an architecture that will enable delivering all the functional requirements while supporting the quality attributes. As can be expected ,sometimes quality attributes are in conflict with each other – the most obvious examples are performance vs. security or flexibility vs. simplicity and the architect’s role is to strike a balance between the different quality attributes (and the stakeholders) to make sure the overall quality of the system is maximized
Contextual solutions (e.g. patterns) can be devised to solve specific quality attributes need. However saying that a system needs to have “good performance” or that it needs to be “testable” doesn’t really help us know what to do. In order for us to be able to discern which patterns apply to specific quality attribute , we need a better understanding of quality attributes besides the formal definition, something that is more concrete.
The way to get that concrete understanding of the effect of quality attributes is to use scenarios. Scenarios are short, “user story”-like proses that demonstrate how a quality attribute is manifested in the system using a functional situation
The scenarios can be used as an input to make sure the quality attributes are actually met. Furthermore you can use the scenarios to help identify the strategies or patterns applicable to make the scenarios possible (and thus ensure the quality attributes are met) within the system. We usually group scenarios into a “utility tree” which is a representation of the total usefulness (“utility”) of a system . As you can see in the diagram below we have the key quality attributes (Performance, Security etc.). Each of the quality attributes has sub categories (e.g. Performance is broken into latency, data loss etc.). Each sub category is demonstrated by a scenario that we expect the system to manifest
The tree representation helps get the whole picture but the important bits here are the scenarios so let’s explore them some more. Scenarios are expressed as statements that have 3 parts: a stimulus, a context and a response. The stimulus is the action taken (by the system / user/ other system / any other person); response is how the system is expected to behave when the stimulus occur, and the context specifies the environment or conditions under which we expect the to get the response
Comments
Post a Comment