Keep business requirements separate from interface specifications Do not directly derive your design from your use cases. There is a set of required fields for a well written use case. Requirements should be organized hierarchically. There are several reasons for this. First and foremost is that a hierarchical organization is needed to manage the complexity of the typical set of requirements.
Humans have a notoriously limited ability to deal with complexity.
Our rule of thumb is that the top-level requirements for the system should be expressed in no more than a dozen or so use cases. No layer of use cases should have more than five to ten times the number of uses cases in the next higher layer. If a lower level, a detailed use case is found that does not fit into an existing category, all higher levels of the use case hierarchy should be updated to reflect the new category. Use cases are best developed iterativaly and incrementally - the same way as the rest of the system deliverables. Hierarchical classification is not functional decomposition.