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). Some requirements are called quality attributes of a system. These refer to the qualities of the system. For example, the quality of support-ability might deliberately be chosen to be low if the product is not intended to serve a long-term purpose. They are of two types: - Observable at execution (functionality, usability, reliability, performance, ...)
- Not observable at execution (supportability, testability, ...)
Functionality is specified in the use cases, as are other quality attributes related to specific use cases. Other system-wide FURPS+ quality attributes are described in the Supplementary Specification. Quality Attributes and Architecture 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 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 our 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. Domain (Business) Rules Domain rules dictate how a domain or business may operate. 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.
Do'stlaringiz bilan baham: |
