Карл Вигерс и Джой Битти

Разработка

требований

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

обеспечению

Издание третье, дополненное

2014

УДК 004.738.5

ББК 32.973.202

В41

Вигерс Карл, Битти Джой

В41 Разработка требований к программному обеспечению. 3-е изд., дополненное /

Пер. с англ. — М. : Издательство «Русская редакция» ; СПб. : БХВ-Петербург,

2014. — 736 стр. : ил.

ISBN 978-5-7502-0433-5 («Русская редакция») ISBN 978-5-9775-3348-5 («БХВ-Петербург») Эта книга — подробное руководство по разработке качественных требований к программному обеспечению. Здесь описаны десятки проверенных на практике приемов выявления, формулирования, разработки, проверки, утверждения и тестирования требований, которые помогут разработчикам, менеджерам и маркетологам создать эффективное ПО. Настоящее издание дополнено новыми приемами, посвященными разработке требований в проектах гибкой разработки (agile).

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

Книга состоит из 32 глав, 3 приложений и словаря терминов.

УДК 004.738. ББК 32.973. Microsoft, а также содержание списка, расположенного по адресу: http://www.microsoft.com/about/legal/en/us/ IntellectualProperty/Trademarks/EN-US.aspx являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все другие товарные знаки являются собственностью соответствующих фирм. Все адреса, названия компаний, организаций и продуктов, а также имена лиц, используемые в примерах, вымышлены и не имеют никакого отношения к реальным компаниям, организациям, продуктам и лицам.

© 2013, Translation Russian Edition Publishers.

Authorized Russian translation of the English edition of Software Requirements, Third Edition, ISBN 978-0-7356Karl Wiegers and Seilevel.

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

© 2014, перевод ООО «Издательство «Русская редакция».

Авторизованный перевод с английского на русский язык произведения Software Requirements, Third Edition, ISBN 978-0-7356-7966-5 © Karl Wiegers and Seilevel.

Этот перевод оригинального издания публикуется и продается с разрешения O’Reilly Media, Inc., которая владеет или распоряжается всеми правами на его публикацию и продажу.

© 2014, оформление и подготовка к изданию, ООО «Издательство «Русская редакция», издательство «БХВПетербург».

Вигерс Карл, Битти Джой Разработка требований к программному обеспечению Издание третье, дополненное Совместный проект издательства «Русская редакция» и издательства «БХВ-Петербург».

Подписано в печать 21.04.2014 г. Формат 70х100/16.

Усл. физ. л. 46. Тираж 1500 экз. Заказ № Первая Академическая типография «Наука», 199034, Санкт-Петербург, 9 линия, 12/ Оглавление Введение

ЧАСТЬ I Требования к ПО: что, почему и кто

Глава 1 Основы разработки требований к ПО

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

Особенности интерпретации требований

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

Три уровня требований

Требования к продукту и требования к проекту

Разработка и управление требованиями

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

Управление требованиями

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

Когда плохие требования появляются у хороших людей

Недостаточное вовлечение пользователей

Небрежное планирование

«Разрастание» требований пользователей

Двусмысленные требования

Требования-«бантики»

Пропущенные классы пользователей

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

Глава 2 Требования с точки зрения клиента

Разрыв ожиданий

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

Сотрудничество клиентов и разработчиков

Билль о правах клиента ПО

Билль об обязанностях клиента ПО

Создание культуры уважения к требованиям

Определение ответственных за принятие решений

Достижение соглашения о требованиях

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

Что если не удается достичь соглашения?

Согласование требований в проектах гибкой разработки

Глава 3 Рекомендуемые приемы формулирования требований........... Каркас процесса создания требований

Выявление требований

Анализ требований

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

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

Управление требованиями

Обучение

VI Оглавление Управление проектом

Начинаем применять новые приемы

Глава 4 Бизнес-аналитик

Роль бизнес-аналитика

Задачи аналитика

Навыки, необходимые аналитику

Знания, необходимые аналитику

Становление аналитика

Бывший пользователь

Бывший разработчик или тестировщик

Бывший (или текущий) менеджер проекта

Специалист предметной области

Молодой специалист

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

Создание дружной команды

ЧАСТЬ II Разработка требований

Глава 5 Определение бизнес-требований

Формулировка бизнес-требований

Определение требуемых бизнес-преимуществ

Концепция продукта и границы проекта

Противоречивые бизнес-требования

