If you want to know how to capture the hidden assumptions and reasons that form the rationale for project decisions, this tutorial is for you.

In this half-day tutorial, participants learn the pros and cons of different approaches to defining project rationale, and are introduced to practical techniques for discovering assumptions and clarifying the reasons for decisions.

The tutorial takes you through the concepts and techniques that have been used to try to capture rationale. The philosophical background of these concepts is briefly introduced to make clear the structure of the different approaches. The tutorial is illustrated with diagrams and examples from industry.

A practical group exercise will give participants the chance to try out some of the skills for themselves, with feedback from the other groups and the tutor.

Participants will take away an understanding of how to handle rationale better on projects of different types.

The tutorial is designed for requirements practitioners, but it should also be of interest to students and researchers in related fields who would like to gain insight into the issues around rationale modelling. No prior knowledge of requirements is assumed, but experience on development projects is a definite advantage.

Understanding the social and organizational context is critical to the success of many systems today. The i* framework offers an agent-oriented approach to requirements engineering. By explicitly modeling and analyzing strategic relationships among multiple actors, the approach incorporates rudimentary social analysis into a systems analysis and design framework. Actors depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. A notion of softgoal is used to deal systematically with quality attributes, or non-functional requirements. Dependencies among actors give rise to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a qualitative reasoning procedure. During systems design, actors explore alternative configurations of dependencies to assess their strategic positioning in a multi-agent, social context.

This tutorial will introduce, explain and demonstrate the i* framework with examples, and describe how to use it during the early stages of the requirements process.

Writing requirements is often seen as a "stenographer's task" - one where the requirements engineer passively records the stakeholders' needs. However, this approach relies on stakeholders knowing what they need, and what they want. Experience tells us that except for rare visionaries, people cannot know what they want until they see it. Many of the useful products that we take for granted today, did not come about from the stakeholders' requests, but from invention and innovation. The mobile phone, text messaging, the World Wide Web and many, many others are innovations, often built from existing components. Commentators are increasingly in agreement that the businesses which will thrive in the next decade will be those that make innovation a regular part of their development process. In this tutorial we explain how to use creative and innovative techniques to bring about more useful, usable and competitive products. We provide examples and illustrations from our experience in air traffic management and automotive engineering. We provide a guide for innovation, and show participants how it is used. Finally, we present some examples of software support tools that can be used to stimulate creativity in the context of the requirements process.

There has been a steady call for the use of empirical methods in requirements engineering and related disciplines such as software engineering and information systems to increase relevance. As a result, the use of empirical methods has increased, but there is continuing concern about the elevance of empirical research results: and "Why go through the trouble of doing empirical research to find out what we knew already ?" and "Why produce empirical knowledge that cannot be used to solve a practical problem?" are frequently heard complaints. There is also concern about the proper integration of empirical research into engineering: "How can we investigate solutions that are not implemented yet, and therefore cannot yet be observed in reality? Let;s implement this and then see what happens"

This tutorial starts from a simple distinction between technology as the design and production of useful artefacts, and requirements engineering (RE) as the mutual alignment of artefacts and the desires of their stakeholders. Research, on the otherr hand, is the investigation of properties of phenomena: For example, properties of artefacts, properties of the problems they solve, properties of the problems they create, and properties of their stakeholders. This tutorial shows how to integrate research into requirements engineering in two ways.

1. For the RE practitioner, the mutual alignment of stakeholder desires and technical solutions requires investigating those desires and validating the solutions. The tutorial shows how this investigation and validation can be done in a critical, scientific way.

2. The RE researcher develops and investigates techniques to be used by the RE practitioner. This tutorial shows how to investigate the RE process and to validate the techniques developed for it.

This tutorial differs from other tutorials on empirical methods in that it does not restrict itself to guidelines for designing empirical research, but also explains how to apply empirical methods in the engineering cycle, and how to apply this in RE practice as well as in RE research. It explains the structutre of the engineering cycle and show the elements of problem identification, analysis, structuring and diagnosis, as well as the logic of solution validation. The tutorial classifies different kinds of research questions and gives a checklist for designing and validating empirical research. The tutorial treats the general structure of different kinds of empirical research, and emphasises qualitative methods such as case study research. We look at the difference between lab experiments, field experiments, action research and field trials and case studies. Finally, the tutorial shows how research problems can be embedded inside engineering problems and vice versa, which gives rise to such nested approaches as action research and action science. To illustrate the methods and techniques, many examples are given, and the participants are given the opportunity to apply the concepts to their own practice. This tutorial treats the various methods of empirical research in a general framework but does not treat the details of experiment design nor does it treat statistical data analysis methods.

