Рассмотрим ситуацию, показанную на рисунке 13. Здесь подрядчик, задающий требования к системе 1 (подрядчик 1), определил измеряемые и изменяемые переменные и выполнил функциональную декомпозицию с помощью функций F1.1…F1.N, F2 и F3.1… F3.Н.

В этот момент (или, возможно, даже раньше) подрядчик решает выделить функции F1 и F3 как отдельные подсистемы для разработки независимыми субподрядчиками.

На рисунке 14 показано как это сделать. Здесь функция F1 и её дочерние функции были вынесены спецификацию для «‎Системы 1.1», а функция F3 и её дочерние функции были вынесены в спецификацию для «‎Системы 1.3».

Задача состоит в том, чтобы создать полную спецификацию требований к «‎Системе 1» для использования подрядчиком 1, спецификацию требований для «‎Системы 1.1» для использования как подрядчиком 1, так и субподрядчиком 1.1, и спецификацию требований для «‎Системы 1.3» для использования как подрядчиком 1, так и субподрядчиком 1.3.

Подрядчик 1 определяет и обеспечивает выполнение требований к «‎Системе 1». Эти требования содержат в себе спецификацию для всей системы, которую подрядчик может не захотеть передавать субподрядчику 1.1 и субподрядчику 1.3.

Однако спецификация для «‎Системы 1» не будет содержать всех подробных требований для функций F1 и F3. Вместо этого детальные требования для функции F1 разработают и уточнят все детали подрядчик 1 и субподрядчик 1.1. Точно также детальные требования для функции F3 подрядчик 1 и субподрядчик 1.3 разработают вместе.

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

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

Какая информация должна быть в исходном ТЗ для подсистемы?

Как показано на рисунке 14, функцию F1 и её дочерние функции передали подсистеме 1.1, а функцию F3 и дочерние — подсистеме 1.3. Это означает, что иерархия функций для F1 и F3 и любые требования, разработанные для этой иерархии, теперь часть спецификации подсистемы 1.1 и подсистемы 1.3. Это гарантирует, что все, что сделает подрядчик, будет учтено в системе. К примеру, если планировалась декомпозиция на подсистемы, подрядчик может не разрабатывать дочерние функции для F1 и F3.

На рисунке 14 также показано, что копия функций F1 и F3 (но не их дочерние функции) сохраняется вместе с их высокоуровневыми требованиями в спецификации для системы 1. Дублирование высокоуровневых требований для F1 и F3 в спецификация системы 1 делается специально, чтобы обеспечить прослеживаемость и непрерывность взаимосвязи между системой 1 и подсистемой 1.1. Каждое требование высокого уровня подсистем 1.1 и 1.3 напрямую связано с идентичным требованием в системе 1.

На данном этапе спецификация требований для подсистем 1.1 и 1.3 состоит только из функций, скопированных из системы 1, и их требований высокого уровня. Как мы обсуждали в разделах с 2.1 по 2.9, полная спецификация требований состоит не только из списка обязательных утверждений «‎система должна».

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

Пример этого мы видим на рисунке 15 и в приложениях B, C и D. На рисунке 15 спецификация простой системы управления полётом (приложение B) разделена на функцию управления полётом (FG) и функцию автопилота (AP). Эти функции разделены на спецификацию подсистемы для простейшей подсистемы руководства полётом (приложение C) и простейшей системы автопилота (приложение D).

Спецификация требований ко всей системе управления полётом (приложение B) содержит подсистему руководства полётом и подсистему автопилота. Общее описание системы для системы управления полётом можно найти в приложении B.1.

Как показано на его контекстной диаграмме (рисунок B-1 в приложении B), система управления полёта отслеживает ориентацию воздушного судна из системы определения положения ВС и получает входные данные пилотов от органов управления ВС. Она устанавливает значения сигналов директорного управления, переменных сбоя системы управления полётом и переменной статус автопилота, предоставляемых основными дисплеями воздушного судна. Также система управления полётом устанавливает значение изменяемой переменной «‎Команды управления приводами ВС"‎, передаваемой приводам управления рулевой поверхности ВС.

