Как не упустить важное в описании
Как не упустить важное в описании сценария использования или бизнес-процесса?

Там, где больше одного участника, всегда есть минимум две картины мира, даже если входы и результаты общие. Типичная ситуация - заказчика интересуют условия соглашения об уровне сервиса (SLA), и ему не интересен внутренний регламент техподдержки, в то время как исполнителю такой регламент просто необходим для управления обслуживанием, включая оценку по KPI, однако SLA не менее значимо. Причем тут моделирование бизнес-процессов и юзкейсы? Оказывается, пересечения (совпадения) множеств интересов - это и есть системообразующие понятия.

Чтобы разобраться в конкретном случае, нарисуйте объектные модели с позиций видения ключевых стейкхолдеров - это могут быть простые онтологии верхнего уровня предметной области проекта.
В нашем примере это - схемы с похожим набором сущностей процесса сервисного обслуживания в представлениях исполнителя и заказчика: на рисунках белым обозначены одинаковые для двух участников понятия, желтым - характерные для каждого в отдельности. Для описания базового пользовательского сценария или типового бизнес-процесса с учетом интересов всех участников важно использовать, прежде всего, общие для всех сущности из объектных моделей.

Если все такие сущности включены в поток работ вашей модели, скорее всего, вы не упустили критично важные составляющие - следовательно, можно приступить к детализации по необходимости.