Okay, I've been reading about FDD on and off for the past 9 months. The process makes sense and follows very closesly to other popular development processes. The most popular of which utilize Use Cases or User Stories in some shape or form. So, I'm confused on how Feature Sets and Features are not identical to Use Cases and their individual steps. What is wrong with writing a Use Case in the following manner:
UC 113 - Verify Hardware Module Properties
1. [Action] [Result] [Object]
2. [Action] [Result] [Object]
3. [Action] [Result] [Object]
4. [Action] [Result] [Object]
5. [Action] [Result] [Object]
6. [Action] [Result] [Object]
7. [Action] [Result] [Object]
8. [Action] [Result] [Object]
9. [Action] [Result] [Object]
10. use case ends.
There is absolutely nothing wrong with that. Geez, that Use Case looks a lot like a Feature Set. Rather, explain to me why a feature set is not a use case. How many different ways do we need to slice this thing...man.
Oh, I could also montior the progress of all my use case the same as how feature sets are monitored. Don't get me wrong, the ideas coming out of FDD are awesome...I just would not have spawned an entire new development theroy. To me, it is proposing better ways for organizing, reporting, and tracking a UCDD process.
FDD is repackaged UCDD
There are others on the group here who are better qualified to give a definitive answer, but I'll give a few thoughts as to why FDD may have gained traction over UCDD.
First and foremost UCDD inherits from RUP, which gives an impression of being big, expensive and complicated. Even if there were no differences between them on a practical level, the impression of the complexity of use cases will work against UCDD.
That impression of complexity is not helped by aspects that are left undefined. For example: at a conference last year in Portsmouth I attended a panel debate on Agile vs. RUP. The question came up about how to decide when you had done enough design to start the coding.
The answer from the Agile team was basically: keep designing until you are confident you have enough information to proceed. That's not a great answer, but I can understand it. I can guage my own confidence level and make a decision.
The answer from the RUP team was almost meaningless: "You have to write the right use cases and write the use cases right". :? That doesn't help...
Finally to my mind FDD is one of very few processes that has a balanced approach to design. Design is not an artefact that must be produced in specific detail for every element of your project, nor is it something to be avoided or captured in code and test cases. It is a communications tool that helps ensure the required features are delivered.
I know this is just a series of impressions and not an explanation of why a feature set is not a use case, but it does go towards you question of how many different ways we need to slice this thing...man.
It needs to be sliced in different ways until the vast majority of us 'get it' in one form or another. If you get it in UCDD but not FDD, and I get it in FDD but not UCDD, then at the end of the day we can both use our preferred approach to produce code efficiently and effectively ... and that is the goal.
Brian.
Use Case != Feature
Hi,
you raise a few questions, so I'll try to answer them one at a time. There are many differences between a use case and a feature, but the fundamental one is that they address totally different concerns.
Use cases are an attempt to specify requirements, and are performed up front before any analysis or design is attempted. Features on the other hand are enumerated *after* the initial modelling activity, or Process 1 in FDD, and are a decomposition of the problem domain.
This is a fundamental difference: the domain itself, which a good object model should attempt to capture, rarely changes. The ad-hoc requirements for a software system that addresses some aspect of a business in that domain are far more volatile.
Their are other differences, such as granularity and how open they are to interpretation, but I see these as side effects of them addressing different concerns.
We have done large projects where the requirements were provided as Use Cases - these are just another form of requirements. Note that FDD doesn't say how requirements should be gathered. I personally would not recomend use cases, but if that's the form your requirements are specified in then use them as an input to process 1.
Despite some misconceptions, you cannot start with trying to enumerate features. In FDD we use "shape modelling" as the initial analytical activity that gets us enough information to then go on and build the features list.
HTH, Paul.
UCDD?
Hi,
I'd not heard of UCDD, so I tried to google it but found very little. There's a mention of it by Ambler in "Agile Modelling Driven Design", but the reference points to the Use Case driven Object Modelling book. I'm not sure how he made the leap from a modelling approach to a development methodology.
The other mention was a paper by Jacobson, back in 1987. If we're talking about RUP, then there are fundamental differences.
If not, can you point me to more references on UCDD?
Paul.
P.S. Doesn't Ambler's AMDD process diagram look *very* familiar?
Self-fulfilling prophecy
If you define a use case to be exactly what a feature is then of course they will look the same. If you then assume one predates the other you will also conclude one is a repackaging of the other.
I don't see people defining use case the way you have.
I've never even heard of the term UCDD till this thread.
So, if that's what you're doing and it's working for you - then great! keep doing it.
Jeff