Software requirements VS architecture — Literature 1

The Twin Peaks model, proposed in 2001, begins with the observation that software requirements and architecture are often developed in a concurrent and iterative fashion [1]. This observation implies the inevitable intertwining of requirements and architecture though it is implicit in practice. By understanding this relationship, practitioners are able to build software systems more cost-effectively and of higher quality. More specifically, they can improve how new systems are built, how change requests are handled, and how new functionality is introduced [2].

The literature on the relationship between requirements and architecture is limited. In “Traversing the twin peaks” [3], the authors argue that requirements are the end result of an architecting process. More concretely, since requirements drive architecture and architecture influences requirements in return, this back and forth interplay constantly shapes requirements and architecture till all trade-offs and conflicts are balanced. Hence, the resulting requirements could more appropriately reflect the ultimate designed architecture. In that sense, the architecturally significant requirements in the resulting requirements are almost the same as the architectural design decisions. 

Bosch [3] proposes the idea that requirements engineering should be done by the architects and they should work with the lead developers to elicit and specify requirements which actually is an implicit state-of-the-practice. This view is partly supported by a study that finds most non-functional requirements are discovered by architects [4]. Bosch dismisses the importance of documenting requirements, as he claims that documentation often becomes outdated very quickly. He emphasizes that it is more effective to let the architects contact the stakeholders and learn their needs directly. 

If requirements are elicited by architects, they might tend to drift into solutions space instead of standing in the problems space. However, this problem could be solved by careful requirements validation from stakeholders. Moreover, in some sense, software development teams just need such proactive perspectives from the solution space to predict feasibility of certain requirements.

[1] Nuseibeh, B. (2011 ) “Weaving Together Requirements and Architectures.” Computer 34(3): 115-117.
[2] Cleland-Huang, J., et al. (2013). “The Twin Peaks of Requirements and Architecture.” IEEE Software 30(2): 24-29.
[3] Mirakhorli, M. and J. Cleland-Huang (2013). “Traversing the Twin Peaks.” IEEE Software 30(2): 30-36.
[4] Ameller, D., et al. (2012). “How do software architects consider non-functional requirements: An exploratory study.” The 20th IEEE International Requirements Engineering Conference (RE), 2012.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>