Requirements engineering and architecture design are two key factors for successful software development.
The risk of unwanted developments is particularly high in these areas, which is why they also offer the greatest potential for risk minimization and general optimization.
It’s not sufficient to address these two areas in isolation. On the contrary, it’s essential to ensure consistent integration of requirements engineering and architecture design if they are to influence each other positively. The so-called Twin Peaks Model emphasizes this relationship and requires iterative collaboration of requirements engineering and architecture design, as shown in this figure.
The impacts of requirements in terms of the effort involved can only be realistically assessed when an initial high-level architecture design is available. If the efforts assessed on the basis of the high-level architecture design are then presented to the customer, it’s not uncommon for them to waive certain requirements. However, existing design alternatives can indicate to those responsible for specifying the requirements that the requirements aren’t sufficiently precisely defined.
The central task of software architecture design is to find a design approach with which the functional and nonfunctional requirements defined by requirements engineering are implemented in a fully designed solution. This approach, however, isn’t a one-way street, as indicated by the Twin Peaks Model shown earlier.
Instead, the process involves continual compromise between the “request list” from requirements engineering and the software architect’s inventory of existing solutions, building blocks, and other architecture artifacts. As the next figure illustrates, this approach means the software architect develops the construction plan for the software system in coordination with relevant stakeholders (e.g., requirements engineer, customer, user, developer, tester, or administrator).
Because a new system or system enhancements should not be addressed in isolation, interfaces to other systems, affected organizations, execution platforms, and the implementation infrastructure also have to be taken into account. The interfaces, requirements, and constraints from the four adjacent areas found in the figure below must be considered and codesigned by the architect.
The architect must also take the entire lifecycle of the system and the adjacent areas referred to previously into account. Architecture always means investment in supporting elements to achieve flexibility and extensibility elsewhere. This, however, demands consideration of the corresponding lifecycles; otherwise, these investments may not be secure.
Software architecture isn’t developed behind closed doors and demands teamwork from the many parties involved in the project. It’s therefore necessary to develop a common understanding of what forms part of a software architecture and what doesn’t, both within the current project and in its surrounding environment. This includes a common nomenclature for the most important terms such as interface or building block.
As shown in the previous figure, the architect has to consider interfaces not only with requirements engineering but also with other disciplines and roles involved in software development. A software architect designs an architecture starting from the conditions, constraints, and requirements of these surrounding areas, thus defining the essential aspects of the solution, such as the building block structure and interaction patterns. Viewed in isolation, the architecture design process isn’t sequential. Even the term “iterative approach” doesn’t sufficiently describe the nature of the architecture design process. The individual tasks involved in the process can’t be meaningfully brought into a linear sequence. Instead, as shown below, we subdivide architecture design into four activities of equal weighting.
These four activities are described as follows:
Effective tool support should also be established on the basis of these concepts. This ensures optimal support for the individual areas of activity involved in the design of the software architecture—for example, analysis and management of requirements, handling of architecture models and documentation, quality assurance, and communication. Autonomous tool solutions already exist for these individual task areas. These stand-alone tools must be integrated as seamlessly as possible to ensure that the architect can use them effectively. Because the design process isn’t sequential but rather iterative and incremental (or even concurrent), it’s especially important to close the gaps between the individual tools.
As already explained, the individual activities involved in the software architecture design process can’t be arranged linearly. They are areas of equal importance to which the software architect has to devote sufficient attention depending on the current project situation. The architecture design is a continuous interplay between the activities shown earlier:
During the architecture design process, the software architect carries out these four activities in a sequence that suits the needs and context of the project. This iterative and incremental interplay of activities is associated with a top-down and bottom-up change of the abstraction levels and perspectives shown earlier.
This way, we can switch from the topmost abstraction level of the conditions, constraints, and requirements of the surrounding areas via the abstraction levels in the software architecture (architecture style and technical infrastructure, plus the functional and technical architecture levels) through to the bottommost abstraction level, which consist of the software program itself, the program’s design, and its implementation. The architecture design process is thus a continuous top-down and bottom-up flow within the abstraction levels, along with a continuous change of activities that are performed interactively and incrementally. This is illustrated in this figure.
Within this process, the project setting and constraints define the constraints of the architecture. In return, the architecture design provides data on technical project risks and planning information.
Requirements engineering describes the functional and nonfunctional requirements for the architecture design coming from those accountable for the system. As explained previously, this isn’t a one-way street, and the architecture design also provides feedback on the feasibility of implementing the requirements and their consequences for requirements engineering.
The partially or fully available technical infrastructure—for example, server infrastructure, operating systems (OSs), requirements for programming languages, and the operating organization—must also be taken into consideration during the architecture design process. The interface with operations is especially far too often neglected, which can result in major problems during system deployment. Once again, this isn’t a one-way street. The architecture design can produce new technical infrastructure requirements—for example, further expansion of the server landscape or the integration of additional middleware.
Finally, the architecture design provides the specifications for detailed design and programming. However, return flows of information are also necessary here. Unforeseen problems can arise during the implementation of the software architecture. If these problems aren’t communicated to the software architect and a supposedly simple solution is implemented instead, this can undermine the entire architecture. It’s therefore important to discuss such problems with the software architect and to jointly develop a solution that may result in changes to the architecture.
The task of the architect is to develop a blueprint for the system based on the functional and nonfunctional requirements, while taking requirements and constraints of the surrounding areas into account. The subsequent implementation, maintenance, support, and enhancements are then based on this blueprint. This requires development of a complete and concise architectural description. On one hand, the architectural description serves as a communication and discussion platform, and, on the other hand, as a design and implementation plan. As shown in the next figure, the architect must provide a large number of interfaces to almost all the roles involved in a software development project.
Editor’s note: This post has been adapted from a section of the book Software Architecture Fundamentals: iSAQB-Compliant Study Guide for the Certified Professional for Software Architecture—Foundation Level Exam by Mahbouba Gharbi, Arne Koschel, Andreas Rausch, and Holger Tiemeyer.