Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

ние

только один раз и ссылаетесь на него при каждом появлении его в

другом варианте использования.

Преимущества способа

с применением вариантов использования

Преимущества применения вариантов использования в том, что

каждый вариант

сосредоточен

на поставленной задаче и

пользовате

ле. Пользователи будут более четко представлять, что же им даст

но

вая система, если вы выберете способ, который

фокусируется

на

функциях системы. При разработке нескольких

Интернет-проектов

представители клиентов

заявили,

что варианты использования

позво-

лили

им более четко представить, какие возможности должны

полу-

чить посетители их Web-сайтов. А аналитики и разработчики смогли

разобраться и в

бизнесе-процессах

пользователей, и в предметной

области. Тщательное изучение этапов взаимодействия лица и

систе-

мы помогает еще на ранних стадиях разработки выявить неясности и

неточности,

а также позволяет составить варианты тестирования на

основе вариантов использования.

Очень расточительно и болезненно для разработчиков писать код,

которым никогда не удастся воспользоваться. Если вы будете

заблаго-

временно определять требования и включать в них все мыслимые

функции, то рискуете создать избыточные требования. Способ с при-

менением вариантов использования позволяет выявить функциональ-

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

выполнять

конкретные задачи. Так вы предотвратите появление «функций-си-

рот», тех, что в ходе сбора информации казались весьма полезными,

однако которыми никто че будет пользоваться из-за того, что они не

связаны напрямую с решением рабочих задач,

Способ с применением вариантов использования облегчает расста-

новку приоритетов требований. Высшим приоритетом обладают те

функциональные требования, которые созданы на основе вариантов

использования с высшим приоритетом. Высший приоритет

назначав

ся по следующим причинам:

§ варианты импользования описывают один из основных бизнес-про-

цессов, активизируемых системой;

многие пользователи часто обращаются к ним;

£ их запросил привилегированный класс пользователей;

i они предоставляют

возможности,

необходимые для соответствия

требованиям;

$ функции других систем зависят от их наличия.

Глава 8. Как понять требования пользователей

163

Ловушка Не тратьте много времени на обсуждение деталей вариантов исполь-

зования, которые не будут реализованы в ближайшие месяцы или годы.

Вероятнее

всего, они изменятся еще до начала

сборки.

Существуют также и преимущества технического характера. С помо-

щью варианта использования можно

выявить

некоторые важные объ-

екты предметной области и их взаимоотношения. Разработчики, ис-

пользующие объектно-ориентированные методы дизайна, могут пре-

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

объектные

модели, такие, как

диаграммы классов и диаграммы последовательностей. (Однако сле-

дует помнить, что варианты использования ни в коем случае не ограни-

чиваются разработкой

объектно-ориентированных

проектов). По мере

того как с течением времени изменяются бизнес-процессы,

задачи,

реализуемые посредством определенных вариантов использования,

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

дизайн, код и тесты вплоть до их истоков — пожеланий клиента —

вам

будет легче внести эти изменения

бизнес-процессов

во всю систему.

Каких ловушек следует опасаться при способе

с применением вариантов использования

Как и любой другой способ разработки ПО, применение вариантов ис-

пользования чревато возникновением множества проблем (Kulak и

Guiney, 2000; Lilly, 2000).

i Слишком много вариантов использования. Если вас захлестнул

вал вариантов использования, вам, возможно, не удастся записать

каждый из них на соответствующем уровне абстракции. Не созда-

вайте

отдельный вариант использования для каждого возможного

сценария. Лучше включите нормальное направление развития, аль-

тернативные направления и исключения в виде сценариев в один

вариант использования, Как правило, количество вариантов ис-

пользования превышает количество бизнес-требований и функций,

однако функциональных требований обычно бывает намного боль-

ше, чем вариантов использования.

i Очень сложные варианты использования. Однажды я изучал ва-

риант использования объемом в четыре страницы, плотно запол-

