All Hands 2004 Requirements Workshop Gathering Requirements for an

All Hands 2004 Requirements Workshop Gathering Requirements for an Integrative Biology Project Authors: David Gavaghan, Jonathan Whiteley, Joe Pitt-Francis, Mark Slaymaker, Sharon Lloyd (University of Oxford),David Boyd Damian Mac Randal, Kerstin Kleese van Dam, Lakshmi Sastry (CCLRC) Presented by Sharon Lloyd, University of Oxford 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Project Objectives ‘The Integrative Biology Project will be developing a simulation framework, which will offer users the potential for more collaborative working, access to HPC resources and a more interactive way of working on these complex problems.’ Starting point .. • global collaborators in heart modelling, less advanced cancer modelling • no collaborative systems for users • huge variety in scientific techniques • existing grid services and tools available for reuse but no real experience of using such tools 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Why Gather Requirements? If we make Assumptions  not what users need  much rework  users demoralised  developers demoralised  lengthy projects  projects a success? 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Integrative Biology Project Process In order to understand the process we are following for Integrative Biology, we need to understand the problems we are trying to solve in building a simulation framework for scientific users.. What should the system do? How do we architect a suitable System? How do we build this architecture ? What do we need to Build Ourselves? Perform Initial requirements Exercise Define a top Level architecture Define security Policy and system needs Perform analysis Of suitable tools Gap Analysis Attempt to utilise Suitable tools from Other projects Scenarios and requirements Top Level Architecture Diagram Security policy And plan Development… Utilisation Demos 1st – 3rd September 2004 Integrative Biology Confidential Reports Slide 1 Requirements Processes- Integrative Biology • recognised need to understand the domain and the user needs • realisation that requirements would be an iterative process over project lifecycle • identified key ‘tame’ users for initial requirements capture to determine what initial prototype should do • determined key development staff as interface with users – 4 groups (security, visualisation, data management and running simulations) • setup a twiki repository for collection of requirements 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Scenarios to Requirements •Defined process using scenarios for users for translation into requirements for system where a scenario is defined as: High level description of a user task self contained, coherent, complete 1-2 paragraphs / 5-10 steps user – system interaction level User centred summary of required features And a requirement is defined as:       One idea Clear (quantified?) General Verifiable Categorized/Prioritized Traceable (to scenarios?) And has the Following attributes Integrative Biology Confidential ID – unique Source (user, scribe, date) Type Priority Requirement Justification Comments Slide 1 1st – 3rd September 2004 Benefits of using scenarios Benefits of defining scenarios.. –takes a user perspective –easy to understand by other users and developers –easy to capture –brings out functional and non functional reqs. –provides a basis for testing & user acceptance but not much help for computationally complex applications (too high level) 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Creating requirements from scenarios REQUIREMENT SCENARIO e.g. tasks for creating a cup of tea Scenario1 e.g. cup needs to be able to hold boiling water Requirement1 REQUIREMENT e.g. kettle must boil water Requirement2 From which test Scenarios may be defined REQUIREMENT e.g. tea caddy should contain tea Requirement3 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 A Sample Integrative Biology Scenario 1. 2. 3. 4. 5. 6. Write a (simple) wrapper, based on a template provided, that will interface the code's I/O to that of the HPC host, Rebuild with the supplied HPC versions of the libraries. (The compiler will "optimise" for the HPC.) Via a portal, upload the input data and executable onto the HPC system Submit the job. Through the portal monitor the job's status, and when it completes, download the result datasets Visualise results using existing visualization tools. 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 An Integrative Biology Requirement example Computational Steering: •ID 123 •Source Mac Randal, 26/2/04 •Type function •Priority must have •Requirement export of data to enable understanding of the current state of the computation. This needn’t be as detailed as final resultset •Justification need to monitor progress to know when and what parameters to change •Status arch doc, page 25: impl, modules 1,8.1,8.2 •comment should be at a checkpoint 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 How did we progress the process with the users? • • We developed focused questionaires detailing the questions each of the 4 areas wished to understand through the requirements process Held workshops to train users in the process Sold the benefits of user involvement and the ability of the users to steer the ultimate IB solution Created sample scenarios translated to requirements as examples Scenarios provided by PI and development team, e.g. Documented process and made presentations available on Twiki • • • Explained that the process would be iterative and that an initial prototype will enable further requirements to be captured 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 How did the initial requirement gathering process progress? • Provision of scenarios sporadic for several reasons so gathering of scenarios required much more hand holding and encouragement for users to express their ideas. • Development staff reviewed scenarios provided with users to ensure comprehension of tasks being performed. • Process was supplemented by a legal collaboration questionnaire which results in additional information feeding into requirements, particularly security needs 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Our Findings 1.User Fear Whilst it is considered poor practise to build systems which the developers think are suitable for users without determining the needs, we have experienced a sense of either fear or ‘I don’t want to be the first’ in providing information. One user stated, ‘I have never been asked what I wanted before – we have always had to make do with the tools available’. Another stated, ‘I am only a lowly modeller and do not feel comfortable stating requirements for a prestigious community of experienced scientists’. 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Our Findings 2. Difficulty in expressing scientific process In all but 1 case, the process resulted in the requirements capture resources writing the scenarios for the user. Often these did not result in scenarios as expected but a transcript of domain understanding. e.g. Code developed by Alan Garny in Physiology. 3. Collaboration or competition ? Our vision of researchers working collaboratively differs hugely from the collaborative work which exists globally at present. There are social as well as technical barriers to overcome. Clearly security of data and models will be a key aspect of building a system which is trusted by the user community 4. Users think they have no assets Security analysis problematic as users do not identify anything they have as assets until you suggest removing them! 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 But.. Our new understanding of the domain provides us with sufficient information to build an initial prototype. This domain knowledge is essential in determining both what we need to develop but also the process for developing it. We did not however gather precise enough scenarios to enable the Requirements team to document requirements as expected. User involvement in high level architecture definition to qualify key Services to be developed assisted with developing the bond with Scientific staff. 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Communicating with Users • Mix of IT literate (scientific hackers) and traditional mathematicians results in complex user group for communicating initiatives • Scenarios would have been ideal mechanism, domain knowledge as collected understandable by collaborating groups • High Level architecture diagram alien to some of the user community • Creation of basic use cases to be used to describe the services we will be offering the users and these will be presented in person. But • Key communication tools will be the demonstrations developed and the prototype developed from these early demonstrators. 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Conclusions • Mapping from scenarios which do not relate to tasks but describe ‘I have developed a software package which..’. Is difficult. • Mapping of existing work practises for a scientific community of such varied technical capability and desire to work collaborativel to the vision of a ‘collaboratory’ requires an understanding of the social dynamics of the partners on the project. • Development of demonstrators or prototypes as communication tools form eliciting requirements essential and result in Hopefully, an increased buy-in from users who see real science being done, not just mock-ups Earlier Results A better chance of standardisation 1st – 3rd September 2004 Integrative Biology Confidential Slide 1 Conclusions The prototype will generate a set of definitive experiences that can be quantified and qualified in terms of what worked and what didn’t work and why, which will be useful to this project and others. 1st – 3rd September 2004 Integrative Biology Confidential Slide 1