Suzanne Robertson

Integrating creativity into requirements processes: experiences with an air traffic management system

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.

Integrating creativity workshops into structured requirements processes

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 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.

Can Requirements Be Creative? Experiences with an Enhanced Air Space Management System

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.

Developing use cases and scenarios in the requirements process

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 UKs 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.

Requirements Management: A Cinderella Story

Why do the business requirements and the final software product often have little in common? Why are stakeholders, developers and managers reluctant to embrace a full requirements process? Why does everybody say, ‘We don’t have time for requirements’? Why is the potentially most beneficial part of the development process ignored or short-changed? Following are some observations about why the real requirements for the product often go undiscovered. We will address this by focusing on the different concerns of the people involved in requirements.

What influences the requirements process in industry? A report on industrial practice

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 organisations own standards, tools, the regulator, first principles, and experienced colleagues. Sources of process knowledge outside organisations had little influence.

Visibility: the key to quality improvement

Sometimes we forget that software is part of a larger system, which includes not only people and hardware, but possibly different organizations and even cultures. The author, principal in the Atlantic Systems Guild, shows us how, by viewing software from a systems perspective, we can take advantage of these diverse information sources to make problems visible and improve the softwares quality. >

Making Requirements Measurable

Background Eliciting and specifying customer requirements in a precise and unambiguous way is critical to the success of a project. However anyone who has done any requirements engineering also knows that it is a very difficult activity involving many diverse skills. An important reason for the degree of difficulty is that requirements engineering involves many different people. Each person has his own opinion of what is or is not a requirement. Customers often find it difficult to articulate their requirements and for large, complex systems these requirements are often conflicting.