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.