User Requirements :

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

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: • the people involved • the organization of the development process • the technology used • The way to progress is to study and improve the way software is produced • better technology only helps once the organizational framework is set • 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 • the results prove that the economical benefits are largely worth the investment • early defect detection, time to market, and quality also improve, to the point that the return on investment for SPI is about 500%

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 • analysis  design  coding • each phase starts following the completion of the previous one • The Iterative Incremental Development model • 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. Software process standards • Capability Maturity Model • Software Engineering Institute • SPICE • the path to an international standard • ISO 15504 • on the way to become an international standard • PSS-05 • ESA

5. 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 to distinguish them logically to identify documents that are the outcome of the various phases Software life-cycle

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

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

8. 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

9. 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

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

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

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. Quantitative attributes that are part of the specification of a capability: capacity speed accuracy Communication interfaces Hardware interfaces Software interfaces Human interaction Adaptability Availability Portability Security Safety Standards Resources Timescales Details on the specification of UR Capability requirements Constraint requirements

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

16. Introduction Purpose of the document Scope of the software Definitions, acronyms, abbreviations References Overview General description Product perspective User characteristics General constraints Assumptions and dependencies Operational environment Specific requirements Capability requirements Constraint requirements The User Requirements Document 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. Physics and processes requirements Heavy ion interactions with molecular structures Low-energy electromagnetic interactions Low-energy hadronic 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 From the SOW (1)

18. 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 From the SOW (2)