Расписывая прецеденты системы которую проектирую, у меня закрался вопрос: Правильно ли я это делаю? Решил спросить вас. Чтобы не лезть в дебри начнём с конкретного.
Пользователь запустил систему. В этот момент есть два варианта развития событий:
1. Список учётных записей системы пуст и система предлагает пользователю создать первую учётную запись.
2. Список учётных записей системы НЕ пуст и система предлагает пользователю выбрать учётную запись из списка, и ввести пароль, для входа в систему.
Я описал этот момент в прецедентах так (формат описания прецедента взял из книги которую читаю):
Описал три прецедента: Запуск системы, Создание первой учётной записи и Выбор учётной записи из списка:
Прецедент: Запуск системы Краткое описание: Пользователь запускает систему Главные актёры: Пользователь Второстепенные актёры: Нет Предусловия:
1. Пользователь запустил систему Основной поток:
1. Прецедент начинается когда пользователь запускает систему
2. Система загружает список учётных записей
3. Если (Список учётных записей системы пуст)
3.1. Система предлагает создать первую учётную запись
4. Иначе
4.1. Система предлагает выбрать учётную запись из списка Постусловия:
1. Система запущена Альтернативные потоки:
1. Отмена
Прецедент: Создание первой учётной записи Краткое описание: Пользователь создаёт первую учётную запись в системе Главные актёры: Пользователь Второстепенные актёры: Нет Предусловия:
1. Система запущена
2. Список учётных записей пуст Основной поток:
1. Прецедент начинается когда система предлагает создать первую учётную запись
2. Система предлагает ввести данные учётной записи и контрольный вопрос для восстановления пароля
3. Пользователь вводит данные и контрольный вопрос
4. Система предлагает установить пароль учётной записи
5. Пользователь устанавливает пароль
6. Система сообщает пользователю, что учётная запись создана
7. Система добавляет первую учётную запись в список учётных записей системы
8. Система отображает список учётных записей Постусловия:
1. Первая учётная запись создана
2. Список учётных записей НЕ пуст
3. Система отобразила список учётных записей Альтернативные потоки:
1. Отмена
Прецедент: Выбор учётной записи из списка Краткое описание: Пользователь выбирает учётную запись из списка и вводит пароль Главные актёры: Пользователь Второстепенные актёры: Нет Предусловия:
1. Система запущена
2. Список учётных записей системы НЕ пуст Основной поток:
1. Прецедент начинается когда система предлагает пользователю выбрать учётную запись из списка
2. Пользователь выбирает учётную запись из списка
3. Пока (Пользователь три раза не введёт не верный пароль)
3.1. Система предлагает ввести пароль для выбранной учётной записи
3.2. Пользователь вводит пароль
3.3. Система проверяет введённый пароль
3.4. Если (Пароль не верен)
3.4.1. Система сообщает пользователю, что пароль не верен
3.5. Иначе
3.5.1. Пользователь входит в систему
4. Система блокирует пароль учётной записи
5. Система сообщает пользователю, что пароль учётной записи блокирован
6. Система предлагает пользователю восстановить пароль Постусловия: Нет Альтернативные потоки:
1. Отмена
Первый вопрос в том, что например в прецеденте Выбор учётной записи из списка можно выделить прецедент Ввод пароля и разбить прецедент Выбор учётной записи из списка на два. Также можно в прецеденте Создание первой учётной записи выделить прецедент Установка пароля для новой учётной записи и описать все нюансы этого процесса, такие как проверка соответствию определённым параметрам, типа длинны пароля или его "стойкости". В общем существует множество вариантов описать данный процесс в прецедентах. Можно выделить как три прецедента, но ни что не мешает выделить и пять. Так на чём стоит остановиться
Ещё вопрос: Стоит ли упиваться описанием прецедентов или рассматривать это процесс как вспомогательное средство и описывать только самые важные аспекты функционирования системы
:)
Re: Ориентируетесь на людей, к-ые это будут читать
Здравствуйте, Cynic, Вы писали:
C>Первый вопрос в том, что например в прецеденте Выбор учётной записи из списка можно выделить прецедент Ввод пароля и разбить прецедент Выбор учётной записи из списка на два. Также можно в прецеденте Создание первой учётной записи выделить прецедент Установка пароля для новой учётной записи и описать все нюансы этого процесса, такие как проверка соответствию определённым параметрам, типа длинны пароля или его "стойкости". В общем существует множество вариантов описать данный процесс в прецедентах. Можно выделить как три прецедента, но ни что не мешает выделить и пять. Так на чём стоит остановиться C>Ещё вопрос: Стоит ли упиваться описанием прецедентов или рассматривать это процесс как вспомогательное средство и описывать только самые важные аспекты функционирования системы
Прежде всего вам нужно понять, для чего вы преценденты пишете? Если вам нужна полная спецификация системы для оценки и передачи в разработку, то вам нужно писать все преценденты, доменную модель, UI, тест кейсы, нефункциональне требования и кучу пояснительного текста. Если вы это для себя решили документировать, то думаю принципиальных use-case-ов вам хватит.
Cоответсвенно выбирайте уровень детализации.
Плюс имейте в виду, что use-case это некоторый завершенный сценарий использования системы, описывающий операцию с бизнес смыслом. Продажа, перевод, приемка на склад и т.д. Есть у кейса ввод пароля самостоятельное бизнес значение?
Что касается того, как разбивать на куски, ориентируйтесь на сложность восприятия. Use-case-ы обычно пишут, чтобы задокументировать ожидаемое поведений системы и акторов. ЭТУ ДОКУМЕНТАЦИЮ БУДУТ ЧИТАТЬ ЛЮДИ. Поэтому главное, чтобы она была точной и легко воспринимаемой. Создание отдельной сущности "ввод пароля" улучшит читаемость?
Re[2]: Ориентируетесь на людей, к-ые это будут читать
От:
Аноним
Дата:
27.10.10 10:11
Оценка:
Здравствуйте, Gurney, Вы писали:
G>Прежде всего вам нужно понять, для чего вы преценденты пишете? Если вам нужна полная спецификация системы для оценки и передачи в разработку, то вам нужно писать все преценденты, доменную модель, UI, тест кейсы, нефункциональне требования и кучу пояснительного текста. Если вы это для себя решили документировать, то думаю принципиальных use-case-ов вам хватит. G>Cоответсвенно выбирайте уровень детализации.
Делаю я это, для того чтобы хоть раз в жизни спроектировать систему нормально, как в учебнике Элементы проектирования присутствовали и раньше, но теперь я взялся сделать всё по уму. Т.е. Выявить требования -> Выявить прецеденты -> Провести анализ -> Спроектировать -> Реализовать -> Тестировать. Естественно не водопадом, а как в UP принято.
Соответственно для чего я это делаю? Я это делаю для того, чтобы на ранних этапах выявить требования — скрытую от моего пристального функциональность системы.
Re[3]: Ориентируетесь на людей, к-ые это будут читать
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Gurney, Вы писали:
G>>Прежде всего вам нужно понять, для чего вы прецеденты пишете? Если вам нужна полная спецификация системы для оценки и передачи в разработку, то вам нужно писать все прецеденты, доменную модель, UI, тест кейсы, не функциональные требования и кучу пояснительного текста. Если вы это для себя решили документировать, то думаю принципиальных use-case-ов вам хватит. G>>Соответственно выбирайте уровень детализации.
А>Делаю я это, для того чтобы хоть раз в жизни спроектировать систему нормально, как в учебнике Элементы проектирования присутствовали и раньше, но теперь я взялся сделать всё по уму. Т.е. Выявить требования -> Выявить прецеденты -> Провести анализ -> Спроектировать -> Реализовать -> Тестировать. Естественно не водопадом, а как в UP принято. А>Соответственно для чего я это делаю? Я это делаю для того, чтобы на ранних этапах выявить требования — скрытую от моего пристального функциональность системы.
Кстати, а каким Вы пользуетесь средством для описания прецедентов Пробовал использовать карточки, но если что то нужно переделать или дополнить, то часто карточку приходится переписывать целиком, не спасает даже карандаш и ластик Поэтому очень медленно получается. Попробовал использовать Word. Скорость явно возрастала, но становиться неудобно просматривать прецеденты когда их много, даже если писать каждый прецедент в отдельном файле и переключаться между ними через панель задач Да и рисовать диаграммы прецедентов в чём-то надо. В общем поделитесь опытом...
:)
Re[2]: Ориентируетесь на людей, к-ые это будут читать
G>Что касается того, как разбивать на куски, ориентируйтесь на сложность восприятия. Use-case-ы обычно пишут, чтобы задокументировать ожидаемое поведений системы и акторов. ЭТУ ДОКУМЕНТАЦИЮ БУДУТ ЧИТАТЬ ЛЮДИ. Поэтому главное, чтобы она была точной и легко воспринимаемой. Создание отдельной сущности "ввод пароля" улучшит читаемость?
Мне очень понравилось как советует писать Джоел Сполски. Писать с юмором, чтобы читалось легко и мозг не взрывался от технического сухого языка. Стал сам так писать — понимание в команде существенно выросло
Здравствуйте, Cynic, Вы писали:
C>Описал три прецедента: Запуск системы, Создание первой учётной записи и Выбор учётной записи из списка:
Достаточно и одного. Хотя, зависит от ...
Основной поток должен явно показывать обычное (наиболее ожидаемое, частое) взаимодействие актера и системы. Альтернативные потоки расширяют основной поток в некоторых точках.
Основной поток
1. Система предлагает выбрать учетную запись
2. Пользователь выбирает учетную запись
3. Система запрашивает пароль учетной записи
4. Пользователь вводит пароль
5. Система начинает работу с выбранной учетной записью
Альтернативные потоки
1а. В системе отсутствуют сведения об учетных записях
1. Система уведомляет об отсутствии учетных записей
2. Система запрашивает данные новой учетной записи
3. Пользователь вводит данные новой учетной записи
4. Система сообщает пользователю, что регистрация прошла успешно
5. Система начинает работу с новой учетной записью (см.п.5)
4а. Пользователь ввел неверный пароль
1. Система уведомляет пользователя, что пароль неверен
2. Система предлагает ввести пароль заново (см.п.4)
4б. Пользователь трижды ошибся при вводе пароля
1. Система блокирует доступ и уведомляет об этом пользователя
4в. Пользователь отказался от ввода пароля
1. Повторяется процедура выбора учетной записи (см.п.1)
C>Первый вопрос в том, что например в прецеденте Выбор учётной записи из списка можно выделить прецедент Ввод пароля и разбить прецедент Выбор учётной записи из списка на два. Также можно в прецеденте Создание первой учётной записи выделить прецедент Установка пароля для новой учётной записи и описать все нюансы этого процесса, такие как проверка соответствию определённым параметрам, типа длинны пароля или его "стойкости". В общем существует множество вариантов описать данный процесс в прецедентах. Можно выделить как три прецедента, но ни что не мешает выделить и пять. Так на чём стоит остановиться
Все индивидуально. Но, как уже сказали выше, всегда надо думать о целях пользователя. Каждый прецедент — некое полезное действие для пользователя, приносящее конкретный результат. В данном случае — важен не "ввод пароля" и "выбор учетной записи", а важен процесс "аутентификации пользователя". Вот его и надо описывать.
Нарисуй диаграмму вариантов использования и на фоне крупных вариантов использования мелкие автоматически отсеются.
C>Ещё вопрос: Стоит ли упиваться описанием прецедентов или рассматривать это процесс как вспомогательное средство и описывать только самые важные аспекты функционирования системы
НЕ надо стремиться все очень подробно описывать (и по форме, и по содержанию). Нужно начинать с самых важных прецедентов — как с точки зрения бизнса, так и с точки зрения архитектуры. Их описывать более подробно, а менее важное — менее подробно.
Здравствуйте, Cynic, Вы писали:
C>Кстати, а каким Вы пользуетесь средством для описания прецедентов Пробовал использовать карточки, но если что то нужно переделать или дополнить, то часто карточку приходится переписывать целиком, не спасает даже карандаш и ластик Поэтому очень медленно получается. Попробовал использовать Word. Скорость явно возрастала, но становиться неудобно просматривать прецеденты когда их много, даже если писать каждый прецедент в отдельном файле и переключаться между ними через панель задач Да и рисовать диаграммы прецедентов в чём-то надо. В общем поделитесь опытом...
Здравствуйте, Gurney, Вы писали:
G>Word + Table of Contents, либо Word + Requisite
Угу. Но есть пара вопросов.
1) Когда вы говорите "Table of Contents" вы имеете в виду некий специальный софт или Содержание документа которое можно склепать в Word'e
2) Requisite-то вроде по сбору требований специализируется. Там, что есть специальный инструментарий для написания прецедентов и прослеживания связанных с ними требований
Здравствуйте, Cynic, Вы писали:
C>1) Когда вы говорите "Table of Contents" вы имеете в виду некий специальный софт или Содержание документа которое можно склепать в Word'e
В Word: использовать стили заголовков, затем работать со схемой документа (меню — вид — схема документа)
Думаю, что Gurney говорит об этом.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Cynic, Вы писали:
C>>1) Когда вы говорите "Table of Contents" вы имеете в виду некий специальный софт или Содержание документа которое можно склепать в Word'e
Б>В Word: использовать стили заголовков, затем работать со схемой документа (меню — вид — схема документа) Б>Думаю, что Gurney говорит об этом.
А специального софта для моделирования прецедентов нету что ли Нужно чтобы описание прецедента связывалось с требованиями которые он затрагивает, сами прецеденты можно было выносить на диаграмму прецедентов (типа как на доске таблички с описанием вывешивают и чертят мелом связи между ними), поддерживались всякие операции, типа обобщения прецедентов и актёров, отношения include/extend, точки расширения в прецедентах и т.п.
Читая Лармана пришел к выводу, что часто путается описание прецендента и описание процедуры. То что описал автор темы — это скорее описание процедур. Для бизнес-логики запуск системы и добавление учетных записей не так важны (скорее всего). А прецендент должен описывать полную операцию в системе, с помощью которой пользователь получает конкретный результат с ТЗ бизнес-логики. В прецендент описывает полное действие, не вдаваясь в детали.
ИЗ ПО хорошо подходят wiki с каким-нибудь шаблоном прецендента/операции.
Здравствуйте, Cynic, Вы писали:
C>А специального софта для моделирования прецедентов нету что ли Нужно чтобы описание прецедента связывалось с требованиями которые он затрагивает, сами прецеденты можно было выносить на диаграмму прецедентов (типа как на доске таблички с описанием вывешивают и чертят мелом связи между ними), поддерживались всякие операции, типа обобщения прецедентов и актёров, отношения include/extend, точки расширения в прецедентах и т.п.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Cynic, Вы писали:
C>>А специального софта для моделирования прецедентов нету что ли Нужно чтобы описание прецедента связывалось с требованиями которые он затрагивает, сами прецеденты можно было выносить на диаграмму прецедентов (типа как на доске таблички с описанием вывешивают и чертят мелом связи между ними), поддерживались всякие операции, типа обобщения прецедентов и актёров, отношения include/extend, точки расширения в прецедентах и т.п.
Б>Как вариант — Enterprise Architect Б>http://www.sparxsystems.com.au/
Да это серьёзный софт. Жалко только, что пока в нём разберёшься зима уже закончится
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Cynic, Вы писали:
C>>Да это серьёзный софт. Жалко только, что пока в нём разберёшься зима уже закончится
Б>В чем сложность? Б>В своей основе это UML-редактор, хотя и сильно продвинутый.
Да просто пока с ним разберёшься все сроки выйдут. Не встречали кстати, где нибудь книги какой нибудь по Architect'у или примеров использования. Так просто долго рыть
Здравствуйте, Cynic, Вы писали:
C>Здравствуйте, Буравчик, Вы писали:
Б>>Здравствуйте, Cynic, Вы писали:
C>>>Да это серьёзный софт. Жалко только, что пока в нём разберёшься зима уже закончится
Б>>В чем сложность? Б>>В своей основе это UML-редактор, хотя и сильно продвинутый.
C>Да просто пока с ним разберёшься все сроки выйдут. Не встречали кстати, где нибудь книги какой нибудь по Architect'у или примеров использования. Так просто долго рыть
На сайте самого архитектора лежат довольно не плохие туториалы. Да и интерфейс у него вполне интуитивный.
Смотря для чего вы создаете прецеденты. У нас, например, прецедентам прямая дорога в беклог, и без них не обходимся. Т.е. то, что не описано прецедентами, не будет реализовано в системе (естественно, речь не идет о нефункциональных требованиях).
Насколько надо дробить прецедент на <<include>>, <<extend>> — решение аналитика в каждом конкретном случае. Может показаться, что, например, вход в систему примитив и отдельно описывать не надо. Но вот я недавно писал аналогичный прецедент для системы голосования, так на прецедент вешла довольно таки много всего, т.к. там цеплялось управление сессиями, возврат к выбору компонента и т.д.
Плюс, я бы не в вставлял в основной поток прецедента ветвление, для этого обычно использую раздел для альтернативных потоков и исключений. Так же рисую диаграмму активности для прецедента — основной поток вертикально сверху вниз, все альтернативы и исключения -ветки вбок, тогда ясно читается основной поток.
Элементы проектирования присутствовали и раньше, но теперь я взялся сделать всё по уму. Т.е. Выявить требования -> Выявить прецеденты -> Провести анализ -> Спроектировать -> Реализовать -> Тестировать. Естественно не водопадом, а как в UP принято.
Автор(ы): Алистер Коберн
