Shamal Faily

John Lyle

Andre Paul
email: andre.paul@fokus.fraunhofer.de

Andrea Atzeni
email: andrea.atzeni@polito.it

Dieter Blomme

Heiko Desruelle

Krishna Bangalore
email: krishna.bangalore@in.tum.de

Requirements Sensemaking using Concept Maps

Requirements play an important role in software engineering, but their perceived usefulness means that they often fail to be properly maintained. Traceability is often considered a means for motivating and maintaining requirements, but this is difficult without a better understanding of the requirements themselves. Sensemaking techniques help us get this understanding, but the representations necessary to support it are difficult to create, and scale poorly when dealing with medium to large scale problems. This paper describes how, with the aid of supporting software tools, concept mapping can be used to both make sense of and improve the quality of a requirements specification. We illustrate this approach by using it to update the requirements specification for the EU webinos project, and discuss several findings arising from our results.

Introduction

Techniques, tools, and artifacts may come and go, yet requirements are a consistent element in a software development project. The needs and expectations of stakeholders motivate the elicitation of requirements that software developers use as a contract for what a system should do. This makes a requirements specification the authority upon which architectural design and software implementation decisions are made.

The perceived usefulness of requirements, however, often fails to extend beyond the initial stages of system design, especially as these are often construed negatively from both a usability and developer perspective. To usability professionals, specifications of system behaviour are agnostic of usability concerns and say little about the needs of people using it. To software developers, they are seen as too abstract to effectively form the basis of an implementation; developers may feel it is easier to prototype a solution and make their own sense of the domain and what needs to be built. Because of this, maintaining system requirements is considered by many to be an unnecessary and cumbersome activity that adds comparatively little value. While this position may be reasonable in projects where all stakeholders are directly involved in the system design, for many projects this is not the case. Customers and prospective end-users may want a precise description of what a system does when explaining the system to other people, or evaluating the system for concerns such as regulatory compliance or value for money. Similarly, security engineers need models of system behaviour upon which their own analysis can be based. In such cases, prototypes that embody what they think the system should do are a poor substitute for a description of what the system is expected to do.

Requirements are seen as static artifacts which, while useful early in a project's life for motivating initial architectural design, are too unwieldy to maintain as a going concern. This perception is not helped by the fact that, as natural language text, they are often hidden away in word processors, spreadsheets, or databases. As developers become more detached from the requirements that form the basis of their work, the rationale for design changes can either become lost or become encapsulated in other design elements. Because of this, when requirements do need to be updated, the revision process can be both tedious and time-consuming. Although research by the Requirements Engineering community has been concerned with how these requirements traceability problems can be prevented, there has been comparatively little work on how these traceability challenges can be addressed once they do occur in real projects. The possible implications arising from missing, superfluous, or ambiguous requirements means that we need creative approaches for addressing these challenges. If such approaches are to be successful, we need to engage the stakeholders responsible for specifying and maintaining these requirements by helping them make better sense of what they are.

In this paper, we present an approach for using concept mapping as a sensemaking technique for requirement specifications. This improves the quality of a requirements specification while also increasing its visibility among project team members. In Section 2, we describe the motivating literature, before presenting our approach in Section 3. In Section 4 we present the results of applying our approach to update the requirements specification for the EU FP7 webinos project, before reflecting on these results and proposing follow-on work in Sections 5 and 6 respectively.

Related work 2.1 Requirements maintainability and traceability

Rather than being concerned with the behaviour of the proposed system, Requirements Engineering is concerned with defining the problem being solved [START_REF] Cheng | Research directions in requirements engineering[END_REF]. While it is tempting to think that, once defined, requirement specifications will be good enough to sustain software engineering activities, changes to the problem space, or modifications to environmental conditions affecting system design might be significant enough to challenge assumptions underpinning a requirements specification, therefore motivating the need to re-evaluate it.

As cases like the Ariane 5 failure have shown, failing to properly analyse existing requirements for their continued relevance can lead to catastrophic results [START_REF] Nuseibeh | Ariane 5: Who dunnit?[END_REF]. Consequently, the importance of rationalising requirements has motivated the need for managing requirements traceability: the ability to describe and follow the life of a requirement, in both a forward and backwards direction [START_REF] Gotel | An analysis of the requirements traceability problem[END_REF]. When properly maintained, requirements traceability provides the rationale for requirements, provides a means for checking their satisfaction, and provides a framework for software tools. Unfortunately, while there is no shortage of requirements traceability frameworks and models, software tools for supporting them are usually restricted to requirements management tools [START_REF] Winkler | A survey of traceability in requirements engineering and modeldriven development[END_REF]. While requirements managements tools are reasonably effective at indicating how requirements are operationalised, Winkler and von Pilgrim found that pre-requirements traceability remains poorly tool-supported. This finding confirms an argument first made by Gotel and Finkelstein [START_REF] Gotel | An analysis of the requirements traceability problem[END_REF], who claimed that pre-requirements specification traceability problems are hard to address because the dynamic nature of the sources and environment from which requirements are drawn makes categorising traces difficult.

One way for dealing with pre-requirements traceability is to employ design rationale tools to externalise the arguments underpinning requirements. For example, Burge [START_REF] Burge | Rationale-Based Software Engineering[END_REF] has discussed how tools like Compendium [START_REF]The Open University: Compendium web site[END_REF] provide a visual language for capturing group discussions and facilitate requirements negotiation. Similarly, Eclipse IDE plugins like Software Engineering Using RATionale system (SEURAT) can be used to capture the source of requirements, in addition to evaluating alternatives and flagging errors when alternatives violate requirements [START_REF] Burge | Seurat: integrated rationale management[END_REF]. More recently, work on the open source Computer Aided Integration of Requirements and Information Security (CAIRIS) requirements management tool [START_REF] Faily | Towards tool-support for Usable Secure Requirements Engineering with CAIRIS[END_REF][START_REF] Faily | CAIRIS web site[END_REF] demonstrated how requirement models can be motivated by usability artifacts such as scenarios and personas [START_REF] Faily | A Meta-Model for Usable Secure Requirements Engineering[END_REF], as well as how argumentation models can be used to structure qualitative data and assumptions underpinning the characteristics of personas [START_REF] Faily | The secret lives of assumptions: Developing and refining assumption personas for secure system design[END_REF][START_REF] Faily | Persona cases: a technique for grounding personas[END_REF].

