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

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

На рис. 10-1 показан шаблон спецификации требований к ПО, соз-

данный на основе стандарта IEEE 830; в нем

предлагается

множество

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

можете

включить в свою спецификацию. В приложении Г показан пример спе-

цификации требований к ПО, производной от этого шаблона.

Измени-

те его в соответствии с особенностями вашего проекта. Если какой-то

раздел вашего шаблона не годится

для

конкретного проекта, не удэ-

ляйте его заголовок, но укажите, что он неприменим. В этом случае у

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

пропу-

щено по невнимательности. Если вам постоянно приходится пропус-

кать одни и те же разделы, это означает, что шаблон следует настро-

ить. Создайте оглавление и журнал изменений спецификации требо-

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

внесший

изменение, и ее причина. Иногда фрагмент информации логически

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

аккурат-

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

обсуж-

дать, где следует хранить каждый элемент.

Сравните рис. 5-2 и

10-1.

Вы

увидите,

что шаблон спецификации

требований к ПО и шаблон документа об образе и границах в некото-

рых местах перекрываются (например, общие элементы есть в грани-

цах проекта, в описании особенностей продукта и в разделах операци-

онной среды). Причина кроется в том, что вы создали только один

до-

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

шаблона,

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

необходимости объединив разделы. Возможно, соответствующие

разделы спецификации требований к ПО пригодятся для детализации

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

содер-

жащихся в документе об образе и границах проекта. Если же вы реши-

те вырезать и вставить фрагменты из документа в другой, то

возможна

опасность того, что в обоих появятся ненужные повторы,

В следующих разделах этой главы рассказано, какую информацию

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

можете объединить материал с помощью ссылки на другие документы

(например, об образе и границах проекта или спецификацию интер-

фейса), а не дублировать его в спецификации требований к ПО.

Введение

Введение представляет собой обзор, помогающий читателям разо-

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

ваний к ПО.

Глава 10. Документирование требований 183

1.1 Назначение

Определите продукт или приложение, требования для которого указа-

ны в этом документе, в том числе редакцию или номер выпуска. Если

эта спецификация требований к ПО относится только к части

системы,

идентифицируйте эту часть или подсистему.

1.2

Соглашения,

принятые в документах

Опишите все

стандарты

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

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

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

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

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

ным приоритетом.

1.3

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

Перечислите пользователей, для которых предназначена эта специ-

фикация требований к ПО. Опишите содержание документа и его

структуру. Порекомендуйте наиболее подходящую для каждого класса

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

1.4

Границы проекта

Кратко опишите ПО и его назначение. Покажите, как связан продукт с

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

целями,

а также с бизнес-целя-

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

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

него. Если спецификацию требований к ПО предполагается разра-

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

об образе и границах продукта в качестве подраздела долгосрочного

стратегического образа.

1.5

ССЫЛКИ

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

лаетесь в этой спецификации, в том числе гиперссылки на них. Это

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

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

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

цептуальные документы и спецификация требований к ПО для продук-

тов, на которые вы ссылаетесь. Объем информации должен быть дос-

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

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

184

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

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

(напри

мер, сетевая папка или URL),

2. Общее описание

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

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

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

2.1 Общий взгляд на продукт

Опишите содержание и происхождение продукта. Поясните, является

он новым членом растущего семейства продуктов, новой

версией

су-

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

со-

вершенно новым продуктом? Если спецификация требований

опреде

ляет компонент более крупной системы, укажите, как это ПО соотносит-

ся со всей системой и определите основные интерфейсы между ними.

2.2 Особенности продукта

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

функции.

Детали будут изложены в разделе 3 спецификации требований к ПО,

здесь же следует их только указать. Также здесь уместно

проиллюстри

ровать основные группы требований и их взаимоотношения,

например

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

вари-

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

2.3 Классы и характеристики пользователей

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

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

вующие характеристики (см. главу 6). Некоторые требования могут от-

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

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

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

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

2.4 Операционная среда

Опишите рабочую среду ПО, включая аппаратные средства, операци-

онные системы и их версии, а также географическое местоположение

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

компоненты ПО или приложений, с которыми система должна быть со-

вместима. В документе об образе и границах проекта эта информация

может быть раскрыта более подробно.

Глава 10. Документирование требований

185

2.5 Ограничения дизайна и реализации

Опишите любые факторы, которые ограничат возможности, доступ-

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

Огра-

ничения могут быть такого рода:

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

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

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

напри-

мер типы и версии установленных Web-браузеров;

1 обязательные соглашения или стандарты разработки (например,

если обслуживать ПО будут клиенты,

то

они должны указать особен-

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

рядчик обязан соблюдать);

