Alistair Mavin

dblp:25/2890 · DBLP profile ↗
← Back
12ranked-venue papers
7as first author
0since 2021 · last 2019
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 11 · 7 first-authorApplied, interdisciplinary, general and emerging computing · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Requirements engineering and software design · 100%

Topics — the 1 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Requirements engineering and software design
requirements validation
0.212013
Computational alignment of goals and scenarios for complex systems · ICSE 2013

Methods — techniques the papers use, named apart from their topics

scenario analysis · 0.2goal analysis · 0.2computational alignment · 0.2
YearPublicationVenuePosition
2019 Towards an Ontology of Requirements Engineering Approaches
abstract
Requirements are a key factor in determining the success or failure of the system development process. Requirements engineering is a creative problem-solving process whose primary purpose is to enable researchers and practitioners to apply appropriate theories, models, techniques and tools to understand and support the requirements processes more effectively. However, there is a multitude of ways to conduct the requirements engineering process and the quality of the requirements can be greatly influenced by the approaches employed. While consensus exists that no one approach works in all situations, how do practitioners and researchers select the most relevant and appropriate approach(es)? In order to understand this, we argue that a community-based effort is required to organise the plethora of requirements engineering approaches into an ontology. Such a structure would provide an opportunity to identify gaps and to improve the interfaces between approaches. Crowdsourcing the development and validation of such an ontology would facilitate its application across different system types and application domains.
Alistair Mavin, Sabine Mavin, Birgit Penzenstadler, Colin C. Venters
RE1
2017 Does Goal-Oriented Requirements Engineering Achieve Its Goal?
abstract
The number of papers and articles on goals would suggest that goal-oriented requirements engineering is a well understood and mature area within the requirements engineering discipline. In particular, there is a wealth of published material on formal goal modelling approaches. However, the uptake of the goal approaches advocated by academics and researchers within real world settings appears to be quite low. Where goals are used in industrial practice their use is mainly informal and the methods used are inconsistent. There appears to be a significant gap between research and practice in the use of goals within requirements engineering. A two-part study was undertaken to check whether there is evidence to support this view of a disconnection between research and industry. Firstly, a literature survey of requirements engineering papers about goals reveals a large body of published material, but the majority has little industrial involvement. Secondly, a questionnaire completed by experienced requirements engineering practitioners suggests that use of goals in practice is inconsistent, informal, and rarely utilises formal modelling approaches. This paper proposes future work that would close the gap between research and practice in the use of goals within requirements engineering.
Alistair Mavin, Philip Wilkinson, Sabine Teufl, Henning Femmer, Jonas Eckhardt, Jakob Mund
RE1
2016 Listens Learned (8 Lessons Learned Applying EARS)
abstract
The Easy Approach to Requirements Syntax (EARS) is an approach for authoring natural language requirements using a simple template with an underlying ruleset. EARS applies a series of keywords to denote separate clauses within a requirement. Application of the template produces natural language requirements in a small number of patterns. EARS has proved popular with practitioners for numerous reasons. It is lightweight, easy to learn and easy to use. It helps authors to write clear, simple requirements that are easy to read and easy to check for errors. In this paper, four experienced EARS practitioners reflect on their experiences of applying the approach in numerous projects in diverse domains over a six year period. The paper provides an overview of the types of project in which EARS was implemented and describes the deployment methods used. During the course of these projects, numerous lessons were learned. The EARS practitioners discussed the lessons to reduce bias and to ensure the generalizability of the results. These include eleven general lessons concerning requirements engineering, elicitation and natural language specification. The main contribution of the paper is the eight key EARS-specific lessons learned during these deployments. These lessons learned are generalized and will scale to any EARS deployment. The lessons learned will be beneficial to practitioners who wish to deploy EARS in their own projects.
Alistair Mavin, Philip Wilkinson, Sarah Gregory, Eero Uusitalo
RE1
2013 Computational alignment of goals and scenarios for complex systems
abstract
The purpose of requirements validation is to determine whether a large requirements set will lead to the achievement of system-related goals under different conditions — a task that needs automation if it is to be performed quickly and accurately. One reason for the current lack of software tools to undertake such validation is the absence of the computational mechanisms needed to associate scenario, system specification and goal analysis tools. Therefore, in this paper, we report first research experiments in developing these new capabilities, and demonstrate them with a non-trivial example associated with a Rolls Royce aircraft engine software component.
Dalal Alrajeh, Alessandra Russo, James Lockerbie, Neil A. M. Maiden, Alistair Mavin, Mark Novak
ICSE5
2013 Collaborative creativity in requirements engineering: Analysis and practical advice
abstract
Requirements engineering (RE) often entails interdisciplinary groups of people working together to find novel and valuable solutions to a complex design problem. In such situations RE requires creativity in a form where interactions among stakeholders are particularly important: collaborative creativity. However, few studies have explicitly concentrated on understanding collaborative creativity in RE, resulting in limited advice for practitioners on how to support this aspect of RE. This paper provides a framework of factors characterising collaborative creative processes in RE. These factors enable a systematic investigation of the collaboratively creative nature of RE. They can potentially guide practitioners when facilitating RE efforts, and also provide researchers with ideas on where to focus when developing methods and tools for RE.
Martin Mahaux, LeMai Nguyen, Olly Gotel, Luisa Mich, Alistair Mavin, Klaus Schmid
RCIS5
2013 A new paradigm for applied requirements engineering research
abstract
This position paper reflects on recent work that sought to make positive changes to the IEEE Requirements Engineering conference (RE), and on twenty years of requirements engineering (REng) research. We question the values that seem to underpin RE, and offer what we believe are more appropriate values. We argue that these new values would result in better alignment between research and the needs of industry. Further, the new values would encourage more rewarding work for researchers, and would lead to a better RE conference. We summarise the value shift in a draft manifesto for applied research in REng. To illustrate the potential for concrete changes, we suggest one possible wiki-based model for REng research that could deliver these new values.
Martin Mahaux, Alistair Mavin
RE2
2012 Choose Your Creativity: Why and How Creativity in Requirements Engineering Means Different Things to Different People
Martin Mahaux, Alistair Mavin, Patrick Heymans
REFSQ2
2010 Big Ears (The Return of "Easy Approach to Requirements Engineering")
abstract
During a previous study, five simple templates were proposed to improve the quality of Natural Language requirements. That study applied the Easy Approach to Requirements Syntax (EARS) templates to the requirements for the certification of an aero engine control system contained in an airworthiness regulatory document. This paper reports on a wider series of experiments, which applied the templates to several different sets of requirement documents. Back-to-back comparisons were undertaken for documents before and after the application of the EARS templates. During these studies the templates were refined, known limitations of EARS were addressed and metrics were collected. The results strongly support the hypothesis that a small set of simple requirement structures would be an efficient way to enhance the writing of high-level stakeholder requirements. The implications of the results are discussed and additional guidance is provided through Lessons Learned, with the aim of making the templates easier to apply.
Alistair Mavin, Philip Wilkinson
RE1
2009 Easy Approach to Requirements Syntax (EARS)
abstract
The development of complex systems frequently in-valves extensive work to elicit, document and review stakeholder requirements. Stakeholder requirements are usually written in unconstrained natural language, which is inherently imprecise. During system development, problems in stakeholder requirements inevitably propagate to lower levels. This creates unnecessary volatility and risk, which impact programme schedule and cost. Some experts advocate the use of other notations to in-crease precision and minimise problems such as ambiguity. However, use of non-textual notations requires translation of the source requirements, which can introduce further errors. There is also a training overhead associated with the introduction of new notations. A small set of structural rules was developed to address eight common requirement problems including ambiguity, complexity and vagueness. The ruleset allows all natural language requirements to be expressed in one of five simple templates. The ruleset was applied whilst extracting aero engine control system requirements from an airworthiness regulation document. The results of this case study show qualitative and quantitative improvements compared with a conventional textual requirements specification.
Alistair Mavin, Philip Wilkinson, Adrian R. G. Harwood, Mark Novak
RE1
2008 Using Scenarios to Discover Requirements for Engine Control Systems
abstract
Rolls-Royce control systems are complex, safety critical and developed in ever-compressed timescales. Scenario techniques are utilised during systems design, safety analysis and systems verification. Scenarios can be used to improve requirements quality and to ensure greater confidence in requirements coverage for both normal and exception behaviour. A study was undertaken to investigate whether the ART-SCENE process and tool could enable engineers to identify exception behaviours earlier in the system design process, thus reducing cost and improving quality. ART-SCENE provides automatic generation of scenarios and alternative course events through the Scenario Presenter. These recognition cues are used to prompt engineers to identify deviations that may otherwise be missed. This paper describes a comparative evaluation between ART-SCENE and a standard hazard identification technique to assess the effectiveness of this approach.
Alistair Mavin, Mark Novak, Philip Wilkinson, Neil A. M. Maiden, Perry Lynch
RE1
2003 Determining Socio-Technical Systems Requirements: Experiences with Generating and Walking through Scenarios
abstract
Scenarios are effective for discovering requirements, but we still do not understand what types of scenario and which walkthrough techniques are most effective. We report the application of one scenario approach - CREWS-SAVRE - to discover requirements for naval and air traffic management systems with BAE Systems and Eurocontrol respectively. Results from these experiences are used to investigate important questions about the effectiveness of structured scenario walkthroughs and the level of domain-specificity most beneficial to the discovery of requirements. Lessons learned suggest that systematic walkthroughs of simple scenarios that do not contain excessive domain knowledge are more effective for discovering system requirements. This provides the reader with simple-to-use guidelines for scenario-based requirements discovery.
Alistair Mavin, Neil A. M. Maiden
RE1
2002 Requirements Engineering: How Do You Know How Good You Are?
abstract
Organisations are seeking to improve the way they undertake engineering activities. There are numerous ways of doing this, one of which is to undertake an on-going process, or capability, enhancement activity. Praxis Critical Systems Limited provides support for such activity based primarily around the REVEAL/spl reg/ requirements engineering method. By providing customised training and coaching in REVEAL/spl reg/, we aim to build up a long-term sustainable skill in the client's organisation. Both Praxis Critical Systems Limited and the client need to measure the effectiveness of the knowledge transfer. To meet this need we have developed the REVEAL/spl reg/ Competency and Assessment scheme. We discuss the steps in this process and share some experiences of using the scheme both in-house and with two major clients.
Andrew Vickers, Alistair Mavin, Helen May
RE2