User Requirements:

1
User Requirements
Geant4-DNA
Capture

• Maria Grazia Pia
• Genova, 29 September 2000

2
Work Package 2 Collection of UR

• Visualisation requirements
• DNA and cellular structures visualisation
  particle tracks
• Visualisation of biological and chemical
  processes visualisation of DNA ruptures
• Scaling and zooming
• General simulation and data analysis requirements
  
• Hierarchy and scalability of the simulation
• Combination of DNA and cellular simulation
  results ultimately to macroscopic biological
  predictions
• Run-time requirements
• Identification of areas where new physics data or
  models are required
• Identification of areas where biological
  information, data or theories are currently
  missing

• Physics and processes requirements
• Heavy ion interactions with molecular structures
• Low energy electromagnetic interactions
• Step size and energy loss requirements secondary
  particle production
• Other physics and processes required in
  biological targets in general, and in the
  vicinity of cells and DNA molecules in particular
• Consideration of biological processes (such as
  DNA repair mechanisms, apoptosis) vs. physical
  processes
• Geometry requirements
• Implementation of the structure of the DNA
• Implementation of the composition of the DNA
• Other cellular structures
• Shielding provided by the biological tissue

3
Capture of user requirements

• It is the process of gathering information about
  user needs
• PSS-05 recommends that
• UR should be clarified through criticism and
  experience of existing software and prototypes
• wide agreement should be established through
  interviews and surveys
• knowledge and experience of the potential
  development organizations should be used to help
  decide on implementation feasibility and build
  prototypes

4
Methods for User Requirements capture

• Interviews and surveys
• Must be structured, to make sure that all issues
  are covered
• Useful to ensure that UR are complete and there
  is wide agreement
• Studies of existing software
• Good or bad features of existing software can
  identify requirements for the new software
• Feasibility studies
• Analysis and design of the principal features of
  the system may show whether implementation is
  possible
• Prototyping
• Useful especially if requirements are unclear or
  incomplete
• The prototype is based on tentative requirements,
  then explore what is really wanted
• Use cases and scenarios
• Thinking systematically in a variety of situations

5
Problems in Requirements Elicitation

• Users may know what they want, but are unable to
  articulate the requirements
• Users may not know what is technologically
  capable and may not consider what is possible
• Users may have reasons for not wanting to
  communicate the requirements
• Users and developers sometimes do not speak the
  same language
• No single user has all the answers, the
  requirements will most likely come from many
  sources
• Developers may not have the necessary skills to
  get the requirements from the users
• Developers sometimes do not appreciate the needs
  or concerns of the users
• Developers sometimes tend to bulldoze the users
  into agreeing on the developers requirements

6
Proposal of organization
Goal producing the URD according to the contract
schedule (1 March 2001)

• Proposal of Project paths
• Geometry UR
• Physics UR missing models, data
• Biology UR missing models, data
• Visualisation UR
• General simulation UR

• Lets define
• Milestones
• Project paths
• Tasks
• Responsibilities

• Proposal of Milestones
• 31/10/2000 All preparatory material ready
• 30/11/2000 1st list of UR
• 20/12/2000 1st URD draft
• 15/01/2001 Iteration on the list of UR
• 7/02/2001 2nd URD draft
• 20/02/2001 Final URD

• Proposal of Tasks (all/some for each path)
• analysis of existing software, models
• survey, produce list, work plan
• prototypes
• decide which, produce list, work plan
• elicitation through interviews and surveys
• prepare template questionnaire, list of
  candidates
• discussion with Geant4 experts about feasibility

7
Responsibilities

• A responsible for each Project Path
• A Working Group for each Project Path
• decide the strategies to adopt (in collaboration
  with Project Coordinators)
• capture requirements
• write specifications
• do requirement analysis
• Deliverables
• A work plan by each Project Path responsible
  (15/10/2000)
• which approaches to adopt
• list of tasks to perform
• responsibilities within the Working Group
• Preparatory material (31/10/2000) to be discussed
  with Project Coordinators
• Questionnaire, list of sw codes, of prototypes to
  build, of people to contact for surveys etc.
• UR lists and URD drafts for the Project Path,
  according to Milestones