2014-02-13
492
Планирование нового продукта не производится в чисто технической среде без учета бизнес - соображений. Необходимо подумать о целевых рынках, оформлении продукта, каналах распределения, функциональных возможностях, затратах на маркетинг, доступности ресурсов, прибыли, возможности возмещения затрат путем продажи большого количества копий и т.д.
Эти соображения следует задокументировать; но они не являются частью спецификаций требований. Некоторые организации используют документ требований маркетинга (marketing requirements document, MRD), чтобы упростить общение между руководством, службой маркетинга и разработчиками и помочь и принятии разумных бизнес -решений, в том числе самого важного решения "делать, не делать". МRD также предоставляет заказчикам н разработчикам возможность очень ранней верификации взаимодействия, что способствует пониманию продукта в его наиболее общем виде и определению общего масштаба продукта. МRD отвечает на следующие вопросы.
• Кто является заказчиком?
• Кто является пользователем?
• На каких рынках предполагается продавать продукт?
• Как поделены эти рынки?
• Различаются ли требования пользователей в различных сегментах рынка?
• Какие классы пользователей существуют?
• Какие потребности удовлетворяет продукт?
• Что это за продукт?
• В чем заключаются основные преимущества продукта; почему его будут покупать?
• Что собой представляют конкуренты?
• Что отличает продукт от конкурирующих продуктов?
• В какой среде будет использоваться система?
• Какими будут затраты на разработку?
• По какой цене предполагается продавать продукт?
• Как будет осуществляться инсталляция, дистрибуция и сопровождение продукта?
Рабочий пример
В главе 6 мы провели некие действия по разбиению системы HOLIS (системы автоматического домашнего освещения) на подсистемы. К настоящему моменту мы не так уж много знаем о HOLIS, но все же этого, вероятно, достаточно, чтобы предпринять первую попытку организовать имеющуюся информацию о требованиях. На рис. 16.5 показано, что команда при описании требований к системе HOLIS использует следующие элементы.
Рис. 16,5. Организация информации о требованиях к системе HOLIS
• Документ-концепция, который содержит краткосрочные и долгосрочные концепции HOLIS в том числе основные требования системного уровня и предлагаемые функции.
• Модель прецедентов системного уровня, которая содержит прецеденты, с помощью которых различные акторы системы взаимодействуют с HOLIS.
• После некоторых дебатов команда приняла решение документировать требования к аппаратным компонентам (размер, вес, мощность, упаковка) всех трех подсистем системы HOLIS в единой спецификации требований к аппаратному обеспечению.
• Так как в каждой из подсистем HOLIS достаточно много программного обеспечения, команда решила разработать для каждой из трех подсистем отдельную спецификацию требований к программному обеспечению, а также модель прецедентов, отражающую, как каждая подсистема взаимодействует с различными акторами.
Дальнейшую разработку данных артефактов требований можно будет наблюдать при продолжении изучения рабочего примера в последующих главах. Их образцы приводятся в приложении А.
