1. Home
  2. Smartpedia
  3. Twin Peaks Model

What is the Twin Peaks Model?

Smartpedia: The Twin Peaks Model describes the concretisation of requirements in parallel with the exploration of suitable system architectures.

Twin Peaks Model Definition

The Twin Peaks Model describes how you develop the requirements and architecture of a system iteratively and in parallel. It provides the answer to the question “What needs to be developed first – the requirements or the architecture”. It illustrates the related activities of requirements engineering and system architecture development.

Twin Peaks Model - developing requirements and architecture jointly

The origin in the spiral model

The Twin Peaks Model is a simplified version of the Spiral Model and goes back to Professor Bashar Nuseibeh, who argued in 2001 that the requirements analysis and the architectural design should be interlocked and organised in parallel. He had recognised that a sequential order of “Requirements first, Design second” is not appropriate for innovative systems.

The visualisation of Twin Peaks

The Twin Peaks model is visualised with two similar mountains (therefore called Twin Peaks); one mountain represents the requirements, the other the architecture. Both are equally high and equally important. They start with rough requirements and architectural models and refine them parallel to each other in mutual alternation. In this way, from the narrow summit of the mountains, you will arrive at new requirements and architectural elements with increasing detail.

Requirements and Architecture in the Twin Peaks Model

Parallel development

Many IT organisations are faced with the question of how they should proceed when developing a new system. Is it a question of capturing requirements first or would it be better to design the software architecture first? Requirements can change, new technologies can appear and earlier design decisions can be questioned. It is therefore advisable at the beginning to design the most important requirements for a system rudimentarily. Use these requirements to develop a prototype or Minimum Viable Product (MVP), get stakeholder feedback, and revise your design. Derive new requirements and reassess and prioritize existing requirements. And implement the prioritised requirements in the architecture again.

Communication during parallel development

The Twin Peaks Model describes a dynamic interaction between requirements and architecture. Good communication between the project participants is essential for this interaction. Ideally, the project team should include both a requirements analyst and a system architect. Both work simultaneously and iteratively. On the one hand, problems with architectural limitations are better understood and on the other hand, architectures are better developed or adapted on the basis of requirements. Of course, the system architect needs an excellent overview of the system and its environment. He assesses the effects and dependencies of requirements on the architecture and communicates requirements resulting from different architectural alternatives.

Advantages of parallel development

Requirements and the architecture of a system are strongly interdependent. The Twin Peaks Model pursues the idea of paying attention to requirements and architecture in parallel. This results in various advantages:

  • The detailing and concretisation of requirements takes place just as step by step as the exploration of suitable architectural alternatives. Thus the architecture grows on the basis of the requirements and architectural decisions can lead to concretisation and re-evaluation of requirements.
    The architecture is the focus and can be designed in such a way that both the set goals and functional and non-functional requirements are fulfilled. At the same time an Architecture-Indifferent Design with a neglect of the architecture is avoided, with which developers use existing or in the domain usual architectures (Presumptive Architecture).
  • Project and product risks can be reduced by evaluating alternatives through analysis, simulation, prototyping or refactoring.
  • Traceability is increased because architectural decisions can be traced back to requirements and vice versa.
  • Inconsistencies between requirements and architecture are avoided.
  • Critical requirements are easily overlooked without early architecture evaluation. This often leads to reworking, delayed design changes and high costs. This can be avoided with the Twin Peaks model.

 

Twin Peaks Model Guide Download

Download the Twin Peaks Model Guide for free now.

Everything important about the Twin Peaks Model at a glance.

  • definition
    parallel development of requirements and architecture
    visualisation
    benefits and challenges

Knowledge on 5 pages to take away.

Challenges for companies

Keeping an eye on the architecture

If you are involved in software and system development, you may also have experienced a deterioration in architecture over time. Despite agile methods like Scrum and Kanban it happens that the focus of the interaction between requirements and architecture shifts and the system architecture takes a back seat. To avoid this, IT organisations should keep an eye on the following questions throughout the lifecycle of a product:

  • Which software architectures are stable with changing requirements and how do we select them?
  • Which requirements are more stable than others and how do we identify them?
  • Which requirements are volatile and how do we identify them?
  • How can systems be scaled for the future?
  • How do I achieve modularisation of systems?

 

Notes:

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

Here you can find additional information from our t2informatik Blog:

t2informatik Blog: The best process in requirements management

The best process in requirements management

t2informatik Blog: The problem with problem descriptions

The problem with problem descriptions

t2informatik Blog: The destructive path to requirements

The destructive path to requirements