A presentation held 1st International Workshop on Requirements Prioritization and Enactment (27/02/2017-02/03/2017, Essen, Germany)

1. Addressing Team Awareness By
Means Of A Requirement
Prioritization Tool
Paolo Busetta, paolo.busetta@deltainformatica.eu
Presented by Matteo Pedrotti, matteo.pedrotti@deltainformatica.eu
PrioRE’17 Workshop at RESFQ 2017
27 February 2017

2. The participants to this experience
(first semester of 2016)
• Delta Informatica is an Italian SME operating in the IT market
• DeltaLab is D.I.’s R&D department, involved in research projects
• Including Horizon 2020-funded SUPERSEDE
• At the time, PRESTO was DeltaLab’s major project
• Funded by the local government
• In collaboration with FBK, University of Trento
• Addressing end-user development and run-time control tools in virtual reality and
serious games for training
• Paolo Busetta, DeltaLab’s research coordinator, was in charge of
supervising the projects by DeltaLab, in addition to other duties
• including PRESTO and SUPERSEDE
• Matteo Pedrotti, DeltaLab’s most senior engineer, was in charge for
PRESTO’s pilot project, among other tasks

3. The situation that led to the experience
• With respect to a normal software engineering project, PRESTO missed a
few key ingredients:
• Reasonably detailed functional requirements (in any form)
• Real end-user involvement
• Permanent product management or a product champion / evangelist
• Rapid prototyping adopted to compensate
• Wishful thinking – the republic of developers turned out to be anarchy
• Nobody had any previous exposure to similar products and users
• Assuming that anyone in the world had, given PRESTO’s novelties
• And, real engineers don’t read specifications, let alone project proposals!
• Indeed, high level of disagreements among developers and between
developers and management about:
• Who were the users and their expectations
• Which functionality was more important and more urgent

4. The case study:
A very controversial
user interface PRESTO Scripting’s
controller is the key tool
for a trainer to start and
direct a training session

5. Experimenting a
(semi-formal) process
Extracted from Bordin et al, 2017 (to appear)

6. The requirement prioritization process
• 16 requirements, grouped under 4 categories
• 2 criteria for evaluation (effort and user value)
• AHP (pair-wise comparison) applied by the tool
• Prioritization in form of an asynchronous game played on the Web
during business hours
• Gamification aspects included different user roles, overall progress of the
game, points given according to promptness
• 8 people (engineers and the research coordinator) involved
• All providing their opinion
• The coordinator had the role of negotiator in case of major conflicts (that
didn’t occur)

7. Discussion and conclusions
• Even in exploratory work, requirements determine where to spend precious
resources, thus prioritization is fundamental
• Lack of formality meant that, even when there was agreement (and this was
not typically the case), technical solutions were divergent
• The applied process allowed everybody to have a forum where to clarify ideas
• This lead to awareness about who was the expected user base
• The use of requirement prioritization tool was a reason to put ideas in writing
and have a clear picture of the options at stake, their costs and their value
• This lead to better reciprocal understanding
• Voting was eventually a minor exercise, given the small setting in terms of people and
number of requirements, but using a tool removed stress
• While advantages on efficiencies are clear (less reworks, errors prevented),
effects on product quality are hard to assess