The following are recommended non-functional requirements for OpenHIE reference software.  

  1. Well Documented: An OpenHIE reference system should include appropriate background, design,  installation, configuration, and operational documentation to ensure it is easy to understand, maintain, and debug.

    1. Source code should have comments so that developers do not need to look anywhere else to understand the code.

    2. Configuration files should have embedded comments explaining the different options.

    3. Installation, configuration, and operational activities should be described.

  2. Easy to implement for common use cases

  3. Built using open source tools and technology: The OpenHIE component should be built using widely available open-source technology (including development environments and languages).

  4. Open, easy access to source code: A standard version control system (e.g., GitHub) should be used to ensure that source code access is fast, easy to download, compile, and execute code.

  5. Standards-based: The software should use broadly adopted standards that enable interoperability among systems.

  6. Reliable and easy-to-use User Interface:  Common identity management workflows must be supported by the user interface, including initial system configuration, and routine workflows.

  7. Minimal software library dependencies: An OpenHIE component should minimize dependencies on 3rd-party libraries.

  8. Minimal abstraction: A OHIE component should not have more layers of abstraction than necessary, and seek to minimize abstraction that confounds design.

  9. Easy Initiation: When properly installed and configured, administrators should be able to initiate the OpenHIE and any associated supporting processes with a single step.

  10. Build on commonly used technology:  

    1. In order to make it easy to run/configure/debug, the software should be built on popular technologies that developers like to use.

    2. Any 3rd party libraries used by the software should be easy for a typical developer to use.

    3. Any external software/systems (like the database) should also be easy to use.

    4. It should be easy to view the contents of the database.

    5. If a traditional SQL database is used, then multiple databases should be supported (MySQL/PostgreSQL/Oracle).

  11. Unit Tests:  

    1. The source code should include unit tests that are based on the specific requirements of OpenHIE.

  1. License:  The component would ideally be distributed under an open-source license that minimizes complexity and enables an implementer community to leverage the software in a broad variety of sustainability contexts.

  1. The component should have a clear and standard license so that it is easy to understand what kinds of usage are allowed.

  1. Accessible Code:  

  1. The code should be hosted somewhere that developers like to use.

  1. GUI

    1. The  component should have an easy to use, well thought out and well implemented front end

       

  • No labels

This work is licensed under a Creative Commons Attribution 4.0 International License.