From: Andrew Gabb (agabb@tpgi.com.au)
Date: Sat Aug 30 2003 - 14:03:52 EST
Jim_Archer@or.blm.gov:
> First, it's interesting that the problem of functional vs.
> non-functional requirements arises in the context of use
> cases. It's not hard to see why. Use cases focus on
> event/response threads through the system whereas
> non-functional requirements focus on the properties of those
> events. "Do it" verses "do it fast". Perhaps the problem is
> not with non-functional requirements but with the focus on
> use cases. If use cases are relegated to a secondary rather
> than primary role in requirement development, then the
> problem largely disappears.
Part of the problem of comparing use cases with 'non-functional requirements' is that the relationship is nowhere near as simple as "Use cases focus on event/response threads through the system whereas non-functional requirements focus on the properties of those events."
This is true in some cases but not others. For example, design constraints may or may not be derived from examples of use. They may be driven by supplier policy (eg development in Java) or technical regulatory requirements (design constraints for safety/security etc.), or many other factors.
Use cases and scenarios, particularly if extended beyond the activities of the immediate operational user (to logistics activities for example) - as they should be - are very useful as a basis for establishing correctness, completeness and context for the requirements relating to those activities. But use cases only present part of the picture, and it doesn't matter how many use cases we have, and how brilliantly we create new ones, there are some requirements which cannot be adequately represented that way.
Use cases, if you like, are only one dimension of the requirements picture, and users are only one form of stakeholder. Ignoring that will make you vulnerable to all sorts of other problems.
This is yet another example of Gabb's Impurity Principle I guess, which in this context might state that nothing is ever as clear-cut and obvious as we'd like it to be.
Andrew
This archive was generated by hypermail 2.1.6 : Mon Sep 01 2003 - 09:00:12 EST