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

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

3.2. Рабочий поток определения требований 73

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

предъявляемых к системе заинтересованными сторонами. Это перего

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

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

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

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

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

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

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

телей через Интернет.

Некоторые книги по UML (и конечно, учебные курсы) отмечают, что

прецеденты UML являются единственным способом фиксирования тре

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

тельном рассмотрении. Прецеденты могут отражать только функцио

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

делать система. Однако есть и другие требования, не относящиеся

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

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

и не могут быть представлены в виде прецедентов. Поэтому в книге

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

ющий дополнительные эффективные способы выявления обоих видов

требований.

Начало Уточнение Построение Внедрение

Определение

требований

Анализ

Проектирование

Реализация

Тестирование

Предварительные

итерации

Шаг

n+1

Шаг

n+2

Шаг

m+1

Рис. 3.2. Определение требований выполняется в фазах Начало и Уточнение.

Адаптировано с рис. 1.5 [Jacobson 1] с разрешения издательства

Addison+Wesley

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

3.3. Метамодель требований, предъявляемых

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

На рис. 3.3 показана метамодель применяемого в данной книге подхо

да к выработке требований. Здесь используется синтаксис UML, кото

рый нами еще не был рассмотрен. Не беспокойтесь! Все это детально

обсуждается позже, а пока необходимо знать лишь следующее:

• Пиктограммы, напоминающие папки, – это пакеты UML. Они яв

ляются механизмом группировки UML и содержат группы элемен

тов модели UML. В сущности, они очень напоминают настоящие

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

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

ник в верхнем правом углу пакета указывает на то, что в пакете на

ходится модель.

• Пиктограмма якоря показывает, что сущность, изображенная со сто

роны кружка, содержит сущность, находящуюся на другом конце

линии.

Наша метамодель показывает, что Спецификация требований к программному

обеспечению (Software requirements specification, SRS) включает Модель

требований (Requirements model) и Модель прецедентов (Use case model).

Эти две модели являются разными, но тем не менее взаимодополняю

щими способами представления требований, предъявляемых к системе.

Можно видеть, что в Модель требований входят Функциональные требования

(требования, определяющие, что должна делать система) и Нефункцио

Модель

прецедентов

Нефункциональные

требования

пиктограмма

якоря

пакет

актер

прецедент

Функциональные

требования

Спецификация

требований

к программному

обеспечению

Модель

требований

Рис. 3.3. Метамодель требований

3.4. Детализация рабочего потока определения требований 75

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

относящиеся к ее функциональности).

Модель прецедентов включает множество пакетов прецедентов (здесь по

казаны только три из них), которые содержат прецеденты (специфи

кации функциональных возможностей системы), актеров (внешние

роли, непосредственно взаимодействующие с системой) и отношения.

По сути, SRS – это начальная стадия процесса построения программ

ного обеспечения. Это отправная точка ОО анализа и проектирования.

Далее настоящая глава посвящена подробному рассмотрению разработ

ки требований. Прецеденты и актеры обсуждаются в главе 4.

3.4. Детализация рабочего потока

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

На рис. 3.4 показаны конкретные задачи рабочего потока определения

требований в UP. Такие диаграммы называют детализацией рабочего

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

ленного потока работ.

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

вовлеченные в конкретный рабочий поток.

Детализации потока работ UP моделируются в виде исполнителей

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

в форме шестеренок). Разновидности UP, такие как RUP, могут ис

Выявить актеров и прецеденты

Назначить приоритеты прецедентов

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

Составитель спецификации прецедентов

Системный аналитик

Архитектор

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

Разработчик пользовательского интерфейса

Создать прототип пользовательского интерфейса

Рис. 3.4. Задачи рабочего потока определения требований. Воспроизведено

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

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

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

суждение отношений между UP и RUP см. в разделе 2.4). Стрелки –

это отношения, показывающие нормальный поток выполнения рабо

ты от одной задачи к следующей. Однако следует помнить, что это

только приближенное представление рабочего потока для «усреднен

ного» случая. Оно может и не быть точным представлением происхо

дящего в действительности. В реальности в зависимости от обстоя

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

параллельно.

Поскольку данная книга посвящена анализу и проектированию, основ

ное внимание сосредоточено только на задачах, важных для ОО анали

тиков и разработчиков. Поэтому нас интересует следующее:

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

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

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

