architecturally significant requirements

Architecturally significant requirements were only recently, as of 2016, recognized as an important notion. When discussing architecture, the terms non-functional requirements or quality attributes are often used.{{cite book |last1=Bass |first1=Len |last2=Clements |first2=Paul |date=2003 |title=Software Architecture in Practice|publisher= Addison Wesley |isbn=978-0321154958}} However, recent empirical studies show that, for a software system, not all non-functional requirements affect its architecture, and functional requirements can also affect its architecture.{{cite conference |url=http://www4.in.tum.de/~vogelsan/publications/ICSE16.pdf|title=Are "Non-functional" Requirements really Non-functional? - An Investigation of Non-functional Requirements in Practice|first1=Jonas |last1=Eckhardt |first2=Andreas|last2=Vogelsang |first3=Daniel|last3=Fernández |date=2016 |conference=The 38th International Conference on Software Engineering |conference-url=http://2016.icse.cs.txstate.edu/ |publisher=Association for Computing Machinery}} This research suggests distinguishing which software requirements are architecturally significant and whether they are functional when discussing software architecture is worth it.

Architecturally significant requirements can be characterized by the following aspects.

Architecturally significant requirements are often hard to define and articulate, tend to be expressed vaguely, tend to be initially neglected, tend to be hidden within other requirements, and are subjective, variable, and situational. Other requirements could also demonstrate these descriptive characteristics. However, architecturally significant requirements’ significance made these manifestations unique and challenging.

A requirement with a broad effect targets trade-off points, is strict (constraining, limiting, non-negotiable), assumption-breaking, or difficult to achieve, and is likely to be architecturally significant.

Indicators of architectural significance that have been reported in the literature include:

• The requirement is associated with high business value and/or technical risk.
• The requirement is a concern of a particularly influential stakeholder.
• The requirement has a first-of-a-kind character, e.g. none of the responsibilities of existing components in the architecture address it.
• The requirement has QoS/SLA characteristics that deviate from those already satisfied by the evolving architecture.
• The requirement has caused budget overruns or client dissatisfaction in a previous project with a similar context.

The OpenUP{{Cite web |url=http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html |title=Concept: Architecturally Significant Requirements |access-date=2016-08-19 |archive-url=https://web.archive.org/web/20161017101618/http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html |archive-date=2016-10-17 |url-status=dead }} and Peter Eeles{{Cite web | url=https://www.researchgate.net/profile/Peter-Eeles-2 | title=Peter Eeles on ResearchGate}} discuss additional criteria for architectural significance in several articles and presentations. Seven criteria for architectural significance were addressed at the European Conference on Software Architecture in 2020: business value/risk, stakeholder concern, quality level, external dependencies, cross-cutting, first-of-a-kind, and source of problems on past projects. These criteria are described in an {{Cite web | url=https://medium.com/olzzio/architectural-significance-test-9ff17a9b4490 | title="Architectural Significance Test"}}

When a requirement specifies a software system’s quality attributes, refers to its core features, imposes constraints on it, or defines the environment in which it will run, it is likely to be architecturally significant.

See discussion of design vs. architecture under software architecture for additional criteria of architectural significance.

Like all non-functional requirements and quality attributes,{{Cite web | url=http://www.sei.cmu.edu/reports/95tr021.pdf | title=Quality Attributes}} architecturally significant requirements should be specified SMART. Quality attribute scenarios are one way to achieve the S (specific) and the M (measured) criteria in SMART. The Software Engineering Institute recommends Quality Attribute Workshops for this effort.{{Cite web | url=http://www.sei.cmu.edu/architecture/tools/establish/qaw.cfm |title = The SEI Quality Attribute Workshop}} It has been suggested that architecture analysis and design be kept lightweight and flexible; quality attribute trees for specific application genres and technology domains can support such approaches.

{{Cite journal | doi=10.1109/MS.2015.65 | title = Lightweight and Flexible: Emerging Trends in Software Architecture from the SATURN Conferences | journal = IEEE Software | volume = 32 | issue = 3 | pages = 7–11 | year = 2015 | last1 = Keeling| first1 = Michael| doi-access = free }}

Communicating the elicited architecturally significant requirements and any other architectural artifacts in a comprehensible notation and language for the target audience (particularly business stakeholders) is essential.

{{Cite journal | doi=10.1109/MS.2016.67 | title = Why They Just Don't Get It: Communicating about Architecture with Business Stakeholders | journal = IEEE Software | volume = 33 | issue = 3 | pages = 13–19 | year = 2016 | last1 = Schulenklopper | first1 = Jochem| s2cid = 1309474 }}

Architecturally significant requirements are used in software design to drive and justify architectural decisions; if not satisfied properly, they contribute to the accumulation of technical debt. For instance, failure to meet security and compliance requirements complicates the system and process assurance audits and increases the risk of audit findings.K. Julisch et al., [http://soadecisions.org/download/ComplianceByDesign-AAM.pdf Compliance by design - Bridging the chasm between auditors and IT architects] {{Webarchive|url=https://web.archive.org/web/20170921213138/http://soadecisions.org/download/ComplianceByDesign-AAM.pdf |date=2017-09-21 }} Computers & Security 30(6-7): 410-426 (2011) Exemplary advice on addressing system quality attributes (including architecturally significant requirements) is available in the literature.{{Cite web | url=https://msdn.microsoft.com/en-us/library/bb402962.aspx | title=Implementing System-Quality Attributes}}A. Rotem-Gal-Oz, SOA Patterns, Manning, 2012.

• Architectural decision
• Architectural pattern
• Attribute-driven design
• List of system quality attributes
• Non-functional requirement
• Requirements engineering
• Software architecture
• Solution architecture
• Systems architecture

{{Reflist}}

Category:Software architecture