WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 | 3 | 4 | 5 |   ...   | 9 |
-- [ Страница 1 ] --

Разработка требований к программному обеспечению Практические приемы сбора требований и управления ими при разработке программного продукта Карл И. Вигерс Дважды

лауреат Software Development Productivity Award ш Microsoft Посвящается Крис Software Requirements Second Edition Practical techniques for gathering and managering requirements throughout the development cycle Karl E. Wiegers Two-time winner of the Software Deve/opment Productivity Award MJ&vsaft* Press Разработка требований к программному обеспечению Практические приемы сбора требований и управления ими при разработке программного продукта Карл И. Вигерс Дважды лауреат Software Development Productivity Award Москва 2004 М.РШШ ЩНЦ УДК 004. ББК 32.973.26-018. В Вигерс Карл В41 Разработка требований к программному обеспечению/Пер, с англ. — М.:

Издательсш-торговый дом «Русская Редакция», 2004. —576с.: ил.

ISBN 5-7502-0240- Эта книга посвящена разработке качественных требований к продукту, Здесь описаны дюжины проверенных на практике способов выявления, фор мулирования, разработки, проверки, утверждения и тестирования требова ний к ПО, которые помогут разработчикам ПО, менеджерам и маркетологам создать эффективное ПО. Это перевод второго издания оригинальной книги, которое дополнено новыми главами о роли аналитика требований, важности бизнес-правил, а также о том, как формулирование требований важно для проектов по обслуживанию, для комплексных решений и проектов, разраба тываемых сторонними организациями.

Основная аудитория — аналитики требований и разработчики продукта, а также дизайнеры, программисты, тестеровщики ПО и другие члены коман ды, задача которых понять и удовлетворить чаяния клиентов, а также маркето логи, менеджеры по продуктам и менеджеры проекта, которые должны про никнуться «духом» и особенностями продукта, чтобы сделать его в полной ме ре конкурентоспособным.

Книга состоит из 23 глав, 4 приложений, словаря терминов и библиогра фического списка.

УДК 004. ББК 32.973.26-018. Подготовлено к изданию по лицензионному договору с Microsoft Corporation, Редмонд, Вашингтон, США.

Microsoft, Microsoft Press, Visual Basic и Windows являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все другие товарные знаки являются собственностью соответствующих фирм.

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

© Оригинальное издание на английском языке, KarlWiegers, © Перевод на русский язык, Microsoft Corporation, © Оформление и подготовка к изданию.

ISBN 0-7356-1879-8 (англ.) издательско-торговый дом "Русская ISBN 5-7502-0240-2 Редакция.., Содержание xiii Предисловие Что дает эта книга xiv Кому предназначена эта книга xv Краткий обзор xv Примеры из практики xvi От принципов - к практике xvii xvii Благодарности Часть I. Требования к продукту: что, почему и кто Глава 1. Особенности разработки требований к ПО Оговоренные требования к ПО (' Особенности интерпретации требований G Уровни требований / Каких требований не должно быть Разработка и управление требованиями Разработка требований Управление требованиями Каждый проект имеет требования Когда плохие требования появляются у хороших людей Недостаточное вовлечение пользователей «Разрастание» требований пользователей Двусмысленность требований «Золочение» продукта Минимальная спецификация Пропуск классов пользователей Небрежное планирование Выгоды от высококачественного процесса разработки требований Характеристики превосходных требований Характеристики отдельных положений спецификации требований Характеристики спецификации требований Глава 2. Требования с точки зрения клиента Кто же клиент? Сотрудничество клиентов и разработчиков Билль о правах клиента ПО Билль об обязанностях клиента ПО Что насчет подписи? Глава 3. Хорошие приемы создания требований Обучение Выявление требований Анализ требований Спецификации требований Проверка требований Управление требованиями Управление проектом Начинаем применять новые приемы Процесс создания требований Глава 4. Аналитик требований Роль аналитика требований Задачи аналитика Навыки, необходимые аналитику Знания, необходимые аналитику Становление аналитика Бывший пользователь Бывший разработчик Профильный специалист Создание атмосферы тесного сотрудничества Часть II. Разработка требований к ПО Глава 5. Определение образа и границ проекта Определение образа продукта вплоть до бизнес-требований Конфликтующие бизнес-требования Бизнес-требования и варианты использования vi Содержание Документ об образе и границах проекта 1. Бизнес-требования 2. Образ решения 3. Масштабы и ограничения проекта 4. Бизнес-контекст Контекстная диаграмма Не упускайте границы из вида Глава 6. Как отобрать пользователей для работы над проектом Основные источники получения информации о потребностях клиентов Классы пользователей Представители пользователей Сторонники продукта 1СЗ Сторонники продукта, приглашенные со стороны Чего следует ожидать от сторонника продукта На что способны несколько сторонников продукта Как «продать» идею о необходимости привлечения сторонника продукта В какие ловушки можно угодить, привлекая сторонников продукта 1С!

Кто принимает решения Глава 7. Как услышать голос клиента Выявление требований Польза семинаров Несколько советов о том, как собирать информацию Поиск упущенных требований Как понять, что сбор требований завершен 1С Глава 8. Как понять требования пользователей Подход с применением варианта использования продукта Варианты использования и сценарии использования Определение вариантов использования Документирование вариантов использования Варианты использования продукта и функциональные требования Преимущества способа с применением вариантов использования Каких ловушек следует опасаться при способе с применением вариантов использования Таблицы «событие - реакция» vi Содержание Глава 9. Игра по правилам Правила бизнеса Факты Ограничения Активаторы операций Выводы Вычисления Документирование бизнес-правил Бизнес-правила и требования Глава 10. Документирование требований Спецификация требований к ПО Требования к именованию Когда информации недостаточно Пользовательские интерфейсы и спецификация требований к ПО Шаблон спецификации требований к ПО 1. Введение 2. Общее описание 3. Функции системы 4. Требования к внешнему интерфейсу 5. Другие нефункциональные требования 6. Остальные требования Приложение А. Словарь терминов Приложение Б. Модели анализа Приложение В. Список вопросов Принципы создания требований Примеры требований: до и после Словарь данных Глава 11. Любое изображение стоит 1024 слов Моделирование требований От желания клиента к модели анализа Диаграмма потока данных Диаграмма «сущность - связь» Диаграмма перехода состояний Карта диалогов Диаграмма классов Таблицы решений и деревья решений Последнее напоминание Содержание viii Глава 12. Обратная сторона функциональности:

атрибуты качества ПО Атрибуты качества Определение атрибутов качества Атрибуты, важные для пользователей Атрибуты, важные для разработчиков 24:!

Требования к производительности 24 • Определение нефункциональных требований с помощью языка Planguage 24' Компромиссы для атрибутов Реализация нефункциональных требований Глава 13. Прототипы как средство уменьшения риска Что такое прототип и для чего он нужен Горизонтальные прототипы Вертикальные прототипы 25( Одноразовые прототипы Эволюционные прототипы 25! Бумажные и электронные прототипы Оценка прототипа Риски прототипирования Факторы успеха прототипирования Глава 14. Назначение приоритетов требований Зачем определять приоритеты требований Игры, в которые люди играют с приоритетами Шкала приоритетов Определение приоритетов на основе ценности, стоимости и риска Глава 15. Утверждение требований Просмотр требований Проведение экспертизы Проблемы при просмотре требований Тестирование требований Определение критерия приемлемости Глава 16. Проблемы при разработке специальных требований ЗС D Требования к проектам по обслуживанию Начните сбор информации Применяйте новые приемы работы с требованиями Перемещайтесь по цепочке трассируемое™ Обновляйте документацию Содержание ix Требования для пакетных решений Разработка вариантов использования Работа с бизнес-правилами Определение требований к качеству Требования к проектам, выполняемым сторонними организациями Требования для принципиально новых проектов Бессистемная спецификация пользовательских требований Присутствие клиента Периодическая расстановка приоритетов на ранних стадиях Простое управление изменениями Глава 17. От разработки требований — к следующим этапам От требований - к планам проекта Требования и расчеты Требования и график От требований - к дизайну и коду От требований - к тестированию От требований - к успеху Часть III. Управление требованиями к ПО Глава 18. Принципы и приемы управления требованиями к ПО Базовая версия требований Процедуры управления требованиями Контроль версий Атрибуты требований Контроль статуса требований Измерение усилий, необходимых для управления требованиями Глава 19. Изменения случаются Управление незапланированным ростом объема Процесс контроля изменений Политика контроля изменений Описание процесса контроля изменений Совет по управлению изменениями Состав совета по управлению изменениями Устав совета по управлению изменениями Средства контроля измений Измерение активности изменений Изменение не бесплатно: анализ влияния Процедура анализа влияния изменения Шаблон отчета об анализе влияния изменения Содержание Глава 20. Связи в цепи требований Трассируемость требований 38Е Мотивация для трассируемое™ требований 38Е Матрица трассируемое™ требований 39С Средства трассирования требований Процедура трассирования требований Осуществимость и необходимость трассирования требований Глава 21. Инструментальные средства управления требованиями Преимущества использования инструментальных средств управления требованиями 40* Возможности инструментальных средств управления требованиями 4(М Реализация автоматизации управления требованиями Выбор инструментального средства Изменение культуры работы Как заставить инструментальные средства работать Часть IV. Особенности реализации процесса построения требований Глава 22. Совершенствование процессов работы с требованиями Как требования связаны с другими составляющими проекта Требования и различные заинтересованные в проекте группы 41Г Основы совершенствования процессов разработки ПО Цикл совершенствования технологических процессов Оцените текущие технологические процессы Создайте план совершенствования Создайте, опробуйте и реализуйте новые процессы Оцените результаты Образцы документов для процессов конструирования требований 42!) Образцы документов для разработки требований Образцы документов для управления требованиями Дорожная карта совершенствования работы с требованиями Глава 23. Требования к ПО и управление риском Основы управления риском при создании ПО Составляющие управления риском Документирование рисков проекта Планирование управления риском Содержание id Риск, связанный с требованиями Выявление требований Анализ требований Спецификация требований Утверждение требований Управление требованиями Управление риском - ваш друг Эпилог Приложение А. Самостоятельная оценка применяемых вами приемов работы с требованиями Приложение Б. Модели совершенствования требований и технологических процессов The Capability Maturity Model for Software CMMI-SE/SW Приложение В. Руководство по поиску и решению проблем, связанных с требованиями Анализ основных причин Общие симптомы проблем, связанных с требованиями Общие препятствия для реализации решений Приложение Г. Примеры документации требований Документ об образе и границах проекта Варианты использования Спецификация требований к ПО Приложение А. Словарь и модель данных Приложение Б. Модели анализа Бизнес-правила Словарь терминов Библиографический список Об авторе Содержание Предисловие Несмотря на более чем пятидесятилетнее существование компьютер ной отрасли, многие компании — разработчики программного обеспе чения по-прежнему прикладывают значительные усилия для сбора i/ документирования требований к ПО, а также управления ими. Недоста точный объем информации, поступающей от пользователей, требова ния, сформулированные не полностью, их кардинальное изменение — вот основные причины, из-за которых зачастую командам, работаю щим в области информационных технологий, не удается вовремя и и рамках бюджета предоставить клиентам всю запланированную функ циональность*. Многие разработчики не умеют спокойно и профессио нально собирать требования пользователей к ПО. У клиентов зачастую не хватает терпения участвовать в разработке требований к ПО, или они норовят передать свои пожелания через совершенно неподходя щих для этого дела людей. Иногда участники проекта даже не могу;

прийти к единому мнению, что же такое «требование». Как заметил один писатель, «программисты скорее предпочтут расшифровать ело ва классической песни Кингсмена (Kingsmen) «Louie Louie», чем требо вания клиентов»**.

Разработка ПО включает по крайней мере столько же общения, сколько и обычная работа с компьютером, но зачастую мы делаем ак цент на работе с компьютером и не уделяем достаточно внимание общению. В этой книге описаны дюжины способов, позволяющих реа лизовать это общение и помогающих разработчикам ПО, менеджерам, маркетологам и клиентам использовать на практике эффективные Исследование «CHAOS Report», проведенное компанией Standish Group International, 1995.

Peterson, Gary. Статья «Risque Requirements» в апрельском номере журнала CrossTalk за 200-'.

xt i методы формулирования требований к ПО. Настоящее издание допол нено новыми главами, посвященными роли аналитика требований, важности бизнес-правил, а также рассказом о том, как формулирова ние требований важно для проектов по обслуживанию, для комплекс ных решений, для извлечения данных из внешних источников и новых проектов. Во многочисленных врезках я привожу реальные примерь, иллюстрирующие типичные ситуации, возникающие при формулиро вании требований.

В книге описаны основные «отличные способы» формулирования требований, а не экзотичные или тщательно разработанные методоло гии, обещающие решить все проблемы, возникающие при формули ровании требований. С тех пор, как в 1999 г. вышло первое издание этой книги, я провел свыше 100 семинаров, посвященных формулиро ванию требований к ПО, для сотрудников коммерческих и правитель ственных организаций всех толков. Я понял, что эти способы годятся практически для любого проекта, включая развертываемые частями, маленькие проекты и крупномасштабные гиганты, а также те, что раз рабатываются «с нуля», и проекты по обслуживанию. Кроме того, эти способы не ограничиваются только областью разработки ПО, и вполне годятся для проектирования оборудования и систем. Как и в случае с любыми другими способами разработки ПО, чтобы понять, какие из способов формулирования требований подходят вам более всего, следует руководствоваться здравым смыслом и опираться на собст венный опыт.

