CSC 300/307/402
Professor Stearns
Quality Attribute Examples



These examples have been written over several years by Cal Poly students.
Each example is marked with the appropriate grading symbol. Acceptable examples are marked GE (good enough).

Most of the quality attributes come from the FURPS+ model described in
Practical Software Metrics for Project Management and Process Improvement by Robert Grady

Accuracy

  1. Every phone call initiated by the auto-dialer must have all the digits exactly correct, including area code. (GE)
  2. Computed grades must be accurate to .01% (NM - compared to what?)
  3. The system will notify the system administrator if the input data source is corrupted. (INC or NF)
  4. Every video must have an unique identification. (UC)
  5. The displayed clock rate must be within 5 Hz of the actual clock rate. (GE)
  6. If the mail list is used for a mailing, < 10% of the letters will be returned as undeliverable. (GE)
Adaptability
  1. The finished software must support new employee types without needing to be rewritten or recompiled. (GE)
  2. The software must be flexible. (NM, UC)
  3. The software must be adaptable. (CIR, UC)
  4. The Mean Time to Change (MTTC) data presentation (no new data entities) will be < 1 person-month for a senior system developer. (GE)
Aesthetics
  1. All text must be pink. (GE but silly)
  2. The user must be pleased with the GUI appearance. (GE but potentially difficult to satisfy)
Compatibility
  1. All web client programs must interact with the server without any changes to the server code. (GE, also NF because of the word All)
  2. The system must be compatibility with MacIntosh OS 10. (NM, UC and far too common)
Configurability
  1. The system must use a java .properties file that contains key value pairs defining the jdbc driver to use. (NR)
  2. The system must adapt to changes in any input record format without the need to recompile any code. (GE)
Consistency
  1. A consistent GUI is required. (NM, UC)
Correctness
  1. Defects/KDSI must be < 3. (GE)
Documentation
  1. All system documentation must be embedded in the source code. (INC)
  2. The source code shall be self-documented by placing the design description in a Javadoc-readable method header (GE)
Extensibility
  1. If the input data format changes, the developer will be able to make the required changes in < 20 person-hours. (GE)
  2. The system must be able to support new CD formats. (NM, NF)
  3. A new job ticket format can be added to the system without changing any extant .class file. (GE)
Frequency/Severity of Failure
  1. The system will crash no more than once per 10000 transactions. (UC - What's a crash? Is "once" an average or not?)
  2. There can be no unhandled exceptions from incorrect user input. (GE)
Human Factors
  1. The UI must be user-friendly. (BW, NM, UC)
  2. The UI must be intuitive. (NM, UC)
  3. All menus must have a consistent format. (GE)
Installability
  1. It must be possible to create and populate the database from a script file. (GE)
  2. A user can install and operate the program without assistance of any kind. (GE)
  3. There must be an install program. (UC)
  4. The installation process will be kept at a minimum. (BW/NM)
Localizability
  1. It must be possible to operate the system in any language. (NF)
  2. All user interface components must support the locale of the system.
    If a locale is not available, US English shall be used. (UC, NM, possibly GE if locale is defined somewhere)
  3. The UI language can be switched from English to German without recompiling nor rebuilding the program. (GE)
  4. The product can switch between English and metric units without recompiling nor rebuilding the program. (GE)
Maintainability
  1. A software developer with 6 months experience will be able to correct any known defect in < 2 person-days. (GE)
  2. The maintenance group must be able to maintain the software. (UC)
  3. Mean Time to Change (MTTC) for defects < 2 person-days. (GE)
Portability
  1. The system will run, without modification, on any Java target platform. (NF)
  2. The system is not portable. (X-all systems are portable)
  3. The system will run on Win 95/98, and NT 4.0/5.0 (X-not portability)
  4. Any Java-enabled web browser must be able to access the system data. (NM)
  5. The system will only work on WinTel machines. (NM, NQ)
  6. The software must be written endian-neutral. (GE)
  7. The software must be written character set-neutral. (GE)
  8. It must be possible to port the system to the MacIntosh platform with < 12 person-months of effort. (GE)
Predictability
  1. The system can never crash. (NF - never say never)
  2. The system must produce predictable results (UC, NM)
Recoverability
  1. During a system restart, the system will return to a functioning state. (GE)
Reliability
  1. The system will be available 100% of the time (X-not reliability)
  2. The MTBF is required to be > one week. (INC - What's a failure?)
  3. The system must never crash. (NF)
Resource Consumption
  1. The system must consume a maximum of 16 Mbytes of memory. (GE)
  2. The system will use no more than 25% of system resources. (NM)
Response Time
  1. Query response time must be fast. (NM)
  2. All queries must return a response in < 2 seconds. (NF-all is the problem)
Reusability
  1. All transactions must be encrypted. (NR, INC, UC)
  2. Only the teacher may modify grades. (NF, UC)
  3. The security system must be upgradable. (NM)
Security
  1. A password must be entered to use the system. (NR, weak - passwords provide little or no security)
Serviceability
  1. A trained support person can produce a localized version of the system without recompiling or rebuilding the system. (GE)
  2. A support person can reconfigure the system. (UC)
Speed
  1. The e-commerce engine must process a customer order in less than 100 ms. (GE)
Testability
  1. All major use cases must be regression tested. (GE)
  2. 100% of the quality requirements must be measurable. (GE)
  3. 100% of the quality requirements must be met by the end of CSC 206 (NF)
Thruput
  1. The system can process 100,000 checks per hour. (GE)
Understandability
  1. 90% of novice users can learn to operate major use cases without outside assistance. (GE)
  2. The main use cases must be accessible from the top screen. (GE if "main" is defined in the SRS)
Usability
  1. The UI must be user-friendly. (BW, NM)
  2. The UI will exhibit conceptual integrity. (NM)
  3. Dr. Cerf shall be satisified with the user interface. (GE)
  4. Dr. Meldal shall not be dissatisifed with the user interface. (GE)


Grading Symbols
NM - not measurable
NF - not feasible
UC - unclear
CIR - circular definition
NR - Not a requirement
INC - incomplete
BW - "bad word"
X - incorrect