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

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

2.2.7Требования в области проблем и в области решений

Ис управленческой, и с инженерной точки зрения необходимо четко различать область проблем (problem domain) и область решений (solution domain) [3]. Этапы разработки, которые ассоциируются с самыми абстрактными верхними уровнями описания системы – описанием потребностей, моделированием практического использования и требованиями заинтересованных сторон, должны быть неизменно увязаны с областью проблем, тогда как более низкие уровни, начиная с требований

ксистеме в целом, относятся к области решений.

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

Таблица 2.3 – Область проблем и область решений

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

180

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

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

Без четкого понимания различий между задачей и решением могут возникнуть следующие проблемы:

–недостаточное понимание действительной проблемы;

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

–постоянные споры о системе между разработчиками и поставщиками, вызванные тем, что система описана в терминах готовых решений;

–невозможность найти оптимальное решение из-за отсутствия свободы в проектировании.

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

На рисунке 2.7 показаны область проблем и область решений в контексте процесса разработки ТС.

181

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

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

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

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

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

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

183

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

Лица, отвечающие за утилизацию продукции. Роль этой категории заинтересо-

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

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

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

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

Специалисты по продаже и маркетингу. Роль этих лиц весьма важна для чёт-

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

Эксперты по удобству (эргономике) и эффективности (технической психоло-

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

187

Эксперты по окружающей среде. Как правило, новая ТС создаётся не для работы в полной изоляции, она будет взаимодействовать с существующими системами.

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

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

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

Общественное мнение и лица, его формирующие. Общественное мнение неоди-

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

Полномочные органы власти – эти организации могут потребовать предоставления определённых свидетельств и подтверждающих документов в процессе сертификации или аттестации. В качестве примера можно привести Федеральную службу понадзорув сфереприродопользования (Росприроднадзор) в РФ илиУправлениепо санитарному надзору за качеством пищевых продуктов и медикаментов (FDA) в США.

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

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

Источники требований заинтересованных сторон. В качестве источников требований заинтересованных сторон могут выступать:

–опросы заинтересованных сторон;

–подробное изучение сценария (в общем случае во время опросов заинтересованных сторон);

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

–существующие системы, требующие обновления;

–проблемы существующих систем и предлагаемые изменения;

188

–аналогичные системы;

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

–возможности, предоставляемые новыми технологиями (одобренные заинтересованными сторонами);

–исследования;

–анкетирование;

–антропоморфические исследования или анализ видеоматериалов.

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

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

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

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

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

189