Sensemaking and concept mapping

While pre-requirements traceability remains a challenge, there is evidence that sensemaking -the process of searching for a representation and encoding data in that representation to answer task specific questions [START_REF] Russell | The cost structure of sensemaking[END_REF] -might assist in understanding where requirements have come from, and where they might ultimately lead. In a long-term study of software development within a company, it was found that relying on rational decisions alone to simplify assumptions increased misunderstanding of products as systems grew [START_REF] Jantunen | Making sense of product requirements[END_REF]. Consequently, the company found that rather than making what appeared to be the most rational decision, it needed to rely on sensemaking techniques to choose the most appropriate course of action. This is because trying to understand the rationale behind a particular decision may lose sight of the contextual factors at play when a decision is made. In the broader context of software engineering, collectively re-organising and synthesising information can help groups of stakeholders make sense of what this information means [START_REF] Russell | Sensemaking for the rest of us[END_REF]. Sensemaking techniques have been used to supplement various aspects of usability evaluation in software design, ranging from re-designing the information architecture for a software platform [START_REF] Dubberly | Using concept maps in product development[END_REF], through to evaluating the usability of APIs [START_REF] Clarke | Making Software: What Really Works, and Why We Believe It[END_REF].

In a sensemaking task of any significant complexity, external representations are important for supporting the cognitive demands made on users, but creating such a representation is itself a significant problem [START_REF] Russell | The cost structure of sensemaking[END_REF]. A popular visual representation for facilitating sensemaking by helping designers absorb knowledge is concept mapping. Concept maps are sensemaking tools that connect many ideas, objects, and events within a domain and, as a result, help organise and visualise knowledge [START_REF] Martin | Universal Methods of Design: 100 Ways to Research Complex Problems, Develop Innovative Ideas, and Design Effective Solutions[END_REF]. Concept maps were first proposed by Novak [START_REF] Novak | Learning How To Learn[END_REF] as a learning tool which allows students to build and reflect on the conceptions of a domain. For example, in a case study in organisational learning [START_REF] Sutherland | Concept mapping methodology: A catalyst for organizational learning[END_REF], individuals made sense of concepts before exposing it to the influence of others and sharing discourse. As such, the technique was able to bring people together and synthesise different views.

Although software tools such as CmapTools [START_REF]IHMC: CmapTools web site[END_REF] can be used to collaboratively build concept maps, these rely on using keyboard and mice as input, potentially making concept mapping less fluid, hindering the co-creation process. Together with work by Klemmer et al. alluding to the benefits of combining the affordances of paper with electronic media [START_REF] Klemmer | The designers' outpost: a tangible interface for collaborative web site[END_REF], this has stimulated a growing interest in the use of tangible interfaces for concept mapping. For example, Tanenbaum and Antle [START_REF] Tanenbaum | A tangible approach to concept mapping[END_REF] created a prototype tabletop system and software application to support the creation and revision of concept maps. This study served as a useful proof-of-concept, but it also highlighted problems such as slow object tracking, and restrictions adding new content; these suggest possible scalability problems when working with larger maps. This scalability problems were confirmed in a more recent study [START_REF] Oppl | Effects of a tabletop interface on the co-construction of concept maps[END_REF] by Oppel and Stary comparing the use of tabletop systems for concept mapping with screen based equivalents. Despite the scalability problems, the study found that the time spent on discussion was significantly higher for tabletop concept maps, and information was less likely to be filtered by 'operators' running the software tool to support the concept mapping process. It was, however, noted that participants of screen based tools tended to focus more on the process of representing the model itself. This issue of representation is important from a Requirements Engineering perspective; concept maps need to be both used and maintained as a system design evolves, and by a potentially larger range of people than those engaged in participatory concept mapping sessions.

Approach

Our approach uses concept mapping to both make sense of and improve the quality of a requirements specification. The approach assumes that an initial requirements specification has already been created, and that the specification is sub-divided into different functional categories. We carry out concept mapping to make sense of a system's requirements, together with the traceability associations that motivate and connect them. In carrying out this exercise, we glean a better understanding of the problem domain the system is situated in. This approach is supplemented by software tools which synthesise concept map data with other requirements artifacts to form a coherent requirements model.

By using software tools to support rather than mediate the concept mapping process, we gain the benefits of tabletop concept mapping without the suffering the scalability problems associated with tangible interfaces, or filtering problems associated with screen based concept mapping tools. The approach also has three other benefits from a broader Requirements Engineering perspective. First, the process of building the concept map also identifies and addresses duplicate or conflicting requirements. When the model is complete, the relationships between the requirements becomes apparent, as well as the most appropriate means for addressing them. Second, because this is largely a group-based exercise, an understanding of what the requirements are and how they contribute towards system design is shared by everyone involved in the process; this also helps to establish what the current scope of the system is, and to address any areas people feel should be addressed but currently are not. Third, the resulting concept map provides a basis for examining how other design artifacts fit into this conceptual model from a traceability perspective. For example, can scenarios or use cases be built into this concept map without changing the structure itself? Does the concept map align with the conceptual integrity of the planned architecture, and do the implementation level items used to drive the implementation align with this model?

