Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

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

3.7. Поиск требований 83

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

Требования следуют из контекста моделируемой системы. В этот кон

текст входят:

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

• другие заинтересованные стороны (например, руководители, спе

циалисты обслуживания, установщики);

• другие системы, с которыми взаимодействует данная система;

• аппаратные устройства, с которыми взаимодействует данная систе

ма;

• правовые и регулирующие ограничения;

• технические ограничения;

• коммерческие цели.

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

вающего в общих чертах (vision) то, что собирается делать система

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

рон. Назначение этого документа – обозначить наиболее важные цели

системы с точки зрения заинтересованных сторон. Общее описание со

ставляется системным аналитиком в UPфазе Начало.

После общего описания системы начинается настоящая выработка тре

бований. В следующих разделах мы обсудим некоторые методики вы

явления требований.

3.7.1. Выяснение требований — карта местности

еще не территория

Три фильтра – пропуск, искажение и обобщение – формируют естест

венный язык.

При выяснении у людей требований, предъявляемых к программной

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

карты, модели их сферы деятельности. Согласно книге Ноама Хомско

го (Noam Chomsky) «Syntactic Structures» [Chomsky 1], опубликован

ной в 1975 г. и посвященной трансформационной грамматике, подоб

Risk (риск) Риск, связанный с добавлением этой возможности: High

(высокий), Medium (средний) или Low (низкий).

Stability

(стабильность)

Оценка вероятности того, что по какимто причинам требо

вание будет изменено: High (высокая), Medium (средняя)

или Low (низкая).

TargetRelease

(целевая версия)

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

зовано.

Атрибут Семантика

84 Глава 3. Рабочий поток определения требований

ная карта создается тремя процессами: пропуск (deletion), искажение

(distortion) и обобщение (generalization). Эти процессы абсолютно не

обходимы, поскольку мы просто не располагаем механизмом позна

ния, способным фиксировать каждый нюанс и деталь нашей сферы

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

деталей карте. Поэтому приходится быть изобретательными. Мы осу

ществляем «выборку» из огромного массива возможной информации,

применяя три фильтра:

• пропуск – информация отфильтровывается;

• искажение – информация изменяется взаимосвязанными механиз

мами вымысла и представления;

• обобщение – информация обобщается в правила, убеждения и по

нятия об истинности и ложности.

Эти фильтры образуют естественный язык. О них важно знать при

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

ния информации может понадобиться активно их идентифицировать

и ставить под сомнение.

Ниже приведены примеры из системы управления библиотекой. Для

каждого примера указаны вопрос, соответствующий данному фильт

ру, и возможный ответ:

• Пример: «Они используют систему для получения книг на время» –

пропуск.

Вопрос: Кто именно использует систему для получения книг на вре

мя?

Ответ: читатели, другие библиотеки и библиотекари.

• Пример: «Тот, кто имеет книгу на руках, не может взять другую

книгу до тех пор, пока не вернет предыдущую, срок возврата кото

рой истек» – искажение.

Вопрос: Существуют ли такие обстоятельства, при которых ктоли

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

имеющиеся на руках книги, срок возврата которых истек?

Ответ: Фактически существует два обстоятельства, при которых

право читателя на получение книг может быть восстановлено. Во

первых, все имеющиеся на руках книги, срок возврата которых ис

тек, возвращены; вовторых, за все невозвращенные книги, срок

возврата которых истек, внесена плата.

• Пример: «Для получения книг у всех должен быть формуляр» –

обобщение.

Вопрос: Есть ли пользователи системы, которым не обязательно

иметь формуляр?

Ответ: Некоторые пользователи системы, например другие библио

теки, могут не иметь формуляра или имеют специальный форму

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

3.7. Поиск требований 85

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

вого шаблона – квантора общности. Примеры кванторов общности:

При встрече с квантором общности всегда можно найти пропуск, иска

жение или обобщение. Кванторы общности обычно свидетельствуют

о достижении границ или пределов ментальной карты субъекта. Обыч

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

общности. Чуть не написали «всегда следует ставить под сомнение

кванторы общности», но тогда мы бы опровергали самих себя!

3.7.2. Интервью

Проведение интервью с заинтересованными сторонами является са

