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

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

темой,

если бизнес-правило встречается в ходе работы — различаются

в зависимости от рабочей среды системы.

Во

избежание

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

бизнес-правил в спецификации требований к ПО. Вместо этого

специ-

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

кретные правила, как на

источник,

скажем,

алгоритма расчета

подо-

ходного налога. Так вы получите несколько преимуществ:

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

со-

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

прави-

ла;

I в спецификации требований к ПО

отражаются

последние измене-

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

лается на основную копию правила;

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

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

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

похо-

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

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

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

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

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

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

ваний: правила, имеющие смысл в ограниченном пространстве, при

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

могут

показаться не такими уж и эффективными. Как и в случае с дру-

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

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

бы во всех ситуациях.

Организации, уверенно управляющие своими бизнес-правилами,

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

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

конкурентное преимущество, которого нет у организаций,

относящих-

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

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

лицам станет понятнее обоснование тех или иных выбранных вами ва-

риантов разработки приложения.

Глава 9. Игра по правилам

173

Что теперь?

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

ние к вашему текущему проекту. Начните заполнять каталог

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

классифицируя правила в соответствии со схемой на рис. 9-1 и

обращая

особое

внимание на источник каждого из них,

Выясните обоснование каждого из ваших функциональных требований, чтобы

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

1 Создайте матрицу связей, указывающую, какие функциональные требования и

элементы БД реализуют каждое из выявленных вами бизнес-правил.

174

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

Документирование требований

Итог

разработки

требований -- задокументированное

соглашение'

между клиентами и разработчиками о создаваемом продукте. Как

уже

говорилось в предыдущих

главах,

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

проекта содержатся

бизнес-требования,

а пожелания

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

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

Под-

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

продукту

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

берете все требования вместе в виде структурированного и

читабель

ного материала и не ознакомите с этим документом всех

заинтере

сованных

в проекте лиц, то у людей не будет уверенности, что они

со-

гласны со всеми положениями.

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

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

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

1 графические модели, иллюстрирующие процессы

трансформации,

состояния системы и их изменения, взаимодействия

данных,

так-

же логические потоки, классы объектов и отношения между ними;

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

щью математически точных, формальных логических языков.

Последний метод обеспечивает наивысшую степень точности,

од-

нако немногие разработчики — и еще меньше клиентов — знакомы :;

ним, поэтому они не

могут,

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

специфи-

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

ния спецификаций описаны в Davis (1993). Несмотря на недостатки,

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

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

175

7-2437

Даже самая лучшая спецификация к требованиям не заменит лич-

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

дый

нюанс,

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

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

ентов,

тестеровщиков

и других заинтересованных лиц— только так

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

возникнут.

В этой главе рассматриваются цель, структура и содержание специ-

фикации требований к ПО. Разобраться в материале вам поможет ру-

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

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

качестве альтернативы традиционным методам документооборота вы

можете выбрать базу

данных,

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

требованиями. Это существенно упростит процесс управления, ис-

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

зависит

от

качества информации,

котораявних

содержится. Вглаве21

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

Спецификация требований к ПО

Спецификацию требований к ПО иногда называют функциональной

спецификацией, спецификацией продукта, документ о требованиях и

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

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

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

необходи-

мые ограничения. Именно на основе спецификации составляются

пла-

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

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

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

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

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

разработки и развертывания.

Спецификация требований к ПО необходима различным участникам

проекта:

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

представление о конечном продукте;

менеджеры проекта по данным спецификации рассчитывают гра-

фики, затраты и ресурсы;

I команда разработчиков ПО получает представление о создаваемом

продукте;

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

1 группа тестирования составляет планы тестирования, варианты

ис-

пользования и процедуры;

i специалисты по обслуживанию и

поддержке

получают

представле-

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

I составители документации создают руководства для

пользовате-

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

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

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

необходима

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

для разработки обучающих материалов;

1 персонал, занимающийся юридической стороной проекта,

прове

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

существующим

зако

нам и постановлениям;

I субподрядчики строят свою работу и несут юридическую

ответст

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

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

специфика

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

разра

ботчиков и клиентов не оставалось ни малейших возможностей

дли

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

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

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

Не обязательно составлять спецификацию для всего продукта

еще

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

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

начале?

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

не-

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

пользо-

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

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

их

реализации разработчиками. Согласованность решений

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

собой процесс изучения и одобрения требований к ПО. При работе с

со

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

не-

нужных переделок.

Структурируйте и составляйте спецификацию требований к ПО та-

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

ней разобраться. В главе 1 перечислено несколько характеристик

пра-

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

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

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

ны согласованно;

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

i оставьте текст невыровненным по правому краю, не выравнивайте

его по ширине;

1 оставляйте достаточно свободного

пространства

(«воздуха»};

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

полужир-

ное начертание,

подчеркивание,

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

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

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

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

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

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

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

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

ре, а не сложную кодировку страниц;

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

ответствующим разделам спецификации или другим документам;

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

ответствующий шаблон.

Требования к именованию

Чтобы легко отслеживать и модифицировать материал, каждое функ-

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

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

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

ках или матрице для отслеживания требований. При этом также

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

проектах. Маркированные списки для этих целей не годятся. Давайте

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

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

Нумерация по порядку

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

