Skip to content

Requirements

Chris Meyer edited this page Jan 22, 2020 · 1 revision

Requirements

Requirements should be necessary, attainable, and verifiable; and written in clear concise sentences.

Requirements should only state what the software is supposed to do in terms of functional and non-functional requirements and use cases.

This is not a design document.

When referring to an item in this requirements document, please specify the Git commit hash and the reference within this document.

Terminology

"application", "app", "procedure", "workflow", "flow", "analysis", or "activity" to describe the general object type representing the analysis.

"instance", "settings", "configuration", "data", "copy", "quantification", "analysis" to describe an internal object for a specific analysis.

Data

Data collected during a synchronized acquisition may have several components that shared a coordinate system.

TODO: Defining regions of interest via graphics on various representations and views of the data should synchronize those graphics and regions of interest between all other representations and views of the data.

Coordinate Systems

Graphics on displays should be mirrored to other displays with the same coordinate system.

Line Plots

Line plots should support multiple layers (composite line plots).

TODO: Each layer should be optionally offset vertically to distinguish it from other layers.

TODO: Each layer should be optionally scaled separately from other layers.

Exploration

User should be able to explore a synchronized acquisition data set using picker tools.

The picker tools should be used on a spatial representation of the synchronized acquisition.

In the case of EELS data with one collection dimension, the spatial representation may be an image where the y-dimension is the sample index and the x-dimension is energy.

In the case of EELS data with two collection dimensions, the spatial representation might be the associated HAADF or similar channel, or it might be a summed range of energy in the EELS data itself.

In the case of EELS data with 2D data, it is assumed that a 1D "projection" of the 2D data is available.

TODO: The case of Ronchigram data with one collection dimension.

In the case of Ronchigram data with two collection dimensions, the spatial representation might be the associated HAADF or similar channel, or it might be a reduction of the Ronchigram such as an integration between two concentric rings to produce something similar to a HAADF or similar channel image.

The picker tools should be able to use point or rectangle as a source region of interest and the reduction should be either summing or averaging.

TODO: The picker tools should be able to use a combination of points, lines, rectangles, ellipses, polygons, and other regions as a source region of interest.

TODO: The user should have the option of summing or averaging over the region of interest to produce a representative spectra.

TODO: The user should be able to construct multiple regions of interest on spatial representations of the synchronized acquisition and have them appear simultaneously in the target display for comparison.

TODO: In the case of a line plot, they will appear as multiple layers in a composite line plot display.

TODO: In the case of an image, they will appear as different colors composited into a color image.

Edge Identification

The user should be able to use tools to identify edges on any 1D EELS spectra.

The user should have a way of manually identifying edges by drawing an interval and selecting edges known to exist in that interval.

TODO: The user should have a way of automatically identifying edges present on any 1D EELS spectra.

TODO: The user should have a way of automatically identifying edges present in any collection of 1D EELS spectra.

Edge Analysis

Edge Processing

Composition Analysis

Phonons

Other

Dealing with the lifetime of each of the objects.

User can create new (empty) quantification instances or copy existing ones. Copying existing quantification instance does not need to copy displays and other items which are optional.

User can view a list of quantification instances.

User can delete quantification instances. Deleting an instance will delete any items that are dependent on the quantification.

User can add edges instances to quantification instances.

User should be able to adjust parameters, such as energy intervals, background model, and cross section model associated with edges of interest.

?? Interval may be designated as a signal interval. Does that implicitly create an edge instance? Does it also implicitly create a quantification instance? If so, how does user know about the new objects? Can instances be treated as "unattached" and deleted when the associated graphic items are removed?

Quantification

Background Subtraction - named vs anonymous

JC: Quickly find max position in a peak with a click.

ZLP alignment, adjustment, and positioning.

Calibration of a spectra should back-calibrate to original data.

Spectrum image with 1D or 2D datum. Picked spectra. Edge mapping (quantification when properly calibrated). Edge mapping by color. Thickness mapping.

TODO: HD spectrum image? Multiple spectrum images where each one represents an energy range.