Документ о концепции и границах

1. Бизнес-требования

2. Рамки и ограничения проекта

3. Бизнес-контекст

Способы представления границ проекта

Контекстная диаграмма

Карта экосистемы

Дерево функций

Список событий

Не упускайте границы из вида

Использование бизнес-целей для принятия решений о границах проекта

Оценка эффекта от изменения границ проекта

Концепция и границы в проектах гибкой разработки

Применение бизнес-целей для определения момента завершения проекта......... Глава 6 Как отобрать пользователей для работы над проектом........ Классы пользователей

Классификация пользователей

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

Архетипы пользователей

Представители пользователей

Сторонник продукта

Сторонники продукта, приглашенные со стороны

Чего следует ожидать от сторонника продукта

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

Как «продать» идею о необходимости привлечения сторонника продукта

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

Разрешение противоречивых требований

Глава 7 Выявление требований

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

Интервью

Семинары

Фокус-группы

Наблюдение

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

Анализ системных интерфейсов

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

Анализ документов

Планирование выявления требований в проекте

Подготовка к выявлению требований

Выявление требований

Действия после выявления требований

Организация и рассылка протоколов

Документирование открытых проблем

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

Как понять, что сбор требований завершен

Несколько советов о том, как собирать информацию

Подразумеваемые и неявные требования

Поиск упущенных требований

Глава 8 Как понять требования пользователей

Варианты использования и сценарии использования

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

Варианты использования и сценарии использования

Предварительные и выходные условия

Определение вариантов использования

Анализ вариантов использования

Проверка вариантов использования

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

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

Преимущества требований, основанных на вариантах использования............ Глава 9 Игра по правилам

Классификация бизнес-правил

Факты

Ограничения

Активаторы операций

Выводы

Вычисления

Атомарные бизнес-правила

Документирование бизнес-правил

Выявление бизнес-правил

Бизнес-правила и требования

Сводим все воедино

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

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

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

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

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

1. Введение

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

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

4. Требования к данным

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

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

7. Требования по интернационализации и локализации

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

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

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

Спецификация требований в проектах гибкой разработки

Глава 11 Пишем идеальные требования

Характеристики превосходных требований

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

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

Системная или пользовательская точка зрения

Язык и стиль

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

Способы представления

Предотвращение неопределенности

Предотвращение неполноты

Примеры требований: до и после

Глава 12 Лучше один раз увидеть, чем 1024 раза услышать............... Моделирование требований

От желания клиента к модели анализа

Выбор правильного представления

Диаграмма потоков данных

Диаграммы swimlane

Диаграмма переходов состояний и таблица состояний

Карта диалоговых окон

Таблицы и деревья решений

Таблицы событий и реакций

Несколько слов об UML-диаграммах

Моделирование в проектах гибкой разработки

Последнее напоминание

Глава 13 Определение требований к данным

Моделирование отношений данных

Словарь данных

Анализ данных

Спецификация отчетов

Сбор требований к отчетности

Особенности определения отчетов

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

Панели мониторинга

Глава 14 Обратная сторона функциональности: атрибуты качества ПО.. Атрибуты качества ПО

Изучение атрибутов качества

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

Внешние атрибуты качества

Внутренние атрибуты качества

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

Реализация требований к атрибутам качества

Ограничения

Атрибуты качества в проектах гибкой разработки

Глава 15 Прототипы как средство снижения риска

Что такое прототип и для чего он нужен

Модели и экспериментальные образцы

Одноразовые и эволюционные прототипы

Бумажные и электронные прототипы

Работа с прототипами

Оценка прототипа

Риски создания прототипов

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

Отвлечение на детали

Нереалистичные ожидания производительности

Слишком много усилий на создание прототипов

Факторы успеха использования прототипов

Глава 16 Сначала о главном: определение приоритетов требований.... Зачем определять приоритеты требований

Некоторые практические соображения определения приоритетов

Игры, в которые люди играют с приоритетами

Некоторые приемы определения приоритетов

Включать или не включать

Попарное сравнение и ранжирование

Трехуровневая шкала приоритетов

Схема классификации приоритетов MoSCoW

100 долларов

Определение приоритетов на основе ценности, стоимости и риска.................. Глава 17 Утверждение требований

Утверждение и верификация

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

Процесс экспертизы

Контрольные списки дефектов

Советы по рецензированию требований

Сложности рецензирования требований

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

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

