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