ненных описанием этапов взаимодействия, встроенной логики и ус-

ловий ответвления. Документ казался весьма невразумительным.

Вам

не

дано контролировать сложность бизнес-задач, но вы можете

выбрать способ их представления в вариантах использования.

Вы-

154

Часть II. Разработка требований к ПО

берите один успешный способ выполнения варианта

использова

ния, с одной комбинацией значений правильных и ложных

значении

для различных логических решений и назовите его нормальным

на

правлением. Другие успешные логические ответвления определите

как альтернативные

направления

и назначьте исключения для

обра-

ботки неудачных ответвлений. Альтернативных направлений может

быть множество, однако каждое должно быть кратким и

понятным,

Чтобы не усложнять эту схему, записывайте варианты использова-

ния в терминах, основных для

взаимодействий

пользователя и сис-

темы, без особой детализации.

1 Включение пользовательского интерфейса в варианты

исполь-

зования. Варианты использования должны описывать то, что поль-

зователям необходимо выполнить с помощью системы, а не на то,

как это будет выглядеть на экране. Сосредоточьтесь на концептуаль-

ном взаимодействии пользователя и системы, отложите работу над

пользовательским

интерфейсом до стадии дизайна. Например, пра-

вильная формулировка на этой стадии — «система предоставляет

выбор»,

а не «система отображает раскрывающийся список». Не

до-

пускайте, чтобы дизайн пользовательского интерфейса диктовал

на-

правление разработки требований. Применяйте наброски экрана и

карты диалогов

{диаграммы

архитектуры интерфейса, как описано в

главе

11),

чтобы в визуальной форме представить взаимодействия

исполнителя и системы, а не утвердить дизайн.

i Включения определения данных в варианты

использования.

Мне приходилось видеть варианты использования, которые

включа-

ли в себя определения элементов данных и структур, которыми мани-

пулируют в варианте использования. Участникам проекта было труд-

но отыскать в них необходимые определения, поскольку неясно, в ка-

ком именно варианте использования оно содержится. В

таких

случаях возможен повтор определений, а значит, и их

рассинхрони-

зация, когда один экземпляр изменяется, а остальные нет. Вместо то-

го чтобы «разбрызгивать» определения по вариантам использования,

соберите их данных в словарь данных,

созданный

для всего проекта,

как описано в главе

10.

i Варианты использования, которые непонятны

пользователям.

Если пользователи не видят связи описания вариантов

использо-

вания со своими бизнес-процессами или задачами, то вариант ис-

пользования следует подкорректировать. Составляйте

варианты

использования с точки зрения клиентов, а не системы и

попросите

клиентов проверить их. Возможно, вам не нужны излишне

сложнее

полные варианты использования.

Глава 8. Как понять требования пользователей

155

1 Новые

бизнес-процессы.

Пользователям

будет трудно придумы-

вать новые варианты использования, если ПО создается для под-

держки процесса, которого еще нет. В этом случае сбор информа-

ции по требованиям может оказаться не моделированием бизнес-

процесса, а изобретением такового. Рискованно ожидать, что с по-

мощью новой информационной системы будет создан эффектив-

ный бизнес-процесс. Выполните модернизацию бизнес-процесса,

прежде чем браться за полное описание

новой

информационной

системы.

i Слишком частое упоминание слов расширить и включить. На-

чиная работу с вариантами использования, необходимо изменить

отношение аналитиков, пользователей и разработчиков к требова-

ниям. Тонкости

взаимоотношений,

определяемых словами расши-

рить и включить, могут запутать кого угодно. Лучше избегать их, по-

ка вы не освоите способ с применением вариантов использования.

Таблицы «событие - реакция»

Есть еще один способ систематизации и документации пользователь-

ских требований: определить внешние

события,

на которые система

должна реагировать. Событием (event) называется

какое-либо

измене-

ние или действие в среде пользователя, вызывающее реакцию систе-

мы ПО

