I am interested in the idea of combining use cases and features into a single coherent framework. In a different context, Alistair Cockburn has noted that one can match the line items of summary use cases with related high level features. For example, the use case line item “The user reviews existing claim information” Matches the feature set “system provides claim information.”
This approach provides a base linkage between use cases and feature sets. Furthermore, use case coverage and feature coverage reinforce and inform each other in a very useful way.
I am inclined to limit the linkages to this level and not attempt to link the full hierarchies of use cases and feature. But this is an open question.
Comments?
Can be done - depends on definitions
Hi jarcher99,
you can link use cases to features. I've done this several times where people are already using use cases and the use cases are working well for them.
Whether a use case line item maps to a single FDD Feature or an FDD Business Activity (feature set as you called it) is situational.
There isn't a consensus definition on what comprises a use case and what is an FDD Business Activity will vary from project to project. So, I don't see it possible to say generically that a use case maps to an FDD <whatever>. But for any given project, you certainly should be able to link from a use case into the FDD FBS (aka features list).
integrating features and use cases
jarcher99,
I have used a use-case driven approach with FDD successfully also.
I tend to map a use case to a feature set. Following a Cockburn-like template, I identify business events, user goals, pre & post conditions to form a skeletal use case. Add a paragraph on the business process giving attention to concise, consistent domain terms (ie nascent Classes). Then drive out features through JAD workshops - I usually list the features in the use case.
I find that the top hierarchy of FDD (subject areas) is usually readily identifiable, and the features tumble out of use cases. The middle reporting level ('feature sets') maps well to a use case, but I usually split the use case into two parts. This is because you often implement key features of each use case and defer the others to later builds.
The 'completion' word is critical in FDD. So you need to see feature sets 'completed' on the Parking Lot diagram. If you don't split the use case into two or more 'feature sets' you never get completion.
Use cases are dangerous but very useful things. Dangerous because of analysis paralysis, but useful because of the power of story and the fact that they map so well to real-world business events.
I tend to specify feature detail in a JIT manner. (I try to keep the use case body light). This avoids paralysis and forces constant, continual communication with the business. Nonetheless it is important to get wide, shallow coverage early so that a Domain model emerges to inform developer's detailed design.
Good luck.
Chris