How can you manage a large amount of use cases?
Candidate essential use cases are quite small, each describing one course of use of a system. Because of this, there can be a large number of them, perhaps 40-50 for a small system, and 200-300 for a medium sized system. This raises another problem: how do you manage and prioritise these use cases. In particular, how do you know where to start with the next part of design. Some use cases are more equal than other use cases. They may take more time (or impose more risk) to implement, they may be more important to actors (say because they will be performed more frequently than other use cases), or they may be more important to stakeholders (for their own impenetrable reasons). How can you placate the developers (who already think this is too big and too hard to build) while still honouring the stakeholders (who are paying for this, after all).
Therefore: Choose focal use cases to drive the design.
It's not easy choosing what to work on first. Everyone has their own idea of what's important. That's why we don't say ``important'', we say ``focal'': we choose to focus on these use cases to drive the design. Focal use cases are typically those that are the most important to users, but also include use cases to cover the main responsibilities to the stakeholders and cover risks expressed by development.
To identity focal use cases, you can print out the list of every use case, and then rapidly work through the list several times, each time giving each use case a score (say from 1 to 5) for one particular aspect of importance, such as: frequency of use, importance to stakeholders, risk to development, etc. Several developers can quickly rank each aspect in parallel, although its useful to have two or three estimates of each aspect. Then, add up the scores for each aspect, sort the use cases on different combinations of aspect scores (a spreadsheet is helpful here) and then choose the order that seems to make the most sense. The top 10% of use cases (to a maximum of 20) are your focal use cases.
In making this decision, it is useful to work towards a minimally useful system, that is, one that can be useful to some of the users. The reason for this is that some use cases identified as focal may depend on other use cases. For example, ``withdraw cash'' cannot be usefully done without any cash in the ATM, implying that a use case like ``add cash to cashbox'' will be needed as well.