мым прямым способом сбора требований. Обычно более полную ин

формацию можно получить при интервьюировании один на один.

Основные моменты указаны ниже.

• Не заблуждайтесь по поводу решения – вам может казаться, что вы

очень хорошо понимаете, чего хотят заинтересованные стороны. Но

во время интервью это предположение не должно учитываться. Это

единственная возможность выяснить, что им нужно на самом деле.

• Задавайте контекстносвободные вопросы – вопросы, которые не

предполагают какоголибо конкретного ответа и заставляют интер

вьюируемого говорить о проблеме. Например, вопрос «Кто исполь

зует систему?» является контекстносвободным и способствует об

суждению, тогда как вопрос «Систему используете вы?» предпола

гает ответ «Да/нет» и заканчивает дискуссию.

• Слушать – единственный способ выяснить, чего хотят заинтересо

ванные стороны, поэтому дайте им возможность поговорить. По

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

ожидаете конкретных ответов на вопросы, у вас, возможно, сфор

мировалось неверное решение и исходя из этого заблуждения вы за

даете закрытые вопросы.

• Не занимайтесь телепатией. В сущности, мы все в некоторой степе

ни телепаты. Телепатия – это заблуждение по поводу того, что вам

известны чьито чувства, желания или мысли, базирующееся на

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

ситуации. Это важная человеческая способность, потому что она

является основой сочувствия. Однако это может внести субъектив

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

вы хотите, а не в чем нуждаются заинтересованные стороны.

• Запаситесь терпением!

• все • никогда

• каждый • никто

• всегда • нисколько

86 Глава 3. Рабочий поток определения требований

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

шое влияние на качество получаемой информации. В частности, мы

предпочитаем неформальную обстановку, например небольшое кафе,

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

ся и разоткровенничаться.

Лучший способ записи информации во время интервью – бумага и руч

ка! Использование портативного компьютера отвлекает обе стороны

и может напугать интервьюируемого. Мы предпочитаем графические

диаграммы, выражающие идеи, как гибкий, не внушающий страха

и графически богатый способ сбора информации. Более подробно об этом

можно узнать по адресу www.mind+map.com.

После интервью информация анализируется и формируются некото

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

3.7.3. Анкеты

Анкеты не заменяют интервью.

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

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

список вопросов до того, как стало известно, какие вопросы задавать.

Анкеты могут быть полезным дополнением к интервью. Они хорошо

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

Можно выделить из интервью ключевые вопросы, объединить их

в анкету, а затем распространить ее на более широкую аудиторию. Это

поможет проверить, правильно ли вы понимаете требования.

3.7.4. Семинар по определению требований

Семинар – это один из самых эффективных способов сбора информа

ции, относящейся к требованиям. Для выявления ключевых требова

ний организуется семинар и основные заинтересованные стороны при

глашаются принять в нем участие.

Семинар должен сосредотачиваться на мозговой атаке. Это мощная

техника сбора информации.

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

ботчик требований, основные заинтересованные стороны и специали

сты в определенной области. Процедура проведения подобного семина

ра следующая:

1. Объясните, что сбор требований проводится методом мозговой атаки.

1.1. Все идеи принимаются как хорошие.

1.2. Идеи записываются, но не обсуждаются – никогда ни о чем не

спорьте, просто записывайте и двигайтесь дальше. Все будет

проанализировано позже.

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

3.8. Что мы узнали 87

2.1. Напишите каждое требование на стикере.

2.2. Приклейте стикер на стену или доску.

3. Затем можно еще раз просмотреть все выявленные требования и на

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

3.6.5).

После встречи результаты анализируются и превращаются в требова

ния, как обсуждалось ранее в этой главе. Результаты распространяют

ся для сбора комментариев.

Выработка требований – это итеративный процесс, в котором требова

ния выявляются по мере уточнения понимания нужд заинтересован

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

по мере углубления вашего понимания.

Намного больше информации об организации семинаров и выработке

требований можно найти в книгах [Leffingwell 1] и [Alexander 1].

3.8. Что мы узнали

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

в UP и общее обсуждение требований, предъявляемых к программно

му обеспечению. Вы узнали следующее.

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

