IQM System requirements

Non-functional

IQM shall be implemented as a webservice (https) 
Rules shall be accessed by endpoints (API) in webservice
IQM shall support swagger api format
IQM shall be distributed as a docker container image by Azure Container Registry
IQM shall be deployed to customers cloud platform
IQM shall implement logic rules to validate data from AM-Cockpit
IQM shall be stateless
IQM rule logic shall be implemented by DNV
IQM rule logic shall be transparent
IQM rule logic shall be immutable (traceable)
IQM shall connect to Veracity
IQM shall collect results
IQM shall show results in “statements of facts” in Veracity
Security shall be implemented according to existing guidelines and best practices
Guidelines/instructions for deployment shall be provided
Availability, support, monitoring, bug-fix, dev-ops, testing, latency, agile development (short iterations)

Functional

Requirements for each compliance rule: If conditions then result, eg If actual powder humidity is above allowed threshold then rule shall return FAIL otherwise OK
Rule requirements will be defined with customers domain experts
Compliance rules shall be triggered by POST methods
API’s shall provide format specification for parameters, request and response (see below examples)
IQM shall implement a data model representing parameters, request and response
Result (parameters, request and response) shall be submitted to Veracity
IQM shall implement Veracity IoT API to submit results
IQM shall store results in Veracity
IQM shall calculate quality score/index
Historic and current result shall be available in a Veracity dashboard
Dashboard/Certificate requirements will be defined with customers domain experts
Customer shall have access to the dashboard
Health method shall be implemented to verify service availability