Geant4-DNA
User Requirements:
their definition and
application in the project
Maria Grazia Pia
Genova, 31 May 2000
Maria Grazia Pia, INFN Genova
1
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 way to progress is to study and improve the way software is produced



the people involved
the organization of the development process
the technology used
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%
Maria Grazia Pia, INFN Genova
2
The software process
It is the set of actions, tasks and procedures involved in
producing a software system, through its life-cycle
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
Maria Grazia Pia, INFN Genova
3
Software process standards

Capability Maturity Model


SPICE


the path to an international standard
ISO 15504


Software Engineering Institute
on the way to become an international standard
PSS-05

ESA
Maria Grazia Pia, INFN Genova
4
Various phases:

User Requirements definition

Software Requirements definition
Architectural Design
Detailed Design and construction
Delivery to the user
Operations





Software life-cycle
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
Maria Grazia Pia, INFN Genova
5
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



The requirements process includes
the following activities:

Requirements Elicitation
analysing the problem

documenting the resulting observations
checking the accuracy of the
understanding gained

Requirements Analysis
Requirements Specification
Requirements Validation
Requirements Management
Maria Grazia Pia, INFN Genova


6
Requirements
Requirements are the quantifiable and verifiable
 behaviours that a system must possess
 constraints that a system must work within
User requirements

this phase defines the scope of the
system
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)
Requirements are subject to evolution in the lifetime of a software project!
 ability to cope with the evolution of the requirements
Maria Grazia Pia, INFN Genova
7
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
Maria Grazia Pia, INFN Genova
8
Methods for User Requirements capture

Interviews and surveys



Studies of existing software


Analysis and design of the principal features of the system may show whether
implementation is possible
Prototyping



Good or bad features of existing software can identify requirements for the new software
Feasibility studies


Must be structured, to make sure that all issues are covered
Useful to ensure that UR are complete and there is wide agreement
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
Maria Grazia Pia, INFN Genova
9
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
Maria Grazia Pia, INFN Genova
10
How to involve the users


Various methodologies/techniques
Three main styles:



Consultative Design
Representative Design
Consensus Design
Representative Design



Consultative Design

Decision making power is in the hands
of the developers


Users are sources of information with
little or no influence





interviewing
structured meetings
steering committees
user liaisons
brainstorming
Maria Grazia Pia, INFN Genova
Joint Application Design (JAD)
Quality Functional Deployment (QFD)
Consensus Design

Techniques in this style are:

User representatives are involved in the
design formulation and decision making
Techniques of this style are:
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)
11
User requirements should be realistic
Realistic user requirements are:
clear
verifiable
complete
accurate
feasible
Clarity and verifiability

Completeness and accuracy

the URD states the users’ real needs
Accuracy

Maria Grazia Pia, INFN Genova
the delivered system will meet user
requirements
useless to request superfluous
capabilities or unnecessary
constraints
12
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
Maria Grazia Pia, INFN Genova
Constraint requirements


place restrictions on how the user
requirements are to be met
constraints on interfaces, quality,
resources, timescale
13
Details on the specification of UR
Capability requirements

Quantitative attributes that are part
of the specification of a capability:

capacity

speed

accuracy
Constraint requirements












Maria Grazia Pia, INFN Genova
Communication interfaces
Hardware interfaces
Software interfaces
Human interaction
Adaptability
Availability
Portability
Security
Safety
Standards
Resources
Timescales
14
Requirements analysis, validation and management
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 management

It is the activity of managing changing requirements during the development
of the software system
Maria Grazia Pia, INFN Genova
15
The User Requirements Document
The URD is a mandatory output of the UR phase
To be compiled according to PSS-05 guidelines

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
Example: Geant4 User Requirements Document
http://wwwinfo.cern.ch/asd/geant/geant4_public/pub_requirements6.3.ps
Maria Grazia Pia, INFN Genova
16
From the SOW (1)
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
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
Consideration of biological processes (such
as DNA repair mechanisms, apoptosis) vs.
physical processes
Maria Grazia Pia, INFN Genova
17
From the SOW (2)
Visualisation requirements



DNA and cellular structures
visualisation; particle tracks
Visualisation of biological and
chemical processes; visualisation of
DNA ruptures
General simulation and data
analysis requirements


Scaling and zooming

Maria Grazia Pia, INFN Genova
Hierarchy and scalability of the
simulation
Combination of DNA and cellular
simulation results ultimately to
macroscopic biological predictions
Run-time requirements
18