The first use case chosen in most organisations is chosen by enthusiasm. Someone has seen a demonstration, the demonstration was impressive, and the work of finding a use case turns into the work of justifying the one already picked. The cost of that order of events is not the licence fee. It is the months spent on a project nobody can stop, because stopping it would mean admitting the choice was made before the evidence arrived.
Start with a decision rather than a technology. Ask which decision changes if the system works, who makes that decision today, and what they would do differently on Monday morning. If the honest answer is that nothing changes except the amount of typing, the candidate is a convenience feature rather than a use case. Convenience features can still be worth building, but they should be labelled as such: they will not survive a budget review and they should not carry the weight of a pilot. A use case that changes a decision has a natural owner, and that owner will say plainly when the output is not good enough.
Then judge the inputs. A use case is only as good as the material it reads, and most of the work sits in the material rather than in the model. Find out where the documents live, who can grant access to them, how often they change, and what happens to them when someone is on leave. Read a sample of thirty real cases, not the ten clean ones that were used in the demonstration. If a field is missing in a third of the sample, that is a finding about the process, and it is worth more than any comparison of models.
Prefer work that is repetitive and tolerant of review. The question to ask is not how accurate the system is in general, but what happens on the day it is wrong. If a person already checks the output as part of their job, adding a suggestion to their screen is a small change. If nobody checks it and the output goes straight to a customer, a rare mistake can cost more than the task was ever worth. Error tolerance has to be decided before the build, by the people who carry the consequences, not after the results arrive.
Choose something you can stop. A candidate that touches one workflow, one team and one data source can be reversed in a week, and the people who have to live with it will speak honestly while it is still cheap to change course. A candidate that rewrites the customer record, the pricing rules and the reporting layer at once cannot be stopped without a programme of work, so nobody will stop it, and the decision to continue will be made by default rather than on evidence.
Write the test set before the build starts. Take real cases with known answers, including the awkward ones: the handwritten form, the scanned attachment, the customer who writes in two languages, the order that was corrected by hand last month. Agree in advance what result would justify continuing and what result would justify stopping. A shortlist scored on those grounds, rather than on how impressive a demonstration looked, is the cheapest part of the exercise and the part most often skipped. Writing the criteria down costs an afternoon; skipping them costs a project with no stop condition.