Сергей, большое спасибо за анализ.
Согласен с Денисом. Так было бы гораздо интереснее. Но если сузить задачу, то...
Это Ваше право
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)
Но я не готов обсуждать это в данном случае, так как цели задачи иные.
Давайте попробуем. Начнём в проблем:
Есть несколько замечаний:
1. Основное: обычно под проблемами понимаются проблемы бизнеса в целом, а не конкретных заинтересованных лиц. "Трудоёмкость регистрации читателя"? Разве владельцу бизнеса должны быть интересны проблемы "негров"? Сотрудникам трудно регистрировать читателей? Да наплевать, если это не приводит к потере прибыли или снижению других важных показателей бизнеса. Надо задать вопрос что плохого в трудоёмкости регистрации читателей? Возможно клиенты уходят к конкурентам? Или из "министерства" грозятся уволить директора за плохие показатели? И как это отражается на достижении целей бизнеса, к чему приводит?
Вполне возможно, но в данном случае мы опускаемся чуть ниже к этим самым неграм. Соглашусь, что трудоемкость - как краткая формулировка мало понятна. Избыточная трудоемкость - лучше?
2. "Повторная регистрация", "Информация о наличии"... Это вообще непонятно что. Можно ли себе представить, что существует проблема "Информация о наличии"? Надо переформулировать.
Полностью согласен. Хотя необходимость повторной регистрации в каждом филиале - явная проблема
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)
. Какие бы Вы формулировки предложили?
Напомню пример создавался автором, что называется с колес.
Запросы заинтересованных лиц:
Обычно под этим понимаются самые первые необработанные источники:
1. Электронные письма (дословно).
2. Документы с "требованиями", как это понимает заказчик. Обычно "неструктурированный поток мыслей".
3. Протоколы совещаний.
В данном случае, поскольку в рамка учебного курса невозможно смоделировать реальные запросы ЗЛ и взаимодействия с ними, то упрощается до формулировки предполагаемых потребностей, устраняющих проблему (concern - озабоченность) ЗЛ
Возможности:В документе они больше похожи на варианты использования. Для того чтобы правильно настроиться на правильную формулировку возможностей (Features) я обычно вспоминаю маркетологов МВидео, Эльдорадо, Техносила. Они очень хорошо формулируют на уличных билбордах фичи различной электроники. Что-то типа:
1. Быстрая подготовка к работе.
2. Удобство использования.
3. Высокая производительность.
4. Развлечения и работа.
Я согласен, что свойства к качеству должны быть заявлены, но где функциональные свойства? Естественно, если Вы запишите "ввод, изменение, удаление данных о.." разве это не будет функциональной возможностью, функцией, свойством будущей системы?
Системные требования:
Насколько я понимаю предполагается представление требований в виде вариантов использования. Есть следующие замечания:
1. Основная часть ВИ - сценарии основного и альтернативных потоков. В документе я не увидел пошаговых сценариев с описанием команд экторов и ответов системы.
2. "Проверка дублирования" и прочие подобные - это не варианты использования. Правильная формулировка предусматривает получение эктором некоторого сервиса от системы.
Тут я следую рекомендациям моего эксперта. Это не сами прецеденты, это требования типа прецеденты, которые впоследствии будет развернуты в полноценные сценарии и диаграммы активности типа черный ящик.
Системный требования я оставил для полноты. Давайте, пока оставим их в данном случае вне поля нашего рассмотрения. Хорошо?