Founder and General manager Chris Rupp, SOPHIST GROUP

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.

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?