...

1. Requirements for stability from a user perspective
2. Identity of the intended users (DM / Project / non-Project, etc.)
3. Need for persistent user environments (e.g., software installations, personal data)
4. Datasets to be held
5. Need for Qserv (whether for development or because of the scale of the data to be held)

For the avoidance of doubt: "LSP" here refers to the entire three-Aspect Science Platform, not just to the Notebook Aspect as one sometimes hears in casual conversation.

Use Case perspective

Formal testing of LSP before initial and subsequent deployments to DACs during commissioning and operations

...

1. Need remain stable only long enough to verify correct operation of the integration issues at stake at any given time.  Maximum availability for testing changes, alternate deployment mechanisms, etc., is useful for developers.
2. User access during integration itself is minimal and limited to project staff checking behavior.  However, periodically, integration must be verified with larger-scale testing and user exposure as in 1.4 below.
3. Persistent user environments must be present as part of the suite of things being integrated, but there is no long-term requirement for their stability / preservation across rounds of integration work.
4. Datasets must be large enough to challenge the scaling of the components, and LSST-like enough to ensure that the full range of features needed in LSST are explored.  Presently the WISE time-domain data and a synthetically enlarged dataset are the ones being used to challenge scaling.  The first reasonably LSST-like dataset will arrive with HSC data integration this year (2018).

...

Exposure of large scientifically useful datasets through the Science Platform to encourage user evaluation and feedback

...

This was one of the primary motivations for the allocation of a significant chunk of "Integration Cluster" resources in FY2017 to create the "PDAC" (Prototype Data Access Center) as a means of realizing the FDR-era notions of "three prototype releases" of what was then called the "science user interface" (including "Level 3" support) for science community review prior to the start of operations.

1. A testing environment exposed to science users must remain stable for long enough that meaningful investigations can be carried out.  At a minimum we would like our test users to be able to attempt to reproduce analyses they have done on similar data in other ways, to confirm that existing community science use cases can be addressed in the LSP (including all its aspects). Even more desirable would be the possibility that the data provided and the unique capabilities of the LSP may enable a certain amount of new science to be done, as this would really ensure that the testing carried out was need-driven.  To enable a new analysis, a period of stability permitting multiple query-analyze-think cycles would be needed.
2. Limited resources for operational support during the present era of construction, before early operations funding becomes available, have always led us to assume that the number of users for this test environment would be small, perhaps O(10), and carefully selected to include a range of scientific perspectives and areas of interest.

Interactive environment for LSST DM developers, especially Science Pipelines, successor to ssh-in lsst-dev systems

...