Emerging Issues in Relating Software Requirements and Architecture

Many of the previous chapters have touched on, some in detail, the issue of whether we should develop a set of software requirements first and then an architecture for a system based on these requirements, or whether available architectural and technological platforms must be considered when actually eliciting, documenting and using requirements. Traditional wisdom has been that requirements for a system are captured and then a suitable architecture developed to fulfill these [2, 6]. As we have seen, many application domains, development approaches and technology solutions challenge this approach. For example, an understanding of architectural characteristics and technologies available for a problem domain are useful when discussing possible requirements with stakeholders e.g. what is actually feasible and what is not [3]. Similarly, many approaches have adopted round-trip engineering between requirements and architecting where enhancing or changing one necessarily impacts greatly the other. Many of the previous chapters indicate that the field is moving towards a view that requirements and architecture for a software system are necessarily closely related and therefore often need to be engineered, if not in parallel, then closely informing one another in an iterative manner. Some domains the notion of what the requirements are or what the available technology solutions to architect are ill-defined. Open source projects are an example where requirements are often organic and emerge from user communities over time. Rapid technology change fields like consumer appliance engineering and cloud computing similarly have architectures and technologies rapidly changing during development. Some applications have requirements that are difficult to anticipate during development e.g. social networking applications and mash-ups where an application may be composed of parts and the “requirements” both dynamic and run-time emergent from stakeholders.