Веб-дизайн

Функциональные спецификации

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

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

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

Будьте позитивны. Вместо описания плохого или непра­вильного поведения системы опишите ее действия, предот­вращающие нежелательный поворот событий. Например, вместо

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

Лучше написать

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

Будьте конкретны. Только оставив как можно меньше пу­тей для неправильной интерпретации требований, мы смо­жем определить, выполнены ли эти требования.

Сравните эти примеры.

1. Сайт будет доступен людям с ограниченными физиче­скими возможностями.

2. Сайт будет удовлетворять Разделу 508 Акта о людях с ограниченными возможностями.

Навскидку первый пример производит впечатление четко сформулированного требования, но даже без глубокого анализа видно, какие пробелы он содержит. Что значит «доступен»? Если все картинки на сайте сопровождаются текстовыми описаниями, этого достаточно? Кто считается человеком с ограниченными физическими возможностя­ми? Если на сайте не воспроизводится звук, значит ли это, что сайт доступен для глухих?

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

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

Вот очень субъективное утверждение:

Стиль сайта будет броским и ярким.

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

Сказанное не означает, что невозможно потребовать от сай­та броскости. Вам просто нужно сформулировать крите­рии оценки:

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

Уэйн никаким образом не участвует в проекте, но спонсор проекта полагается на его представления о том, что явля­ется броским. Будем надеяться, что эти представления не расходятся с мнением пользователей. Однако требования остаются довольно произвольными, поскольку мы полага­емся на суждение Уэйна, а не на объективно сформулиро­ванные критерии. Возможно, лучше всего будет такое тре­бование:

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

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

Мы также можем устранить субъективность, сформулиро­вав некоторые требования в количественных терминах. Подобно тому как метрики успешности делают измеримы­ми стратегические цели, формулировка требований в коли­чественных терминах поможет нам понять, удовлетворены ли эти требования. Например, вместо утверждения, что система должна иметь «высокую производительность», следует потребовать, чтобы она была в состоянии одновре­менно обслужить не менее 1000 пользователей. Если у ко­нечного продукта поле со счетчиком пользователей будет трехзначным, мы скажем, что требование не выполнено.