Goal:
- Using the existing context as a starting point, develop use cases for the functionality of current context.
- Analyze the use cases and requirements for the context and how they fit into the larger RADPS architecture.
Key Stakeholders(s): Takeshi Nakazato, Dirk Muders, PL developers. Mark Whitehead, Jan-Willem Steeb, Eric Koch, Amanda Kepley
Tasks:
-
Identify the use cases that are relevant to RADPS. If necessary, add any additional use cases that are not currently supported by the Pipeline context, but should be supported by RADPS. A template for the use cases is provided as a convenience, but the group is free to adopt whatever template they want.
-
Analyze the use cases developed above and RADPS requirements (including both the ngVLA and ALMA WSU cases). What characteristics should the final design have? How do these characteristics relate to the RADPS architecture?
Acceptance criteria:
- Primary RADPS context characteristics (quality attributes?) have been identified and we have enough information to proceed to the design stage.
- All relevant use cases for RADPS context have been identified and described in appropriate level of detail.
Goal:
Key Stakeholders(s): Takeshi Nakazato, Dirk Muders, PL developers. Mark Whitehead, Jan-Willem Steeb, Eric Koch, Amanda Kepley
Tasks:
Identify the use cases that are relevant to RADPS. If necessary, add any additional use cases that are not currently supported by the Pipeline context, but should be supported by RADPS. A template for the use cases is provided as a convenience, but the group is free to adopt whatever template they want.
Analyze the use cases developed above and RADPS requirements (including both the ngVLA and ALMA WSU cases). What characteristics should the final design have? How do these characteristics relate to the RADPS architecture?
Acceptance criteria: