Занимаюсь написанием дипломной работы по теме разработка ИС.
Хочу для себя получить опыт разработки подобных систем, их документирования, управления требованиями...

Написал документ об обзоре и границах для данного проекта, просьба прокоментировать что сделано не правильно, что можно было бы изменить...


Так же набросал UseCase для данной ИС, если будет нужен могу выложить

На мой взгляд попытка не удалась.

Исходные данные - крайне скудно. Совершенно не понятно, что за заказы, в чем собственно проблема, почему отсутствие автоматизации - это плохо?

Возможности бизнес-заказчика - а текст как связан с заголовком?

Бизнес цели и критерии успеха - цели бывают качественные и количественные, критерии это количественный показатель достижения или не достижения цели
Улучшить качество обслуживания клиентов - это то значит? Увеличить скорость - насколько? Снизить затраты - на сколько за счет чего?

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

Далее. у Вас то система для заказаов, то система для контрактов?

Сам образ написан более внятно. Правда профили ЗЛ очень скудные. Рукводство слишком абстрактная роль.

Посмотрел документ.
1. Думаю имеет смысл явно выделить раздел в котором указывать problem definitions. И имеет смысл либо делать это в виде  классической таблицы Проблема ... - затрагивает ... - Ее следствием является ... - Успешным решением будет ..., либо просто в виде списка где каждая проблема будет иметь свой ID.
2. У вас раздел называется "Бизнес-цели и критерии успеха". Цели обозначены, но звучат неубедительно -- т.к. нет тех самых критериев.  Для указанных вами целей стоит привести ожидаемые оценки -- как вы будете измерять улучшение качества обслуживания клиентов, насколько увеличиться скорость работы с заказами, насколько будет снижены затраты на ведение заказов. А за счет чего это будет достигнуто -- указать либо в разделе "Возможности бизнеса заказчика" либо прямо в problem definitions, при условии если проблемы и цели имеют четкую и прямую, а не опосредованную связь. Еще одно -- у целей тоже должны быть уникальные идентификаторы, я например использую BG1, BG2, ...
3. То же самое с рисками -- должны иметь идентификаторы, и кроме этого желательно их "оцифровать" и показать пути миграции с них, хотябы в общих чертах.
4. В функиях системы стоит "Взаимодействие с клиентом", если честно я не понимаю что имеется ввиду -- толи возможность клерка взаимодействовать с клиентом посредством системы (каким образом???), толи вы говорите что система не собственно софт, а система в ГОСТовском понимании, включающая персонал -- тогда это будет похоже на функцию системы в ГОСТовском смысле. А вообще, это слабо похоже на функции, а больше на преимущества, которые получают пользователи системы. И стоит этот раздел именовать как Features. А фичи не всегда есть функции. И если это именно фичи должны быть, то раздел следует назвать "Высокоуровневые возможности и свойства системы". И перечислять именно фичи системы, а не получаемые преимущества.
5. Предположения и завсисмости невнятно сформулированы. Нужно более четко их сформулировать и привести внятное описание что под этим имеется ввиду. Например, что это предположение или зависимость "Прайс фирмы на услуги и товары" Не понятно.

спасибо за коментарии. учтем при переработке материала