Утверждение требований с применением критериев приемки

Критерии приемки

Приемочные тесты

Глава 18 Повторное использование требований

Зачем нужно повторное использование требований?

Виды повторного использования требований

Объем повторного использования

Объем изменений

Механизм повторного использования

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

Популярные сценарии повторного использования

Семейства продуктов

Реинжиниринг и замена системы

Другие возможности повторного использования

Схемы требований

Средства, облегчающие повторное использование

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

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

Факторы успеха повторного использования

Глава 19 От разработки требований — к следующим этапам............. Оценка объема работ по реализации требований

От требований — к планам проекта

Оценка размера проекта и объема усилий на основе требований................ Требования и график

От требований — к дизайну и коду

Архитектура и выделение ресурсов

Дизайн ПО

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

От требований — к тестированию

От требований — к успеху

ЧАСТЬ III Требования в проектах определенных классов

Глава 20 Проекты гибкой разработки (agile)

Ограничения водопадной модели

Гибкий подход к разработке

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

Вовлечение клиентов

Подробнее о документации

Резерв проекта и расстановка приоритетов

Планирование времени

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

Расчет на неизбежные изменения

Адаптация приемов работы с требованиями для проектов гибкой разработки...... Переход к гибкой разработке: что дальше?

Глава 21 Проекты по доработке или замене систем

Ожидаемые затруднения

Работа с требованиями при наличии существующей системы

Расстановка приоритетов на основе бизнес-целей

Осторожно с пробелами

Сохранение уровня производительности

Когда старых версий требований нет

Какие требования нужно определять

Как собирать требования к существующей системе

Продвижение новой системы

Уместны ли итерации

Глава 22 Проекты с серийным продуктом

Требования к выбору тиражируемых решений

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

Работа с бизнес-правилами

Определение потребностей в данных

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

Оценка решений

Требования к внедрению серийных решений

Требования к конфигурированию

Требования по интеграции

Требования по расширению

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

Изменение бизнес-процессов

Обычные сложности с пакетными решениями

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

Взаимодействие заказчика и подрядчика

Управление изменениями

Критерии приемки

Глава 24 Проекты автоматизации бизнес-процессов

Моделирование бизнес-процессов

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

Проектирование в первую очередь будущих процессов

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

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

Глава 25 Проекты бизнес-аналитики

Общие сведения о проектах бизнес-аналитики

Разработка требований в проектах бизнес-аналитики

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

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

Определение потребностей в данных

Определение аналитических операций преобразования данных................. Эволюционная природа аналитики

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

Моделирование систем реального времени

Контекстная диаграмма

Диаграмма переходов состояний

XII Оглавление Таблица событий и реакций

Архитектурная диаграмма

Создание прототипов

Интерфейсы

Требования к временным характеристикам

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

Проблемы встроенных систем

ЧАСТЬ IV Управление требованиями

Глава 27 Приемы управления требованиями к ПО

Процесс управления требованиями

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

Управление версиями требований

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

Отслеживание состояния требований

Разрешение проблем с требованиями

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

Почему нужно управлять требованиями

Глава 28 Изменения случаются

Почему нужно управлять требованиями

Управление незапланированным ростом объема

Политика управления изменениями

Основные понятия процесса управления изменениями

Описание процесса управления изменениями

1. Назначение и границы

2. Роли и ответственность

3. Состояние запроса на изменение

4. Входные критерии

5. Задачи

6. Выходные критерии

7. Отчет о состоянии контроля изменений

Приложение. Атрибуты запросов на изменение

Совет по управлению изменениями

Состав совета по управлению изменениями

Устав совета по управлению изменениями

Пересмотр обязательств

Средства управления изменениями

Измерение активности изменений

Анализ влияния изменений

Процедура анализа влияния изменения

Шаблон отчета об анализе влияния изменения

Управление изменениями в проектах гибкой разработки

Глава 29 Связи в цепи требований

Отслеживание связей требований

Мотивация для отслеживаемости требований

Матрица отслеживаемости требований

Средства отслеживания требований

Процедура отслеживания требований

Осуществимость и необходимость отслеживания требований

Глава 30 Инструментальные средства разработки требований.......... Средства разработки требований

Средства выявления требований

Средства создания прототипов

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

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

Преимущества использования средств управления требованиями............. Возможности средств управления требованиями

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

Выбор инструментального средства

