К программному обеспечению

 

Спецификация требований к ПО является составной частью процесса управления требованиями (см. подразд. 1.5). В качестве повторения отметим, что все требования к ПО делятся на функциональные и нефункциональные. Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Нефункциональ­ные требования описывают атрибуты системы (технические ха­рактеристики) и ее окружения.

Для выявления требований используются (в различных соче­таниях) следующие методы:

· собеседование (интервьюирование);

· анкетирование;

· моделирование и анализ бизнес-процессов (далее будет рас­смотрена методика перехода от объектной бизнес-модели к системным требованиям);

· сессии по выявлению требований (мозговой штурм);

· создание и демонстрация пользователям работающих про­тотипов приложений (для выявления замечаний и дополни­тельных требований).

Собеседование — наиболее часто используемый и обычно наи­более полезный метод выявления требований. При использова­нии интервью может быть поставлено несколько целей, таких, как выяснение, проверка и толкование фактов, формирование заинтересованности, привлечение пользователей к работе, сбор предложений и мнений. Но метод собеседования требует для эф­фективного контакта хороших навыков общения с людьми, име­ющими различные ценности, приоритеты, мнения, побуждения и индивидуальные особенности. Преимущества метода собеседо­вания заключаются в следующем:

· опрашиваемое лицо может свободно и открыто отвечать на вопросы и почувствовать себя участником проекта;

· лицо, проводящее собеседование, может наблюдать за пове­дением опрашиваемого лица, изменять ход опроса, пере­формулировать или иначе строить вопросы во время собесе­дования.

Недостатки метода собеседования:

· метод трудоемкий и дорогой, поэтому может оказаться не­практичным;

· успех собеседования зависит от навыков общения лица, проводящего собеседование, и от желания опрашиваемых лиц участвовать в интервью.

Существуют два типа интервью: неструктурированное и структурированное. Неструктурированные интервью проводят с одной общей целью, которая явно не высказывается, и с по­мощью нескольких общих вопросов. Лицо, проводящее собесе­дование, рассчитывает на то, что опрашиваемое лицо должно са­мо определять рамки и направление интервью. В таких интервью часто теряется нить рассуждений, и по этой причине они редко используются при проектировании систем.

В структурированных интервью лицо, проводящее собеседо­вание, заранее подготавливает конкретный ряд вопросов к опра­шиваемому лицу. В зависимости от ответов в процессе собеседо­вания могут быть заданы дополнительные вопросы для уточне­ния или разъяснения некоторых тем. Вопросы без подразумевае­мых ответов позволяют опрашиваемому лицу выбрать ответ, на­иболее подходящий с его точки зрения. Вопросы, допускающие единственный ответ, ограничивают выбор возможного ответа или требуют коротких, прямых ответов.

Анкетирование позволяет с помощью анкет получать сведения от большого количества людей, контролируя правильность их от­ветов. При работе с большой аудиторией этот метод наиболее эф­фективен. Преимущества метода анкетирования заключаются в следующем:

· люди могут заполнять и возвращать анкеты в удобное для них время;

· люди склонны сообщать в ответах действительные факты, если анкетирование анонимное;

· это относительно недорогой способ сбора данных с участи­ем большого количества людей.

Недостатки метода анкетирования:

· не все могут согласиться ответить на вопросы, анкеты могут возвращаться незаполненными;

· нет возможности пояснить или переформулировать непра­вильно понятые вопросы, наблюдать и анализировать реак­цию респондента на отдельные вопросы;

· подготовка анкет может потребовать много времени.

Мозговой штурм особенно полезен в ситуациях, когда обсуж­даются новые, нестандартные решения незнакомой проблемы. Большинство новаторских идей очень часто бывают результатом комбинации нескольких, на первый взгляд, не связанных друг с другом идей. Мозговой штурм включает в себя генерацию идей и расстановку приоритетов. Процесс генерации идей обычно под­чиняется правилам, соблюдение которых преследует одну цель — выработку как можно большего числа идей. Критика и споры в этот период не поощряются; существующие пределы и ограниче­ния снимаются, можно изменять и комбинировать идеи.

Основная идея создания прототипа состоит в быстрой пост­ройке модели системы, которая, как предполагается, нужна пользователю. Обычно в прототипах многие детали опускаются, в том числе процедуры контроля входных данных, обработки ошибок, резервного копирования и восстановления данных. Не учитываются также производительность и масштабируемость. Создание прототипа никак не противоречит и не препятствует применению других методов получения требований от пользова­теля. Однако иногда только с помощью прототипа удается заста­вить клиента начать обсуждение требований, которые при другом подходе кажутся слишком абстрактными. Кроме того, работа с прототипом часто помогает получить требования, которые в про­тивном случае так и остались бы неизвестными. Прототип хорош еще и тем, что он является неким осязаемым доказательством (или иллюзией) прогресса в разработке системы. А в некоторых случаях он может даже поддерживать какие-то ограниченные ра­бочие возможности системы. К сожалению, как отмечалось в гла­ве 1, реальный опыт работы с прототипами свидетельствует, что их создание обычно препятствует любому официальному доку­ментированию требований, следовательно, требования формули­руются только в виде кода. Детали работы системы, игнорируе­мые прототипом (обработка ошибок, резервное копирование и др.), могут так и не появиться в виде требований.

Выявленные в результате применения перечисленных мето­дов требования к ПО оформляются в виде ряда документов и мо­делей. К основным документам, регламентируемым технологией Rational Unified Process, относятся:

· Концепция — определяет глобальные цели проекта и основ­ные особенности разрабатываемой системы. Существенной частью концепции является постановка задачи разработки, определяющая требования к выполняемым системой функ­циям.

· Словарь предметной области (глоссарий) — определяет об­щую терминологию для всех моделей и описаний требова­ний к системе. Глоссарий предназначен для описания терминологии предметной области и может быть использован как словарь данных системы.

· Дополнительные спецификации (технические требования) - содержит описание нефункциональных требований к сис­теме, таких, как надежность, удобство использования, про­изводительность, сопровождаемость и др.

Примеры документов приведены в подразд. 3.4.2.

Функциональные требования к системе моделируются и до­кументируются с помощью вариантов использования (use case), которые в контексте процесса управления требованиями тракту­ются следующим образом:

· вариант использования фиксирует соглашение между участ­никами проекта относительно поведения системы;

· вариант использования описывает поведение системы при различных условиях, когда система отвечает на запрос одно­го из участников, называемого основным действующим ли­цом;

· основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвеча­ет, соблюдая интересы всех участников.

Варианты использования — это вид документации, применя­емый, когда требуется сконцентрировать усилия на обсуждении принципиальных требований к разрабатываемой системе, а не на подробном их описании. Стиль их написания зависит от масшта­ба, количества участников и критичности проекта. Существуют четыре уровня точности[24] при описании вариантов использования (расположенные по степени повышения точности):

· Действующие лица и цели (перечисляются действующие лица и все их цели, которые будет обеспечивать система).

· Краткое изложение варианта использования (в один абзац) или основной поток событий (без анализа возможных оши­бок).

· Условия отказа (анализ мест возникновения возможных ошибок в основном потоке событий).

· Обработка отказа (написание альтернативных потоков со­бытий).

Введение перечисленных уровней преследует своей целью грамотное планирование и экономию времени разработки. В итерационном цикле создания системы не следует пытаться за один прием подробно описать все требования, их нужно посте­пенно уточнять, повышая уровень точности. Выбор первоочеред­ных вариантов использования для уточнения определяется их приоритетами (см. подразд. 1.5).

Методика моделирования вариантов использования в техно­логии Rational Unified Process предусматривает специальное сог­лашение, связанное с группировкой структурных элементов и диаграмм модели. Это соглашение включает следующие правила:

· Все действующие лица, варианты использования и диаграм­мы вариантов использования помещаются в пакет с именем Use Case Model.

· Если моделируется сложная многофункциональная систе­ма, то совокупность всех действующих лиц и вариантов ис­пользования может разделяться на пакеты. В качестве прин­ципов разделения могут использоваться:

структуризации модели в соответствии с типами пользовате­лей (действующих лиц);

функциональная декомпозиция;

разделение модели на пакеты между группами разработчиков (в качестве объектов управления конфигурацией).

