Концепция эксплуатации должна ответить на ряд вопросов пользователя.
• Что требуется от системы с функциональной точки зрения?
• Какие основные и второстепенные функции должна выполнять система?
• Что ограничивает ее возможности?
• Что пользователи ценят в ожидаемом продукте?
• Когда необходимо построить и поставить систему?
• Каков запланированный жизненный цикл системы?
• Какова предполагаемая стоимость жизненного цикла системы?
• Где предполагается использовать систему?
Наличие четко определенной концепции эксплуатации является ключевым исходным основанием для успеха системы. Нельзя начинать работу с ожиданиями, что можно спроектировать что-то сейчас, а исправить позже.
Далее начинается процесс формирования из системных требований верхнего уровня набора требований к системе в терминах, понятных разработчикам. Следует изложить, что должна делать новая система, и насколько хорошо она должна это делать. Заявленные требования предоставляются заказчиками систем, например, через часто используемые запросы контрактных предложений (RFP) и рабочие задания (SOW). Эти требования обычно формулируются на языке заказчика, зачастую в виде пожеланий. Требования заказчика недостаточны для проектирования системы. Обычно они неполные, нечетко сформулированные, а иногда и противоречивы по своему характеру. Системные требования должны быть собраны, отфильтрованы, уточнены, декомпозированы и задокументированы. Для этапа разработки необходим полный, технически обоснованный и точный набор системных требований, которые необходимо реализовать.
Требования являются ключом к успеху проекта. Хорошие требования к системе или продукту должны быть:
• Специфичны, должны отражать только один аспект конструкции или характеристик системы. Кроме того, должны быть выражены в терминах потребности (что и как хорошо), а не решений (как).
• Измеримы, характеристика выражается объективно и количественно, может быть проверена при испытании.
• Достижимы, технически реализуемы при доступных затратах, параметры элементов должны соответствовать законам физики и современным технологиям.
• Прослеживаемы, требования нижнего дочернего уровня должны четко вытекать из требований более высокого родительского уровня. Требования, не имеющие «родителей», должны быть оценены для необходимости включения на данный уровень.
Чтобы сформировать хорошие требования к системе, сначала нужно обратиться к заинтересованным сторонам. Это пользователи системы, операторы и специалисты по обслуживанию системы. Кроме того, это люди, которые косвенно влияют на пользователей системы, администраторы, вспомогательный персонал и разработчики системы. В обсуждениях с заинтересованными сторонами определяются потребности, которые должна удовлетворять система. Далее на основе этих запросов формируют системные требования, которые определяют, что будет делать система.
Для сбора потенциальных требований можно использовать разные источники.
1. Интервью с пользователями для уточнения дизайна продукта и улучшения качества.
2. Опрос и анкетирование, которые широко используются в социальных исследованиях и анализе рынка.
3. Наблюдение, которое включает фиксацию выполнения определенных функций и задач.
4. Изучение документов для сбора информации о том, как системы использовались, что необходимо добавить или улучшить в следующей версии системы.
5. Изучение аналогичных систем. Для этого можно использовать интервью с пользователями, исследование критических инцидентов, вопросов работоспособности, ремонтопригодности и удобства использования.
