Методология системотехнического проектирования электронных и радиоэлектронных средств (в двух частях)

–это требование по своей сущности более сложно, чем первое, следовательно, ему нужно уделить особое внимание;

–изменениетребования вовтором случаебудет иметь большеевоздействие, чем изменение требования в первом случае, поэтому второму требованию следует уделить особое внимание.

Разумеется, явный дисбаланс на одном уровне может непосредственно влиять на следующий более низкий уровень. Это показано на рисунках 2.30,в и г, где двумя уровнями ниже фактор развитости один и тот же. Какой вывод можно сделать на этом основании? Возможны следующие ответы:

–самое верхнее требование на рисунке 2.30,в размещено на слишком высоком уровне;

–средние требования на рисунке 2.30,г размещены на слишком низком уровне. Ожидаемый фактор развитости требований между уровнями можно научиться

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

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

На рисунке 2.31 показано, как может выглядеть типичное распределение значений фактора развитости. На рисунке значения фактора представлены в зависимости от количества требований, которым присуще это значение. Наибольшее количество требований расположено в интервале значений фактора от 2 до 6, лишь для некоторых фактор равен 1 или превышает 6. Это те самые вышеупомянутые требования, которые следует точно определить и уделить им особое внимание.

Рисунок 2.31 – Частотное распределение значений фактора развития требований

230

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

Помня о том, что прослеживаемость является связью типа «многие ко многим», рассмотрим рисунок 2.32. Два требования самогонижнего уровня связаны болеечем с одним требованием вышележащего уровня. Что можно сказать об этих требованиях? Возможно, они более критичны, чем остальные, поскольку удовлетворяют нескольким требованиям, поэтому им следует уделить особое внимание.

Рисунок 2.32 – Критичность требований

Распределение восходящей прослеживаемости можно использовать для обособления этих требований. На рисунке 2.33 показана типичная форма такого распределения.

Рисунок 2.33 – Частотное распределение критичности требований

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

231

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

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

а

б

Рисунок 2.34 – Потенциальные изменения, возникающие вследствие запроса на изменение

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

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

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

232

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

Рисунок 2.35 – Обработка запросов на изменения

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

2.5.3Анализ функционирования и проектирование

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

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

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

233

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

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

Наиболее часто специальная разработка требуется для компонентов трех типов:

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

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

3)компонентов, взаимодействиекоторых сосредой недостаточнохорошоизучено. Выявление элементов системы (компонентов и подсистем), для которых показа-

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

лица 2.10).

Таблица 2.10 – Функциональные элементы системы

234

Окончание таблицы 2.10

В таблице перечислены основные функциональные элементы, разбитые на четыре класса: сигналы, данные, материалы и энергия. У каждого функционального элемента есть ряд ключевых характеристик, определяющих его функциональные возможности. У большинства характеристик имеются пределы, обусловленные физическими свойствами лежащих в их основе технологий и зачастую фундаментальными зависимостями между функциями (например, скоростью и точностью) [15]. Если для выполнения какого-то функционального требования к новой системе характеристики элемента системы должны быть выше, чем ранее достигнутые, значит, может возникнуть необходимость либо в разработке компонента, либо в изменении требования.

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

Таблица 2.11 – Избранные критические характеристики функциональных элементов системы

235

Окончание таблицы 2.11

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

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

2.6Оформление и представление требований

кобъекту проектирования

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

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

Техническое задание – это первый и весьма важный документ для проектирования ТС с разработкой соответствующей документации, предназначенный для определения цели проектирования и обоснования направления поиска. Он разрабатывается всегда независимо от стадии разработки. Содержание, общий порядок разработки, согласования и утверждения ТЗ устанавливает ГОСТ 15.016-2016.

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

236

лицо или организация. Основной причиной, заставляющей заказчика обратиться к разработчику, является отсутствие у заказчика соответствующих специальных знаний либо ограниченность его ресурсов (нехватка времени на решение задачи, необходимого количества людей, оборудования) [7].

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

Перевести технические требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, т.е. сформулироватьТЗ, –первый и обязательный этап работы. Поэтомуестественно, что решение задачи начинается с её осмысления и уточнения исходных данных. Разработчик выполняет это в тесном контакте с заказчиком.

Статистика проектной деятельности показывает, что если стоимость исправленияпроектной ошибки, допущенной наэтапетехническогопроектирования,принять за 1 у.е., то стоимость её исправления возрастает в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и формулировки ТЗ.

В общем виде ТЗ на разрабатываемый объект должно содержать перечень выполняемых этим объектом функций и список предъявляемых к нему требований. В ТЗ включают перечень и значения прогнозируемых параметров с отражением уровня стандартизации и унификации; параметров, характеризующих научно-техни- ческий уровень (патентную чистоту) и качество изделия с учётом полного удовлетворения целевого назначения; стоимость его разработки. В ТЗ входят следующие основные разделы:

–наименование и область применения;

–основание для разработки;

–цель, назначение и источник разработки;

–технические требования;

–условия эксплуатации,

–экономические показатели,

–стадии и этапы разработки,

–порядок контроля и приёмки,

–приложения.

237

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

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

С другой стороны, стоит в обобщенном смысле принимать во внимание слова Ли Якокки [16]: «…Беда в том, что ты учился в Гарварде, где тебе вбили в голову, что нельзя предпринимать никаких действий, пока не соберешь все факты. У тебя 95% информации, а для того, чтобы собрать недостающие5%, тебе понадобится еще шесть месяцев. За это время все факты устареют, потому что рынок развивается гораздо быстрее. Самое главное в жизни – всё сделать вовремя.

…Главная задача состоит в том, чтобы собрать все важные факты и точки зрения, которые вам доступны. Но в какой-то момент надо начинать действовать решительно. Во-первых, потому что даже самое правильное решение оказывается

238

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

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

Перечень шагов по выявлению и формулировке требований может быть представлен следующим образом [17].

1.Определить ожидания заинтересованных сторон.

2.Определить ограничения проекта и предприятия.

3.Определить внешние ограничения.

4.Определить эксплуатационные сценарии.

5.Определить меры (количественные критерии) эффективности.

6.Определить границы системы.

7.Определить внешние интерфейсы.

8.Определить окружение среды эксплуатации.

9.Определить концепции процесса жизненного цикла.

10.Определить функциональные требования.

11.Определить требования к характеристикам.

12.Определить режимы работы.

13.Определить технические показатели эффективности.

14.Определить конструктивные характеристики.

15.Определить человеческие факторы.

16.Установить базовый уровень требований.

17.Оформить требования по стандарту.

Выводы

1.Требования к объекту проектирования – это желаемые характеристики (свойства) будущего изделия и их значения и/или диапазоны значений.

2.Работа с требованиями является основополагающим компонентом любой инженерной деятельности.

3.Инженерия требований (requirements engineering) – это подраздел системной инженерии, занимающийся выявлением, разработкой, прослеживанием, анализом, проверкой соответствия, установлением взаимосвязей и управлением требованиями, которые определяют систему на последовательных уровнях абстракции.

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

5.Причины неудачи проектов чаще всего объясняются неполнотой требований.

239