2.1 Предпосылки, цели и область применения.
2.2 Операционную политику и ограничения.
2.3 Описание предлагаемой системы.
2.4 Режимы работы.
2.5. Классы пользователей и задействованный персонал.
2.6. Среду поддержки.
3. Эксплуатационных сценариев.
4. Анализа предлагаемой системы.
4.1 Краткое изложение улучшений.
4.2. Недостатки и ограничения.
4.3 Альтернативные рассмотренные варианты и компромиссы.
Наличие четко определенной концепции эксплуатации является ключевым исходным основанием для успеха системы. Нельзя начинать работу с ожиданиями, что можно спроектировать что-то сейчас, а исправить позже.
После уточнения концепции эксплуатации переходят к определяющему действию системной инженерии, которое включает разработку архитектуры новой системы (не путать с архитектурой зданий).
Архитектурой системы называют структуру компонентов, их отношений, а также принципов и руководств, регулирующих их проектирование и развитие во времени.
Системная архитектура отражает утвержденные системные требования. Она содержит наиболее важные стратегические реализационные решения, изобретения, инженерные компромиссы. В процессе разработки архитектуры формируется набор представлений, как система будет удовлетворять системным требованиям, все основные логические, физические, статические и динамические структуры, альтернативные решения, допущения и обоснования. Архитектура системы может включать функции, характеристики, технологию, оценку стоимости, риски, ограничения, границы системы, и т. д. Перечень функций затрагивает используемые в эксплуатации входные и выходные данные, сценарии использования, циклические процессы, функциональные требования, приоритеты. Поведение компонентов является частью архитектурного описания.
Архитектуры можно классифицировать в соответствии с отношениями между функциональными и физическими компонентами инновационных продуктов:
• Интегральная архитектура характерна функциональной взаимозависимостью между компонентами, при этом каждая функция может выполняться несколькими компонентами, а также компонентами, исполняющими несколько функций. Она плохо подходит для поддержки разнообразия продуктов. Но для простых изделий, которые производятся в больших объемах, интегральная архитектура может позволить упростить спецификацию (например, шариковые ручки, одноразовые бритвы, и т.д.) и тем самым способствовать разнообразию продуктов.
• Модульная архитектура отличается функционально независимыми компонентами, каждый из них отвечает за реализацию одной функции, и каждая функция выполняется одним компонентом. Модульная архитектура будет секционной, если интерфейс между каждой парой взаимосвязанных компонентов стандартизован. В модульной архитектуре компоненты могут соединяться друг с другом не напрямую, а через общий компонент (называемый шиной) и с использованием стандартного интерфейса.
На базе модульной архитектуры фирмы разрабатывают «платформенные системы», в которых общая платформа позволяет быстро разрабатывать производные продукты, отвечающие конкретным потребностям рынка. Компоненты, специфичные для производных, могут быть разработаны без необходимости перепроектирования основных и «внутриплатформенных» компонентов. Так создают семейства автомобилей, смартфонов, и др.
Вариант реализации гибкости заключается в глубокой цифровизации продукции. При этом продукт сформирован в виде «компьютера с периферией», поведение и функции которого зависят от программного обеспечения, которое будет запускаться на той же аппаратной платформе. Для этого производителю нужно оценить выбор между стоимостью продукта и гибкостью, поскольку изделие со встроенными функциональными резервами обеспечит большую гибкость, но будет более дорогим в производстве.
Архитектурное разнообразие открыто для обновлений с целью улучшения локализованных характеристик (например, установка жесткого диска большей емкости в компьютерную систему); надстроек или дополнений компонентов, придающих продукту новые функции (например, добавление внешнего источника освещения на видеокамеру); замены компонентов с целью расширения спектра действий продукта (например, сменные объективы в фотоаппаратах); адаптации компонентов для работы продукта в различных условиях (например, адаптер для питания устройства от сети переменного тока или в автомобиле).
Примером универсального модуля многочисленных электронных гаджетов может служить разъем для смартфонов USB-C, где объединен ряд функций:
A. Симметричный овальный разъем можно подключать в любой ориентации, для удобства применения функций интерфейса USB.
B. Имеются альтернативные режимы для объединения нескольких интерфейсов, включая стандартные спецификации передачи данных USB, и множество технологий и спецификаций работы в альтернативных режимах, когда контакты разъема передают данные по другим протоколам.
C. Реализована двунаправленная зарядка, которая может передавать энергию до 100 Вт. При этом устройство с портом USB-C может питать подключенное устройство, либо получать энергию от подключенного устройства для собственной зарядки.
D. Добавлено преобразование цифрового сигнала в аналоговый. В ряде смартфонов нового поколения отказались от разъемов для наушников, чтобы разместить другое аппаратное обеспечение. Пользователи могут использовать наушники со штатным разъемом 3,5 мм на своих смартфонах, подключив их через адаптер порта USB-C.
Модульная архитектура также упрощает использование стандартных компонентов, что приводит к очевидным преимуществам за счет экономии масштаба производства и снижения сложности. Иногда эти преимущества будут уравновешены дополнительными затратами, поскольку необходимость выбора среди ограниченного набора стандартных компонентов может приводить к завышению размеров по отношению к потребностям конкретного применения.
В зависимости от степени разделения работ между производителями конечного продукта и поставщиками принято различать уровни разработки продуктов «черного» и «белого ящика». В первом случае производитель конечной системы вообще не затрагивает внутреннюю работу компонентов, а ограничивается определением и тестированием значимых функций и характеристик. При разработке «белого ящика» производитель имеет прямое влияние на разработку компонентов и владение соответствующей технологией.
При проектировании архитектуры системы нужно учитывать сложную сеть взаимоотношений между функциональными элементами. Разработчику придется объединять компоненты в модули, которые относительно независимы друг от друга, и внутри которых могут проявляться существенные взаимозависимости. Варианты могут включать функциональные элементы, объединяемые одним потоком (без разветвления на другие функциональные элементы), либо организовать ветвление в потоке, когда каждая ветвь должна быть назначена отдельным модулям. Элементы, функцией которых является преобразование и передача материала, энергии или информации, обычно размещают в одном и том же модуле.
Архитектура не является единой структурой. Она определяет основные части системы и то, как эти части будут взаимодействовать друг с другом, чтобы удовлетворить общие системные требования. Определения архитектуры не уточняют, что представляют собой компоненты. При формировании архитектуры можно использовать диаграммы, наброски, рисунки, таблицы, и другие наглядные материалы для выражения пожеланий будущих пользователей. Например, в одном из стандартов имеется более 50 разделов по типам описаний архитектуры.
Верхний уровень требований к системе формируют на базе обобщенных результатов маркетинговых исследований будущей инновации. Эти данные включают выбор концепции эксплуатации, архитектуры системы, требования, включая запросы заказчика и производные (альтернативы функций, распределение требований). Также учитывают пожелания возможного заказчика.
Требованием называют утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо, а также необходимо для приемки продукта или процесса, согласно стандарту ISO/IEC 29148 «Разработка требований».
Есть несколько причин, зачем нужны требования:
• Требования определяют цель программы, например, чтобы предложить хороший продукт на рынок и получить прибыль от реализации проекта.
• Требования определяют, что система должна делать, и управляют ее развитием.
• Требования определяют ограничения, связанные с реализацией проекта, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства, и т. д.
Требования не являются спецификациями. Они определяют функции, характеристики системы, и задачи в части окружающей среды. Распространенной ошибкой является чрезмерное ограничение проектирования путем указания ненужных барьеров для творчества архитекторов и инженеров при выполнении проекта.
Посредством требований уточняются формулировки или характеристики продукта или системы, которые разработчик хочет или должен получить. В системных требованиях учитывают запросы заинтересованных сторон, то есть производителей, поставщиков, операторов и других лиц. Сюда входят корпоративные клиенты, заинтересованные в рынке будущей системы, низких эксплуатационных и капитальных затратах; операторы системы, заинтересованные в ее производительности, долговечности, надежности, наличии запасных частей; пользователи, которые заботятся о комфорте, безопасности и удобстве использования. Эти стороны, в конечном счете, будут использовать систему, извлекать из нее выгоду, управлять, поддерживать в рабочем состоянии, влиять на нее или подвергаться ее воздействию.
Заявленные требования обычно формулируются на языке заказчика, зачастую в виде пожеланий. Требования заказчика недостаточны для проектирования системы. Обычно они неполные, нечетко сформулированы, а иногда и противоречивы по своему характеру. Далее начинается процесс формирования из системных требований верхнего уровня набора требований к системе в терминах, понятных разработчикам. Следует изложить, что должна делать новая система, и насколько хорошо она должна это делать, преобразуя внешние требования клиентов во внутренние требования разработчиков. Системные требования должны быть собраны, отфильтрованы, уточнены, декомпозированы и задокументированы. Вовлечение клиентов на как можно более раннем этапе определения требований способствует значительному сокращению циклов разработки и переделок, а также гарантирует, что требования, выданные клиентами, являются полными, последовательными и понятными для производителя. Документ формирует технический лидер, и он утверждается менеджером программы.
Далее выполняют преобразование требований заказчика в требования верхнего уровня проекта. Они сгруппированы по конкретным направлениям. Требования к системе и характеристикам формирует технический лидер. Промышленные требования верхнего уровня в части производственных и испытательных требований составляет управляющий производством. Требования к процессам и проектам верхнего уровня, где рассматривают процессы управления проектом, качество и требования к закупкам, входят в зону работы менеджера команды разработки.
На основе согласованных требований верхнего уровня инженерные группы каскадно формируют документы на требования, необходимые и понятные исполнителям рабочих пакетов и поставщикам. Для этапа разработки необходим полный, технически обоснованный и точный набор системных требований, которые необходимо реализовать в проекте или программе для удовлетворения потребностей клиентов, и корпоративных контрактов ОКР.
Требование определяет одну или несколько характеристик продукта и уровни их достижения, необходимые для достижения конкретной цели (например, функция, которую необходимо выполнить, уровень производительности, который должен быть достигнут, а также ограничения по максимальной массе или размеру продукта) для данного набора условий.
Спецификация системных требований определяет требования, которым должна удовлетворять система, подсистемы, аппаратное обеспечение, компонент или другой физический элемент. Обычно используется в качестве основы для приобретения, проектирования и разработки, верификации и валидации системы, подсистемы или другого элемента.
Спецификация требований к программному обеспечению определяет требования, которым должен удовлетворять каждый элемент ПО. Используется в качестве основы для закупки, проектирования, проверочного и приемочного тестирования элемента программного обеспечения.
Спецификация требований к интерфейсу (глава 3.6) определяет требования, которые должны быть удовлетворены на интерфейсе между двумя элементами (аппаратно-аппаратное, аппаратно-человеческое, аппаратно-программное или программное обеспечение). Используется для поддержки закупок, проектирования, проверочных и приемочных испытаний одного или обоих элементов интерфейса.
Удобно классифицировать требования по видам, для дальнейшего использования:
1. Требования потребителя определяют ожидания потребителя или заинтересованной стороны от продукта или системы с точки зрения их эксплуатации, целей, функций, производительности, среды и ограничений. Определяются согласно подтвержденным потребностям целевых клиентов в течение всего жизненного цикла продукта.
2. Функциональные требования определяют, какие функции необходимо выполнить для достижения целей продукта при его использовании. Они соответствуют основным функциям и сервисам функционального анализа, и полностью характеризуют необходимые операции или задачи, которые должен выполнять продукт (что, когда, и как).
3. Нефункциональные требования, не связаны с выполнением какой-либо задачи или конкретной функции, но определяют характеристики и свойства, которыми должна обладать система, например, технические требования безопасности ИТ (конфиденциальность, целостность), производительность и доступность в соответствии с определенными критериями. В них входят, такие особенности, как совместимость (способность подсистем интегрироваться в целую систему или среду), общность использования компонента взаимозаменяемо с существующим, но другим типом компонента, экономическая эффективность как общая стоимость системы для достижения заданного уровня выгоды, ремонтопригодность как легкость, с которой ее можно отремонтировать, тестируемость или как система может быть систематически испытана и измерена на предмет ее рабочих характеристик, готовность как статус ожидаемой готовности работы системы при обращении пользователя, удобство использования или оценка навыков, обучения или способностей, необходимых для работы и обслуживания системы, устойчивость как способность системы выжить в условиях воздействия возмущений и сбоев.
4. Требования к производительности определяют, насколько хорошо продукт или система должен выполнять свои функции, измеряемые с точки зрения количества, качества, охвата, сроков или готовности. Эти требования также назначаются системным элементам (подсистемам и компонентам) посредством процессов каскадирования и распределения сверху вниз. Например, функция тормозной системы автомобиля может быть определена как способность остановить транспортное средство на дистанции 35 м от начальной скорости 100 км/ч на ровной сухой дороге при внешней температуре 20° C и усилии нажатия на педали тормоза 30 кг.
5. Требования к интерфейсу определяют, что необходимо сделать на данном интерфейсе (глава 3.6) между различными системами, подсистемами или компонентами для работы продукта. Для физического интерфейса они будут определять, например, эксплуатационные или проектные характеристики физического соединения или соединения между двумя объектами (прочность соединения, давление, возникающее в соединении, несущем указанный поток жидкости или газа, размер и тип крепежных деталей), электрические характеристики (кодовый отраслевой номер разъема, допустимая нагрузка по току, сопротивление, емкость или скорость передачи данных через соединение).
6. Требования надежности, которую можно определить как вероятность того, что продукт, система, подсистема или компонент не откажут в течение заданного периода времени при определенных условиях эксплуатации.
7. Требования к окружающей среде предназначены для контроля неблагоприятного воздействия окружающей среды на людей, продукты или системы, в которых продукт или система предназначены для работы. Экологические проблемы включают эффекты вибрации, ударов, акустических шумов, термических, загрязнений, коррозии, общей дозы или пикового уровня радиации, погодных атмосферных воздействий, условия и качество воздуха (например, выбросы парниковых газов), магнитные поля, градиенты давления во время работы, микробный рост, и т. д.
8. Требования к человеческому фактору должны гарантировать, что люди в качестве операторов или специалистов по сопровождению продукта или систем могут выполнять назначенные им функции или задачи с безопасностью и комфортом.
9. Требования безопасности относятся к эксплуатации продукта или системы с точки зрения отсутствия несчастных случаев или опасных ситуаций, которые могут привести к неблагоприятным последствиям для здоровья, травмам, гибели людей или повреждению имущества и окружающей среды.
10. Требования безопасности данных для многих сложных продуктов должны гарантировать, что к продукту не смогут получить доступ никакие неавторизованные лица или лица, которые считаются угрозой для продукта или его систем. Они должны включать отказ в доступе, а также включение дополнительных защит в случае нарушения безопасности.
11. Ограничения в определенном смысле показывают границы развития продукта, например, тип операционной системы, с которой система должна работать, или того, какой язык кодирования использовать для настройки системы.
Сформулированный и утвержденный набор требований необходим для начала процесса проектирования продукта и обеспечивает:
• четкое представление различными группами команды проекта, отвечающими за разные подсистемы, как и почему распределяются требования, чтобы поддержать кросс-функциональные взаимодействия между всеми модулями в продукте;
• понятные обязанности проектных групп для выполнения требований;
• ранние гарантии того, что все требования верхнего уровня полностью удовлетворены в продукте, с прослеживаемостью до того места, где они выполняются;
• проверку предотвращения непреднамеренного добавления функций и затрат, чтобы избежать внеплановой «позолоты» (удорожания) проекта;
• быструю оценку влияния любых изменений, внесенных в требования;
• процедуры ранней верификации и подтверждения соответствия конструкции продукта заданным требованиям.
Требования определяют систему, но не уточняют ее проект. Они излагают, что желательно для системы, но не дают способов, как этого добиться. Далее системные требования необходимо перевести в технические спецификации, которые необходимы разработчикам, чтобы сконцентрироваться на наиболее критических факторах проекта, упростить ситуацию за счет игнорирования несущественных опций.
Требования к характеристикам обычно определяются в физических параметрах, таких как скорость, ускорение, вес, точность, мощность, время. Например, для легкового автомобиля требуется транспортировка 4 пассажиров на дистанцию 500 км со скоростью 80 км в час. Каждое требование к характеристикам нужно сопровождать набором требований к верификации, включая процедуры, измерения и испытания для проверки выполнения требований.
Атрибутом или свойством называют характеристику товара, которая должна обеспечить хорошие продажи. Предполагается, что клиенты покупают и используют продукты на основе совокупности свойств, которую можно разбить на ряд атрибутов. Полный набор атрибутов продукта должен покрывать все потребности покупателей. Основные атрибуты, связанные с каждым требованием, могут включать:
1) уникальный идентификатор;
2) краткий заголовок;
3) приоритетность;
4) критичность;
5) реализуемость;
6) риск;
7) источник требования;
8) тип;
9) объяснение;
10) историю появления (кем и когда);
11) отношение к другим требованиям (базовое, прослеживаемое, и др.).
Широту областей, охватываемых набором атрибутов продукта, можно показать на примере легкового автомобиля:
a) дизайн и стиль кузова,
b) количество пассажиров и эргономика, включая емкость багажника,
c) доступность (включая затраты на приобретение, эксплуатацию и техническое обслуживание),
d) мощность двигателя и экономия топлива,
e) комфорт в салоне (уровень шумов, вибрация и климат-контроль),
f) плавность хода и управляемость (свойства динамики автомобиля, связанные поведением во время маневров),
