NIH | National Cancer Institute | NCI Wiki  

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Scrollbar
iconsfalse

Page info
title
title

Instructions

...

Initial Analysis:

Item

Information/Response

Date

02/02/2010

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

Init1dbw11

Originator/Customer's Name:

Dianne Reeves                                                                                      

Originator/Customer's Company:

CBIIT Manual based metadata content developers

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)

When a Metadata Curator or Information Modeler creates data element annotations using our current tools, we string together concepts to create the semantic description, making the meaning of the data unambiguous. If the class or attribute being described includes an adjective, or qualifier, there is sometimes debate over how many of those qualifiers belong in the single, coordinated concept vs. stringing together the terms out of atomic concepts to form the semantic description.
Example: If you are creating a data element for 'second laparotomy procedure findings', I would string together concepts of second + laparotomy + surgical procedure + results (or findings).  This is the postcoordinated method.
By contrast, the precoordinated method would state that 'second laparatomy procedure' is all one concept, and requires a new NCI thesaurus concept.
The problem would be that some people will use the postcoordinated method, and others the precoordinated - but does it make a difference when looking up content on the grid, or exchanging content?  Additionally, we find that submitters with lesser expertise in a domain area area faster to request precoordinated terms than SMEs or experienced curators who may be more comfortable finding terms that can be strung together.
There needs to be a way to support both approaches without sacrificing the ability to find, reuse, and share content

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 Model

Post Interview - ongoing throughout development of use cases:

...

Item

...

Description

...

Information/Response

...

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).


Scrollbar
iconsfalse

...

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

...

...

 

...

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.

...