(McMenamin

и Palmer, 1984; Wiley, 2000). В таблице «событие —

реакция»

(event-response

table)

[ее также называют таблицей событий

(event table) или списком событий (event

list)]

перечислены все такие

события и ожидаемое поведение системы, которое должно последо-

вать, как реакция на каждое событие. Существует несколько типов сис-

темных

событий, они показаны на рис. 8-9 и описаны далее:

взаимодействие пользователя с ПО, как когда он, например, вызы-

вает вариант использования [иногда называется

бизнес-событием

(business

event)].

Последовательность событий и реакций соответ-

ствует этапам взаимодействия для этого варианта использования,

В отличие от вариантов использования, в таблице «событие — реак-

ция» не описываются цели пользователя при работе с системой и не

приводятся причины, по которым эта последовательность событий

и реакций имеет значение для пользователя;

I контрольный сигнал, чтение данных или прерывание, полученное от

внешнего аппаратного

устройства,

например при изменении поло-

жения

выключателя,

изменении напряжения или перемещении мы-

ши пользователем;

156

Часть II. Разработка требований к ПО

событие инициируется в определенный момент времени

(скажем,

автоматический запуск экспорта данных в полночь) или когда

исте-

кает предварительно заданный период времени с момента

опреде-

ленного события (например, система фиксирует температуру, счи-

тываемую сенсором каждые 10 секунд).

предварительно

определенное время

Рис, 8-9. Примеры системных событий и реакций

Таблицы «событие — реакция» особенно хороши для управления

системами, работающими в режиме реального времени. Табл.

8-1

представляет собой простую таблицу «событие — реакция», в

которой

частично описано поведение очистителей ветрового стекла

автомоби-

ля. Обратите внимание, что ожидаемая реакция зависит не только от

события, но и от состояния, в котором находится система во время со-

бытия. Например, результаты событий 4 и 5.1 в табл. 8-1

различаются

из-за того, были ли включены «дворники» в момент, когда пользова-

тель настроил управление

«дворниками»

на периодический режим. Ре-

акция может просто изменить некоторую внутреннюю системную ин-

формацию (события 4 и 7.1 в таблице) или привести к

результату,

за-

метному извне (большинство других событий).

Информация в таблице «событие — реакция» фиксируется на уровне

пользовательских требований. Если в таблице определены и названы

все возможные комбинации событий, состояний и реакций (включая

условия

исключений),

таблица также может служить частью

функцио-

нальных требований для этого фрагмента системы. Однако

аналитик

должен добавить дополнительные функциональные и нефункциональ-

ные требования в спецификацию требований к ПО. Например, сколько

Глава 8. Как понять

требования

пользователей

157

«взмахов»

в минуту делают «дворники» в быстром и

медленном

режиме

очищения? В быстром или медленном режиме выполняется периоди-

ческая очистка? Является ли периодический режим непрерывно изме-

няющимся или он работает дискретно? Каковы максимальный и мини-

мальный интервал времени при работе в периодическом режиме? Если

вы закончите работу на уровне пользовательских требований, разра-

ботчику самому придется выяснять эту информацию. Помните, ваша

цель — сформулировать требования настолько точно, чтобы

разработ-

чик знал, что строить.

Обратите внимание, что

события,

перечисленные в табл. 8-1 запи-

саны на важнейшем уровне (описывается суть события), а не на

уров-

не реализации (описываются особенности реализации). В табл. 8-1

ничего не говорится о том, как выглядит элемент управления «дворни-

ками» или о том, как пользователь управляет ими. Дизайнер может

реализовать эти требования как угодно — от традиционных элементов

управления

«дворниками»,

как в современных автомобилях, до систе-

мы распознавания голоса, реагирующей на произносимые команды:

«включить

дворники»,

«выключить

дворники», «быстрая очистка», «очи-

стить один раз» и т.д. Записывая пользовательские требования на важ-

