The most serious problems have to do with requirements - getting the right requirements and getting the requirement right. The larger and more complex the system being developed, the more that requirements problems become among the highest risk factors. This is true regardless of the domain. I have personally observed this within aerospace, telephony, financial systems, inventory control, and a wide variety of other domains. A major point of this column is that simply using use cases to specify requirements does not automatically mean that you will get good requirements.
Use cases are no more than a structured format for gathering and expressing requirements.
A good format is helpful but not sufficient. In both cases the developed system will not meet the needs of the organization. It is my hypothesis that good use case development relies on the knowledge gained during domain analysis. Conversely, to understand a domain, it is helpful to know the actors and the major domain activities. This implies that an iterative process that includes both domain analysis and use case development is essential to getting good requirements.