– Цель в контексте
– Область действия
– Уровень
– Предусловия
– Условие успешного завершения
– Условие неудачного завершения
– Первичный действующий субъект
– Условие начала действия
B. ОСНОВНОЙ СЦЕНАРИЙ ПРИ УСПЕШНОМ ЗАВЕРШЕНИИ
C. РАСШИРЕНИЯ
D. ВАРИАНТЫ
E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
– Приоритет
– Рабочая характеристика
– Частота
– Превосходящий прецедент использования
– Подчиненный прецедент использования
– Канал связи с первичным действующим субъектом
– Вторичные действующие субъекты
– Канал связи со вторичными действующими субъектами
F. РАСПИСАНИЕ
G. ОТКРЫТЫЕ ПРОБЛЕМЫ
Используя формальный шаблон в качестве шпаргалки, вы можете быть уверены в том, что включили всю необходимую информацию в сценарий использования системы: характеристики производительности, другие стороны-участники, приоритет, частоту использования и разнообразные ошибки и исключения, которые могут появляться неожиданно ("нефункциональные требования"). Шаблон удобен для записи комментариев пользователей, наподобие "если мы получим условие ххх, тогда нам придется сделать ууу". Шаблон может послужить в качестве готовой повестки дня при встрече с пользователями ваших программ.
Рис. 7.2. Пример сценария использования системы
ПРЕЦЕДЕНТ ИСПОЛЬЗОВАНИЯ № 5: ПРИОБРЕТЕНИЕ ТОВАРА
A. ХАРАКТЕРНАЯ ИНФОРМАЦИЯ
• Цель в контексте: Покупатель напрямую направляет коммерческий запрос в нашу фирму и ожидает отгрузки товаров и выставления счета за указанные товары.
• Область действия: Фирма
• Уровень: Итоговая информация
• Предусловия: Нам известен покупатель, его адрес, и т. д.
• Условие успешного завершения: Покупатель получает товары, мы получаем оплату.
• Условие неуспешного завершения: Мы не производим отгрузку товаров, покупатель не производит оплату.
• Первичный действующий субъект: Покупатель, любой агент (или компьютер), действующий от имени заказчика
• Условие начала действия: Получение запроса на приобретение товара.
B. ОСНОВНОЙ СЦЕНАРИЙ С УСПЕШНЫМ ЗАВЕРШЕНИЕМ
1. Покупатель обращается в фирму с запросом на приобретение товара.
2. Фирма фиксирует имя покупателя. его адрес, требуемые товары. и т. д.
3. Фирма предоставляет покупателю информацию о товарах, ценах, сроках поставки, и т. д.
4. Покупатель подтверждает заказ.
5. Фирма компонует заказ, отправляет заказ покупателю.
6. Фирма высылает покупателю счет-фактуру.
7. Покупатель оплачивает счет-фактуру.
C. РАСШИРЕНИЯ
3а. Один из пунктов заказа отсутствует у данной фирмы: Заказ переоформляется.
4а. Покупатель производит оплату непосредственно кредитной картой: Прием оплаты кредитной картой (прецедент использования № 44).
7а. Покупатель возвращает товар: Оформление возвращенного товара (прецедент использования № 105).
D. ВАРИАНТЫ
1. Покупатель может осуществить заказ по телефону, факсу, при помощи Интернет-формы (на странице), по другим сетям электронного обмена информацией.
7. Покупатель может оплатить заказ наличными денежным переводом, чеком, или кредитной картой.
E. СОПУТСТВУЮЩАЯ ИНФОРМАЦИЯ
• Приоритет: Высший
• Производительность: 5 минут на оформление заказа, оплата в течение 45 дней
• Частота: 200 заказов в день
• Превосходящий прецедент использования: Управление взаимоотношением с заказчиком (прецедент использования № 2).
• Подчиненные прецеденты использования: Компоновка заказа (прецедент использования № 15)
• Прием оплаты кредитной картой (прецедент использования № 44). Возврат товара покупателем (прецедент использования № 105).
• Канал общения с первичным действующим субъектом: по телефону, факсу или компьютерной сети.
• Вторичные действующие субъекты: компания – оператор платежной системы, банк, экспедиторская фирма.
F. РАСПИСАНИЕ
• Должная дата: Выпуск 1.0
G. ПРОБЛЕМЫ, ЯВЛЯЮЩИЕСЯ ОТКРЫТЫМИ
• Что происходит, если имеется лишь часть заказа?
• Что происходит, если кредитная карта похищена?
Подобного рода организация поддерживает иерархическое структурирование сценариев использования системы – вложение более подробных сценариев в сценарии более высокого уровня. Например, сценарии post debit и post credit дополняют друг друга в сценарии post transaction.
Последовательность операций может быть зафиксирована при помощи диаграмм на языке UML, а схемы концептуального представления иногда могут быть полезны для оперативного моделирования бизнес-процессов. На самом деле сценарии использования представляют собой текстовые описания с иерархией и перекрестными ссылками. Сценарии использования могут содержать гиперссылки на другие сценарии и могут вкладываться друг в друга.
Рис. 7.3. Сценарии использования, выраженные UML, понятны даже ребенку!
Кажется невероятным, что кто-нибудь может всерьез воспринимать документирование информации, используя примитивные символы, подобные изображенным на рисунке 7.3. Не будьте рабом системы обозначений: используйте любой метод общения, с помощью которого можно обмениваться требованиями с вашей аудиторией.
Чрезмерная спецификация
При генерации документов, содержащих требования, возникает серьезная опасность чрезмерной спецификации. Хорошие документы остаются абстрактными. Там, где думают о требованиях, простейшая формулировка, точно отражающая суть потребности, является наилучшей. Это не означает, что вы можете допустить неопределенность, нужно зафиксировать основополагающие семантические инварианты в качестве требований и задокументировать конкретную или же существующую на данный момент практику в качестве политики.
Требования не являются архитектурой. Требования – это не конструкция, и не пользовательский интерфейс. Это потребность.
Видеть перспективу
Вина за возникновение "проблемы 2000 года" часто возлагается на близоруких программистов, пытавшихся сэкономить несколько байтов в те дни, когда объем памяти мэйнфреймов был меньше, чем у современных пультов дистанционного управления телевизорами.
Но это не зависело от программистов и не являлось вопросом использования памяти. Если уж быть честным до конца, вина за это лежит на системных аналитиках и проектировщиках. "Проблема 2000 года" возникла по двум основным причинам: нежелание выйти за пределы существующей бизнес-практики и нарушение принципа DRY.
Двухразрядное обозначение года использовалось в деловой практике задолго до появления компьютеров. Это было обычной практикой. В то время приложения, предназначенные для обработки данных, в основном занимались автоматизацией существующих бизнес-процессов и просто повторили ошибку. Даже в том случае, когда архитектура требовала двухразрядного обозначения при вводе данных, создании отчетов и хранении данных, должна была бы появиться абстракция DATE, которая «знала» о том, что две цифры представляли собой усеченную форму реальной календарной даты.
Подсказка 53: Абстракции живут дольше, чем подробности
Требует ли от вас фраза "Видеть перспективу", чтобы вы занялись предсказанием будущего? Нет. Это означает создание формулировок типа: