The following is a list of documents that provide background material, requirements, and related topics:
Term |
Definition |
---|---|
MUST |
This word means that the definition is an absolute requirement of the specification. |
MUST NOT |
This phrase means that the definition is an absolute prohibition of the specification. |
WILL |
This word means that the definition is an absolute future requirement of the specification. |
WILL NOT |
This phrase mean that the definition is an absolute future prohibition of the specification. |
SHOULD |
This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. |
SHOULD NOT |
This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. |
MAY |
This word means that a requirement is truly optional. The developer may choose to include the item based on the needs of their design. |
When designing use cases, it is important to maintain a consistent approach to determining at which level use cases are placed when they are authored. The granularity of the use case directly relates to its implementability, so maintaining a leveling scheme will insure that use cases are implemented, tested, etc. at a consistent level. In alignment with this, we will maintain the following use case leveling criteria:
The user interface shall be designed for ease-of-use by the designated end-users, shall use terms common to the user's normal business environment, and shall require little to no additional training on the system. Drop down menus, Google-like searches, and tooltips should be used wherever appropriate.
The user interface should be accessible via a web browser.
Following is a list of basic assumptions:
TBD
Some basic description of model services.
ID |
Requirement |
Source |
Release |
---|---|---|---|
MOS-1 |
The Model Service MUST support the abilities to record new model elements. |
--- |
|
MOS-2 |
The Model Service MUST support the abilities to record new assertions. |
--- |
|
MOS-3 |
The Model Service MUST support the abilities to record new rules. |
--- |
|
MOS-4 |
The Model Service SHOULD support the abilities to record queries. |
--- |
|
MOS-10 |
The Model Service MUST allow for the discovery of models based on querying model parts. |
--- |
|
MOS-11 |
The Model Service MAY support the federated discovery of models. |
--- |
|
MOS-12 |
The Model Service SHOULD allow the discovery of related model parts. |
--- |
|
MOS-20 |
The Model Service MUST support the comparison of model parts. |
--- |
|
MOS-21 |
The Model Service MUST support the harmonization of models through the comparison of model parts. |
--- |
|
MOS-30 |
The Model Service SHOULD support the merging of different parts of different models. |
--- |
|
MOS-40 |
The Model Service MAY support the graphical visualization of models. |
--- |
|
MOS-50 |
The Model Service MUST support the versioning of models. |
--- |
|
MOS-60 |
The Model Service MUST allow the retiring of models. |
--- |
|
MOS-70 |
The Model Service MUST allow the of updating of parts of a model. |
--- |
|
MOS-80 |
The Model Service MUST allow the deletion/unregistering of models. |
--- |
|
MOS-90 |
The Model Service SHOULD support the transformation of models. |
--- |
|
MOS-100 |
The Model Service SHOULD support the validation of models. |
--- |
|
MOS-110 |
The Model Service MUST support the reuse of model parts. |
--- |
|
MOS-111 |
The Model Service MUST support the entire reuse of direct copies of model parts. |
--- |
|
MOS-120 |
The Model Service MUST support the extension of model parts. |
--- |
|
MOS-121 |
The Model Service MUST allow the extension of classes. |
--- |
|
MOS-122 |
The Model Service MUST allow the extensions of model part relationships. |
--- |
|
MOS-123 |
The Model Service SHOULD allow the extension of attribute value lists. |
--- |
|
MOS-130 |
The Model Service SHOULD support the constraining of model parts. |
--- |
|
MOS-131 |
The Model Service SHOULD allow for classes to be subsetted. |
--- |
|
MOS-132 |
The Model Service SHOULD allow for attribute value lists to be subsetted. |
--- |
|
MOS-140 |
The Model Service MUST support the discovery of services related by model similarities. |
--- |
|
MOS-150 |
The Model Service SHOULD support the discovery of related documentation. |
--- |
Some basic description of metadata services.
ID |
Requirement |
Source |
Release |
---|---|---|---|
MDS-1 |
The Metadata Service MUST support the notion of data elements. |
--- |
|
MDS-2 |
The Metadata Service MUST allow the recording of data elements. |
--- |
|
MDS-3 |
The Metadata Service MUST allow new data element assertions to be made. |
--- |
|
MDS-4 |
The Metadata Service MUST allow for data elements to be updated. |
--- |
|
MDS-5 |
The Metadata Service MUST allow for data elements to be versioned. |
--- |
|
MDS-6 |
The Metadata Service SHOULD allow for data element business rules to be validated. |
--- |
|
MDS-7 |
The Metadata Service MUST allow for data elements to be retired. |
--- |
|
MDS-8 |
The Metadata Service MUST allow for data elements to be deleted/rolled back. |
--- |
|
MDS-9 |
The Metadata Service MUST support the discovery of reusable data element content. |
--- |
|
MDS-10 |
The Metadata Service SHOULD support the notion of data element usage information. |
--- |
|
MDS-11 |
The Metadata Service MUST support metadata to be queried by data element. |
--- |
|
MDS-12 |
The Metadata Service SHOULD support metadata to be queried by data element in a federated manner. |
--- |
|
MDS-13 |
The Metadata Service MUST support the comparison of data elements |
--- |
|
MDS-14 |
The Metadata Service SHOULD support the creation of a new data element from an existing data element. |
--- |
|
MDS-15 |
The Metadata Service MUST support the discovery of related models by data element. |
--- |
|
MDS-16 |
The Metadata Service SHOULD support the discover related metadata items by data element. |
--- |
|
MDS-17 |
The Metadata Service SHOULD support the discovery of related services by data element. |
--- |
|
MDS-18 |
The Metadata Service SHOULD support the discovery of related data element rules. |
--- |
|
MDS-19 |
The Metadata Service SHOULD support the discovery of forms related by data element. |
--- |
|
MDS-101 |
The Metadata Service MUST support the notion of value domains. |
--- |
|
MDS-102 |
The Metadata Service MUST allow the recording of value domains. |
--- |
|
MDS-103 |
The Metadata Service MUST allow new value domain assertions to be made. |
--- |
|
MDS-104 |
The Metadata Service MUST allow for value domains to be updated. |
--- |
|
MDS-105 |
The Metadata Service MUST allow for value domains to be versioned. |
--- |
|
MDS-106 |
The Metadata Service SHOULD allow for value domain business rules to be validated. |
--- |
|
MDS-107 |
The Metadata Service MUST allow for value domains to be retired. |
--- |
|
MDS-108 |
The Metadata Service MUST allow for value domains to be deleted/rolled back. |
--- |
|
MDS-109 |
The Metadata Service MUST support the discovery of reusable value domain content. |
--- |
|
MDS-110 |
The Metadata Service SHOULD support the notion of value domain usage information. |
--- |
|
MDS-111 |
The Metadata Service MUST support metadata to be queried by value domain. |
--- |
|
MDS-112 |
The Metadata Service SHOULD support metadata to be queried by value domain in a federated manner. |
--- |
|
MDS-113 |
The Metadata Service MUST support the comparison of value domains |
--- |
|
MDS-114 |
The Metadata Service SHOULD support the creation of a new value domain from an existing data element. |
--- |
|
MDS-115 |
The Metadata Service MUST support the discovery of related models by value domain. |
--- |
|
MDS-116 |
The Metadata Service SHOULD support the discover related metadata items by value domain. |
--- |
|
MDS-117 |
The Metadata Service SHOULD support the discovery of related services by value domain. |
--- |
|
MDS-118 |
The Metadata Service SHOULD support the discovery of related value domain rules. |
--- |
|
MDS-119 |
The Metadata Service SHOULD support the discovery of forms related by value domain. |
--- |
|
MDS-120 |
The Metadata Service SHOULD support the ability to create a value domain through subsetting/constraining. |
--- |
--- |
MDS-121 |
The Metadata Service SHOULD allow value domains to be extended through the creation of new from existing. |
--- |
--- |
MDS-130 |
The Metadata Service SHOULD support semantic transformations that would be explicitly based on value domain mapping, e.g. to the same value meaning. |
--- |
|
MDS-131 |
The Metadata Service MAY support syntactic transformations that would transform source value domain representation to target value domain representation. |
--- |
|
MDS-201 |
The Metadata Service MUST support the notion of data element concepts. |
--- |
|
MDS-202 |
The Metadata Service MUST allow the recording of data element concepts. |
--- |
|
MDS-203 |
The Metadata Service MUST allow new data element concept assertions to be made. |
--- |
|
MDS-204 |
The Metadata Service MUST allow for data element concepts to be updated. |
--- |
|
MDS-205 |
The Metadata Service MUST allow for data element concepts to be versioned. |
--- |
|
MDS-206 |
The Metadata Service SHOULD allow for data element concept business rules to be validated. |
--- |
|
MDS-207 |
The Metadata Service MUST allow for data element concepts to be retired. |
--- |
|
MDS-208 |
The Metadata Service MUST allow for data element concepts to be deleted/rolled back. |
--- |
|
MDS-209 |
The Metadata Service MUST support the discovery of reusable data element concept content. |
--- |
|
MDS-210 |
The Metadata Service SHOULD support the notion of data element concept usage information. |
--- |
|
MDS-211 |
The Metadata Service MUST support metadata to be queried by data element concept. |
--- |
|
MDS-212 |
The Metadata Service SHOULD support metadata to be queried by data element concept in a federated manner. |
--- |
|
MDS-213 |
The Metadata Service MUST support the comparison of data element concepts |
--- |
|
MDS-214 |
The Metadata Service SHOULD support the creation of a new data element concept from an existing data element concept. |
--- |
|
MDS-215 |
The Metadata Service MUST support the discovery of related models by data element concept. |
--- |
|
MDS-216 |
The Metadata Service SHOULD support the discover related metadata items by data element concept. |
--- |
|
MDS-217 |
The Metadata Service SHOULD support the discovery of related services by data element concept. |
--- |
|
MDS-218 |
The Metadata Service SHOULD support the discovery of related data element concept rules. |
--- |
|
MDS-219 |
The Metadata Service SHOULD support the discovery of forms related by data element concept. |
--- |
|
MDS-220 |
The Metadata Service MUST support the discovery of related data elements by data element concept. |
--- |
|
MDS-221 |
The Metadata Service SHOULD support the discovery of related value sets by data element concept. |
--- |
|
MDS-230 |
The Metadata Service SHOULD support the creation of a data element from an existing data element concept and value domain. |
--- |
|
MDS-231 |
The Metadata Service SHOULD support the creation of a new data element concept from an existing data element concept. |
--- |
ID |
Requirement |
Source |
Release |
---|---|---|---|
RRS-1 |
The Registry-Registry service MUST support the import of content from one registry to another. |
--- |
|
RRS-10 |
The Registry-Registry service MUST support the export of content in a convenient data format. |
--- |
|
RRS-20 |
The Registry-Registry service SHOULD support the update of edited content from one registry to another. |
--- |
|
RRS-30 |
The Registry-Registry service MAY support the search of one registry from another. |
--- |
|
RRS-40 |
The Registry-Registry service MUST support content to be submitted from one registry to another. |
--- |
|
RRS-50 |
The Registry-Registry service MUST support the registration of content from one registry to another. |
--- |
|
RRS-60 |
The Registry-Registry service MUST support the updating of the registration of content from one registry to another. |
--- |
ID |
Requirement |
Source |
Release |
---|---|---|---|
GEN-1 |
Services SHOULD support the notion of annotating any data with well defined concepts. |
--- |
|
GEN-10 |
Services SHOULD allow users to subscribe for notifications of changes to data. |
--- |
|
GEN-20 |
Services MUST support the notion of data reuse. |
--- |
ID |
Requirement |
Source |
Release |
---|---|---|---|
MRT-1 |
A Metadata Registry Tool MUST support a clinician friendly browser. |
--- |
|
MRT-10 |
A Metadata Registry Tool MUST support an information specialist browser. |
--- |
|
MRT-20 |
A Metadata Registry Tool SHOULD support a customizable browser. |
--- |
|
MRT-30 |
A Metadata Registry Tool MAY support a generalized portal that integrates various metadata registry tools. |
--- |
|
MRT-40 |
A Metadata Registry Tool SHOULD allow workflow management to support ECCF artifact creation. |
--- |
|
MRT-50 |
A Metadata Registry Tool MUST support an interface of browser/editing models and metadata with modeling tools. |
--- |
Performance refers to the qualitative or quantitative measure of how well a system reacts in a user workflow. This can be measured in time from a user or system perspective, as well as the amount of resources (CPU, memory, etc.) that software must consume to complete a task.
ID |
Requirement |
---|---|
PE-1 |
Where not otherwise specified, web pages should be completely returned within seconds of request. |
Auditing, logging, and provenance is the process of recording events in an automated and/or manual way within a certain scope in order to provide an audit trail that can be used to understand the activity of the system and/or to diagnose problems.
ID |
Requirement |
---|---|
ALP-1 |
The application will address Title 21 Code of Federal Regulations (21 CFR Part 11) Electronic Records where appropriate and reasonable. |
ALP-10 |
The system must audit each and every user action that results in database access (read or write). Examples include: add/edit study or participant data, user login, query etc.
|
ALP-20 |
Auditing information must be accessible in a timely manner to system administrators. |
ALP-30 |
Auditing features must at least be available through standard database logging/auditing. |
ALP-40 |
Logging must be implemented in all the architectural layers - presentation, business logic and data access layers |
Fault handling is a mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of software or user execution.
ID |
Requirement |
---|---|
FH-1 |
Any runtime exceptions or errors must be reported to the user in a graphical window containing the probable cause of the problem and how to rectify that. |
FH-10 |
The exceptions and errors shall be divided into two groups:
|
Quality of service is the ability to provide sufficient uptime and availability of software to guarantee a certain level of performance to access and data flow.
ID |
Requirement |
---|---|
QS-1 |
The system must be adequately validated during the system development lifecycle. |
QS-10 |
The system must provide the functionality to generate and manage accurate data records during the development processes. |
QS-20 |
The system development lifecycle must include validity checks for all data fields. |
In design, Usability is the study of the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal.
ID |
Requirement |
---|---|
US-1 |
An intuitive user friendly graphical user interface must be developed. |
PE-10 |
Web page requests must resolve in a timely manner. Where not otherwise specified, this is on the order of seconds. |
PE-20 |
The application will address section 508 of the Rehabilitation Act of 1973 where appropriate and reasonable. |
Security is the protecting of information and information systems from unauthorized access, use, disclosure, disruption, modification or destruction.
ID |
Requirement |
---|---|
SE-1 |
The system must limit access to authorized individuals. |
SE-10 |
Electronic Signatures should meet necessary requirements as described in 21 CFR part 11. |
SE-20 |
The application will address section 508 of the Rehabilitation Act of 1973 where appropriate and reasonable. |
SE-30 |
System developers must adhere to the caBIG Data Sharing & Intellectual Capital Policy and Procedures |
Portability is the software codebase feature to be able to reuse the existing code instead of creating new code when moving software from an environment to another. The prerequirement for portability is the generalized abstraction between the application logic and system interfaces.
ID |
Requirement |
---|---|
PO-1 |
Operating system native libraries should not be used. |
PO-10 |
All the paths for the local file system must not be hard coded. Example C:\myDir etc. |