Hi,
I've recently learned about FDD and particularly liked the idea of using features for planning and controlling a project at a detailed level. We are currently starting a project and have produced a use case model (no detailed use case documentation), a high-level domain object model and a non-functional requirements document.
The idea I wanted to explore is to use the use case model as basis for the feature sets. Each use case could be a feature set and instead of defining the use case in detail we just identify features associated to each use case. We also identify feature sets from the non-functional requirements list (e.g. interface to accounting system, etc.).
For the testing part we are thinking about adding a tester to the domain walkthrough of each feature in order to come up with some test cases for functional testing.
Is this something that could work?
Thanks for your feedback and best regards,
Ernst
Building a features list from Use Cases
Hi
A common question and the answer frequently depends on the quality of the use case work done.
You can certainly build a features list from use cases and use cases, when done well, do often equate closely to feature sets because both are groupings of functional requirements.
However, unless you have done a rigourous job of factoring out includes and extends in your use cases you are likely to find that some features are used in more than one use case. If use case =feature set then you need to either pick which one the feature will be listed in or live with duplicate features in different featu5re sets and the added management complication that brings.
Also if the use cases are not defined at a similar level of granularity you may find some use cases with one or two features and others with many tens of features; again not ideal.
Personally I like to define feature sets separately to use cases but cross reference related use cases from each feature. This way, the use cases can be maintained independently of the features list if necessary.
There is more on this topic in my book A Practical Guide to FDD - see www.step-10.com for more details.
Have fun
You can link but not derive
I agree with Steve.
In addition, I would not use a use case model as the basis for business activities (feature sets - sic). In fact, I wouldn't do a use case model at all - but that's a separate topic. The features list and its categorisation comes from simple functional decompositon of the domain. This is easy to do after the informational/analytical activities that take place in the Develop an Overall Model process.
If you have use cases, linking back to them from features can be helpful.
Also, I can't see how you derive business activities from non-functional requirements. I also don't see "interface to accounting system" as a non-functional requirement. To me non-functional requirements are things like performance, usability, etc.
Jeff
UI Feature Sets and Use Cases
I've written about grouping UI layer Features based on Use Cases though I much prefer Larry Constantine's Task Cases (as part of his Usage Centered Design). However, I now favor the approach of modeling the whole UI as a Statechart or Visual Vocabularly diagram and then basing the Feature Sets for UI Features on the "containers" within the UI e.g. a tab pane.
I don't find basing Business Activities on Use Cases useful and it has been problematic on projects where it has been tried against my advice.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Per feature domain walkthrough is optional
Hi,
I missed the last part of your comment.
The domain walkthrough in the Design By Feature process is optional and is not held for enough of the features to rely on this as the sole means of knowledge transer to system test (remember that unit test is done by the developers and is a required step in the Build By Feature process).
You certainly could add a tester to each feature team as they form and reform but in most cases it will be the design (and design package) that would be the testers source of knowledge. If this is what you mean by functional test - then yes this is a good integration point. However, I call this unit test and the developers plus the chief programmer do it.
If you mean the more traditional kind of post-development testing then given that you started by saying you build use cases and use case models, I would have thought they are the primary source for testing (ignoring all the problems I have with use cases).
Jeff
QA finds the DBF Walkthrough most useful
At 4thpass (a Motorola company in Seattle, WA) the QA (test) team find that adding a tester to the Feature Team in step 4 is very useful. The testers use the walkthrough and the design session to provide input for the test cases.
Also we use a method which I now refer to as "Design by Feature Set" where we design the whole FS (or Business Activity if your talking PD layer) then we chop it into work packages for step 5 and shelve some until the others are completed. Hence, the walkthrough is for the full set of Features and allows multiple test cases to be written as a result.
The QA manager is on record as reporting that the step 4 DBF Walkthrough represents the optimal meeting for QA to enter the process - any earlier and requirements can be too nascent and subject to change - any later and QA is behind the flow and can't react quickly enough to the arrival of code from step 5.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Design By Feature and Build By Feature
Hmmm that's much too waterfall-ish for me. Design by Feature and Build By Feature could easily be renamed Design by Workpackage and Build by Workpackage as, operationally, that is exactly what happens. In the JMCU book, I stuck with the By Feature names as I felt the processes are much more easily understandable with those names. i.e. it is easy then in text or in a workshop to teach the real workflow and it doesn't break the understanding that we take whole features through design and build in one increment.
I've been tossing this one around for a while now for the next version of the processes. If I did change the process 4 and 5 names to reflect the workflow, then I would likely also change the name of the CPWP - Chief Programmer Workpackage (the main reason being that the role is not the most important aspect of this selection of features - the workflow is).
To design all features in a business activity (feature set) is to leave a great deal of flexibility, and hence risk reduction, on the table.
Also, as has been explained elsewhere, the Step 4 DBF walkthrough is an optional step and is not performed for all features. It sounds like you are doing it for all features - that is very unusual.
Jeff
Design By Feature and Build By Feature
I tend to agree with you on the names - simple is easy to remember and the workflow can be taught.
I disagree with you on the "waterfall" - Business Activities tend to fairly small - less than 1 month of work - it woudl still qualify as iterative and it reduces overhead.
I'm not sure I agree on the concept of leaving risk reduction on the table - this would be a dependent on the size of the Business Activity. If it is too large to do it in a month then yes, I would still break it down but I would question the analysis in the first place.
Yes, you are correct - we walkthrough all Features in DBF and we don't consider it optional.
I too have been tossing around the naming and the workflow concepts. I went one way in the book but it isn't necessarily my definitive and final opinion on it.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/