A detection use case is only valuable if an analyst can trust it enough to act on it. That trust comes from structure, not volume of rules.
Name the exact threat scenario
'Unauthorized engineering workstation change outside an approved maintenance window' is a use case. 'Detect malware' is an aspiration, not a use case.
Name the data source explicitly
If you cannot name the specific log, network capture, or system record that would reveal the scenario, you do not have real coverage for it yet -- no matter what the architecture diagram implies.
Define true positive and false positive up front
Write down, before the rule ever fires in production, what a confirmed real event looks like versus a benign explanation, so triage does not have to be invented in the moment.
Attach the response action
Every use case should come with a defined next step when it fires -- escalate to whom, at what severity, through what channel. A detection with no defined response is an alert waiting to become noise.
Prioritize by consequence, not ease of collection
Build use cases around your highest-consequence risk register entries first, not around whatever data happened to be easiest to onboard into your tooling.