This approach is applied in three stages. In the first stage, concept names are elicited from the existing requirements, and concept maps are created for each category of requirements. In the second stage, the concept maps are consolidated onto a single diagram and, as associations are made between concepts from these different sub-maps, the consolidated concept map itself evolves. In the final stage, we validate the concept map by examining how well they align and account for other requirements artifacts, and generate the resulting requirements model. This is not the first time that concept mapping has been proposed as a technique for supporting Requirements Engineering; Kof et al. [START_REF] Kof | Concept mapping as a means of requirements tracing[END_REF] have proposed concept mapping as a generating traces between requirements artifacts. However, our approach differs in two respects. First, Kof et al. are concerned with using concept mapping primarily for supporting the traceability between artifacts at different levels of abstraction, whereas our approach is primarily designed to help designers make sense of the requirements. Second, while Kof et al. uses a frequency profiling algorithm to identify concepts, our approach involves manually inspecting each requirement to infer a suitable concept characterising each requirement. This makes the process more time-consuming, but it better sensitises designers to the requirements themselves.

Category concept mapping

Before concept maps can be created, it is necessary to create a concept name or phrase characterising each requirement. For example, the requirement The train control software shall control the acceleration of all the system's trains can be characterised using the phrase Acceleration control. This short phrase becomes the canonical identifier for each requirement.

For each functional area associated with the specification, concept maps are then created. This involves preparing paper cut-outs of the concept names associated with each requirement, placing them on a large piece of paper and, using a pencil, drawing and annotating the relationship between each concept. This exercise is carried out in groups of between two -four for each part of the problem domain represented by the requirements category. During the exercise, the requirements specification associated with the category is available for consultation. Requirements that are redundant or out of scope are removed from the concept map, and a reason for their omission is noted. Requirements that are unclear or ambiguous are discussed within the group and, where necessary, the requirement's concept name or description is updated as appropriate.

Once each map is completed, it is transcribed to a machine readable format. For this, we use Graphviz [START_REF]AT&T: Graphviz web site[END_REF]; this is a suite of graph visualisation tools, which can layout graphs written in a simple textual language called DOT. Figure 1 illustrates an excerpt of a Graphviz concept map.

Concept map consolidation

Once all the concept maps have been created, they are then consolidated onto a single concept map. Like the category concept mapping exercise, this involves drawing relationships between paper cut-outs of requirements. However, this exercise begins by re-creating each of the individual concept maps based on their respective Graphviz models. Using a similar sized group to the first stage, which includes participants involved in the development of the category concept maps, the concept maps are reviewed to clarify relationships both within and between each category. Like the category concept mapping exercise, unclear requirement descriptions are updated and, where appropriate, those deemed duplicate, redundant, or out-of-scope are removed. Similarly, like the first stage, once this exercise is complete the Graphviz versions of each category concept map are updated to incorporate any revisions and relationships between categories.

Concept map validation and model generation

Building the consolidated concept map not only shows how requirements are connected, it also helps align them with other design artifacts. This is due to the better understanding that the design team gains developing the visual model. For example, zooming out of the concept map can help retrospectively determine which scenarios the requirements were designed to support. Zooming in explores how the elicited use cases operationalise the requirements. This alignment activity also acts as an additional form of validation; by casting the concept map in a different light, existing concepts or relationships are challenged, and new requirements and traceability associations may be identified. Therefore, the final stage involves identifying design artifacts associated with each requirement concept, and updating each category DOT file to include the aligning artifact references. Our approach supports three types of aligning concepts: scenarios, use cases, and backlog items. Backlog items are items of work which are carried out when developing software as part of the Scrum method [START_REF] Schwaber | Agile Project Management with Scrum[END_REF]. This approach does not pre-suppose Scrum is employed, and this concept can be used synonymously for any downstream design and development artifact.

If we reflect on Figure 1 then we discover that while Graphviz is useful for modelling concept maps, something more is necessary for representing requirements traceability. For example, the association between Service discovery and Service identity indicates that concepts are related to different categories, not just those associated with a given DOT file. Pasting the contents of all DOT files into a single file is feasible, but with concepts cross-referenced across different files then some duplication of associations is inevitable. It also desirable to filter these maps in some way, or visualise the consequences of the traceability alignment. Moreover, because other requirements artifacts might be maintained using different representations, there needs to be a coherent requirements models that designers can reference internally and present to others externally.

Because it supports the aligning concepts used by this approach, artifacts were converted to XML and imported into the open-source CAIRIS tool [START_REF] Faily | CAIRIS web site[END_REF]. To better fit this approach, a number of modifications were made to CAIRIS. To complement its preexisting requirements visualisations, an additional graphical view was added to CAIRIS to support the visualisation and manipulation of concept maps; this included the filtering of maps by name or functional category. In this view it is also possible to quickly assess the quality of the requirements themselves using an automated quality gateway check; the metrics are described in more detail by [START_REF] Wilson | Automated quality analysis of natural language requirement specifications[END_REF], and are based on requirements completeness, the presence of an imperative phrase, and ambiguity. These resulting metrics were visualised using cartoon Chernoff Faces [START_REF] Chernoff | The Use of Faces to Represent Points in K-Dimensional Space Graphically[END_REF], where each part of the face represented a different requirement quality variable. Eye-brow shape indicates the completeness of a given requirement. If no text is found in certain fields, or phrases like "TBC", "none", or "not defined" are present, the completeness score is marked down accordingly, and the eye-brows convey a negative mood. The eye shape indicates whether or not an imperative phrase exists in the requirement description. If such a phrase exists then the eyes become vertically elongated. The mouth indicates the presence of weak or fuzzy phrases, such as mostly, appropriate, normal, or adequate; the presence of these phrases turn the smile into a frown. Examples of how Chernoff Faces visualise these quality attributes are given in Figure 2. These Chernoff Faces are also coloured based on their level of pre-and post-requirements traceability.

Requirements with no evidence pre-and post-requirements traceability were coloured red. Requirements which are motivated by other requirements, based on scenarios and use cases, or refined to product backlog items were coloured blue. Requirements with both pre-and post-requirements traceability are coloured green. While it would be unreasonable to expect pre-and post-requirements traceability at early stages of a project, this level of traceability is important for high priority requirements. With this in mind, the labels of high-priority requirements without both pre-and post-requirements trace-

Complete ? Imperative  Unambiguous       ? ?
  Fig. 2. Example Chernoff Faces mapping to requirement quality attributes ability are highlighted in red. This is illustrated in Figure 3 which illustrates a Chernoff Face augmented concept map based on the initial concept map in Figure 1.

Results

We evaluated our approach by using it to update the requirements specification for the EU FP 7 webinos project. webinos is a federated software platform for running web applications consistently and securely across mobile, PC, home media, and in-car systems. More information about the project is described in [START_REF] Fuhrhop | The webinos project[END_REF]. This requirements specification was initially derived from a set of use cases and scenarios [START_REF]webinos Consortium: webinos project deliverable D2.1: Use Cases and Scenarios[END_REF] and contained 330 requirements; these requirements were sub-divided under eight functional categories: Device and Service Functional Capability (CAP), Discovery and Addressing (DA), Identity (ID), Lifecycle (LC), Negotiation and Compatibility (NC), Policy and Security (PS), Remote Notifications and Messaging (NM), and Transfer and Management of State (TMS). These requirements were used to devise a software architecture for the webinos platform.

As architectural design progressed, the project team obtained a better understanding of the problem domain; this challenged many of the assumptions underpinning existing requirements artifacts. However, time constraints during the architectural design meant that the requirements could not be revisited until software development of the platform had already commenced. The platform was implemented using an iterative model based on the Scrum method [START_REF] Schwaber | Agile Project Management with Scrum[END_REF]. Scrum teams were created for representative webinos platforms and the core architectural components and features developed were derived from the architectural design documentation.

The process was applied over a two month period by a team of nine part-time and one full-time team member; the part-time team members were involved in platform development activities, while the full-time team member was responsible for coordinating the overall approach.

Preparatory activities

Before applying our approach, a number of preparatory activities needed to be carried to better facilitate collaboration between the team. The first step involved converting the scenarios, use cases, and requirements needed to a more accessible format given the distributed nature of the project team. These were originally documented in Microsoft Word which proved to be too unwieldy. It was, therefore, decided to use the project wiki to maintain these. Unfortunately, because there was no easy programmatic way to access content on the wiki, a git repository [32] was used to maintain the underlying page source. Moreover, while the largely textual structure of the wiki was a fit for storing scenarios and use cases, a more structured format was felt more useful for editing requirements. Consequently, requirements for each category were stored in spreadsheet files which, like the wiki page source files, were also kept under configuration control. Scripts were written to convert both the page sources and the spreadsheets into an XML format compatible with CAIRIS.

Category concept mapping

Before concept names could be created to characterise each requirement, it was first necessary to improve the quality of many of the original requirements. In most cases, this involved little more than simplifying the requirements text, and breaking down large requirements descriptions into multiple requirement statements. At this stage, ten new requirements were added, but existing requirements were not removed, nor were their priorities changed. Also, in addition to the inclusion of a spreadsheet column for the concept name, an additional comments attributes was added to each requirement to indicate what original requirement each updated requirement was based on.

The team met over a two day period to begin the category concept mapping process. To acquaint the team members with the process of concept mapping, three concept maps (LC, NC, and PS) were created . As Figure 4 (left) shows, print-outs of the requirements for each category were available for participants to refer to during this exercise; these were used to refer to the requirements description and, when the group felt this text was ambiguous or inaccurate, these were revised. At the end of each session, the concept map was transcribed to DOT. A laptop was also available for directly updating the requirements spreadsheets. Each concept mapping session took approximately half a day with the exception of the Policy and Security concept mapping session which, due to the number of requirements, took one day. Following this workshop, responsibility for completing the remaining five concept maps, together with updating the DOT files and requirements, was distributed among the five partners. The partners then completed these remaining concept maps over a three week period.

Concept map consolidation

Once the remaining concept maps were developed, the team met over a further two-day period to consolidate the concept maps. The session was attended by eight of the ten team members, where each person worked on at least one of the contributing concept maps.

Like the category concept mapping exercise, this involved drawing relationships between paper cut-outs of requirements. This exercise, however, began by re-creating each of the individual concept maps. In most of the cases, this involved re-drawing the concept map based on the optimised Graphviz layout although, in two cases, partners brought their physical maps with them. Each individual concept map was placed on a table covered with butcher paper, and marginally trimmed to fit the space available. Because it contained the most requirements, the PS concept map was the most central, while other concept maps were situated around this. Also, by covering the table with paper, it became easier to draw associations between concepts. Where drawing associations were difficult to follow, then a duplicate concept label was added to the table to simplify reading of the concept map.

Rather than drawing concept mapping to a close, consolidating the maps instead caused the original concept maps to be re-examined in a new light. While participants expected to be asked to comment on the contribution their work areas made to the collective map, many did not realise that they needed to become knowledgeable in the concepts associated with the other maps. Consequently, much of the first day was spent walking through and discussing each of the five concept maps developed remotely, as well as reviewing the three concept maps created when the team last met. The first half of the second day was spent exploring how different concept maps were connected and, where necessary, updating the requirements as a better understanding was gleaned of them. The second half of the second day was spent walking through a selection of scenarios, use cases, and backlog items to check the concept map accounted for the concepts described in these artifacts. Finally, the remaining requirements were reviewed to ensure they were still within scope, their description was accurate, and they were appropriately prioritised.

