Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка требований к программному продукту. Учебное пособие
.pdf
Приложение 4
ПРИМЕР ДИАГРАММЫ ПОТОКА ДАННЫХ
Нулевой уровень диаграммы потоков данных для системы заказов
химикатов показан на схеме [1, с. 269].
Первоначально представленная модель кажется сложной, несмотря
на краткость описания процессов этой системы (см. приложение 2). Рекомендуется выделить любой элемент, представляющий собой процесс
или хранилище данных, и проанализировать входящие и исходящие
стрелки. Тогда станет понятно, что на диаграмме
для любого процесса
показаны данные, с которыми процесс работает, а также источники возникновения данных и точки их назначения.
Для более глубокого понимания процессов переработки данных
нужно разработать модели потоков данных нижнего уровня или указать
функциональные требования для соответствующей части системы.
61
Приложение 5
ПРИМЕР ЧАСТИЧНОЙ ДИАГРАММЫ SWIMLANE
На схеме представлена частичная диаграмма swimlane системы заказов химикатов [1, с. 273].
Дорожки соответствуют ролям (химик, специалист по заказам)
и подразделениям (приемное отделение, поставщик), таким образом показаны выполняемые каждым участником (ролью или подразделением)
действия (шаги) в процессе заказа химиката у поставщика.
Естественно начать определение функциональных требований с прямоугольника «Создание заказа
химиката». Нужно определить функциональность исследуемой системы для выполнения этого шага и требования
к данным для «Заказа химиката».
62
При анализе шага «Проверка и одобрение счета» выявляется необходимость формулирования соответствующего требования. Для этого
нужно уточнить формат счета, источник его создания и выдачи, список
автоматизируемых действий при работе со счетом и необходимость передачи сведений в другие системы.
Возможны ситуации, когда диаграмма swimlane показывает элементы, с которыми система взаимодействует
косвенно, поэтому в мо-
дели потоков данных таких элементов нет.
63
Приложение 6
ПРИМЕР ДИАГРАММЫ ПЕРЕХОДОВ
Ниже представлена диаграмма переходов для системы заказа химикатов [1, с. 275].
Анализируя диаграмму переходов состояний исследуемой системы,
пользователи как специалисты в предметной области могут определить
ненужные и отсутствующие состояния, а также неправильные переходы. В этом и заключается ценность представления информации о требованиях с помощью различных моделей анализа.
Далее показана
таблица состояний, соответствующая приведенной
выше диаграмме переходов состояний [1, с. 277].
64
Оба изображения содержат одну и ту же информацию, но табличный
формат помогает не пропустить никаких переходов, а формат диаграммы помогает заинтересованным лицам наглядно увидеть возможные последовательности переходов.
В моделях состояний не показаны детали обработки, выполняемой
системой, а приведены только возможные изменения состояний, возникающие в результате этих процессов
. Они помогают разработчику по-
нять ожидаемое поведение системы.
65
Приложение 7
ПРИМЕР КАРТЫ ДИАЛОГОВЫХ ОКОН
Для проверки качества пользовательского интерфейса нужно сравнить готовые варианты использования и потоки процессов с картами
диалоговых окон. Это дает возможность определить доступность нужных функций через интерфейс пользователя для выполнения требуемой
последовательности шагов.
В проекте заказа химикатов стандартным вариантом использования
является заказ химиката со склада, а альтернативным вариантом – заказ
у
поставщика. Дополнительно пользователю нужно иметь доступ к исто-
рии контейнеров со склада для выбора контейнера с нужным химикатом.
На схеме ниже показана карта диалоговых окон для этого варианта
использования [1, с. 280].
66
Входной точкой карты диалоговых окон является линия перехода,
начинающаяся с черного кружка. Пользователь будет попадать в эту
часть пользовательского интерфейса приложения из другой части интерфейса. Точки выхода из карты диалоговых окон для возвращения
в другую часть пользовательского интерфейса представляют собой линии перехода, входящие в кружок с точкой внутри
и без исходящих ли-
ний перехода.
Чтобы разобраться в карте диалоговых окон, рекомендуется каждый
раз анализировать только один объект – один прямоугольник и одну линию. После усвоения информации следует переходить к анализу другого объекта.
Пользователь попадает в эту часть пользовательского интерфейса по
стрелке перехода «Запросить размещение заказа». Он получает доступ
к «Списку текущих заказов» (соответствующий прямоугольник).
Функциональность, доступная пользователю в этом месте интерфейса, определяют исходящие из диалогового окна (прямоугольника)
«Список текущих заказов» стрелки (смотреть надписи на стрелках перехода):
отменить весь заказ;
разместить заказ на ненулевое количество химикатов;
заказать еще один химикат;
удалить химикат из
списка.
Последняя линия перехода «Удалить химикат из списка» вновь возвращается в то же окно диалога, из которого вышла. В этом случае из
списка заказов удаляется выбранный заказ, но пользователь по-прежнему имеет доступ только к обновленному списку заказов, т. е. активное
окно диалога сохраняется.
В ходе анализа этой
карты диалоговых окон можно проследить все
способы (пути) выполнения заказа химикатов пользователем:
способ 1 – заказ химиката у поставщика;
способ 2 – заказ химиката со склада;
способ 3 – заказ химиката со склада с дополнительным просмот-
ром истории операций с контейнером;
способ 4 – заказ химиката со склада или у поставщика с выводом
сообщения об
ошибке, например при неверном введении названия хи-
миката или другой информации.
67
Приложение 8
ПРИМЕР ТАБЛИЦЫ РЕШЕНИЙ И ДЕРЕВА РЕШЕНИЙ
На принятие решения влияют четыре условия:
1) имеет право пользователь заказывать химикаты или нет;
2) есть или нет заказываемый химикат в наличии на складе либо
у поставщика;
3) есть или нет специальная подготовка у пользователя для работы
с опасными химикатами;
4) включен или нет запрашиваемый химикат в список опасных хи-
микатов
.
Ниже представлена таблица решений для выбора действий во всех
возможных ситуациях [1, с. 282].
На схеме представлено дерево решений как еще одна модель анализа
для ситуаций со сложной логикой [1, с. 283].
Таблицы решений и деревья решений обеспечивают полноту выявления всех возможных комбинаций условий для выбора действий продуктом. Они более просты
для анализа, чем текстовый формат требований.
68
Приложение 9
ОЦЕНКА КАЧЕСТВА ТРЕБОВАНИЙ К РАЗРАБАТЫВАЕМОЙ
ИНФОРМАЦИОННОЙ СИСТЕМЕ
Анкета для оценки качества разработанного набора требований
в техническом задании
Оцените степень выраженности характеристик качества отдельных
требований и набора требований в целом в баллах от 0 до 6 (0 – качество
отсутствует, 6 – качество проявлено в полной мере).
№
п/п
1
Исключены в формулировках
требований следующие слова:
эффективный; быстрый; скорый; гибкий; универсальный;
улучшенный; лучший; более
качественный; превосходный;
включает в себя, но не ограничен этим; в большинстве случаев; как правило; в частности;
соответствует, согласуется;
равняется; максимизировать;
оптимизировать; минимизировать; обычно; в идеальном варианте; не обязательно; возможно; желательно;
разумно; по возможности; при
необходимости; устойчивый
к сбоям; цельный; корректный;
несколько; множественный;
много; немного; современный;
достаточный; позволяет; дружественный; простой; легкий
2
Выполнена декомпозиция высокоуровневых требований на
простые
Характеристики Риск Отметка
Оценка качества по отдельным требованиям
должно;
Двусмысленность требования. Нужно заменить приведенные и им подобные
слова на формулировки без
двусмысленности
Несовпадение представлений заинтересованных лиц
проекта о продукте и о том,
что создает разработчик
0123456
0123456
69
Продолжение таблицы
№
п/п
3 Сформулированы логические
парные требования
Характеристики Риск Отметка
Пропуск требования.
Например, сохранять и загружать незаконченные
файлы, т. е. оба действия
должны быть включены
в набор функциональных
требований
4 Все пограничные значения
Пропуск требования 0123456
учтены
5 Использованы различные
формы представления требований: текст, таблицы, схемы,
Пропуск требований
(связь высокоуровневых
и простых требований)
рисунки
6 Требования со сложной логи-
кой представлены в виде таблиц или деревьев требований
Пропуск требований,
например, по условию
«иначе»
7 Создана модель данных Пропуск требований. Все
сущности данных, с которыми работает информационная система, должны
иметь соответствующую
функциональность для их
создания, чтения из внешних источников, обновления текущих значений и
(или) удаления
8 Обеспечена связь с источни-
ками требований, в качестве
которых могут выступать пользователь, предоставивший
начальное требование; высокоуровневое системное требование; вариант использования;
бизнес-правило или другой документ
Риск некорректности требования, т. е. требование
неточно описывает возможность, которая будет
удовлетворять какую-то
потребность заинтересованного лица, поэтому
дует четко определять
функциональность, которую надо построить
0123456
0123456
0123456
0123456
0123456
сле-
70
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]