<<< Previous speaker next speaker >>>

Founder and General manager Chris Rupp, SOPHIST GROUP

Founder and General manager Chris  Rupp Chris Rupp is the founder of NLP-based requirements engineering. She has developed and published pattern-oriented approaches to development. She is the author of numerous international publications and continues to work as a coach and consultant. Mrs. Rupp is the founder and general manager of the SOPHIST GROUP. She is an expert in, among other things, natural linguistics and object-oriented methods, as well as organizational psychology and neuro-linguistic programming (NLP). Mrs. Rupp may be reached at Tel: +49 40 900 0 or via E-mail: chris.rupp@sophist.de.

Presentation: "Clairvoyance for connoisseurs - Identifying Your Client's Needs and Documenting the Same"

Time: Tuesday 11:30 - 12:20

Location: Store Sal


A comprehensive understanding of what your clients and users need is the decisive factor in system development. Ever more frequently, architects and developers are granted the dubious pleasure of confronting requirement-donors and being responsible for ascertaining requirements.

But do you know how to best identify and extract all the conscious, unconscious and subconscious requirements your users and stakeholders harbor? Modern requirements engineering methods offer a variety of alternatives to cumbersome interviews and lengthy specifications.

When trying to galvanize the users and complete projects in "internet-time", the correct and intelligent use of investigative techniques is a key competence. If the requirements are fragmentary, unspecific, unclear or just plain nonexistent - guess who gets to pay the bill: the architect. It does thus really pay off to actively warrant that all the requirements have been collected in a professional fashion, that the specification is thorough and the wordings exact.

The knowledge collected must then be documented, in order to guarantee its readability, feasibility and serviceability. Using examples, the lecture will illustrate how to check if all the most important ideas of the stakeholders where accounted for in the specification and if the document is airtight or just another air bubble.

Workshop: "Still specifying or are you already implementing? - How much requirements engineering is enough?"

Track: Tutorial

Time: Sunday 13:00 - 16:00

Location: Musikhuset Nr. 222


How much requirements engineering does a project really need? And how much is too much? Especially architects love complaining about two types of specifications – which make life hard, but have become a common sight:

  • sketchy, shallow specifications, which delineate the product-to-be-built altogether too vaguely and where architects have to try and best-guess what future users might desire, or
  • all-encompassing, extremely detailed specifications, where there’s so many constraints that the only viable solutions make life really hard for the involved

When it comes to the level of comprehensiveness of a specification, worlds lie between what the classic process models deem appropriate and what an agile approach would prescribe. Thus when it’s time to pick and choose, make sure you opt for a methodology that suits the risks and constraints you have identified with your project.

We believe that, during projects, the key risks are the best indicator for how much methodological drudgery is really necessary – once you’ve managed to minimize the hazards, you can stop. In a word: as little as possible but as much as necessary!

Sadly this simple maxim is often neglected. When people specify, they use the wrong methods, the wrong notations and cause disarray rather than institute clarity. The lecture will demarcate the significant factors which influence the operating expenses during you project and which govern the selection of apt notations and methods of requirements engineering. Moreover, we will be taking an in-depth look at those focal points during the process where you – as an architect – are called-upon to question results or denote the proceeding course of action.

The lecture will answer the following questions:

Why doe specifications today look like they do – and how may we turn that to good account?
How can I, an architect, recognize a good specification?
Where is my input sought-after and crucial?