Формулирование требований
Формулирование требований
Когда установлено общее видение проекта и достигнуто понимание пользовательских проблем, пора переходить к определению требований. Как сформулировать требования, насколько подробными должны быть формулировки и как ничего не упустить?
Общие и частные требования
Один из лучших способов дать чёткое описание набора требований к проекту — представить его в виде схемы. Самый высокий уровень схемы занимают общие требования. Они объединяют совокупности частных требований, которые, таким образом, можно обсуждать, оценивать, сравнивать и утверждать как единое целое. Нужно иметь возможность анализа общих требований и обладать совершенным пониманием их основных целей. Общих требований не должно быть слишком много, так как каждое в свою очередь генерирует ряд второстепенных требований. Например, в случае компании, которой надо адаптировать имеющееся приложение обработки заказов для работы в Интернете, достаточно пяти общих требований:
• разработать интерфейс на базе браузера;
• повысить производительность до уровня, приемлемого для Web-пользователей;
• организовать рассылку уведомлений о выполнении заказов по электронной почте;
• добавить к программе новые возможности, которые повысят производительность пользователей;
• предусмотреть применение в будущем в качестве клиентской платформы карманных компьютеров.
Каждое общее требование должно подразделяться на несколько частных. С последними могут быть связаны и другие требования, конкретизирующие или поясняющие функциональность требований более высокого уровня. В результате документация может принять такой вид:
• Общее требование 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, позволяющих группе, проводящей испытания, читать любые двоичные файлы, используемые или генерируемые приложением. Это позволит сравнивать файлы, полученные в результате нескольких испытаний программы с последовательно изменёнными параметрами. Также можно заставить программу вести протокол внутренних несогласованностей, который будет полезен при диагностике трудно воспроизводимых сбоев в работе программы.
Детализация требований
Ещё одна проблема, которую придётся решить, — насколько подробно нужно формулировать требования. Разумеется, в данном случае задача в том, чтобы определение было как можно полнее: чем подробнее описано требование, тем легче следить за ходом его реализации. Чем больше аспектов определено заранее, тем больше параллелизма в работе разработчиков и групп, отвечающих за тестирование, обучение пользователей и выпуск программного продукта, так как тогда им проще понять, какой продукт создаётся. Однако часто подробно документировать требования очень трудно и даже невозможно, так как приходится работать в незнакомых областях (так чаще всего и бывает при работе над программными проектами). Как правило, чтобы понять, что именно пытаются создать участники проекта, приходится изрядно поэкспериментировать и испробовать много новых идей. Бывает и так, что поставленная цель оказывается вовсе недостижима. Ниже я опишу способ, позволяющий согласовать потребности в эксперименте и в документировании требований к проекту.
Недостаточно подробное определение обычно является следствием недостаточного понимания. Если недостающие сведения относятся к маркетингу или другим вопросам бизнеса, то разработчики мало чем помогут — это работа менеджера проекта и менеджера по маркетингу. Однако при нехватке сведений о реализуемых функциях, например, когда неясно, как работает та или иная функция, откуда берётся информация или чего хочет пользователь, можно создать прототип пользовательского интерфейса, иллюстрирующий внешний вид этих функций. Если недостающая информация касается технических возможностей, скажем, может ли программный продукт выполнять те или иные действия, можно провести анализ технической осуществимости, а затем создать прототип. Вот как свести воедино информацию из реального мира, экспериментальную работу и творческий процесс в процесс формулирования требований, прежде чем перейти к планированию (рис. 8-1).
Главная идея в том, чтобы заранее выяснить места возможного риска и до начала работы над проектом разработать решения потенциальных проблем. Анализ осуществимости и прототипы пользовательского интерфейса помогут понять суть проблемы, оценить потребности и снизить общий риск. Эти методики обеспечивают процесс формулирования требований обратной связью с внешним миром и позволяют составлять более детальные планы.
Рис. 8-1. Связь между требованиями, практичностью и созданием прототипа.
О базовых методиках анализа технического риска и создания прототипов пользовательского интерфейса, а также их использование для формулирования оптимальных требований см. главы 9 и 10.