нейшем уровне, вы избежите введения ненужных ограничений дизай-

на. Однако следует фиксировать все известные ограничения по дизай-

ну,

чтобы заставить разработчика думать.

Таблица

8-1.

Таблица «событие -

реакция»

для автомобильных «дворников»

ID Событие Состояние системы

Реакция

системы

1.1 установка системы улравле- «дворники» отключены установка механизма

ния «дворниками» в режим «дворников» в режим мед-

медленной очистки ленной очистки

1.2

установка системы

управле-

быстрая очистка установка механизма

ния «дворниками» в режим

«дворников»

в режим мед-

медленной очистки ленной очистки

1.3

установка системы управле- периодическая очистка установка механизма

ния «дворниками» в режим «дворников» в режим мед-

медленной очистки ленной очистки

2.1

установка системы управле- «дворники» отключены установка механизма

кия

^дворниками»

в режим «дворников» г режим

быст-

быстрой очистки рой очистки

158

Часть II. Разработка требований к ПО

Таблица

8-1.

Таблица «событие - реакция» для автомобильных «дворников» (продолжение)

ID Событие

Состояние системы

Реакция

системы

2.2 установка системы управле-

ния

«дворниками"

в режим

быстрой очистки

2.3 установка системы

управле-

ния «дворниками» в режим

быстрой очистки

медленная очистка

периодическая очистка

3.1 отключение системы управ- быстрая очистка

ления

«дворниками^

установка механизма

«дворников» в

режим

быстрой очистки

установка механизма

«дворников» в

режим

быстрой очистки

1. завершение текущего

чикла очистки

2. выключение механиз-

ма «дворников»

3.2

отключение

системы управ-

ления

«дворниками*

медленная очистка

3.3

отключение

системы управ-

ления «дворниками»

периодическая очистка

4 установка системы

управле-

«дворники»

отключены

ния «дворниками» в режим

периодической очистки

5.1 установка системы

управле-

ния «дворниками» в режим

периодической

очистки

быстрая

очистка

5.2 установка системы управле- медленная очистка

ния «дворниками» в режим

периодической очистки

1. завершение текущего

чикла очистки

2. выключение механиз-

ма «дворников»

1. завершение текущего

чикла очистки

2. выключение механиз-

ма «дворников»

1. считывание временного

интервала очистки

2, инициализация

тайме-

ра очистки

считываниевременногс

интервала очистки

2. завершение

текущего

чикла очистки

инициализация

таймо-

ра очистки

со времени

предыдущем

очистки прошел установ-

ленный интервал времени

периодическая очистка

считываниевременнг'ГО

интервала очистки

2. завершение

текущей:)

чикла очистки

3. инициализация тай-

мера очистки

выполнение одного цикла

медленной очистки

Глава 8, Как понять требования пользователей

159

Таблица

8-1.

Таблица

-событие

- реакция» для автомобильных «дворников» (продолжение)

ID Событие

Состояние системы Реакция системы

7.1

измение

интервала

перио-

дической

очистки

периодическая очистка

1. считывание временного

интервала очистки

инициализация

тайме-

ра очистки

7.2 измение интервала перио-

дической очистки

«дворники»

отключены

реакция

отсугсвует

7,3 измение интервала перио-

дической очистки

быстрая очистка реакция отсугсвует

7.4

изменив

интервала перио-

дической очистки

медленная очистка

реакция

отсутсвует

8 получение сигнала на вы-

полнение периодической

очитски

«дворники»

отключены

выполнение

одного

цикла

медленной очистки

Что теперь?

Составьте несколько вариантов использования для вашего текущего проекта на

основании шаблона иа рис. 8-6. Включите в них все альтернативные направле-

ния развития и исключения. Определите функциональные требования, которые

позволят пользователю успешно завершить каждый вариант использования.

Проверьте, не включены

ли

уже все эти функциональные требования в специфи-

кации

требований к ПО.

1 Перечислите все внешние события, которые могут вызвать определенное поведе-

ние системы. Создайте таблицу «событие -

реакция»,

в которой показано состоя-

ние системы в момент воздействия каждого события и реакция системы на него.

160

Часть II. Разработка требований к ПО

Игра по правилам

«Привет, Тим,

этоДжекки.

У меня проблема с запросом

хими-

ката при помощи системы контроля

химикатов.

Мой менеджер

посоветовал обратиться к тебе. Он сказал, что ты был

сторон-

ником продукта и занимался требованиями к этой системе».

«Да,

это так, — ответил

Тим.

—А

в чем проблема?»

«Мне

нужно еще немного фосгена для

красок,

которыми я

сей-

час занимаюсь, — сказала

Джекки,

— но система не принимает

мой запрос и сообщает, что я уже больше года не посещала

занятий по работе с опасными химикатами. О чем это она? Я

годами работала с фосгеном и еще более страшными

химик.з-

тами — и никаких проблем. Почему же мне нельзя

получить

еще немного фосгена?»

«Ты,

возможно, знаешь, что

Contoso

Pharmaceuticals требует

от сотрудников ежегодно прослушивать курс по безопасной

работе с химикатами, — заметил Тим. — Такова корпоративная

политика; система контроля химикатов лишь проводит ее в

жизнь. Я знаю, что раньше кладовщики давали тебе все, что

требовалось, но теперь из-за страховки это невозможно. Из-

вини за

неудобства,

но мы должны подчиняться правилам. Те-

бе придется пройти обучение, чтобы система выполнила твой

запрос».

В любой организации действует широкий набор корпоративных поли-

тик,

законов и промышленных стандартов. Такие отрасли, как банков-

ское дело, авиация и производство медицинской техники, подчиняют-

ся постановлениям правительства. Все эти контролирующие принци-

пы в целом называются бизнес-правилами (business rules).

Зачастую

161

их выполнение и соблюдение осуществляется средствами программ-

ных систем. В других случаях за соблюдением правил и процедур сле-

дят люди.

Большинство бизнес-правил берут начало вне контекста какой-либо

конкретной программной системы. Такие правила, как корпоративная

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

опасными химикатами, действуют, даже если приобретение и распро-

странение химикатов осуществляется исключительно вручную. Стан-

дартные правила отчетности существовали даже в дни зеленых наглаз-

ных повязок для сна и чернильных авторучек. Тем не менее бизнес-

правила — один из основных источников функциональных требований

к ПО, поскольку они определяют

возможности,

которыми должна обла-

дать система для выполнения правил. Даже бизнес-требования высо-

кого уровня могут определяться

бизнес-правилами;

так, например,

система контроля химикатов должна генерировать отчеты о выполне-

нии федеральных и государственных постановлений о хранении и ис-

пользовании химикатов.

Не все фирмы рассматривают собственные важнейшие бизнес-

правила как ценность, которой они и являются на самом деле. Если эта

информация не задокументирована и не хранится должным

образом,

она существует только в головах сотрудников. Но последние могут по-

разному понимать правила, в результате чего отдельные программные

системы могут no-разному выполнять одно и то же бизнес-правило.

Если вам известно, где и как каждое приложение реализует относя-

щиеся к нему бизнес-правила, модифицировать приложения в случае

изменения правил станет гораздо легче.

Ловушка Недокументированные

бизнес-правила

известны только

отдельным

специалистам, а посему они теряются, когда последние

увольняются

или переходят

на другую работу.

На большом предприятии лишь подмножество всех имеющихся

бизнес-правил относится к любому конкретному приложению. Созда-

ние набора общих правил

помогает

аналитикам требований опреде-

лить потенциальные требования, которые не были выявлены при обсу-

ждении с пользователями. Наличие главного хранилища бизнес-пра-

вил упрощает согласованную реализацию приложений, на которые эти

правила влияют.

162

Часть II. Разработка требований к ПО