FDD says nothing how requirements are formulated prior to process 1 - Develop an Overall (Domain) Model. In fact FDD downplays the importance of formal requirements and stresses the importance of participation of Domain experts. I know in part this is due to Jeff's, far from unique, prior experiences with Use Cases!
I have commented that - Any idiot can write a Use Case, and most of them do! What I mean by this is that the Use Case format and notation is loose and you can put pretty much anything in a Use Case format. This problem is exacerbated by Business Analysts who, while they understand the business, often have a limited grasp of what software developers need and can use. An additional problem is what I call the paid-by-word syndrome - aka more is better!
This often leads to much time and effort being expended on developing large numbers of Use Cases whose value is not commensurate with that effort.
FDD would argue that it is certainly more efficient, and probably more effective to get the requirements directly from the horse?s mouth, i.e. from Domain Experts in the context of Domain Modelling. I do not dispute this approach works but feel it has its limitations and there is a role for formal requirements.
I also use Use Case synonymously with formal requirements as this is the most widely used notation, and this is not a post about the merits of Use Cases versus other requirements notations. BTW, while I have always advocated formal requirements, I am a relatively recent convert to Use Cases and for anyone looking for a good how-to guide, I recommend Cockburn's Writing Effective Use Cases.
I would propose that formal requirements are done if one or more of the following apply.
1. The Domain Experts are not available: The people who know most about the business, are generally the people most valuable to the business, and scheduling large chunks of their time over several weeks of Modelling is frequently an issue. A separate formal requirements process mitigates this problem.
2. The system impacts multiple aspects of the business: This manifests itself in different Domain Experts saying different, often contradictory things, because they represent different aspects of the business. This not uncommonly surfaces inter-departmental rivalries - Marketing doesn't understand how things really work. It frequently takes time for different views to be synthesized into a consensus and formal requirements gives that time and opportunity.
3. The system is transformational to the business: Every system changes the way its host organization works - some more so than others. Frequently Domain Experts are focused on how the business works currently and have not given sufficient thought to how the new proposed system will change the organization. The good news is that these people are often the businesses brightest and most motivated people, and quickly get their head around the prospective changes. All they need is time to consider and a period of formal design does this.
4. The system is large: As the scale of any activity increases then the need for formalism and division of responsibility increases. The value of formal requirements increases as the size of the system increases. One consequence is that it helps keep Domain Modelling short and facilitates subdividing the Domain Modelling if appropriate.
5. The requirements exceed the capacity to deliver: What this means is that requirements must be prioritised, and substantial amounts deferred. This can be a difficult and contentious issue and is best kept out of Domain Modelling.
6. The organization itself is undergoing change: Organizations can undergo significant change. This could be because of market changes, legislative changes or that bunch of Management Consultants the CEO hired. It?s risky to try and design and develop a system while an organization is undergoing change. Frequently time and effort are expended on features that you suddenly discover - Oh, we are going to stop selling that product in December! Formal requirements help surface and resolve these issues in a cost-effective way.
In my view there is nothing to prevent you producing formal requirements as Use Cases in an FDD project and they can be of significant value. However, with the caveat that bad Use Cases can be more of a hindrance than a help!
Phil