1 обратная совместимость с продуктами, выпущенными ранее;

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

фиксированы в других

документах,

как рассказано в главе 9);

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

срокам,

ограничения памяти или процессора,

размер,

вес, мате-

риалы или затраты;

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

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

существующего продукта;

I стандартный формат обмена данными, например

XML.

2.6 Документация для пользователей

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

ставляемые с исполняемым ПО. В них могут входить руководства для

пользователя,

онлайн-справка

и обучающие программы. Определите

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

тации.

2.7 Предположения и зависимости

Предположением (assumption) называется

положение,

которое счита-

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

формации. Проблемы возможны в том случае, если предположение

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

ются, поэтому определенные предположения можно отнести к группе

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

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

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

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

186

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

специально для этого приложения,

аналитик—

что он будет взят

из

предыдущего проекта, а менеджер проекта— что

предполагается

приобрести коммерческую библиотеку функций.

Определите все зависимости (dependencies) проекта от

внешних

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

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

планируете?

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

то вы зависите от своевременной их поставки. Если эти зависимости

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

сошлитес..

здесь на них.

3. Функции системы

Шаблон на рис. 10-1 структурирован с помощью особенностей

системы—

это еще один способ систематизации функциональных

требований. Другие методы классификации: по вариантам использо-

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

стимулам,

реакциям,

классам

объектов

или функциональной иерархии (IEEE, 1998b). Воз-

можны также комбинации этих элементов, например варианты ис-

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

единст-

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

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

про-

дукта. Я опишу схему особенностей на примере.

З.х Функция системы X

Укажите название особенности несколькими словами, например «3.1

Проверка правописания».

Также

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

З.х.1

по З.х.З

для каждой особенности системы.

З.х.1

Описание и приоритеты

Кратко опишите особенность системы и укажите, обладает ли она

вь-

соким, средним или низким приоритетом (см. главу 14.)

Приоритет^

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

хо-

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

определите атрибут требований для приоритета. Атрибуты требова-

ний обсуждаются в главе

18,

а средства управления требованиями — а

главе

21.

З.х.2 Последовательности «воздействие - реакция»

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

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

отклики системы, определяющие реакцию конкретной функции. Эти

Глава 10, Документирование требований 187

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

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

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

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

ния, которые связаны с этой особенностью. Чтобы пользователь мог

задействовать эту особенность или реализовать варианты

использо-

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

ПО.

Опишите,

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

ошибки,

неправильный ввод информации или неверные действия. Присвойте

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

4. Требования к внешнему интерфейсу

По мнению Richard

Thayer

(2002),

«требования

к внешнему интерфейсу

определяют оборудование, ПО или элементы баз

данных,

с которыми

система или компонент должны взаимодействовать...» Информация

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

должным образом взаимодействовать с внешними компонентами. Ес-

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

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

части.

Выработка согласованного решения, касающегося внешнего и

внутреннего интерфейса системы, признана наилучшим приемом в

области разработки ПО (Brown, 1996). Вставьте подробные описания

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

данных. В сложной системе с множеством подкомпонентов следует

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

фикацию системной архитектуры (Hooks и

Farry,

2001). В документа-

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

кументов. Например, ссылка на спецификацию программного интер-

фейса другого приложения (API) или на руководство по работе с

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

может отправить ПО.

Войны интерфейсов

Две команды разработчиков ПО объединились для создания флагманского продукта

Datum Corporation. Команда, отвечающая за базу знаний, создала ядро сложного ин-

терфейса на C++, а команда, отвечающая за приложения, реализовала пользова-

тельский интерфейс на Microsoft Visual Basic. Обе подсистемы взаимодействовали

между собой посредством API. К сожалению, команда, отвечающая за базу знаний,

188

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

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

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

потребовалось несколько

часов,

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

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

лись до

сведения

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

с соответствующими модификациями в коде, написанном на Visual Basic. Интерфейс

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

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

цессе контроля за изменениями вашего проекта.

4.1

Интерфейсы пользователя

Опишите логические характеристики каждого пользовательского ин-

терфейса, который необходим системе. Некоторые из них

перечисле-

ны здесь:

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

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

продукта,

которые необхо-

димо соблюдать;

I стандарты шрифтов, значков, названий кнопок, изображений, цве-

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

мых элементов управления и т.п.;

конфигурация экрана или ограничения разрешения;

1 стандартные кнопки, функции или ссылки перемещения, одинако-

вые для всех

экранов,

например кнопка справки;

быстрые клавиши;

