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/17/2009 |
Requirement # unique id <SemCon Ops Initiative>.<analysts initials><requirement number> |
Init1pm11 |
Originator/Customer's Name: |
|
Originator/Customer's Company: |
NCI |
Stakeholder Community:
|
Software and Application designers and architects |
Summary of requirement pre-interview, by Reviewer: |
Domain analysis models play a central role in providing a common framework for implementation models. Within the life sciences domain a first pass domain analysis model called the LSDAM is being produced. Ultimately this model will need to be revised and refined so that it can play a role in the life sciences domain analogous to the role played by the BRIDG model in the clinical trial space. The architectural and semantics expectations regarding future development of this model will play a role in driving refinement, however the functional and structural requirements of the life sciences domain must drive the evolution of the model and the tactics that are defined for its use. DAMs are authored by Information Modelers, overseen by Metadata Curators, and reused by Information Modelers and Software Engineers. |
The issues with the current infrastructure and business practices are that the required domain models typically only hold the classes, attributes, associations, some models contain enumerations, but not all. And no other constraints on submitting formalized behaviors.
In order to localize, or constrain a DAM, such as BRIDG, a developer needs to understand the rules that apply to the model, and what is allowed to be changed. Can the value domain be changed? can a different code list be used? etc. One example was around activity classes in BRIDG when trying to develop COPPA. "They were very complicated and we didn't know (without talking to the developer or seeing the data) if they were complete or not complete (e.g., specific enough or too general or wrong or ambiguous, semantically)" WE need to understand more about this requirement in order to develop a use case.
|
Recommended Next Step Enter one: Follow-up interview, Observe, Use Case Template (text), Use Case Model (formalized/UML diagram), Group Discussion, Prototype, Waiting Room |
Followup Interview |
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):
|
|
ConOp Initiative(s) |
|
|
Use Case Linkage (required) |
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. |
Init1pm11.u - LS DAM refinement and utilization https://wiki.nci.nih.gov/x/rgtyAQ |
Conflicts / Dependencies(required) |
Are there any conflicts with other requirements / use cases? |
Yes OR No - If yes, what and why? |
Next Step (required) |
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 |