Think you’ve got your requirements defined? Think FURPS!

One of the best ways I’ve found to ensure all the bases are covered when defining or reviewing system requirements is to use the FURPS checklist.

Created by Robert Grady, FURPS is an acronym for:

Functionality: This is the one most of us jot down when defining requirements. It answers the question, “What do I want the end product to do?” In addition to considering product features and capabilities, remember to think about what level of security is required.

Usability: Who will use the product? How will they use it? What look-and-feel do you want? What about help screens and self-help “wizards”? One often overlooked area is that of user documentation and training–often sub-projects unto themselves!

Reliability: What is your expectation in terms of system up-time? What do you consider an “acceptable” system failure? How quickly should the system be able to recover from a failure? What should the mean time between failures (MTBF) be?

Performance: Consider the functional requirements you have defined. What level of performance are you expecting? Think about speed, efficiency, availability, accuracy, response time, recovery time, and resource usage.

Supportability: How easy should it be to test the system; and how would this be done? What about maintenance–what’s your expectation in terms of system care and feeding? How configurable should the system be? What about installation–who should be able to install it?

Grady’s FURPS definition actually includes a “+” (FURPS+) lest we forget to consider:

+ Design Constraints: Anything the design team should be aware of in terms of how you would like the system designed?

+ Implementation Requirements: For example, do you expect the implementation team to adhere to a standard?

+ Interface Requirements: Any legacy or other external systems the product should interact with? How / When should this interaction occur?

+ Physical Requirements: Material? Shape? Size? Weight? (This one’s more geared toward hardware requirements)

I’ve just scratched the surface in this post–each of these areas easily warrants a dedicated article to elaborate on details. For a far more detailed explanation than I could ever provide here, check out Robert Grady’s book, Practical Software Metrics for Project Management and Process Improvement, (Prentice Hall).