Init1dbw13 - Forms Services

Date: 

03/10/2010

Requirement # unique id <SemConOps Initiative>.<analysts initials><requirement number>
e.g. Init1dbw1
(eventually linked to Use Cases)

Init1dbw13

Originator/Customer's Name:

Bob Friemuth for AGNIS Metadata Tool

Originator/Customer's Company:

Mayo

Summary of requirement initial analysis, by Reviewer: (as unambiguously as possible, describe who (List of Actors) is interacting with the system, what the business goal is and how the system might support the actor's ability to acheive their goal)

In the course of retrieving the metadata for a CRF from the caDSR, the
metadata curator using the generates a request to retireve a Form from caDSR. The AGNIS Metadata Tool sends a large number of web service requests to the cadsrapi40Service web service. This can take a long time, due to the large number of round trips to the server. One possible way to improve performance would be to implement a caDSR API that, instead of returning only one object at a time, could return a graph of objects in response to a single web service request. This would move processing to the server side, where it can be done more efficiently, and also improve performance by reducing the number of round trips to the server.
For example, a caDSR client tool such as the AGNIS Metadata Tool might benefit from an API capable of returning a graph of objects such as the following in response to a single query.  
The RULES (skip to/from instructions, default values or repeating group information) around the question might also be useful, such as the order of the question in the form.


> Question
>   |-- definitionCollection
>   |-- designationCollection
>   |-- instruction
>   |-- dataElement
>   |     |-- dataElementConcept
>   |     |    |-- definitionCollection
>   |     |    |-- designationCollection
>   |     |    +-- referenceDocumentCollection
>   |     |          +-- attachments
>   |     |-- definitionCollection
>   |     |-- designationCollection
>   |     |-- referenceDocumentCollection
>   |     |    +-- attachments
>   |     +-- valueDomain
>   |           |-- definitionCollection
>   |           |-- designationCollection
>   |           +-- referenceDocumentCollection
>   |                 +-- attachments
>   |-- referenceDocumentCollection
>   |     +-- attachments
>   +-- validValueCollection
>         |-- definitionCollection
>         |-- designationCollection
>         |-- instruction
>         |-- referenceDocumentCollection
>         |     +-- attachments
>         +-- valueDomainPermissibleValue
>              +-- permissibleValue
>                    +-- valueMeaning
>                           |-- definitionCollection
>                           |-- designationCollection
>>>>>>>>>>>>>>>>>>>>>>>>>>>>|-- conceptCollection
>                           +-- referenceDocumentCollection
>                                 +-- attachments
>  

Recommended Next Step Enter one: Follow-up interview, Observe, Use Case Template (text), Use Case Model (formalized/UML diagram), Group Discussion, Prototype, Waiting Room

Use Case Template to describe the 'graph' in more detail

Stakeholder Community:

Enter appropriate category of stakeholder from Primary Stakeholders:  

• Software and Application designers and architects
• Software and Application engineers and developers
• Scientific and medical researchers
• Medical research protocol designers
• Clinical and scientific research data and metadata managers
• Clinicians
• Patients
• Medical research study participants
• Broader Stakeholders: caBIG® Community WS NIH projects and related commercial COTS vendors (caEHR, SDO's (HL7, CDISC); International Collaborators (e.g NCRI, cancerGrid, China), Government and regulatory bodies (FDA, CDC, ONC)
  (link to view SemConOps Stakeholders description).
  

Requirement Type (required)

Analyst's assessement of the most appropriate category/type of requirement (no need to ask interviewee):

• Functional: Fundamental or essential to the product - describes what the product has to do or what processing is needed
  
• Nonfunctional: properties the functions must have such as performance, usability, training or documentation
  
  • Project constraint: schedule or budget constraints
    
  • Design constraint: impose restrictions on how the product must be designed, such as conformant to ISO 11179, utilizes 21090 or is able to work on a particular type of device
    
  • Project driver: business-related forces such as descriptions of stakeholders or purpose of the product/project
    
  • Project issue: conditions that will contribute to the success or failure of the project

ConOp Initiative(s)
Requirements Analyst/Business Analyst

• Select most appropriate initiative: (click for descriptions) 
• Initiative 1 - Distributed, federated metadata repositories and model repositories and operations
• Initiative 2 - Automated generation of metadata from line-of-business artifacts
• Initiative 3 - Rules management and contracts support (behavioral semantics)
• Initiative 4 - Semantics support for W3C service oriented architecture resources
• Initiative 5 - HL7 CTS II/ OMG MIF compliant federated terminology services
• Initiative 6 - Controlled biomedical terminology, ontology and metadata content
• Initiative 7 - Assessment of semantic unification of compositional and derivational models
• Initiative 8 - Other

High Level Use Case Summary)
Requirements Analyst/Business Analyst

Please write a short descriptive narrative use case; the steps or activities in this use case are usually the things the user wants to accomplish with the system (user/actor's goals).  

Use Case Linkage (required)
Business Analyst

Which use case(s) is this requirement linked to?  (should follow Use Case numbering scheme <SemCon Ops Initiative>.<analysts initials><requirement number>.<use case number>, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc.

Use case Number(s):

Conflicts / Dependencies(required)
Requirements Analyst/ Business Analyst

Are there any conflicts with other requirements / use cases? 

Yes OR No - If yes, what and why?

Next Step (required)
(Requirement Analyst / Business Analyst)

After reviewing the results of the interview, the forum, and all other materials related to this requirement, the analyst should recommend the next step, then attach the Tiny Link (on the Info tab) for this page to the Master List table.

Enter one: Follow-up interview, Observe, Use Case Template (text), Use Case Model (formalized/UML diagram), Group Discussion, Prototype, Waiting Room