Supporting Concurrent Development of Requirements and Architecture

Supporting Concurrent Development of Requirements and Architecture

I held this talk at the 2014 MODELSWARD conference in Lisbon, Portugal

6d03452555634eae10adad12866ba544?s=128

Andreas Vogelsang

January 08, 2014
Tweet

Transcript

  1. Technische Universität München Supporting Concurrent Development of Requirements and Architecture:

    A Model-based Approach MODELSWARD 2014 January 08, 2014 Andreas Vogelsang1, Sebastian Eder1, Georg Hackenberg1, Maximilian Junker1, Sabine Teufl2 2 fortiss GmbH, Munich, Germany 1 Institut für Informatik Technische Universität München
  2. Technische Universität München • Requirements engineering and architecture development is

    often not carried out in a sequential manner • A more realistic view of development: Requirements and Architecture 2 1 B. Nuseibeh: "Weaving Together Requirements and Architectures“, IEEE Computer, 2001 The Twin Peaks model1 Challenge: consistency between artifacts2 2 A. Etien and C. Salinesi: “Managing requirements in a co-evolution context”, RE 2005
  3. Technische Universität München Approach 3

  4. Technische Universität München Review and Analysis Procedures • Manual Review

    between Use Cases, Scenarios and MSCs – Validation of the formalization – Based on checklists • Automated MSC Feasibility Checks between MSCs and Formal Specifications – Transformation of MSC to temporal logic proposition – Model checking against formal specification • Automated Refinement Tests between Formal Specification and Architecture* – Test cases generated from the formal specification – Translation to test cases for the architecture – Execution on the architecture – Comparison to the results of the original test case 4 * D. Mou et al.: "Binding requirements and component architecture by using model-based test-driven development" International Workshop on the Twin Peaks of Requirements and Architecture, 2012
  5. Technische Universität München Study Object: The CMCS • Canal Monitoring

    and Control System1 – controls a system of canals on which ships are cruising – canals are equipped with locks and bridges • Case documented by a requirements specification – 2 Use Cases (pass Bridge, pass Lock) – Domain Model – Hardware Topology 5 1 Case taken from the 2011 Workshop on Model-Driven Requirements Engineering (MoDRE 2011)
  6. Technische Universität München Evaluation: Setting • Goal: How does MDE

    perform in a co-evolutionary dev. context? • CMCS system developed in master-level practical courses (2x) – Overall 15 students (8 + 7) – Divided into two groups: • Requirements engineers • Architects – Duration: 4 months – Reviews by course supervisors – Tool Support: AutoFOCUS31 6 Requirements Engineers Architects Project time Use Cases/ Scenarios MSCs Formal specifications Architecture 0 % 100 % 1 http://af3.fortiss.org
  7. Technische Universität München Experiences • Feasibility – System was successfully

    developed and deployed 7
  8. Technische Universität München Experiences • Correctness of Requirements – Uncovered

    misconceptions regarding the behavior of the environment 8
  9. Technische Universität München Experiences • Concurrent Development of Requirements and

    Architecture – Consistent requirements and architecture artifacts 9 MSCs Formal Specification
  10. Technische Universität München Experiences • Concurrent Development of Requirements and

    Architecture – Information flow from requirements to architecture and vice versa 10 Architecture (excerpt)
  11. Technische Universität München Experiences • Explicit Design Decisions – Relation

    links document the design decisions – Abstract signals are translated to concrete logical signals 11 Formal Specification Architecture (excerpt)
  12. Technische Universität München Experiences • Scalability – 2 use cases,

    10 scenarios, 17 properties (14 formalized) – Analysis: • most time consuming MSC feasibility check (36 steps: ~100 sec.) • Problems – Formal Specifications and Architecture sometimes very similar • Potential for reuse 12
  13. Technische Universität München Conclusions and Future Work Conclusions: 1. Detection

    of inconsistencies in requirements through (semi)formal approach 2. Continuous consistency checks facilitate concurrent development 3. Design decisions captured by artifact relations Future Work: – Integrate nonfunctional requirements into the formal specifications – Effort/Usage examination 13 Thanks for the attention. Special thanks to: The students of our master’s course and the AF3 developers at fortiss GmbH
  14. Technische Universität München Backup

  15. Technische Universität München Artifacts: Requirements 15

  16. Technische Universität München Artifacts: Formal Specification 16

  17. Technische Universität München Artifacts: Architecture 17