Что дает эта книга Из всех возможных способов совершенствования процесса разработ ки ПО наибольшее преимущество за формулированием требований.

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

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

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

I сделатьклиентадовольным;

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

Моя цель — помочь вам усовершенствовать процессы сбора и ана лиза требований, написания и оценки спецификаций, определяющих xv ' Предисловий требования, а также процессы управления требованиями на протяже нии всего цикла разработки продукта. Надеюсь, вы на самом деле ста нете применять усовершенствованные способы, а не просто прочтете о них. Изучить новые способы легко;

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

Кому предназначена эта книга Она для тех, кто так или иначе вовлечен в сбор и формулирование тре> бований к программному продукту. Основная аудитория— аналитики требований и разработчики продукта независимо от того, работаю" они полный день или привлекаются к проекту время от времени. Более широкий круг читателей — дизайнеры, программисты, тестеры ПО и другие члены команды, задача которых понять и удовлетворить чаяния клиентов, а также маркетологи и менеджеры по продуктам, которые должны проникнуться «духом» и особенностями продукта, чтобы еде лать его в полной мере конкурентоспособным. Менеджеры проекта, отвечающие за своевременный выпуск, также найдут здесь для себя немало интересного: они узнают, как управлять показателями, связан ными с требованиями к проекту, а также реагировать на изменение этих требований. Еще один сегмент аудитории — клиенты, которые жаждут высказать свои пожелания о создаваемом продукте. Настоя щая книга поможет им понять роль процесса формулирования требо ваний и их место в этом процессе.

Краткий обзор Книга состоит из четырех частей. Первая часть «Требования к продукту:

что, почему и кто» начинается с ряда определений и описания некото рых характеристик требований, которые считаются качественными. Ее ли вы занимаетесь техническими вопросами, надеюсь, вы поделитес-» концепциями главы 2, посвященной взаимодействию клиентов и раз работчиков, со своими ключевыми клиентами. В главе 2 описано не сколько дюжин хороших приемов создания и управления требования ми, а также процесс формулирования требований в целом. Глава 4 по священа роли аналитика требований.

Вторая часть «Разработка требований к ПО» начинается с описания способов для определения бизнес-требований к проекту. Другие гла вы этой части посвящены тому, как правильно выбрать представите Предисловие xw лей клиента, узнать у них требования и задокументировать варианты использования, бизнес-правила, функциональные требования и атри буты качества. В главе 11 обсуждается несколько моделей анализа, представляющих требования с разных точек зрения, в главе 13 — при менение прототипов ПО, позволяющих снизить риск выпуска продукта ненадлежащего качества. Прочие главы посвящены расстановке при оритетов и оценке требований. Завершается вторая часть описанием особенностей формулирования требований для нескольких конкрет ных проектов и рассказом о том, как требования влияют на другие ас пекты работы над проектом.

В третьей части «Управление требованиями к ПО" речь пойдет о прин ципах и способах управления требованиями, особое внимание уделяет ся технологиям, позволяющим реагировать на изменение требований.

В главе 20 рассказано, как отслеживать изменение требований с само го начала до их реализации в продукте. Третья часть завершается опи санием коммерческих утилит, расширяющих возможности управления требованиями к проекту.

Заключительная часть книги «Особенности реализации процесса построения требований» поможет вам перейти от теории к практике.

В главе 22 рассказано, как включить новые способы формулирования требований в действующий процесс разработки. Глава 23 посвящена рискам, связанным с требованиями к проекту. Приложение А позволи вам оценить применяемые способы формулирования требований и оп ределить области, требующие совершенствования. В прочих приложе ниях представлены руководство по устранению проблем, возникающих при формировании требований, а также примеры задокументирован ных требований к проектам.

Примеры из практики Методы, описанные в книге, я иллюстрирую примерами, за основу ко торых взяты реальные проекты;

это касается и информационной сис темы среднего размера под названием Chemical Tracking System. (He волнуйтесь — чтобы разобраться в этом проекте, знание химии вам не потребуется.) Диалоги участников проектов из примеров разбавляют текст книги. Думаю, вне зависимости от того, что за ПО разрабатывает ваша команда, вы найдете эти диалоги интересными и полезными, Предисловие От принципов - к практике Трудно представить, сколько энергии потребуется на преодолении препятствий, мешающих изменению и практическому применению но вых знаний. Заманчивей оставаться в зоне комфорта, которая опреде ляется знакомыми — если не сказать, не всегда эффективными — спо собами разработки. Чтобы облегчить вам применение новых знаний на практике, каждую главу я заканчиваю разделом «Что теперь?», гдз перечислены конкретные действия, которые вы можете выполнить з отношении реального проекта. На моем Web-узле http://www,proces simpact.com вы найдете аннотированные шаблоны документов для ог ределения требований, контрольные списки проверки, таблицу при оритетов требований, описание процесса контроля изменений, а так же полезные вещи для многих других процессов. Используйте эти ма териалы, чтобы применять полученные значения на практике. Начните с небольших усовершенствований, но — именно сегодня, не отклады вая на завтра.

Отдельные участники проекта с большой неохотой возьмутся за применение новых способов формулирования требований. Некоторь е люди откровенно неблагоразумны, и если вы имеете дело именно с та кими людьми, описанные здесь способы работать не будут. Исполь зуйте материал книги для обучения коллег, клиентов и менеджеров.

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

Не обязательно запускать новый проект, чтобы начать применять усовершенствованные способы формулирования требований. В гла ве 16 рассказывается, как использовать описываемые в книге способы в проектах по обслуживанию. Постепенное внедрение новых спосо бов — сопряженный с незначительным риском подход к совершенст вованию процесса разработки, который подготовит вас к комплексно му использованию новых способов при работе над следующим круп ным проектом.

Цель — сформулировать требования, которые позволят проектиро вать приложения с приемлемым уровнем риска. Потратив на это дос таточно времени, вы можете быть уверены, что свели к минимуму риск переделки продукта, создания негодного ПО или срыва сроков сдачи проекта. Эта книга научит вас, как объединить усилия нужных людей для разработки качественных требований к нужному продукту, Предисловие xvii Благодарности Выражаю глубокую благодарность людям, не поленившимся просмотреть руко пись этой книги и предложившим бесчисленные рекомендации по совер шенствованию ее текста. Рецензенты первого издания — Стив Адольф (Steve Adolph), Никки Бьянко (Nikki Bianco), Билл Дэгг (Bill Dagg), Дейл Эмери (Dale Em ery), Крис Фальбуш (Chris Fahlbusch), Джиоф Фламанк (Geoff Flamank), Линда Флеминг (Lynda Fleming), Кэти Гетц (Kathy Getz), Джим Харт (Jim Hart), Тэмми Хогэнсон (Tammy Hoganson), Майк Малек (Mike Malec), Дипендра Мойтра (Deep endra Moitra), Майк Ребацк (Mike Rebatzke), Фил Рекио (Phil Recchio), Кэти Род (Kathy Rhode), Джоанна Ротман (Johanna Rothman), Джойс Стац (Joyce Statz), Дорис Штурценбергер (Doris Sturzenberger), Пракаш Упадхайюла (Prakash Up adhyayula) и Скотт Витмайр (Scott Whitmire). Что касается настоящего, второго, издания, то я высоко ценю вклад Стива Адольфа (Steve Adolph), Росса Колларда (Ross Collard), Ричарда Дальтона (Richard Dalton), Криса Фальбуша (Chris Fahl busch}, Линды Флеминг (Lynda Fleming), Элен Готтесдинер (Ellen Gottesdiener), Линды Льюис (Linda Lewis), Джеффа Пинка (Jeff Pink), Эрика Симмонса (Erik Sim mons), Дэвида Станденфорда (David Standerford), Дэниса Стефенсона (Dennis Stephenson), Скотта Витмайра (Scott Whitmire), Ребекки Вирш-Брок (Rebecca Wirfs-Brock) и Триши Цвирнбаум (Trish Zwirnbaum).

Спасибо сотрудникам Microsoft Press, принявшим участие в работе над пер вым изданием этой книги, в том числе редакторам Бену Раину (Ben Ryan), Джону Пирсу (John Pierce), Мэри Колбах Барнард (Магу Kalbach Barnard), Мишель Гудман (Michelle Goodman), Робу Нэнсу (Rob Nance) и Поле Горлик (Paula Gorelick). За работу над вторым изданием благодарю Даниеля Берда (Danielle Bird), Томаса Польмана (Thomas Pohlmann), Дэвона Масгрейва (Devon Mus grave), Санди Резник (Sandi Resnick), художника Майкла Клопфера (Michael Kloepfer) и наборщицу Джину Кассил (Gina Cassill). Значительную помощь мне оказали и слушатели семинаров по формулированию требований к ПО, за по следние несколько лет они завалили меня предложениями и рекомендациями.

Пожалуйста, пишите мне по адресу kwiegers@acm.org и делитесь со мной опытом.

Выражаю глубочайшую признательность Крис Замбито (Chris Zambito) самой веселой, самой терпеливой и самой заботливой жене, о какой писатель может только мечтать.

Благодарности xviii Особенности разработки требований к ПО «Привет, Фил, это Мария из отдела персонала. У нас проблема с системой, которую вы разрабатывали для нас. Одна из со трудниц изменила имя на Спакл Старлайт, а система не прини мает это изменение. Ты можешь помочь?» Юна вышла замуж за парня по имени Старлайт?» "Нет, она просто взяла другое имя, — ответила Мария. — В этом-то и проблема. Как будто мы можем брать другое имя только при изменении семейного положения».

«Да, я не предусмотрел такой возможности. Я не помню, чтобы и ты говорила мне о ней, когда мы обсуждали систему. Вот по этому-то диалоговое окно «Изменить имя» доступно только из окна «Изменение семейного положения», — сказал Фил.

«Я полагаю, ты знаешь, что люди могут законным образом ме нять имена, когда захотят, — ответила Мария. — Мы должны исправить это к пятнице, а то Спакл не сможет обналичить чек.

Ты сможешь исправить этот дефект к такому сроку?» "Это не дефект, ~ резко парировал Фил. —Яине знал, что вам нужна эта функциональность. Сейчас я занимаюсь оценкой производительности системы. Думал, что потребуется менять что-то другое». (Шелест бумаги.) «О-о, да здесь есть еще кое что. Я, вероятно, смогу исправить это в конце месяца, но не на этой неделе. Извини меня. Но в следующий раз с такими просьбами звони пораньше и, пожалуйста, описывай их».

«А что же я скажу Спакл? — возмутилась Мария. — Ей придется залезать в долги, если она не сможет обналичить чек».

«Эй, Мария, это не моя вина, — запротестовал Фил. — Если ты не сказала мне при первом осуждении, что вам понадобится Часть I. Требования к продукту: что, почему и кто изменять имена в любое время, этого и нет в системе. Ты не можешь винить меня за то, что я не умею читать мысли в твоей голове».

Сердитая и смирившаяся, Мария отрывисто сказала: «Это как раз то, из-за чего я ненавижу компьютерные системы. Позве ни мне, как только сможешь исправить недостаток».

Если вы когда-либо бывали в шкуре клиента на переговорах, подобных этому, то знаете, как расстраиваются пользователи продукта*, кото рый не позволяет выполнять основные задачи. Разработчики испыты вают чувство разочарования, когда узнают о функциональности, кото рую пользователи ожидали получить, только после развертывания сис темы. Точно также раздражает, если приходится прерывать работу и;

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

Масса проблем с ПО возникает из-за несовершенства способов, которые люди применяют для сбора, документирования, согласования и модификации требований к ПО. Как в случае с Филом и Марией, проблемы могут возникать из-за неформального сбора информации, предполагаемой функциональности, ошибочных или несогласованных предположений, недостаточно определенныхтребований и бессистем ного изменения процесса.

Большинство людей при строительстве дома даже не интересуются подрядчиками, пока в полном объеме не обсудят свои потребности и желания и не уточнят все детали. Покупатели понимают, что внесение изменений влечет за собой изменение цены;

им это не нравится, но они это понимают. Однако люди весело ищут оправдания, когда дело касается разработки ПО. Ошибки, допущенные на стадии сбора требо ваний, составляют от 40 до 60% всех дефектов проекта (Davis, 1993;

Leff ing well, 1997). Две наиболее распространенные проблемы, о кото рых сообщается в большом Европейском обзоре индустрии ПО, — оп ределение и управление требованиями заказчика (ESPITI, 1995). Тем не мене многие организации еще применяют неэффективные методы на этих стадиях разработки ПО. Типичный исход — неожидаемые про белы, а также различия между тем, что разработчики собираются строить, и тем, в чем клиенты реально нуждаются.

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

Концепции и приемы, обсуждаемые здесь, применимы к ПО любого вида и к ПО, содержащему элементы, которые вы строите.

Глава 1. Особенности разработки требований к ПО Нигде более, как на стадии сбора требований, так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта.

К заинтересованным в проекте лицам относятся:

1 заказчики, которые финансируют проект или приобретают продукт для решения каких-то бизнес-задач;

