The Changing Context of Software Requirements Necessitates Better Model for Requirements and Architecture Co-development

Nowadays software development is seldom started from green-field. Most mature products have inherited many implementations developed decades ago. Still new software development projects would often continue to use code from legacy systems or earlier versions, COTS or open source implementations, which consequently impose many design decisions as constraints on those projects. Additionally, the current business environment (business process and user process) is tightly associated with various software systems that are already embedded in business activities. As a result, the problem space and the solution space present larger and larger overlaps. Therefore, software requirements today differ tremendously from requirements in the past, where conventionally requirements in the past mainly reside in the problem space and are considered to be separated from the solutions space while requirements now bear a great influence from the solution space and we cannot afford to consider them in isolation from the solution space anymore. With this new context, there is a need to refocus and rethink on software requirements from a solution perspective.

In the solution space, software architecture is the most important artefact that more or less dominates the success of the software project, especially in a long run. Software architecture has been recognized to have a close relationship with requirement for more than two decades. In the presence of the new context of software requirements, architecture has a much closer and more complex relationship with requirements now. In general, this relationship demonstrates that software requirements drive the architectural design while software architecture in return could constrain, frame and even inspire new requirements.

However, there exhibits a lack of good model for requirements and architecture co-development. In practice, requirements process cannot be separated from architectural design (the solution space) as explained earlier. Meanwhile, architectural design process cannot be isolated from requirements process as well because as-made architectural decisions would shape requirements again in a way that negates existing requirements or sparks off new requirements. Very often, requirements and architecture are nearly co-developed in practice, but in an ad hoc way.

Requirements practice in the past thirty years appeared to be distant from success even though almost everyone acknowledges the importance of software requirements. And architecture still emerges over time as the way it is rather than intentionally designed, where the risk is that early implemented architectural decisions if wrong would most likely kill the project or cost a lot to repair and as such cause the resultant software very challenging to maintain and evolve. One reason for this challenge in requirements practice and architectural design lies in the lack of good co-development model for requirements engineering and architectural design, which springs from the inadequate knowledge that can clearly illustrate this relationship in detail so that can be used to facilitate the co-development.

Such a co-development model should inform a process of decision making – the decision of both requirements and architecture. More importantly, such a model should resolve the uncertainty of decision making – the uncertainty of requirements; and the uncertainty of the relationship between requirements and architecture. As such, this model presents greater hope for improving requirements practice and architectural design in the current changing context.

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.