Source: http://en.wikipedia.org/wiki/Furps
Nowhere does it say that you must dispense with all prior knowledge in order to be agile. The FURPS+ card is a good example of a tool I've found useful in non-agile years long past, and still useful in the context of an agile project.
In agile, we don't refer to requirements; instead we talk about stories. Stories are really reminders for customer needs (requirements, in the general sense). We will refine these needs into product through continual discussion. We demonstrate confidence in our ability to ship software product by executing tests that represent acceptance criteria for each story.
Deriving a list of stories to represent a deliverable product is something that must happen in order to plan a release cycle. This backlog of stories must of course include all the customer's functional needs, as well as their non-functional needs. Non-functional? Many "real" customers don't think about such things.
The FURPS+ acronym, devised by Robert Grady of HP, provides a bit more meat around what we mean by non-functional stories, and also provides a good way to categorize such needs. The breakdown here suggests some representative questions around potential needs.
- Functionality - What the customer wants! Note that this includes security-related needs.
- Usability - How effective is the product from the standpoint of the person who must use it? Is it aesthetically acceptable? Is the documentation accurate and complete?
- Reliability - What is the maximum acceptable system downtime? Are failures predictable? Can we demonstrate the accuracy of results? How is the system recovered?
- Performance - How fast must it be? What's the maximum response time? What's the throughput? What's the memory consumption?
- Supportability - Is it testable, extensible, serviceable, installable, and configurable? Can it be monitored?
The + reminds us of a few additional needs that a customer could have:
- Design constraints - Do things like I/O devices or DBMS constrain how the software must be built?
- Implementation requirements - Do the programmers need to adhere to standards? Is the use of TDD required? Is statistically sound testing in the context of Cleanroom required?
- Interface requirements - What downstream feeds must be created? What other systems must this one interface with? How frequent are feeds produced?
- Physical requirements - What hardware must the system be deployable on? Must we be able to deploy to a machine no larger than 12" square, to be stationed in the Iraqi desert?
Just remember, in agile, stories are negotiable (but end product is usually not)!
I just came across a June 2009 presentation by Grady Booch on Software Architecture (that is largely based on similar slides he's given on the topic for the last 5 years). He listed the following:
ReplyDelete- Functionality
- Usability
- Resilience
- Performance
- Reuse
- Comprehensibility
- Economic & Technology Constraints & Tradeoffs
- Aesthetic Concerns
I notice the isnt quite exactly the same as yours (but close enough). I also notice that if I separate "Economic" from "Technology" above and slightly change the ordering I get an acronym of "FURPS REACT"
The "FURPS-REACT" acronym might be more suggestive/meaningful than simple FURPS plus. You may want to change one or two things in it (e.g., maybe 'T' would be better of as Testability, and we'd want something else instead of 'Aesthetics' for the 'A')
Just a thought! take it or leave it :-)
Hi Brad-- Just saw this comment, great idea! I never really remembered the + elements, and would appreciate an expanded mnemonic. We'll definitely revisit this one.
ReplyDeleteSaqib:
ReplyDelete"Requirements" and "wishlist" are really similar terms. In agile teams, we have a "backlog" (really two, one for the product and one for the sprint, but that's a different story). FURPS+ helps to define the stories (wishlist items) we need to put into our backlog (wishlist). While that's not technically 100% accurate, it is the right way to think about such things.
Also, FURPS+ helps us to think of tests we want to run against our stories. Maybe we've considered the happy paths (when the feature works) but not looked at failure modes, recovery modes, how the feature interacts with other features, edge cases for numeric limits (leap years, for instance, or negative numbers). FURPS+ reminds us of other categories of interaction or other cases of success/failure that we might not have considered before.
Tim