Besides updating most of the requirements to improve their comprehensibility and clarity, a significant number of requirements (120) were defined as out-of-scope and removed from the specification. The most common reasons for deletion was that a requirement was either superseded or duplicated by other requirements, and what were originally understood to be platform requirements were requirements for end-user applications instead. To ensure that the reason for removing requirements was not forgotten, an out-of-scope spreadsheet, and moving the requirement into this sheet, together with an explanation for why the requirement was being removed.

The final consolidated map is illustrated in Figure 5.

Concept map validation and model generation

Before departing the consolidation workshop, the group carried out a worked example of how the semantic zooming exercise should be carried out, and how the alignment associations between scenarios, use cases, and backlog items should be specified using DOT. Following the workshop, each partner took responsibility for carrying out this alignment activity for one or more functional categories. Because of their familiarity with the respective functional categories, the same breakdown was used as for the category concept mapping.

The participants found that aligning scenarios and use cases to requirements was straightforward because, having gleaned a better understanding of the requirements for their particular area, it was now easier to put the scenarios and use cases in context. However, the lack of post-requirements traceability meant that aligning requirements to the backlog items and implementation code was much harder. To remedy this, the lead developers were invited to review both the concept maps and the Scrum backlog list to both identify requirement concepts they believed were missing, or requirements that motivated backlog items they were working on. Working with their feedback, the participants updated the DOT concept maps for the aligning concepts based on the comments received.

Because of the wide range of artifacts and technologies, and the desire for consistency, additional work was needed to synthesise the data before importing into CAIRIS. A build script was created to import all of the requirements artifacts (scenarios, use cases, and requirements) that were stored in the git repository into a single requirements model in CAIRIS; the script also exported the scenarios, use cases, and requirements into both a single specification document, and a collection of wiki pages that project team members could review. When responding to comments from either the document or the wiki page, respondents were asked to update the artifacts in git rather than the wiki pages itself. To validate that people were updating the git-based artifacts, the build script was run daily to re-generate a CAIRIS model based on the contents of the git repository. When the script failed, it was often because of typographical errors in use case, scenario, or requirement identifiers; these caused referential integrity errors when importing data into CAIRIS' database schema.

Discussion

In this section, we discuss some of our findings and lessons we learned applying our approach.

Modelling fatigue

Although concept mapping is easy to explain and, to a passive bystander, concept mapping looks easy, it is a cognitively demanding process. Moving and linking concepts forced participants to make and justify value judgements in-situ within a group setting, rather than at the individual's leisure while working offsite. This led to two consequences. First, there was a tendency to under-estimate the amount of time needed for concept mapping. The category concept mapping sessions took twice as long as initially planned because of the discussion generated during the sessions. Second, in a number of cases, time pressures and mental demands meant there was sometimes a tendency to designate borderline requirements as out-of-scope. These cases were most apparent in categories with large numbers of requirements. For example, the original Policy and Security category contained 115 requirements; following the update, only 58 requirements remained. In some cases, subsequent reviews meant that requirements placed out-of-scope needed to be re-introduced into the specification.

Despite the challenges, participants were still positive about their experiences applying the approach. One participant observed that although the time was under-estimated, delays were only in the region of hours, rather than the weeks and months it took to negotiate the original requirements. Participants also found that, as the concept maps became more elaborate and more requirements were incorporated into it, the complexity of the task did not increase. Moreover, participants that worked on multiple concept maps during the Catania workshop found that working on more maps helped them understand the other concept maps better, and aligning scenarios, use cases, and backlog items was considered trivial once the concept maps had been completed.

Marketing the approach

As a vehicle for updating the webinos requirements specification, most participants were initially sceptical about how useful the approach would be. While the theory behind the approach were clear, many participants failed to see how moving around pieces of paper, and drawing labelled arcs between them would improve the quality of the requirements specification. Participants were, however, also sceptical about how useful the approach taken to elicit and specify the original requirements specification would be for updating them. Given the options available, the concept mapping approach was the most palatable because it directly addressed traceability problems that were facing the project at that time.

As the participants became involved in the hands-on concept mapping process itself, they found the approach both rewarding and worthwhile. In particular, working with physical objects like papers, pencils, and scissors reinforced the tangibility of requirements, something not felt when working with screen based interfaces for manipulating requirements. Nonetheless, although the biggest benefit of this approach is obtaining a better understanding of a system's requirements, to gain initial adoption it was important to focus on the immediate tangible benefits which, for this approach, is toolsupported requirements traceability. Once participants had bought in to concept mapping, they encouraged others to get involved by joining sessions, and reviewing concept maps remotely, thereby improving the visibility of the process across the project. This was a notable result because, up to that point, the requirement specification was seen as something the project contractually needed to deliver, rather than something that added value in its own right.

Human-centered tool support

Although tools played only a supporting role in the process, it was invaluable for assisting what might otherwise have been tedious activities. These included printing out concept names, using spreadsheets to review requirements tables, de-duplicating traces that occurred in multiple DOT files, and generating a specification document. Consequently, rather than using software to automate the process of concept mapping, it was instead used to remove some of the drudgery associated with supporting the hands-on concept mapping sessions.

After reflecting on the sessions themselves, participants felt that, with so much information being discussed around the concept maps, software tools would have been useful for recording transcripts and annotating concepts with additional information. While someone fulfilling the role of scribe would have been useful at the formative stages of the concept mapping, participants appeared to self organise as the sessions progressed. For example, when the group decided a requirement was out-of-scope, there was usually a pause of around a minute as notes were taken to explain the rationale for de-scoping this requirements. When de-scoping took place when the concept maps were more advanced, concept maps needed to be updated to ensure links were not left hanging. By then, however, the group was confident enough to tidy up the concept map and reflect on the consequences of de-scoping the requirement while one person updated the requirements spreadsheets.

