FrWithoutUseCases

From SPA Wiki

Jump to: navigation, search

BOF on Functional Requirements without Use Cases Bruce Anderson [facilitator] and Richard Mitchell

Recently I've been involved in several projects where use cases weren't appropriate for expressing the functional requirements, but I haven't heard this discussed much - the current orthodoxy in RUP and other proprietary methods is that use cases do the trick. I asked people who had done FrwUC to identify themselves, and then had the other participants interview them one-to-one. After that we listed the technique/artefact used, and the project characteristics, hoping to create a map.

  • Spreadsheet of features and tests >> needed schedulable requirements [using Coad's FDD]
  • Functional tests and (temporary) story cards >> XP, 3-week delivery cycles for internet applications
  • "Structured English" / pseudo-code >> not very successful
  • Use cases with "spurious actors" [principally clocks] >> online banking and comms, highly asynchronous
  • Lots of text and rules >> use case paralysis [not successful]
  • Activity diagrams (business processes) %2b classes (business objects) %2b some use cases (interactions) >> batch processing, rule-driven, clock-driven [back-office processing]
  • Use cases and business type model >> control hacking [what does this mean? take better notes, Bruce!]
  • State diagram [finite state machine] >> call-centre telephony
  • Business processes %2b activity diagrams [small processes] %2b rules [become methods] %2b business objects >> batch, rules etc [back-office processing]
Conclusions [by Bruce]

Use cases work when they work because processing is in small units driven by the structure of the business interaction - dialogue between users and developers is constructive Declarative models are much harder to create, because users have much less skill in understanding what has to be done when - they can report on practice, but not on possibilities It'a always a good idea to use a business type model with users - really, to create it with them - as this simplifies making the glossary, and gives a set of concepts for expressing the rest of the requirements

Acknowledgements

This account does not do full justice to the participants or discussion - in particular there was no XP-versus-RUP (etc) pettiness - user stories are just low-effort use cases.