Jeffrey Carlin  has identified a number of requirements that are referenced in the DMSR but that do not exist in the DMSR (or anywhere). This is reported in DM-11029 - Getting issue details... STATUS

The DM-SST will review these;  if they are relevant, we will propose via LCR to  to  include them in the DMSR, if not, the dangling references to them should just be removed.  

Criteria for evaluation

  • Verifiability - can the requirement be verified by DM?
  • Feasibility - is it feasible to verify a requirement
  • Useful  - is it useful to add these at this late stage?


Should we make the DMSR a stand alone document? 

DMSR 'dangling requirements'

ColumnSpecification

Retain/Modify/Delete
(SST recommendation)

CommentsActionsStatus

DMS-REQ-0003: Create and Maintain Science Data Archive



The LSST project shall create and manage an archive of all its public data products and the raw data necessary to reproduce them. In addition, the archive shall contain all necessary engineering and calibration data for the full understanding of the performance and operation of the Observatory.

  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this:

  • DMS-REQ-0004: Nightly Data Accessible Within 24 hrs

Derived from Requirements:

      • DMS-REQ-0003: Create and Maintain Science Data Archive
      • OSS-REQ-0127: Level 1 Data Product Availability

Which OSS requirement was this meant to shadow?  OSS-REQ-0167

  • Gregory Dubois-Felsmann Identify the OSS requirement that this one was intended to shadow   - It's OSS-REQ-0167.

Re-added to the DMSR as part of RFC-709 - Getting issue details... STATUS

DONE

DMS-REQ-0005: Produce Data Releases

All Level 2 Data Products shall be made public as part of periodic coherent Data Releases
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this:

  • DMS-REQ-0006: Timely Publication of Level 2 Data Releases (removed in LCR-962)

  • LCR: 962: We are proposing to remove DMS-REQ-0006 on the basis that "Timely publication of Level 2 Data Releases" is unverifiable by DM and is a process issue relating to operations planning. The intent of the requirement was to make the release process transparent and to remove any suggestion that LSST scientists are getting early access to data for their own publications. To aid in this we are proposing a new requirement to allow query auditing (DMS-REQ-0345).

Which OSS requirement was this meant to shadow?

DMS-REQ-0005 looks to derive from OSS-REQ-0134:

3.1.5.3.1.1 Level 2 Data Product Availability

ID: OSS-REQ-0134

Specification: All Level 2 Data Products shall be made public as part of a Data Release, with releases coming at least once every time DRT1, and as soon as possible following the completion of data release processing as is consistent with verifying the applicable data quality requirements

Removed as part of LCR-962

DONE

DMS-REQ-0007: Pipeline Infrastructure


The DMS shall provide Processing, Storage, and Network resources capable of executing the DMS Data Release pipelines over all pre-existing survey data in a time no greater than drProcessingPeriod.

  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification
  • Duplicate - correct the reference

Has been put back as DMS-REQ-0163 - it is a near-exact duplicate of the original -0007 text.


DONE

DMS-REQ-0009 


  • Accept as is
  • Delete dangling reference
  • Include with modification
  • Duplicate - correct the reference
DMS-REQ-0009 is documented as being derived from DMS-REQ-0007 but that relationship makes no sense. Remove remove dangling requirement  DMS-REQ-0007 from 3.2.1 Simulated Data ID: DMS-REQ-0009 (Priority: 1b)

TODO

DMS-REQ-0011: Produce Difference Sources

The DMS shall produce Difference Sources from the analysis of Difference Exposures.

  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this:

  • DMS-REQ-0010: Difference Exposures: : The DMS shall create a Difference Exposure from each Processed Visit Image by subtracting a re-projected, scaled, PSF-matched Template Image in the same passband.

LPG: Related is DMS-REQ-0269: The DMS shall construct a catalog of all Sources detected on Difference Exposures with SNR > transSNR.

Looks like this requirements was meant to shadow

3.1.5.2.1.4 Catalogs (Level 1)
ID: OSS-REQ-0130
Specification: The Level 1 Data Products shall include the following catalogs:

  • Exposure meta-data
  • Difference Sources (DIASources, detected by comparing visits with reference images for the same field)
  • ......


Remove dangling requirement DMS-REQ-0011 from  1.3.3 Difference Exposures ID: DMS-REQ-0010 (Priority: 1b)

