Configuring and applying complex requirements processes in organisations remains a challenging problem. This paper reports the application of the Map-driven Modular Method Re-engineering approach (MMMR) to a research-based requirements process called RESCUE in order to identify omissions and weaknesses, and to reason about improvements to RESCUE that are currently being implemented. Results have implications for both the scalability and effectiveness of the MMMR approach and for innovative requirements processes such as RESCUE.
Establishing the requirements for software-based socio-technical systems remains a
challenge for many organisations. One reason for this is the increasing complexity of
the processes needed to establish such requirements effectively. As a consequence, we
need tried-and-tested techniques for manipulating and adapting these requirements
processes so that they meet the needs and constraints of client organisations. This
paper reports the results of a collaboration between method engineering and
requirements engineering researchers to apply one formalism – the MAP formalism
[
Our objectives for this work were two-fold: (1) to validate and extend the
RESCUE process and improve its effectiveness in future requirements engineering
projects, and (2) to test the utility of the map-driven method re-engineering (MMMR)
approach [
In the next section we briefly describe the MMMR approach. Section 3 introduces the RESCUE process. Section 4 describes how we re-engineered RESCUE using MMMR. Section 5 reports how RESCUE was extended using this re-engineering work. Section 6 concludes the paper.
Our approach for modular method re-engineering uses the MAP formalism [
Fig. 1 depicts the process model of the MMMR as a map. This process model helps to represent every method as a map with its associated guidelines. According to the map structure, re-engineering the process model of a method consists in redefining it in terms of map sections and their guidelines. For this reason, our process (Fig. 1) seeks to achieve two core intentions: Define a section and Define a guideline and proposes a set of strategies to satisfy these two intentions. For example, we can identify map sections By structural analysis of the method product model elements or By functional analysis of its process model steps and activities. The definition of new sections based on the existing ones may be achieved By decomposition of an existing section into several ones, By aggregation of a set of sections, By elicitation of alternative sections to a given one, and By progression strategy which helps to define a new section allowing to progress in the map from the existing one. The Template based strategy provides a template for every type of guideline (IAG, ISG and SSG) while the Guided strategy helps novices with more detailed recommendations for guidelines definition. The Modification strategy helps to revise the existing sections while the Correction strategy allows to transform the existing sections due to some guideline modification. The Completeness validation ends the re-engineering process by verifying if all the guidelines have been defined.
The RESCUE (Requirements Engineering with Scenarios for User-Centred
Engineering) process [
The synchronisation checks applied at these 5 points are designed using a
RESCUE meta-model [
The re-engineering of RESCUE started by defining the map at the higher level of abstraction, then by detailing the IAG associated with each of its sections as lower level maps. As RESCUE is process-oriented, the Functional analysis strategy was applied to identify the sections of its map. This identification was based on the analysis of the five main RESCUE stages and their objectives. Therefore, five main intentions were identified: Agree on System Boundaries, Specify Use Cases, Generate Scenarios, Specify Requirements and Validate Requirements. Besides, the strategies allowing to achieve these intentions was named and ordered. For example, the Multiperspective modelling strategy proposes different models, such as human activity model, context model and use case model, to achieve the intention Agree on System Boundaries. The Creativity workshop driven strategy proposes to organise creativity workshops in order to Specify Use Cases. The intention Generate Scenarios is realised with ART-SCENE tool which generates scenarios automatically from the previously specified use cases. The Scenario Walkthrough strategy is proposed to Specify Requirements. The Impact Scenario Analysis strategy is used to Validate Requirements by analysing the impact of scenario execution and requirements correction, while the Feedback strategy is used for new requirements acquisition and specification if necessary. The RESCUE process ends by delivering the complete set of requirements specifications. We called this strategy the Delivery strategy.
Each intention in the RESCUE map should be modelled at the same level of abstraction. However, the scenarios produced by achieving the intention Generate Scenarios are only used as a means to specify requirements in a specification that is the main achievement from RESCUE. Therefore, the Aggregation strategy (Fig. 1) was applied and the intentions Generate Scenarios and Specify Requirements were merged into a new one Specify Complete Requirements.
As each RESCUE stage ends by synchronising the results of that stage, we added three new sections allowing to reiterate the execution of the intentions Agree on System Boundaries, Specify Use Cases, and Specify Complete Requirements, following the With synchronisation workshop strategy. Fig. 2 depicts the obtained first level RESCUE map.
Each IAG associated to the RESCUE map can also be defined as a map following the MMMR approach (Fig. 1). Fig. 3 illustrates the map (in solid lines) representing the IAG associated to the RESCUE map section <Specify Use Cases, Specify Complete Requirements, With generated scenario walkthrough>. The RESCUE team generates scenarios and walking through them using ART-SCENE to discover requirements by using different walkthrough techniques. Requirements are documented using the VOLERE shell. 5
In order to validate and extend the RESCUE process we explored all its second level maps. First of all we analysed the intentions having only one strategy in the current version of RESCUE and considered other possible ways to achieve these intentions. For example, we considered possible new strategies to enhance the complete requirements specification process captured in the map depicted in solid lines in Fig. 3. As a consequence, 9 new strategies and one new intention were identified and modelled. They are shown in Fig. 3 in dashed lines.
The new intention, Explain System, was added to the map in response to questions about how the process ended. Not all instances of the process result in documented requirements. Scenarios can also be used as effective communication and explanation devices for a new system, independent of their use to discover requirements.
Two new strategies, Video Generation with ART-SCENE and By Video
Walkthrough were designed to produce the agreed scenario and discover requirements
by using the recent extensions to ART-SCENE to support multi-media representation
of scenarios and video-based scenario walkthroughs [
We hypothesise that all these new strategies will result in more correct and consistent discovery and documentation of requirements. 6
This paper reports a research-driven investigation of the MMMR approach to reengineer the RESCUE requirements process. Findings were relevant for RESCUE and MMMR. Development of the process models revealed important omissions and single strategy intentions in RESCUE that we resolved by adding new intentions and strategies to the process models. This led us to re-investigate existing literature about scenario-driven requirements processes, and to undertake cost-benefit analyses of RESCUE strategies that we will investigate through future RESCUE rollouts. Existing process representations of RESCUE did not afford such analysis. The MMMR process maps also gave the authors confidence that changes to RESCUE were consistent with the existing process. The result was an agenda of improvements to RESCUE and its software tools that we are currently implementing.
The paper also demonstrates the effectiveness of MMMR for modelling large-scale requirements processes. Modelling intentions and strategies, rather than processes and artefacts was tractable and cost-effective whilst still allowing the discovery of missing or weak elements of the process.