/
10.Requirements Analysis

10.Requirements Analysis

#

Requirements

Details

Questions/Difficulties

Estimate(man-hours)

Response from Artic

Status

#

Requirements

Details

Questions/Difficulties

Estimate(man-hours)

Response from Artic

Status

1

Functionality to create sub-tasks for multi-object requests based on # of Object IDs selected for Jira applications outside of the Imaging app. Currently sub-tasks are based on # of object IDs x views, light type, etc. Artic would want to maintain that functionality for IMAGEREQ but enable multi-object requests for non-IMAGEREQ applications

Currently we have this provision for multiObjectType1 and multiObjectType2 requests from CITI.

  • What do we mean by non-IMAGEREQ applications? Are these different projects in JSD(JIRA)?

  • How issues will be created in Jira? Will they be created through a separate JSD portal? Will they be created under a different project other than IMAGEREQ?

 

  1. Yes these are different projects in JSD. IMAGEREQ has its own set of reuqirements for sub-tasks, however, other JSD apps will only need to consider # of Object IDs.

  2. Launched via CITI (Object Manager, same as Imaging) - under a separate JSD portal, different projects than IMAGEREQ

priority 1

Estimating

2

Functionality to tighten up the failure response of the Imaging app in the new multi-node environment based on the discussions with Artic

  • Deletion of temporary files

  • Responsibility to process the custom plugin logic has to be taken out of each node into a separate app

  • Some kind of asynchronous processing has to be introduced

  • In order to take out the entire logic into a separate process will take large amount of time. Currently we are using JIRA’s java api to get detail about issues and other things which are required at runtime in order to perform tasks like creation of tasks and sub-tasks. If we abstract out this details in another app then the entire communication has to be done with Jira using REST api calls to the Jira data center

  • We will have to take out the entire logic that we have written so far for server(data center) and put it into another framework which supports asynchronous processing

 

Let me review this with the team and see if we need to do this.

Priority 3

have concerns

3

Functionality to create sub-tasks using the Object (not in CITI) request forms based on comma separated list in the Object ID field x views, light type, etc. Seems like this would require CITI Request Type ID and CITI Request ID to be populated. wondering if we can do this via post function or something like that.

I think we already have the provision to make these changes in the code for Object(not in CITI). We will have to modify the code to take into account the comma separated values in object id field.

Do we have to retain the earlier functionality to create sub-tasks based on only views, light type, etc.(and implement this change as a separate functionality) or modify the existing behavior to consider comma separated values in object id field while creating sub-tasks along with views, light type, etc ?

 

  1. Yes, retain earlier functionaity to create sub-tasks based on views, light type, etc. The only difference is that this form is launched directly from the Jira portal and not CITI for the IMAGEREQ project only. The comma separated list of Object IDs will be manually entered in the Object Photography Request (not in CITI) form.

priority 2

Estimating