Flowdown from intended OSS requirement is captured in DMS-REQ-0269:

TODO

DMS-REQ-0040: Enable BAO Analysis


The DMS shall provide the data products enabling the measurement of the effects of Baryon Acoustic Oscillations (BAO) in the detected galaxies.
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this:

  • DMS-REQ-0046: Provide Photometric Redshifts of Galaxies. The DMS shall compute a photometric redshift for all detected Objects

This requirement does not state any higher level requirement that it derives from


This was probably an attempt to take on more that what was in the SRD. The idea was that somebody should sign off to produce the inputs that are need ed - i.e provide photometric redshifts

See comment 4b) below

Remove dangling requirement DMS-REQ-0040 from 1.4.2.1 Provide Photometric Redshifts of Galaxies ID: DMS-REQ-0046 (Priority: 2) 

TODO

DMS-REQ-0041: Measure Intrinsic Ellipticies of Small Galaxies



The DMS shall measure the intrinsic ellipticities of small galaxies. The maximum galaxy size for this requirement is 10 arcsec. The measurement error goal for this is TBD.

  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this:

  • DMS-REQ-0047: Provide PSF for coadded images. The DMS shall determine a characterization of the PSF for any specified location in coadded images.

Related to OSS-REQ-0161, which was recently rewritten in LCR-1405 to not specify requirements on the measurement of galaxy ellipticity

DMS-REQ-0047 also derives from 3 OSS REQs:

  • OSS-REQ-0153: World Coordinate System Accuracy
  • OSS-REQ-0316: Wavefront Sensor Data
  • OSS-REQ-0136: Co-added Exposures

L: Requirement to provide PSF is not only driven by the need to measure ellipticity of galaxies.

See comment 4b) below

Remove dangling requirement DMS-REQ-0041 from 1.4.12 Provide PSF for Coadded Images ID: DMS-REQ-0047 (Priority: 1b)

TODO

DMS-REQ-0055: Correct for Camera Bias Structure


GPDF: Possibly meant as a derived requirement from another requirement in the DMSR
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this:

  • DMS-REQ-0060: Bias residual image: The DMS shall construct on an as-needed basis an image that corrects for any temporally stable bias structure that remains after overscan correction.

Derived from Requirements:

    • DMS-REQ-0055: Correct for Camera Bias Structure
    • OSS-REQ-0271: Supported Image Types:
    • OSS-REQ-0046: Calibration:  In calibration state the LSST system shall be capable of performing a science calibration plan. Discussion: The science calibration plan can include both the acquisition of specialized sky observations or instrumental characterization data (e.g. dome flats, dark and bias images).


Remove dangling requirement DMS-REQ-0055 from 1.5.4 Bias Residual Image ID: DMS-REQ-0060 (Priority: 1a)

TODO

DMS-REQ-0056: Correct for Camera Crosstalk


GPDF: Possibly meant as a derived requirement from another requirement in the DMSR
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0061: Crosstalk Correction Matrix. The DMS shall, on an as-needed basis, determine from appropriate calibration data what fraction of the signal detected in any given amplifier on each sensor in the focal plane appears in any other amplifier, and shall record that fraction in a correction matrix

Derived from Requirements:

      • DMS-REQ-0056: Correct for Camera Crosstalk
      • OSS-REQ-0349: Data Release Production Crosstalk Correction :  The data release production process shall be capable of applying crosstalk corrections for a given raft based on the data from that raft and at least dataRelXtalkMaxAmp amplifiers from other rafts.




DONE

DMS-REQ-0057: Correct for Detector Fringing


GPDF: Possibly meant as a derived requirement from another requirement in the DMSR
  • Accept and re-include as is
  • Delete dangling reference (replace references to with reference to duplicate)
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0063: Monochromatic Flatfield Data Cube ID

Appears to be a duplicate of

  • DMS-REQ-0283: Fringe Correction Frame ID. The DMS shall produce on an as-needed basis an image that corrects for detector fringing. The effectiveness of the Fringe Correction shall be verified in production processing on science data.
Remove dangling requirement DMS-REQ-0057 from 1.5.7 Monochromatic Flatfield Data Cube ID: DMS-REQ-0063 (Priority: 1b)

TODO

DMS-REQ-0058: Correct for Instrument Sensitivity Variation


