a demonstrator by University of Toulouse 1 Capitole, and National University of La Plata

GRUS (GRoUp Support) is a Web-based Group Decision Support System (GDSS) supporting collective decision processes that take into account the individual preferences of different actors from a same or different organization. It’s based on a multi-criteria approach for solving a concrete problem, in which decision makers must agree on a concrete alternative, i.e. a solution of the decision to make, thanks to their individual preferences. The system has been used in diverse scenarios in various domains, but not in agriculture.

A particularity within the world of agriculture is that there are still places with a lack of technological support, that may help the farmers to evaluate and explore alternative solutions. In this regard, Wilken et al [Wil90], mention that in Central America and Mexico during the ‘90, there were traditional systems, mainly depending on local group experience-based knowledge that is transferred verbally from one generation to other. We observed that this mechanism still perseveres in some farms of small or medium size in south America, in particular in Argentina. There is still an informality in decision-making, and we would like to know if a system assisting users in the decision process is really helpful for farmers, e.g. if they found that using a system allows them to visualize more alternatives of solution, or if their confidence changes when taking decisions by explicitly entering their preferences on each alternatives on each criterion and the related weight of each criterion.

But before contrasting the use of a system against the conventional methodologies, it is essential to evaluate if the current system, designed to support general-purpose of decision making, adapts well to the knowledge and specific needs of farmers. A possible way to do this is to conduction a demonstration script session with the farmers. In this regard, Sutcliffe & Ryan [Sut98] mention that one of the techniques of their method called SCRAM for requirements elicitation and validation is providing a designed artefact which users can react to. To do so, prototypes or concept demonstrators can be used. In fact, the authors present a case study where prototypes were developed but had limited functionality, so they choose to run the demonstration as a concept demonstrator script. Røkke et al. [Røk10] also present a work where a combination of prototypes and demonstrator sessions are used to elicit and validate the early acceptance of the stakeholders’ requirements, in the context of a the User Interface Development for the Oil and Gas Industry.

We have been working in the construction of a demonstrator script to easily show farmers how the system would work to make a decision within their domain. That required us to choose a scenario in the specific domain of the farmers that will participate in the session, to learn about and choose a method (the demonstrator script), to plan the script, to get together to record the sessions of 5 participants (playing the role of farmers) and finally, to edit the recordings and create the demonstrator script (the final video). The result of such experience can be watched in the video below:

If you wish to know more, or if you wish to share feedback with us, please use the comments box below.