Twin Peaks Model. Developing the Architecture and Requirements of a Software System.
What is the meaning of Twin Peaks Model? What advantages does it offer and how is it used in software development?
One mountain peak represents the requirements and the other represents the architecture. In the Twin Peaks Model you work from the top of the peaks to the bottom. That means at first the requirements and architecture are roughly described and both are then refined together over time.
The refinement takes place in parallel and in mutual interplay. For example, when the first requirements are elicited, then the architects draft a prototype, get feedback from the stakeholders and work on the design. Requirements can also be further refined in this process.
In the end, the rough, general requirements and architecture become detailed.
What Is the Twin Peaks Model?
The Twin Peaks Model tackles the development of the architecture and requirements of a software system. Developed by Bashar Nuseibeh, an IT professor at the Open University in the UK, the model aims to solve the chicken-and-egg problem in software development:
Before drafting the architecture, requirements need to be defined. But requirements can only be defined when the architecture is known.
In practice, this often results in a classical waterfall model: First, requirements are specified and then the architecture is developed based on these.
This approach may lead to problems. For instance, requirements are derived that can’t be implemented with the existing technology. Or the architecture is assembled piecemeal from individual components, performs poorly, and doesn’t fulfill stakeholders’ expectations.
To solve these problems, Nuseibeh introduced the Twin Peaks Model. He suggested that the architecture and requirements should be seen as two mountains that need to be worked on from top to bottom using an iterative approach. The “peaks” of the mountain are the starting points and development takes place from top to bottom in mutual interplay.
Advantages of the Twin Peaks Model
- Requirements take the system context into account
- Quick development of design alternatives
- Quick creation of prototypes
- Efficient development of the architecture through use of existing solutions
- Workload of requirements can be estimated using the first rough architecture plan
- Reduction of costs because “unrealistic” requirements are identified before development begins
- Risk reduction in development
Short and sweet definition of the Twin Peaks Model:
The Twin Peaks Model is used in software development to iteratively develop the architecture and the requirements. Both “peaks” are equally important.
What Does the Twin Peaks Model Achieve?
The Twin Peaks Model helps with the following problems:
I’ll Know It When I See It (IKIWISI)
Often, requirements are only developed once users can test the system. With the Twin Peaks Model for software development, prototypes can be developed earlier on, which can then be used to gather user feedback and achieve the desired solution iteratively.
React to changes
Changes in projects have to be dealt with. For example, stakeholders often change their minds, which also changes the requirements. According to the Agile Manifesto, it’s more important to react to changes than to stick to the plan. With the Twin Peaks Model, it’s possible to develop stable architecture despite constantly changing requirements.
Click here to read more about the Agile Manifesto and agile project management »
Commercial off-the-shelf software
Existing components are generally available to software architects for designing their software. Through the implementation of recommended solutions, the costs of implementation sinks. The Twin Peaks Model helps you to identify and implement off-the-shelf components early on.
Knowledge to go
Develop architecture and requirements in parallel with objectiF RPM
Learn more about how objectiF RPM can support your software development
Use of the Twin Peaks Model
Using the Twin Peaks Model succesfully presupposes that you’ve integrated a software architect into your team before the project starts. What does the Twin Peaks Model mean for software architects and requirements engineers?
Tasks of the Architecture
The architect works with existing solution components and needs to consider consider frameworks and interfaces to other systems. Additionally, the architect keeps an overview of the entire life cycle of the system. Thus a software architect works in different areas with people in different roles such as requirements engineers, developers, designers, quality managers, and project managers. Following the Twin Peaks Model, a software architect has the following tasks:
- Examination of the existing functional and non-functional requirements (including the boundary conditions)
- Working out the architecture in detail
- Assuring the quality of the architecture using reviews and prototypes, among other things
- Overseeing the implementation (ensuring communication between all participants)
Tasks of Requirements Engineering
A requirements engineer delivers functional and non-functional requirements that need to fulfill the architectural conditions. The architecture influences defined requirements by revealing technical boundaries or goal conflicts among the requirements. In the Twin Peaks Model, a requirements engineer needs to manage the following tasks:
- Deliver of the first, coarse requirements for software architects
- Rework and define requirements with reference to the available architecture and framework
- Adaptation of requirements to changes/innovations in technical possibilities
- Following the Twin Peaks Model, the tasks are to be carried out iteratively and incrementally with ongoing communication with the other people involved.
How can these two areas of expertise be brought together in practice in such a way that development becomes traceable? If a requirement changes, you’ll need to know which components are affected. In large projects with thousands of requirements related to system elements, it’s easy to lose track of things. In practice, combining requirements engineering and architecture design calls for software support. With the right software, you can create diagrams that allow you to connect requirements with blog diagrams and individual components using realize, refine or satisfy relationships. In this way, you ensure the necessary traceability that will help you keep track of everything.
Click here to learn more about designing a system using software support »
This Is How you Implement the Twin Peaks Model in Practice.
With objectiF RPM you develop architecture and requirements in parallel »
Develop requirements and architecture iteratively
To develop a software solution that satisfies all stakeholders, you can’t strictly separate the requirements and architecture from each other. Rather, you have to – as suggested by the Twin Peaks Model – carry out both activities in parallel and with regular coordination between all participants. But how can you efficiently create requirements and architecture models, refine them in parallel and maintain traceability amidst constant change? How can you assure the quality of your specifications and models? And how can you guarantee communication and exchange of information between all project participants?
These tasks require software support. With objecitF RPM, you can keep track of your requirements centrally and create architecture models. Visual methods like requirement diagrams, class diagrams and block diagrams allow you to easily connect system components with the relevant requirements, ensuring traceability at all times. objectiF RPM offers quality assurance in the form of review workflows for requirements and other elements. Want to learn more?