GPDF: Possibly meant as a derived requirement from another requirement in the DMSR
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0062: Illumination Correction Frame
  • DMS-REQ-0063: Monochromatic Flatfield Data Cube
  • DMS-REQ-0059: Bad Pixel Map

Related to?

  • DMS-REQ-0069: Processed Visit Images
Remove dangling requirement DMS-REQ-0058 from 1.5.3 Bad Pixel Map ID: DMS-REQ-0059 (Priority: 1a)

TODO

DMS-REQ-0066: Keep Exposure Archive



The DMS shall provide an archive of all Raw Exposures taken by the LSST. All other exposure types produced by the DMS (Processed Science Exposures, Calibration Exposures, Coadded Exposures) shall either be archived, or a method shall be provided to recreate them on demand. The Archive shall be designed to be capable of managing the data for the full duration of the survey and associated data processing.
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this:

  • DMS-REQ-0065: Provide Image Access Service: The DMS shall provide a service for Image Access through community data access protocols, to support programmatic search and retrieval of images or image cut-outs. The service sh

Derived from Requirements:

      • DMS-REQ-0066: Keep Exposure Archive
      • OSS-REQ-0180: Data Products Query and Download Availability
      • OSS-REQ-0181: Data Products Query and Download Infrastructure
      • OSS-REQ-0176: Data Access

  • DMS-REQ-0068: Raw Science Image Metadata. For each raw science image, the DMS shall store image metadata.

  • DMS-REQ-0072: Processed Visit Image Content. Processed visit images shall include the corrected science pixel array, an integer mask array where each bit-plane represents a logical statement about whether a particular detector pathology affects the pixel, a variance array which represents the expected variance in the corresponding science pixel, and a representation of the spatially varying PSF that applies over the extent of the science array.

  • DMS-REQ-0074: Difference Exposure Attributes. : For each Difference Exposure, the DMS shall store: the identify of the input exposures and related provenance information, and a set of metadata attributes including at least a representation of the PSF matching kernel used in the differencing.
Readd to DMSR

Re-added to the DMSR as part of RFC-709 - Getting issue details... STATUS

DONE

DMS-REQ-0076: Keep Science Data Archive



The DMS shall provide a science data archive containing catalogs of all detected sources and objects and associated metadata that meet data quality thresholds for retention.
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this:

  • DMS-REQ-0075: Catalog Queries
  • DMS-REQ-0078: Catalog Export Format
  • DMS-REQ-0077: Maintain Archive Publicly Accessible
  • DMS-REQ-0130:  Calibration Data Products

Related also to OSS REQ:

OSS-REQ-0004: The Archive Facility. Specification: The LSST shall provide an "Archive Facility" to host the following functions:

  1. Ingest and daily processing of all raw science data;
  2. Archiving of all data - raw, engineering, and derived products;
  3. Data Release Production;
  4. Calibration Product Production;
  5. Moving Object Production;
  6. United States Data Access Center; and
  7. Data Management Operations (secondary location).

Appears to be a duplicate of

  • DMS-REQ-0003: Create and Maintain Science Data Archive

Discussion: The Archive Facility includes the personnel offices, computer equipment, and other specialized infrastructure necessary to safely execute all the functions of the listed Centers and to secure all LSST assets located at the Archive.

Replace dangling requirement DMS-REQ-0076 with DMS-REQ-0003 in 

  • DMS-REQ-0075: Catalog Queries
  • DMS-REQ-0078: Catalog Export Format
  • DMS-REQ-0077: Maintain Archive Publicly Accessible
  • DMS-REQ-0130:  Calibration Data Products


TODO

DMS-REQ-0080:Difference Sources Available within 24 hours


Detected sources and associated metadata shall be available for public access in the DMS science data archive within 24 hours of their generation by the DMS.

  • Accept and re-include as is
  • Delete dangling reference (and replace with duplicate)
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0033: Provide Source Detection Software. The DMS shall provide software for the detection of sources in a calibrated image, which may be a Difference Image or a Co-Add image.

DMS-REQ-0080 focuses on the latency whereas DMS-REQ-0033 is about simply providing software to detect sources.

Appears to be a duplicate of

  • DMS-REQ-0004: Nightly Data Accessible Within 24 hrs .

Propose to delete and replace derived from requirement under DMS-REQ-0033 with DMS-REQ-0004



Replace dangling requirement DMS-REQ-0080 with DMS-REQ-0004 in 

  • DMS-REQ-0033: Provide Source Detection Software