I пользователи, которые взаимодействуют напрямую или не напря мую с приложением (подкласс заказчиков);

I аналитики требований, которые пишут требования и передают их разработчикам;

1 разработчики, которые создают, разворачивают и поддерживают продукт;

I тестеры, которые определяют соответствие поведения ПО желае мому;

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

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

I сотрудники правового отдела, которые следят, чтобы продукт не противоречил всем действующим законам и постановлениям;

1 производственники, которые должны построить продукт, содержа щий данное ПО;

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

Хорошо справившись с этой стадией процесса, вы получите отлич ный продукт, восхищенных заказчиков и удовлетворенных разработчи ков. В противном случае вам грозит непонимание, разочарование и разногласия, которые подрывают веру в продукт и его ценность. Так как требования представляют собой основу для действий и разработ чиков и менеджеров проекта, все заинтересованные в проекте лица должны быть вовлечены в создание этого документа.

Но разработка требований и управление ими — трудный процесс!

Здесь нет быстрых или волшебных решений. Однако многие организа ции борются с одними и теми же трудностями, для преодоления ко торых мы можем найти общие приемы, годные в различных ситуациях.

В этой книге описаны дюжины таких приемов. Их рекламируют для по строения абсолютно новых систем, однако они отлично подходят для поддержки проектов и выбора коммерческих готовых решений (см.

главу 16). Не используйте эти приемы только для модели «водопада», Часть I. Требования к продукту;

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

Из этой главы вы узнаете:

i несколько ключевых терминов, применяемых при конструирова нии ПО;

I особенности разработки требований, которые отличают этот про цесс от управления требованиями;

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

I некоторые характеристики великолепных требований.

Держите руку на пульсе Чтоб быстреноко проверить приемы построения требований в вашей организации, спростите себя, как много следующих положений верны для ваших текущих проек тов. Если вы пометите хотя бы три или четыре положения, эта книга для вас.

I Образ и границы проекта никогда не определены ясно.

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

1 Заместители пользователей - менеджеры по продуктам, по разработке, менед жеры пользователей или маркетологи - вызываются говорить от имени клиен тов, но не точно представляют их потребности.

1 Требования существуют только в головах «экспертов», работающих в вашей ор ганизации, и никогда не фиксируются в письменном виде.

I Заказчики настаивают, чтобы критиковались все требования, без учета их при оритетов.

I Разработчики получают двусмысленную и неполую информацию, поэтому при ко дировании им приходится делать предположения.

I Взаимодействие между разработчиками и заказчиками ограничивается внешним видом пользовательского интерфейса и не затрагивает того, что же действитель но клиенты собираются делать с помощью приложения.

1 Ваши заказчики подписывают требования и затем постоянно изменяют их.

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

I Запросы на изменение требований теряются по пути: ни вы, ни ваши клиенты не знают статус каждого запроса.

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

I Технические требования хороши, а вот заказчики нет.

Глава 1. Особенности разработки требований к ПО Оговоренные требования к ПО Одна из проблем, существующих в индустрии программного обеспе чения, — это отсутствие общепринятых определений терминов, кото рыми мы пользуемся для описания нашей работы. Разные эксперты, говоря об одном и том же документе, называют его и требования поль зователя, и требования к ПО, и функциональные требования, и сис темные требования, и технологические требования, и бизнес-требова ния, и требования к продукту. Заказчики зачастую считают, что требо вания -- это развитая концепция продукта, предназначенная для разработчиков. Те, в свою очередь, полагают, что в отношении клиен тов это детальная разработка интерфейса пользователя. Такое много образие ведет к сумятице и раздражающим проблемам коммуникации.

Основной закон: требования должны быть документированы. Одна жды я занимался проектом, который делала опытнейшая команда, од нако ее состав постоянно менялся. Заказчик впал в неистовство, когда к нему пришел еще один аналитик требований и сказал: «Мы должны поговорить о том, что же вам нужно». На что заказчик ответил: «Я уже излагал свои требования. А теперь постройте мне систему!» Дело в том, что никто не документировал собранную информацию, поэтому каждому новому аналитику приходилось начинать с набросков. Пол ный бред объявлять о готовности требований, если на самом деле у вас есть куча электронных писем, голосовых сообщений, записок, про токолов совещаний и неясных воспоминаний о беседах в коридоре.

Особенности интерпретации требований Консультант Brian Lawrence предположил, что требования — это «неч то такое, что приводит к выбору дизайна" (Lawrence, 1997). Многие категории информации попадают в эту категорию. IEEE Standard Glos sary of Software Engineering Terminology (1990) определяет требования как:

1. условия или возможности, необходимые пользователю для реше ния проблем или достижения целей;

2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетво рять стандартам, спецификациям или другим формальным доку ментам;

3. документированное представление условий или возможностей для пунктов 1 и 2.

6 Часть I. Требования к продукту;

что, почему и кто Это определение охватывает требования как пользователей (внеш нее поведение системы), так и разработчиков (некоторые скрытые па раметры). Термин пользователи следует распространить на всех заин тересованных лиц, так как не все, кто заинтересован в проекте — поль зователи. Я думаю о требованиях, как о свойствах, которыми должен обладать продукт, чтобы представлять какую-то ценность для пользо вателей. Следующее определение подтверждает различие типов тре бований (Sommerville и Sawyer, 1997):

Требования... это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут быть ограничены процессом разработки системы.

Ясно, что нет универсального определения требований. Для облег чения восприятия материала необходимо согласовать набор характе ристик, чтобы модифицировать трудный термин требования (require ments), а также оценить ценность их записи в общедоступной форме.

Ловушка Не полагайте, что все лица, заинтересованные в вашем проекте, раз деляют общее представление о том, что же такое требования. Задайте определения авансом, чтобы вы все изначально говорили на одном языке.

Уровни требований В этом разделе приводятся определения, которыми я буду пользо ваться для терминов, наиболее часто применяемых у такой сфере, как разработка требований. Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. 1-1 иллюстрирует способ представления этих типов требований. Как и все модели, она не полная, но схематич но показывает организацию требований. Овалы обозначают типы ин формации для требований, а прямоугольники — способ хранения ин формации (документы, диаграммы, базы данных).

Дополнительная информация В главе 7 приводится множество примеров различных типов требований.