Requirements confidence

As both the category and the consolidated concept maps took shape, participants felt confident enough to address requirements which, up to that point, had been included in the specification but had not been properly addressed in the implementation. For example, the specification made several references to context and the need for webinos to be context-aware. When the map was consolidated, the participants found that the better understanding of the requirements had not helped clarify how to address requirements referencing this term. As a result, the team discussed what the term should mean and, once a proper definition had been agreed, revised both the concept map and the associated requirements based on this improved understanding.

Rounding off the consolidation workshop with the requirements prioritisation exercise re-affirmed the confidence that the team had developed about the requirements. Having now seen a big picture of the requirements, the team felt better equipped to reprioritise them based on estimated delivery schedule of webinos, and their importance, rather than the urgency stated by certain stakeholders.

Conclusion

In this paper, we presented an approach where concept mapping was used to both improve the visibility of requirements and, with the aid of tool-support, improve their quality. Moreover, our discussion suggests that, as well as improving the quality of the requirements, the approach also served as a useful pedagogical tool about the value of good requirements practice. By transposing requirements from text on a screen to a concept name on a piece of paper, and forcing debate around what particular requirements meant for the project, team members saw software requirements in a more positive light. As a foundation for future work, this paper makes two additional contributions.

First, we have demonstrated that sensemaking and organising learning techniques can provide practical support to participative Requirements Engineering activities. In particular, we found that concept mapping gave team members the confidence to make value judgements. We accept, however, when tired and under pressure, such judgements might be made too easily. For this reason, future work considering the group dynamics of concept mapping for supporting software engineering activities would be valuable.

Second, we have shown that lightweight software tools, where applied appropriately, can augment the concept mapping process without getting in its way. Our discussion suggests that desired tool-support shares many of the characteristics of Computer Aided Qualitative Data Analysis (CAQDAS) such as Atlas.ti [START_REF] Muhr | User's Manual for ATLAS.ti 5.0[END_REF]. While the ability to quickly search for concepts and other data was available once the data had been imported into CAIRIS, it wasn't during the concept mapping process itself. While recent work has looked at how CAQDAS tools might interface with requirements management tools when developing personas [START_REF] Faily | Persona cases: a technique for grounding personas[END_REF], our results suggest that understanding how tool interaction might be useful for supporting other design techniques warrants further investigation.

Fig. 1 .

 1 Fig. 1. Example Graphviz concept map

Fig. 3 .

 3 Fig. 3. Chernoff Face concepts

Fig. 4 .

 4 Fig. 4. concept mapping session (left) and category concept map (right)

Fig. 5 .

 5 Fig. 5. Consolidated concept map

Acknowledgements

The research described in this paper was funded by the EU FP7 webinos project (FP7-ICT-2009-05 Objective 1.2).


Claudia C Gutiérrez Rodriguez

Anne-Marie Déry-Pinna

Visualizing Sensor Data: Towards an Experiment and Validation Platform

Keywords: Information Visualization, HCI, Sensor Data, Medical Applications, Experimentation platform

In the last decade, technological improvement on sensors increasingly motivates the use of sensor data in numerous application domains such as environmental, health, transportation, etc. Progressively, with the advances on user terminals, there is a strong trend towards interactive sensor data visualization. As viewing raw sensor data stored in multiple databases does not specially fulfill user requirements, data visualization raises challenges about supporting users to easily use and handle sensor data. In this paper, we address this particular subject with an extensible visualization and interaction platform. Within this platform, we provide developers the facility to experiment and validate multiple visualizations for sensor data, specially based sensor data properties and users' requirements. We illustrate our platform with a medical study case focused on ECG data visualization.

Introduction

Nowadays, data visualization is increasingly resorted considering the tremendous benefits by creating, exploring and interacting with large collections of data. Visualization currently supports several tasks such as medical diagnosis [START_REF] Stoicu-Tivadar | Human-computer interaction reflected in the design of user interfaces for general practitioners[END_REF][START_REF] Stroetmann | Understanding Patients: Participatory Approaches for the User Evaluation of Vital Data Presentation[END_REF], training simulations [START_REF] Campbell | Emergency Response Planning and Training through Interactive Simulation and Visualization with Decision Support[END_REF] or architectural reconstructions [START_REF] Niederauer | Non-invasive interactive visualization of dynamic architectural environments[END_REF], as well as monitoring streams of data coming from sensors employed on several application domains like transportation or environmental [START_REF] Grundy | Visualisation of Sensor Data from Animal Movement[END_REF].

Even if different visualization techniques and forms (i.e. charts, maps…) have been proposed to support both, use and interaction over large amounts of data [START_REF] Keim | Information Visualization and Visual Data Mining[END_REF], visualization of sensor data fulfilling users' requirements is not a simple task. It implies several challenges and requires different elements, such as: a good comprehension of data itself (e.g. properties and structure), a deep understanding of basic HCI and the principles that underline them, together with a proper interpretation of the potential usages of these data by experts.

In this paper, we address these challenges with a platform oriented to experiment and validate multiple visualizations for sensor data. The main goal of this platform is to provide users (i.e. developers and experts) with a tool capable to assist them in the definition and design of possible sensor data visualizations and interactions for particular usage contexts. With this platform, users are able to evaluate the accuracy of possible visualizations, identify new functionalities or specializations being useful to adapt and increasing the usage capabilities.

This paper is organized as follows: Section 2 discuss approaches on visualization techniques for sensor data. Section 3 introduces the specificities of our extensible platform. In Section 4, we explain how the platform is used for extensibility in a medical case study managing data coming from an Electrocardiogram (ECG). Finally, Section 5 presents our conclusions and future work.

Overview

