Иллюстрированные сценарии прецедентов
Иллюстрированные сценарии прецедентов, ИСП [10.4], наряду с прототипами позволяют достичь лучшего понимания между Заказчиком и Разработчиком. Но если прототипы адресованы скорее Заказчику, нежели Разработчику, то с ИСП ситуация обстоит наоборот: они содержат дополнительные сведения, помогающие Разработчику лучше понять специфику проблемной области и, тем самым, лучше отразить ее в интерфейсе пользователя.
Основная идея ИСП - "разбавить" текст описания сценария варианта использования аспектами применимости.
Аспект применимости - информация, позволяющая расширить описание прецедента описаниями, конкретизирующими те или иные его особенности и, в конечном итоге, повысить степень комфортности пользователя.
Различают [10.4] 3 разновидности аспектов применимости: ориентиры, средние значения атрибутов и объемы объектов, средняя интенсивность использования.
Ориентиры
Ориентиры - это описание опциональных функциональных возможностей системы. Отсутствие таких возможностей не приводит к фатальной неудаче. Присутствие - улучшает применимость, снабжая полезной информацией. Ориентиры следует расценивать не как требования, а как пожелания или рекомендации.
Пример. Описание потока событий ИСП для прецедента "Оформить заказ", расширенного ориентирами (текст в квадратных скобках).
В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из клиентской базы, определяет товарные позиции из справочника и указывает их количество. Система отображает на мониторе наименование позиций, цену, сумму и количество на складе. Менеджер назначает скидку и определяет порядок оплаты. Система рассчитывает итоговую сумму. [Менеджер должен иметь возможность видеть текущее сальдо расчетов с клиентом и данные по последним десяти сделкам со статистикой по дисциплине соблюдения договорных обязательств].
|
|
|
Средние значения атрибутов и объемы объектов
Данная информация позволяет оптимальнее построить пользовательский интерфейс и оценить на ранних стадиях проекта "узкие места" в обработке данных, которые могут повлиять на производительность системы.
Так, при выборе из 2 возможностей лучше подойдет элемент управления checkbox, при выборе, ограниченном 2-3 десятками позиций - выпадающий список, при многообразии, измеряемом тысячами вариантов, потребуются дополнительные средства фильтрации и поиска.
Пример. Описание потока событий ИСП для прецедента "Оформить заказ", расширенного объемами и средними значениями объектов (текст в фигурных скобках).
В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из клиентской базы {до 10000 клиентов}, определяет товарные позиции из справочника {товары разбиты на 10 категорий, количество позиций в категории не превышает 500} и указывает их количество {до 100 позиций, средняя закупка - 8 позиций}. Система отображает на мониторе наименование позиций, цену, сумму и количество на складе. Менеджер назначает скидку и определяет порядок оплаты {на данный момент существуют 3 варианта порядка оплаты}. Система рассчитывает итоговую сумму.
|
|
|
Средняя интенсивность использования
Средняя интенсивность использования позволяет выделить сценарии "массового" использования, в которых все должно быть идеально (быстродействие, удобство пользования, минимум действий на выполнение операций). Например - интерфейс кассира в супермаркете. Другая крайность - сценарии, выполняемые от случая к случаю, не каждый день и не требующие особой оперативности (например, расчет заработной платы за месяц). Эти данные позволяют структурировать подачу информации, убрать из "главных" интерфейсов редко используемые опции и т.п.
Пример. Фрагмент описания потока событий ИСП для прецедента "Оформить заказ для нового клиента", расширенного значениями средней интенсивности использования (текст в круглых скобках).
|
|
|
В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из клиентской базы (в 95% случаев), либо вызывается интерфейс регистрации нового клиента (в 5% случаев).
Документирование требований
Чтобы требования, выявленные и описанные (см. "Выявление требований" и "Классификация и специфицирование требований" ) приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде документа. В российской практике для этого обычно используется документ "Техническое задание", ТЗ, в западной - "Software Requirements Specification", SRS (спецификация программных требований). По сути это - один и тот же документ, поэтому далее по тексту будем употреблять термин "ТЗ", рассматривая различные шаблоны его построения - как на основе российских ГОСТ, так и западных методологий и стандартов.
SRS Согласно стандарту IEEE STD 830-1998 (http://standards.ieee.org/findstds/standard/830-1998.html), SRS - это спецификация для определенного программного изделия, программы или набора программ, которые выполняют определенные функции в специфической среде. SRS может составляться одним или более представителями поставщика, одним или более представителями заказчика, или обоими. В тексте указанного выше стандарта содержатся подробные сведения о том, как составлять SRS, а также шаблон SRS. Альтернативным источником знаний об SRS может послужить методология RUP. В русскоязычной практике данному термину приблизительно соответствует термин "Техническое задание" (ТЗ). В РФ ТЗ на создание автоматизированной системы регламентируются ГОСТ 34.602-89 [38].
Дата добавления: 2021-03-18; просмотров: 178; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!