Другие задачи рабочего потока определения требований не так важны

для нас как аналитиков и разработчиков. Назначение приоритетов преце

дентов – это деятельность в основном по планированию архитектуры

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

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

видах деятельности можно узнать в книге [Jacobson 1].

Мы расширяем рабочий поток определения требований в UP, чтобы ра

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

(или другом естественном) языке.

На рис. 3.4 показано, что стандартный рабочий поток UP сосредоточен

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

ний. В этом нет ничего страшного, но, как было отмечено выше, такой

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

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

Выявление функциональных

требований

Разработчик требований

Выявление нефункциональных

требований

Отображение (trace

)

требований в прецеденты

Назначение приоритетов

требований

Архитектор

Рис. 3.5. Расширенный рабочий поток определения требований: новые задачи

и исполнители

3.5. Важное значение определения требований 77

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

и добавить следующие новые задачи:

• Выявление функциональных требований.

• Выявление нефункциональных требований.

• Назначение приоритетов требований.

• Отображение (trace) требований в прецеденты.

Также был введен новый исполнитель – разработчик требований. Но

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

3.5. Важное значение определения требований

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

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

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

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

Согласно [Standish 1], неполные требования и неучастие пользовате

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

проблемы – результат ошибок в выработке требований.

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

требований, эффективная выработка требований – решающий фактор

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

3.6. Определение понятия требования

Требование можно определить как «подробное описание того, что

должно быть реализовано». Существует два основных типа требований:

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

система;

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

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

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

это сделать.

Требования – это (по крайней мере, так должно быть) основа всех

систем. Это, по сути, формулировка того, что должна делать система.

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

система должна делать, но не того, как она должна это делать. Это

важное различие. Можно определить, что должна делать и какое по

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

чтолибо говорить о том, как эта функциональность может быть реа

лизована.

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

Хотя теоретически, конечно же, очень привлекательно отделить «что»

от «как», но на практике набор требований скорее будет смесью «что»

и «как». Отчасти изза того, что обычно проще писать и понимать опи

сание реализации, нежели абстрактное изложение проблемы. Отчасти

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

предопределяют «как» системы.

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

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

бований, многие компании попрежнему не считают это важным. Как

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

программного обеспечения заключается в проблемах с требованиями.

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

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

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

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

и в разной степени полезных «документах с требованиями». Зачастую

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

иразмер. Для любого документа с требованиями, в какой бы форме он

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

полезен мне?» и «помогает ли он мне понять, что должна делать систе

ма?» К сожалению, полезность таких произвольным образом оформ

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

UP обладает формальным подходом к определению требований, осно

ванным на модели прецедентов. Здесь мы расширяем его моделью тре

бований, базирующейся на традиционных представлениях о функцио

нальных и нефункциональных требованиях. Это расширение прямо

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

меняемому в RUP. Наша метамодель требований (рис. 3.3) показыва

ет, что SRS состоит из модели прецедентов и модели требований.

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

UML, таком как Rational Rose. Прецеденты подробно рассматривают

ся в главах 4 и 5.

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

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

пример RequisitePro (www.ibm.com) или DOORS (www.telelogic.com).

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

мере возможности. Как создавать правильно сформированные требо

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

3.6.2. Правильно сформированные требования

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

требований. Фактически требования в UML представляются исключи

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

3.6. Определение понятия требования 79

Однако многие разработчики моделей (включая и нас) полагают, что

прецедентов недостаточно и все же нужны традиционные инструмен

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

Для записи требований используйте утверждение «shall» («должен»).

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

(рис. 3.6). Каждое требование имеет уникальный идентификатор (обыч

но это число), ключевое слово (shall (должен)) и описание действия. Пре

имущество применения унифицированной структуры состоит в упро

щении задачи синтаксического разбора требований для инструментов

управления требованиями, таких как DOORS.

3.6.3. Функциональные и нефункциональные

требования

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

ные. Существует много других способов систематизации требований, но

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

Функциональное требование – это то, что система должна делать.

Функциональное требование – это формулировка того, что должна де

лать система, это описание назначения системы. Например, для бан

комата (automated teller machine, ATM) можно было бы определить

следующие функциональные требования:

1. Система ATM shall (должна) проверять действительность вставлен

ной в банкомат карточки.

2. Система ATM shall (должна) проверять достоверность PINкода,

введенного пользователем.