Visualization is an important mechanism when working with large amounts of data as sensor data. It makes more comfortable for users to interact within, as for select or filter data of interest, data can be understood faster and easier [START_REF] Campbell | Emergency Response Planning and Training through Interactive Simulation and Visualization with Decision Support[END_REF][START_REF] Keim | Information Visualization and Visual Data Mining[END_REF]. However, visualizing sensor data is not a trivial task. Multiple views of sensor data can be extracted according to several aspects such as context of use, users' requirements, data properties, etc., and thus several questions arise such as: How sensor data can be reasonable visualized?

In the last few years, more and more interactive tools have been proposed to support users (i.e. domain experts) exploring and presenting data that might be stored, analyzed or simulated [START_REF] Aigner | Visual Methods for Analyzing Time-Oriented Data[END_REF][START_REF] Luo | A developing framework for interactive temporal data visualization[END_REF]. The information analysis on such interactive tools is supported by user interfaces based on visualization and interaction techniques, visual design, human perception and cognition understanding [START_REF] Shneiderman | The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations[END_REF]. According to [START_REF] Stone | Information visualization: Challenge for the humanities[END_REF], the challenges of this kind of tools are to visualize in a way that balances complexity with conciseness and accuracy with essence. They must avoid providing confuse pictures of information or inadvertently or deliberately miscommunicate users.

Recent prototypes and guidelines look forward new opportunities on information visualization by providing task (i.e. Zoom) and visualization taxonomies (i.e. 1-, 2-, 3-dimensional data, temporal…) [START_REF] Richter | Visualizing Sensor Data[END_REF], modeling visualization elements, considering hardware and software to visual design (i.e. Smartphone, PC, tablets…) [START_REF] Carmo | MoViSys -A Visualization System for Geo-Referenced Information on Mobile Devices. Visual Information Systems. Web-based visual information search and management[END_REF] or even regarding user himself as a primary key on visualization development.

Several research works are also focused on sensor data analysis through visualization techniques [START_REF] Grundy | Visualisation of Sensor Data from Animal Movement[END_REF][START_REF] Richter | Visualizing Sensor Data[END_REF]. This work leads to several proposals matching tasks and sensor's type in order to provide a possible visualization or providing clues for guidelines between sensor type and visualization taxonomy. Such kinds of visualizations are unfortunately stand-alone applications and have no facilities for interacting with multiple cases of study. They provide graphical environments for specific sensor data representation like combining text with visual indicators (i.e. tables, icons…), real-time charts (i.e. temperature, speed…), maps (i.e. location) and perform only some specific operations over sensor data like Zoom.

Analyzing requirements on emergent applications exploiting sensor data lead us to conclude that visualization in this context must goes beyond a simple illustration of text or matching relations between visualization elements. More and more, integrate different means of interaction and visualization is required to support users in their tasks (i.e. diagnosis, monitoring, supervision…). We distinguish two main requirements accordingly: (i) provide visualizations adapted to specific data type and application context and (ii) provide adapted functionalities that support further data visualization extensibilities by means of users' experience and needs.

Regarding these requirements, we propose in the next section an extensible platform oriented to experiment and validate sensor data visualization. In such a platform several generic visualizations are proposed and its design enables users to identify and implement the most adequate visualizations for a specific usage context. In fact, a definitive list of visualizations cannot be provided and thus we decide to focus on the extensibility and adequacy of the platform. .

Towards an Experiment and Validation Platform

Designing a platform to experiment and validate sensor data visualizations enables, among other, to analyze the consistency and relevancy of potential visualizations related to users' needs and their usage context. To this end, we introduce in the following paragraphs, an extensible platform oriented to assist experts visualizing and interacting sensor data.

General Overview and Architecture

Through this platform, developers attended by domain experts, may identify and implement the most appropriate visualizations to support users into tasks such as monitoring, medical diagnostic, tracking, etc. Our platform is thus designed to facilitate: (i) adding new types of sensors (data formats, data transfer protocols…) (ii) extracting useful data to be displayed (iii) enabling data correlation from different sensors (iv) associating appropriate visualizations to data type and (v) adding new visualizations and interactions.

The platform is built on 3-tier architecture. A database (DB) dedicated to store data to be displayed, a server where basic functionalities for managing data are deployed and a client which is the interactive part of the architecture allowing users to test visualizations and feedback developers about their particular needs on data representation. For this paper, we especially focus on the visualization aspect of the architecture describing the main functionalities to experiment and validate possible sensor data visualizations and interactions.

Developers and domain experts: providing adapted functionalities

In order to provide an extensible experiment and validation tool, we offer in this platform several visualization and interaction functionalities both at the server and client side. Our approach proposes extendable visualization libraries and data model enabling to extend the capacities of the platform and also provides a set of functionalities enabling experts to experiment and feedback developers. On the server side, implemented functionalities are organized on two main axes: Data and Visualization management. Data management enables to manage data records of several data types. Developers and experts are then allowed to import data of different types, extract them, associated to specific visualizations (i.e. ordered by adequacy: map and chart for gps data records) and making them persistent. Together, visualization management assists developers adding, creating and deleting visualizations. Developers can create a new visualization which extends of the existing ones providing their specificities through associated metadata. For example, we can specify if visualization can be used for particular cases like synchronization, real-time display, selection or composition. Further, such visualization is then available for new data records association. Actually, this association is given by the developers; however we aim to automate this process by defining adapted semantic rules.

Fig. 1. Dashboard: visualizing two data records

On the client side, we propose a visualization tool which act as a mediator between developers and experts. It can be described by three main features: Dashboard, Data management and User profile. The dashboard implements functionalities to associate data types to specific visualizations, list and select data records, interact with the suggested visualizations (all adapted to sensor data representation depending on the type of data record and the associated list of visualizations) and displaying one or several data records visualizations. Together, traditionally functionalities adapted to dynamic sensor data are also provided, such as: Zoom (selecting a piece of a graph) or Markers (displaying reference points with color and description). Data management allows importing extract and gathering data coming from one or several sensors. Users can manage such records and create, add, delete or modify them and then test visualizations and interact with it in order to better understand and explain their requirements. Our platform proposes to manage user profile by controlling user access with an id and a password.

