Архитектурно значимые требования

Тип требования в системной инженерии

Архитектурно значимые требования — это те требования, которые оказывают измеримое влияние на архитектуру компьютерной системы . ^[1] Это может включать как программные, так и аппаратные требования. Они представляют собой подмножество требований , которые влияют на архитектуру системы измеримо идентифицируемыми способами.

Отношение к нефункциональным требованиям и атрибутам качества

Архитектурно значимые требования были признаны важным понятием лишь недавно, в 2016 году. При обсуждении архитектуры часто используются термины нефункциональные требования или атрибуты качества . ^[2] Однако недавние эмпирические исследования показывают, что для программной системы не все нефункциональные требования влияют на ее архитектуру , и функциональные требования также могут влиять на ее архитектуру. ^[1]^[3] Это исследование предполагает, что стоит различать, какие требования к программному обеспечению являются архитектурно значимыми и являются ли они функциональными при обсуждении архитектуры программного обеспечения. ^[3]

Характеристики

Архитектурно значимые требования можно охарактеризовать следующими аспектами. ^[1]

Описательные характеристики

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

Индикаторы

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

Показатели архитектурной значимости, отмеченные в литературе, включают:

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

OpenUP ^[4] и Питер Илс ^[5] обсуждают дополнительные критерии архитектурной значимости в нескольких статьях и презентациях. Семь критериев архитектурной значимости были рассмотрены на Европейской конференции по архитектуре программного обеспечения в 2020 году: ценность/риск для бизнеса, обеспокоенность заинтересованных сторон, уровень качества, внешние зависимости, сквозной подход, первый в своем роде и источник проблем в прошлых проектах. Эти критерии описаны в ""Тесте архитектурной значимости"".

Эвристика

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

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

Выявление

Как и все нефункциональные требования и атрибуты качества, ^[6] архитектурно значимые требования должны быть определены SMART . Сценарии атрибутов качества ^[2] являются одним из способов достижения критериев S (конкретных) и M (измеряемых) в SMART. Институт программной инженерии рекомендует семинары по атрибутам качества для этих целей. ^[7] Было предложено, чтобы анализ и проектирование архитектуры оставались легкими и гибкими; деревья атрибутов качества для конкретных жанров приложений и технологических областей могут поддерживать такие подходы. ^[8]

Крайне важно донести до целевой аудитории (в частности, заинтересованных сторон ) выявленные архитектурно значимые требования и любые другие архитектурные артефакты в понятной форме и на понятном языке . ^[9]

Влияние

Архитектурно значимые требования используются в разработке программного обеспечения для обоснования архитектурных решений ; если они не выполняются должным образом, они способствуют накоплению технического долга . Например, невыполнение требований безопасности и соответствия усложняет аудиты обеспечения безопасности системы и процесса и увеличивает риск результатов аудита. ^[10] Образцовые советы по рассмотрению атрибутов качества системы (включая архитектурно значимые требования) доступны в литературе. ^[11]^[12]

Смотрите также

Ссылки

^ abc Чен, Ляньпин; Али Бабар, Мухаммад; Нусейбех, Башар (2013). «Характеристика архитектурно значимых требований». IEEE Software . 30 (2): 38– 45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID 17399565.
^ ab Bass, Len; Clements, Paul (2003). Архитектура программного обеспечения на практике . Addison Wesley. ISBN 978-0321154958.
^ ab Eckhardt, Jonas; Vogelsang, Andreas; Fernández, Daniel (2016). Действительно ли «нефункциональные» требования нефункциональны? - Исследование нефункциональных требований на практике (PDF) . 38-я Международная конференция по программной инженерии. Ассоциация вычислительной техники.
^ "Концепция: Архитектурно значимые требования". Архивировано из оригинала 17 октября 2016 г. Получено 19 августа 2016 г.
^ «Питер Илс на ResearchGate».
^ «Атрибуты качества» (PDF) .
^ «Семинар по атрибутам качества SEI».
^ Килинг, Майкл (2015). «Легкость и гибкость: новые тенденции в архитектуре программного обеспечения с конференций SATURN». IEEE Software . 32 (3): 7– 11. doi : 10.1109/MS.2015.65 .
^ Шуленклоппер, Йохем (2016). «Почему они просто не понимают: общение об архитектуре с заинтересованными сторонами бизнеса». IEEE Software . 33 (3): 13– 19. doi :10.1109/MS.2016.67. S2CID 1309474.
^ K. Julisch et al., Compliance by design - Bridging the Chasm between the auditors and IT architects Архивировано 21 сентября 2017 г. в Wayback Machine Computers & Security 30(6-7): 410-426 (2011)
^ «Реализация атрибутов качества системы».
^ А. Ротем-Гал-Оз, Шаблоны SOA, Мэннинг, 2012.

[ASR_Chen-1] Чен, Ляньпин; Али Бабар, Мухаммад; Нусейбех, Башар (2013). «Характеристика архитектурно значимых требований». IEEE Software . 30 (2): 38– 45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID 17399565.

[ASR_LB-2] Bass, Len; Clements, Paul (2003). Архитектура программного обеспечения на практике . Addison Wesley. ISBN 978-0321154958.

[ASR_JE-3] Eckhardt, Jonas; Vogelsang, Andreas; Fernández, Daniel (2016). Действительно ли «нефункциональные» требования нефункциональны? - Исследование нефункциональных требований на практике (PDF) . 38-я Международная конференция по программной инженерии. Ассоциация вычислительной техники.

[4] "Концепция: Архитектурно значимые требования". Архивировано из оригинала 17 октября 2016 г. Получено 19 августа 2016 г.

[5] «Питер Илс на ResearchGate».

[6] «Атрибуты качества» (PDF) .

[7] «Семинар по атрибутам качества SEI».

[10.1109/MS.2015.65-8] Килинг, Майкл (2015). «Легкость и гибкость: новые тенденции в архитектуре программного обеспечения с конференций SATURN». IEEE Software . 32 (3): 7– 11. doi : 10.1109/MS.2015.65 .

[ieeeswi2-9] Шуленклоппер, Йохем (2016). «Почему они просто не понимают: общение об архитектуре с заинтересованными сторонами бизнеса». IEEE Software . 33 (3): 13– 19. doi :10.1109/MS.2016.67. S2CID 1309474.

[10] K. Julisch et al., Compliance by design - Bridging the Chasm between the auditors and IT architects Архивировано 21 сентября 2017 г. в Wayback Machine Computers & Security 30(6-7): 410-426 (2011)

[11] «Реализация атрибутов качества системы».

[12] А. Ротем-Гал-Оз, Шаблоны SOA, Мэннинг, 2012.