TODO

DMS-REQ-0081: Produce Object Catalog



The LSST DMS shall produce a catalog of all objects detected by the Detection Pipeline in at least two Difference Exposures from a single Visit.
  • Accept and re-include as is
  • Delete dangling reference (and replace with duplicate)
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0034: Associate Sources to Object. The DMS shall associate Sources measured at different times and in different passbands with entries in the Object catalog.

Appears to be a duplicate of

  • DMS-REQ-0275: Object Catalog. The DMS shall create an Object Catalog, based on sources deblended based on knowledge of CoaddSource, DIASource, DIAObject, and SSObject Catalogs, after multi-epoch spatial association and characterization
Replace dangling requirement DMS-REQ-0081 with DMS-REQ-0275 in  DMS-REQ-0034

TODO

DMS-REQ-0086: Produce Orbit Catalog



The LSST DMS shall produce a catalog of all moving objects detected by the Moving Object Pipeline (MOP)
  • Accept and re-include as is
  • Delete dangling reference (and replace with duplicate)
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0089 :Solar System Objects Available Within Specified Time

Appears to be a duplicate of

  • DMS-REQ-0273: SSObject Catalog/ The DMS shall produce a catalog of all Solar System Objects (SSObjects) that
Replace dangling requirement DMS-REQ-0086 with DMS-REQ-0273 in DMS-REQ-0089

TODO

DMS-REQ-0090: Generate Alerts



  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0029: Generate Photometric Zeropoint for Visit Image.
  • DMS-REQ-0030: Generate WCS for Visit Images

Appears to be a covered by

DMS-REQ-0274: 3 Alert Content ID. The DMS shall create an Alert for each detected DIASource, to be broadcast using community protocols, with content that includes: a unique Alert ID, the Level-1 database ID, the DIASource record that triggered the alert, the DIAObject (or SSObject) record, all previous DIASource records corresponding to the object (if any), and cut-outs of images (from both the template image and the difference image) of sufficient areal coverage to identify the DIASource and its immediate surroundings. These cutouts should include WCS, PSF, variance and mask information. The Alert should also include program and/or scheduler metadata.

No requirement derived from DMS-REQ-0274.

Propose to delete DMS-REQ-0090 and use DMS-REQ-0274.

Discussion: Would it be clearer to rename DMS-REQ-0274 to 'Generate Alert Packet' or 'Generate Alert Packet' ?


Replace dangling requirement  DMS-REQ-0090 with DMS-REQ-0274 in 

  • DMS-REQ-0029: Generate Photometric Zeropoint for Visit Image.
  • DMS-REQ-0030: Generate WCS for Visit Images

TODO

DMS-REQ-0092: Alert Attributes

For each alert, DMS shall store the pipeline parameters used to derive it, and a set of metadata attributes including at least:

  • Class of event detected
  • Confidence of detection
  • All associated information from the Object Catalog (includes Sources associated with this Object)
  • Postage stamp images centered on the Object from both difference exposures of the visit which triggered the alert, and from the template image used in image substraction.
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

 Requirements deriving from this

  • DMS-REQ-0094: Keep Historical Alert Archive:


I see no duplicate or coverage in any other requirement covering Alert provenance


LPG/EB: : DMS-REQ-0094  Keep historical alert archive will archive all the alerts 'as-sent'. This covers the postage stamp and associated information &  confidence parts. We do not classify alerts. The pipeline parameters should be part of an eventual provenance solution


Remove DMS-REQ-0092 from DMS-REQ-0094

TODO

DMS-REQ-0104: Produce Co-Added Exposures


The DMS shall produce Co-Added Exposures combining the set of exposures taken of the same region of the sky that meet a user-specified set of quality and other selection criteria. These may include site conditions (seeing, sky brightness), telescope conditions (wavefront quality), PSF shape and spatial variability, date of exposure, or filter used.

Each Exposure contributing to a Co-Added Exposure shall be projected onto a common reference frame using a projection selected from a set of options by a Policy. [ACTION: harmonize with co-add pipeline requirement, enumerate the types of coadds required]

  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0106: Coadded Image Provenance
  • DMS-REQ-0030: Generate WCS for Visit Images

Appears to derive from  OSS-REQ-0136: Co-added Exposures

