Hi,
I am involved in a somewhat larger project in the embedded domain. Traditionally, embedded systems have tremendously grown over the last couple of years whereas the ways of working have often remained, well, chaotic to ad-hoc at best. This also includes the way requirements are (not) captured.
In my cases, requirements come to us from Telco operators, product management, and a technical system group outside of the actual SW development. Our input is somewhere between Power Point and Excel.
In that context, I would have thought high-level use cases for capturing functional or at least the behavioral requirements would actually be a progress towards the right direction. However, having read about FDD I am somewhat confused. I have started wondering whether finer-grained features as suggested by FDD can be used INSTEAD of Use Cases or are a secondary step.
According to Cockburn you would start breath-first use cases without much detail, and then refine as you move towards implementation.
So how does FDD scale up to fairly large projects (300 developers, various sites,...)
And do I need Use Cases at all?
Cheers,
Thomas
They co-exist well
Hi Thomas,
I'm basically for "whatever works." If use cases are working for you, then keep using them.
I'm not a fan of use cases myself and if it's a green-field - I don't use them. Having said that, I've worked with use cases often and continue to do so in project and consulting work.
Use cases are good at capturing the interactions between an actor and a system and that can be a good fit for embedded work.
Whether it is an embedded system or not and use cases are in place, it is not an either or decision regarding features. Fine-grained features in a Feature Breakdown Structure (FBS) can (and should IMHO) be used along with use cases where use cases are required. That's what we do when use cases are a part of a client's standards.
Regarding FDD scaling up - what aspect of this do you have a question with? Much of FDD comes from my experiences working in a (approx) 1000 developer organisation. I can see no reason it can't scale to that size. There are structures you need as projects get bigger - and these are not documented well for FDD. That's something I'll take on for future newsletters. But, if you have any specific questions I'd be happy to try and answer them.
Jeff