Бизнес-требования (business requirements) содержат высокоуровне вые цели организации или заказчиков системы. Как правило, их выска зывают те, кто финансируют проект, покупатели системы, менеджер ре альных пользователей, отдел маркетинга или «ясновидец» (специалисп Глава 1. Особенности разработки требований к ПО "* по системам машинного зрения). В этом документе объясняется, поче му организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записы вать бизнес-требования в форме документа об образе и границах про екта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document).

Создание такого документа описано в главе 5. Определение границ проекта представляет собой первый этап управление общими пробле мами расползания границ.

Функциональные Нефункциональные Бизнес требования Документ об образе и границах проекта Требования пользователей Атрибуты качества Документ о вариантах использования Внешний интерфейс Системные Функциональные требования требования Спецификация требований к ПО Рис. 1 -1. Взаимосвязи нескольких типов информации для требований Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким обра зом, в этом документе указано, что клиенты смогут делать с помощью системы. Пример варианта использования — «Сделать заказ» для В Часть I. Требования к продукту: что, почему и кто заказа билетов на самолет, аренды автомобиля, заказа гостиницы че рез Интернет.

Глава 8 посвящена требованиям пользователей.

Дополнительная информация Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, что бы пользователи смогли выполнить свои задачи в рамках бизнес-тре бований. Иногда именуемые требованиями поведения (behavioral re quirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользо вателю подтверждение о заказе». Как иллюстрируется в главе 10, функциональные требования описывают, что разработчику необходи мо реализовать.

Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многиэ подсистемы, то есть система (IEEE, 1998с). Говоря о системе, мы под разумеваем программное обеспечение или подсистемы ПО и обору дования. Люди — часть системы, поэтому определенные функции сис темы могут распространяться и на людей.

Однажды моя команда писала ПО для контроля некоторой лаборе торной аппаратуры, которая автоматизировала скучное добавление точного количества вещества в ряд мензурок. Из требований для всей системы мы вывели производные функциональные требования к ПО, чтобы посылать сигналы оборудованию для перемещения распреде ляющих вещество насадок, считывания показаний датчиков положе ния и включения/выключения насоса.

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вь числительные алгоритмы. Как вы увидите в главе 9, бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты ИСПОЛЬЗОВЕ;

ния, или диктовать, какими функциями должна обладать систем;

:!, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхож дение конкретных функциональных требований вплоть до соответс вующих им бизнес-правил.

Глава 1. Особенности разработки требований к ПО Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описы вается так полно, как необходимо, ожидаемое поведение системы. Я буду относиться к спецификации, как к документу, хотя это может быть база данных или крупноформатная таблица с требованиями, хранили ще данных в коммерческом инструменте управления требованиями (см. главу 21) или даже, может быть, куча карточек для небольшого проекта. Спецификация требований к ПО используется при разработ ке, тестировании, гарантии качества продукта, управлении проектом и связанных с проектом функциях.

В дополнение к функциональным требованиям спецификация со держит нефункциональные, где описаны цели и атрибуты качества. Ат рибуты качества (quality attributes) представляют собой дополнитель ное описание функций продукта, выраженное через описание его ха рактеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, лег кость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограниче ния дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта, Люди часто рассуждают о характеристиках продукта. Характеристи ка (feature) — это набор логически связанных функциональных требо ваний, которые обеспечивают возможности пользователя и удовле творяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта. Характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что вхо дят в список необходимых для решения задач пользователей. В каче стве примеров характеристик продуктов можно привести избранные страницы или закладки Web-браузера, контроль за орфографией, за пись макрокоманды, сервопривод стекла в автомобиле, он-лайновое обновление или изменение налогового кодекса, ускоренный набор те лефонного номера или автоматическое определение вируса. Характе ристики могут охватывать множество вариантов использования, и для каждого варианта необходимо, чтобы множество функциональныхтре бований было реализовано для выполнения пользователем его задач.

Чтобы вы лучше восприняли некоторые из различных видов требова ний, я рассмотрю программу подготовки текстов. Бизнес-требование может выглядеть так: «Продукт позволит пользователям исправлять ор Часть I. Требования к продукту: что, почему и кто фографические ошибки в тексте эффективно». На коробке CD-ROM указано, что проверка грамматики включена как характеристика, удов летворяющая бизнес-требования. Соответствующие требования поль зователей могут содержать задачи (варианты использования) вроде та кой: «Найдите орфографическую ошибку» или «Добавьте слово в общий словарь». Проверка грамматики имеет множество индивидуальных функциональных требований, которые связаны с такими операциями, как поиск и выделение слова с ошибкой, отображение диалогового окна с фрагментом текста, где это слово находится, и замена слова с ошиб кой корректным вариантом по всему тексту. Атрибут качества легкость и простота использования (usability) как раз и определяет его значение посредством слова «эффективно» в бизнес-требовниях.

Менеджеры и сотрудники отдела маркетинга определяют бизнес требовния для ПО, которые помогут их компании работать эффектив нее (для информационных систем) или успешно конкурировать Hia рынке (для коммерческих продуктов). Каждое требование пользовате ля должно быть сопоставлено бизнес-требовнию. На основе требова ний пользователя аналитики определяют функции, которые позволят пользователям выполнять их задачи. Разработчикам необходим-.!

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

Хотя в модели на рис. 1-1 показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между тизнес-тр«1 бованиями, требованиями пользователей и функциональными требо ваниями. Кто бы когда бы ни предложил новые характеристики, вари анты использования или функциональные требования, аналитик дол жен спросить;

«Они попадают в указанные границы?» Если ответ «да*, то они соответствуют спецификации. На «нет», как известно, и суда нет. А вот если ответ «нет, но они должны там быть», то заказчик иги тот, кто финансирует проект, должен решить, готов ли он раздвинув границы проекта, чтобы принять новое требование.

Каких требований не должно быть Спецификация требований не содержит деталей дизайна или реали зации (кроме известных ограничений), данных о планировании проек та или сведений о тестировании (Letting well и Widrig, 2000). Удал и-е указанные элементы из требований, чтобы из этого документа было абсолютно ясно, что надлежит построить команде разработчиков. Для проекта, как правило, создаются требования других типов: документ, Глава 1. Особенности разработки требований к ПО где описана среда разработки, ограничения бюджета, руководство пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду. Все это относится к требованиям к про екту, но не к продукту, поэтому они не будут рассмотрены в этой книге Разработка и управление требованиями Путаница, которая возникает, как только речь заходит о требованиях, затрагивает даже то, что именно называть этим словом. Некоторые авторы называют целую область разработкой технических условий (requirements engineering) (Sommerville и Kotonya, 1998);

другие упот ребляют термин управление требованиями (requirements manage ment) {Leffingwell и Widrig, 2000). Я считаю полезным разделить об ласть разработки технических условий на разработку требований (re quirements development) — подробнее об этом в части II этой книги — и управление требованиями (requirements management) — см. часть III как показано на рис. 1 -2.

Область разработки технических условий Извлечение Анализ Документирование Проверка Рис. 1-2. Компоненты области разработки технических условий Разработка требований Далее мы можем подразделить этот этап на извлечение (elicitation), анализ (analysis), документирование (specification) и утверждение (val idation) (Abran и Moore, 2001). В эти подэтапы входят все действия, включающие сбор, оценку и документирование требований для ПО или ПО-содержащих продуктов, в том числе:

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

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

12 Насть I. Требования к продукту: что, почему и кто 1 определение задач и целей пользователей, а также бизнес-целей,с которыми эти задачи связаны;

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

I распределение высокоуровневых требований по компонентам ПС, определенным в системной архитектуре;

I установление относительной важности атрибутов качества;

I установление приоритетов реализации;

I документирование собранной информации и построение моделей;

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

Постепенность процесса — ключ к успеху разработки требований.

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

Управление требованиями Этот этап определяется как «выработка и поддержание взаимного согласия с заказчиками по поводу требований к разрабатываемому ПО» (Paulk и др., 1995). Это соглашение воплощается в спецификации (в письменной форме) и моделях. Одобрение пользователей — только половина дела. Разработчики также должны принять задокументирс ванные требования и высказаться за создание этого продукта. К дейсп виям по управлению требованиями относятся:

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

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

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

I согласование плана проекта с требованиями;

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

1 отслеживание отдельных требований до их дизайна, исходного ко да и вариантов тестирования;

Глава 1. Особенности разработки требований к ПО I отслеживание статуса требований и действий по изменению на протяжении всего проекта.

На рис. 1 -3 показан другой способ разделения областей разработки требований и управления ими. В этой книге описано несколько дюжин специальных приемов для выполнения извлечения требований, их анализа, документации, проверки и управления, Сотрудники отдела маркетинга, заказчики, | менеджеры требования Анализ, докумен тирование, про смотр, обсуждение Разработка требований Управление требованиями текущая отредактирован версия ная версия Сотрудники Окружающая отдела маркетинга, среда проекта заказчики, менеджеры Рис. 1 -3. Разделение областей разработки требований и управления ими Каждый проект имеет требования Frederick Brooks выразительно определил критическую роль требова ний при разработке ПО в классическом эссе (1987) «No Silver Bullet:

Essence and Accidents of Software Engineering»:

Строжайшее и единственное правило построения систем ПО - решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа ра боты не исправляются так трудно.

Часть I, Требования к продукту: что, почему и кто Каждое приложение или содержащая ПО система имеет пользова телей, которые полагаются на нее, как на средство улучшения их жиз ни. Время, которое тратится на выяснение потребностей пользовате лей: представляет собой высокоэффективную инвестицию в успех проекта. Если разработчики не записывают требования, с которыми заказчики уже согласились, как могут они удовлетворить этих заказчи ков? Даже требования к ПО, не предназначенного для коммерческой:

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

Зачастую невозможно полностью определить требования до пред варительного конструирования. В этом случае действуйте итеративно и постепенно: разрабатывайте одну порцию требований за раз, обяза тельно дождитесь ответной реакции заказчика, прежде чем приступат., к следующему циклу. У вас не будет оправдания, если вы начнете пи сать код до того, как просмотрите требования перед следующим ша гом. Итерации при кодировании стоят гораздо дороже, чем при разра ботке концепций.

Люди иногда впустую тратят время, отведенное на написание тре бований, но этот этап не самый сложный. Самое трудное — выявит:., эти требования. Первоначально написание требований представляв собой процесс выяснения, разработки и расшифровки данных. Четкое понимание требований к продукту дает вам уверенность, что ваша ко манда работает над теми проблемами, над которыми нужно, и приду мает лучшее их решение. Требования позволят вам расставить при оритеты в работе и оценить ресурсы, которые понадобятся. Не зна^, что собой представляют требования, вы не сможете определить мо мент окончания проекта, установить, достигнуты ли цели, или выбрать компромиссное решение, когда придется сужать границы проекта.

Никаких предположений в требованиях Я недавно имел дело с группой разработчиков, которая применяла доморощенные инструменты разработки ПО, в том числе и редактор исходного кода. К сожалению, ни один из них не записал, что инструмент должен позволять пользователям печа тать код, хотя пользователи без сомнения предполагали, что это будет именно так.

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

Если вы не записываете даже подразумеваемые и предполагаемые требования, не удивляйтесь, если продукт не будет отвечать ожиданиям пользователей. Перио дически спрашивайте: «Что мы предполагаем?", чтобы постараться извлечь на по верхность эти спрятанные мысли. Если вы заметите какое-то предположение при Глава 1. Особенности разработки требований к ПО 2- обсуждении требований, запишите его и подтвердите его точность. Если вы зани маететесь заменой системы, просмотрите системные характеристики, чтобы выяс нить, действительно ли они необходимы при замещении, а не выносите поспешного решения - да или нет.

Когда плохие требования появляются у хороших людей § исправления ошибок в требованиях Относительная стоимость S & _ _ гаш ё ' Кодирование !

Требования Разработка Тестирование Работа с продуктом Фазы разработки Рис. 1 -4. Относительная стоимость исправления ошибок в требованиях в зависимости от того, когда они обнаружены Основное следствие проблем с требованиями — переделка того, что, как вы думаете, уже готово. На это расходуется от 30 до 50% общего бюджета разработки (Boehm и Papaccio, 1988), а ошибки в требовани ях стоят от 70 до 85% стоимости переделки (Leffingwell, 1997). Как по казано на рис. 1-4, гораздо дороже исправить дефекты, которые най дены позднее в проекте, чем сразу после создания (Grady, 1999). Сле довательно, предотвращение ошибок в требованиях и обнаружение их на ранних стадиях сильно уменьшает объем переделки. Вообразите, насколько изменится ваша жизнь, если вы сократите этот объем напо ловину! Вы сможете построить ПО быстрее или сконструировать боль ший и лучший продукт за о же время и даже иногда будете приходить домой.

Часть I. Требования к продукту: что, почему и кто Дефекты в требованиях представляют собой угрозу успеху проекта, где успех означает выпуск продукта, который удовлетворяет ожидани ям пользователей в качестве и функциональности при соблюдении бюджета и графика проекта. В главе 23 рассказано, как управлять та кими рисками, чтобы предотвратить крушение проекта. Некоторые и;

.

наиболее общих рисков описаны далее в этой главе.

Недостаточное вовлечение пользователей Заказчики зачастую не понимают, почему так важно тщательно со брать требования и обеспечить их качество. Разработчики не всегда придают значение вовлечению пользователей в процесс, из-за того что среди них больше фанатов написания кода, а не любителей во зиться с клиентами или же потому что они считают, что все уже знают и потребностях пользователей. В любом случае трудно добраться дн людей, которые непосредственно будут иметь дело с продуктом, ;

i выразители мнения пользователей не всегда понимают, что тем нужно в реальности. Недостаточное вовлечение пользователей ведет к обна ружению ошибок в требованиях на поздних стадиях проекта, а значит, к задержке завершения проекта. Нет альтернативы сотрудничеству разработчиков непосредственное реальными пользователями на про тяжении всего проекта {см. главу 6).

«Разрастание» требований пользователей Так как требования тщательно прорабатываются и их объем со време нем увеличивается, проект часто выходит за установленные рамки как по срокам, так и по бюджету. Первоначально принятые планы не все гда основаны на реалистичном понимании размера и сложности тре бований, ограничение же на модификацию только усиливает пробле мы. Эти проблемы частично кроются в частых запросах пользователей на изменения, а частично— в том, какими способами разработчика отвечают на них.

Чтобы управлять границами требований, для начала уточните биз нес-цели проекта, основы его образа, рамки, ограничения, критерии успеха и ожидаемую пользу. Оцените, как предполагаемые характери стики или изменения требований отразятся на связанной с ними структуре. Эффективный процесс модификации заставляет интенсив нее работать аналитиков, которые помогут всем заинтересованным лицам принять обдуманные бизнес-решения относительно того, какие изменения следует принять, и увязать их стоимость со временем, ре сурсами или возможными компромиссами. Изменения зачастую кри тически важны для успеха, однако они всегда имеют цену.

Глава 1. Особенности разработки требований к ПО По мере того как продукт модифицируется в процессе разработки, его архитектура может медленно разрушаться. «Заплатки» кода за трудняют понимание и поддержку продукта. Добавление кода может стать причиной нарушения твердых и взаимосвязанных принципов ди зайна и разрыва связей (McConnell, 1993). Чтобы минимизировать возможность потери качества продукта в результате проблем такого рода, вначале протестируйте, как возможные изменения отразятся на архитектуре и дизайне, а уж затем реализуйте их непосредственно в коде.

Двусмысленность требований Двусмысленность — страшилка любой спецификации требований (Lawrence 1996). Один из ее симптомов— пользователь имеет воз можность интерпретировать одно и то же положение по-разному.

Другой — что у нескольких читателей требований возникает разное представление о продукте. В главе 10 указано множество слов и фраз, которые порождают двусмысленность, возлагая ответственность ин терпретации на пользователя. Кроме того, двусмысленность зачастую проистекает из неточности и плохой детализации требований, в ре зультате чего разработчикам приходится заполнять возникающие пробелы собственными силами.

Двусмысленность ведет и к формированию различных ожиданий у заинтересованных лиц. Впоследствии некоторые из них удивляются «Что же это получилось?» Разработчики же впустую тратят время, за нимаясь не теми проблемами. А тестеры готовятся к проверке не тех особенностей поведения системы.

Один из способов обнаружить двусмысленности — пригласить раз личных представителей пользователей для официальной экспертизы требований. (Подробнее об этом рассказано в главе 15.) Пусть они просмотрят документ и выскажут свои замечания. Если они интерпре тируют требования различными способами, но это имеет смысл для каждого из них, то неясность не проявится сейчас, а гораздо позже, когда исправлять ее будет весьма дорого. Другой способ вскрыть двусмысленность — написать вариант тестирования для требования и построить прототип. Cause и Weinberg (1989) описывают и другие методы.

«Золочение» продукта Под «золочением» понимают такие ситуации, когда разработчики до бавляют функции, которых нет в спецификации, но им кажется, что это понравится пользователям. Зачастую же клиентам не нужны такие из 18 Часть I. Требования к продукту: что, почему и кто быточные возможности, получается, что время, отведенное на реали зацию тратится впустую. Прежде чем просто вставлять новые функции, разработчики и аналитики должны представить свои творческие иде^ на суд заказчиков. Задача команды — четко соблюдать требование спецификации, а не действовать за спиной клиентов без одобрения.

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

продукта. Все, что вы захотите добавить, стоит времени и денег, поэто му постарайтесь осознать ценность своевременного выпуска продук та. Чтобы уменьшить «золочение», отслеживайте каждый бит функцио нальности до его первоисточника, чтобы четко понимать, почему именно он включен в продукт. Применение вариантов использования для извлечения требований поможет сосредоточиться на выборе те>:

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

Минимальная спецификация Иногда сотрудников отдела маркетинга или менеджеров охватывав искушение создать урезанный вариант спецификации, как, например набросок концепций продукта на салфетке. Они ожидают, что разра ботчики «нарастят мясо» на основе этих набросков, пока проект разви вается. Это годится для тесно сплоченной команды, которая занима ется небольшой системой, или когда выполняется проект-исследова ние, или когда требования действительно гибкие (McConnell, 1996), Хотя в большинстве случаев это все-таки раздражает разработчиков (которые могут действовать при некорректных предположениях и с ог раниченными инструкциями) и дезориентирует клиентов (которые не:

получат тот продукт, который они воображали).

Пропуск классов пользователей Большинство продуктов предназначены для нескольких групп пользо вателей, которые могут применять различные наборы функций с раз ной частотой и имеют опыт работы с ПО самого широкого диапазона.

Если вы не определили важные классы пользователей для вашего про дукта заранее, некоторые потребности клиентов не будут учтены, После идентификации всех классов удостоверьтесь, что каждый из них имеет голос {см. главу 6).

Глава 1. Особенности разработки требований к ПО 1 ! Небрежное планирование «Я кое-что придумал для нового продукта. Когда вы сможете это сде лать?» Не отвечайте на подобный вопрос, пока больше не узнаете о проблеме. Неопределенные, недетализированные требования порож дают слишком оптимистические оценки: они «выходят боком», когда возникает перерасход. Неподготовленная оценка звучит как обяза тельство для слушателя. При плохо просчитанной смете проект боль ше всего страдает из-за затрат на частые изменения требований, про пущенных требований, недостаточного взаимодействия с пользова телями, недетализированной спецификации требований и плохого анализа (Davis, 1995). Когда вы высказываете оценку, то указывайте либо качественные показатели (лучший вариант, наиболее вероятно, худший вариант), либо количественные, но с учетом вашего личного мнения («Я на 90% уверен, что мы сделаем это за три месяца»).

Выгоды от высококачественного процесса разработки требований Те организации, которые применяют высококачественные процессы разработки требований получают массу преимуществ. Одно из них — уменьшение объема переделок в течение последней стадии разработ ки и на протяжении всего длительного периода обслуживания продук та. Эффективность качественных требований не очевидна, и многие люди ошибочно считают, что время, которое тратится на обсуждение требований, просто отсрочивает выпуск продукта. При завершении проекта становится особо ясной ценность приемов повышения каче ства на ранних стадиях (Wiegers, 1996a).

В удачных процессах создания требований к совместной работе над проектом привлекалось множество заинтересованных лиц, причем на протяжении всего проекта. Сбор требований позволяет команде раз работчиков лучше понять пользователей или реалии рынка, что крити чески важно для любого проекта. Гораздо дешевле понять все особен ности до построения ПО, чем после передачи его в руки пользователей.

Привлечение пользователей к созданию требований порождает восхищение продуктом и верность клиентов. Делая упор на задачи пользователей, а не на внешне привлекательные функции, команда из бежит необходимости переписывать код, который даже не понадобит ся. Вовлечение клиентов в процесс снижает вероятность появления ложных ожиданий, возникающих из-за различия того, в чем пользова 20 Часть I. Требования к продукту: что, почему и кто тели нуждаются, и того, что разработчики выпускают. Подумайте о том, как со временем получать отзывы заказчиков. Причем лучше раньше, чем позже;

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

Кроме того, есть и дополнительные выгоды. Ясное разделение тре бований на те, что относятся к ПО, оборудованию или подсистемам, взаимодействующим с людьми, позволяет применять системный под ход к разработке продукта. Эффективные процессы контроля за изме нениями минимизируют неблагоприятные последствия от изменения требований. Недвусмысленно составленные документы облегчают тес тирование продукта, что в свою очередь повышает шансы создать вь сококачественный продукт, который удовлетворит всех пользователей Никто не станет обещать конкретный возврат инвестиций в процесс улучшения требований. Вы можете мысленно проанализировать, что вы от этого получите. Сначала прикиньте общую сумму вложений. Она складывается из стоимости оценки применяемых сейчас приемов, раз работки новых процедур и документирования шаблонов, тренинга ко манды, покупки книг и инструментов и, возможно, привлечения кон сультантов со стороны. Наибольшая инвестиция — это время, которое ваша команда тратит на сбор, документирование, просмотр и управле ние требованиями. Но теперь подумайте о возможных выгодах, которь, ми вы будете наслаждаться, и о том, сколько времени и денег они вам сэкономят. Невозможно количественно оценить все преимущества, од нако они реальны:

« меньше дефектов в требованиях;

1 меньше переделок;

I меньше ненужных функций;

I ниже стоимость модификации;

I быстрее разработка;

I меньше разобщенности;

I меньше расползания границ;

i меньше беспорядка в проекте;

1 точнее оценки тестирования;

1 выше удовлетворение заказчиков и разработчиков.

Глава 1. Особенности разработки требований к ПО Характеристики превосходных требований Как можно отличить отличную спецификацию требований к ПО от про блематичной? В этом разделе обсуждается несколько характеристик, которым должны отвечать отдельные положения требований, а также соответствующие им черты спецификации в целом (Davis, 1993;

IEEE, 1998b). Лучший способ определить, действительно ли ваши требова ния имеют желаемые атрибуты, — попросить нескольких заинтересо ванных в проекте лиц внимательно просмотреть спецификацию. Они обнаружат различные виды проблем. Так, например, аналитики и раз работчики не могут точно определить полноту или корректность доку мента, тогда как пользователям не удается оценить технические ха рактеристики.

Характеристики отдельных положений спецификации требований В идеальном мире каждый отдельный пользователь, бизнес или функ циональные требования отвечают различным параметрам качества которые и описаны в следующих разделах, Полнота Каждое требование должно полно описывать функциональность, кото рую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем уда лось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструиро ванию этой функции.

Корректность Каждое требование должно точно описывать желаемую функциональ ность. Для соблюдения корректности необходима связь с источника ми требований, например с пожеланиями пользователей или высоко уровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот по чему им или их непосредственным заместителям необходимо предос тавлять требования для просмотра.

Часть I. Требования к продукту;

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

Чтобы не придумывать недостижимые положения, обеспечьте взаимо действие разработчиков с маркетологами и аналитиками требовании на период всего извлечения требований. Разработчики реально оце нят, что можно выполнить технически, а что нет, или что сделать мож но, но при дополнительном финансировании. Инкрементальная раз работка и подтверждающие концепцию прототипы позволяют прове рить осуществимость требования.

Необходимость Каждое требование должно отражать возможность, которая действи тельно необходима пользователям или которая нужна для соответст вия внешним системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения. Отследите каждое требование вплоть до стадии сбора мнений пользователей, когда выявлялись варианты использовании, бизнес-правила или другие источники.

Назначение приоритетов Назначьте приоритеты каждому функциональному требованию, харак теристике или варианту использования, чтобы определить, что необ ходимо для каждой версии продукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки, Дополнительная информация В главе 14 назначение приоритетов обсуждает ся в деталях.

Недвусмысленность Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите доку ментацию просто, кратко и точно, применяя лексику, понятную пользо вателям. «Ясность»— цель качества требований, связанная с точно стью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.

Глава 1. Особенности разработки требований к ПО Проверяемость Попробуйте разработать несколько тестов или примените другие приемы для проверки, например экспертизу или демонстрации, чтобы установить, действительно ли в продукте реализовано каждое требо вание. Если требование не проверяется, вопрос его корректной реа лизации становится предметом заключения, а не целью анализа. Не полные, несогласованные, невыполнимые или двусмысленные требо вания также не проверяются (Drabick 1999).

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

Полнота Никакие требования или необходимые данные не должны быть про пущены.

Согласованность Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, систем ными или бизнес-требованиями. Несогласованность документов сле дует устранить до начала процесса разработки. Вы не всегда знаете, какое именно положение некорректно (если какое-то некорректно), пока не выполните исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен.

Способность к модификации Необходимо обеспечить возможность переработки требований, если понадобится, и поддерживать историю изменений для каждого поло жения. Для этого все они должны быть уникально помечены и обозна чены, чтобы вы могли ссылаться на них однозначно. Каждое требова ние должно быть записано в спецификации только единожды. Иначе вы легко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные ут верждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и ука затель. Сохранение спецификации в базе данных коммерческого инст румента управления требованиями сделает их пригодными для по вторного использования.

24 Часть I. Требования к продукту: что, почему и кто Трассируемость Трассируемость, или возможность для анализа, можно реализовать как в направлении назад, к первоисточникам, так и вперед, к элемен там дизайна и исходному коду, который его реализует, а также к вари антам использования, которые позволяют проверить корректность, реализации. Трассируемые требования помечены соответствующим!' идентификаторами. Они записаны в структурированной, детализиро ванной форме, в противоположность параграфам в длинной повество вательной форме. Избегайте слипания множества требований в один ком, отдельные требования можно трассировать к различным элемен-, там дизайна и кода.

Дополнительная информация В главе 10 обсуждается написание высококаче ственных функциональных требований, а в главе 20 - трассировка.

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

Что теперь?

I Опишите связанные с требованиями проблемы, с которыми вы сталкивались в текущем или предыдущих проектах. Идентифицируйте каждую проблему разра ботки или управления, а также то влияние, которое она оказывает на проект и их основные причины.

I Облегчите обсуждение с членами вашей команды и всеми заинтересованными лицами, записывая проблемы, с которыми вы сталкивались в текущем или пре дыдущих проектах, их влияние и основные причины. Объясните участникам, что они должны противостоять этим трудностям, если когда-нибудь надеются спра виться с ними.

I Организуйте однодневный тренинг, посвященный требованиям, для команды, которая работает над вашим проектом. Пригласите основных заказчиков, марке тологов и менеджеров, используя что угодно, чтоб заманить их всех в одну ком нату. Тренинг представляет собой эффективное средство сплочения команды.

Он позволяет выработать единую лексику и общее понимание эффективных приемов и поведения, чтобы команда смогла решить поставленную перед ней задачу.

Глава 1. Особенности разработки требований к ПО / Требования с точки зрения клиента Герхард, старший менеджер компании Contoso Pharmaceuti cals, встретился с Синтией, новым сотрудником отдела по разработке информационных систем. «Нам нужно создать но вую систему контроля химических препаратов, — начал Гер хард. — Она должна обеспечить контроль за всеми химически ми контейнерами на складе и в лабораториях. Возможно, бла годаря этому химики смогут отказаться от заказа новых контейнеров. Система сэкономит компании уйму денег. Кроме того, отделу контроля безопасности и здравоохранения необходимо отчитываться перед правительством».

"Понимаю, почему этот проект важен, Герхард, —сказала Син тия. — Но прежде чем я набросаю график разработки проекта, нам потребуется собрать некоторые требования к системе".

Герхрад удивился: «Что вы имеете в виду? Я только что пере числил вам требования», «На самом деле вы описали концепцию и некоторые бизнес цели проекта, — объяснила Синтия. — Бизнес-требования та кого высокого уровня не дают достаточно информации, чтобы точно определить, какую систему создавать и сколько време ни на это может потребоваться. Я хочу, чтобы аналитик пора ботал с несколькими пользователями и понял, что они ожида ют от системы. Затем мы определим, какая функциональность удовлетворит одновременно ваши бизнес-цели и потребно сти пользователей. Возможно, вам даже не потребуется новая система, чтобы сэкономить средства».

Герахрд никогда раньше не сталкивался с подобной реакцией специалиста отдела информационных систем. "Химики — за Часть I. Требования к продукту: что, почему и кто пятые люди, — запротестовал он. — Вряд ли у них найдется время объяснить все подробности до того, как вы начнете пи сать программу. Не могут ли ваши люди сами определить кс нечную цель?» Синтия попыталась объяснить, почему необходимо выслушать именно пользователей новой системы. «Если мы сами станем угадывать ожидания пользователей, ничего хорошего не вый дет. Мы — разработчики ПО, а не химики. Нам на самом делэ неизвестно, чего именно хотят специалисты от системы кон троля препаратов. Я по собственному опыту знаю, что, если не потратить время на изучение проблемы до начала программи рования, результаты окажутся неудовлетворительными».

«У нас нет времени на это, — настаивал Герхард. — Я описал вам мои требования. Теперь, пожалуйста, просто создайте систему. Сообщайте мне о ходе работы».

Такие диалоги регулярно возникают при разработке ПО. Клиенты, ко торым требуется новая информационная система, зачастую не пони мают, насколько важно непосредственно опросить будущих реальных пользователей. Специалисты по маркетингу, разработавшие концеп цию нового замечательного продукта, считают, что адекватно пред ставляют интересы предполагаемых покупателей. Тем не менее мне ние непосредственных покупателей ПО неоценимо, и заменить его чем-либо иным нельзя. Согласно некоторым современным концепци ям разработки ПО, например концепции экстремального программи рования (Extreme Programming), клиент, даже если он постоянно занят собственным бизнесом, должен тесно взаимодействовать с командсй разработчиков. Как говорится в одной книге по экстремальному про граммированию, «успех проекта зависит от согласованных действий клиента и программистов» (Jeffries, Anderson и Hendrickson, 2001).

Одна из проблем при формировании требований в том, что люди пу тают разные уровни требований: бизнес-уровень, уровень пользова телей и функциональный. Герхард перечислил несколько преиму ществ, которые, по его мнению, получит компания Contoso, внедрив новую систему контроля химикатов. Однако он не знает требований пользователей, поскольку не работаете этой системой. Пользователе, в свою очередь, могут описать необходимые им возможности систе мы, но не способны грамотно перечислить функции, которые должны реализовать разработчики для предоставления им таких возможно стей.

', Глава 2. Требования с точки зрения клиента В этой главе речь пойдет о взаимодействии клиента и разработчика жизненно важной для успеха проекта по разработке ПО. Я предлагаю вашему вниманию «Билль о правах клиента ПО» и соответствующий «Билль об обязанностях клиента ПО» при формировании требований Таким образом,, я надеюсь прояснить роль клиента, а конкретнее пользователя, в процессе создания требований, Страх отказа Недавно я побывал в отделе информационных систем одной фирмы и услышал пе чальную историю. Разработчики только что создали новую внутрикорпоративную систему. Пользователи с самого начала не хотели общаться с разработчиками, и ко гда те с гордостью представили новую систему, пользователи отвергли ее как со вершенно неприемлемую. Разработчики, приложившие немало усилий, чтобы удов летворить потребности пользователей, как они их понимали, испытали настоящий шок. И что же они предприняли? Да просто все исправили. При несоответствии тре бований систему всегда можно подправить, однако это значительно дороже, чем ес ли бы пользователи описали свои потребности с самого начала.

Безусловно, разработчикам пришлось потратить на доводку проекта больше вре мени и, значит, отложить следующий проект. Это абсолютно проигрышная ситуа ция. Разработчики растеряны и расстроены, клиенты разочарованы, так как система не оправдала их ожиданий, а компания потеряла кучу денег. Когда клиенты с самого начала плотно и постоянно вовлечены в разработку системы, такого неудачного, но, к сожалению, нередкого итога удается избежать.

Кто же клиент?

В широком смысле, клиент— это человек или организация, получаю щая от продукта прямую или косвенную выгоду. Клиентами ПО можно считать заинтересованных в проекте лиц, требующих, оплачивающих, выбирающих, определяющих, использующих и получающих про граммный продукт. Как говорилось в главе 1, прочие заинтересован ные лица — аналитики требований, разработчики, специалисты по тестированию, технические писатели, менеджеры проектов, а также персонал службы поддержки, юридической службы и маркетинговой службы.

Менеджер Герхард — это клиент, оплачивающий, или спонсирую щий, проект по разработке ПО. Клиенты уровня Герхарда определяют бизнес-требования к системе. Они формулируют высокоуровневую концепцию продукта и бизнес-обоснование для его развертывания.

28 Часть I. Требования к продукту: что, почему и кто Как вы узнаете из главы 5, бизнес-требования описывают бизнес-це ли, которых хочет достичь клиент, компания или другие посредники.

Бизнес-требования формируют каркас всего проекта. Любые другие функции и требования к продукту должны удовлетворять бизнес-тре бования. Тем не менее бизнес-требования не предоставляют разра ботчикам достаточно информации для создания продукта.

Следующий уровень требований — требования пользователей: и:< определяют те, кто прямо или косвенно взаимодействуют с продук том, то есть конечные пользователи. Они способны описать требуе мую функциональность, а также ожидаемые качественные характери стики продукта.

Клиенты, предоставляющие бизнес-требования, иногда пытаются говорить от имени пользователей, но обычно они слишком далеки О" реальной работы, чтобы точно описать их нужды. В случае с информа ционными системами или разработкой нестандартного приложени-i бизнес-требования должен определять тот, кто платит, а требования пользователей — те, кто будет стучать по клавишам и непосредствен но работать с продуктом. Всем участникам проекта рекомендуете!

проверить согласованность бизнес-требований и требований пользо вателей.

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

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

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

Представители клиента, например, из отдела маркетинга или менед жеры по продукту, обычно пытаются на свой вкус определить, что кли ент счел бы привлекательным. Тем не менее без конечных пользовате лей сформулировать требования пользователей не удастся (подроб нее — в главе 7). В противном случае будьте готовы читать обзоры >:з журналах, описывающие недостатки вашего продукта, которых уда лось бы избежать при активном участии пользователей.

Неудивительно, что бизнес-требования и требования пользовате лей иногда противоречат друг другу. Бизнес-требования отражают ор ганизационную стратегию или бюджетные ограничения, скрытые от пользователей. Пользователи, разочарованные тем, что менеджмент насильно внедряет новую информационную систему, не всегда хотят общаться с разработчиками ПО, считая последних предвестниками Глава 2. Требования с точки зрения клиента неблагоприятного будущего. Избежать этого помогает ясное и полное обсуждение целей и ограничений проекта. Возможно, действитель ность не удовлетворит никого, но у людей появится возможность по нять и подстроиться под нее. Для сглаживания всех конфликтов анали тику необходимо взаимодействовать с полномочными представителя ми пользователей и менеджеров.

Сотрудничество клиентов и разработчиков Отличные программные продукты — результат правильно реализован ной архитектуры, основанной на требованиях, полученных в результа те эффективного, то есть тесного взаимодействия разработчиков и клиентов. Слишком часто сотрудничество разработчиков и клиентов оборачивается враждой. Напряженность также создают менеджеры, изменяющие требования пользователей по собственному усмотре нию. В этом случае не выигрывает никто.

Совместная работа возможна только тогда, когда все участники процесса разработки знают, что именно необходимо им для успеха, и когда они понимают и уважают стремление их соратников к успеху. Ко гда при работе над проектом нагнетается напряжение, очень легко за быть, что у всех участников единая цель — создать успешный про граммный продукт, ценный для бизнеса и отвечающий чаяниям всех участников проекта, «Билль о правах клиента ПО» {табл. 2-1) содержит 10 положений, на выполнении которых клиенты могут на вполне законных основаниях настаивать при общении с аналитиками и разработчиками на этапе формулирования требований к проекту. Каждый пункт этого права описывает соответствующую ответственность аналитиков и разработ чиков ПО. «Билль об обязанностях клиента ПО» (табл. 2-2), напротив, содержит 10 положений, определяющих ответственность клиента пе ред аналитиком и разработчиком на этапе формулирования требова ний. Возможно, его стоит назвать «Билль о правах разработчика».

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

В процессе планирования проекта клиенту и разработчикам следует изучить оба этих списка и постараться достигнуть взаимопонимания, Часть I. Требования к продукту: что, почему и кто Сильно занятые клиенты, возможно, предпочтут не принимать участия в формулировании требований (то есть попытаются избежать обязан ности № 2). Однако мы знаем, что в этом случае значительно повыша ется риск создания продукта ненадлежащего качества. Убедитесь, что основные участники процесса формулирования требований понимаю г и принимают свои обязанности. В случае затруднений организуйте семинар и обсудите спорные пункты. Это позволит избежать трений позже, когда одна сторона будет ожидать чего-то, что другая не может или не желает предоставить.

Таблица 2-1. Билль о правах клиента ПО при формировании требований Клиент имеет право 1. Иметь дело с аналитиком, который разговаривает на вашем языке 2. Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается система 3. Потребовать, чтобы аналитик преобразовал требования, предоставленные вами устно, в письменную спецификацию требований к программному продукту 4. Получить от аналитика подробный отчет обо всех рабочих продуктах, созданных в процессе формулирования требований 5. На уважительное и профессиональное отношение к вам со стороны аналитиков и разработчиков 6. Знать о вариантах и альтернативах требований и их реализации 7. Описать характеристики, упрощающие работу с продуктом 8. Изменить требования или разрешить использование имеющихся программных компо нентов Э. Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых компромиссах, которые возникают в связи с изменениями в ПО 10. Потребовать, чтобы система функциональностью и качеством удовлетворяла требования заказчика Таблица 2-2. Билль об обязанностях клиента ПО при формировании требований Клиент обязан 1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса 2. Потратить столько времени, сколько необходимо, на объяснение требований 3. Точно и конкретно описать требования к системе 4. Принимать своевременные решения Глава 2. Требования с точки зрения клиента, Таблица 2-2. Билль об обязанностях клиента ПО при формировании требований (продолжение) Клиент обязан 5. Уважать определенную разработчиком оценку стоимости и возможность реализации ваших требований 6. Определять приоритеты требований 7. Просматривать документы с требованиями и оценивать прототипы 8. Своевременно сообщать об изменениях требований 9. Поддерживать принятый в организации-разработчике порядок контроля изменений JO. Уважительно относиться к методам, с помощью которых аналитики создают требования Не предполагайте, что участники проекта интуитивно знают, как со Ловушка трудничать при формулировании требований. Потратьте время и обсудите, каким образом организовать взаимодействие наиболее эффективно.

Билль о правах клиента ПО Право № 1. Иметь дело с аналитиком, который разговаривает на вашем языке При обсуждении требований следует выяснить потребности и задачи вашего бизнеса, используя при этом принятую в вашем бизнесе тер минологию. Заставьте аналитиков говорить с вами на вашем языке (возможно, для этого им следует предоставить небольшой словарь), не продирайтесь в разговорах с ними через компьютерный жаргон.

Право № 2. Иметь дело с аналитиком, который изучил ваш бизнес и цели Выявляя требования, аналитики смогут лучше понять задачи вашего бизнеса и осознать, какое место уготовано создаваемому ПО в вашем бизнесе. Это поможет им удовлетворить ваши ожидания. Пригласите разработчиков и аналитиков к себе в офис. Если заказанная система заменит существующее приложение, предложите разработчикам по работать с ним. Таким образом, им будет легче понять его сильные и слабые стороны и то, как его можно усовершенствовать.

32 Часть I. Требования к продукту: что, почему и кто Право № 3. Потребовать, чтобы аналитик преобразовал требования, предоставленные вами устно, в письменную спецификацию требований к ПО Аналитик отсортирует всю информацию, предоставленную вами и дру гими клиентами, и выявит на основе бизнес-требований, бизнес-пра вил, функциональных требований, целей качества, возможных реше ний и прочих элементов область применения. Конечный итог этогс анализа — спецификация требований к программному обеспечению (software requirements specification, SRS), представляющая собой со глашение между разработчиками и клиентами о функциях, качестве и ограничениях создаваемого продукта. Она должна быть организована и написана так, чтобы вы ее легко поняли. Если вас что-то не устраива ет, выскажите свое мнение: документ должен точно и полно отражать ваши нужды и чаяния.

Право № 4. Получить подробный отчет обо всех рабочих продуктах, созданных в процессе формулирования требований Аналитик может представить требования с помощью различных диа' грамм, дополняющих текст спецификации требований к программном'/ обеспечению. В главе 11 рассматриваются несколько моделей анали' за. Альтернативные представления требований очень важны, поскольку иногда графики позволяют яснее выразить некоторые особенности по ведения системы, например последовательность выполняемых деист вий. И хотя эти диаграммы могут показаться непривычными, понять их несложно. Попросите аналитика объяснить назначение каждой из ни< (а также других продуктов, созданных в процессе формулирования требований), смысл обозначений и процедуру проверки диаграмм н.з предмет ошибок.

Право № 5. На уважительное и профессиональное отношение к вам со стороны аналитиков и разработчиков Если клиенты и разработчики не понимают друг друга, обсуждение требований может обернуться большим разочарованием. Совместная работа позволяет открыть друг другу глаза на проблемы, с которым i сталкивается каждая из этих групп. Клиенты, участвующие в процесса выработки требований, имеют полное право требовать от аналитикою и разработчиков уважительного отношения к себе и бережного отно шения к затраченному времени. В свою очередь, и клиентам следует оказывать уважение разработчикам, ведь они все вместе сотруднича ют для достижения общей цели — успешного проекта.

Глава 2. Требования с точки зрения клиента Право № 6. Знать о вариантах и альтернативах требований и их реализации Чтобы гарантировать, что новая система не будет автоматизировать неэффективные или устаревшие процессы, аналитик должен знать, почему существующие системы не годятся для ваших бизнес-процес сов. Аналитики, основательно разбирающиеся в предметной области бизнеса, иногда предлагают те или иные усовершенствования ваших бизнес-процессов. Полезен и аналитик, творчески подходящий к делу:

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

Право № 7. Описать характеристики, упрощающие работу с продуктом Вполне вероятно, что аналитики спросят вас о характеристиках ПО, выходящих за рамки функциональных потребностей пользователей.

Благодаря им программный продукт становится более удобным в ра боте, что позволяет клиентам эффективнее выполнять их задачи. Ино гда пользователи просят, чтобы продукт был дружественным, надеж ным или эффективным, однако эти термины слишком субъективны, чтобы помочь разработчикам. Поэтому аналитик должен выяснить конкретные характеристики, означающие для вас дружественность, надежность или эффективность. Подробнее — в главе 12.

Право № 8. Изменить требования или разрешить использование имеющихся программных компонентов Отношение к требованиям должны быть гибкими. Аналитику могут быть известны готовые программные компоненты, которые практиче ски полностью удовлетворят некоторые названные вами потребности.

В таком случае вам следует скорректировать отдельные требования, чтобы разработчики могли использовать имеющееся ПО. Разумные возможности применения существующих модулей сэкономит ваши время и деньги. Если вы посчитаете разумным включить в свой про дукт готовые коммерческие компоненты, будьте готовы проявить гиб кость, поскольку характеристики таких компонентов вряд ли будут точ но соответствовать вашим потребностям.

Право № 9. Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых компромиссах, которые возникают в связи с изменениями в ПО Зная: что один вариант дороже другого, разные люди делают разный выбор. Для принятия правильных бизнес-решений необходимы дан Часть I. Требования к продукту: что, почему и кто ные об эффективности и стоимости предполагаемого изменения требований. У вас есть право ожидать от аналитиков добросовестной оценки эффекта, затрат и компромиссов. Разработчики не должны за вышать предполагаемую стоимость изменения только потому, что не хотят его реализовывать.

Право № 10. Потребовать, чтобы система функциональностью и качеством удовлетворяла требования заказчика Такого завершения проекта желают все, однако он возможен, только если вы сумеете донести до разработчиков всю информацию, которая поможет им создать подходящий продукт, и если разработчики четко изложат вам все варианты и ограничения. Убедитесь, что вы высказа ли все свои ожидания и предположения;

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

Билль об обязанностях клиента ПО Обязанность № 1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса Только вы можете полноценно познакомить разработчиков с концеп циями и терминологией своего бизнеса. Вам не надо делать аналити ков экспертами в предметной области, основная задача — помочь им понять ваши проблемы и цели. Не ожидайте, что аналитики постигнет нюансы и неявные особенности бизнеса. Скорее всего у них нет зна ний, воспринимаемых вами и вашими коллегами, как должное. Невы сказанные предположения о таких знаниях могут вызвать проблемы в дальнейшем.

Обязанность № 2. Потратить столько времени, сколько необходимо, на объяснение требований Клиенты — занятые люди, и те, кто участвует в формулировании тре бований — обычно самые занятые из них. Тем не менее вы обязаны потратить время на участие в совещаниях, мозговых штурмах, интер вью и прочих процедурах, необходимых для выявления требований.

Иногда аналитик считает, что понял вашу идею, а позже сообразит, ч~о ему необходимы дополнительные разъяснения. Пожалуйста, терпели во относитесь к такому поэтапному подходу к формулированию и про яснению требований;

это — природа сложного человеческого обще ния и ключ к успеху. Терпимо относитесь к глупым, на ваш взгляд, во просам;

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

Глава 2. Требования с точки зрения клиента Обязанность № 3. Точно и конкретно описать требования к системе Весьма заманчиво оставить требования неопределенными и нечетки ми, ведь прояснять подробности так утомительно и долго. Тем не ме нее на каком-то этапе разработки участникам проекта необходимо устранить все неоднозначности и неточности. Вам, как клиенту, и кар ты в руки. В противном случае угадывать, что же именно вам нужно, будут разработчики.

В спецификации требований к программному обеспечению реко мендуется использовать пометки «TBD» (to be determined — необхо димо определить), указывающие на необходимость дополнительных исследований, анализа и информации. Тем не менее иногда такие мар керы используют в случаях, когда конкретное требование трудно опре делить точно и никто не хочет с ним возиться. Попытайтесь прояснить цель каждого требования, чтобы аналитик мог точно выразить его в спецификации требований к ПО. Если точное определение невозмож но, выработайте совместно процедуру, которая позволит достичь не обходимой ясности. Зачастую в таких случаях применяют метод прототипов — когда вы совместно с разработчиками формулируете требования поэтапно и постепенно.

Обязанность № 4. Принимать своевременные решения Точно так же, как и подрядчик при строительстве дома, аналитик за даст вам множество вопросов и попросит выбрать различные вариан ты и принять решения. Это может быть согласование противоречивых запросов от разных клиентов, выбор между конфликтующими атрибу тами качества и оценка точности информации. Клиенты, обладающие соответствующими полномочиями, должны принять эти решения, ко гда их об этом попросят. Зачастую работа стопорится, так как клиент не может принять окончательного решения, и поэтому, медля с отве том, он затягивает работу над проектом.

Обязанность № 5. Уважать определенную разработчиком оценку стоимости и возможность реализации ваших требований Все программные функции чего-то стоят. Разработчики лучше всего способны оценить эту стоимость, хотя многие из них и не имеют опыта в этом деле. Может оказаться, что некоторые необходимые вам функ ции технически неосуществимы или их реализация слишком дорога, например недостижимая в рабочей среде производительность или доступ к данным, которые системе просто недоступны. Даже если све 36 Часть I. Требования к продукту: что, почему и кто дения об осуществимости и стоимости некоторых функций, сообщен ные разработчиком, вам не понравятся, следует уважать эту оценку.

Иногда требования можно изменить так, что они станут дешевле и достижимее. Например, «мгновенное» выполнение операции реализс вать нельзя, однако вполне по силам задать минимальный временной интервал (скажем, «в пределах 50 миллисекунд»}.

Обязанность № 6. Определять приоритеты требований Лишь при работе над ограниченным кругом задач можно рассчитать время и ресурсы для реализации всей желаемой функциональности, Определить, какие возможности необходимы, какие полезны и без ка ких пользователи обойдутся, — важная составляющая анализа требо ваний. Именно вы определяете эти приоритеты, поскольку разработ чики не в состоянии расставить приоритеты. Чтобы вам облегчить за дачу, разработчики предоставляют информацию о стоимости и рискам всех требований. Определив приоритеты, вы поможете разработчи кам вовремя и с минимальными затратами создать максимально эф фективный продукт.

Обязанность № 7. Просматривать документы с требованиями и оценивать прототипы Как говорится в главе 15, просмотр требований — одна из наиболее значимых операций, обеспечивающих качество ПО. Участие клиентов в таких просмотрах — единственный способ узнать, отражены ли по требности клиента наиболее полно и точно. Если клиенты не уверены <з точности задокументированных требований, им следует как можно раньше сообщить об этом лицам, ответственным за реализацию тре бований, и предложить варианты усовершенствования.

Читая спецификацию требований, не всегда удается четко предста вить работу программы. Чтобы лучше понять потребности клиента и выявить оптимальные способы их удовлетворения, разработчики ино гда создают прототипы предполагаемого продукта. Ваша ответная ре акция на эти предварительные, частичные или пробные версии дает разработчикам необходимую информацию. Поймите, что прототип ни является рабочим продуктом, и не давите на разработчиков.

Обязанность № 8. Своевременно сообщать об изменениях требований Постоянное изменение требований — серьезная угроза для возмож ности своевременной сдачи проекта командой разработчиков. Изме нение неизбежно, но чем позже в ходе разработки о нем сообщается.

Глава 2. Требования с точки зрения клиента тем более сильное влияние оно окажет. Изменения могут стоить доро го, и сроки будут нарушены, если клиент пожелает реализовать в прак тически завершенном проекте новую функциональность. Как только вы решите изменить требования, сразу же сообщите об этом аналити ку, с которым работаете.

Обязанность № 9. Поддерживать принятый в организации-разработчике порядок контроля изменений Для снижения негативного эффекта от изменений выполняйте необхо димые процедуры контроля изменений, определенные в проекте. Это гарантирует, что никакое требование не потеряется, будет проанали зирован эффект каждого изменения и все предполагаемые корректи вы будут согласованы друге другом, Обязанность № 10. Уважительно относиться к методам, с помощью которых аналитики создают требования Сбор и проверка требований — одни из самых трудных задач в раз работке ПО. У всех подходов, применяемых аналитиками, есть ра циональная основа. И хотя операции по созданию требований могут вас разочаровать, время, затраченное, чтобы разобраться в требова ниях, — не пропадет даром. Процесс окажется менее болезненным, если вы разберетесь в методах, используемых аналитиками для соз дания требований. Не стесняйтесь и просите аналитиков объяснить, зачем необходимы те или иные сведения и почему они просят вас по участвовать в некоторых операциях по созданию требований.

Что насчет подписи?

Результатом сотрудничества клиента и разработчика считается согла шение по требованиям к продукту. Многие организации просят клиен та поставить свою подпись на документах с требованиями: это означа ет, что клиент их подтверждает. Все участники процесса утверждения требований должны понимать свою меру ответственности. Подписав документ, клиент не может впоследствии заявить: «Мне дали лист бу маги с моим именем под чертой, и я на этой черте расписался, иначе разработчики не начали бы программировать». Если такой заказчик захочет через некоторое время изменить требования или его не устро ит результат работы, детским лепетом прозвучат слова: «Ну да, я под писал эти требования, но у меня не было времени их читать. Я доверял вам, ребята — и вы меня подвели!» 38 Часть I. Требования к продукту: что, почему и кто Иногда проблему создает менеджер по разработке, он не должен рассматривать подпись как способ сделать требования неизменным!/1, Когда клиент просит о каких-то изменениях, глупо указывать ему н.д спецификацию требований к ПО и протестовать: «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нуж но было что-то другое, следовало сказать об этом раньше».

Реальность такова, что на ранних этапах работы над проектом из вестна лишь часть требований, со временем они меняются. Утвержде • ние требований — вот та самая операция, которая закрывает прение, возникающие в процессе создания требований. Тем не менее участни кам необходимо подтвердить свои слова подписями.

Ловушка Не используйте подпись в качестве оружия. Применяйте ее как завер шение этапа проекта и выработайте четкое коллективное понимание того, как под пись повлияет на возможные в будущем изменения.

Гораздо важнее ритуала подписи концепция создания базовой, или основной версии (baseline) требований — «моментального снимка документа на какой-то момент времени. Текст под подписью на стра нице базовой версии должен звучать примерно так: «Подтверждаю что настоящий документ наилучшим образом представляет наше по нимание требований к этому проекту на данный момент и что описан мая система удовлетворит наши потребности. Я согласен вносить в бу дущем изменения в эту базовую версию в соответствии с процессов изменения требований, определенным в проекте. Я понимаю, что ут вержденные изменения могут потребовать переоценки стоимости, ре сурсов и сроков сдачи проекта». Благодаря этому документу, команда получает возможность контролируемо изменять границы проекта, ана лизируя влияние каждого предполагаемого изменения на сроки сдачи и прочие факторы успеха проекта.

Согласованное понимание значения подписи позволяет избежать прений, возникающих при изменении взглядов на требования, а также при изменении рыночных и бизнес-требований к проекту. Если кли енты боятся, что им не удастся внести коррективы после того, кас утвердят спецификацию требований к ПО, они станут затягивать ут верждение, в результате чего возникает страшная штука — парали1' аналитического процесса. Осмысленный процесс создания базового соглашения о требованиях дает уверенность всем участникам проекта Глава 2. Требования с точки зрения клиента I клиент уверен, что разработчики будут взаимодействовать с ним для создания нужной системы, даже если перед началом работы над проектом они не успели продумать все требования;

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

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

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

Скрепив начальные операции по формулированию требований внешним соглашением, вы сплотите клиентов и разработчиков на пути к успеху проекта.

Что теперь?

I Определите, кто из клиентов предоставит бизнес-требования и пользовательские требования к проекту. Какие пункты «Билля о правах» и «Билля об обязанностях» эти клиенты понимают, принимают и используют на практике, а какие - нет?

I Обсудите «Билль о правах» со своими основными клиентами и узнайте, нет ли у них ощущения бесправности. Обсудите «Билль об обязанностях» и выясните, ка кие из обязанностей клиенты принимают. Измените «Билль о правах» и «Билль об обязанностях» так, чтобы все стороны приняли концепцию дальнейшего со трудничества.

I Если вы участвуете в проекте по разработке ПО в качестве клиента и чувствуете, что ваши права попираются, обсудите это с менеджером проекта или аналити ком требований. Согласитесь выполнять «Билль об обязанностях», это позволит наладить более тесные и дружеские рабочие отношения с программистами.

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

Часть I. Требования к продукту: что, почему и кто 3 Хорошие приемы создания требований Лет десять-пятнадцать назад мне нравились методики разработки программного обеспечения — комплексные наборы моделей и прие мов, рассчитанные на полное решение проектов. Тем не менее сейчас я предпочитаю выявлять и использовать приемы, проверенные практи кой отрасли. Лучший прием на сегодня таков: не разрабатывать не или приобретать полнофункциональное решение, а дополнить имеющийся пакет средств разработчика различными возможностями, позволяю щими решать самые разнообразные проблемы. Даже если вы возьме те на вооружение коммерческую методику, переделайте ее так, чтоб она оптимально соответствовала вашим потребностям, и дополните ее компоненты эффективными приемами из собственного пакета разра ботчика.

Понятие «лучших приемов» довольно спорно: кто решает, что лучше, и на каком основании? Можно создать группу экспертов или исследо вателей и проанализировать проекты различных организаций (Browr, 1996;

Brown, 1999;

Dutta, Lee и Van Wassenhove, 1999). Таким образом вам удастся выявить приемы, которые обычно эффективно применя лись в успешных проектах, а в неудачных — показали себя плохо или но применялись вообще. В процессе работы эксперты согласованно ог ределяют, какие действия неизменно дают превосходный результат обычно их называют лучшими приемами. Подразумевается, что это — высокоэффективные способы, которые при работе над определеннь ми проектами и в определенных ситуациях существенно повышают шансы профессиональных разработчиков ПО на успех.

В табл. 3-1 перечислено приблизительно 50 приемов;

они разделены на 7 категорий. Надеюсь, они помогут разработчикам более эффектив но формулировать требования. Некоторые приемы относятся к несколь ким категориям, но в таблице они указаны только один раз. Приемы годятся не для всех ситуаций, и поэтому не стоит слепо следовать сце нарию, а руководствоваться трезвым расчетом, здравым смыслом и опытом. Заметьте: не все из указанных приемов относятся к лучшим, проверенным практикой отрасли, и именно поэтому глава называется "Хорошие приемы создания требований», а не «Лучшие приемы». Со мневаюсь, что когда-либо будет проведена систематическая оценка всех их на предмет выбора лучшего. Тем не менее многие практики, и я в том числе, считают данные способы эффективными (Sommerville и Sawyer, 1997;

Hofmann и Lehner, 2001). Я кратко описываю каждый спо соб, а также указываю ссылки на другие главы и источники. В заключи тельном разделе главы приведен примерный план формулирования требований — последовательность действий, подходящая для боль шинства проектов по разработке ПО.

Таблица 3-1. Приемы формулирования требований Управление требованиями Управление проектом Обучение Обучите аналитиков Определите процесс Выберите соответствую требований управления изменениями щий цикл разработки проекта Ознакомьте Установите границы для контроля изменений Планируйте на основании представителей требований пользователей Проанализируйте, какое и менеджеров влияние оказывают Своевременно пересма с требованиями изменения тривайте обязательства Обучите разработчиков Определите основную вер- Управляйте рисками, основам предметной касающимися требований сию и управляйте версиями области требований Отслеживайте объем Создайте словарь Отслеживайте хронологию работ по реализации бизнес-терминов требований изменений Отслеживайте состояние Делайте выводы требований из полученного опыта Определите изменяемость требований Используйте утилиту управления требованиями Создайте матрицу связей требований 42 Часть I. Требования к продукту: что, почему и кто Таблица 3-1. Приемы формулирования требований (продолжение} Разработка требований Сбор информации Анализ Спецификации Проверка 1 Определите процесс 1 Нарисуйте кон 1 1i Используйте шаб- 1i Изучите доку формулирования текстную диа- лон спецификации менты с требо грамму требований требований к ПО ваниями i\ 1\ Определите источ- 1i 1 Определите образ и Создайте прото- Протестируйте типы ники требований требования границы проекта 1 Проанализируйте i! Задайте каждому 1!

I Определите классы Определите пользователей осуществимость требованию уни- критерии кальный иденти- приемлемости 11 Расставьте прио 1 Выделите из поль фикатор ритеты зователей ярого для требований 1i Задокументируйте сторонника продукта бизнес-правила 11 Смоделируйте 1 Создайте фокус :

требования группы Укажите атрибуты качества !1 Создайте словарь 1 Определите назна терминов чение продукта 11 Распределите 1 Определите систем требования по ные события подсистемам и реакцию на них 1! Воспользуйтесь 1 Проводите совмест технологией раз ные семинары, вертывания функ упрощающие сбор ций качества требований (Quality Function II Наблюдайте за Deployment) пользователями на рабочих местах 1 Изучите отчеты о проблемах 1 Используйте требо вания многократно Обучение Не все разработчики ПО знают теорию сбора требований. Тем не ме нее на определенном этапе профессиональной деятельности многие из них осваивают обязанности аналитика требований и работают с кли ентами, собирая, анализируя и документируя требования. Однако не разумно ожидать, что все разработчики умеют формулировать требо вания к ПО и общаться с клиентом. Обучение позволяет повысить про фессиональные навыки сотрудников, выполняющих роли аналитикоЕ1;

, Глава 3. Хорошие приемы создания требований но не может компенсировать нехватку навыков межличностного обще ния и отсутствие интереса к делу.

Процесс формулирования требований весьма важен, и поэтому все;

участники проекта должны понимать концепцию и приемы формули рования требований. Эффективный способ создать команду — со брать участников проекта на однодневный семинар, где и обсудить все требования. Стороны смогут глубже понять проблемы, стоящие перед остальными, а также то, что необходимо участникам друг от друга для успеха проекта. Аналогичным образом разработчиков следует просве тить о концепциях и терминологии предметной области. Подробнее об этом — в следующих главах:

I в главе 4 — об обучении аналитиков требований;

I в главе 10 — о создании бизнес-словаря проекта.

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

Квалифицированный аналитик требований терпелив и методичен, об ладает навыками межличностного общения и коммуникативными на выками, сведущ в предметной области и знает множество способов формулирования требований к ПО.

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

Пользователи, которые будут принимать участие в разработке ПО, должны пройти непродолжительный тренинг (один-два дня), чтоб нау читься формулировать требования. Он полезен и для менеджеров по разработке и по работе с клиентами. Обучение поможет понять осо бое значение выделения требований, суть процесса их разработки, а также опасность пренебрежения ими. Посетив мои семинары по тре бованиям, некоторые пользователи замечали, что стали теплее отно ситься к разработчикам ПО.

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

Это уменьшит вероятность путаницы, непонимания и доработок. Мож но также на время проекта назначить каждому разработчику «личного пользователя», который будет разъяснять профессиональные терми ны и бизнес-концепции. Лучше, если это будет настоящий фанат про дукта.

Создание бизнес-словаря. Словарь со специализированными тер минами из предметной области снизит вероятность непонимания, 44 Часть I. Требования к продукту: что, почему и кто Включите в него синонимы, термины, имеющие несколько значений, и термины, имеющие в предметной области и повседневной жизни раз ные значения.

Выявление требований В главе 1 обсуждались три уровня требований: бизнес-уровень, поль зовательский уровень и функциональный. Они собираются из разных источников на различных этапах работы над проектом, имеют различ ные цели и аудиторию и должны документироваться по-разному. Виз нес-требованияне не должны отменять каких-либо значительных поль зовательских требований;

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

Подробнее об этом — в следующих главах:

1 в главе 3 — о процессе формулирования требований;

1 в главе 5 — об определении образа и границ проекта;

I в главе 6 — об определении классов пользователей и иххарактери стик, выборе сторонника продукта из каждого класса пользовате лей, наблюдении за пользователями на рабочих местах;

I в главе 7 — о проведении совместных семинаров;

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

1 в главе 22 — об определении процесса формулирования требо ваний.

Определение процесса формулирования требований. Задоку ментируйте этапы выявления, анализа, определения и проверки тре бований. Наличие инструкций по выполнению ключевых операций по может аналитикам качественно и согласованно выполнить их работу Кроме того, вам будет проще поставить задачи по созданию требова ний и графики, а также продумать необходимые ресурсы.

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

образа проекта позволит всем заинтересованным лицам в общих чер тах понять назначение продукта. Границы проекта определяют, что следует реализовать в этой версии, а что — в следующих. Образ и гра ницы проекта — хорошая база для оценки предлагаемых требований, Образ продукта должен оставаться от версии к версии относительно Глава 3. Хорошие приемы создания требований 4!

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

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

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

Выбор сторонника продукта (product champion) в каждом классе пользователей. Это человек, который сможет точно передавать на строения и нужды клиентов. Он представляет потребности определен ного класса пользователей и принимает решения от их лица. В случае разработки внутрикорпоративных информационных систем, когда все пользователи — ваши коллеги, такого человека выбрать проще. При коммерческой разработке пораспросите клиентов или используйте площадки бета-тестирования. Выбранные вами люди должны прини мать постоянное участие в проекте и обладать полномочиями для при нятия решений, касающихся пользовательских требований.

Создание фокус-групп типичных пользователей. Определите группы типичных пользователей предыдущих версий вашего продукта или похожих. Выясните у них подробности о функциональности и каче ственных характеристиках разрабатываемого продукта. Фокус-группы особенно значимы при разработке коммерческих продуктов, когда приходится иметь дело с большой и разнородной клиентской базой. В отличие от сторонников продукта, у фокус-групп обычно нет полномо чий на принятие решений, Работа с пользователями для выяснения назначения продукта.

Выясните у пользователей, какие задачи им требуется выполнять средствами ПО. Обсудите, как должен клиент взаимодействовать с системой для выполнения каждой такой задачи. Воспользуйтесь стан дартным шаблоном для документирования всех задач и для каждой сформулируйте функциональные требования. Похожий способ, часто применяемый в правительственных проектах, — создать документ с концепциями операций (ConOps), где указаны характеристики новой системы сточки зрения пользователя (IEEE, 1998a).

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

Это могут быть сигналы и данные, получаемые от внешнего оборудо вания, а также временные события, вызывающие ответную реакцию, например ежевечерняя передача данных, генерируемых системой, 46 Часть I. Требования к продукту: что, почему и кто внешнему объекту. В бизнес-приложениях бизнес-события напрямую связаны с задачами.

Проведение совместных семинаров. Совместные семинары по вы явлению требований, где тесно сотрудничают аналитики и клиенты — отличный способ выявить нужды пользователей и составить наброски документов с требованиями (Gottesdiener, 2002). Конкретные примеры таких семинаров — Joint Requirements Planning (JRP — совместное!

планирование требований) (Martin, 1991) и Joint Application Develop ment (JAD — совместная разработка приложений) (Wood и Silver, 1995).

Наблюдение за пользователями на рабочих местах. Наблюдая зл работой пользователей, выявляют контекст потенциального примене ния нового продукта (Beyer и Holtzblatt, 1998). Простые диаграммы ра бочих потоков, а также диаграммы потоков данных позволяют выяс нить, где, как и какие данные задействовал пользователь. Документи руя ход бизнес-процесса, удается определить требования к системе предназначенной для поддержки этого процесса. Иногда даже выяс няется, что для выполнения деловых задач клиентам вовсе и не требу ется новое ПО (McGraw и Harbison, 1997).

Изучение отчетов о проблемах работающих систем с целью по иска новых идей. Поступающие от клиентов отчеты о проблемах и предложения о расширении функциональности — отличный источник:

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

Повторное использование требований в разных проектах. Если необходимая клиенту функциональность аналогична уже реализован ной в другом продукте, подумайте, готовы ли клиенты гибко пересмот реть свои требования для использования существующих компонентов Требования, соответствующие бизнес-правилам компании, можно применить в нескольких проектах. Это требования к безопасности, определяющие порядок доступа к приложениям, и требования, соот ветствующие постановлениям правительства, например Закон о граж данах США с ограниченными возможностями (Americans with Disabi lilies Act).

Анализ требований Анализ требований подразумевает их детализацию, гарантирующую, что требования понимают все заинтересованные лица, а также тща Глава 3. Хорошие приемы создания требований 3- тельное исследование требований на предмет ошибок, пробелов и других недостатков. Кроме того, анализ включает создание прототи пов, анализ осуществимости и согласование приоритетов. Цель ана лиза — достаточно качественно и подробно описать требования, по зволяющие менеджерам реалистично оценить все затраты на проект, а техническому персоналу — начать проектирование, сборку и тести рование.

Зачастую отдельные требования стоит представить несколькими способами, например в текстовой и графической форме. Это позволит выявить их особенности и проблемы, не заметные при представлении одним способом (Davis, 1995). Также это помогает всем заинтересо ванным лицам выработать согласованное представление об итогах разработки продукта. Подробнее об этих темах — в следующих главах:

1 в главе 5 — о создании контекстной диаграммы;

I в главе 10 — о создании словаря данных;

1 в главе 11 — о моделировании требований;

I в главе 13 — о создании пользовательского интерфейса и техниче ских прототипов;

I в главе 14 — об определении приоритетов требований;

1 в главе 17 — о распределении требований по подсистемам.

Создание контекстной диаграммы. Контекстная диаграмма — про стая модель анализа, отображающая место новой системы в соответ ствующей среде. Она определяет границы и интерфейсы между раз рабатываемой системой и сущностями, внешними для этой системы, например пользователями, устройствами и прочими информационны ми системами.

Создание пользовательского интерфейса и технических прото типов. Если разработчики или пользователи не совсем уверены насчет требований, создайте прототип — частичную, возможную или предва рительную версию продукта, которая сделает концепции и возможно сти более осязаемыми. Оценка прототипа поможет всем заинтересо ванным лицам достичь взаимопонимания по решаемой проблеме.

Анализ осуществимости требований. Проанализируйте, насколько реально реализовать каждое требование при разумных затратах и с приемлемой производительностью в предполагаемой среде. Рас смотрите риски, связанные с реализацией каждого требования, вклю чая конфликты с другими требованиями, зависимость от внешних фак торов и препятствия технического характера.

Определение приоритетов требований. Воспользуйтесь аналити ческим подходом и определите относительные приоритеты реализа 48 Часть I. Требования к продукту: что, почему и кто ции функций продукта, решаемых задач или отдельных требований.

На основании приоритетов установите, в какой версии будет реализо вана та или иная функция или набор требований. Подтверждая изме нения, распределите все их по конкретным версиям и включите в план выпуска этих версий затраты, необходимые на внесение изменений.

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

Моделирование требований. В отличие от подробной информации, представленной в спецификации требований к ПО или пользователь ского интерфейса прототипа, графическая модель анализа отобража ет требования на высоком уровне абстракции. Модели позволяют вы явить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность — связь», диаграммы перехода состояний, на зываемые также автоматами (statecharts), карты диалогов, диаграммы классов, диаграммы последовательностей, диаграммы взаимодейст вий, таблицы решений и деревья решений.

Создание словаря терминов. В нем соберите определения всех элементов и структур данных, связанных с системой, что позволяет всем участникам проекта использовать согласованные определения данных. На стадии работы над требованиями словарь должен содер жать определения элементов данных, относящихся к предметной об ласти, чтобы клиентам и разработчикам было проще общаться.

Распределение требований по подсистемам. Требования к слож ному продукту, включающему несколько подсистем, следует сораз мерно распределять между программными, аппаратными и оператор скими подсистемами и компонентами (Nelsen, 1990). Как правило, это осуществляет системный инженер или разработчик.

Применение технологий развертывания функций качества. Тех нология развертывания функций качества {Quality Function Deploy ment, QFD) — точная методика, соотносящая возможности и атрибуты продукта с их значимостью для клиента (Zultner, 1993;

Pardee, 1996).

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

Технология развертывания функций качества рассчитана на три класса требований: ожидаемые, о которых клиент может не упомянуть, но бу дет расстроен, если их не окажется в продукте, обычные требования и отдельные, специальные требования, которые обеспечивают удобство Глава 3. Хорошие приемы создания требований работы клиентам, но отсутствие которых не влечет санкций со стороны клиента.

Спецификации требований Независимо от способа выявления требований, документировать их нужно так, чтоб это обеспечивало удобный доступ и просмотр. Зафик сировать бизнес-требования можно в положении об образе и грани цах проекта. Пользовательские требования обычно представляют в виде вариантов применения или таблиц «событие — реакция». Специ фикация требований содержит подробные функциональные и нефунк циональные требования к ПО. Подробнее о приемах по спецификаци ям к требованиям — в следующих главах:

i в главе 9 — о документировании бизнес-правил;

I в главе 10 — об использовании шаблона спецификации требований к ПО, о присвоении уникальных идентификаторов всем требованиям;

I в главе 12 — об указании атрибутов качества.

Использование шаблона спецификации требований к ПО. Создай те стандартный шаблон для документирования требований к ПО в ва шей организации. Шаблон предоставляет согласованную структуру, позволяющую фиксировать описания нужной функциональности, а так же прочую информацию, касающуюся требований. Вместо того чтобы изобретать новый шаблон, модифицируйте один из существующих в соответствии со спецификой проекта. Многие компании начинают с ис пользования шаблона спецификации требований к ПО, описанного в стандарте IEEE 830-1998 (IEEE, 1998b);

подробнее о работе с ним — в главе 10. Если ваша компания занимается разными проектами, напри мер проектирует новое крупное приложение и параллельно дорабаты вает версии старых программ, создайте соответствующие шаблоны для всех типов проектов. Шаблоны и процессы должны быть масштаби руемыми.

Pages:     || 2 | 3 | 4 | 5 |   ...   | 9 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.