NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Instructions

Follow the script instructions and record the information in the designated table cells. You may wish to make notes below the questions.

Pre Interview:

Item

Information/Response

Date

12/16/2009

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

Init1pm1

Originator/Customer's Name:

Bob Freimuth: forum posting

Originator/Customer's Company:

Mayo Clinic, ICR Interoperability Working Group

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 decription).
  • Software and Application designers and architects
  • Broader Stakeholders (caBIG Community)

Summary of requirement pre-interview, by Reviewer:

The ICR Interoperability working group has summarized a set of tooling/development requirements that they believe will help developers meet their interoperability development goals.  This set of requirements can (and should) be represented by a variety of use cases.  It is also likely that these requirements significantly overlap many of the other requirements that are being gathered by other stakeholders.
The following is a bulleted list summary of their requirements.  Please refer back to the original post by Bob for a full list when modeling.

  • Metadata integration
    • There should be a single place (API and web interface) to be able to browse and cross-link between metadata items that are associated with information models, including UML, CDEs, Concepts, and XML Schema* There should be traceability between the various metadata items such that you can easily navigate between them in the API and metadata web interfaces, including the versions of the metadata items* The modeling tool must be integrated with the metadata repository in such a way that you can easily incorporate metadata into your model.
    • The modeling tool should by integrated with the SIW such that models can be validated and loaded into the metadata repository seamlessly
    • Metadata and the services that support them should be linked seamlessly.  Users should be able to know what systems are exposing what models through the metadata repository web interface (and possibly APIs).
    • Metadata repository will provide linkages between systems that support the same or similar CDEs, aka "touchpoints" between systems.
    • A system should be able to find semantically similar CDEs that might be useful for joining in a scientific way (use case: Find all malignant breast cancer tumors, return all tissues that have site "breast" or auxiliary site is a subtype of "breast")
  • Tooling enhancements
    • The modeling tool or metadata respository web interface should be able to automatically generate all of the metadata-oriented artifacts required for a silver compatibility review
    • The compatibility review system should be dynamically linked with the metadata repository such that a minimal number of artifacts need be produced to perform a review
    • Modelers should be able to create metadata (CDEs/concepts) in a sandbox environment on-demand as needed.  This should be integrated seamlessly within the modeling tool.** Metadata and modeling tool integration should provide real-time suggestion functionality (such as type-ahead) when linking UML components with semantic metadata.
    • Workflow authoring tools should be able to use linkage/"touchpoint" functionality to automatically "hook" services together in the workflow (use case: When dragging services onto the authoring tool dashboard, these services should be automatically "piped" together where applicable (i.e. when output from 1 service maps to the input of another service). Leveraging metadata capable of mapping outputs to inputs will facilitate this.)
    • The same hooking within workflow authoring tools should also suggest "shim" services (i.e. translation services) (use case: In cases where services cannot be directly piped together, the tool should help identify shim services that can be used. This will require possible extension of metadata around shim services.)
    • Where "shim" services do not exist, tooling should automatically generate the service interfaces necessary to perform the translation in order to facilitate development
  • New types of metadata
    • An identification scheme is needed to facilitate traceability of clinical data to biospecimen data (use case: Scientist would like to gather the clinical data and associate biospecimen from a particular participant/patient. Scientist would also like to identify any associated microarry experiments performed on the biospecimen and check for availability of additional biospecimens for further analysis)
    • Identify a service as a translation service between data types
    • Semantic descriptions of workflows will be needed in order to "share" workflows

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

  1. Use Case Model - understand gaps in use cases and requirements more fully
  2. Followup interview - fill gaps
  3. Repeat

Interview

Item

Script / Question

Information/Response

1

Hello, my name is NAME. I am calling you today because NCI and caBIG are working toward a new and improved version of the semantic infrastructure to better support integration scenarios.
Our first step was to organize requirements collected over the past year. Your organization has expressed a requirement/need for BRIEF STATEMENT OF USER REQUIREMENT.  This has been identified as potentially a critical component to support application/data and service integration, and we need more information in order to enable us to meet this requirement.
Do you have about 30 minutes to talk about this?

If yes, proceed. If no, note a good time to call back.
                                                                                                                    

2

Do you have any solution integration needs? If so, what are they? Have you envisioned new ways of interacting with existing or new parts of the semantic  infrastructure?
(prompt to elicit changes/new ways of using the infrastructure)

Notes describing potential interactions

3

Are there any business changes you are assuming we will be able to deal with? 
(prompt to elicit changes/new ways of using the infrastructure) 

Notes on anticipated business changes

4

Are there any capabilities you are expecting to be available to support your needs? 
(prompt to elicit expectations/dependencies)

Notes that identify capabilities, tools, and/or services expected

5

Do you use any of the existing software/services? If so, what do you like or dislike about it?
(if related to existing capability)

Yes OR No/ Notes that fully describe the requirement

6

If this requirement in met, what would be the benefits? If you do not have it, what would be the negative impact?
(prompt to elicit benefits/value - will help to prioritize)

Summary of perceived benefit or negative impact

7

If, for any reason, we were not able to create that solution, do you think there might be another way to solve this issue? Can you think of an alternative solution?
(prompt to elicit alternative solutions/workarounds)
(to be prepared by the Requirement Analyst)

Description of any other solution that customer can envision

8

Would you agree that we can summarize your requirement like this?
(Summarize one requirement in 2-3 lines and read back to interviewee for confirmation.)

Requirement statement accepted by interviewee

9

How important is this requirement to the interviewee? Required: Customer Priority/Annotationrement Analyst
(Provides concrete assessment of the relative importance for the requirements specification)

Select:

  1. Must have
  2. Should have
  3. Nice to have but not essential
  4. Other (describe)

10

On a scale from 1 to 3 with 1 being "not satisfied" to 3 "completely satisfied", how would you rate your overall satisfaction with the product if this requirement was met?  (Relative rating/ranking of how satisfied or dissatisfied interviewee would be if this requirement were met/not met)

Select:

  1. Not satisfied
  2. Mostly satisfied
  3. Completely satisfied 
  4. Other (describe)

11

Are there other requirements that you would like to share with us? I'd be more than happy to call you back another time, or if you have another 10 minutes, please share other issues you can think of.
(prompt to elicit any hidden - potentially higher priority requirements if they exist)

(If yes, take notes to use in on a new page with this template; if time not available now, try to make appointment for another call.)

12

Who else should we talk to in order to elicit more information about this need?

Name of contact(s)

 

For specific service enhancement or requirement from Forum entry:


13

Can you or someone else give me a step-by-step description of how you would describe the expected performance/behavior of the software in order for you to feel that your requirement is met? 
(Required: Fit Criterion - will help us create test cases and user acceptance criteria - to be prepared by the Requirement Analyst)

Well defined measurable verifiable expectation

14

Forum Link:

VKC or other forum where this requirement is discussed

15

URLs (optional):

Links to pages or applications related to this requirement

16

References (optional):

Links to articles, papers or presentations related to this requirement

Post Interview - ongoing throughout development of use cases:

Item

Description

Information/Response

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

 

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

  • No labels