FDD :: Develop an Overall Model


I had the pleasure of catching a 45 min (Wish it was 4 hours :) ) presentation from Jeff yesterday, 13/3 Melbourne Australia, about FDD.

I have a few questions

1) Develop an Overall Model what level is this taken to ? The last project I worked on had 2500 classes, should it be every one you can think of at the start, or just high level ?

2) I am working on embedded projects does FDD suit embedded, as there are concerns/risks that the HW does not work, does not arrive etc..

3) Feature List, does this feature list then become your requirements or is it a translation of shalls etc.. to your understanding of requirements. The last project we went for RUP and the use cases were being written/updated iteratively as was the software.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
szego's picture

Shape Modelling

Hi Matt,

Wow! 2500 classes? I'm sorry to hear that. Is that for an entire system, including business logic, user interface, system interfaces, persistence etc? We typically don't see that many classes. We build large systems, but they're usually line-of-business type apps for corporate and commercials these days, whereas you seem to do embedded systems so I'm not so sure if there be a correlation anyway.

We always layer our app into a Problem Domain (PD) that is the business logic, as well as UI, system interface (SI) and persistence layers (DM). The PD might be something like a couple hundred classes for a 12-month construct 50 person project. When you add in user interface this number can obviously baloon, as can things like "implementation" classes (I hate that word though) and interfaces for packaging etc.

The short answer to the Overall Model question is that we do what we call "shape modelling". By that we mean the focus of the model is the key classes and their associations only. We may capture a few key attributes (or even methods) for some classes, but this is not what we're concerned with primarily. What we are concerned with is that we get good coverage of the problem domain, as described by the domain walkthroughs described in process 1. Some people like to call this the "breadth" of the model, rather than then "depth" (but I have some problems with that terminology).

So our model would contain classes to capture all of the concepts presented during the domain walkthrough's, perhaps with a few key attributes, and all of the associations between the classes along with the correct cardinalities for the associations. Sometimes in the course of process one we run a sequence to validate some model shape, and might want to capture a few key methods that result from this.

We dont try to capture every attribute and method we can possibly think of! And we certainly don't try to include every possible class we can remotely justify. At this stage we go out of our way to get the simplest model possible that captures all of the problem domain as presented in the walkthroughs. We are looking for shape here, not content.

As far as embedded systems are concerned, FDD is really agnostic at this level. From my experience most of the differences with embedded are to do with the architecture and design constraints, and perhaps more of your requirements coming form standards documents rather than end users. At a lower level things like the development environment might be redically different, and an edit/build/test cycle may be significantly more complex if you dont have emulation available. The things you mention are all issues, but feel more like typical project management issues and really are outside the scope of what FDD addresses.

I think most difference would appear in the modelling - especially since we use Colour Modelling and the Archetypal Domain Shape. Note though that FDD doesn't mandate this - use whatever modelling approach you like (however the model in groups, present and then merge process is fundamental and necessary!). You tend to see more of a focus on the green party/place/thing classes with embedded than with the pink moment-intervals that are the key in business apps.

A fundamental shift here though is the language we use - maybe some "mental mapping" is necessary. So when we talk about "the customer" or the "domain expert" this might equate to some electrical and timing specifications for a bus in a PABX or the protocol spec for a layer in a comms stack.

So FDD still applies - it realy doesn't manadate technique down at the level where most differences are to be found when doing embedded systems development.

Hope this helps!

szego's picture

Features List == Requirements?

Hi Matt,

you raise a very interesting question about the features list! The answer is really "yes" and "no". Once we have the features list, it really is a complete specification of the requirements, but it doesn't attempt to replace or supercede any existing requirements documents in any way. The features list has to be a complete specification: once you've built every feature on this list (via processes #4 and #5) you are done! But the features list is not the "only" artifact that can be called the requirements - FDD doesn't state that. In fact during process #4 we even refer back to any existing requirements, either in the form of a person (domain expert) or document. It doesn't tackle the requirements issue, and it's left open on purpose.

As for use cases: given a choice we don't use them. But we have done a project with 3500 pages of use cases as the requirements. The features list become the point of reference, but the use cases were sometimes referenced. e.g. "Why are we doing this....oh - yeah, the use case said 'blah blah blah'..."

As for the requirements changing while you're building: yeah - that's a problem! If you're constrained by time/resources/cost then it's an issue. If you're not, then it doesn't matter.

We've never been asked to run a project like that. We do big projects - and the customer always wants to know what it's gonna cost, what they're gonna get, and when it will be done. They don't want it to vary - in fact they expect us to carry the risk.

So the features list isn't a silver bullet for scope creep, but it does give you incredible visibility into it. It's so granular that you can't hide new function in there without it being noticed. You can demonstrate an amazing level of control here - when something is new it's obviously new, and you can show exactly what the impact will be.

Changes happen - it's a part of life. Parnas talks about why they always will happen, even under the best conditions, as long as people are part of the equation. So when there's a change that needs to happen, of course you do it! But if I'm carrying the risk, then I want relief - timeline or $$$ or something. You can't eat it beyond about 10% - if one dimension grows more than 10% then you need to adjust something else. And with FDD you show great control by making it visible, and demonstrating exactly the impact it will have.

Have fun, PaulS :)

Jeff De Luca's picture

Functional requirements

I would add the qualifier that the features list is a complete specification of the functional requirements.


thanks for responses

Thanks for the great responses, the last project (2500 classes, 700K SLOK, 2K pages use case, iterative use case) was probably an exception rather than the rule. That was the biggest project my current employer had attempted, most of our work is embedded, my current project is only going to be on 40K ROM and 8K Ram which is one of the smallest products.