быть связаны и другие требования, конкретизирующие или поясняющие функциональность требований более высокого уровня. В результате документация может принять такой вид:
• Общее требование 1
•• Частное требование 1
••• Частное требование нижнего уровня 1.1
••• Частное требование нижнего уровня 1.2
•• Частное требование 2
••• Частное требование нижнего уровня 2.1
••• Частное требование нижнего уровня 2.2
Ниже приводится пример некоторых общих и частных требований, организованных в соответствии с вышеописанной структурой.
• Разработать интерфейс на базе браузера для приложения по обработке заказов.
• Функциональные требования.
•• При размещении заказа:
••• Ввести для каждого заказа следующую информацию (по пунктам).
••• Проверить идентификатор покупателя.
•• Удалить заказ.
•• Проверить статус заказа.
•• Сгенерировать подтверждение заказа.
• Обеспечить поддержку следующих браузеров:
•• Microsoft Internet Explorer версии X.
•• Netscape версии Y.
• Производительность должна быть приемлема для Web-пользователя.
• Требования ко времени реакции системы:
•• Размещение заказа должно занимать менее 3 секунд.
•• Удаление заказа должно занимать менее 6 секунд.
•• Проверка статуса заказа должна занимать менее 4 секунд.
•• Подтверждение заказа должно занимать менее получаса.
• Облегчить использование приложения с помощью новых возможностей:
•• Разрешить заказ нескольких товаров в одном заказе.
•• Разрешить пользователю просмотр его идентификатора покупателя.
Как видно из этого примера, каждое общее требование включает набор поддерживающих его требований, которые конкретизируют или разъясняют содержание «родительского». Каждое поддерживающее требование сформулировано просто и ясно, что позволяет легко проследить его реализацию в данном выпуске ПО. Следует расширять степень детализации спецификации требований, пока не будут описаны все ключевые элементы функциональности и вы не останетесь довольны созданным описанием.
Определение требований должно быть полным. Рассмотрите все аспекты нового выпуска, даже те, что нельзя свести к набору частных требований. Далее приводится список общих категорий требований, применимый практически ко всем проектам по созданию программ. Я не предлагаю использовать этот список в том виде, в каком он представлен здесь, хотя возможно и такое; однако при составлении собственного списка требований рассмотрите каждую из следующих категорий.
•
Каждый участник должен понять ключевые задачи и функции проекта, прежде чем приступать к работе. Эти задачи и функции составляют сущность программного продукта и будут направлять его разработку, а также работу по тестированию и обучению пользователей.
•
Хотя при работе над пользовательским интерфейсом придётся дать ответ на два важных вопроса: «Как пользователю выполнить действие X?» и «Как должна выглядеть функция Y?», лучше не пытаться формализовать их, так как это слишком затруднит описание, тестирование и реализацию последовательных улучшений. Вместо этого надо разработать визуальную модель приложения с помощью различных методик конструирования прототипов пользовательского интерфейса. Эта модель и будет спецификацией требований к пользовательскому интерфейсу. (Подробнее об этот см. главу 9. Там же я расскажу об эффективных способах формулирования и анализа требований к пользовательскому интерфейсу программного продукта.) При наличии конкретной платформы, технологий или связанных с бизнесом ограничений, влияющих на структуру интерфейса, важно оговорить их заранее.
•
Необходимо описание программной и аппаратной среды, в которой будет работать продукт. В описании должны быть чётко указаны конкретные версии существующего ПО с учётом новых выпусков, которые могут стать доступными к окончанию работы над проектом. Не забывайте о проблемах, связанных с глобализацией: поддержке ОС, местных языков, валют и различий в часовых поясах.
•
Определите потребности, связанные с интеграцией и возможностью взаимодействия с существующими программами и оборудованием. При необходимости интеграции новой программы с существующими решениями, следует указать способ её осуществления и поддерживаемые версии программного и аппаратного обеспечения.
•
Определите ожидаемую производительность продукта. Обозначьте в простом виде значения параметров, которые нужно достигнуть, а также возможные способы измерения этих параметров. Следует подумать и о времени реакции системы в зависимости от типов нагрузки и потребностей пользователей.
•
Уделите внимание установке ПО. В определении требований должны обсуждаться по крайней мере действия, которые должен выполнить пользователь, чтобы установить ПО, а также действия самой программы установки, необходимые для завершения процесса установки. Кроме того, укажите платформы, которые должна поддерживать программа установки.
•
Требования к тестированию продукта могут не только способствовать существенному повышению продуктивности работы, но и принести дополнительные выгоды. Так, если в программе установки предусмотрен режим, не требующий ручного ввода информации, можно будет автоматически устанавливать и тестировать все ежедневные сборки программы. Не исключено, что программный продукт должен будет поддерживать набор API, позволяющих группе, проводящей испытания, читать любые двоичные файлы, используемые или генерируемые приложением. Это позволит сравнивать файлы, полученные в результате нескольких испытаний программы с последовательно изменёнными параметрами. Также можно заставить программу вести протокол внутренних несогласованностей, который будет полезен при диагностике трудно воспроизводимых сбоев в работе программы.
Ещё одна проблема, которую придётся решить, — насколько подробно нужно формулировать требования. Разумеется, в данном случае задача в том, чтобы определение было как можно полнее: чем подробнее описано требование, тем легче следить за ходом его реализации. Чем больше аспектов определено заранее, тем больше параллелизма в работе разработчиков и групп, отвечающих за тестирование, обучение пользователей и выпуск программного продукта, так как тогда им проще понять, какой продукт создаётся. Однако часто подробно документировать требования очень трудно и даже невозможно, так как приходится работать в незнакомых областях (так чаще всего и бывает при работе над программными проектами). Как правило, чтобы понять, что именно пытаются создать участники проекта, приходится изрядно поэкспериментировать и испробовать много новых идей. Бывает и так, что