3. Система ATM shall (должна) выдавать по одной ATMкарточке не

более $250 в сутки.

Нефункциональное требование – ограничение, накладываемое на сис

тему.

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

ключевое слово

уникальный идентификатор

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

Рис. 3.6. Формат формулировки требований

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

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

систему. Система ATM может иметь следующие нефункциональные

требования?

1. Система ATM shall (должна) быть написана на C++.

2. Система ATM shall (должна) обмениваться информацией с банком,

используя 256разрядную кодировку.

3. Система ATM shall (должна) проверять действительность карточки

ATM в течение не более трех секунд.

4. Система ATM shall (должна) проверять достоверность PINкода в те

чение не более трех секунд.

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

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

3.6.4. Организация требований

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

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

пов требований, которая может использоваться при классификации

требований. Типы требований применяются главным образом для соз

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

требований. Такими группами легче управлять, что делает работу

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

Базовое разделение на функциональные и нефункциональные требова

ния, описанное выше, является очень простой таксономией. Но можно

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

как показано на рис. 3.7.

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

Производительность

Производственная мощность

Наличие

Соответствие стандартам

Безопасность

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

Клиенты

Продукты

Заказы

Каналы сбыта

Платежи

Рис. 3.7. Иерархия типов требований

3.6. Определение понятия требования 81

Конкретные типы требований зависят от типа создаваемого программ

ного обеспечения. Это особенно касается функциональных требова

ний. Для нефункциональных требований набор типов требований,

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

Организация требований по типам полезна в случае большого числа

требований (около сотни и более). Такой подход особенно хорош, если

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

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

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

В принципе глубина иерархии типов требований может быть любой.

На практике двухтрех уровней для системы средней сложности впол

не достаточно.

3.6.5. Атрибуты требований

У каждого требования может быть ряд атрибутов, фиксирующих до

полнительную информацию (метаданные) о требовании.

Каждый атрибут требования имеет описательное имя и значение. На

пример, у требования может быть атрибут dueDate (дата платежа), зна

чением которого является дата выполнения данного требования. Так

же требование может иметь атрибут source (источник), в качестве зна

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

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

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

бования.

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

priority (приоритет). Его значение определяет приоритет требования от

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

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

Таблица 3.1

Если применяется схема MoSCoW, у каждого требования есть атрибут

Priority, который может принимать одно из значений: M, S, C или W.

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

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

Значения атрибута Priority Семантика

Must have (обязан иметь) Обязательные требования, являющиеся фун

даментальными для системы.

Should have (должен иметь) Важные требования, которые могут быть опу

щены.

Could have (мог бы иметь) Понастоящему необязательные требования

(реализуются, если есть на это время).

Want to have (хотел бы иметь) Требования, которые могут подождать до сле

дующих версий системы.

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

бута. Таким образом, можно, например, сгенерировать список всех тре

бований с максимальным приоритетом (Must have). Это очень полезно!

Преимущество набора критериев MoSCoW в его простоте. Однако в нем

смешиваются два разных свойства требования: важность и очеред

ность. Важность требования, единожды заданная, стремится оставать

ся относительно стабильной. А вот очередность, оцениваемая относи

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

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

зависимости от других требований.

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

разделены важность (Benefit) и очередность (TargetRelease). Атрибу

ты RUP представлены в табл. 3.2.

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

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

Выбор того, что применять – MoSCoW, RUP или какойто другой на

бор атрибутов требований, – зависит от конкретного проекта. Главное

при определении набора атрибутов – сделать его максимально про

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

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

Таблица 3.2

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

Status (статус) Может иметь одно из следующих значений:

Proposed (предложенные) – требования, которые находятся

в состоянии обсуждения и еще не утверждены.

Approved (одобренные) – требования, утвержденные для

реализации.

Rejected (отклоненные) – требования, которые решено не

реализовывать.

Incorporated (включенные) – требования, которые были

реализованы в определенной версии.

Benefit

(полезность)

Может иметь одно из следующих значений:

Critical (критичное) – требование должно быть реализова

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

сованными сторонами.

Important (важное) – требование может быть опущено, но

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

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

Useful (полезное) – требование может быть опущено без су

щественного влияния на приемлемость системы.

Effort

(трудоемкость)

Оценка времени и ресурсов, необходимых для реализации

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

методами, например методом функциональных точек

(www.ifpug.org)