ный порядковый номер, например UR-9 или SRS-43. Коммерческие

средства управления требованиями присваивают такой идентифика-

тор, когда пользователь добавляет новое требование в БД. (Эти сред-

ства также поддерживают функцию иерархического именования.) Пре-

фикс обозначает тип требования, например UR означает «user require-

ment» («пользовательское

требование»).

При удалении требования

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

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

ных требований, а названия не раскрывают содержания требования.

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

Иерархическая нумерация

Это наиболее распространенный способ. Если функциональные

тре

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

будут начинаться с 3.2 (например, 3.2.4.3). Чем больше цифр, тем

больше уровень детализации требования. Это способ отличается

про

стотой и компактностью. Ваш текстовый редактор может назначить

номера

автоматически.

Однако даже в спецификации среднего

разме

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

названия,

со

стоящие только из

цифр,

ничего не говорят о назначении требований

Когда же вы начнете применять этот метод на практике, то

обнаружи

те, что присваиваемые

названия

не являются неизменными. Если вы

вставите новое положение, то номера всех последующих фрагментов

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

умень-

шатся. При этом нарушаются все ссылки на эти фрагменты.

Ловушка Однажды один аналитик заметил: «Мы не разрешаем людям встав-

лять требования - сбивается нумерация». Не позволяйте применять неэффектив-

ные приемы, которые могут

препятствовать

эффективной и разумной работе.

Вы можете усовершенствовать этот способ. Пронумеруйте

важней-

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

отдельный

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

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

пример, если в спецификации требований к ПО есть «Раздел 3.5 —

Функции редактора», то требования в нем будут названы

ФР-1,

ФР-2 и

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

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

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

Иерархические текстовые тэги

Консультант Tom

Gilb

предложил текстовую схему иерархических тэгов

именования отдельных требований (Gilb, 1988). Рассмотрим такое

тре-

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

ние

запроса, когда тот хочет печатать более 10 копий».

Этому

требова-

нию можно присвоить тэг

Print.ConfirmCopies,

который означает, что

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

количест

вом печатаемых копий. Иерархические текстовые тэги структурирова-

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

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

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

незначитель-

ная плата за стабильность.

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

Когда информации недостаточно

Иногда вы вдруг понимаете, что вам не хватает определенной ин-

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

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

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

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

«TBD»

(to be determined — необходимо

определить).

Выясните все до реализации набора требований. Любые неясности

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

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

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

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

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

кор-

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

сборке,

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

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

модифицируемыми.

Ловушка Неясности не решаются сами собой. Запишите,

кто

отвечает за каж-

дый вопрос, как и когда. Пронумеруйте все пометки

«TBD»,

это упростит контроль.

Пользовательские

интерфейсы и спецификация

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

Включение элементов пользовательского интерфейса в специфика-

цию имеет как преимущества, так и недостатки. Отрицательным мо-

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

тельского интерфейса отображают решения

(дизайн),

а не требова-

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

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

мо-

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

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

Включение элементов пользовательского интерфейса в требования

может сместить приоритеты, и описание функциональности

окажется

неполной.

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

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

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

снимкам экрана. У одной компании, создающей ПО для Интернета, по-

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

180

Часть II.

Разработка

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

ки

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

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

предстаез-

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

поэтому

им приходилось тратить массу времени на последующие

исправление;.

Из положительных сторон следует отметить, что изучение возмож-

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

прототип)

де-

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

ботчиков. Изображения пользовательского интерфейса помогают

при

планировании и оценке проекта. Подсчет элементов графического ин-

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

{graphical

user interface, GUI) или числа

функ-

циональных точек*

{function

points), связанных с каждым

экраном,

по-

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

зацию.

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

изображений—

набросков—

в спецификацию требований к ПО без

обязательного точного соблюдения этих моделей при реализации.

При этом улучшается взаимодействие специалистов без ненужных or -

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

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

назначение

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

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

зователя.

Шаблон спецификации требований к ПО

Каждая организация, специализирующаяся на разработке ПО,

должна

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

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

шаблоны спецификации (Davis, 1993; Robertson и Robertson, 1999;

Lei-

fingwell и Widrig,

2000).

Многие применяют шаблоны, созданные на

ос-

нове того, что описан в IEEE Standard 830-1998,

«IEEE

Recommended

Practice for Software Requirements Specifications» (IEEE, 1998b). Он го-

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

ограни-

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

Функциональной

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

приложения независимо от того, как они сконструированы. Вы можете оценить функциональны •?,

точки, исходя из требований

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

по числу внешних логических файлов и элементов

вводимых данных, выводимых данных и запросов (IFPUG,

2002).

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

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

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

дого крупного класса отдельный шаблон спецификации.

Введение

1.1

Назначение

1.2 Соглашения, принятые документах

1.3

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

1.4

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

1.5

Ссылки

2. Общее

описание

2.1

Общий

взгляд

на продукт

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

2.3

Классы

и характеристики

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

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

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

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

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

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

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

3.x. 1 Описание и приоритеты

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

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

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

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

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

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

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

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

5.1

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

5.2

Требования

к охране труда

5.3 Требования к безопасности

5.4 Атрибуты качества

6. Остальные требования

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

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

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

Рис.

10-1.

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

182

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