Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

•• Частное требование 2

••• Частное требование нижнего уровня 2.1

••• Частное требование нижнего уровня 2.2

Ниже приводится пример некоторых общих и частных требований, организованных в соответствии с вышеописанной структурой.

• Разработать интерфейс на базе браузера для приложения по обработке заказов.

• Функциональные требования.

•• При размещении заказа:

••• Ввести для каждого заказа следующую информацию (по пунктам).

••• Проверить идентификатор покупателя.

•• Удалить заказ.

•• Проверить статус заказа.

•• Сгенерировать подтверждение заказа.

• Обеспечить поддержку следующих браузеров:

•• Microsoft Internet Explorer версии X.

•• Netscape версии Y.

• Производительность должна быть приемлема для Web-пользователя.

• Требования ко времени реакции системы:

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

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

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

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

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

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

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

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

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

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

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

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

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

• Среда

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

• Интеграция

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

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

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