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?