This paper looks at the possibility of using fuzzy terms in a software requirements specification. Potential benefits are reviewed. Methods for testing whether a fuzzy specification is met are investigated. Ways of modeling criticality and rigidity of specifications using fuzzy approaches are also identified. An example based on query response times is used throughout the paper. The results of a pilot study to see whether computer response time requirements can be fuzzified are described.
1. FUZZY SPECIFICATIONS: AN OXYMORON?
An oxymoron is a self-contradicting phrase that nevertheless makes sense. Classic examples include "jumbo shrimp" and "freezer burn." Examples from the world of computer science might include "virtual reality," "artificial intelligence" and "super mini." What about the topic of this paper--fuzzy specifications? This appears to be another oxymoron, since the term "fuzzy" implies vagueness to most people, and the term "specification" implies preciseness. Can these two terms be consolidated? We think they can.
The ANSI/IEEE Standard 830-1984 [1] for software requirements specifications (SRS) lists the following characteristics of a good SRS: Unambiguous, complete, verifiable, consistent, modifiable, traceable, and usable during the operation and maintenance phase. The qualities pertinent to this discussion are:
-
Unambiguous: Every listed requirement should have only one interpretation.
-
Verifiable: For every requirement there exists some finite cost-effective process to check that the software product meets the requirement.
Both qualities are related to preciseness. A precisely stated requirement will have only a single interpretation and will be able to be tested.