1. Maria Grazia Pia, INFN Genova 1 User Requirements: Maria Grazia Pia Genova, 31 May 2000 their definition and application in the project Geant4-DNA

2. Maria Grazia Pia, INFN Genova 2 The benefits of software engineering ] The goal: producing better software at lower cost, within predictable resource allocations and time estimates, and happier users of the software ] Three key components: l the people involved l the organization of the development process l the technology used ] The way to progress is to study and improve the way software is produced l better technology only helps once the organizational framework is set l there is evidence that going for new technology instead of improving the process can make things worst ] The practices of SPI are well established, and have been applied in a large number of organizations for several years l the results prove that the economical benefits are largely worth the investment l early defect detection, time to market, and quality also improve, to the point that the return on investment for SPI is about 500%

3. Maria Grazia Pia, INFN Genova 3 The software process Complex domain, evolving, with many types of models available; some examples of software process models are, for instance: ] The Waterfall model l analysis  design  coding l each phase starts following the completion of the previous one ] The Iterative Incremental Development model l cycles of analysis  design  coding, with incremental refinement It is the set of actions, tasks and procedures involved in producing a software system, through its life-cycle

4. Maria Grazia Pia, INFN Genova 4 Software process standards ] Capability Maturity Model l Software Engineering Institute ] SPICE l the path to an international standard ] ISO 15504 l on the way to become an international standard ] PSS-05 l ESA

5. Maria Grazia Pia, INFN Genova 5 Software life-cycle Various phases: ] User Requirements definition ] Software Requirements definition ] Architectural Design ] Detailed Design and construction ] Delivery to the user ] Operations ] Frequently the tasks of different life cycle phases are performed somewhat in parallel to consider them disjoint in time is a simplification ] It is however important l to distinguish them logically l to identify documents that are the outcome of the various phases

6. Maria Grazia Pia, INFN Genova 6 What is requirements engineering ] Requirements engineering can be defined as the systematic process of developing requirements through an iterative cooperative process of l analysing the problem l documenting the resulting observations l checking the accuracy of the understanding gained 73% of projects are canceled or fail to meet expectations due to poor requirements definition and analysis (The Standish Group, The Chaos Report 1995) The requirements process includes the following activities: ] Requirements Elicitation ] Requirements Analysis ] Requirements Specification ] Requirements Validation ] Requirements Management

7. Maria Grazia Pia, INFN Genova 7 Requirements Requirements are the quantifiable and verifiable l behaviours that a system must possess l constraints that a system must work within Requirements are subject to evolution in the lifetime of a software project!  ability to cope with the evolution of the requirements User requirements l this phase defines the scope of the system Software requirements l this is the analysis phase of a software project l builds a model describing what the software has to do (not how to do it)

8. Maria Grazia Pia, INFN Genova 8 Capture of user requirements ] It is the process of gathering information about user needs ] PSS-05 recommends that: l UR should be clarified through criticism and experience of existing software and prototypes l wide agreement should be established through interviews and surveys l knowledge and experience of the potential development organizations should be used to help decide on implementation feasibility and build prototypes

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

10. Maria Grazia Pia, INFN Genova 10 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

11. Maria Grazia Pia, INFN Genova 11 How to involve the users ] Various methodologies/techniques ] Three main styles: l Consultative Design l Representative Design l Consensus Design Consultative Design ] Decision making power is in the hands of the developers l Users are sources of information with little or no influence ] Techniques in this style are: l interviewing l structured meetings l steering committees l user liaisons l brainstorming Representative Design ] User representatives are involved in the design formulation and decision making ] Techniques of this style are: l Joint Application Design (JAD) l Quality Functional Deployment (QFD) Consensus Design ] System development is the prime responsibility of the user l Users are continually involved throughout the design process l The users are the driving force in this style ] Techniques of this style are: l Participatory Design (PD)

12. Maria Grazia Pia, INFN Genova 12 User requirements should be realistic Realistic user requirements are: clear verifiable complete accurate feasible Clarity and verifiability l the delivered system will meet user requirements Completeness and accuracy l the URD states the users’ real needs Accuracy l useless to request superfluous capabilities or unnecessary constraints

13. Maria Grazia Pia, INFN Genova 13 Specification of User Requirements It is the process of organising information about user needs and expressing them in a document Two main categories of requirements: Capability requirements ] describe the process to be supported by the software (what the users want to do) ] define the operations that the software will be able to perform ] operations are grouped hierarchically to help manage the complexity Constraint requirements ] place restrictions on how the user requirements are to be met ] constraints on interfaces, quality, resources, timescale

14. Maria Grazia Pia, INFN Genova 14 Details on the specification of UR ] Quantitative attributes that are part of the specification of a capability: l capacity l speed l accuracy ] Communication interfaces ] Hardware interfaces ] Software interfaces ] Human interaction ] Adaptability ] Availability ] Portability ] Security ] Safety ] Standards ] Resources ] Timescales Constraint requirements Capability requirements

15. Maria Grazia Pia, INFN Genova 15 Requirements analysis, validation and management Requirements analysis ] The requirements gathered during elicitation are analysed for l conflicts l ambiguity l inconsistencies l missing requirements l extra requirements Requirements validation ] The requirements are checked for l omitted l extra l wrong l ambiguous or inconsistent requirements ] This activity also checks to ensure that all requirements follow stated quality standards Requirements management ] It is the activity of managing changing requirements during the development of the software system

16. Maria Grazia Pia, INFN Genova 16 The User Requirements Document ] Introduction l Purpose of the document l Scope of the software l Definitions, acronyms, abbreviations ] References ] Overview ] General description l Product perspective l User characteristics l General constraints l Assumptions and dependencies l Operational environment ] Specific requirements l Capability requirements l Constraint requirements The URD is a mandatory output of the UR phase To be compiled according to PSS-05 guidelines Example: Geant4 User Requirements Document http://wwwinfo.cern.ch/asd/geant/geant4_public/pub_requirements6.3.ps

17. Maria Grazia Pia, INFN Genova 17 From the SOW (1) Physics and processes requirements n Heavy ion interactions with molecular structures n Low-energy electromagnetic interactions n Low-energy hadronic interactions n Step size and energy loss requirements; secondary particle production n Other physics and processes required in biological targets in general, and in the vicinity of cells and DNA molecules in particular n Consideration of biological processes (such as DNA repair mechanisms, apoptosis) vs. physical processes Geometry requirements n Implementation of the structure of the DNA n Implementation of the composition of the DNA n Other cellular structures n Shielding provided by the biological tissue

18. Maria Grazia Pia, INFN Genova 18 From the SOW (2) Visualisation requirements n DNA and cellular structures visualisation; particle tracks n Visualisation of biological and chemical processes; visualisation of DNA ruptures n Scaling and zooming General simulation and data analysis requirements n Hierarchy and scalability of the simulation n Combination of DNA and cellular simulation results ultimately to macroscopic biological predictions n Run-time requirements