Skip to content

Latest commit

 

History

History
29 lines (17 loc) · 1.8 KB

README.md

File metadata and controls

29 lines (17 loc) · 1.8 KB

DINA Information Packages, Functional Component Descriptions and Module Descriptions

Approach for breaking down the DINA work and architecture from content-driven high-level concepts (Information Packages) to lower-level functionality-oriented components.

Three levels of the DINA modelling process

  • Information Packages make up the information model. Information Packages should be logically standalone, thus independent from other Information Packages.

    • It addresses the question Which information lives where?
    • The Information Packages are not expected to change too much over time.
  • For each Information Package one to many Functional Components are described. Although a component description should already focus on functionality, the technical implementaion should play only a minor role. Rather the component description should be high-level and focussed on the accomplishment of use cases and workflows.

    • It addresses the question Which functionality needs to be considered per component?
  • From the functional component descriptions module descriptions can be derived.

    • It should be possible to develop a data model from the module descriptions.
    • The module descriptions should be versioned (different MVPs) and are expected to be modified for each MVP.
    • Each module description links to a dedicated specification repository in which the backlog for the implementation will be documented (e.g. API endpoints, software stack, data schema etc.)
    • It addresses the question How to implement the desired informationa and functionality?

The above-mentioned three levels should not be mixed.


Existing Information Packages