ВУЗ: Оренбургский государственный университет
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 25.10.2018
Просмотров: 2707
Скачиваний: 5
26
По окончании этапа анализа требований, многостраничный документ, со-
держащий сотни пользовательских историй, будет разбит на части. Каждая
часть будет освещать только необходимую функциональность, а в еѐ основе
будет стоять диаграмма вариантов использования, на основе которой можно
будет легко увидеть все требуемые функции системы. Описание вариантов ис-
пользования не будут дублироваться, а лишь дополнять друг друга.
Выделение пользовательских историй в отдельные пакеты
Первым этапом анализа требования является выделение пользовательских
историй в отдельные пакеты требований. Для специализированных систем
управления требованиями вроде Borland Caliber RM или Rational Request Pro, в
которых все требования хранятся в базе данных, и представлены древовидным
списком, пакетами являются элементы первого уровня, которые будут играть
роль контейнера для всех остальных требований. При использовании текстовых
документов пакетами будут являться отдельные файлы, возможно с общим ин-
дексом.
Главная цель формирования пакетов – упростить доступ к нужным дан-
ным, за счет того, что все варианты использования относящихся к определен-
ной функциональности можно будет увидеть на одной странице (оглавление
или диаграмма вариантов использования). В случае использования текстовых
документов, пакеты также существенно упростят автору процесс последующе-
го редактирования – не нужно будет блокировать весь документ на время ре-
дактирования, а пользователям документа будет легче узнать об изменениях
(как правило, для этого используется секция «История изменений» в начале
каждого документа). Для того чтобы достичь поставленной цели требуется до-
биться того, чтобы в один пакет входило 20–30 пользовательских историй.
Пакеты формируются из пользовательских историй, которые описывают
схожую деятельность или способ достижения схожего результата. Как правило,
всего они подчинены одному бизнес требованию.
27
Два подхода: Варианты использования или спецификации требований
Существует два основных метода проектирования – проектирование на
основе вариантов использования и проектирование на основе требований.
Проектирование на базе вариантов использования считается более эффек-
тивным, так как этот метод позволяет не терять связь с пользовательскими ис-
ториями и прекрасно иллюстрирует требуемое поведение системы в целом, а,
следовательно, гарантирует востребованность всего функционала, который бу-
дет создан (очень расточительно и болезненно для разработчиков писать код,
которым никогда не удастся воспользоваться). Но все, же есть условия, при ко-
торых аналитик может пренебречь этим методом в пользу проектирования на
базе требований:
• Проектирование на основе требований следует предпочесть, если
необходимо сократить затраты на стадию анализа до минимума, а количество
пользовательских историй в пакете не велико (их содержимое можно просмот-
реть не дольше чем за 10 минут).
• Команда разработки не умеет или не хочет работать с вариантами ис-
пользования и требует предоставление требований к системе в классическом
виде.
Далее описаны работы, которые нужно произвести в рамках выбранного
вами метода.
А. Варианты использования. Структурирование пользовательских исто-
рий
Как правило, у всех пользовательских историй в пакете есть одна или не-
сколько главных целей, и есть история, которая описывает наиболее простой
способ их достижения. Такая история называется – базовой, а описание еѐ дей-
ствия – базовый путь. Остальные истории описывают альтернативный способ
достижения результата или содержат дополнительные действия для достиже-
ния специфического результата и по большому счету являются дополнениями к
базовой истории.
28
Пользовательские истории это разновидность стандартных вариантов ис-
пользования, с той лишь особенностью, что они описывают взаимодействие не
с реальной, а с гипотетической системой. Это свойство пользовательских исто-
рий будет использовано в этой главе и все манипуляции в процессе структури-
рования будут производиться в соответствии с правилами и методами, разрабо-
танными для стандартных вариантов использования.
Б. Спецификация требований
Для нормальной разработки нужен список требований, который одно-
значно идентифицирует потребности пользователей и не имеет множественных
повторений, которые присутствуют с избытком в пользовательских историях
(если не произвести структурирование историй, описанное в предыдущем под-
ходе). Кроме этого, для более гибкого проектирования необходим как можно
более детализированный (раздробленный) список.
Извлечение требований из пользовательских историй
На этом этапе нужно выделить все уникальные результаты пользователь-
ских историй в отдельные требования. Если результат истории оказался уни-
кальным, то вы должны преобразовать его в требование (просто скопировать
его тело, используя повелительное наклонение). Если же похожий результат
уже был вынесен в требование в рамках другой пользовательской истории, то
надо проанализировать их возможные отличия и, если они есть – модернизиро-
вать существующее требование или создать дополнительное дочернее требова-
ние/ограничение. Приоритет требования должен быть унаследован от роди-
тельской истории с максимальным приоритетом.
Кроме результата пользовательской истории следует проанализировать ее
поток выполнения. Он может содержать уточнения/пожелания к поведению
продукта, которые не плохо было бы учесть. Пожеланиям следует назначать
приоритет ниже, чем приоритет родительской истории.
29
В результате этой работы должен быть получен древовидный список тре-
бований.
Типы D-требований
Существуют несколько типов требований.
1.
Функциональные требования:
• функциональность приложения.
2.
Нефункциональные требования.
1)
Производительность:
• скорость;
• пропускная способность (трафик);
• использование памяти (оперативная память, жесткий диск).
2) Надежность и доступность.
3) Обработка ошибок.
4) Интерфейсные требования.
Как программа взаимодействует с пользователем и с другими програм-
мами.
5) Ограничения:
• точность;
• ограничения на инструменты и язык, например «должен использо-
ваться С#»;
• ограничения проектирования;
• стандарты, которые должны быть использованы;
• платформы, которые должны быть использованы.
3.
Обратные требования.
Чего программа не делает.
30
Диаграммы последовательности
Диаграммы последовательности являются графическим представлением
передачи управления и особенно полезны для визуализации реализации вари-
антов использования.
Диаграммы последовательности заставляют нас рассуждать в терминах
объектов. В такой диаграмме жизненный цикл каждого участвующего объекта
показан вертикальной линией с именем объекта и указанием его класса вверху.
Каждое взаимодействие между объектами отображается горизонтальной стрел-
кой от объекта, инициирующего взаимодействие, к объекту, выполняющему
дальнейшие функции.
Способы организации детальных требований
D-требования можно организовать с помощью нескольких схем:
• по основным свойствам (предоставляемый вовне сервис, обычно опре-
деляется с помощью пар стимул-реакция). Этот способ организации часто вос-
принимают как «требования», имея в виду, что требования сгруппированы по
различным свойствам программы. Это не предоставляет никакой систематиче-
ской организации, поскольку позволяет переходить от свойства одной части
программы к свойству абсолютно другой части программы;
• по режиму (например, системы управления радарами могут иметь тре-
нировочный, нормальный и аварийный режимы);
• по вариантам использования (иногда еще называется по сценариям).
Идея заключается в том, что большинство детальных требований являются ча-
стью варианта использования;
• по классу. Это объектно-ориентированный стиль, в этом способе орга-
низации мы классифицируем требования по классам;
• по иерархии функций (то есть путем разбиения программы на множе-
ство высокоуровневых функций и последующего разбиения их на подфункции
и т. д.) Например, требования для программы домашнего бюджета можно раз-
бить на (1) функции проверки, (2) функции сбережений и (3) функции инвести-