Seems to be (partially) covered by DMS-REQ-0278: Coadd Image Method Constraints

There are several type-specific coadd requirements,

  • DMS-REQ-0280: Template Coadds
  • DMS-REQ-0281: Multi-band Coadds
  • DMS-REQ-0279: Deep Detection Coadds
  • DMS-REQ-0330: Best Seeing Coadds
  • DMS-REQ-0335: PSF-Matched Coadds

all that derive from OSS-REQ-0136: Co-added Exposures.

Suspect that DMS-REQ-0104 meant to be one requirement deriving from OSS-REQ-0136 with the type-specific coadd requirements in the DMSR deriving from DMS-REQ-0104

Following the reasoning of 4b) in the comments below, I propose to re-add this requirement to make the DMSR more standalone.

Readd DMS-REQ-0104: Produce Co-Added Exposures. Add enumeration of type-specific coadd requirements  listed in DMSR already.  Change type-specific coadd requirements "derive from" to DMS-REQ-0104 from OSS-REQ-0136

TODO

DMS-REQ-0116: Extended Object Shape Parameters


For extended objects only, the summary metadata attributes must also include shape parameters.
Weak lensing studies require the image moments (or equivalent) through N=2.
For weak lensing extended objects of size greater than TBD (10 arcsec?) do not require shape parameters to be measured
  • Accept and re-include as is
  • Delete dangling reference
  • Include with modification

Requirements deriving from this

  • DMS-REQ-0070: Generate PSF for Visit Images. The DMS shall determine a characterization of the PSF for any specified location in Processed Visit Images

There is no mention of extended objects in the OSS

A related requirement is:

  • DMS-REQ-0052: Enable a Range of Shape Measurement Approaches. The DMS shall provide for the use of a variety of shape models on multiple kinds of input data to measure sources: measurement on coadds; measurement on coadds using information (e.g., PSFs) extracted from the individual exposures; measurement based on all the information from the individual Exposures simultaneously.

Related: (LCR-1405):

OSS-REQ-0161: Deep Detection and Measurement Quality.  The Object catalog shall include shape measurements that permit the recovery of constant applied shears between 0.01 and 0.05 from an ensemble of isolated galaxies, with a multiplicative bias less than 0.001 and additive biases less than 0.0001.

    • Derived from Requirements:OSS-REQ-0137: Catalogs (Level 2)

OSS-REQ-0161 is not anywhere flowed down to the DMSR. Should DMS-REQ-0116 be associated with OSS-REQ-0161?

As for DMS-REQ-0040 above This was probably an attempt to take on more that what was in the SRD. See comment 4b) below

Remove dangling requirement DMS-REQ-0116 from  DMS-REQ-0070

TODO

