Инновации от идеи до рынка

Архитектура не является единой структурой. Она определяет основные части системы и то, как эти части будут взаимодействовать друг с другом, чтобы удовлетворить общие системные требования. Определения архитектуры не уточняют, что представляют собой компоненты. При формировании архитектуры можно использовать диаграммы, наброски, рисунки, таблицы, и другие наглядные материалы для выражения пожеланий будущих пользователей. Например, в одном из стандартов имеется более 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) плавность хода и управляемость (свойства динамики автомобиля, связанные поведением во время маневров),

g) безопасность и защищенность водителя и пассажиров (проверяемые краш-тестами),

h) экологические характеристики (выбросы вредных веществ в ходе эксплуатации),

i) система информации и развлечений для водителя и пассажиров.

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

1. Система шасси.

2. Система отображения.

3. Аудиосистема.

4. Система ввода.

5. Электронная система обработки данных.

6. Система памяти (оперативной и длительной).

7. Система питания.

8. Система беспроводной связи.

9. Система охлаждения.

В частности, атрибуты удобного для просмотра экрана дисплея будут включать: размер дисплея (например, 15 дюймов по диагонали с соотношением длины к ширине 16:9), разрешение экрана 1920*1080 пикселей, физическая яркость дисплея 600 кд/м2, цветопередача, видимость под большими углами обзора, элементы управления яркостью и контрастностью дисплея, отражательная способность поверхности дисплея.

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

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

b) все подсистемы должны работать при номинальном напряжении 12 в;

c) все лампы должны иметь минимальный срок службы 2000 часов;

d) выключатели должны исправно работать не менее 1 000 000 циклов включения и выключения;

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

f) лампы в сборе должны выдерживать удары камешками размером 1 см на скорости 100 км в час;

g) фонари в сборе должны крепиться к кузову транспортного средства не менее чем в 3 точках;

h) все фары и противотуманные фары должны иметь возможность горизонтального и вертикального наведения.

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

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

2. Подсистема заднего освещения, состоящая из задних фонарей, стоп-сигналов, задних указателей поворота, фонарей заднего хода, фонарей номерного знака и задних отражателей.

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

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

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

6. Подсистема распределения электроэнергии, состоящая из жгутов проводов, реле и предохранителей.

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

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

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

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

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

• Определение пользователей системы и потребностей системы. Перевод потребностей пользователей в формальное определение системных требований.

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

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

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

• Составление исходной функциональной базы конфигурации, с документированием результатов вышеуказанных действий.

• Проведение обзора результатов концептуального дизайна.

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

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

• В формулировке требования должно быть указаны слова, что «продукт должен» (делать, выполнять, работать, обеспечивать, взвешивать), за которыми следует описание того, что должно быть сделано.

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

• Требование должно использовать согласованную терминологию для обозначения продукта и его компонентов более низкого уровня.

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

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

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

• Требование должно быть согласованным и прослеживаемым с другими требованиями выше и ниже в системной иерархии.

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

• Формулировка каждого требования должна быть краткой, с минимально полной информативностью.

После выявления требований проводят их анализ. Необходимо понять, что действительно нужно пользователям, и получить полную картину, как система будет использоваться, когда она будет построена. Избыточность системы или программного обеспечения является следствием того, что цели продукта и требования пользователей плохо определены. Часто не налажено взаимодействие между пользователями и разработчиками системы в ходе проектирования. При руководстве разработками новых продуктов необходимо при принятии каждого решения учитывать знания конечных пользователей, их желания, способности и уровни навыков, отраженные в документе «Концепция эксплуатации». Эти данные следует включать в требования верхнего уровня системы. Типовыми инструментами здесь являются сценарии использования, или описания применения системы пользователями. По ним можно представить действия пользователя и функции системы, изучить и обсудить потенциальные проблемы с предполагаемым использованием системы. Одним из важных аспектов этого этапа анализа является преобразование требований пользователей в количественные технические показатели эффективности. В процессе, который называют развертыванием функции качества (QFD1), выполняют преобразование голоса потребителя (требований и ожиданий) в технические характеристики продукции и рабочие инструкции. Потребности клиентов могут быть сформулированы расплывчатыми и качественными терминами, их нелегко измерить. QFD переводит эти требования с языка заказчиков на язык инженеров, перед которыми стоит задача разработки решений. Термин «развертывание» относится к распределению требований от верхнего уровня системы на подсистемы, модули, компоненты, программное обеспечение и материалы, а также на процессы их изготовления и сборки в производстве. Обширную литературу по использованию функции развертывания качества можно найти в интернете.

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

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