выполняется в фазах Начало и Уточнение жизненного цикла про

екта UP.

• Наша метамодель требований (рис. 3.3) показывает, что существует

два способа представления требований: 1) функциональные и не

функциональные требования и 2) прецеденты и актеры.

• Детализация рабочего потока определения требований в UP вклю

чает следующие деятельности, представляющие интерес для ОО

аналитиков и разработчиков:

• Выявление актеров и прецедентов;

• Детализация прецедента;

• Построение модели прецедентов.

• Стандартный рабочий поток определения требований в UP расши

ряется:

• актером: Разработчик требований;

• деятельностью: Выявление функциональных требований;

• деятельностью: Выявление нефункциональных требований;

• деятельностью: Назначение приоритетов требований;

• деятельностью: Отображение (trace) требований в прецеденты.

• Большинство провалов проектов обусловлено недостатками выра

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

88 Глава 3. Рабочий поток определения требований

• Существует два типа требований:

• функциональные требования – какое поведение должна предла

гать система;

• нефункциональные требования – определенное свойство или

ограничение, накладываемое на систему.

• Правильно сформированные требования должны быть выражены

в простых структурированных фразах на английском языке, исполь

зующих выражения shall (должен), для того чтобы инструменталь

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

синтаксический анализ.

<id> <система> shall <действие>

• Модель требований содержит функциональные и нефункциональ

ные требования к системе. Это может быть:

• документ;

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

• Требования могут быть организованы в таксономию – иерархию ти

пов требований, которая классифицирует требования.

• Требования могут иметь атрибуты – дополнительную информацию

(метаданные), ассоциированную с каждым требованием:

• например приоритет – MoSCoW (Must have, Should have, Could

have, Want to have);

• например атрибуты RUP (Status, Benefit, Effort, Risk, Stability,

TargetRelease);

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

от этого проект только выиграет.

• Карта местности еще не территория. Естественный язык содержит:

• пропуски – информация отфильтровывается;

• искажения – информация модифицируется;

• обобщения – информация обобщается в правила, убеждения и по

нятия об истинности и ложности.

• Кванторы общности (например, «все», «каждый») могут указывать

границы чьейлибо ментальной карты сферы деятельности; их необ

ходимо ставить под сомнение.

• Техники выявления требований:

• интервью;

• анкеты;

• семинары.

Моделирование прецедентов

4.1. План главы

В этой главе обсуждаются основы моделирования прецедентов, что яв

ляется еще одной формой выработки требований. Моделирование пре

цедентов будет рассмотрено так, как оно описано в UP. Основное вни

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

применяться ОО аналитиком или дизайнером для эффективного моде

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

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

Полный (и более сложный) учебный пример можно найти на нашем

вебсайте www.umlandtheunifiedprocess.com.

UML не определяет какойлибо формальной структуры для описания

прецедентов. В этом кроется проблема, поскольку разные разработчи

ки моделей используют разные стандарты. Чтобы както справиться

с этим, в этой главе и в учебном примере мы приняли простой и эффек

тивный стандарт. Наш вебсайт предоставляет схему XML (eXtensible

Markup Language, расширяемый язык разметки) с открытым исход

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

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

лучших практиках индустрии и обеспечивают простой, но при этом

эффективный стандарт записи спецификаций прецедентов.

На нашем вебсайте также можно найти очень простую таблицу сти

лей XSL (eXtensible Stylesheet Language, расширяемый язык стилей),

которая превращает XMLдокументы прецедентов в HTML, отобража

емый в броузере. Эта таблица стилей – полезный пример. Она может

быть запросто настроена под стандарты фирменного оформления или

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

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

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

бится обратиться к учебникам по XML, таким как [Pitts 1] и [Kay 1].

90 Глава 4. Моделирование прецедентов

Рис. 4.1. План главы

4.3.1. Контекст системы

(границы системы)

обзор

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

изучаем, как моделировать

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

изучаем, как сократить

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

изучаем, как моделировать

повторение в потоке прецедента

4.2. Моделирование прецедентов

4.3. Деятельность UP: выявление актеров и прецедентов

4.4. Деятельность UP: Детализация прецедента

4.5. Спецификация прецедентов

