При разработке требований рекомендуется формулировать простые утверждения. Требования включают обязательные характеристики, такие как «необходимый, проверяемый, достижимый технически, затраты, сроки». Т.е. каждое требование должно выразить одну мысль, быть кратким и простым, быть заявлено положительно, быть грамматически правильным; без опечаток и орфографических ошибок, быть понятным однозначно, должно использовать терминологию для обозначения системы (продукта) и ее частей более низкого уровня, соблюдать правила проекта (шаблонов и стилей), формат требования «кто хочет что».

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

Для перевода требований заказчика в технические характеристики продукта часто используют процедуру развертывания функции качества (quality function deployment, QFD). Метод QFD представляет собой один из инструментов проектирования изделий и процессов, помогающий преобразовывать пожелания потребителя в технические требования к изделиям и процессам их производств. Основная идея технологии QFD заключается в том, чтобы связать потребительские свойства, надежность (т.е. фактические показатели качества) и установленные в стандартах параметры продукта (вспомогательные показатели качества), между которыми всегда существует большое различие.

Метод (https://clck.ru/3FNPmg) основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуются в технические. Затем технические характеристики преобразуются в характеристики компонентов, далее в характеристики процессов и в характеристики контроля продукта.

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

Одним из видов требований нижних уровней являются производные требования.

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

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

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

Схема процесса декомпозиции требований изображена на рис.7.

На рисунке процесс движется слева направо. На шаге 1 установлены возможности системы (выставленные исходные требования). На шаге 2 проводится декомпозиция требований верхнего уровня по функциям системы, формируются производные и «дочерние» требования. На шаге 3 требования к функциям привязывают к подсистемам и компонентам системы.

Распределение требований при разработке системы можно разделить на вертикальное и горизонтальное. Вертикальное распределение отражает разложение требований с верхнего уровня системы на уровень подсистемы, далее на уровень оборудования и т. д. Горизонтальное распределение относится к соответствию между требованиями и элементами архитектурного дизайна на одном уровне.

Прослеживаемость (трассировка) и иерархия требований также являются важными компонентами управления требованиями. После декомпозиции требований верхнего уровня на нижние уровни свойство прослеживаемости идентифицирует отношения и связи между требованиями разных уровней и их источниками для проверки происхождения и правильности формулировки. Анализ прослеживаемости является эффективным методом контроля и обнаружения противоречий и совпадений требований.

При рассмотрении вышеуказанных вопросов производных требований важным является уточнение набора интерфейсов системы. Интерфейс описывает связь между двумя функциями или процессами, фактически отражая часть требований к системе. Интерфейсы в системе появляются при ее сопряжении с внешними системами (соединение частей комплекса с бортовыми системами, линии связи авионики с наземным центром управления полетами и др.), либо при ее декомпозиции при распределении работ, либо при разделении элементов конструкции на модули и компоненты в зоне ответственности конкретного субподрядчика. Существуют разные типы интерфейсов: механические (компоненты физически стыкуются друг к другу); электропитание (напряжение и токи между подсистемами); электронные (характеристики электрических сигналов между системами); данные (формат и содержание информации, передаваемой между подсистемами); тепловые (тепловые потоки между подсистемами); программное обеспечение (связь модулей или оборудования).

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

Примеры стандартных интерфейсов (механические и шины данных) показаны на рис. 8.

Требования к интерфейсам должны удовлетворять определенным правилам для исполнения задаваемых функций.

1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.

2. Функции, характеристики, ограничения и допущения этих интерфейсов должны быть определены и зафиксированы в требованиях к интерфейсам.

3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.

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

5. Требования к интерфейсу включают логические и физические интерфейсы.

6. Функциональные и ресурсные распределения по подсистемам влияют на требования интерфейса. В качестве примера рассмотрим сжатие данных. Эта функция может быть выделена либо в радиолокационной подсистеме, подсистеме обработки данных или подсистеме связи.

Интерфейсы можно классифицировать на внешние и внутренние (по отношению к системе в целом или по отношению к области работ конкретного подрядчика). Разделение на внутренний и внешний интерфейсы внутри системы зависит от положения исполнителей в цепочке «заказчик-поставщик».

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

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

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

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

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

a) определить интерфейс и его характеристики (физические, электрические, механические, человеческие и т.д.);

b) обеспечить совместимость интерфейса со всеми сопряженными интерфейсами, используя процесс, документированный и одобренный в проекте;

c) разработать документ управления интерфейсом;

d) определить монтажные чертежи или другую документацию, которая включает полную конфигурацию интегрируемого продукта, список деталей и инструкции по сборке;

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

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

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

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

• Документ управления интерфейсом (ICD) излагает детали интерфейса между двумя элементами системы: числа и типы разъемов, электрических параметров, механических свойств, а также экологических ограничений, определяет дизайнерское решение на требование интерфейса.

Набор из трех документов, как правило, делается в усеченном варианте, часто используют только документ управления интерфейсом с введением отдельных данных из других документов. В документе ICD указаны персонально сотрудники, ответственные за интерфейсы (по одному на каждый, один владелец может быть у нескольких интерфейсов).

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

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

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

b) измеримы, т.е. характеристика выражается объективно и количественно (например, точное требование, указывающее температуру детали в градусах, может быть проверено при испытании);

c) достижимы, т.е. технически реализуемы при доступных затратах;

d) соответствовать указанному уровню подсистемы (например, требование наличия солнечных батарей спутника не входит в уровень требований ракеты-носителя, а только в требования для подсистемы полезного груза);

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

Можно изложить некоторые полезные правила формирования требований, как набор рекомендаций, чего следует «избегать» в тексте требований:

1) хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;

2) «лазеек», таких как «если это необходимо», поскольку они делают требование бесполезным;

3) помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;

4) рассуждений и нечетких слов («обычно», «в основном», «часто», «нормально», «типично»);

5) использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);

6) принятия желаемого за требуемое («100% надежный», «приятный для всех пользователей», «безопасный», «подходящий для всех платформ», «не должен никогда ломаться», «быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем»).

Приведем несколько примеров требований, с точки зрения того, хорошо ли они изложены.

•Самолет должен иметь три двигателя (исходное требование для DC-3). Позже выяснилось, что самолет должен отвечать требованиям эксплуатации при отказе одного двигателя.

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

• После проектирования системы пожаротушения в Таганском туннеле 3-го транспортного кольца Москвы было проведено ее опробование. Оказалось, что после срабатывания системы огонь успешно ликвидируется, но восстановить движение по туннелю невозможно, так как пену нечем удалять (рис. 9). Видимо, предполагалось, что она будет сливаться в водостоки. Пришлось вносить в систему доработки.

На практике нередко встречаются отклонения от требований. Для дальнейшего продвижения в проекте необходимо указать причины отклонений. Как правило, это следствие отсутствия части информации. В документах встречаются места, оставленные для заполнения в дальнейшем. В документах на английском языке используют пометки типа TBA (to be agreed – необходимо согласовать), TBC (to be complete – необходимо завершить), TBD (to be decided – необходимо принять решение). Однако при «заморозке требований» весь набор пустых ячеек для требований должен быть заполнен. Важно знать при формулировке раздела требований в англоязычных контрактах, что слово «Compliance» является единственным вариантом подтверждения строгого соответствия исполнителя требованиям контракта.

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

Валидация требований часто входит в один из этапов ворот принятия решений. Проверка требования включает четыре типовых вопроса.

•Правильная ли сформулирована проблема?

• Смогли ли указанные требования отразить проблему?

• Верно ли сформулированы эти требования?

• Соответствуют ли требования установленным границам системы и ограничениям?

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

В результате процесса разработки формируется набор требований к системе, который должен быть выполнен при создании продукта или системы. Он содержится в документах контракта, спецификациях или технических заданиях на выполнение работ. Характеристики этого набора требований будут идентичны вышеописанным характеристикам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным (т.е. не нуждается в дополнительных пунктах требований). Входящие в него требования должны быть согласованными (т.е. не содержат противоречий, дублирований и др). Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 3.4).

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

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

Одной из целей функционального анализа является обеспечение прослеживаемости от требований верхнего уровня системы до требований к рабочему проектированию. Учитывая конкретные требования к оборудованию, можно двигаться «вверх» для обоснования этого требования. Функциональный анализ должен обеспечить механизм прослеживаемости «снизу вверх».

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

Функциональный анализ, в частности, формирует основу для разработки:

a) электрического и механического проектирования компонентов мониторинга состояния и средств диагностики;

b) моделей надежности;

c) анализа характера, последствий и критичности отказов;

d) анализа технического обслуживания, ориентированного на надежность;

e) анализа ремонтопригодности;

f) анализа человеческого фактора;

g) анализа безопасности и рисков системы;

h) логистического анализа (анализа цепочки поставок).