Requirements engineering (RE) is a nascent discipline. Practitioners rarely agree on what makes a "best practice." Researchers rarely agree as well. The proceedings of the 16 years of the IEEE requirements engineering conferences contain hundreds of papers claiming that this method or that tool or these languages are somehow "better" than the rest. The reality is we really don't know. Even the most fundamental issues are yet to be resolved. This tutorial will explore ten or so open issues relating to requirements engineering. It will have a flavor unlike any tutorial yet provided at the RE conferences. The instructor will pose a series of "open issues" on requirements engineering. For each issue, the instructor will argue vehemently for the "pro" position for 15 minutes. Then he will argue equally vehemently for the "con" position for 15 minutes. This way the audience will see both sides of each argument. After both sides for an issue are made, the audience will be asked to vote on which position they believe.

Issues may include: (a) You can elicit all requirements via collaborative meetings, (b) Prioritizing requirements is easy: just rank them from 1 to n, (c) Requirements fall right out of business strategy, (d) The marketing department should be in complete control of requirements, (e) Reduce requirements change, (f) You must fully understand the market and the industry before writing requirements, and (g) Requirements should be written in language x.

Society is currently experiencing an exploding demand, accompanied by an equally accelerated dependency, on one commodity - information. Fortunately, our technologies are racing ahead in a Moore's Law confirming way. Less fortunately, human minds and organizations haven't displayed the same aptitudes for change, appearing to be locked into Miller's "Magical Number Seven Plus or Minus Two." We are seeing a need to use our minds and organizations more effectively in order to make good use of new technologies and to meet these growing demands and dependencies.

We will examine, in this tutorial, some of the challenges that we human beings are discovering in the design of systems capable of exploiting technology's accelerating contributions. We explore a design strategy based on full life-cycle requirements engineering involvement, "from the gleam in marketing's eyes, through delivery, into sustained periods of maintenance and upgrades, and on to replacement."

We discuss and illustrate a series of difficulties directly encountered in the design of systems recently drawn from such areas as imbedded automotive, global finance, telecommunications, and healthcare systems design. We propose a requirements oversight template created to catch inconsistencies at the business, systems, and functional requirements levels and to aid in total life-cycle project traceability. We will demonstrate improved effectiveness in information discovery, development, and integration by way of effective issues and assumptions management, formal - requirements driven - design reviews before, during and after development, and design decision traceability assuring due diligence through enhanced design visibility.

One of the most used elicitation techniques is the interview. For many, the art of conducting a successful interview with a stakeholder is still a puzzle. Often the following questions are raised:

• How do I tickle the requirements out of the interviewee?
• What should I do, when the interviewees have difficulty to describe their requirements?
• Etc.

Quality has to be built in at the beginning. The quality of software can be defined as the extent to which the requirements on it are fulfilled. So it is important to elicit the correct requirements. A common elicitation technique is the workshop. In this tutorial we will show how to prepare and run elicitation workshops to achieve maximum effect and increased quality of the requirements that get elicited. The roles of participant, moderator, consultant and scribe will be played out during the tutorial.

This tutorial is aimed at persons whose job it is, to elicit requirements. The goal is to enable the tutorial participants to efficiently plan, conduct and document interviews. The roles of interviewer, interviewee and scribe will be played out during the tutorial. Through discussion and exchange of experiences you can gain lots of tips and find out what the usual hazards are. You will learn how to organise your elicitation interviews in a better way. And have lot of fun at the same time!

When the requirements and the interaction design of a system are separated, they will most likely not fit together, and the resulting system will be less than optimal. Even if all the real needs are covered in the requirements and also implemented, errors may be induced by human-computer interaction through a bad interaction design and its resulting user interface. Such a system may even not be used at all. Alternatively, a great user interface of a system with features that are not required will not be very useful as well.

Therefore, we argue for combined requirements engineering and interaction design, primarily based on usage scenarios. However, scenario-based approaches vary especially with regard to their use, e.g., employing abstract use cases or integrating scenarios with functions and goals in a systematic design process. So, the key issue is to be addressed is how to combine different approaches, e.g., in scenario-based development, so that the interaction design as well as the development of the user interface and of the software internally result in an overall useful and useable system. In particular, scenarios are very helpful for purposes of usability as well.

This advanced tutorial encourages much discussion and involvement of the participants in order to make it as interactive as possible. It will consist of lectures, group discussions and individual paper exercises. The technical points made will be illustrated with running examples throughout.

Mass Customization is the customization and personalization of products and services for individual customers at a mass production price. From an engineering perspective, mass customization means to develop a product line which can be easily repeated but which is flexible enough to be tailored to meet individual customer demands effectively and efficiently. Successful mass customization implies the efficient management of the variability between products across the product line lifecycle i.e. requirements, design, build, test. This tutorial discusses techniques, experiences and open issues about managing the variability of product line requirements which for complex, highly reliable products must be well-structured, understandable, complete, consistent, and controlled.

One approach to managing these problems is to establish a pool of reusable requirements and to construct the requirements for a new product by making a selection from the pool. A concern of this approach is the efficient and clean selection of a consistent combination of requirements. A consistent combination is one in which the requirements selected satisfy any constraints imposed by the pool of reusable requiments. Critical issues are the management of requirements variability across different products and the management of inter-dependencies between selection decisions from the pool. We address these concerns, present results of using these techniques for real-world applications, and describe some software tools that can be used to support them.