A GenericRequirement is one that applies to many or all functional requirements (e.g., UserStories), or more broadly to the SystemUnderDevelopment? (i.e., to none of the stories).
AlistairCockburn, in LimitsOfUserStories, lists some examples of 'examples you don't write stories for.' His list led me to organize GenericRequirements thusly:
- generic data requirement
- size (e.g., The customer's last name will be stored as 32 characters max.)
- validation
- organization/structure
- generic performance requirement
- response-time (e.g., Response time on user requests will be less than 3 seconds.)
- generic reliability requirement
- availability (e.g., System uptime will be at least 23.5 hours per day.)
- generic programming standard requirement (e.g., The system will be implemented in Java.)
- generic process requirement (e.g., The process used in developing the system will be ISO9001 certified.)
- generic usability interface requirement (usability?)
- interface (e.g., The application will work on IE4+ and NS4+.)
How can we use this, or some other taxonomy, to facilitate efficient testing of a
GenericRequirement? That is, you want a way to a) describe the requirement that doesn't violate
OnceAndOnlyOnce - and even more to the point, b) write the
tests OnceAndOnlyOnce.
-- RaySchnitzler