The prototype of this extensible platform is based on Web applications technology (Figure 1). Such a technology opens new possibilities of implementation such as Web Services, REST protocol, HTML5, etc. Also, it offers a better collaboration and information sharing, as well as a bridge to target mobile devices such as Smartphones and Tablets.

Experimentation and platform validation: visualizing ECG data

In order to validate the feasibility of our platform, we experiment into an application oriented to support medical experts in the analysis of ECG data. To this end, we have adapted our platform to the preliminary requirements of the usage context and interacted with the experts to evaluate its extensibility and adequacy. This evaluation process is very close to the specifications provided by the ISO 9241-2101 standard for Human-centered Design for Interactive Systems, which defines all the aspects related to user's experience and its impact on the presentation, functionality, behavior and capabilities of the system. Thus, the experimentation described in this section takes into account the context of use (i.e. users, tasks, environments…), the user requirements (through all the development process), the design solutions which meet these requirements and the user-centered evaluations of such solutions, modifying according to the users' feedback.

Users: implant and medical experts

The users involved in this experiment are 3 actors: (i) two experts on cardiac implants which provide cardiologists and surgeons with infrastructures to monitor the behavior of such implants, and (ii) one medical expert, a cardiologist, which provide a diagnostic and treat cardiac pathologies. Each actor is supposed to test our platform according to the following scenario.

Scenario: ongoing experimentation and validation process

In our scenario, the expert requires to analyze a data stream coming from an ECG both in real-time and a posteriori. In order to adequate our solution to users' requirements, we experiment our platform by following three main phases described hereafter.

Phase 1: User requirements analysis when presenting the platform and the possible visualizations and interactions to the experts.

Feedback: Based on the provided functionalities, experts give a direct feedback to the developers and asked for the possibility to load ECG data type (i.e. xml-hl7), to visualize such data on the typical visualizations recommended by the cardiologist (i.e. cardiac derivations, peaks,…) and to create visualizations dynamically according to traditional ECG results (i.e. EVI compositions…)

Results:

The developer validates the possibility to manage new data types, as for example *.hl7. Also, a specific composition for ECG data based on the combination of selected data was considered. A new visualization can be derived from this composition.

Phase 2: Presentation of a first prototype integrating the solutions and requiring user testing. Once the implementation of new visualizations performed, users can test and react by providing their feedback for possible extensions.

Feedback: The experts have identified their need to perform their own data selection in terms of ECG graph display and also to select peaks values between maximum and minimum values.

Fig. 2. Real-time visualization: dynamic visualization of a data record

Results: Our platform has been then enhanced with new functionalities and opened to new application domains such as medical by analyzing data coming from an ECG (Figure 2). With our platform, expert is leaded to upload files containing ECG data (i.e. xml-hl7) and to specifically select which data he/she wants to import (i.e. by date). Once the expert creates and selects a data record, he is able to display it with the different visualizations proposed on the dashboard. He can test several visualizations for the same record, for example in a table, in a static or in a dynamic graph (real-time simulation), etc. Indeed, all the proposed visualizations are adapted to visualize sensor data.

Thanks to our platform and by choosing a real-time representation, medical expert can simulate a dynamic sensor data stream and interact with data in different ways, for example: (i) manage graphs distribution over the dashboard (ii) zoom in a particular segment of the graph (iii) annotate the graph with markers (reference points) (iv) select some fragments of the graph (Figure 3) (v) compose a new graph based on selected data fragments.

Fig. 3. Peaks detection and visualization

Phase 3: Other user test is required to validate the set of implemented functionalities. This aspect is an ongoing work. In fact, results acquired until now support us to increasingly enhance our platform. We attempt to introduce and test the platform by more medical experts (~10 experts) and especially considering a real scenario context.

Conclusion and Perspectives

In this paper, we have presented an extensible platform oriented to visualize and interact with sensor data coming from various applications domains. We propose several features and functionalities attempting to support developers and experts to simulate, create, interact and visualize multiple sensor data representations. In order to illustrate the applicability of our platform, we validate our proposal over a medical case study requiring a display of data coming from an ECG (Electrocardiogram). Results validate the extensibility of our platform and approach and motivate for further improvements.

The testing and enhancement of our platform is an ongoing work. At this time, we integrate new modules facilitating the implementation of features such as: preprocessing data to be displayed, managing composition of visualization tools and sensed data with an ergonomic point of view, relating patient health records, storing experts' visualization and interaction preferences, as well as migrating to mobile devices. In our future work, we aim to propose a more automatic visualization association and display, especially based on semantic rules and usage-based learning approaches.

This platform is currently used as part of a research project with specialists on cochlear and cardiac implants. Further experimentations with final experts will be performed on mobile devices should take place within a year. At present, experts and developers work closely to determine the visualization and interaction choices. Also, we plan to perform quantitative evaluations of platform's usability considering the measures proposed by ISO 9241-11 (Specifications and evaluation of usability).

http://www.iso.org/iso/catalogue_detail.htm?csnumber=52075

STM3 -Solution for the Treatment and Monitoring in Mobile Medicine (http://www.polescs.org/projets?letter=S&page=5)

3 http://www.sorin.com/

Acknowledgments. This work is supported by the FUI project STM3 2 granted by the French SCS Cluster. We thank Sorin Group 3 , members of the project and specialists in cardiac implants, for their support and collaboration. The authors would also like to thank the students Computer Science Department of Polytech'Nice Sophia Antipolis for their contribution to this project.