Requirements and Quality Attributes

All requirements of software systems fall into three categories ²:

• Functional requirements: what the system must do, and how it must behave or react to runtime stimuli.
  • Architect responds by assigning an appropriate sequence of responsibilities throughout the design.
• Quality attribute requirements: qualifications of the functional requirements or of the overall product.
  • Architect responds by using various structures designed into the architecture, and the behaviours and interactions of the elements that populate those structures
• Constraints: design decisions with zero degrees of freedom (i.e., pre-made and unchangeable decisions).
  • Architect responds by accepting the constraint and reconcile it with other affected design decisions.

Functionality

Functionality is the ability of the system to do the work for which it was intended ².

Functionality does not determine architecture. Given a set of required functionality, there is no end to the architectures that could be created to satisfy that functionality ².

Functionality is achieved by assigning responsibilities to architectural elements, resulting in one of the most basic of architectural structures².

Specifying Quality Attribute Requirements

A quality attribute requirement should be unambiguous and testable.

Six parts of a Quality Attribute Scenario:

1. Source of the stimulus: some entity (human, computer system) that generated the stimulus
2. Stimulus: a condition that requires a response with it arrives at a system
3. Environment: the stimulus occurs under certain conditions, such as "overload" or "normal" operation
4. Artefact: the artefacts that are stimulated.
5. Response: the activity undertaken as the result of the arrival of the stimulus
6. Response measure: when the response occurs, it should be measurable in some fashion so that the requirements can be tested.

Availability

Availability refers to the ability of a system to mask or repair faults such that the cumulative service outage period does not exceed a required value over a specified time interval. ²

A failure is the deviation of the system from its specification, where the deviation is externally visible. ²

A failure's cause is called a fault. Faults can be prevented, tolerated, removed, or forecast. In this way, a system becomes "resilient" to faults. ²

Time to repair is the time until the failure is no longer observable ²

Failure is not only an option, it's almost inevitable. What will make your system safe and available is planning for the occurrence of failure or (more likely) failures, and handling them with aplomb. ²

Steady state availability is calculated as follows, where $MTBF$ denotes the mean time between failures and $MTTR$ denotes the mean time to repair:

Interoperability

Interoperability is about the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context.

• Syntactic interoperability: having the ability to exchange data
• Semantic interoperability: having the ability to interpret the data being exchanged

Any discussion of a system's interoperability needs to identify with whom, with what, and under what circumstances.

Two concept central to interoperability:

• "Exchange information" can mean something as simple as program A calling program B with some parameters. Entities, however, can exchange information in less direct ways. For example, if I have an idea of a program's behaviour, and I design my program to work assuming that behaviour, then my program and that one have also exchanged information, just not at runtime.
• "Interface" can mean a syntactic description of a component's programs and the type and number of their parameters, most commonly realized as an API. More than that, interface also includes a set of assumptions that we can safely make about an entity.

Two important aspects of interoperability:

• Discovery: the consumer of a service must discover (either at runtime or prior to runtime) the location, identity, and the interface of the service.
• Handling of the response:
  • The service reports back to the requester with the response
  • The service sends its reponse to another system
  • The service broadcasts its response to any interests parties

Modifiability