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

Интересно, что, говоря о своих потребностях или требованиях к новой системе, заинтересованные лица, как правило, описывают их не так, как в приведенных выше высказываниях. Они часто называют вам не свою реальную потребность ("Если я не повышу производительность этого отдела, то не получу премию за этот год" или "Я хочу иметь возможность затормозить эту машину как можно быстрее без пробуксовки") и не реальное требование к системе ("Я должен снизить время обработки ввода заказов на покутив на 50 процентов" или "Автомобиль должен иметь систему компьютерного контроля для каждого колеса"). Вместо этого они описывают некую абстракцию, что-то вроде "Мне нужен новый экран на основе GUI для ввода заказов на покупку" или "Я хочу, чтобы машина была оснащена антиблокировочной тормозной системой".

Мы называем эти высокоуровневые выражения желаемого поведения системы функциями (features) продукта или системы. Эти функции часто не очень хорошо определены и могут даже противоречить друг другу. "Я хочу увеличить скорость обработки заказов" и "Я хочу обеспечить более дружественный пользователю интерфейс, чтобы помочь нашим новым служащим изучить систему", но так или иначе они являются отражением реальных потребностей.

Что происходит при обсуждении? Пользователь уже преобразовал реальную потребность (производительность или безопасность) в поведение системы, которое, по его мнению, будет служить реальной потребности (рис. 8.1). При этом что ("Мне нужно"' незаметно заменилось на как ("что, по моему мнению, должна делать система, чтобы удовлетворить данную потребность"). Это неплохо, так как он имеет реальный опыт в данной предметной области и реальное понимание значения функции. Кроме того, такие функции легко обсуждать и документировать на обычном языке, а также объяснять их другим, что существенно обогащает схему требований.

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

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

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

Рис. 8.1. Требования и функции тесно взаимосвязаны

Ранее мы определили функцию следующим образом.

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

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

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

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

Таблица 8.1. Примеры функций