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

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

Ниже описаны четыре категории требований.

• «Опережающие» и «догоняющие» требования

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

Разделение требований на категории «опережающих» и «догоняющих» позволяет проанализировать конкурентоспособность вашей программы. Например, если выяснилось, что в программе реализовано слишком мало опережающих требований или их вообще нет, можно реализовать дополнительные опережающие требования. Стратегия разработки программ в NuMega всегда включает ряд особенностей, которые делают программу уникальной на рынке и позволяют ей стать или остаться, так сказать, «чемпионом породы».

• Перспективные и ретроспективные требования

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

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

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

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

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

Рис. 8-2. Набор требований, представленный в виде таблицы из четырёх ячеек.