Personal thoughts only for discussion - these do not represent any project consensus (Graham Klyne, 2011-06-13)
Our first 6 months have been a useful period of getting to know each other and how we can best work together. This aspect has been particularly apparent in the preparation of the first round of deliverables that has substantially involved all (or most) project members. The following thoughts are my personal reflections concerning the work that led to preparation of the Month 6 project deliverables, which were substantially concerned with initial user requirements arising from bioinformatics and astrophysics use-cases. These are presented in the spirit of agile retrospection, that we might perform better in future, and are in no way intended to be read as criticisms of any persons or group.
In summary, I think there are three main areas where improvements may be possible:
- deliverable documents driving the specific project work rather than vice versa
- duplication and overlap of requirements gathering effort in the different task force areas
- activities to check that all high priority user requirements get addressed in a technical work package
Deliverables driving specific work
I feel that much of the work we did at the end of April and all of May was driven specifically by the needs of the deliverable documentation rather than the needs of the project. Much good work was done in this process, but as the effort was targeted for the deliverables, much of it was prepared in a form that is not immediately amenable to ongoing project work, which I feel risks duplication.
My suggestion for improvement would be that we consider future deliverables earlier than a month or so before their due date, and plan the project work accordingly to prepare the required materials in a living form (wiki, repository data files, etc.), so that the writing of deliverables becomes mostly an editorial process. As is often done for software, I think we should plan for a "feature freeze" at least 2-4 weeks before the deliverable due date, to avoid doing work for the published documentation that is not reflected in the ongoing project record. There is a parallel here with the notions of "working research object" and "publication research object": the publication object should not contain information that is not present in the working object.
To make this work, we would need to be aware of what is needed for the deliverables as we do the project work. I would suggest that the time to consider the deliverable outline contents should be at the start of a deliverable cycle, not one month before the end. This would allow us to consider the work that needs to be done, and allow more time for coordination between the various task forces (see next point).
Fragmented requirements documentation
When I reviewed the Month 6 deliverables, I noticed (as others have also noted) that there was a fair amount of duplicated content, and (I suppose) corresponding duplicated effort. Apart from the lack of time for effective coordination noted above, I think there is a problem that the requirements gathering was focused on, or driven by, the technical areas rather than the user domains. This may be in part because of the deliverable-driven nature of our work during this phase. For myself, I did not fully realize until rather late in the day the extent that I needed to be more involved with the USER task force activities as well as the technical area that I'm employed to consider. Further, there were some important user requirements (i.e. important from the users' perspective) that were excluded from some of the technical requirements documents, and were somewhat under-represented in the deliverable documentation.
When I started my own work on D4.1, the problem that immediately struck me was that we were being asked to define user requirements in terms of technical features, which I feel is rather putting the cart before the horse (http://www.phrases.org.uk/meanings/put-the-cart-before-the-horse.html). This led quite rapidly to my proposal at http://www.wf4ever-project.org/wiki/display/docs/User+requirements+elicitation+and+analysis+-+proposal, which was subsequently used to lesser or greater extent for each of the D2.1, D3.1 and D4.1 deliverables.
I would suggest that the requirements gathering process should be centred squarely in the bioinformatics and astronomy users work packages, and the USER task force activities. The role of the life-cycle, collaboration and integrity/authenticity technical work packages should be to filter the articulated requirements to identify corresponding technologies or implementation strategies for their delivery. I would suggest that rather than being titled "... initial requirements", the technical requirements documents might better have been titled as "... requirements satisfaction plan" (or some variation of this idea), to emphasize the shift from user- to technical- considerations. Much of the material that ended up on the D2.1, D3.1 and D4.1 documents might have better been covered in D5.1 and D6.1. This would have lead to the bulk of the work performed for user requirements elicitation and analysis (per http://www.wf4ever-project.org/wiki/display/docs/User+requirements+elicitation+and+analysis+-+proposal) being documented in D5.1 and D6.1, which I think would make it easier to present a comprehensive list of user requirements in one place, and use that as the starting point of requirements analysis for the technical work-packages.
Further, I would suggest that work conducted under the user requirement work packages would include some activity to cross-check the technical requirements to ensure that all the high priority user requirements are actually being addressed, as it is possible for the technical packages to assume that user requirements they do not addressed are being handled by one of the other packages.
Requirements gathering and documentation
I think there is plenty of scope for improvement in the requirements elicitation process (http://www.wf4ever-project.org/wiki/display/docs/User+requirements+elicitation+and+analysis+-+proposal), and I look forward to refining this. One of the things I'd like to be able to do is keep the original requirements data (as distilled and analyzed from user scenarios) in a structured form that is amenable to some level of automated processing to eliminate some of the menial secretarial work involved in its presentation (I invoke the spirit of "Connoly's Bane" here: http://www.ninebynine.org/SWAD-E/Scenario-HomeNetwork/HomeNetwork/HomeNetwork-347.htm).
http://www.ninebynine.org/SWAD-E/Scenario-HomeNetwork/HomeNetwork/HomeNetwork-347.htmI also felt that the D3.1 collaboration requirements document did a better job of presenting the transition from user requirements to technical specifics than I did for the D4.1 integrity requirements document. D3.1 (http://repo.wf4ever-project.org/Content/17/D3.1.pdf) section 7 ("Technical requirements") enumerates and describes the various technical features (or "dimensions") that are referenced in the projection from user requirements to technical requirements in section 4 ("Use cases and user requirements summary"). By comparison D4.1 (http://repo.wf4ever-project.org/Content/18/D4.1.pdf) briefly sketches the technical requirements and then attempts to map them to "technical dimensions", which caused some confusion while we were preparing the document; partly, I think this was a mixing of technology-specific requirements analysis with a more general analysis of user goals.
I also noticed that D2.1 (http://repo.wf4ever-project.org/Content/12/D2.1.pdf) in section 10 ("Technical requirements") goes beyond the technical requirements to distill functional and representational requirements. I think this is a useful addition, and should be added to the methodology. I speculate that this phase should probably be documented in the technical work package deliverables.