Все рекомендации по написанию качественных вариантов ис­пользования, включая перечисленные в подразд. 2.5.1, можно из­ложить в виде набора образцов, которые перечислены в табл. 3.3.

Таблица 3.3

Образцы написания вариантов использования

Наименование образца	Проблема	Предлагаемое решение
Формирование команды разработчиков
Небольшая команда разработ­чиков	Участие слишком многих людей в написании вари­анта использования не­эффективно; компромисс между многими различ­ными точками зрения мо­жет привести к неудовлетворительным резуль­татам при создании сис­темы	Ограничьте число разра­ботчиков, отрабатываю­щих детали варианта ис­пользования, двумя или тремя людьми. Для под­ключения дополнитель­ных участников используйте образец Двухуров­невое рецензирование
Состав сторонних участников	Невозможно удовлетво­рить потребности всех за­интересованных лиц, не обмениваясь информаци­ей с ними	Активно привлекайте за­казчиков и заинтересо­ванных лиц в вашей орга­низации к разработке ва­риантов использования
Сбалансированная команда	Команда из близких по роду деятельности, оди­наково мыслящих людей может создать небольшой набор ограниченных ва­риантов использования, не удовлетворяющий об­щим потребностям	Формируйте команду из людей с различными спе­циализациями, представ­ляющими интересы раз­личных заинтересован­ных лиц. Команда долж­на включать как разра­ботчиков, так и пользова­телей
Организация процесса разработки
Глубина после об­щего представле­ния	Невозможно продвигать­ся вперед и создавать на­бор согласованных вари­антов использования, ес­ли тратить впустую время на последовательное на­писание подробных вари­антов использования	Разрабатывайте сначала общее представление ва­риантов использования, затем постепенно добав­ляйте детали, работая с группой взаимосвязан­ных вариантов использо­вания
Итерационная разработка	Разработка вариантов ис­пользования за один про­ход затруднительна, ус­ложняет внесение допол­нительной информации и затрудняет выявление факторов риска	Разрабатывайте варианты использования итераци­онно, повышая на каждой итерации их точность и корректность
Множество форм	Различные проекты тре­буют различную степень формальности и различные шаблоны. Использо­вать один и тот же шаб­лон вариантов использо­вания непродуктивно	Выбирайте формат вари­антов использования, ос­новываясь на проектных рисках и предпочтениях участников
Двухуровневое ре­цензирование	Многие заинтересован­ные лица могут пожелать принять участие в рецен­зировании вариантов ис­пользования. Это слиш­ком долгое и дорогостоя­щее занятие	Используйте два вида ре­цензирования: первое, проводимое небольшой группой внутренних участников, может вы­полняться многократно; второе, проводимое пол­ной группой, выполняет­ся, как правило, один раз
Своевременное завершение	Разработка модели вари­антов использования сверх потребностей заин­тересованных лиц и раз­работчиков приводит к напрасным тратам ресур­сов и затягивает проект	Прекращайте разработку вариантов использова­ния, как только они дос­тигают необходимой пол­ноты и удовлетворяют потребности участников проекта
Свобода творчества	Чрезмерное внимание к стилю написания вариан­тов использования тор­мозит работу	Небольшие различия в стиле написания вариан­тов использования несу­щественны. Если вариант использования достиг не­обходимой полноты, его автор имеет право на сти­листические отступления
Организация набора вариантов использования
Общепринятая четкая концепция	Недостаточно четкое представление о системе может привести к неуве­ренности и противопо­ложным мнениям среди заинтересованных лиц и быстро парализовать про­ект	Необходимо подготовить и утвердить концепцию системы, в которой четко определены ее цели и роль в деятельности орга­низации. Распространите концепцию среди всех участников проекта
Видимые границы	Если вы не определили границы системы, ее масштаб будет расти не­контролируемым образом	Установите четкую и ви­димую границу между системой и внешней сре­дой, перечислив людей и оборудование, взаимо­действующих с данной системой
Ясный состав действующих лиц	Если выявлять только пользователей системы, игнорируя роли, которые они играют по отноше­нию к системе, можно упустить существенную часть поведения системы или ввести избыточное поведение	Идентифицируйте действующих лиц, с кото­рыми должна взаимодей­ствовать система, и роли, которые они играют по отношению к системе. Четко опишите каждую роль
Транзакции, зна­чимые для пользо­вателей	Система несовершенна, если она не может пре­доставить пользователям необходимые услуги и не выполняет цели и задачи,, определяемые ее концеп­цией	Идентифицируйте важ­ные, значимые услуги, которые система предос­тавляет действующим ли­цам для удовлетворения их потребностей
Разворачива­ющееся представ­ление	Количество шагов в опи­сании поведения системы превышает возможности охвата и интересы раз­личных типов читателей вариантов использования	Создайте иерархическую организацию набора ва­риантов использования, которую можно развер­нуть для большей детали­зации, или свернуть, что­бы скрыть детали и пока­зать контекст
Отдельный вариант использования
Законченная единственная цель	Неправильно заданные цели не дают разработчи­кам четко определить, где заканчивается один вариант использования и на­чинается другой	Каждый вариант исполь­зования должен иметь за­конченную и четко опре­деленную цель, которая может находиться на лю­бом уровне образца Раз­ворачивающееся предс­тавление
Имя в виде гла­гольной фразы	Бессмысленные, слиш­ком общие имена вариан­тов использования не да­ют читателям правильно­го представления, на них сложно ссылаться	Именуйте каждый вари­ант использования актив­ной глагольной фразой, отражающей цель основ­ного действующего лица
Сценарий и фраг­менты	Читатели должны иметь возможность легкого сле­дования по интересующе­му их сценарию, в про­тивном случае они могут утратить интерес или по­терять важную информа­цию	Основной сценарий дол­жен быть предельно простым, без анализа воз­можных ошибочных си­туаций. Фрагменты сце­нария, отражающие аль­тернативы, должны рас­полагаться под ним
Исчерпывающие альтернативы	Вариант использования может иметь много аль­тернатив. Отсутствие не­которых из них означает, что разработчики непра­вильно понимают поведе­ние системы, и система может получиться несо­вершенной	Описывайте все альтерна­тивы и ошибочные ситуа­ции, которые могут иметь место в варианте исполь­зования
Перегрузка ин­формацией	Включение нефункцио­нальных требований в ва­риант использования мо­жет быстро привести его в неопределенное и беспо­рядочное состояние	Включите дополнитель­ные позиции в шаблон варианта использования за пределами текста сце­нария, чтобы отразить полезную дополнитель­ную информацию
Точность и читае­мость	Варианты использова­ния,, слишком сложные для нетехнических специ­алистов или слишком неточные для разработчи­ков, несовершенны и мо­гут привести к созданию неадекватной системы	Сделайте вариант ис­пользования достаточно читаемым, чтобы заинте­ресованные лица могли в нем разобраться и оце­нить его, и достаточно точным, чтобы разработ­чики понимали, что им делать
Сценарии и шаги
Обнаруживаемые условия	Разработчики вариантов использования всегда ре­шают проблему, сколько и какие условия включить в их описание	Включайте только реаль­но обнаруживаемые усло­вия. Объединяйте усло­вия, которые оказывают на систему одинаковое воздействие
Уровни шагов	Чрезмерно крупные или мелкие шаги сценария ва­рианта использования де­лают вариант использова­ния трудным для воспри­ятия и понимания	Оставляйте в сценарии от трех до девяти шагов. В идеальном случае все ша­ги должны быть на близ­ких уровнях и на уровне абстракции, следующем за целью варианта ис­пользования
Выполнение цели действующего ли­ца	У читателей и разработ­чиков возникают пробле­мы в понимании поведе­ния системы, если неяс­но, какое действующее лицо отвечает за выпол­нение шага сценария, и что оно делает для его за­вершения	При описании каждого четко указывайте, какое действующее лицо вы­полняет действие, и что оно получает по его за­вершении
Продвижение впе­ред	Разработчики должны ре­шить, как много поведе­ния включить в каждый шаг. Слишком много де­талей делает вариант ис­пользования длинным и трудным для чтения	Исключайте или объеди­няйте шаги, которые не означают никакого дви­жения вперед для действу­ющего лица. Упрощайте фрагменты, которые от­влекают внимание читате­ля от Движения вперед
Нейтральность к технологии	Включение технологи­ческих ограничений и де­талей реализации в опи­сание варианта использо­вания увеличивает слож­ность и затрудняет пони­мание его цели	Описание варианта ис­пользования должно быть нейтральным по отноше­нию к технологии
Связи между вариантами использования
Общее поведение	Описание одинаковых шагов в различных вари­антах использования за­нимает лишнее время и затрудняет понимание об­щих процессов в модели вариантов использования	Выражайте общие дей­ствия в виде «включае­мых» вариантов исполь­зования
Перемещение аль­тернатив	Длинные или сложные описания альтернатив могут занять доминирую­щее положение и пока­заться более важными, чем они заслуживают	Рассмотрите возможность выделения сложных аль­тернатив в отдельный ва­риант использования
Абстракция	Попытка описать в одном варианте использования две или более различных альтернатив, ни одна из которых не является до­минирующей, приводит к проблемам	Создайте обобщенный абстрактный вариант ис­пользования. Поместите каждый отдельный вари­ант сценария, уточняю­щий абстракцию, в спе­циализированный вари­ант использования
Модификация существующих вариантов использования
Удаление изли­шеств	Чрезмерно длинный ва­риант использования гро­моздок и труден для рабо­ты, уводит в сторону вни­мание пользователей	Переместите длинный, громоздкий фрагмент или слишком сложное расши­рение в отдельный вари­ант использования
Объединение фрагментов	Варианты использова­ния, описывающие очень маленькие или изолиро­ванные фрагменты пове­дения, не выражают дос­таточной для понимания информации относитель­но услуг, предоставляе­мых системой (Транзак­ции, значимые для поль­зователей)	Объединяйте небольшие взаимосвязанные вариан­ты использования или фрагменты вариантов ис­пользования в варианты использования, связан­ные общей целью
Удаление лишних вариантов исполь­зования	Варианты использова­ния, результаты которых незначительны, отвлека­ют внимание и затрудня­ют понимание системы	Удалите варианты ис­пользования, которые не дают ничего существен­ного для системы или вы­пали из текущего актив­ного списка вариантов использования

 

