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?