User requirements
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

User Requirements : PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Geant4-DNA. User Requirements :. their definition and application in the project. Maria Grazia Pia Genova, 31 May 2000. The benefits of software engineering.

Download Presentation

User Requirements :

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

User requirements


User Requirements:

their definition and application in the project

Maria Grazia Pia

Genova, 31 May 2000

The benefits of software engineering

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%

The software process

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

Software process standards

Software process standards

  • Capability Maturity Model

    • Software Engineering Institute


    • the path to an international standard

  • ISO 15504

    • on the way to become an international standard

  • PSS-05

    • ESA

Software life cycle

Various phases:

User Requirements definition

Software Requirements definition

Architectural Design

Detailed Design and construction

Delivery to the user


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

What is requirements engineering

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



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

Capture of user requirements

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

Methods for user requirements capture

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

Problems in requirements elicitation

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

How to involve the users

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:


structured meetings

steering committees

user liaisons


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

User requirements should be realistic

Realistic user requirements are:






Clarity and verifiability

the delivered system will meet user requirements

Completeness and accuracy

the URD states the users’ real needs


useless to request superfluous capabilities or unnecessary constraints

User requirements should be realistic

Specification of user requirements

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

Details on the specification of ur

Quantitative attributes that are part of the specification of a capability:




Communication interfaces

Hardware interfaces

Software interfaces

Human interaction









Details on the specification of UR

Capability requirements

Constraint requirements

Requirements analysis validation and management

Requirements analysis

The requirements gathered during elicitation are analysed for




missing requirements

extra requirements

Requirements validation

The requirements are checked for




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

The user requirements document


Purpose of the document

Scope of the software

Definitions, acronyms, abbreviations



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

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

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)

From the sow 2

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)

  • Login