Варианты использования, безусловно, не единственный спо­соб выражения функциональных требований. Это объясняется следующими причинами:

· их описания слишком подробны. Заинтересованные лица зачастую желают видеть лишь краткий перечень основных функций;

· некоторые важные функции системы легче выразить в крат­кой форме без привязки к именам вариантов использова­ния.

Следовательно, помимо вариантов использования, функции системы можно выразить через ее свойства (system features), представляющие собой высокоуровневые, краткие утверждения. Более строго в контексте Rational Unified Process системное свой­ство определяется как «наблюдаемая извне и обеспечиваемая системой функция, которая непосредственно удовлетворяет пот­ребности заинтересованного лица». Свойство можно облечь в следующую лингвистическую форму: система будет выполнять «свойство X».

Спецификация требований в технологии Rational Unified Process не требует обязательного моделирования бизнес-процес­сов организации, для которых создается ПО, однако наличие бизнес-моделей существенно упрощает построение системной модели вариантов использования. При переходе от бизнес-моде­ли к начальной версии модели вариантов использования приме­няются следующие правила.

· Для каждого исполнителя в модели бизнес-анализа, кото­рый в перспективе станет пользователем новой системы, в модели вариантов использования создается действующее лицо с таким же наименованием. В состав действующих лиц включаются также внешние системы, играющие в бизнес-процессах пассивную роль источников информации.

· Варианты использования для данного действующего лица создаются на основе анализа обязанностей соответствую­щего исполнителя (в простейшем случае для каждой опера­ции исполнителя создается вариант использования, реали­зующий данную операцию в системе).

Такая начальная версия модели описывает минимальный вари­ант системы, пользователями которой являются только исполните­ли бизнес-процессов. Если в дальнейшем в процессе развития сис­темы ее непосредственными пользователями будут становиться действующие лица бизнес-процессов, то модель вариантов исполь­зования будет соответствующим образом модифицироваться.

Применение данных правил будет проиллюстрировано в сле­дующем примере.

 

3.4.2.