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

Document History

	Version	Date	Authors	Description	Validator	Validation Date
	0.1.0	18/01/2016	RACHEX, GERRY, BLANC	Creation of this page	TBC	TBC

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 : They are the gross astronomical images (not preprocessed). It contain full of information on the celestial objects but also many electronic noise or artefacts which degrades the image (thermal noise, random noise, sky glow, read noise, etc., dusts on the matrix CCD or on the filters, space rays, passages of artificial satellites or falling stars, sometimes a gradation caused by the light pollution or the internal or infrared bright reflections)

DARK : Pictures taken ideally in the same temperature, same binning and with the same time of exposure as the LIGHT, but with the lid in front of the objective of the telescope. The objective of the images DARK is to capture defaults (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 SIGMA REJECT WITH NORMALIZATION. 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.

3.Specific requirements, covering functional, non-functional and interface requirements

3.2 Functions

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 Requirement X.Y.Z (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 Requirement X.Y.Z (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: