Do you remember the 1990 series Twin Peaks? I thought of it straight away when I heard about the Twin Peaks model. Unlike the series, which took place in a small town called Twin Peaks, the model has no dark secrets or mysterious happenings. After all, this has nothing to do with David Lynch. But it is better this way, because there will not be so many arguments over how something should be interpreted.
The twin peaks model is easier to understand: It describes how requirements and software system architecture can be efficiently developed.
What first: requirements or architecture?
The origin of the twin peaks model can be found in the well-known dilemma: what has to exist first, the requirements or the architecture?
Unfortunately, the waterfall model often controls the heads of both “parties”: In the first phase, the system requirements are developed, then comes the system design. But that often leads to more work and more costs in the project because reacting quickly to changes like new stakeholder requests or new technological possibilities is difficult. So this procedure results in requirements that can’t be implemented technically or in architecture that the stakeholders are not satisfied with. Of course, this becomes apparent too late in the project.
That is why in 2001, Bashar Nuseibeh suggested the Twin Peaks model to develop both requirements and architecture iteratively and parallel. How did he get this name?
Requirements and architecture are two identical mountains
One mountain represents the requirements, the other one the architecture. Both are the same height and just as important as each other. In the twin peaks model, you don’t climb the mountains. You are instead put on top of them and have to find your way down. Kind of mean. Because experienced mountain climbers know that the descent is just as difficult, if not more so, than the ascent. Actually, there are three ways to come down the mountain: with your back to the mountain, sideways or with your chest to the mountain . Good, we learned even more! But before I digress, a quick explanation of descending the mountain with the twin peaks model:
You start with rough requirements and architecture models and refine them parallel to each other through a mutual interplay. That way you achieve more and more detailed requirements and architecture elements from the narrow peak of the mountain.
Now ask yourself the question: who should start working, or take the first step?
Stal suggests drafting about 30 % of the most important system requirements rudimentarily . Based on this, the architects develop prototypes, get feedback from the stakeholders and rework the drafts. Before they re-invent the wheel, the architects also check if they can implement existing solutions. With the development of individual components, the requirements are also refined.
So no one can hide out and do their own thing – all participants have to continually communicate with each other.
To separate the development of requirements and architecture and proceed waterfall-style leads to unsatisfactory results. The twin peaks model provides a concept that reflects the ideals of agile development and with which you can achieve the right solution iteratively. So how can you efficiently develop requirements and architecture? How do you make sure everything is traceable and that all participants can communicate with each other and exchange information?
We have the right software for that: objectiF RPM enables you to work with requirements diagrams like block diagrams or class diagrams, and to generate these into documents or exchange them. Traceability is always guaranteed because you can place the system components in relationships with requirements and evaluate these relationships. Then changes in the project are no longer a problem!
Check it out for yourself and test objectiF RPM for free with the Trial Edition!
 Nuseibeh, B. (2001). Weaving the Software Development Process Between Requirements and Architecture. Proc. Of ICSE 2001 Workshop STRAW-01. Toronto.
 Bloch, R. (2011). So gehen Sie sicher im unsicheren Gelände. (in English: How to proceed safely in uncertain territory). Retrieved from ALPIN http://www.alpin.de/sicher-am-berg/7258/artikel_so_gehen_sie_sicher_im_unsicheren_gelaende.html
 Stal, M. (2016). Twin-Peaks-Modell in der Softwareenticklung. (in English: Twin Peak Model in software development). Retrieved from on heise Developer https://www.heise.de/developer/artikel/Twin-Peaks-Modell-in-der-Softwareentwicklung-3133582.html