Концепция эксплуатации системы управления полётом указана в виде юскейсов в приложении B.2. Внешние объекты, с которыми взаимодействует система, определены вместе с измеряемыми и изменяемыми переменными и их ограничениями среды в приложении B.3. Функции системы управления полётом вместе с высокоуровневыми требованиями определены в приложении B.4. При этом высокоуровневые требования для подсистемы руководства полётом указаны в приложении B.4.1, а высокоуровневые требования функции автопилота — в приложении B.4.2.

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

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

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

В то же время есть различия, которые необходимо учитывать (смотрите рисунок 15). Например, подсистема руководства полётом не использует поле запуска автопилота измеряемой переменной «Входные данные пилота» (Pilot Inputs) и не устанавливает измеряемую переменную «Статуса Автопилота» (AP Status), предоставляемую сигналам директорного управления. Система также не изменяет переменную «Команды управления приводами ВС» (Actuator Commands), предоставляемую приводам управления рулевой поверхности ВС.

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

В результате подсистема руководства полётом имеет одну новую изменяемую переменную (инструкции автопилоту), которую подсистема руководства полётом передаёт автопилоту, и одну новую изменяемую переменную (запрос инструкций автопилоту), которую подсистема автопилот отправляет в подсистему руководства полётом. Они соответствуют внутренним переменным, показанным на диаграмме зависимостей для подсистемы руководства полётом (рисунок B-2 в приложении B). Разделение системы управления полётом на две отдельные подсистемы открывает доступ к этим внутренним переменным, и теперь они рассматриваются как измеряемые и изменяемые переменные подсистемы руководства полётом и автопилота.

Измеряемые и изменяемые переменные для подсистемы руководства полётом определяются вместе с определением её внешних объектов в приложении C.3.

Как указано в разделе 2.3, следующий шаг — описать концепцию эксплуатации новой подсистемы. Это поможет объяснить, как подсистема будет взаимодействовать со своими пользователями и другими подсистемами.

Как и в случае с общим описанием системы, это обеспечит важный контекст для субподрядчиков и поможет определить, какие функции должна предоставлять подсистема, какая информация необходима для вызова этих функций и какую информацию система должна предоставить своим пользователям и другим системам. Один из способов описания концепции эксплуатации — разработать юзкейсы подсистемы. Можно использовать и другие подходы, определённые подрядчиком и субподрядчиком, при этом объём и уровень строгости зависят от того, насколько хорошо субподрядчик знаком с работой подсистемы. Место для описания концепций эксплуатации систем руководства полётом и автопилота представлены в приложениях C.2 и D.2, но примеры там не приводятся, хотя несколько юскейсов уже было представлено ранее.

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

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

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

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

Пример такой первоначальной спецификации для системы управления полётом приведен в приложении C. Пример для системы автопилот приведён в приложении D. Конечно, спецификация требований к подсистеме ещё не завершена.

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

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

Основная задача в этом процессе — завершение функциональной декомпозиции подсистемы, как мы обсуждали в разделе 2.5. Как только определили основные функции подсистемы, следует возобновить предварительную оценку безопасности подсистемы, как обсуждалось в разделе 2.6. Это следует сделать, чтобы определить любые производные требования к безопасности системы.

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

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

Например, на рисунке 15 сумма задержек переменной «Инструкции автопилоту» (принадлежащей подсистеме руководства полётом) и «Команды управления приводами ВС» (подсистемы Автопилот) должна быть меньше, чем задержка, указанная для изменяемой переменной"Команды управления приводами ВС" (Системы управления полётом). Также следует проверить допуски, заданные для изменяемых переменных подсистемы, чтобы убедиться, что они согласуются с допуском, указанным для соответствующей изменяемой переменной в родительской системе.

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

Далее к разделу 2.11