Tutorial 1: Writing Requirements Documents with GORE: from Theory to Practice

Writing Requirements Documents with GORE: from Theory to Practice Dr Robert Darimont – Respect-IT (B)

Tuesday October 23rd, 2:00 pm – 5:30 pm

Requirements Engineering (RE) is nowadays acknowledged as a key discipline for IT project success. But unfortunately people who have to write requirements documents often are still facing the syndrome of the writer in front of a blank sheet: What do I have to say and not to say in a requirements document? This tutorial is primarily intended for them.

Goal-Oriented Requirements Engineering (GORE) provides a clean and workable answer to the challenge of writing the requirements, all the requirements and nothing else than the requirements. The intrinsic nature of goals allows indeed the requirements engineer to focus on the problem to be solved and on the minimal constraints to impose on any candidate solution.

The tutorial focuses on the GORE/KAOS approach developed in the Software Engineering Labs at the University of Louvain (B) and used on a day-to-day basis in Respect-IT. It contains the following parts:

  • Part 1: The process of writing a requirements document with a GORE approach is outlined. A particular focus is put on the elaboration of KAOS requirements models[1]on which the requirements documents are based. During the presentation, the cornerstone concepts of KAOS are investigated, illustrated and related with each other:
    • Goals. Goals are desired properties on the information system. Asking the ‘why’ and ‘how’ questions systematically on goals allow the analyst to elicit the requirements progressively, to understand the rationales behind the requirements and to keep the requirements in a consistent and complete framework. Conflicts and obstacles that prevent goals from being satisfied are identified and investigated as well.
    • Domain Objects. Domain objects provide a high-level description of what the information system consists of in terms of concepts and relationships over them. An immediate benefit of collecting domain objects during the analysis is the ability to produce an adequate glossary in the requirements document.
    • Agents & Responsibilities. Listing the requirements in a document is not enough: it is important to specify who (= agent) is responsible for what :  which module is responsible for each requirement, what are the expectations on the external systems that need to interact with the system, what are the expectations about the users of the system, …  This part allows the analyst to define the project scope sharply. In addition, the main interfaces between the system to be and its environment can be prefigured by allowing the analyst to specify the objects that the agents control or monitor.
    • Operations. Operations add a behavioral dimension to agents. They describe transitions of system objects that are needed to comply with the requirements.  Processes are compositions of operations.
  • Part 2: Examples taken from real requirements documents produced with the approach are presented.
  • Part 3: A case study applying GORE in accelerated motion is outlined. It is about the specification of an IT system to control a car park infrastructure.
The presenter. Robert Darimont is the founding CEO of Respect-IT, a spin-out of the University of Louvain (B). He has led a lot of medium- and large-size requirements engineering projects for more than 15 years in various domains (industry, public / private administrations). He plays a key role in the development of the Objectiver tool that supports the GORE/KAOS approach. Robert Darimont received a PhD on the formalization of refinement patterns and the formalization of RE processes from the University of Louvain (direction: Prof. A. van Lamsweerde).

[1]  GORE requirements modeling is the main topic of the A. van Lamsweerde’s book : Requirements Engineering: From System Goals to UML Models to Software Specifications (Wiley, 2009).


Tutorial 2: Is cloud computing bringing complexity or simplicity?

Is cloud computing bringing complexity or simplicity? Hervé Crespel – X4it (F) and Joseph DeRosa – Consultant (USA)

October 25th, 2012, 9:00 am – 5:00 pm


Cloud computing is changing software “things” even more than you might expect. Not only do we see new software components, but also software architectures are changing dramatically.  With parallel computing now possible at very large scales, we see an explosion in the promise and possibilities for software systems. The “cloud” must have complexity to enable innovation and evolution, while it must have management simplicity to harness the power of that complexity.


Two main questions are facing software and system designers: How do you harness the complexity of the cloud and how do you ensure it remains simple to adapt and change? If you don’t manage complexity during change, you can be sure that complexity will increase unnecessarily. Moreover, if change becomes too restricted or difficult, innovation will be stilted and the evolution of cloud computing will not reach its true potential. In this tutorial, Joe DeRosa and Hervé Crespel give you some relevant answer to “managing complexity” and “keeping it simple.”  They present both technical and management aspects of cloud computing and complex systems.


Hervé and Joe bring deep knowledge of cloud computing and complex systems, respectively.  They explain what cloud computing is, what complexity is, and how the “cloud” must be constructed and managed to harness its power.


Part 1: Cloud Computing Overview

In this part, Hervé presents the cloud computing market and solutions and asks some relevant ques­tions about complexity.

Part 2: Complexity management overview

In this part, Joe shows how the previous questions relate to complexity showing what complexity is, what it is not, and how one harnesses its power.

Parts 3 and 4: Solutions and advice for properly building cloud computing.

In these parts, Hervé and Joe deal with the same questions proposing solutions and explaining why they would be simple and efficient.  Among these solutions: using Architecture 4.0 model and managing the “commons of the cloud.”

Sample problem: cloud services are proprietary and enable vendor lock-in

Cloud computing brings services which are fully proprietary, both in their conception and in their APIs. Enterprise services are already fully proprietary and that is the main reason why it is so difficult to connect enterprise services. If enterprises are using the same cloud services, it could be simpler to connect. But, if a company prefers to avoid vendor lock-in, it has to implement 2 proprie­tary services from 2 vendors in order to be able to change vendor anytime.  This problem is exacerbated with multiple vendor implementations.  So how do you choose a cloud service and build an efficient implementation. Architecture 4.0 is a useful model for that.

Some questions to be answered

  • What is cloud computing?  Is it easier to store, compute exchange and share information?
  • How does the cloud make possible a new kind of system: Personal Information System.
  • What are the various strategies companies are taking to implement it?  Which approaches are proprietary and which are “open”?   Is the cloud providing us with standard services?
  • If we store data in the cloud or develop applications over the cloud, is it easy to change cloud providers?
  • If we use a cloud service, is it easy to use another service?
  • Do I need to change my software development processes?  Deployment processes?  Business processes?
  • How does complexity play into cloud computing?  When is the complexity useful? When is it increased unnecessarily?
  • What are strategies for managing complexity?  How do you build a service-oriented enterprise?



The presenters

Dr DeRosa has over 25 year experience in software and systems engineering. He retired from the MITRE Corporation as Director of Systems Engineering, where he oversaw the systems engineering of numerous major government programs and participated in research in complex systems. He is now an industry consultant specializing in complex systems engineering. He has delivered papers on the subject worldwide at IEEE, INCOSE and ICSSEA conferences, delivering a keynote address at ICSSEA 2008 and a complexity tutorial at ICSSEA 2011. He was a former staff member at Massachusetts Institute of Technology (MIT) Lincoln laboratory and Director of Business Development for LINKABIT Corporation, as well as an industry consultant to many aerospace firms. He has a PhD in Electrical Engineering and did post-graduate studies at the Santa Fe Institute, the New England Complex Systems Institute and Babson College Business School.
Hervé Crespel, pioneer of object design and agile software, has 31 years of experience in a very large information system. Melting theory, management and practice, as CIO, CTO, innovation director, software quality control director and urbanism and enterprise architecture leader, he has acquired a wide knowledge from technical to functional, able to manage IT experts, and to make programs, architecture or large budget decisions. He has introduced in his company the first PC, the first laser printer, or the first network. He was also introducing pdf and CD-ROM in 1994, Java in 1997, XML in 1999 or Adobe Flex in 2005. Now retired, he is running a small company with the purpose to cross and exchange the best practices for doing sustainable software.