стандарты отображения сообщений;

стандарты конфигурации для упрощения локализации ПО;

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

зрением.

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

такие, как конфигурации определенных диалоговых окон, в отдельной

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

требований к ПО. Конечно, добавить еще одну точку зрения на

требо-

вания

полезно,

но необходимо подчеркнуть, что эти модели не

явля-

ются официальными планами экрана. Если в спецификации требова-

ний к ПО говорится об улучшении существующей системы, то стоит

включить в документ изображения экранов в том виде, как они будут

реализованы. Для разработчиков уже заданы ограничения существую-

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

деть измененные, а, возможно, новые экраны.

Глава 10. Документирование требований 189

4.2 Интерфейсы оборудования

Опишите характеристики каждого интерфейса между компонентами

ПО и оборудования системы. В описание могут входить типы поддер-

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

управле-

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

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

4.3

Интерфейсы ПО

Опишите соединения продукта и других компонентов ПО

(идентифи-

цированные по имени и

версии),

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

ные системы,

средства,

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

компоненты. Укажите назначение элементов сообщений, данных и

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

тами ПО. Опишите службы, необходимые внешним компонентам ПО, и

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

которым будут иметь доступ компоненты ПО. Если механизм предос-

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

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

то укажите его как ограничение.

4.4 Интерфейсы передачи информации

Укажите требования для любых функций взаимодействия, которые бу-

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

зер, протоколы сетевого соединения и электронные формы. Опреде-

лите соответствующие форматы сообщений. Опишите особенности

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

данных и механизмов синхронизации.

5. Другие нефункциональные требования

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

ния, не относящиеся к требованиям к интерфейсу, которые представ-

лены в разделе 4, и к ограничениям, описываемым в разделе 2.5.

5.1 Требования к производительности

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

ных системных операций. Обоснуйте их необходимость для того, что-

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

дизайна. Например, из-за жестких требований к времени отклика ба-

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

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

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

190

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

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

бования уже расписаны в других разделах.

Приложение А. Словарь терминов

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

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

сокра-

щения и аббревиатуры. Расшифруйте каждое сокращение и приведи-

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

для нескольких проектов. В этом случае в спецификации требований к

ПО будут определены только те термины, которые относятся лишь к

данному проекту.

Приложение Б. Модели анализа

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

о таких моделях анализа, как диаграммы потока данных, диаграммы

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

«сущность--

связь» (см. главу

11),

Приложение В. Список вопросов

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

требованиями. Это могут быть элементы, помеченные

как«ТВО»

(to be

determined — необходимо определить), отложенные решения, необхо-

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

зательно включать в спецификацию требований к ПО, но в некоторых

организациях принято прилагать список

«TBD»

к спецификации требо-

ваний к ПО. Постарайтесь как можно быстрее разрешить эти пробле-

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

нов спецификации требований к ПО высокого качества.

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

Не существует выверенного способа написания идеальных

требова-

ний,

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

време-

нем. Безупречную документацию по требованиям отличает техниче-

ский стиль изложения и пользовательская терминология, а не компью-

терный сленг.

Kovitz

(1999) предлагает множество рекомендаций и

примеров на эту тему. Вот некоторые из них:

Глава 10. Документирование требований 193

используйте полные

предложения,

с правильной грамматикой, пра-

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

краткими и ясными;

используйте действительный залог

(например,

«Система сделает

то-то», а не «Произойдет

то-то»);

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

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

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

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

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

ким образом, чтоб они стали абсолютно ясны;

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

тема будет» или «Пользователь будет», затем — активный

глагол,

а после — наблюдаемый результат. Укажите инициирующие усло-

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

деленным образом. Например, «Если запрошенный химикат най-

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

мых на складе контейнеров с указанным химикатом». Вы можете

использовать «должно» как синоним «будет», однако следует из-

бегать «следовало бы»,

«может»,

«можно было бы» и аналогичных

слов, из которых не ясно, необходимо ли действие;

при указании требования в форме «Пользователь будет...» иденти-

фицируйте определенного исполнителя (например, «Покупатель

будет...»);

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

вить информацию визуально. Читателей утомляет большой объем

сплошного текста;

подчеркните наиболее значимые фрагменты информации. Здесь

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

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

траст, например затенения (Kovitz, 1999);

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

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

В табл. 10-1 перечислены некоторые из

них,

а также приводятся ре-

комендации, как исправить такие неясности,

Ловушка Оценка качества требований зависит от того, кто их оценивает. Анали-

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

документ

абсолютно ясный, безо

всяких

неясностей и

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

194 Часть II.

Разработка

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