9 Comments

  1. Leanne Guy

    Gregory Dubois-Felsmann  Thinks that most of these were supposed to be in the DMSR but there was not enough time to include them before the FDR. 

  2. Gregory Dubois-Felsmann

    To expand on that, because more of the story came back to me in the course of meeting with Leanne Guy just now:

    1. The "dangling requirements" appear in the DMSR, in general, as entries in the "Derived from Requirements" subsection under each requirement.  This subsection is autogenerated as part of the MagicDraw docgen procedure.  The ability to generate this subsection was added to the docgen template after the migration from Enterprise Architect to MagicDraw as the systems engineering database.  The first version of LSE-61 that exposes this information is from February 2017, Docushare version 14 (https://docushare.lsst.org/docushare/dsweb/Get/Version-42765/LSE-61-20170216-with-history.docx) - though with a cruder template than the current version.  This means that at earlier times the document reviews that occurred, e.g., for FDR, did not expose this information.  This answers the "how is it that this wasn't noticed before" question.
    2. A full OSS-to-DMSR flowdown was not presented at FDR (this is work that was triaged at that time in the light of limited systems engineering resources)
    3. The reason the relationships exist in the model at all at this time derives from prior practice in the systems engineering group in which, when a requirement was "deleted" it was not actually deleted from the model, but moved aside into a folder that was excluded from document generation.  Because the "deleted" requirement was not actually deleted, the relationships between the "deleted" requirement and other requirements were also not deleted from the model, and are still available to the docgen even though the target requirements are not themselves included in the docgen.  (E.g., DMS-REQ-0009 is part of the DMSR, while DMS-REQ-0007, to which it refers, is in the "excluded from docgen" folder.  While DMS-REQ-0007 itself, properly, does not appear in the docgen, the template fails to hide the DMS-REQ-0009-to-DMS-REQ-0007 relationship.
    4. The set of requirements that were excluded from the docgen, but appear above because they have relationships with other requirements that are still in the DMSR, were "deleted" (moved aside) for a variety of reasons - it's definitely not a single story.  I've identified two specific reasons that account for quite a few of the cases.
      1. Some of the very high-level deleted requirements, like DMS-REQ-0003, were, in the run-up to the FDR, recognized as being very nearly copies of associated OSS requirements.  The SE team decided that these would be best represented using the SysML <copy> relationship, but that was not available in a useful way in EA at the time, so as an interim decision it was decided not to duplicate them "by hand" in the DMSR at all (thereby making the DMSR not a truly standalone document, but only usable together with the OSS).  This was not seen as a permanent decision, but we never actually went back to fix this up.  In those cases where quasi-OSS-duplicates, like DMS-REQ-0003, had been present in the DMSR, we decided to remove them and only put them back, eventually, in the "correct" way using the <copy> relationship.  This is now possible in MagicDraw.  It would be extremely useful to complete this work now so that the DMSR can finally be a truly standalone document; that will greatly facilitate verification.
      2. Some of the deleted requirements, like DMS-REQ-0040 and DMS-REQ-0041, arose from an abandoned attempt to provide science-oriented flowdowns for some requirements like "provide photo-z's" which were otherwise difficult to derive from higher-level requirements.  The SE group eventually decided that this approach produced more problems than it solved, especially with verification, and these requirements should not be restored to the document.  The flowdown links to these deleted requirements should be removed, and it is acceptable to completely remove the offending requirements from the model.  It may or may not be worth looking at providing alternate flowdown for, e.g., the provision of photo-z's.
      3. Requirements DMS-REQ-0055 through DMS-REQ-0058 arose from an abandoned attempt to connect detailed requirements for the ISR code to expected imperfections in the Camera data.  While the reason this was abandoned is difficult to reconstruct - I suspect we just ran out of time - in this case the question should go to the Science Pipelines groups: is it useful to have requirements in this area, and would it be possible to write them in a verifiable way?

    I volunteered to look at the "4a" class of requirements and see which OSS requirements could be used in the DMSR via <copy> to replace them.

    Leanne Guy and I will continue looking at this next week.

  3. Michael Wood-Vasey

    Leanne Guy I read through the above and Gregory Dubois-Felsmann 's explanation and plan make sense to me.

    I understand that the plan is:

    4a - Copy from OSS: Gregory Dubois-Felsmann will provide recommendations and ask Systems Engineering to implement.

    4b - Detritrus: Gregory Dubois-Felsmann will tell System Engineering to drop these

    4c - ISR+Camera: Michael Wood-Vasey and Robert Luptoncan take responsibility for these, but with a low priority.  These requirements will be hard to write down in useful way.

  4. Gregory Dubois-Felsmann

    This has become relevant to  RFC-709 - Getting issue details... STATUS  this week.  Picking up the ball again.

  5. Gregory Dubois-Felsmann

    I'm proposing on  RFC-709 - Getting issue details... STATUS  that modified versions of DMS-REQ-0003 and DMS-REQ-0066 be restored to the DMSR to support a more logical document flow and improve the flowdown of the LSR-REQ-0049 requirement for on-demand re-creation of un-archived data products.

    1. Leanne Guy

      This was done

  6. Leanne Guy

    Gregory Dubois-Felsmann I have completed a concrete proposal based on the comments above. Could you review please. 


  7. Leanne Guy

    Jim Bosch Could you review proposal for DMS-REQ-0104: Produce Co-Added Exposures and comment please

    1. Jim Bosch

      The proposed action for DMS-REQ-0104 sounds good to me; I like that it helps a bit with the interpretation of the word "user" in its spec, which otherwise makes it sound like science users are telling us the criteria that sets what goes into our coadds; with those other existing requirements as dependencies, I'm comfortable with that "user" referring to whoever is configuring the pipeline for one of those coadd types (i.e. actually a DM developer).

      That said, I am a bit confused by the reference in the comment in the table to Gregory Dubois-Felsmann  (4b) bullet, as that seems to recommend the opposite (dropping the requirement) of the action being proposed for this one.