•• Размещение заказа должно занимать менее 3 секунд.

•• Удаление заказа должно занимать менее 6 секунд.

•• Проверка статуса заказа должна занимать менее 4 секунд.

•• Подтверждение заказа должно занимать менее получаса.

• Облегчить использование приложения с помощью новых возможностей:

•• Разрешить заказ нескольких товаров в одном заказе.

•• Разрешить пользователю просмотр его идентификатора покупателя.

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

Определение требований должно быть полным. Рассмотрите все аспекты нового выпуска, даже те, что нельзя свести к набору частных требований. Далее приводится список общих категорий требований, применимый практически ко всем проектам по созданию программ. Я не предлагаю использовать этот список в том виде, в каком он представлен здесь, хотя возможно и такое; однако при составлении собственного списка требований рассмотрите каждую из следующих категорий.

• Задачи и функции проекта

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

• Пользовательский интерфейс

Хотя при работе над пользовательским интерфейсом придётся дать ответ на два важных вопроса: «Как пользователю выполнить действие X?» и «Как должна выглядеть функция Y?», лучше не пытаться формализовать их, так как это слишком затруднит описание, тестирование и реализацию последовательных улучшений. Вместо этого надо разработать визуальную модель приложения с помощью различных методик конструирования прототипов пользовательского интерфейса. Эта модель и будет спецификацией требований к пользовательскому интерфейсу. (Подробнее об этот см. главу 9. Там же я расскажу об эффективных способах формулирования и анализа требований к пользовательскому интерфейсу программного продукта.) При наличии конкретной платформы, технологий или связанных с бизнесом ограничений, влияющих на структуру интерфейса, важно оговорить их заранее.

• Среда

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

• Интеграция

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

• Производительность

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

• Установка

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

• Тестирование

Требования к тестированию продукта могут не только способствовать существенному повышению продуктивности работы, но и принести дополнительные выгоды. Так, если в программе установки предусмотрен режим, не требующий ручного ввода информации, можно будет автоматически устанавливать и тестировать все ежедневные сборки программы. Не исключено, что программный продукт должен будет поддерживать набор API, позволяющих группе, проводящей испытания, читать любые двоичные файлы, используемые или генерируемые приложением. Это позволит сравнивать файлы, полученные в результате нескольких испытаний программы с последовательно изменёнными параметрами. Также можно заставить программу вести протокол внутренних несогласованностей, который будет полезен при диагностике трудно воспроизводимых сбоев в работе программы.

Ещё одна проблема, которую придётся решить, — насколько подробно нужно формулировать требования. Разумеется, в данном случае задача в том, чтобы определение было как можно полнее: чем подробнее описано требование, тем легче следить за ходом его реализации. Чем больше аспектов определено заранее, тем больше параллелизма в работе разработчиков и групп, отвечающих за тестирование, обучение пользователей и выпуск программного продукта, так как тогда им проще понять, какой продукт создаётся. Однако часто подробно документировать требования очень трудно и даже невозможно, так как приходится работать в незнакомых областях (так чаще всего и бывает при работе над программными проектами). Как правило, чтобы понять, что именно пытаются создать участники проекта, приходится изрядно поэкспериментировать и испробовать много новых идей. Бывает и так, что поставленная цель оказывается вовсе недостижима. Ниже я опишу способ, позволяющий согласовать потребности в эксперименте и в документировании требований к проекту.

Недостаточно подробное определение обычно является следствием недостаточного понимания. Если недостающие сведения относятся к маркетингу или другим вопросам бизнеса, то разработчики мало чем помогут — это работа менеджера проекта и менеджера по маркетингу. Однако при нехватке сведений о реализуемых функциях, например, когда неясно, как работает та или иная функция, откуда берётся информация или чего хочет пользователь, можно создать прототип пользовательского интерфейса, иллюстрирующий внешний вид этих функций. Если недостающая информация касается технических возможностей, скажем, может ли программный продукт выполнять те или иные действия, можно провести анализ технической осуществимости, а затем создать прототип. Вот как свести воедино информацию из реального мира, экспериментальную работу и творческий процесс в процесс формулирования требований, прежде чем перейти к планированию (рис. 8-1).