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