Abstract: Requirements Bazaar is a service to elicit software requirements from a variety of stakeholders. It has been proposed as a solution for scaling requirements engineering process for communities of practice and service providers [1]. As a service, it is designed to have the requirements as the primary objects that the users create and browse. In this paper we argue, based on Charles Sanders Peirce’s theory of signs and John Dewey’s theory on experience, that the design should recognize the central object of the action of the user. Requirements Bazaar is analysed through that perspective. We claim that the central object is the software artefact being improved, not the requirements. Requirements as objects need to be grounded to the designed artefact in order to be meaningful for a design process. We present analysis of service from end-users perspective, and suggest improvements to Requirements Bazaar’s interaction design.

1 INTRODUCTION

This paper treats software as hypothesis [2], and Requirements Bazaar (http://requirements-bazaar.org) presents a hypothesis how social requirements engineering could work. When hypothesis takes a form of a software or an internet service, researchers can test and examine the details of the hypothesis by examining the software or service and evaluating if it succeeds in what it aims to. By reviewing Requirements Bazaar, we try to bring light to aspects of Social Requirements Engineering [3].

In software development the users/stakeholders have to be able communicate their needs to developers. This communication needs a common ground for the developers and users. This common ground is created through the context of use and aims of the users, their understanding of what are the tools and signs the users interact with in their practices. In a practice, some of the tools used may be software. Since instances of software are practically copies of each others, software can be used as a common reference for discussions about the practice between developers and end-users. However the context of failing tools or missing tools and interrupted actions brings emotional issues to the negotiation of needs.

Requirements Bazaar has been evaluated in large-scale integrated EU project Learning Layers for supporting software development in the project. Software development in the project varies from mobile apps to widgets, web services and back end services.

In the next section we present the theoretical grounding for analysis. Then to ground the analysis we present short development history and overview of Requirement Bazaar. Then we offer an analysis and critique of Requirement Bazaar when it is used as a platform for co-design and improvement of software, based on our experience in Learning Layers project. Within the analysis we offer brief suggestions how the service could be improved in order to help end-users and developers to communicate.

2 THEORETICAL ASPECTS FOR DESIGN ANALYSIS AND IMPROVEMENTS

The Peirce’s theory of signs describes an interpretation process that is tied to context, emotions and forming of habits. The concept of habit is broad and contrary to the understanding of habits as automated routine actions, Peirce includes reflective thinking to the meaning of habit. Reflection is always emotional and can include rational conscious thinking. Conscious rational thinking requires effort and is usually promoted by irritation or doubt ([4, p. 413;p. 19], [5] and [6]). Reflective thinking plays part in invention and coming up with new solutions, but there remains traces of irritation and doubt.

The handling of the emotional aspects of requirements is an important challenge in design for requirement elicitation. The interface elements and interactions should operate on the emotional reflective aspect to leave space for effort directed towards the actual subject matter of the requirements, the action what the user is trying to do. The signs (elements) that are interpreted and interacted with in the interface need to be connected to the common ground of the end-users and developers.

The common ground (or in Peirce’s terms collateral experience [7, vol. 3, p. 621; vol. 6., p. 338; vol. 8, p. 179], [8]), the base of experiences that direct our attention and which help to form the future expectations can be enhanced with John Dewey’s theory on experience: ”The experience is not something that happens inside the subject, it’s not something where the subject forms a representations of the things in the environment. Rather it is a continuous interaction with environment, where the ’inside and outside’ are not really separate but form a unified whole. [9, pp. 73-74]. As it can be seen, it is essential that the digital tools can be connected to previous experiences, act in the emotional reflective level, promote and help to take the effort to integrate rational thinking manners that cannot occur and take place without the common ground and emotional aspects.

For our analysis of Requirements Bazaar this means that the end-users concept of requirements, or folk requirements, are operational when working with the system and the requirements are emotionally loaded. These aspects have to be respected when finding the common ground for both the stakeholders and developers.

3 REQUIREMENTS BAZAAR

A Requirements Bazaar for Personal Learning Environments

Requirements Bazaar was originally designed as a part of Responsive Learning Environments-project (ROLE) to help gather and trace needs for widgets and features that could be useful for personal learning environments (PLEs). Requirements Bazaar was a prototype to implement Social Requirements Engineering (SRE) approach for gathering requirements from communities across ROLE project in Germany, UK and China. SRE approach aims to connect users’ communities of practice to developers by offering services for expression, tracing, negotiation, prioritisation and realisation of community requirements [3].

The first prototype of Requirements Bazaar (Fig. 1, http://www.cs.le.ac.uk/projects/ROLE/sre/) implemented SRE in five-staged requirement lifecycle: elicitation, negotiation, selection, development and feedback. In the context of ROLE, main purpose of requirement elicitation was to express need for new tools (widgets) from community of learners to developers: ”When a learner is unable to find a suitable tool, the learner should be able to express her or his need for the new tool.”[3]

In the negotiation stage the requirements are refined and clarified with a public discussion where developers and end-user community both participate. The community can also give votes for the requirement to convey requirement’s importance. The next stage is selection, where developers use the available information to decide which requirements they try to fill first. Then in the development stage, the progress of development is communicated back to community by linking developers project management software to Requirements Bazaar. In the feedback stage the community is notified about the satisfied requirement and asked for feedback via the negotiation system.

In ROLE-project, the requirements were requirements for the community members’ PLEs. PLE is the artefact to improve. As the emphasis was in personalisation, a PLE didn’t really exist as a shared artefact to improve. PLEs exist as hundreds of different instances in different configurations, each used for different purposes. The requirement elicitation and negotiation process thus aimed to abstract the requirement from the unique instance where it first was reported into a requirement that can be useful in as many PLEs as possible. The intended end result for requirement was often a new widget: a new artefact that can be added into learner’s PLE. It could be a modification of an existing widget, or a modification of the widget management process. These were the genetic reasons for abstracting away the artefact from the process: artefact may be a unique configuration of a PLE with no interest for other learners, or a new widget, if a developer decides that this is the way to solve the requirement. This fluidity of the artefact being improved was a feature of ROLE’s process, but we aim to demonstrate that in more typical requirements engineering case, the artefact to be improved should be presented as a central point of reference.

B Redesigned Requirements Bazaar

During the ROLE project, two major prototypes of Requirements Bazaar were developed. The second prototype expanded Requirements Bazaar into a general purpose requirements gathering tool that aims to be useful outside the project. This is the version we are evaluating in this paper. The redesign of Requirement Bazaar modified the 5-staged SRE process to 4-phased workflow imagined in Fig. 2 [1].

Figure 2. Basic workflow from Renzel et al. [1]

Figure 3. Add a requirement-form turns the user’s mental requirement into a document tracked by the system.

Reporting a requirement, or opening a requirement is done with ’Add a Requirement’-form (Fig. 3), activated from main navigation bar. From the form it is clear that a requirement is the main document type that the system is going to manipulate and track. Here requirements shift from linguistic or mental entities – from statements of needs – to documents with a title and a summary. The related software can be added as classification information and files related to requirement e.g. screenshots, URLs, log files or user stories can be added as additional artefacts to the requirement document.

According to Fig. 2, an open requirement is the locus for requirement negotiation and refinement. An individual requirement is presented with a slideshow-like carousel interface, where the first slide is the summary and other slides are the different artefacts added to requirement (Fig. 4). The summary and category information are displayed below the carousel, and each requirement has a threaded discussion below the row of action buttons (not visible in the screenshot.) The state transition actions of assigning a requirement to a developer and completing a requirement are in the left.

Figure 4. Viewing a requirement

The requirement selection is an activity that carried great importance in ROLE-project’s version of Requirements Bazaar, as the assumption was that the user community would be requesting different new widgets to be created from a small set of developers, and there would be a need for comparison and sorting of requirements from various perspectives to decide which end-user needs should be answered first. The second version of Requirement Bazaar also kept emphasis on requirement discovery. In the second version the purpose of requirement discovery is twofold: The first purpose is to support developers in selection and prioritisation with adjustable scoring and ranking options. The second purpose is to give community awareness of requirements [1], in order to help members to vote for requirements, to refine them and to see if their requirement has already been stated.

Figure 5. Discovering requirements

The redesign of Requirement Bazaar includes a dashboard, a personalised front page that offers large icons and buttons for the two main actions: add a requirement and discover requirements. The left sidebar offers a list of projects – these are the requirements created, contributed, developed or followed by the user – and the recent activity of the user.

Figure 6. Front page/dashboard

4 ANALYSIS

A Software Artefacts as Focus of Work

In the first prototype of Requirement Bazaar, the purpose of the system was to bring together three PLE communities and the group of developers available for the project, in order to develop widgets. Widget development typically entails small projects where each widget has a single purpose, and where at the time when the requirement is elicited, the widget doesn’t yet exist. In comparison, in a more typical software development process, and in a more typical requirement engineering process, software artefacts try to fulfill numerous requirements, and the requirements may change during the project. Even when there is no software artefact to start with, there is the background assumption that when requirements are asked, they are asked for a certain software artefact that will end up realising the requirements. Even further, when a project decides to use an SRE process, there is an assumption that there will be software development, and consequently, a software artefact. Of course there is a chance that the result artefact ends up being several separate artefacts, but even then the requirement to explain that would be about one artefact: e.g ”Each part of X can be launched and shut down separately.” It is safe to assume that when there is social requirement engineering for software, the software artefact looms near.

From a Peircean perspective, the relation between software artefact and requirements is that software is the artefact — the real object with which you interact in the world. It is the tool or sign that is used. This object that is used, allows interpretation and action to be executed: it provides experiences. The requirements are irritations or gaps in action, where one has to stop because it is not possible to do what one wants in a manner that the user wants. They arise from moments of reflection on what would be needed so that one can do what one wants. Requirements emerge as a side product of experience of doing something with the software, or from the action as performed without the software. They become an object of communication, something that can be referred to when trying to express what a person wants to get done, what a person wants to do and feel and where the aim or goal of the person is. From a Peircean perspective, the requirements are emotional interpretants when the software is the tool and the sign of interaction.

Requirements Bazaar has the concept of software artefact added in its second version, but as a classification category for a requirement (Fig. 3, see selection boxes under ’Classification’). Our claim is that the software artefacts, or representations of them, should be the primary objects of Requirements Bazaar, and requirements are dependant on them. ”New software suggestion” should create a new software artefact, with its initial requirement hanging from it. The human action of devising a requirement comes from an experience with an artefact, a disappointment, a limitation or a new possibility being perceived. The action and its context are difficult to translate into digital realm, but the artefact being used – software – should be included in the requirement elicitation system. We can now review workflow in Fig. 2 and notice that for phase 1 to apply, the need has to raise in a context of certain type of artefact. A user may have an ’Unfulfilled need’ of ”I need a cup of coffee”, but such need shouldn’t lead to ’Open Requirement’ in workflow as it is not related to any software artefact that SRE process is trying to produce or improve. The common software artefact is the missing point of entry to the workflow.

New software artefacts should be added into the system as primary objects, from front page and from top action bar. Each artefact should be encouraged to have several screenshots uploaded to be used as a reference points for requirements.

B Requirement as a Folk Concept

Social requirements engineering is balancing between requirements as technical concepts used in requirements engineering, and requirements as everyday concepts, or folk concepts. As a technical concept of requirements engineering, it makes sense to talk about requirement’s lifecycle or its implementation, and deal with requirements as objects that can have a title, summary and categories. A requirement in this sense can exist detached from the person who stated the requirement, it doesn’t have to connect to the person and the action where it originated, and it doesn’t need to be aimed at any person.

The requirement as a folk concept is a result of a certain kind of communication act: It is a result of requiring, an action less emphatic than pleading or demanding, but more targeted than wishing, and more forceful than suggesting. We don’t delve deeper into pragmatics of these acts, but the reader should recognise that there are differences between these actions. The user brings into Requirements Bazaar an assumption that the requirement should be a requirement, not a demand, a plead, a wish or any other type of statement.

One feature of the requirement as a result of a communication act is that requirements are targeted to other people. It assumes target to have volition and to comply, e.g. in ”I require you to show a passport”. To not comply is a larger violation compared to declining when being asked, and requirements are made in situations where there are clear power relations between participants: Teachers make requirements for students, much less other way around. Thus requirements can be costly, as when requirement is ignored, the power difference is challenged. The gist is that folk concept of stating a requirement involves social roles, and the act can violate roles and norms independent of the intended rules of requirements gathering system. In Requirements Bazaar, assumption is that the stakeholder community makes requirements aimed at no-one in particular, but for software, and the system tries to support and encourage to state these requirements. It is problematic in two ways:

First, it is difficult to distinguish between making requirements for developers and requirements for software. As a technical concept, requirement is something that software needs to satisfy. As a folk concept, requirement is something that a person capable of choice can satisfy. It is odd to say e.g. ”I require a tree to grow here.”, without implying that someone else should make it happen. The requirement satisfaction is the feature of the artefact, but the reason why it fails transfers to the people responsible of its behaviour. This can be a strength for social requirements engineering, as the object that should satisfy the requirement can be used as a common artefact to help the negotiation and redirect the failures and disappointments from being directed to developers. De-personalisation of requirements to be pointed at objects, however, does not remove the power aspect of requiring, as it still implies that someone should make the requirement satisfaction to happen. It may even heighten the power difference, as requirements can be made without even having to meet those who have to serve to make the artefact comply. We propose that the requirements should embrace their dual role, and be more explicitly stated to be requirements for artefacts, and be a request for selected developers to improve the artefact. The requirement creation screen (Fig. 3) should include a computed set of potential developers as thumbnail images, to make the human recipients of the communication act more present.

As a minor issue, in the form for adding a requirement (Fig. 3) there is another example how the technical concept of requirement is overriding the folk concept of a requirement: the title field ”Enter requirement title...”. The folk concept of requirement as a communication act doesn’t distinguish between title of a requirement and requirement itself. Naming the title field as ’Requirement’ and summary as ’explanation’ would keep the UI more compatible with the folk concept. Second, Requirements Bazaar is now extended to tasks where stating requirements is not the most apt description about community’s intentions. In Learning Layers -project Requirement Bazaar is encouraged to be used also as a bug reporting tool, and mapping the task of reporting a bug into the task of making a requirement is unnecessary work for user, and the end-result brings unwanted aspects of communication practices to the resulting requirement: when making a report, reporter’s responsibility with the problem is finished, but with a requirement, the maker of requirement is implicitly left waiting if the requirement is satisfied or ignored.

For the user the need to report a bug derives from different experience and activity than generating a requirement. It is emotionally different process as well as from what the user does and experiences. Recognizing something as a bug involves recognizing the intended behaviour of the tool from its actual behaviour, and it is primarily about the behaviour of the tool and secondarily about the action that the user wants to do. Bug reporting should be a separate activity with dialog matching with the purpose.

Rephrasing of requirements as ’projects’ in the dashboard (Fig. 6) creates more confusion between expectations and workflow of the system. In widget development, where coupling between requirements and widgets that implement them was tight, requirement implementation as a widget development task could be paraphrased as a project, but the progress from e.g. bug report to requirement to project is more difficult to justify and makes the user to suspect that bug report got miscategorised.

C Requirement Discovery from the End-User Perspective

Requirement discovery page (Fig. 5) supports the developers in requirement selection and for the end-user community it works as a gateway to requirement negotiation and refinement activities. The emphasis in the UI is requirement prioritisation through weighted scoring. In this page the shift of purpose in Requirement Bazaar from widget requirements to software requirements results in UI problems: In the current version, the only way to show requirements for one software is to do a search by software name and view matching results. In the original purpose of discovery for requirements for widgets there wasn’t need for continuous focused development of single widget/software artefact and mapping several requirements to one software artefact. When Requiremnents Bazaar is used for larger separate development projects the feature of competing requirements is of limited benefit, as the requirements compete against requirements from other projects. Having the requirements compete through voting and activity serves to motivate developers, as they recognise the importance of their task, but for the end-users it is problematic. Showing the most voted and most active requirements first creates a snowball effect of higher visibility and activity on already top-ranked requirements, and other requirements forming a long tail that receives diminishing views, and thus have diminishing chances for ever becoming more active. New requirements start with no votes and no activity, and so they disappear into the long tail, which is demotivating for the end-users adding requirements, because they get immediate feedback that their requirement is not important.

We propose two changes:

1. The requirement discovery page should be reorganised around the software artefacts. Reasoning for this can be found from previous sections.
2. Requirement ranking page should have its own page, aimed for developers. It should not be the main page to discover requirements, as for community it has an opposite effect: it helps in discovering those requirements that are already well-discovered by community and hides those requirements, that are in need of community voting and refining.

5 CONCLUSION

Our aim was to ground the analysis on pragmatism for an alternative viewpoint on issues of interaction design. The main findings of our analysis are that for end-users, an artefact is not a category of a requirement. A requirement is communication about an artefact to another person. We suggest the following changes to improve the role of the artefact in this implementation of social requirements engineering process:

Front page/dashboard (Fig. 6)

• Add new software artefact to improve should be added as an action
• Report a bug should be added as a separate action
• Your projects should be renamed to your requirements

Requirement discovery (Fig. 5)

• Requirement scoring and prioritisation should be in own subpage.
• Requirement discovery should be organised around software artefacts.
• Ordering of requirements should help discovery of new or neglected requirements

Requirement display (Fig. 4)

• Information order should be: software artefact being improved, requirement, explanation, supporting resources, negotiation.
• Requirement should be able to use existing uploaded screenshots from artefacts as a reference.

Add a new requirement (Fig. 3)

• Order of elements in form should be: software artefact being improved, requirement, explanation, supporting resources.
• Requirement should be able to use existing uploaded screenshots from artefacts as a reference.
• Requirement form should display the computed set of potential developers as recipients for requirement.
• ’Report a bug’ form should not have recipients, and fields should be renamed as software, problem, description of situation, supporting resources, and the form heading should be ’Report a bug’.

The requirements and the bugs are context-dependant entities. They are dependant on the end-users’ experiences with software artefacts, which are dependant on end-users using software artefacts in their actions and practices. Therefore we suggest that the requirement elicitation should involve presenting the software before the requirement to prepare the context. The requirement itself should to be received by a human to be felt as valued, but the act of making a requirement to another human displays a power inequality. We propose that the requirements should be directed towards the software artefact, but with an invited audience of related developers. The problems may be relevant to social requirement engineering in general, but in our case Requirement Bazaar has been the software artefact and the common ground to figure out these problems.

Acknowledgements

This research was supported by the 7th Framework Programme large-scale integrated project LAYERS (grant no. 318209).

REFERENCES

[1] D. Renzel, M. Behrendt, R. Klamma, and M. Jarke, “Requirements Bazaar: Social Requirements Engineering for Community-Driven Innovation,” in Requirements Engineering Conference (RE), 2013 21st IEEE International. IEEE, 2013, pp. 326–327.

[2] T. Leinonen, T. Toikkanen, and K. Silfvast, “Software as hypothesis: Research-based design methodology,” in The proceedings of Participatory Design Conference 2008. ACM, 2008.

[3] E. L.-C. Law, A. Chatterjee, D. Renzel, and R. Klamma, “The Social Requirements Engineering (SRE) Approach to Developing a Large-Scale Personal Learning Environment Infrastructure,” in EC-TEL, ser. Lecture Notes in Computer Science, A. Ravenscroft, S. N. Lindstaedt, C. D. Kloos, and D. H. Leo, Eds., vol. 7563. Springer, 2012, pp. 194–207.

[4] C. S. Peirce, The Essential Peirce: selected philosophical writings. 1893-1913. Vol. 2. Indiana University Press, 1998, vol. 2.

[5] M. Bergman, “Improving our habits: Peirce and meliorism,” paper presented in Metaphysical Club, Helsinki, Finland on the 31st of March 2009. Last retrieved 21nd of August 2009. [Online]. Available: http://www.helsinki.fi/peirce/MC/papers/Bergman%20-%20Peirce%20and%20Meliorism.pdf

[6] E. Kilpinen, “The habitual conception of action and social theory,” Semiotica, vol. 2009, no. 173, pp. 99–128, 2009.

[7] C. S. Peirce, Collected Papers of Charles Sanders Peirce, C. Harthstorne, P. Weiss, and A. W. Burks, Eds. Harvard University Press, 1931-1958, vol. 1-8.

[8] M. Bergman, “C. S. Peirce on interpretation and collateral experience,” in Forskarseminarium i filosofi 7.10.2002. Filosofiska institutionen Åbo Akademi, 2002.

[9] J. Dewey, The Later Works of John Dewey, 1925-1953: 1938, Logic - The Theory of Inquiry, ser. The Collected Works of John Dewey, J. A. Boydston, Ed. Southern Illinois University Press, Carbondale, 1986, vol. 12.

Master of Arts Jukka Purma is a doctoral candidate and a project researcher in Learning Environments Research Group at Aalto University School of Arts, Design and Architecture. He has been involved in several EU projects and he is preparing his thesis on visualization tools for biolinguistics. He has background in cognitive science.

Docent of semiotics Merja Bauters is a postdoctoral researcher in Learning Environments Research Group at Aalto University School of Arts, Design and Architecture and senior lecturer in the Department of Philosophy, History, Culture and Art Studies at University of Helsinki where she also received her PhD. She has been involved in multiple EU projects, such as NetPro (Network-based project learning tools) from 1999­-2004; Developing Knowledge-Practices Laboratory, KP-Lab (http://www.kp-lab.org/), IST project for EU's Sixth Framework Program (2006­2011), Coop-PBLinVET, Leonardo Da Vinci (2010-2012), Promoting Project & Practice Based Learning supported by collaborative learning technologies in Initial Vocational Education of Mechanical Manufacturing (http://coop-pbl.com/en), Creating Knowledge through Design & Conceptual Innovation (http://www.knowledge-through-design.uni-kiel.de/project), Lifelong Learning Programme, (2011­12). At the moment she is leading one work package in The Learning Layers project supported by the European Commission within the 7th Framework Programme. Her interests are on the topics of interpretation, experience and Peircean and Deweyan pragmatism, habit formation, change of habit, experience and reflection.