Команда разработчиков практически никогда не получает совершенной или, по крайней мере, достаточно хорошей спецификации, которую можно использовать в качестве основы для разработки системы. Один из выводов, который из этого следует, состоит в том, что если команде не предоставлены хорошие определения, ее члены должны пойти и добыть их. Другими словами, чтобы добиться успеха, команда разработчиков должна играть гораздо более активную роль в процессе выявления требований.
Количество функций, которое команда может позволить себе рассматривать, существенно влияет на уровень абстракции определения. Для того чтобы справиться со сложностью разрабатываемой системы, рекомендуется описывать возможности каждой новой системы или дополнения к уже существующей системе более абстрактно, чтобы в результате получить не более 25—99 функций. Желательно, чтобы их количество не превышало 50.
При этом относительно небольшой объем информации обеспечивает всестороннюю и полную основу для определения продукта, общения с заказчиками, управления масштабом и проектом. С помощью 25—99 функций, удобным образом разбитых на категории и упорядоченных, можно описывать и обсуждать самые разнообразные системы, будь то космический корабль многоразового использования или программное средство автоматического обнаружения неисправностей. Позже эти функции будут преобразованы в детальные требования, достаточно конкретные, чтобы их можно было реализовать, называемые требованиями к программному обеспечению, или программными требованиями (software requirements). Необходимость в дополнительной конкретизации возникнет позднее. На данном этапе команде достаточно рассуждать на уровне функций.
После того как возможные функции перечислены, можно приступить к принятию решений вида "отложить до следующей версии", "реализовать немедленно", "полностью отвергнуть" или "исследовать дополнительно". Этот процесс принято называть корректировкой масштаба проекта.
Атрибуты функций — элементы данных, которые содержат дополнительную информацию о каждой функции. Атрибуты используются для того, чтобы связать функции или требования с другой информацией проекта. С помощью атрибутов можно отслеживать, задавать приоритет, и управлять функциями, предложенными для реализации.
Присваивая функциям различные атрибуты, можно более успешно управлять сложностью информации. В зависимости от специфики проекта, атрибуты могут быть самыми разнообразными, однако некие общеупотребительные атрибуты применяются в большинстве проектов (табл. 3.6).
Таблица 3.6. Атрибуты функций.
| Атрибут | Описание |
| Статус | Отслеживает ход процесса определения базового уровня проекта и последующей разработки. Функция может иметь статус предлагаемая, утвержденная, включенная. |
| Приоритет / Полезность | Функции не одинаковы по своей важности. Определение относительных приоритетов или полезности для конечного пользователя открывает путь к диалогу между заинтересованными лицами и членами команды разработчиков. Этот атрибут используется при управлении масштабом и определении очередности. Пример: определение функции как критической, важной, полезной. |
| Трудоемкость | Оценка количества командо- или человеко-недель, строк кода или общего уровня трудоемкости помогает определить, что можно, а что нельзя осуществить за определенный период времени. Пример. низкий, средний или высокий уровень трудоемкости. |
| Риск | Вероятность того, что данная функция вызовет нежелательные последствия, такие как увеличение расходов, отставание от графика или даже закрытие проекта. Пример, высокий, средний и низкий уровень риска. |
| Стабильность | Вероятность того, что будет меняться данная функция или ее понимание командой. Используется для того, чтобы помочь при определении приоритетов разработки и выявлении тех элементов, для которых следующим действием должно стать дополнительное исследование. |
| Целевая версия | Указание версии продукта, в которой впервые появится реализация данной функции. Комбинирование этого атрибута с полем статуса дает команде возможность предлагать, записывать и обсуждать различные функции, не принимая их к разработке. |
| Назначение | Во многих проектах функции будут предназначаться "функциональным командам", ответственным за дальнейшую их доработку, написание программных требований, а также, возможно, их реализацию |
| Обоснование | Используется для отслеживания источника запрашиваемой функции. Например, ссылка может указывать на страницу или номер строки спецификации продукта или временной маркер на видеозаписи важного интервью с клиентом. |
