To analyse all the information collected for this project a method derrived from "Grounded theory" was used. The process of Grounded theory begins with a research situation. Within that situation, the researchers task is to understand what is happening there, and how the players manage their roles. This is mostly done through observation, conversation and interview. After each bout of data collection ther esaercher notes the key issues.
Constant comparison is the heart of the process. At first you compare interview (or other data) to interview (or other data). Theory emerges quickly. When it has begun to emerge you compare data to theory. The results of this comparison are written in the margin of the note-taking as coding. Your task is to identify "categories" (roughly equivalent to themes or variables) and their properties (in effect their sub-categories).
In the process of problem analysis and determining requirements we are not trying to find a theory (although one may emerge through this process), however he concept of constant comparisson of data and identification of categories and sub-categories is an importnat one. Our "research situation" is the University of Oxford and the difficulties and barriers exist in the processes of creating reading lists. If a tool is to be developed to make these processes flow more effectively we must be able to map its functionality to very specific problems, which fall into categories. If the solutions map the problems we should have an effective tool!
The analysis of the data began with categorizing problems that lay within the scenarios and use cases of current use, this was simply done through colour coding themes that ran throughout the scenarios collected via interview and surveymonkey at the "Reading Lists Workshop". Constant comparisson was made between the categories to derrive more categories from the data. At the end of the analysis two overall problem categories existed (cultural and technological) which were broken down into sub problem categories.
A white board was used to redit categories
From the suggestions made on the screenshot sheets given out at the "Reading Lists Workshop" and the functionality that had already been built into the tool, requirements were mapped to problems and placed within a hierarchy (i.e requirements to solve the most pressing / frequently occuring problems and needs came highest).
Read the "Summary report" for the analysis findings.