Виктор Николенко - Системная инженерия на раз-два

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

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

Необходимым стартовым компонентом для продвижения по этапам разработки является документ «Концепция эксплуатации». В стандартах РФ документ не фигурирует, однако полезен для разработчиков, а также при разрешении последующих возможных конфликтов исполнителя с заказчиком. В нем количественно и качественно описывают ожидаемые характеристики разрабатываемой системы с точки зрения пользователя. По мере разработки и проверки концепции потребности заинтересованных сторон преобразуются в эксплуатационные требования. Задачей концепции является наглядное описание целей создания системы, «что» она должна делать, а не «как». Это не техническое задание, где изложен детальный набор требований к системе, подсистемам и элементам.

Концепция эксплуатации должна ответить на ряд вопросов пользователя.

• Что требуется от системы с функциональной точки зрения?

• Какие основные и второстепенные функции должна выполнять система?

• Что ограничивает ее возможности?

• Что пользователи ценят в ожидаемом продукте?

• Когда необходимо построить и поставить систему?

• Каков запланированный жизненный цикл системы?

• Какова предполагаемая стоимость жизненного цикла системы?

• Где предполагается использовать систему?

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

Далее начинается процесс формирования из системных требований верхнего уровня набора требований к системе в терминах, понятных разработчикам. Следует изложить, что должна делать новая система, и насколько хорошо она должна это делать. Заявленные требования предоставляются заказчиками систем, например, через часто используемые запросы контрактных предложений (RFP) и рабочие задания (SOW). Эти требования обычно формулируются на языке заказчика, зачастую в виде пожеланий. Требования заказчика недостаточны для проектирования системы. Обычно они неполные, нечетко сформулированные, а иногда и противоречивы по своему характеру. Системные требования должны быть собраны, отфильтрованы, уточнены, декомпозированы и задокументированы. Для этапа разработки необходим полный, технически обоснованный и точный набор системных требований, которые необходимо реализовать.

Требования являются ключом к успеху проекта. Хорошие требования к системе или продукту должны быть:

• Специфичны, должны отражать только один аспект конструкции или характеристик системы. Кроме того, должны быть выражены в терминах потребности (что и как хорошо), а не решений (как).

• Измеримы, характеристика выражается объективно и количественно, может быть проверена при испытании.

• Достижимы, технически реализуемы при доступных затратах, параметры элементов должны соответствовать законам физики и современным технологиям.

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

Чтобы сформировать хорошие требования к системе, сначала нужно обратиться к заинтересованным сторонам. Это пользователи системы, операторы и специалисты по обслуживанию системы. Кроме того, это люди, которые косвенно влияют на пользователей системы, администраторы, вспомогательный персонал и разработчики системы. В обсуждениях с заинтересованными сторонами определяются потребности, которые должна удовлетворять система. Далее на основе этих запросов формируют системные требования, которые определяют, что будет делать система.

Для сбора потенциальных требований можно использовать разные источники.

1. Интервью с пользователями для уточнения дизайна продукта и улучшения качества.

2. Опрос и анкетирование, которые широко используются в социальных исследованиях и анализе рынка.

3. Наблюдение, которое включает фиксацию выполнения определенных функций и задач.

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

5. Изучение аналогичных систем. Для этого можно использовать интервью с пользователями, исследование критических инцидентов, вопросов работоспособности, ремонтопригодности и удобства использования.

При сборе и анализе системные требования удобно классифицировать по типам:

– Функциональные требования, отвечающие на вопрос «что система должна делать?»

– Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?»

– Экологические, нефункциональные требования и сценарии использования, отвечающие на вопрос «при каких условиях экологии, надежности и доступности система должна работать для удовлетворения данного требования?»

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

– Политика и публичные законы, которые вносят ограничения по безопасности, экологии и шуму.

– Требования к качеству, включая требования к безопасности.

– Бизнес-требования, в том числе цена продукта, стоимость жизненного цикла, конкурентоспособность, и так далее.