Настройка средств и процессов

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

ЧАСТЬ V Реализация процесса построения требований

Глава 31 Совершенствование процессов работы с требованиями.... Как требования связаны с другими составляющими проекта

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

Как добиться готовности к изменениям

Основы совершенствования процессов разработки ПО

Анализ первопричин

Цикл совершенствования технологических процессов

Оценка текущих приемов

Планирование действий по совершенствованию

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

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

Документы процесса разработки требований

Документы процесса управления требованиями

Достигнута ли цель?

Дорожная карта совершенствования работы с требованиями

Глава 32 Требования к ПО и управление рисками

Основы управления рисками при создании ПО

Составляющие управления рисками

Документирование рисков проекта

Планирование управления рисками

Риск, связанный с требованиями

Выявление требований

Анализ требований

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

Утверждение требований

Управление требованиями

Управление рисками — ваш друг

Приложение А

Приложение Б

Приложение В

Словарь терминов

Об авторах

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

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

• признание бизнес-анализа профессиональной дисциплиной и расширение профессиональной сертификации и организаций, таких как International Institute of Business Analysis и International Requirements Engineering Board;

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

• распространение методов гибкой разработки (agile) и развитие приемов работы с требованиями в проектах гибкой разработки;

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

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

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

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

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

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

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

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

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

• повысить удовлетворенность клиентов;

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

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

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

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

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

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

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

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

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

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

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

XVIII Введение Примеры из практики Методы, описанные в книге, мы иллюстрируем примерами, за основу которых взяты реальные проекты, это касается и информационной системы среднего размера под названием Chemical Tracking System. Не волнуйтесь — чтобы разобраться в этом проекте, знание химии вам не потребуется. Диалоги участников проектов из примеров разбавляют текст книги. Думаю, вне зависимости от того, что за ПО разрабатывает ваша команда, вы найдете эти диалоги интересными и полезными.

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

Чтобы облегчить вам применение новых знаний на практике, каждую главу я заканчиваю разделом «Что дальше?», где перечислены конкретные действия, которые вы можете выполнить в отношении реального проекта. В разных главах есть шаблоны документов для определения требования, контрольные списки проверки, таблица приоритетов требований, описание процесса «изменение-контроль», а также полезные вещи для многих других процессов. Все это можно загрузить с веб-сайта этой книги по адресу: http://aka.ms/ SoftwareReq3E/files.

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

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

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

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

Часть I Требования к ПО: что, почему и кто Глава 1 Основы разработки требований к ПО

Глава 2 Требования с точки зрения клиента

Глава 3 Рекомендуемые приемы формулирования требований......... Глава 4 Бизнес-аналитик

Глава Основы разработки требований к ПО «Привет, Фил, это Мария из отдела персонала. У нас проблема с системой управления персоналом, которую вы разрабатывали для нас. Одна из сотрудниц изменила имя на Спаркл Старлайт, а система не принимает это изменение. Ты можешь помочь?»

«Она вышла замуж за парня по имени Старлайт?»

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

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

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

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

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

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

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

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

Масса проблем с ПО возникает из-за несовершенства способов, которые люди применяют для сбора, документирования, согласования и модификации требований к ПО. Как в случае с Филом и Марией, проблемы могут возникать из-за неформального сбора информации, предполагаемой функциональности, ошибочных или несогласованных предположений, недостаточно определенных требований и бессистемного изменения процесса. Многие исследования показывают, что на ошибки, внесенные на этапе сбора требований, приходится от 40 до 50% всех дефектов, обнаруженных в программном продукте (Davis, 2005). Некорректные сведения от пользователей и недостатки определения и управления требованиями клиентов — основные причины провалов проектов. Но невзирая на эти сведения многие организации все еще применяют неэффективные методы сбора требований.

Нигде более, как на стадии сбора требований так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта. (Подробнее о заинтересованных лицах см. главу 2.) К заинтересованным в проекте лицам относятся клиенты, пользователи, бизнес-аналитики, разработчики и многие другие. Хорошо справившись с этой стадией процесса, вы получите отличный продукт, восхищенных заказчиков и удовлетворенных разработчиков.

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

