Chris Rupp auf der JAOO 2008 in Dänemark

Die Eroberung der Welt geht weiter…. Nach dem Chris dieses Jahr bereits in Australien, Österreich, Schweiz und Neuseeland Vorträge gehalten hat, ist das nächste Ziel die JAOO Konferenz in Aarhus Dänemark.

Die JAOO Konferenz findet vom 28.09. bis 03.10.2008 statt und spricht vor allem Themen wie Software Technologie, Methoden, Java, Programmierung, Architektur und Best Practices an.
Wenn Sie also Chris (und andere Speaker) mal wieder live erleben möchten, dann haben Sie mit dieser Konferenz gleich die doppelte Möglichkeit dazu: Sie hält hier den Vortrag „Clairvoyance for connoisseurs? Identifying your clients needs and documenting the same“ und ein Tutorial mit dem Titel „Still specifying or are you already implementing? – How much requirements engineering is enough?“. Das Tutorial ist vor allem an Architekten gerichtet. Weiter unten finden Sie die Abstracts zu den Beiträgen.

Link zur Konferenz-Webseite:

Presentation: „Clairvoyance for connoisseurs ? Identifying your client’s needs and documenting the same“

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.

Tutorial: „Still specifying or are you already implementing? – How much requirements engineering is enough?“
(Time: Sunday 13:00 – 16:00)

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 do 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?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

+ 2 = elf