FrWithoutUseCases
From SPA Wiki
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.