Но разработка требований и управление ими — трудный процесс! Здесь нет быстрых или волшебных решений. Однако многие организации борются с одними и теми же трудностями, для преодоления которых мы можем найти общие приемы, годные в различных ситуациях. В этой книге описаны десятки таких приемов. Их рекламируют как средства построения абсолютно новых систем, однако они отлично подходят для улучшения, замены и реинжиниринга проектов (см. главу 21) и выбора коммерческих готовых решений (см. главу 22). Командам, которые выбирают итеративный процесс, следуя методике гибкой разработки (agile), необходимо знать, что же делать на каждом этапе (см. главу 20).

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

• разобраться с ключевыми терминами, применяемыми при сборе требований к ПО;

• различать требования к продукту и к проекту;

• различать требования по разработке и управлению;

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

Внимание! Мы используем термины «система», «продукт», «приложение» и «решение» для определения любого вида ПО или содержащего ПО компонента, который создается для внутрикорпоративного использования, на продажу или по заказу.

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

• Бизнес-цели, концепция и границы вашего проекта никогда четко не определялись.

• У клиентов никогда не хватало времени на работу над требованиями с аналитиками или разработчиками.

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

• Клиенты считают все требования критически важными, поэтому они не разбивают их по приоритетам.

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

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

• Ваши клиенты никогда не одобряли требования.

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

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

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

• Клиенты запросили определенную функциональность и разработчики реализовали ее, но никто ее не использует.

• В конце проекта спецификация была выполнена, но бизнес-задачи не были выполнены, и клиент не удовлетворен.

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

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

Консультант Брайан Лоренс предположил, что требования — это «нечто такое, что определяет выбор дизайна» (Lawrence, 1997). Это неплохое неформальное определение, потому что в эту категорию можно отнести много видов информации. И, в конце концов, весь смысл разработки требований заключается в принятии соответствующих проектировочных решений, которые в конечном итоге должны удовлетворить клиента. Другое определение требования заключается в том, что продукт должен обеспечивать выгоду заинтересованному лицу. Тоже неплохо, но не очень точно. Наше любимое определение сформулировано Иеном Соммервиллем и Питом Сойером (Ian Sommerville и Pete Sawyer, 1997):

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

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

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

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

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

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

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

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

Табл. 1-1. Информация о некоторых типах требований Бизнес-требование Высокоуровневая бизнес-цель организации или заказчиков системы Бизнес-правило Политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. По своей сути это не требование к ПО, но оно Ограничение Ограничение на выбор вариантов, доступных разработчику Внешнее требование Описание взаимодействия между ПО и пользователем, к интерфейсу другой программной системой или устройством Характеристика Одна или несколько логически связанных возможностей Функциональное Описание требуемого поведения системы в определенных Нефункциональное Описание свойства или особенности, которым должна требование обладать система, или ограничение, которое должна соблюдать система Атрибут качества Вид нефункционального требования, описывающего характеристику сервиса или производительности продукта Системное Требование верхнего уровня к продукту, состоящему требование из многих подсистем, которые могут представлять собой Пользовательское Задача, которую определенные классы пользователей требование должны иметь возможность выполнять в системе, или Требования к ПО состоят из трех уровней — бизнес-требования, пользовательские и функциональные требования. Вдобавок в каждой системе есть свои нефункциональные требования. Модель на рис. 1-1 иллюстрирует способ представления этих типов требований. Как гласит знаменитое высказывание статистика Джорджа Е. П. Бокса (George E. P. Box), «В конечном счете все модели врут, но некоторые оказываются полезными» (Box и Draper, 1987). Это, конечно же, применимо к рис. 1-1. Как и все модели, она не полная, но схематично показывает организацию требований.

Документ концепции и границ Документ пользовательских требований Рис. 1-1. Взаимосвязи нескольких типов информации для требований. Сплошные линии означают «содержатся в», а пунктирные — «являются отправной точкой» или «влияют на»

Внимание! Хотя мы в этой книге и называем требования «документами», как на рис. 1-1, это не обязательно традиционные бумажные или электронные документы. Их можно считать просто контейнерами, в которых хранится знание о требованиях. Такой контейнер может быть традиционным документом или же электронной таблицей, набором диаграмм, базой данных, средством управления требованиями или сочетанием всех этих артефактов. Для удобства мы будем называть документом любой такой контейнер. Мы предоставим шаблоны, которые определяют типы информации, которые стоит хранить в каждой из таких группировок независимо от того, в какой форме они хранятся. Как называть такие артефакты не так важно, как добиться согласия в компании относительно их имен, какие виды информации в них содержатся, а также как эта информация организована.

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

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