33.5. The Science: Identification and Analysis of Architectural Factors
Architectural Factors
Any and all of the FURPS+ requirements may have a significant influence on the architecture of a system, ranging from reliability, to schedule, to skills, and to cost constraints. For example, a case of tight schedule with limited skills and sufficient money probably favors buying or outsourcing to specialists, rather than building all components in-house.56 However, the factors with the strongest architectural influence tend to be within the high-level FURPS+ categories of functionality, reliability, performance, supportability, implementation, and interface. Interestingly, it is usually the non-functional quality attributes (such as reliability or performance) that give a particular architecture its unique flavor, rather than its functional requirements. For example, the design in the NextGen system to support different third-party components with unique interfaces, and the design to support easily plugging in different sets of business rules.In the UP, these factors with architectural implications are called architecturally significant requirements . "Factors" is used here for brevity.Many technical and organizational factors can be characterized as constraints that restrict the solution in some way (such as, must run on Linux, or, the budget for purchasing third-party components is X).
Quality Scenarios
When defining quality requirements during architectural factor analysis, quality scenarios [1] are recommended, as they define measurable (or at least observable) responses, and thus can be verified. It is not much use to vaguely state "the system will be easy to modify" without some measure of what that means.[2]
[1] A term used in various architectural methods promoted by the Software Engineering Institute (SEI); for example, in the Architecture Based Design method.
[2] Tom Gilb, the creator of perhaps the first iterative and evolutionary method, Evo, is also a long-time proponent of the need to quantify and measure non-functional goals. His PLanguage structured requirements language emphasizes quantification.
Quantifying some things, such as performance goals and mean time between failure, are well known practices, but quality scenarios extend this idea and encourage recording all (or at least, most) factors as measurable statements.Quality scenarios are short statements of the form <stimulus> <measurable response>; for example:
- When the completed sale is sent to the remote tax calculator to add the taxes, the result is returned within 2 seconds "most" of the time, measured in a production environment under "average" load conditions.
- When a bug report arrives from a NextGen beta test volunteer, reply with a phone call within 1 working day.
Note that "most" and "average" will need further investigation and definition by the NextGen architect; a quality scenario is not really valid until it is testable, which implies fully specified. Also, observe the qualification in the first quality scenario in terms of the environment to which it applies. It does little good to specify a quality scenario, verify that it passes in a lightly loaded development environment, but fail to evaluate it in a realistic production environment.
Pick Your Battles
A caution:
Writing these quality scenarios can be a mirage of usefulness. It's easy to write these detailed specifications, but not to realize them. Will anyone ever really test them? How and by whom? A strong dose of realism is required when writing these; there's no point in listing many sophisticated goals if no one will ever really follow through on testing them.pick your battles p. 432 There is a relationship here to the "pick your battles" discussion that was presented in an earlier chapter on the Protected Variations pattern. What are the really critical make-or-break quality scenarios? For example, in an airline reservation system, consistently fast transaction completion under very high load conditions is truly critical to the success of the systemit must definitely be tested. In the NextGen system, the application really must be fault-tolerant and fail over to local replicated services when the remote ones failit must definitely be properly tested and validated. Therefore, focus on writing quality scenarios for the important battles, and follow through with a plan for their evaluation.
Describing Factors
One important goal of architectural analysis is to understand the influence of the factors, their priorities, and their variability (immediate need for flexibility and future evolution). Therefore, most architectural methods (for example, see [HNS00]) advocate creating a table or tree with variations of the following information (the format varies depending on the method). The following style shown in Table 33.1 is called a factor table , which in the UP is part of the Supplementary Specification.
Factor | Measures and quality scenarios | Variability (current flexibility and future evolution) | Impact of factor (and its variability) on stakeholders, architecture and other factors | Priority for Success | Difficulty or Risk |
---|---|---|---|---|---|
ReliabilityRecoverability | |||||
Recovery from remote service failure | When a remote service fails, reestablish connectivity with it within 1 minute of its detected re-availability, under normal store load in a production environment. | current flexibility - our SME says local client-side simplified services are acceptable (and desirable) until reconnection is possible.evolution - within 2 years, some retailers may be willing to pay for full local replication of remote services (such as the tax calculator). Probability? High. | High impact on the large-scale design.Retailers really dislike it when remote services fail, as it prevents or restricts them from using a POS to make sales. | H | M |
… | … | … | … |
Factors and UP Artifacts
The central functional requirements repository in the UP are the use cases, and they, along with the Vision and Supplementary Specification, are an important source of inspiration when creating a factor table. In the use cases, the Special Requirements, Technology Variations , and Open Issues should be reviewed, and their implied or explicit architectural factors consolidated in the Supplementary Specification.It is reasonable to at first record use-case related factors with the use case during its creation, because of the obvious relationship, but it is ultimately more convenient (in terms of content management, tracking, and readability) to consolidate all the architectural factors in one locationin the factor table in the Supplementary Specification.
Main Success Scenario :
|
Special Requirements:
Technology and Data Variations List: 2a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard. …Open Issues :
|