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

Какбыло упомянуто, основная причина провалов проектов по разработкепрограммного обеспечения заключается в проблемах с требованиями.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ключевое слово<id> <система> shall <действие>имя системыдействие, которое должно быть выполненоРис. 3.6.

Формат формулировки требованийОднако многие разработчики моделей (включая и нас) полагают, чтопрецедентов недостаточно и все же нужны традиционные инструментальные средства выработки и управления требованиями.Для записи требований используйте утверждение «shall» («должен»).Мы рекомендуем очень простой формат формулировки требований(рис.

3.6). Каждое требование имеет уникальный идентификатор (обычно это число), ключевое слово (shall (должен)) и описание действия. Преимущество применения унифицированной структуры состоит в упрощении задачи синтаксического разбора требований для инструментовуправления требованиями, таких как DOORS.3.6.3. Функциональные и нефункциональныетребованияПолезно разделять требования на функциональные и нефункциональные. Существует много других способов систематизации требований, нодля простоты начнем с этих двух категорий.Функциональное требование – это то, что система должна делать.Функциональное требование – это формулировка того, что должна делать система, это описание назначения системы.

Например, для банкомата (automated teller machine, ATM) можно было бы определитьследующие функциональные требования:1. Система ATM shall (должна) проверять действительность вставленной в банкомат карточки.2. Система ATM shall (должна) проверять достоверность PINкода,введенного пользователем.3. Система ATM shall (должна) выдавать по одной ATMкарточке неболее $250 в сутки.Нефункциональное требование – ограничение, накладываемое на систему.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. Иерархия типов требований813.6.

Определение понятия требованияКонкретные типы требований зависят от типа создаваемого программного обеспечения. Это особенно касается функциональных требований. Для нефункциональных требований набор типов требований,приведенный на рис. 3.7, довольно стандартный и неплох для начала.Организация требований по типам полезна в случае большого числатребований (около сотни и более). Такой подход особенно хорош, еслииспользуется инструментальное средство выработки требований. Тогда для получения полезной информации можно будет делать запроск модели требований по типу требований.В принципе глубина иерархии типов требований может быть любой.На практике двухтрех уровней для системы средней сложности вполне достаточно.3.6.5.

Атрибуты требованийУ каждого требования может быть ряд атрибутов, фиксирующих дополнительную информацию (метаданные) о требовании.Каждый атрибут требования имеет описательное имя и значение. Например, у требования может быть атрибут dueDate (дата платежа), значением которого является дата выполнения данного требования. Также требование может иметь атрибут source (источник), в качестве значения которого выступает описание того, откуда возникло данное требование. Конкретный набор используемых атрибутов зависит отприроды и нужд проекта и может меняться в зависимости от типа требования.Наверное, самым распространенным атрибутом требований являетсяpriority (приоритет). Его значение определяет приоритет требования относительно остальных требований.

Обычно для назначения приоритетов применяется набор критериев MoSCoW, описанный в табл. 3.1.Таблица 3.1Значения атрибута PriorityСемантикаMust have (обязан иметь)Обязательные требования, являющиеся фундаментальными для системы.Should have (должен иметь)Важные требования, которые могут быть опущены.Could have (мог бы иметь)Понастоящему необязательные требования(реализуются, если есть на это время).Want to have (хотел бы иметь) Требования, которые могут подождать до следующих версий системы.Если применяется схема MoSCoW, у каждого требования есть атрибутPriority, который может принимать одно из значений: M, S, C или W.Инструментальные средства выработки требований обычно обеспечивают возможность делать запрос к модели требований по значению атри82Глава 3.

Рабочий поток определения требованийбута. Таким образом, можно, например, сгенерировать список всех требований с максимальным приоритетом (Must have). Это очень полезно!Преимущество набора критериев MoSCoW в его простоте. Однако в немсмешиваются два разных свойства требования: важность и очередность. Важность требования, единожды заданная, стремится оставаться относительно стабильной. А вот очередность, оцениваемая относительно остальных требований, в ходе проекта может меняться независимо от важности требования.

Например, доступность ресурсов илизависимости от других требований.RUP определяет более полный набор атрибутов требований, в которомразделены важность (Benefit) и очередность (TargetRelease). Атрибуты RUP представлены в табл. 3.2.Количество атрибутов требований должно быть минимальным, от этогопроект только выиграет.Выбор того, что применять – MoSCoW, RUP или какойто другой набор атрибутов требований, – зависит от конкретного проекта. Главноепри определении набора атрибутов – сделать его максимально простым.