7.3. Commentary: Supplementary Specification

The Supplementary Specification captures other requirements, information, and constraints not easily captured in the use cases or Glossary, including system-wide “URPS+” quality attributes or requirements. Note that requirements specific to a use case can (and probably should) be first written with the use case, in a Special Requirements section, but some prefer to also consolidate all of them in the Supplementary Specification.. Elements of the Supplementary Specification could include:

• FURPS+ requirements— functionality, usability, reliability, performance, and supportability

• reports

• hardware and software constraints (operating and networking systems, ...)

• development constraints (for example, process or development tools)

• other design and implementation constraints

• internationalization concerns (units, languages, ...)

• documentation (user, installation, administration) and help

• licensing and other legal concerns

• packaging

• standards (technical, safety, quality)

• physical environment concerns (for example, heat or vibration)

• operational concerns (for example, how do errors get handled, or how often to do backups?)

• domain or business rules

• information in domains of interest (for example, what is the entire cycle of credit payment handling?)

Constraints are not behaviors, but some other kind of restriction on the design or project. They are also requirements, but are commonly called “constraints” to emphasize their restrictive influence. For example:

Must use Oracle (we have a licensing arrangement with them).

Must run on Linux (it will lower cost).

Suggestion Early design decisions and constraints (“premature elaboration”) are almost always a bad idea, so it is worth being suspicious and challenging of these, especially during the inception phase when very little has been carefully analyzed. Some constraints are imposed for unavoidable reasons, such as a legal restriction or an existing external system interface that must be invoked.

Quality Attributes

Some requirements are called quality attributes [BCK98] (or “-ilities”) of a system. These include usability, reliability, and so forth. Note that these refer to the qualities of the system, not that these attributes are necessarily of high quality (the word is overloaded in English). For example, the quality of supportability might deliberately be chosen to be low if the product is not intended to serve a long-term purpose.

They are of two types:

Functionality is specified in the use cases, as are other quality attributes related to specific use cases (for example, the performance qualities in the Process Sale use case).

Other system-wide FURPS+ quality attributes are described in the Supplementary Specification.

Although functionality is a valid quality attribute, in common usage, the term “quality attribute” is most often meant to imply “qualities of the system other than functionality.” Herein, the term is likewise used. This is not exactly the same as non-functional requirements, which is a broader term including everything but functionality (for example, packaging and licensing).

When we put on our “architect hat,” the system-wide quality attributes (and thus the Supplementary Specification where one records them) are especially interesting because—as will be introduced in Chapter 32—architectural analysis and design are largely concerned with the identification and resolution of the quality attributes in the context of the functional requirements. For example, suppose one of the quality attributes is that the NextGen system must be quite fault-tolerant when remote services fail. From an architectural viewpoint, that will have an overarching influence on large-scale design decisions.

Quality attributes have interdependencies and involve trade-offs. As a simple example in the POS, “very reliable (fault-tolerant)” and “easy to test” are in some opposition, because there are many subtle ways a distributed system can fail.

Domain (Business) Rules

Domain rules [Ross97, GK00] dictate how a domain or business may operate. They are not requirements of any one application, although an application's requirements are often influenced by domain rules. Company policies, physical laws, and government laws are common domain rules.

They are commonly called business rules, which is the most common type, but that term is limited, as some software applications are for non-business problems, such as weather simulation or military logistics. A weather simulation has “domain rules” that influence the application requirements, related to physical laws and relationships.

It is often useful to identify and record those domain rules that influence the requirements, usually realized in the use cases, because they can clarify incomplete or ambiguous use case content. For example, in the NextGen POS, if someone asks if the Process Sale use case should be written with an alternative to allow credit payments without signature capture, there is a business rule (RULE1) that clarifies whether this will not be allowed by any credit authorization company.

Caution Rules are not application requirements. Do not record system features as rules. They describe the constraints and behaviors of how the domain works, not the application.

Information in Domains of Interest

It is often valuable for a subject matter expert to write (or provide URLs to) some explanation of domains related to the new software system (sales and accounting, the geophysics of underground oil/water/gas flows, ...), to provide context and deeper insight for the development team. It may contain pointers to important literature or experts, formulas, laws, or other references. For example, the arcana of UPC and EAN coding schemes, and bar code symbology, must be understood to some degree by the NextGen team.