FURPS+

Et akronym for kvalitetsegenskaber i IT

Functionality (F)

What the customer wants! Incl. security-related needs. What the application should do. These requirements describe the system’s general features including what it does, interfaces with other systems, security, and so forth.

Usability (U)

How effective is the product from the standpoint of the person who must use it? What the program should look like. These requirements describe user-oriented features such as the application’s general appearance, ease of use, navigation methods, and responsiveness.

Reliability (R)

Maximum acceptable system downtime? Failures rate Ect. How reliable the system should be. These requirements indicate such things as when the system should be available (12 hours per day from 7:00 a.m. to 8:00 p.m.), how often it can fail (3 times per year for no more than 1 hour each time), and how accurate the system is (80 percent of the service calls must start within their predicted delivery windows).

Performance (P)

How fast must it be? Ect. How efficient the system should be. These requirements describe such things as the application’s speed, memory usage, disk usage, and database capacity.

Supportability (S)

Is it testable, installable, and configurable? Can it be monitored? Ect.
How easy it is to support the application. These requirements include such things as how easy it will be to maintain the application, how easy it is to test the code, and how flexible the application is. (For example, the application might let users set parameters to determine how it behaves.)

+

Reminds us that there are more concerns …

Design constraints - These are constraints on the design that are driven by other factors such as the hardware platform, software platform, network characteristics, or database. For example, suppose you’re building a financial application and you want an extremely reliable backup system. In that case, you might require the project to use a shadowed or mirrored database in case the main database crashes. You might even require the shadow database to be stored off-site in case the main site is hit by an asteroid or something. (I’ve worked on a couple of projects with that requirement.)

Implementation requirements - These are constraints on the way the software is built. For example, you might require developers to meet the Capability Maturity Model Integration (CMMI) or ISO 9001 standards.

Interface requirements - These are constraints on the system’s interfaces with other systems. They tell what other systems will exchange data with the one you’re building. They describe things like the kinds of interactions that will take place, when they will occur, and the format of the data that will be exchanged.

Physical requirements - These are constraints on the hardware and physical devices that the system will use. For example, they might require a minimum amount of processing power, a maximum amount of electrical power, easy portability (such as a tablet or smartphone), touch screens, or environmental features (must work in boiling acid).