Software Technologies - Home
Bridging the Twin Peaks - Winning with Requirements and Architecture
Christof Ebert
JAN 21, 2013 13:17 PM
A+ A A-

Requirements and architecture of any system thus are highly interdependent. Projects without early architecture evaluation will overlook critical requirements. They will fail in prioritizing requirements. They face budget overruns and rework due to inappropriate and late design changes. This blog looks how to bridge the twin peaks of requirements and architecture.  

Understanding requirements and using them to make informed architectural decisions is a critical success factor for any system. Requirements are subject to change. New technologies appear and challenge previous design decisions. Architecture has to anticipate and follow such technology evolution. Projects thus must address requirements and system architecture in parallel. The “Twin Peaks” model nicely shows this relationship. One peak is the requirements and the other one is architecture. They stand side by side, and we typically start up in the clouds, working our way towards a solid ground. Too often, however, when descending the requirements or architecture peak, we fail looking to the other peak. Costly disconnect of requirements and architecture is the result.

A recent client project highlights this disconnect. A service-driven approach was introduced without adequate aligning architecture and needs. The requirements were developed and modeled without looking to solution models and architecture constraints. Business processes were modeled with a nice modeling tool, but not mapped to requirements. The intended service-oriented architecture copied previous technology-driven silos, as this was the language everybody understood. The result was a soup of individual components that would not perform according to business expectations. When arriving at the scene, we had to finally restart the entire requirements modeling and architecture concept – at a high cost of rework.

Bridging the Twin Peaks of requirements and architecture means to look on requirements and architecture in parallel. The two peaks remain, but their key concerns evolve concurrently. Synergies between requirements and architecture are modeled and evaluated when they appear. For instance, a cost constraint could drive architecture decisions, while an architecture perspective on security and performance could help re-evaluating initial requirements. Usability and other critical quality attributes are specified and evaluated with their actual impacts, while there is still time to restate and prioritize.

Bridging the Twin Peaks means to stepwise emphasize the synergies between requirements and architectural design. Requirements are incrementally or evolutionary developed, while concurrently exploring suitable alternative architectural decisions. The well-known Spiral development model is used to stepwise and pragmatically mitigate project and product risks. Development proceeds with successive iterations of both these concerns, leading to increasingly detailed requirements and refinements of the architecture.


Bridging the Twin Peaks recognizes the reality of most development projects, where time and resource constraints do not allow for a lengthy requirements elicitation process before proceeding with system design. Techniques such as the Win-Win approach, the Architectural Trade-off Analysis Method, and the quality requirements catalog with accompanying Soft-Goal Interdependencies help bridging the twin peaks. MDA helps in defining a system architecture related to requirements, while still separating the key concerns of requirements and architecture in order to minimize the constraints they place upon each other during the early stages of a project.

Bridging the Twin Peaks requires appropriate development methods that support effective communication in a dynamic development environment. A key need for effectively and efficiently bridging the twin peaks thus means to assign a system architect to the project core team – before project start. The architect must have an excellent overview on the system and its environment, and thus challenge requirements during elicitation. Product management, sales and marketing people on the other hand can ask questions on the impact and dependencies of their requirements at a time, when they can still be modified with low effort. Organizational measures should be taken to appropriately structure work packages in distributed projects so that requirements and architecture are handled in parallel, even across distance.

Bridging the Twin Peaks must extend to the entire life-cycle as we have seen in many industry settings. For instance, quality concerns must be maintained throughout the system's lifetime. The often-seen architecture degradation during product and system evolution highlights that we still have to build more bridges between the twin peaks of requirements and architecture – throughout the entire product life-cycle.



The “Build Your Career” TechSet of IEEE, provides a solid overview on requirements engineering articles that will help you both as a beginner or industry expert. URL:

The Twin Peaks Model had initially been described by Bashar Nuseibeh in his article "Weaving Together Requirements and Architectures" IEEE Computer, vol. 34, no. 3, pp. 115-117, Mar. 2001. URL:


IEEE Software theme issue on “Twin Peaks of Requirements and Architecture”:

White Papers and resources:     


Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world to sustainably improve product strategy and product development and to manage organizational changes. He has worked extensively in requirements engineering and product management, and serves as a frequent keynote speaker and RE evangelist at conferences and with many companies. An IEEE senior member, he serves on a number of advisory and industry bodies, teaches at the University of Stuttgart and has authored several bestselling books including his most recent book “Global Software and IT” published by Wiley-IEEE.

Contact him at


[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment: