Business analysts are just as indispensable as they always have been, but now we need to work differently, in a more agile way, to fit with agile development. This talk shows you how to do that. It is about three things: Too many projects start with an assumed solution, often by recording this assumed solution as a backlog. This talk shows you a better way to start.; Spend enough time with the customers to understand their work, their desired outcome, and what it is they value. We talk about generating alternative candidate solutions and testing them using quick, safe-to-fail probes. The justification for multiple candidates is to get away from the assumed solution, and validate the customer's problem space by exploring different ways to solve it.; Use a story map to organise the stories written by the business analysts. The BAs write the stories in units corresponding to business events. The product owner prioritises the story map (which is in effect prioritising the business events) and thereby synchronises the work of the business analysts with that of the developers.

Requirements engineering is a creative process in which stakeholders work together to create ideas for new software systems that are eventually expressed as requirements. This paper reports a workshop that integrated creativity techniques with different types of use case and system context modeling to discover stakeholder requirements for EASM, a future air space management software system to enable the more effective, longer-term planning of UK and European airspace use. The workshop was successful in that it provided a range of outputs that were later assessed for their novelty and usefulness in the final specification of the EASM software. The paper describes the workshop structure, gives examples of outputs from it, and uses these results to answer 2 research questions about the utility of creativity techniques and workshops that had not been answered in previous research.

Requirements is too often seen as a "stenographer's task", one where the requirements engineer passively listens and records while the stakeholders state their needs. However, this approach relies on stakeholders knowing what they need, and what they want. Experience tells us that except for rare visionaries, people do not 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' imagination, but from an invention. In this tutorial we explain and illustrate how to use creative techniques to invent requirements that result in more useful, usable and competitive products. We provide a guide for invention, and show participants how to use this guide to invent innovative requirements for a familiar system.

Scenarios are often used for discovering requirements using established techniques, but how such scenarios are initially developed is not so well understood. This experience paper reports the application of one scenario-based approach - RESCUE - to discover requirements for DMAN, an air traffic management system for the UK's National Air Traffic Services. A retrospective analysis of the DMAN use cases, scenarios and requirements artifacts revealed the importance of diverse information sources in the specification of use cases that enabled systematic requirements discovery. Results were used to explore 3 research questions that arose in previous studies. The paper reports lessons from this experience and offers guidelines that practitioners can apply in their requirements processes and academics can use to inform their research.

What influences the way people in industry (including commerce and government) do their requirements work? This paper, using a short questionnaire, found that the main influences were training, an organisation's own standards, tools, the regulator, first principles, and experienced colleagues. Sources of process knowledge outside organisations had little influence.

Requirements engineering is a creative process in which stakeholders and designers work together to create ideas for new systems that are eventually expressed as requirements. This paper describes RESCUE, a scenario driven requirements engineering process that includes workshops that integrate creativity techniques with different types of use case and system context modeling. It reports research in which RESCUE creativity workshops were used to discover stakeholder and system requirements for MSP, a future air traffic management system to enable the more effective, longer term planning of European airspace use. The workshops were successful in that they provided new and important outputs for subsequent requirements processes. The paper describes the workshops structures and results, and answers 3 important research questions.

Summary form only given. Good requirements don't just happen; they come from effective practices. And effective practices come from distillation of experience. In her job as a consultant Suzanne Robertson has worked on a wide variety of projects in diverse socio-technical domains. She has had the opportunity to discover good practices by examining the way that successful requirements projects are run and by identifying patterns of behaviour that are common to those projects. This talk is about these requirements exemplars - patterns to emulate - that she has distilled from experience with projects in many different cultures. The talk reviews a selection of requirements exemplars such as: requirements foundation (what's the best base?); product in parallel (two different scopes?); knowledge versus documents (which is which?); rooms with walls (why bother?); maximum disruption (why cause chaos?); linguistic integrity (what language do we speak?); eating the orange (which knife to use?); the waiting room (now or later?); and Lewis and Clark (when to explore the unknown?). Examples from real projects support the discussion along with ideas for how to make use of exemplars in your own environment.

Requirements engineering is a creative process in which stakeholders and designers work together to create ideas for new systems that are eventually expressed as requirements. However, many requirements engineering or software development methods do not encourage or support creative thinking, let alone integrate it with existing modeling and analysis processes. This paper describes RESCUE, a scenario-driven requirements engineering process that includes workshops that integrate creativity techniques with different types of use case and system context modelling. It reports a case study in which RESCUE creativity workshops were used to discover stakeholder and system requirements for DMAN, a future air traffic management system for managing departures from major European airports. The workshop was successful in that it provided new and important outputs for subsequent requirements processes. The paper describes the workshop structure and wider RESCUE process, important results and key lessons learned.

No abstract available.