Requirements Process
Summary of Requirement Gathering
User requirements gathering process
To gather requirements we used ‘User Story Workshops’ an agile development technique. This allowed us to capture user requirements in everyday language without thinking about technology. User Stories are written in the form:
• As a/an……
• I want to…..
• So that…….
The workshops were 1 hour long. They started with a 10 minute introduction to the project and the technique. We then moved on to the main activity of discussing the project and getting the participants to complete the User Story Cards.
We also undertook a survey of teaching staff (open from 15th of November to the 6th December 2013) which received 148 responses. From the responses to the final question open text question: ‘A final thought, if you were to use a discovery tool such as the one we are creating, what is the one thing you would want it to do?‘ we developed additional user stories to complete the set of requirements we used for the next stage of prioritization.
User Story Workshops
22 October, 10 to 11 -2 Participants from Learning Service/TELS (Pilot)
23 October, 11 to 12-2 Participants from Learning Service/TELS (Pilot)
Thu 21 Nov 2013, 10 - 11:00 – 2 Participants
Tuesday 26 Nov, 3.30 - 4.30 – 2 Participants
Wednesday 27th of November, 9.30 to 10.30 – 2 Participants
Thursday 28th November 1:00 to 2:00 – 6 Participants
Friday 10 January 2014, 10 to 11 – 1 Participant (a key stakeholder who could not contribute to earlier sessions)
7 Events, 17 Participants
Workshop Evaluations
At the end of each session we handed out short evaluation forms with the open questions:
1. What was the most useful part of today’s event?
2. What was the least useful part of today’s event?
3. What changes would you like to see made to today’s event?
4. Any other comments:
We received11 completed evaluation forms from across the sessions. The responses were generally positive, though we did make some initial changes to the session introduction presentation on feedback received after the pilot sessions.
Participants found the most useful aspects of the event the open discussion and found ‘User stories’ as a genuinely useful technique. They appreciated being asked for their views. One participant summed it up as: ‘Interesting, fun, worthwhile!’
The main change participants at the smaller sessions would have liked would have been to have larger groups, so they could have heard more viewpoints.
Outcomes
The workshops and survey responses produced 149 completed User Story cards.
11 December 20013 – We reviewed the User Stories that we had received at this point (141). WE removed some user stories that seemed to be either test scenarios (examples of a search) or ones that suggested fields in the database. These user stories will be used to help create the database and used to create test searches for the ERD tool.We grouped them under themes and amalgamated the duplicate requirements. We kept a note of those which were requested multiple times to consider as part of the prioritisation process. This gave us 36 Requirements to take forward to the prioritisation stage. 5 Additional requirements were added after a final requirements gathering session with a key stakeholder which could not take place until 10 January 2014.
Lessons Learned
Low participation numbers suggests the timing of these events may not have been ideal as despite sending out timely emails on several mailing lists and utilising personal contacts, it was hard to get participants. We also had 4 cancellations across the events due to work commitments. The events coincided with the final week of teaching for staff so it may have been preferable to schedule them a week or two later in the semester. However at the time we felt we could not do this as it would have too great an impact on project deadlines.
This was also reflected in the responses to the evaluation forms where participants noted that they would have preferred to work in larger groups.
However when combined with the response to the survey which was predominantly from teaching staff we do feel that we have requirements representative of the user population.
Another lesson learnt was the way in which you discuss the project in a presentation is key, we learnt from this throughout the workshops and tweaked the presentation after the first couple of workshops.
Summary of the Prioritisation process
Process
Before the prioritisation events we reviewed the requirements and gave each a weighting which reflected the amount of effort we estimated would be required to implement this. These were numbered in the Fibonacci number series: 1, 2, 3, 5, 8, 13, 21, 34(this was as high was we needed). This sequence was used as the sharp rise in the numbers reflects the uncertainty that is introduced to any estimation as you become less certain of how to implement a requirement. It also allows an easier way to agree on the estimation of effort as the difference between effort 8 and 10 is difficult to quantify while a difference in effort between 8 and 13 is easier. Each requirement and its weighting was then printed out onto A4 card for the prioritisation events.
To prioritise the requirements we ran 4 poker chip prioritisation workshops with users. These started with a 10 minute introduction to the project and the techniques we were using for requirements gathering. Some of the participants at the events had already participated in the requirements gathering events but several were new to the project and so needed this context to be able to participate fully . After this we gave each participant 20 poker chips and instructed them to read the requirements (laid out across several tables) and to play the correct number of chips (either individually or in together) to vote for an item. We encouraged them to discuss the requirements both with each other and with us and to move chips about as required. We then grouped the cards together that had received votes and asked the participants to review the group as a whole and decide if anything important to them was missing, with the option to change votes until they were satisfied.
Prioritisation Events
Wed 8th Jan 2014, 10 - 11:30, 4 Participants
Friday 10 January 2014, 10 to 11 – 1 Participant (a key stakeholder)
Monday 13th Jan 2014, 14:30-16:00, 6 Participants
Tuesday 14th Jan 2014, 14:30-16:00, 3 participants (2 cancellations)
4 Events 14 Participants
Event Evaluations
At the end of each session we handed out short evaluation forms with the same questions as used for the requirements gathering events. We received 11 completed evaluation forms. Several participants said they appreciated the ability to shape the tool, discussion and finding out about the project. People were positive about the technique but several did mention that they think it would have worked better in larger groups.
Outcomes
Before the events we created a spreadsheet listing all the requirements and after each event we logged the votes on this. After the events we added the votes together for each requirement divided this by 41(the number of requirements) and multiplied this by 100 to give a number representing how highly rated each requirement was. We then sorted the spreadsheet into this order.
As a sanity check we looked at the order of items in relation to those items which were requested multiple times and the two lists do appear in a broadly similar order.
We then put a red line at the point in the list where we estimate we have enough development time to complete initially. This gave a group of 11 requirements to take forward to the initial build.
Lessons Learned
We were really pleased with how this technique worked. Participants at the prioritisation events engaged really well with the process and We saw some interesting discussion which has helped us understand more clearly what the users require and why. We were also pleased that no one at these sessions suggested further requirements, which suggests that the initial round of requirements gathering was adequate. We were pleased that the final prioritisation process has led to a sensible group of requirements that make a coherent group to take forward.