AstroImage/SRS

Read first:
 * http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
 * http://en.wikipedia.org/wiki/Software_requirements_specification
 * IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

=1.  Introduction=

1.1 Purpose of the requirements document
The purpose of this document is to present a detailed description of the astro images processing software. The purpose of this SRS document is to provide a detailed overview of our software product, its parameters and goals. This document describes the project's target audience and its user interface, hardware and software requirements. This document is intended for both the stakeholders and the developers of the software.

1.2 Scope of the product
This software system will be a Astro Images Processing System for Amateur astronomers. This system will be designed to preprocess and process astronomical images. By maximizing preprocess and process efficiency, the system will meet the customers’ needs while remaining easy to understand and use.

1.3 Definitions, acronyms and abbreviations
LIGHT : It's a gross astronomical image (not preprocessed). It contain lots of information about celestial objects, but also many electronic noise or artifacts which degrade the image (thermal noise, random noise, sky glow, read noise, etc., dusts on the matrix CCD or on the filters, cosmic rays, passages of artificial satellites or falling stars, sometimes a gradation caused by the light pollution or internal or infrared bright reflections)

DARK : Image ideally taken at the same temperature, binning and even with the same exposure time as LIGHT images, but with the cover in front of the objective of the telescope. The objective of DARK pictures is to capture defects (noise and interfact) which degrade the LIGHT image.

MASTER DARK : It is important to take a series of at least about fifteen images DARK and to combine them by sigma reject without normalization to make a MASTER DARK. It is this the one who will allow to correct the presences of noises, space rays and other defects on the LIGHT.

FLAT FIELD : Images taken by a surface or a bottom of sky enlightened uniformly. These images will serve to capture gradations, dusts, vignetting present in our LIGHT images.

MASTER FLAT : It is obtained by combination by sigma reject with normaliation. Normally a good MASTER FLAT corrects the images of dusts and vignetting of the optics and certain gradients. But he is not compulsory and can sometimes degrade the image.

THERMAL NOISE : Hot pixel caused by the thermal noise produces by the electronics of the camera.

RANDOM NOISE : Electronic noise which is totally unpredictable

SKY GLOW : Noise caused by the light pollution

READ NOISE : Noise caused by the download of the images

DITHERING : It consists during the acquisition of the images, to move slightly the telescope of some pixels between each of the LIGHT images to create a light movement between the images. We can so eliminate totally artefacts (hot pixels, space rays, tracks of plane, meteors, etc.) during the combination(overall) by SIGMA CLIP (SIGMA REJECT).

1.4 References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.

1.5 Overview of the remainder of the document
The next chapter, the Overall Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The third chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product. Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language.

=2.  General description=

2.5 Assumptions and dependencies
=3.Specific requirements, covering functional, non-functional and interface requirements=

3.2.1 Processing of Dark (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.2 Creation of Master Dark (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.3 Processing of Flat (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.4 Creation of Master Flat (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.5 Calibration (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.6 Debailleurisation (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.7 Registration (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.8 Overlapping of lights (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.9 White balance (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.10 Adjustment of the contrast (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.11 Noise deletion (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.12 Deletion of the light pollution (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.13 Deletion of the green dominant (in Structured Natural Language)
Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:
 * Natural language sentences (with MUST, MAY, SHALL)
 * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
 * Mathematical Notations
 * Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.6 emergent system properties and quality characteristics
=4. Product evolution=

=5. Appendices= =6. Index=