Глава 8 Функции продукта или системы

Глава 8
Функции продукта или системы
Основные положения
Команда разработчиков должна играть более активную роль в выявлении
требований к системе.
Функции системы или продукта являются высокоуровневым выражением
желаемого поведения системы.
Количество функций системы должно находиться в пределах 25–99; предпочтительно, чтобы оно не пр
евышало 50.
Атрибуты обеспечивают дополнительную информ
ацию о функции.
В предыдущих главах мы описали ряд проблем, приводящих к тому, что команда разработчиков практически никогда не получает совершенной или, по крайней мере, достаточно хорошей спецификации, которую можно использовать в качестве основы для разработки системы. Один из выводов, который из этого следует, состоит в том, что если
нам не дают хороших определений, мы должны сами пойти и добыть их. Другими словами, чтобы добиться успеха, команда разработчиков должна играть гораздо более активную роль в процессе выявления требований. Мы увидим, что хотя и можно возложить основную часть этой ответственности на руководителя, аналитика или менеджера продукта, в конечном итоге вся команда удет
б
вовлечена в тот или иной этап данного процесса.
Потребности заинтересованных лиц
и пользователей
Очевидно, что команда разработчиков может создать хорошую систему только в том
случае, если она понимает реальные потребности заинтересованных лиц. Эта информация необходима команде для принятия правильных решений при определении и реализации системы. Совокупность исходных данных, которые мы называем потребностями заинтересованных лиц или пользователей,
представляет собой критически важный фрагмент соб
ираемой картины.
потребности
Зачастую эти потребности пользователя будут неоднозначными и размытыми. Заказчик может сказать: “Мне нужны простые способы, позволяющие узнать
состояние моих складских запасов” или “Мне бы хотелось, чтобы существенно возросла
производительность ввода заказов на покупку”. Но, несмотря на нечеткость формулировки, именно эти высказывания создают основу для всех последующих действий. Раз они
106
Часть 2. Понимание потребностей пользователей
так важны, мы направим свои усилия на то, чтобы как следует понять их. Мы определим
потребность заинтересованного лица следующимбразом.
о
Отражение некой личной, рабочей или бизнес-проблемы (или возможности), решение которой оправдывает замысел, покупку или использование новой системы.
Функции
Интересно, что, говоря о своих потребностях или требованиях к новой системе, заинтересованные лица, как правило, описывают их не так, как в приведенных выше высказываниях. Они часто называют вам не свою реальную потребность (“Если я не повышу производительность этого отдела, то не получу премию за этот год” или “Я хочу иметь
возможность затормозить эту машину как можно быстрее без пробуксовки”) и не реальное требование к системе (“Я должен снизить время обработки ввода заказов на покупку
на 50 процентов” или “Автомобиль должен иметь систему компьютерного контроля для
каждого колеса”). Вместо этого они описывают некую абстракцию, что-то вроде “Мне
нужен новый экран на основе GUI для ввода заказов на покупку” или “Я хочу, чтобы машина была оснащена антиблокировочной то
рмозной системой”.
Мы называем эти высокоуровневые выражения желаемого поведения системы функциями (features) продукта или системы. Эти функции часто не очень хорошо определены
и могут даже противоречить друг другу. “Я хочу увеличить скорость обработки заказов” и
“Я хочу обеспечить более дружественный пользователю интерфейс, чтобы помочь нашим новым служащим изучить систему”, но так или иначе они являются отражением реальных потребностей.
Что происходит при обсуждении? Пользователь уже преобразовал реальную потребность (производительность или безопасность) в поведение системы, которое, по его
мнению, будет служить реальной потребности (рис. 8.1). При этом что (“Мне нужно”)
незаметно заменилось на как (“что, по моему мнению, должна делать система, чтобы
удовлетворить данную потребность”). Это неплохо, так как он имеет реальный опыт в
данной предметной области и реальное понимание значения функции. Кроме того, такие
функции легко обсуждать и документировать на обычном языке, а также объяснять их
другим, что существенно обогащает схему треб
ований.
Использование функций — удобный способ описания возможностей без
лишних подробностей.
Но такой подход имеет недостаток. Если команда при обсуждении не поймет, какая
потребность стоит за функцией, это может привести к неприятным последствиям. Если
по какой-либо причине функция не служит реальной потребности, то система может потерпеть неудачу в удовлетворении целей пользователя, несмотря на то что в ней будет
реализована запрашиваемая фун
кция.
Тем не менее мы считаем этот высокий уровень абстракции, эти функции, весьма полезным и удобным способом описания функциональных возможностей новой системы
без излишних подробностей. Данные функции будут служить основой нашей деятельности по разработке требований.
Глава 8. Функции продукта или системы
107
Потребность?
Потребности
Функции
Функция?
Программные требования
Область решения
Рис. 8.1. Требования и функции тесно взаим
освязаны
Ранее мы определили функцию следующим образом.
Обслуживание, предоставляемое системой для выполнения одной или нескольких
потребностей заказчика.
В таком определении описываемые пользователями функции не могут быть столь уж далеки от их потребностей, так что у нас есть удобный способ, чтобы начать определять систему.
Основным при понимании нужд пользователя является выявление и организация потребностей и функций предлагаемой системы. Иногда мы будем получать все потребности и ни одной функции, а в других случаях нам будут указаны все функции и ни одной потребности. Порой мы не сможем отделить их друг от друга. Но, помня о различии между ними, мы в любом
случае должны выделять информацию о том, что система должна делать.
Функции легко описать на обычном языке. Их описания состоят из коротких фраз
(табл. 8.1), лишь изредка функции разрабатываются более подробно. Они представляют
собой очень полезные конструкции для управления масштабом продукта на ранних этапах взаимных согласований и поиска компромиссов. Формулировка функций не требует
значительных инвестиций; их легко описать и пер
ечислить.
Таблица 8.1. Примеры функций
Прикладная область
Пример функции
Система управления элеватором
Осуществляемое вручную управление дверью
при угрозе пожара
Система управления запасами
Предоставлять свежую информацию о состоянии всех инвентарных единиц
Система обнаружения неисправностей
Обеспечивать текущие данные для оценки качества продукции
108
Часть 2. Понимание потребностей пользователей
Окончание табл. 8.1
Прикладная область
Пример функции
Система обработки платежных ведомостей
Сообщать текущие начисления по категориям
Автоматическая система домашнего освещения (HOLIS)
Установка специального режима на период
длительного отсутствия
Система контроля вооружений
Требуется, как минимум, две независимые
конфигурации авторизации для запуска
Готовое приложение
Совместимость с Windows2000
Управление сложностью путем выбора уровня абстракции
Систему произвольной сложности можно определить с помощью списка
из 25–99 функций.
Количество функций, которое мы позволяем себе рассматривать, будет существенно
влиять на уровень абстракции определения. Для того чтобы справиться со сложностью
разрабатываемой системы, мы рекомендуем описывать возможности каждой новой системы
или дополнения к уже существующей системе как можно более абстрактно, чтобы в результате
получить не более 25–99 функций, причем желательно, чтобы их число не превышало 50.
При этом относительно небольшой объем информации обеспечивает всестороннюю
и полную основу для определения продукта, общения с заказчиками, управления масштабом и проектом. С помощью 25–99 функций, удобным образом разбитых на категории и
упорядоченных, мы сможем описывать и обсуждать самые разнообразные системы, будь
то космический корабль многоразового использования или программное средство
(например, автоматическое обнаружение неисправностей). В части 5 эти функции будут
преобразованы в детальные требования, достаточно конкретные, чтобы их можно было
реализовать. Мы будем называть их требованиями к программному обеспечению, или программными требованиями (software requirements), в отличие от высокоуровневых функций.
Необходимость в дополнительной конкретизации возникнет позднее. На данном этапе
нам достаточно рассуждать на уровне функций.
После того как возможные функции перечислены, можно приступить к принятию
решений вида “отложить до следующей версии”, “реализовать немедленно”, “полностью
отвергнуть” или “исследовать дополнительно”. Этот процесс корректировки масштаба
лучше проводить на уровне функций, а не на уровне требований, иначе можно просто
увязнуть в деталях. Мы рассмотрим проблему масштаба более подробно в части 4,
“Управление масштабом”.
Атрибуты функций продукта
Чтобы было легче оперировать этой информацией, мы будем рассматривать атрибуты функций — элементы данных, которые обеспечивают дополнительную информацию
о каждой функции. Атрибуты используются для того, чтобы связать функции или требования с другой информацией проекта. С помощью атрибутов можно отслеживать функции (имя или уникальный идентификатор, состояние, исторические данные, распределен из, трассируется к и т.д.), задавать их приоритет (поле приоритета), а также управ-
Глава 8. Функции продукта или системы
109
лять (статус) функциями, предложенными для реализации. Например, атрибут приоритет можно использовать для хранения результатов накопительного голосования во время “мозгового штурма”; атрибут номер версии — для фиксации конкретной версии программного обеспечения, в которой предпол
агается реализовать данную функцию.
Присваивая функциям различные атрибуты, можно более успешно управлять сложностью информации. Хотя атрибуты могут быть самыми разнообразными, опыт свидетельствует, что существуют некие общеупотребительные атрибуты, которые применяются в большинстве проектов (табл. 8.2). Далее в данной книге мы будем использовать эти
атрибуты при работе с функциями и требованиями, а также отношениями между различными типами системных требований.
Таблица 8.2. Атрибуты функций
Атрибут
Описание
Статус
Отслеживает ход процесса определения базового уровня проекта и
последующей разработки. Пример: функция может иметь статус
предлагаемая, утвержденная, включенная
Приоритет/Полезность
Функции не одинаковы по своей важности. Определение относительных приоритетов или полезности для конечного пользователя
открывает путь к диалогу между заинтересованными лицами и членами команды разработчиков. Этот атрибут используется при
управлении масштабом и определении очередности. Пример: определение функции как критической, важной, полезной
Трудоемкость
Оценка количества командо- или человеко-недель, строк кода или
общего уровня трудоемкости помогает определить, что можно, а
что нельзя осуществить за определенный период времени. Пример:
низкий, средний или высокий уровень трудоемкости
Риск
Вероятность того, что данная функция вызовет нежелательные последствия, такие как увеличение расходов, отставание от графика или даже
закрытие проекта. Пример: высокий, средний и низкий уровень риска
Стабильность
Вероятность того, что будет меняться данная функция или ее понимание командой. Используется для того, чтобы помочь при определении
приоритетов разработки и выявлении тех элементов, для которых следующим действием должно стать дополнительное исследование
Целевая версия
Указание версии продукта, в которой впервые появится реализация
данной функции. Комбинирование этого атрибута с полем статуса
дает команде возможность предлагать, записывать и обсуждать различные функции, не принимая их к разработке
Назначение
Во многих проектах функции будут предназначаться “функциональным
командам”, ответственным за дальнейшую их доработку, написание
программных требований, а также, возможно, их реализацию
Обоснование
Используется для отслеживания источника запрашиваемой функции. Например, ссылка может указывать на страницу или номер
строки спецификации продукта или временной маркер на видеозаписи важного интервью с клиентом.
Итак, давайте перейдем к некоторым профессиональным приемам, которые помогут
нам получить необходимую информацию. Начнем с интервьюирования (глава 9).
110
Часть 2. Понимание потребностей пользователей