Функциональные требования определенно должны занимать большую часть документа. После того как будет разрисована схема информационных потоков, разработчик получает общее представление о разбиении системы на модули. Чем проще разбиваются функциональные возможности на определенные фрагменты, тем проще функциональные требования поддаются группировке. Автором было написано множество технических требований к Web-приложениям, которые являются существенным моментом при создании хранилищ данных. Этот подход заключается в том, чтобы каждому основному объекту данных посвящался отдельный раздел. Приложение управления проектом может иметь набор описаний проектов, набор пользователей и набор комментариев. Каждый из них должен иметь раздел функциональных требований с перечислением, во-первых, всей хранимой информации и, во-вторых способов ее обработки.
С другой стороны, требования к эффективности создаваемой системы накладывают ограничения на функциональность. Может потребоваться обозначить минимальную конфигурацию браузера, необходимую для работы с Web-узом. Максимальные веса страниц являются хорошей идеей. Если клиент требует, чтобы использовалась определенная технология, то это должно быть отражено в этом разделе. Неплохо предварительно знать, что, работая с PHP, вам потребуется работать с СУБД Oracle и Web-сервером Internet Information Server на платформе Windows XP.
В разделе, посвященном обработке исключительных ситуаций, описывается реакция системы на нештатные ситуации, например сбои и ошибочный ввод. Обсудим, что происходит в том случае, если Web-сервер внезапно возгорится. Необходимо приять решение о частоте проведения резервного копирования (раз в час, раз в день или раз в неделю). Кроме того, необходимо предусмотреть работу с пользователями, которые вводят ошибочную информацию. Например, необходимо определить, как поступает система в случае, когда пользователь не ввел название города: она просит пользователя нажать клавишу возврата или повторно отображает форму с заполненными полями, но пропущенные поля должны быть отмечены красной звездочкой.
Если у клиента есть свои соображения по поводу очередности ввода в строй определенных функций, это тоже необходимо документально зафиксировать. Опыт показывает, что в случае жестких сроков заказчик начинает торговаться о том, какие функции должны быть запущены в первую очередь. Другие требования могут быть не такими существенными для системы, и заказчик может согласиться подождать еще. Если есть какие-то пожелания по этому вопросу, очень важно, чтобы проектировщик и разработчики знали об этом заблаговременно.
Предполагаемые доработки будут в далеком будущем. Заказчик может быть не готов к разработке Web-узла электронной коммерции на миллион долларов прямо сейчас, но может захотеть добавить какие-то функциональные возможности через год. Вероятно, что нет никакого смысла использовать дорогую базу данных для хранения каталога на 50 товаров, но использование мощной базы с прицелом на дальнейшее его расширение может оказаться достаточно уместным.
Последней частью спецификации требований является набор указаний по проек­тированию. Они заключаются в требованиях разработчика технического задания к просчетам, допускаемым при программировании. Такой материал может быть изложен в виде суммирования личного опыта аналогичного проектирования или предложения метода проектирования.