Architecturally significant requirements

Architecturally significant requirements (ASRs) are those requirements that have a measurable effect on a computer system’s architecture.[1] This can comprise both software and hardware requirements. They are a subset of requirements, the subset that affects the architecture of a system in measurably identifiable ways.

Relation to non-functional requirements and quality attributes

For quite a long time, ASRs were not recognized as an important notion. When talking about architecture, non-functional requirements (NFRs) or quality attributes is often used.[2] However, recent empirical studies show that, for a software system, not all NFRs actually affect its architecture, and requirements that are not NFRs can also affect its architecture.[1][3] So, architecturally significant requirements is a valuable notion that is suggested to use when talking about requirements in relation to architecture.[3]

Characteristics

ASRs can be characterized from the following aspects.[1]

Descriptive characteristics

ASRs 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, ASRs’ architectural significance made these characteristics’ manifestations unique and challenging for ASRs.

Indicators

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

Indicators for 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 important (influential, that is) stakeholder.
  • The requirement has a first-of-a-kind character, e.g. none of the responsibilities of already existing components in the architecture addresses it.
  • The requirement has QoS/SLA characteristics that deviate from all ones that are 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[4] and Peter Eeles (IBM) discusses additional criteria for architectural significance in several articles and presentations[5]

Heuristics

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

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

Elicitation

Like all NFRs and quality attribute[6] requirements, ASRs should be specified in a SMART way. Quality attribute scenarios[2] are one way to achieve the S(specific) and the M(easured) criteria in SMART. The SEI recommends Quality Attribute Workshops (QAWs) for this effort.[7] It has been suggested to keep architecture analysis and design lightweight and flexible; quality attribute trees for certain application genres and technology domains can support such approaches.[8]

It is important to communicate the elicited ASRs, and any other architectural artifacts, in a notation and language that is comprehensible for the target audience (hear: business stakeholders).[9]

Impact

ASRs 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.[10] Exemplary advice on how to address system quality attributes (including ASRs) is available in the literature.[11][12]

See also

References

  1. 1 2 3 Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45. doi:10.1109/MS.2012.174.
  2. 1 2 Bass, Len; Clements, Paul (2003). Software Architecture in Practice. Addison Wesley. ISBN 978-0321154958.
  3. 1 2 Eckhardt, Jonas; Vogelsang, Andreas; Fernández, Daniel (2016). Are "Non-functional" Requirements really Non-functional? - An Investigation of Non-functional Requirements in Practice (PDF). The 38th International Conference on Software Engineering. Association for Computing Machinery.
  4. ↑ http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html
  5. ↑ http://www.architecting.co.uk/presentations/Architecting%20Large-Scale%20Systems.pdf
  6. ↑ http://www.sei.cmu.edu/reports/95tr021.pdf
  7. ↑ http://www.sei.cmu.edu/architecture/tools/establish/qaw.cfm
  8. ↑ Keeling, Michael (2015). "Lightweight and Flexible: Emerging Trends in Software Architecture from the SATURN Conferences". IEEE Software. 32 (3): 7–11. doi:10.1109/MS.2015.65.
  9. ↑ Schulenklopper, Jochem (2016). "Why They Just Don't Get It: Communicating about Architecture with Business Stakeholders". IEEE Software. 33 (3): 13–19. doi:10.1109/MS.2016.67.
  10. ↑ K. Julisch et al., Compliance by design - Bridging the chasm between auditors and IT architects Computers & Security 30(6-7): 410-426 (2011)
  11. ↑ https://msdn.microsoft.com/en-us/library/bb402962.aspx
  12. ↑ A. Rotem-Gal-Oz, SOA Patterns, Manning, 2012.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.