4.5.1. Имя прецедента

4.5.2. ID прецедента

4.5.3. Краткое описание

4.5.4. Актеры

4.5.5. Предусловия и постусловия

4.5.6. Основной поток

4.5.7. Моделирование

альтернативных потоков

4.5.7.1. Выявление

альтернативных потоков

4.5.7.2. Сколько

альтернативных потоков?

4.8. Что мы узнали

4.7. Когда применять моделирование прецедентов

4.6. Отображение требований

4.5.6.5. Ключевое

слово Пока (While)

4.5.6.4. Ключевое

слово Для (For)

4.5.6.2. Ключевое слово Если (If)

4.5.6.3. Повторение в потоке4.5.6.1. Ветвление потока

4.3.3.2. Диаграмма прецедентов4.3.2.2. Время как актер

4.3.3.1. Идентификация прецедентов4.3.2.1. Идентификация актеров

4.3.4. Глоссарий проекта4.3.3. Что такое прецеденты?4.3.2. Что такое актеры?

else

4.2. Моделирование прецедентов 91

Помимо схемы с открытым исходным кодом и таблиц стилей мы рабо

таем над более гибким подходом под названием SUMR (Simple Use case

Markup Restructured – простая реструктурированная разметка преце

дентов, произносится «summer»). Это простой язык структурирован

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

и актеров. Примеры схемы SUMR, синтаксические анализаторы и ге

нераторы XML и HTML предоставлены на нашем вебсайте, подробнее

см. в разделе 2.2.

4.2. Моделирование прецедентов

Моделирование прецедентов – это форма выработки требований. В раз

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

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

«традиционным» способом. Моделирование прецедентов – это другой,

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

Моделирование прецедентов обычно происходит следующим образом:

• Устанавливаются границы потенциальной системы.

• Выявляются актеры.

• Выявляются прецеденты:

• определяется прецедент;

• устанавливаются основные альтернативные потоки.

• Предыдущие шаги повторяются, пока прецеденты, актеры и грани

цы системы не стабилизируются.

Обычно начинают с самой общей оценки границ системы, чтобы обо

значить область моделирования. Затем все действия осуществляются

итеративно и зачастую параллельно.

Прецеденты – способ записи требований.

Результат этой деятельности – модель прецедентов. В этой модели че

тыре компонента:

• Граница системы – прямоугольник, очерчивающий прецеденты для

обозначения края, или границы, моделируемой системы. В UML 2

эту границу называют контекстом системы (subject).

• Актеры – роли, выполняемые людьми или сущностями, исполь

зующими систему.

• Прецеденты – то, что актеры могут делать с системой.

• Отношения – значимые отношения между актерами и прецедента

ми.

Модель прецедентов является основным источником объектов и клас

сов. Это основные исходные данные для моделирования классов.

92 Глава 4. Моделирование прецедентов

4.3. Деятельность UP: Выявление актеров

и прецедентов

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

В этом разделе основное внимание сосредоточено на деятельности Вы

явление актеров и прецедентов рабочего потока определения требований

(см. раздел 3.4), изображенной на рис. 4.2. В разделе 4.4 мы рассмот

рим деятельность Детализация прецедента.

Рассмотрим исходные данные для деятельности Выявление актеров и пре

цедентов.

• Бизнесмодель – может быть предоставлена в распоряжение разработ

чиков модели системы, но это не всегда выполняется. Если она

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

• Модель требований – создание этой модели было описано в главе 3.

Эти требования являются хорошим исходным материалом для про

цесса моделирования прецедентов. В частности, функциональные

требования предложат прецеденты и актеров. Нефункциональные

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

дентов.

• Список возможностей – это набор потенциальных требований, кото

рые могут быть представлены в форме общего описания (vision)

проекта или чеголибо подобного.

Глоссарий проекта

Модель прецедентов

[в общих чертах]

Системный

аналитик

Выявление актеров

и прецедентов

Бизнес!модель

[или модель предметной области]

Список возможностей

Модель требований

Рис. 4.2. Деятельность UP: Выявление актеров и прецедентов. Адаптировано

с рис. 7.11 [Jacobson 1] с разрешения издательства Addison+Wesley