Акторы и варианты использования
Результатом выявления требований, см. лекцию 6 является реестр требований. Требования совладельцев обычно оформляются в простой письменной форме, без какой-либо особой регламентации. Типовой пример оформления требования к программе электронной почты - "Система должна позволять набирать текст сообщения с возможностью форматирования текста и вставки смайликов". Данные требования далеко не во всем могут удовлетворять критериям, сформулированным в лекции 3: они могут противоречить друг другу, быть неясными, неточными и т.д. Тем не менее, документ "Требования совладельцев", несмотря на невысокий уровень формализации, играет очень важную роль: в нем собраны мнения всех заинтересованных сторон и главная цель сбора начальных требований заключалась в том, чтобы получить по возможности как можно более полный набор требований, не пропустив чего-то важного.
Для того, чтобы повысить уровень информативности требований, устранить взаимные противоречия и добиться выполнения их других основных характеристик, осуществляется переход от полностью неформализованных текстов к частично регламентированным (например, шаблонам MS Word) текстам, классификация, присвоение наборов атрибутов, построение моделей, прототипирование.
Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования (Use case), предложенный И.Якобсоном (см., например, [8.1]).
Прежде, чем приступить собственно к специфицированию требований в форме вариантов использования, RUP рекомендует выявить реестр акторов В различных русскоязычных текстах автору приходилось видеть следующие переводы термина "actor": актор, актер, актант, агент, субъект, пользователь. Так как все они либо неблагозвучны, либо неточны, за неимением лучшего далее по тексту будем пользоваться переводом, наиболее близким к транскрипции. (actors) и вариантов использования.
Актор - это некто или нечто, обладающее активностью по отношению к программной системе. Если вы разрабатываете простой текстовый редактор, то, скорее всего, выбор актора не составит особого труда: это будет пользователь, набирающий текст. Однако не всегда все так просто. Помимо пользователя в качестве актора может рассматриваться другая программная система, аппаратное устройство, в ряде случаев - активная компонента самой системы. Поиск акторов корпоративной информационной системы обычно сводится к анализу ролей различных пользователей. Менеджер по продажам, старший менеджер и начальник отдела продаж - один актор, два или три? Это зависит от их функциональных обязанностей, разграничения доступа, способов использования информационной системы. Поиск акторов может осуществляться, например методом мозгового штурма. В дальнейшем при необходимости найденные акторы могут обобщаться, пересматриваться и объединяться.
Вариант использования в первом приближении можно рассматривать, просто, как функцию, реализуемую системой. Однако, современный взгляд на организацию бизнеса говорит о том, что всякая функция должна иметь ценность для конечного потребителя продукта или услуги. Философия варианта использования предполагает выделение среди всего функционала системы подмножества, полезного конкретному конечному пользователю (точнее говоря, типу конечного пользователя). Другая сторона - вариант использования должен не только быть полезен, а еще и позволять получать КП конкретные законченные результаты. Так, одной из функций текстового редактора, очевидно, является создание пустого файла. Но вряд ли КП будет использовать редактор с целью изготовления пустых файлов. Следовательно, создание пустого файла - функция, но не вариант использования системы. Вариантом использования может быть, например, подготовка в текстовом редакторе служебной записки. Вариант использования реализуется через функции системы.
Глоссарий
Помимо формирования требований совладельцев другим результатом начальной фазы выявления требований является концептуальный анализ проблемной области. Самым первым результатом его является формирование глоссария (словаря) основных используемых терминов. Значение глоссария трудно переоценить: он является основой, ключом для единообразного понимания описаний требований Заказчиком и Разработчиком.
Кроме того, глоссарий является отправной точкой для построения более развернутых моделей проблемной области, которые, на стадии реализации информационной системы, ложатся в основу объектной модели (для объектно-ориентированных приложений) и модели данных (для генерации схемы базы данных).
Глоссарий оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем. Иногда проблемную область целесообразно сегментировать на ряд "подобластей" (subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.
Спецификация варианта использования
Существуют различные шаблоны описания вариантов использования. Так, в монографии [8.2] рассматриваются следующие основные стили описания:
Свободный формат,
Полный формат (предложенный А. Коберном),
Таблица в две колонки,
Таблица в три колонки,
Стиль RUP.
Кроме того, иногда целесообразно использовать:
Псевдокод,
Диаграмму активности UML (см. лекцию 9),
Другие графические модели.
Свободный формат
Свободный формат предполагает описание действий пользователя и системы в повествовательном стиле, например: "Менеджер запрашивает у Системы список заказов за период. Система отображает на экране найденные заказы данного Менеджера с указанием их основных атрибутов". Свободный стиль допускает использование конструкций "Если то". "Если Менеджер имеет полномочия Начальника Отдела, то Система предоставляет возможность просмотра заказов всех менеджеров этого отдела".
Шаблон полного описания варианта использования по А. Коберну
Название <краткая фраза в виде глагола в неопределенной форме совершенного вида, отражающая цель>
Контекст использования <уточнение цели, при необходимости - условия ее нормального завершения>.
Область действия <ссылка на рамки проекта>. Например - подсистема бухгалтерского учета.
Уровень <один из трех: обобщенный, цели пользователя, подфункции>. Автор задает предопределенную трехуровневую классификацию требований, в целом соответствующую классификации требований на бизнес-требования, требования пользователей и функциональные требования, см. лекцию 2.
Основное действующее лицо <имя роли основного актора или его описание>.
Участники и интересы <список других акторов-участников прецедента с указанием их интересов>.
Предусловие <то, что ожидается, уже имеет место>.
Минимальные гарантии <что гарантируется акторам-участникам>. Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются неизменными.
Гарантии успеха <что получат акторы-участники в случае успешного достижения цели>.
Триггер <то, что "запускает" вариант использования, обычно - событие во времени>.
Основной сценарий <здесь перечисляются шаги основного сценария, начиная от триггера и вплоть до достижения гарантии успеха>.
Формат описания: <Номер шага> <Описание действия>
Расширения <здесь последовательно описываются все альтернативные сценарии>. Каждая из альтернатив привязана к шагу основного сценария.
Формат описания: <Номер шага.Номер расширения> <Условие>:<Действие или ссылка на подчиненный вариант использования>.
Любой из шагов основного сценария может иметь 1 или более ветвлений. Каждое ветвление оформляется в виде расширения. В блоке "Расширения" все расширения описываются последовательно.
В случае, если альтернативный сценарий не удается описать одной строкой - применяется следующий формат.
Начиная со строки, следующей после описания расширения, идет описание его действий в формате основного сценария:
<Номер шага.Номер расширения.Номер шага расширения> <Действие>
Описание расширения заканчивается описанием выхода из расширения. Основные варианты выхода из расширения: возврат к очередному по номеру шагу основного сценария, окончание прецедента, переход к другому шагу основного сценария.
Список изменений в технологии и данных <что гарантируется акторам-участникам>. Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются неизменными.
Вспомогательная информация <дополнительная информация, полезная при описании варианта использования>.
Табличные представления варианта использования
Иногда представляется удобным помещать сценарии вариантов использования в таблицу, как это показано ниже. Информация при этом принимает более структурированный вид.
Таблица в 2 колонки:
| Актор |
Действие |
|---|
| Пользователь |
Формирует запрос на поиск заказов |
| Система |
Отображает список заказов |
| Пользователь |
Выбирает требуемый заказ |
| Система |
Показывает подробную информацию по заказу |
Таблица в 3 колонки:
| № шага |
Пользователь |
Система |
|---|
| 1 |
Делает запрос на поиск заказов |
Отображает список заказов |
| 2 |
Выбирает требуемый заказ |
Показывает подробную информацию по заказу |
Шаблон варианта использования RUP
С шаблоном описания варианта использования RUP и примерами можно ознакомиться в интерактивной версии RUP http://www-306.ibm.com/software/rational/ .
Ниже приведен краткий обзор его разделов.
Наименования и краткое описание. В этом разделе указывается: наименование варианта использования, акторы варианта использования, краткое (в один абзац) описание варианта использования.
Поток событий2.1. Основной поток событий
Так же, как в "Основной сценарий".
2.2. Альтернативные потоки событий
Каждый из альтернативных сценариев описывается в отдельном параграфе, в том же стиле, что и основной поток событий. Альтернативные сценарии описывают поведение системы при любых отклонениях от основного сценария, а также поведение в исключительных ситуациях.
Специальные требованияЗдесь перечисляются нефункциональные требования, имеющие непосредственное отношение именно к этому варианту использования.
ПредусловияСобытия, описываемые предусловиями или постусловиями, должны быть состояниями, которые пользователь может наблюдать [8.3]. Предусловие описывает состояние, в котором система должна находиться до начала исполнения прецедента.
ПостусловияПостусловие RUP по сути описывает то же, что и минимальная гарантия у Коберна. Л.Новиков [8.3] акцентирует внимание на том, что корректно сформулированное постусловие должно быть истинным при любом возможном сценарии прецедента, а не описанном в основном потоке.
Точки расширенияДанный параграф определяет положение точек, расширяющих поток событий.
Выбор формы описания варианта использования
При выборе формы и степени подробности варианта использования следует учитывать такие факторы, как:
Размеры проекта,
Важность проекта и варианта использования,
Традиции, сложившиеся в коллективе "Заказчик-Разработчик".
Для небольшого проекта вряд ли будет целесообразным применять описания вариантов использования в развернутом формате, достаточно использовать краткую форму свободного стиля. Для проекта, в котором задействовано более десяти участников, в котором возникают проблемы разбиения на микро-коллективы, координации участников, следует выбрать более формализованный и более подробный вариант.
Степень подробности зависит также от критичности проекта в целом и критичности варианта использования в данном проекте. А.Коберн делит все программные проекты по степени критичности на 4 категории: исходя из цены ошибок: "проекты, ошибки в которых могут привести к…":
опасности для жизни людей,
невосполнимым финансовым потерям,
финансовым потерям в ограниченном объеме,
снижению комфортности конечного пользователя.
Очевидно, что военные системы, либо системы управления сложными техническими объектами требуют более скрупулезного документирования, в том числе - и на уровне описания вариантов использования.
Кроме того, в одном и том же проекте могут встречаться более важные - с позиций частоты и массовости использования, сложности для понимания, технических рисков и т.д. и менее важные прецеденты. В этом случае для разных прецедентов одного и того же проекта вполне допустимо описание с разной степенью подробности.
Наконец, спецификация вариантов в стиле Коберна, стиле RUP, в табличной форме, с использованием псевдокодов или графических конструкций (см. материалы лекции 9) во многом определяется субъективным выбором автора прецедентов и сложившимся опытом работы с заказчиком проекта.
Спецификация нефункциональных требований
Описание нефункциональных требований обычно осуществляется в форме, близкой к свободному формату описания варианта использования. RUP рекомендует концентрировать нефункциональные требования в документе, описывающем вариант использования во всех случаях, когда это возможно. В случае, если нефункциональные требования носят общий характер и не могут быть привязаны к конкретному прецеденту - они выносятся в документ "Дополнительная спецификация".
Атрибуты требований
Описания требований должны быть операбельны. Для этого все требования должны учитываться в той или иной учетной системе, будь то электронная таблица MS Excel, специализированная база данных, либо интегрированная среда управления изменениями. При регистрации требования оно проходит классификацию в соответствии с определенной системой признаков. Основные признаки (атрибуты) требований были рассмотрены в лекции 2. Кроме того, для оперативного управления требованиями бывает полезно назначить им такие свойства, как проект, ответственное лицо, статус, риск, степень законченности и т.п. В RUP для управления атрибутами требований предусмотрен артефакт "Атрибуты требований".
Артефакт "Атрибуты требований", предлагаемый RUP, представляет собой репозиторий текстов требований, их атрибутов и трассируемости.
Атрибуты требований представлены матрицей атрибутов требований, где для каждого типа требований перечисляются требования по одной оси и атрибуты требований этого типа по другой. Для каждого требования указываются значения его соответствующих атрибутов. Примеры атрибутов: статус во времени, приоритет, важность, риск, № итерации (этапа) в плане.
Трассируемость описывается в виде дерева, показывающего в графическом виде входящие и (или) исходящие связи трассируемости (см. лекцию 13).
Акторы и варианты использования
Результатом выявления требований, см. лекцию 6 является реестр требований. Требования совладельцев обычно оформляются в простой письменной форме, без какой-либо особой регламентации. Типовой пример оформления требования к программе электронной почты - "Система должна позволять набирать текст сообщения с возможностью форматирования текста и вставки смайликов". Данные требования далеко не во всем могут удовлетворять критериям, сформулированным в лекции 3: они могут противоречить друг другу, быть неясными, неточными и т.д. Тем не менее, документ "Требования совладельцев", несмотря на невысокий уровень формализации, играет очень важную роль: в нем собраны мнения всех заинтересованных сторон и главная цель сбора начальных требований заключалась в том, чтобы получить по возможности как можно более полный набор требований, не пропустив чего-то важного.
Для того, чтобы повысить уровень информативности требований, устранить взаимные противоречия и добиться выполнения их других основных характеристик, осуществляется переход от полностью неформализованных текстов к частично регламентированным (например, шаблонам MS Word) текстам, классификация, присвоение наборов атрибутов, построение моделей, прототипирование.
Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования (Use case), предложенный И.Якобсоном (см., например, [8.1]).
Прежде, чем приступить собственно к специфицированию требований в форме вариантов использования, RUP рекомендует выявить реестр акторов В различных русскоязычных текстах автору приходилось видеть следующие переводы термина "actor": актор, актер, актант, агент, субъект, пользователь. Так как все они либо неблагозвучны, либо неточны, за неимением лучшего далее по тексту будем пользоваться переводом, наиболее близким к транскрипции. (actors) и вариантов использования.
Актор - это некто или нечто, обладающее активностью по отношению к программной системе. Если вы разрабатываете простой текстовый редактор, то, скорее всего, выбор актора не составит особого труда: это будет пользователь, набирающий текст. Однако не всегда все так просто. Помимо пользователя в качестве актора может рассматриваться другая программная система, аппаратное устройство, в ряде случаев - активная компонента самой системы. Поиск акторов корпоративной информационной системы обычно сводится к анализу ролей различных пользователей. Менеджер по продажам, старший менеджер и начальник отдела продаж - один актор, два или три? Это зависит от их функциональных обязанностей, разграничения доступа, способов использования информационной системы. Поиск акторов может осуществляться, например методом мозгового штурма. В дальнейшем при необходимости найденные акторы могут обобщаться, пересматриваться и объединяться.
Вариант использования в первом приближении можно рассматривать, просто, как функцию, реализуемую системой. Однако, современный взгляд на организацию бизнеса говорит о том, что всякая функция должна иметь ценность для конечного потребителя продукта или услуги. Философия варианта использования предполагает выделение среди всего функционала системы подмножества, полезного конкретному конечному пользователю (точнее говоря, типу конечного пользователя). Другая сторона - вариант использования должен не только быть полезен, а еще и позволять получать КП конкретные законченные результаты. Так, одной из функций текстового редактора, очевидно, является создание пустого файла. Но вряд ли КП будет использовать редактор с целью изготовления пустых файлов. Следовательно, создание пустого файла - функция, но не вариант использования системы. Вариантом использования может быть, например, подготовка в текстовом редакторе служебной записки. Вариант использования реализуется через функции системы.
Глоссарий
Помимо формирования требований совладельцев другим результатом начальной фазы выявления требований является концептуальный анализ проблемной области. Самым первым результатом его является формирование глоссария (словаря) основных используемых терминов. Значение глоссария трудно переоценить: он является основой, ключом для единообразного понимания описаний требований Заказчиком и Разработчиком.
Кроме того, глоссарий является отправной точкой для построения более развернутых моделей проблемной области, которые, на стадии реализации информационной системы, ложатся в основу объектной модели (для объектно-ориентированных приложений) и модели данных (для генерации схемы базы данных).
Глоссарий оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем. Иногда проблемную область целесообразно сегментировать на ряд "подобластей" (subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.
Спецификация варианта использования
Существуют различные шаблоны описания вариантов использования. Так, в монографии [8.2] рассматриваются следующие основные стили описания:
Свободный формат,
Полный формат (предложенный А. Коберном),
Таблица в две колонки,
Таблица в три колонки,
Стиль RUP.
Кроме того, иногда целесообразно использовать:
Псевдокод,
Диаграмму активности UML (см. лекцию 9),
Другие графические модели.
Свободный формат
Свободный формат предполагает описание действий пользователя и системы в повествовательном стиле, например: "Менеджер запрашивает у Системы список заказов за период. Система отображает на экране найденные заказы данного Менеджера с указанием их основных атрибутов". Свободный стиль допускает использование конструкций "Если то". "Если Менеджер имеет полномочия Начальника Отдела, то Система предоставляет возможность просмотра заказов всех менеджеров этого отдела".
Шаблон полного описания варианта использования по А. Коберну
Название <краткая фраза в виде глагола в неопределенной форме совершенного вида, отражающая цель>
Контекст использования <уточнение цели, при необходимости - условия ее нормального завершения>.
Область действия <ссылка на рамки проекта>. Например - подсистема бухгалтерского учета.
Уровень <один из трех: обобщенный, цели пользователя, подфункции>. Автор задает предопределенную трехуровневую классификацию требований, в целом соответствующую классификации требований на бизнес-требования, требования пользователей и функциональные требования, см. лекцию 2.
Основное действующее лицо <имя роли основного актора или его описание>.
Участники и интересы <список других акторов-участников прецедента с указанием их интересов>.
Предусловие <то, что ожидается, уже имеет место>.
Минимальные гарантии <что гарантируется акторам-участникам>. Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются неизменными.
Гарантии успеха <что получат акторы-участники в случае успешного достижения цели>.
Триггер <то, что "запускает" вариант использования, обычно - событие во времени>.
Основной сценарий <здесь перечисляются шаги основного сценария, начиная от триггера и вплоть до достижения гарантии успеха>.
Формат описания: <Номер шага> <Описание действия>
Расширения <здесь последовательно описываются все альтернативные сценарии>. Каждая из альтернатив привязана к шагу основного сценария.
Формат описания: <Номер шага.Номер расширения> <Условие>:<Действие или ссылка на подчиненный вариант использования>.
Любой из шагов основного сценария может иметь 1 или более ветвлений. Каждое ветвление оформляется в виде расширения. В блоке "Расширения" все расширения описываются последовательно.
В случае, если альтернативный сценарий не удается описать одной строкой - применяется следующий формат.
Начиная со строки, следующей после описания расширения, идет описание его действий в формате основного сценария:
<Номер шага.Номер расширения.Номер шага расширения> <Действие>
Описание расширения заканчивается описанием выхода из расширения. Основные варианты выхода из расширения: возврат к очередному по номеру шагу основного сценария, окончание прецедента, переход к другому шагу основного сценария.
Список изменений в технологии и данных <что гарантируется акторам-участникам>. Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются неизменными.
Вспомогательная информация <дополнительная информация, полезная при описании варианта использования>.
Табличные представления варианта использования
Иногда представляется удобным помещать сценарии вариантов использования в таблицу, как это показано ниже. Информация при этом принимает более структурированный вид.
Таблица в 2 колонки:
| Актор |
Действие |
|---|
| Пользователь |
Формирует запрос на поиск заказов |
| Система |
Отображает список заказов |
| Пользователь |
Выбирает требуемый заказ |
| Система |
Показывает подробную информацию по заказу |
Таблица в 3 колонки:
| № шага |
Пользователь |
Система |
|---|
| 1 |
Делает запрос на поиск заказов |
Отображает список заказов |
| 2 |
Выбирает требуемый заказ |
Показывает подробную информацию по заказу |
Шаблон варианта использования RUP
С шаблоном описания варианта использования RUP и примерами можно ознакомиться в интерактивной версии RUP http://www-306.ibm.com/software/rational/ .
Ниже приведен краткий обзор его разделов.
Наименования и краткое описание. В этом разделе указывается: наименование варианта использования, акторы варианта использования, краткое (в один абзац) описание варианта использования.
Поток событий2.1. Основной поток событий
Так же, как в "Основной сценарий".
2.2. Альтернативные потоки событий
Каждый из альтернативных сценариев описывается в отдельном параграфе, в том же стиле, что и основной поток событий. Альтернативные сценарии описывают поведение системы при любых отклонениях от основного сценария, а также поведение в исключительных ситуациях.
Специальные требованияЗдесь перечисляются нефункциональные требования, имеющие непосредственное отношение именно к этому варианту использования.
ПредусловияСобытия, описываемые предусловиями или постусловиями, должны быть состояниями, которые пользователь может наблюдать [8.3]. Предусловие описывает состояние, в котором система должна находиться до начала исполнения прецедента.
ПостусловияПостусловие RUP по сути описывает то же, что и минимальная гарантия у Коберна. Л.Новиков [8.3] акцентирует внимание на том, что корректно сформулированное постусловие должно быть истинным при любом возможном сценарии прецедента, а не описанном в основном потоке.
Точки расширенияДанный параграф определяет положение точек, расширяющих поток событий.
Выбор формы описания варианта использования
При выборе формы и степени подробности варианта использования следует учитывать такие факторы, как:
Размеры проекта,
Важность проекта и варианта использования,
Традиции, сложившиеся в коллективе "Заказчик-Разработчик".
Для небольшого проекта вряд ли будет целесообразным применять описания вариантов использования в развернутом формате, достаточно использовать краткую форму свободного стиля. Для проекта, в котором задействовано более десяти участников, в котором возникают проблемы разбиения на микро-коллективы, координации участников, следует выбрать более формализованный и более подробный вариант.
Степень подробности зависит также от критичности проекта в целом и критичности варианта использования в данном проекте. А.Коберн делит все программные проекты по степени критичности на 4 категории: исходя из цены ошибок: "проекты, ошибки в которых могут привести к…":
опасности для жизни людей,
невосполнимым финансовым потерям,
финансовым потерям в ограниченном объеме,
снижению комфортности конечного пользователя.
Очевидно, что военные системы, либо системы управления сложными техническими объектами требуют более скрупулезного документирования, в том числе - и на уровне описания вариантов использования.
Кроме того, в одном и том же проекте могут встречаться более важные - с позиций частоты и массовости использования, сложности для понимания, технических рисков и т.д. и менее важные прецеденты. В этом случае для разных прецедентов одного и того же проекта вполне допустимо описание с разной степенью подробности.
Наконец, спецификация вариантов в стиле Коберна, стиле RUP, в табличной форме, с использованием псевдокодов или графических конструкций (см. материалы лекции 9) во многом определяется субъективным выбором автора прецедентов и сложившимся опытом работы с заказчиком проекта.
Спецификация нефункциональных требований
Описание нефункциональных требований обычно осуществляется в форме, близкой к свободному формату описания варианта использования. RUP рекомендует концентрировать нефункциональные требования в документе, описывающем вариант использования во всех случаях, когда это возможно. В случае, если нефункциональные требования носят общий характер и не могут быть привязаны к конкретному прецеденту - они выносятся в документ "Дополнительная спецификация".
Атрибуты требований
Описания требований должны быть операбельны. Для этого все требования должны учитываться в той или иной учетной системе, будь то электронная таблица MS Excel, специализированная база данных, либо интегрированная среда управления изменениями. При регистрации требования оно проходит классификацию в соответствии с определенной системой признаков. Основные признаки (атрибуты) требований были рассмотрены в лекции 2. Кроме того, для оперативного управления требованиями бывает полезно назначить им такие свойства, как проект, ответственное лицо, статус, риск, степень законченности и т.п. В RUP для управления атрибутами требований предусмотрен артефакт "Атрибуты требований".
Артефакт "Атрибуты требований", предлагаемый RUP, представляет собой репозиторий текстов требований, их атрибутов и трассируемости.
Атрибуты требований представлены матрицей атрибутов требований, где для каждого типа требований перечисляются требования по одной оси и атрибуты требований этого типа по другой. Для каждого требования указываются значения его соответствующих атрибутов. Примеры атрибутов: статус во времени, приоритет, важность, риск, № итерации (этапа) в плане.
Трассируемость описывается в виде дерева, показывающего в графическом виде входящие и (или) исходящие связи трассируемости (см. лекцию 13).
1. Процесс спецификации требований — это переход от хаоса к порядку: от разрозненных пожеланий к структурированной системе.
2. Варианты использования являются центральным звеном этого процесса, так как они фокусируются на реальной ценности системы для пользователя.
3. Универсального шаблона описания не существует; эффективность инструмента зависит от контекста проекта. Гибкость в выборе формата — необходимое условие успешной коммуникации.
4. Качественная спецификация требований невозможна без единой терминологической базы (глоссария) и системы управления атрибутами, что позволяет делать требования не только понятными, но и контролируемыми на всем протяжении жизненного цикла разработки.
1. В чем заключается основная ценность первичных, неформальных требований совладельцев, если они часто бывают неточными и противоречивыми?
2. Чем понятие «Вариант использования» (Use Case) отличается от понятия «функция системы»? Приведите пример из лекции.
3. Кто или что может выступать в роли «Актора» при разработке корпоративной информационной системы? От чего зависит разделение разных должностей на одного или нескольких акторов?
4. Почему создание глоссария считается важнейшим этапом работы над требованиями? Какую роль он играет для заказчика и разработчика?
5. Перечислите известные вам стили и шаблоны описания вариантов использования, упомянутые в лекции.
6. Какие факторы влияют на выбор степени подробности (формата) описания конкретного варианта использования в рамках одного проекта?
7. Что описывается в разделе «Расширения» (или «Альтернативные потоки») в шаблоне варианта использования?
8. Для чего требованиям присваиваются атрибуты (статус, приоритет, риск)? Что такое трассируемость требований?
