Сергей Мартыненко на текущем ЛАФ устроил мастер-класс по составлению списка вариантов использования. Он оттолкнулся от моего примера опубликованного в начале темы.
Правда я не во всем согласен в том подходе, который рассказывал на ЛАФ Сергей. Позже меня посетила мысль, вспоминание, что я где-то видел этот подход. Стоит наверное высказать его кратко.
По описанию ( в нашем случае использовался пример начала темы) выделялись объекты предметной области и сопутствующие понятия при работе с информацией.
Для каждого объекта применялся CRUDL анализ, напомню Create Read Update Delete(Deactivate) List.
List - вносить в список, перечислять. Отобразить список объектов данного типа.
Для каждого объекта проверяется потребность в CRUDL операции и на этом строится вариант использования или его сценарий.
Насколько я знаю такой подход активно используется (использовался) в базах данных. Можно ли назначать ВИ для каждой такой операции? Мне это показалось не совсем верным.
Потому активировать хочу тему, а за одно получить ответы на вопросы, которые я ранее задавал. Надеюсь, Сергей, ты ответишь (:
Мой подход:
1. выделить два уровня. Уровень моря и уровень змея.
2. Разделить на множество юзкейсов.
Почему так:
* Текущий ВИ "Создать меню" не проходит проверку на уровень моря
Почему не проходит.
Судя по твоим критериям - это либо некая бизнес-задача, либо время для исполнения не должно превышать 20 минут.
Я хочу с этим поспорить. Для начала озвучу критерия Крэга Лармана (они созвучны твоим):
1. Одобрение руководством – ВИ связан с выполнением функциональных обязанностей пользователя
2. Критерий элементарного бизнес-процесса. Элементарный бизнес-процесс – это задача, выполняемая одним человеком в одном месте в одно время в ответ на некоторое бизнес-событие, добавляющая бизнес-значение или переводящая данные в некоторое устойчивое состояние
3.Критерий размера. ВИ состоит из нескольких шагов и отображает некоторое законченное взаимодействие пользователя и системы
Мне кажется, ВИ Создать меню (Я бы конечно лучше сказал Создать меню блюд), вполне подойдет к этим критериям. Руководство вполне одобрит, что некто ответственный создает новое меню, это подходит и под описание ЭБП, да и критерий размера тут вполне подходит.
Потому, не соглашусь с критикой Сергея.
* Текущий ВИ не проходит проверку на полноту по методу "объект-действие"
Этого метода я не знаю, возможно это метод CRUDL. Был бы признателен, если Сергей поделится этим знанием.
* При моем подходе SRS будет более устойчива к изменениям
-- Вариант А. Реестр ВИ. (Может быть не самый лучший подход, но достаточно понятный)
1. Управление Меню. Уровень змея [включает в себя все нижеследующие].
2. Создание меню. Уровень моря.
3. Копирование меню. Уровень моря.
4. Просмотр меню. Уровень моря.
5. Редактирование меню. Уровень моря.
6. Просмотр списка меню. Уровень моря.
7. Удаление меню. Уровень моря.
Далее. <<5. Редактирование меню.>> можно оставить как есть, а можно сказать, что включает все операции, кроме операций с блюдами и все пять операций CRUDL с блюдами выписать отдельно. Последнее, на мой взгляд, лучше.
Итого моя рекомендация: Вместо одного ВИ напишите дюжину двух уровней.
Я понимаю, что ты расширил видение задачи. Это хорошо. Хотя исходная задача была иная. При этом в твой список представленный мною ВИ вошел без изменения и превратился в уровень моря, хотя выше ты утверждал иное.
Вариант использования Создать меню