Типичные заинтересованные стороны и их цели:
• Финансисты, которые желают знать, может ли проект быть завершен в пределах отведенного времени и ресурсов.
• Архитекторы, разработчики и тестеры, для которых сначала важна фаза исходного строительства, а позднее – фазы сопровождения и развития.
• Руководители проектов, которые должны организовывать группы и планировать этапы.
• Специалисты по маркетингу, использующие качественные требования для описания отличий системы от разработок конкурентов.
• Пользователи: конечные пользователи, системные администраторы и люди, занимающиеся установкой, развертыванием, техническим обеспечением и настройкой системы.
• Персонал технической поддержки, для которого важно количество и сложность обращений в их службу.
У каждой системы существуют свои качественные требования. Некоторые из них (такие как производительность, безопасность и масштабируемость) могут иметь четкое формальное определение, но другие, часто не менее важные (например, способность к изменениям, простота сопровождения и удобство использования), невозможно определить достаточно четко, чтобы от этого была хоть какая-нибудь польза. Не правда ли, странно: заинтересованные стороны желают реализовывать функции в программном коде, а не в оборудовании, чтобы при необходимости их можно было легко и быстро изменить, а потом едва упоминают возможность внесения изменений в формулировках качественных требований? От архитектурных решений зависит то, какие изменения будут вноситься легко и быстро, а какие потребуют времени и значительных затрат. Так разве не должен архитектор понимать ожидания своих клиентов в отношении таких качеств, как «способность к изменениям», так же хорошо, как он понимает функциональные требования?
Related posts: