---
sidebar_position: 2
---

# Software Requirements Specification

**A single source of truth documenting the collection, interpretation, analysis and engineering of NPIS requirments**

# Table of Contents {#table-of-contents .TOC-Heading}

# Introduction

Software Requirements Specification (SRS) is a software engineering
standard for requirements documentation. It serves as an output
deliverable of the requirements engineering or gathering and analysis
phase of the system development life cycle. Professional practise
follows IEEE 830 or ISO/IEC/IEEE 29148 as a set of requirements
documentation standards that harmonizes and streamlines the
sometimes-confusing communication of requirements between developers and
stakeholders.

## Purpose

The purpose of this Software Requirements Specification (SRS) document,
is to present a detailed articulation and description of requirements
for the National Petroleum Information System[]. It communicates in detail, the purpose
and features of the system, the interfaces of the system, what the
system will do, the constraints under which it must operate and how the
system will react to external events. This document is intended for both
the stakeholders and the consultants/developers of the system and
constitutes the substance of an agreement between them.

## Scope, Approach and Methods

Technical description of requirements for the National Petroleum
Information System, adopted the ISO/IEC 12207/29148 as the IEEE software
engineering standards (IEEE, 2018).

This is to help the consultant achieve harmonization of the content
definition for software life cycle process results among the IEEE
software engineering standards and with related international standards.

Having adopted prototyping as a methodical approach, this SRS is a live
document; meaning, it is a preliminary output or prototyped work product
that is versioned based on the currently gathered and analyzed
requirements. So far, requirements gathering has entailed the thorough
review and analysis of the project terms of reference and legal and
regulatory framework governing petroleum supply operations for Uganda.
This included the following:

- Petroleum Supply Act, 2003, Act No. 13 of 2003

- Petroleum Supply General Regulations, 2009

- The National Environmental Act, Cap 153 of 1995

It is intended to spark the user feedback loop of prototyping through
further engagements with the client for a more acquainted familiarity
with petroleum supply operations workflows.

To establish a correlation between the content of software requirements
specifications as defined in 830 and IEEE 12207.1, the consultant used
the Unified Modelling Language (UML). As both a modelling language and
technique, UML is intended to provide a standard way to visualize the
National Petroleum Information System. Also, as an approved ISO
standard, UML will help the consultant produce results consistent with
the international standard for software life cycle processes, ISO/IEC
12207 (IEEE, 2018) and (IEEE, 1998) standards.

This document will use UML diagrams to represent two different views of
the system model:

**Static (or structural) view:** emphasizes the static structure of the
system using objects, attributes, operations and relationships. It will
include class diagrams and composite structure diagrams.

**Dynamic (or behavioural) view:** emphasizes the dynamic behaviour of
the system by showing collaborations among objects and changes to the
internal states of objects. This view will include use case diagrams,
sequence diagrams, activity diagrams and state machine diagrams.

This SRS will primarily employ both use case and activity diagrams to
depict the system and its environment with respect to actors and what
use cases the system satisfies and serve as a guide to the information
that is captured by further defining those use cases in a textual or
tabular format in the Specific Requirements section. Activity diagrams
and Sequence diagrams will be used to emphasize specific use cases for
details and workflow-tasks for the petroleum supply operations.
<!-- [Figure 1:Using Activity, Use Case and Sequence UML Diagrams] -->

<!-- ![UML Activity Diagram](/img/uml.png) -->


![UML Activity Diagram](data:image/png;base64,[encoded data, 78048 characters])



Use case diagram notation reference is presented in appendix Use Case
Diagram Notation Reference.

## Glossary

This section does include terminologies that would otherwise wouldn't
make much sense elsewhere before being properly introduced to the
readers.

## References

Besides the consultancy's terms of reference, reviewed sources from
which the presented preliminary requirements have been extracted include
the petroleum supply operations legal and regulatory framework:

Most importantly, this document complies to the ISO/IEC/IEEE 29148
(IEEE, 2018) standard. In particular, the ISO/IEC/IEEE 29148:2011
provides additional guidance in the application of requirements
engineering and management processes for requirements-related activities
in ISO/IEC 12207 and ISO/IEC 15288.

## Document Overview

The next chapter, the Overall Description section, of this document
gives an overview of the functionality of the National Petroleum
Information System. It describes the initial preliminary requirements
and is used to establish a context for the technical requirements
specification in the next chapter.

The third chapter, Requirements Specification section, is written
primarily for technical audiences and describes in technical terms the
details of the system functionality.

Both sections of the document describe the same software product in its
entirety, but are intended for different audiences and thus use
different language.

This is not authored in isolation, but rather it does cross refence
other project work products like the preliminary database design
document and the preliminary user interface document from which sections
are referred to here as needed. This allowed us to have a formal
IEEE-compliant.

# General Description

The National Petroleum Information System (NPIS) is a web application
purposely engineered to automate workflows executed during petroleum
supply operations and business processes by officers of the Petroleum
Supply Department (PSD) and petroleum developers.

The NPIS is therefore to help facilitate the capturing, storage,
retrieval, processing, visualization and reporting of information from
all petroleum supply operations workflows including; permits and
licensing, storage and transporting, pricing, environmental impact
assessment, enforcement and monitoring, labs and quality assurance, LGP
and standards processes.

NPIS is to provide downstream petroleum information and profile accounts
management for petroleum developers as client applicants and holders of
permits and licenses for petroleum supply operations.

## System Users and Characteristics

This section discusses NPIS users, their roles and their granted
permission groups as par the project terms of reference and gathered
user and system requirements.

The extracted users below have been generalized with no regard to which
petroleum supply operations they are designated to, that is to say; all
principle petroleum officers for example, have been given a nomenclature
under a singular group without differentiating whether they are under
licensing or transport.

<!-- +----+-------------------------+----------------------------------------+
|    | System User             | Characteristics                        |
+====+=========================+========================================+
| 1  | Commissioner            | A user to emulate all system roles and |
|    |                         | granted permissions mandated to the    |
|    |                         | head of the PSD by the Petroleum       |
|    |                         | Supply Act and other enactments.       |
|    |                         |                                        |
|    |                         | This involves emulating the following  |
|    |                         | workflows:                             |
|    |                         |                                        |
|    |                         | - The administering of an effective    |
|    |                         |   and equitable licensing system for   |
|    |                         |   petroleum supply operations and      |
|    |                         |   installation under subsection (2)    |
|    |                         |   (b), section 7 of the petroleum      |
|    |                         |   supply act                           |
|    |                         |                                        |
|    |                         | - The evaluation and processing of all |
|    |                         |   applications for and approve the     |
|    |                         |   granting, renewal, assignment,       |
|    |                         |   suspension or revocation of all      |
|    |                         |   permits and licences under           |
|    |                         |   subsection (2) (c), section 7 of the |
|    |                         |   petroleum supply act.                |
|    |                         |                                        |
|    |                         | - The ensured establishment,           |
|    |                         |   maintenance and periodic updates of  |
|    |                         |   the NPIS and the evaluation and      |
|    |                         |   dissemination of information derived |
|    |                         |   from the NPIS under subsection (2)   |
|    |                         |   (d), section 7 of the petroleum      |
|    |                         |   supply act.                          |
|    |                         |                                        |
|    |                         | - Prepare a classification of          |
|    |                         |   petroleum operations and projects    |
|    |                         |   and in consultation with NEMA,       |
|    |                         |   prepare guidelines for environmental |
|    |                         |   impact assessments and audits issued |
|    |                         |   under subsection (2) of section 33   |
|    |                         |   of the Petroleum Supply Act.         |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 2  | Assistant Commissioner  | A user authorised by the commissioner  |
|    |                         | user to deputise the commissioner or   |
|    |                         | all system roles and permissions       |
|    |                         | mandated to the assistant head of the  |
|    |                         | PSD by the Petroleum Supply Act and    |
|    |                         | other enactments.                      |
|    |                         |                                        |
|    |                         | This involves emulating the following  |
|    |                         | workflows:                             |
|    |                         |                                        |
|    |                         | - The administering of an effective    |
|    |                         |   and equitable licensing system for   |
|    |                         |   petroleum supply operations and      |
|    |                         |   installation under subsection (2)    |
|    |                         |   (b), section 7 of the petroleum      |
|    |                         |   supply act                           |
|    |                         |                                        |
|    |                         | - The evaluation and processing of all |
|    |                         |   applications for and approve the     |
|    |                         |   granting, renewal, assignment,       |
|    |                         |   suspension or revocation of all      |
|    |                         |   permits and licences under           |
|    |                         |   subsection (2) ©, section 7 of the   |
|    |                         |   petroleum supply act.                |
|    |                         |                                        |
|    |                         | - The ensured establishment,           |
|    |                         |   maintenance and periodic updates of  |
|    |                         |   the NPIS and the evaluation and      |
|    |                         |   dissemination of information derived |
|    |                         |   from the NPIS under subsection (2)   |
|    |                         |   (d), section 7 of the petroleum      |
|    |                         |   supply act.                          |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 3  | Principal Petroleum     | A system user emulating the roles and  |
|    | Officer                 | permissions of an officer of the PSD   |
|    |                         | for conducting:                        |
|    |                         |                                        |
|    |                         | - Reviews and Analyses (licensing &    |
|    |                         |   permits applications),               |
|    |                         |                                        |
|    |                         | - Evaluation (approves, rejects),      |
|    |                         |                                        |
|    |                         | - Interpretation of acquired data from |
|    |                         |   instrumentation and measurement      |
|    |                         |   technologies for different           |
|    |                         |   downstream petroleum facilities like |
|    |                         |   storage tanks, dispensing pumps,     |
|    |                         |   pipelines, transportation trucks and |
|    |                         |   containers during preliminary        |
|    |                         |   workflows in the licencing process.  |
|    |                         |                                        |
|    |                         | - Participating in inspecting          |
|    |                         |   monitoring measurements equipment at |
|    |                         |   installed downstream facilities to   |
|    |                         |   ensure they are well calibrated.     |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 4  | Senior Petroleum        | A system user who emulates roles and   |
|    | Officer                 | permissions of Senior Petroleum        |
|    |                         | Officer in the PSD.                    |
|    |                         |                                        |
|    |                         | The roles emulated are:                |
|    |                         |                                        |
|    |                         | participates in supervising and        |
|    |                         | appraising petroleum officers in       |
|    |                         | licencing of downstream petroleum      |
|    |                         | facilities to ensure aspects of        |
|    |                         | instrumentation and measurement are    |
|    |                         | addressed. Participates in preliminary |
|    |                         | activities leading to licensing        |
|    |                         | processes.                             |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 5  | Petroleum Officer       | A system user who emulates roles and   |
|    |                         | permissions of an individual who       |
|    |                         | conducts systematic examination and    |
|    |                         | reviews to determine whether or not a  |
|    |                         | facility installation or petroleum     |
|    |                         | supply operations of a licence         |
|    |                         | applicant meet requirements issued     |
|    |                         | under subsection (2) of section 17 of  |
|    |                         | the Petroleum Supply Act.              |
|    |                         |                                        |
|    |                         | Petroleum Officer reviews, audits      |
|    |                         | licencing of downstream petroleum      |
|    |                         | facilities standards.                  |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 10 | Environment Officer     | A system user who emulates roles and   |
|    |                         | permissions of an individual either    |
|    |                         | internally or external to the PSD      |
|    |                         | tasked to carry out environmental      |
|    |                         | impact assessment which involves the   |
|    |                         | systematic examination conducted in    |
|    |                         | accordance with the National           |
|    |                         | Environment Statute, 1995, to          |
|    |                         | determine whether or not a project     |
|    |                         | will have any adverse impact on the    |
|    |                         | environment; and includes              |
|    |                         | environmental reviews, environmental   |
|    |                         | evaluations and environmental impact   |
|    |                         | studies and all related procedures.    |
|    |                         |                                        |
|    |                         | Also, the commissioner as head of the  |
|    |                         | PSD by mandate as the lead agency      |
|    |                         | within the meaning of the National     |
|    |                         | Environment Statute, 199, can act as   |
|    |                         | the environmental officer or authorise |
|    |                         | any officer of the PSD in the process  |
|    |                         | of conducting environmental impact     |
|    |                         | assessments and audits and implement   |
|    |                         | other requirements for environmental   |
|    |                         | protection in the supply chain, in     |
|    |                         | accordance with the applicable laws    |
|    |                         | issued under subsection (1) of section |
|    |                         | 33 of the Petroleum Supply Act.        |
|    |                         |                                        |
|    |                         | And this grants the commissioner       |
|    |                         | system user, the composite role to     |
|    |                         | execute role and permissions           |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 11 | Laboratory Sample       | A system user who emulates roles and   |
|    | Receptionist            | permissions of an individual who as    |
|    |                         | part of the Request for Analysis       |
|    |                         | Workflow of petroleum samples or       |
|    |                         | products at the Downstream Petroleum   |
|    |                         | Testing Central Laboratory, executes   |
|    |                         | tasks involving the reception,         |
|    |                         | cataloguing, billing and logging of    |
|    |                         | petroleum samples.                     |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 12 | Laboratory Assistant    | A system user who emulates roles and   |
|    |                         | permissions of an individual who as    |
|    |                         | part of the Request for Analysis       |
|    |                         | Workflow of petroleum samples or       |
|    |                         | products at the Downstream Petroleum   |
|    |                         | Testing Central Laboratory, executes   |
|    |                         | tasks involving the receives, captures |
|    |                         | sample numbers, of petroleum samples.  |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 13 | Laboratory Analyst      | A system user who emulates roles and   |
|    |                         | permissions of an individual who as    |
|    |                         | part of the Request for Analysis       |
|    |                         | Workflow of petroleum samples or       |
|    |                         | products at the Downstream Petroleum   |
|    |                         | Testing Central Laboratory, executes   |
|    |                         | tasks involving the analysis, creation |
|    |                         | and storage of analysis data for       |
|    |                         | petroleum samples.                     |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 14 | Laboratory Reviewer     | A system user who emulates roles and   |
|    |                         | permissions of an individual who as    |
|    |                         | part of the Request for Analysis       |
|    |                         | Workflow of petroleum samples or       |
|    |                         | products at the Downstream Petroleum   |
|    |                         | Testing Central Laboratory, executes   |
|    |                         | tasks involving the analytical review  |
|    |                         | of all created analysis data for       |
|    |                         | petroleum samples.                     |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 15 | Laboratory Technical    | A system user who emulates roles and   |
|    | Officer                 | permissions of an individual who as    |
|    |                         | part of the Request for Analysis       |
|    |                         | Workflow of petroleum samples or       |
|    |                         | products at the Downstream Petroleum   |
|    |                         | Testing Central Laboratory, executes   |
|    |                         | tasks involving the overall review and |
|    |                         | scrutiny of all Request for Analysis   |
|    |                         | data.                                  |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 16 | Head Laboratory         | A system user who emulates roles and   |
|    |                         | permissions of an individual who as    |
|    |                         | part of the Request for Analysis       |
|    |                         | Workflow of petroleum samples or       |
|    |                         | products at the Downstream Petroleum   |
|    |                         | Testing Central Laboratory is tasked   |
|    |                         | to head all activities in the Request  |
|    |                         | for Analysis Workflow and mandated to  |
|    |                         | approve and offer the analysis         |
|    |                         | certificate.                           |
|    |                         |                                        |
|    |                         | Emulating the above roles requires a   |
|    |                         | technically qualified user, who is     |
|    |                         | expected to be computer and Internet   |
|    |                         | literate.                              |
+----+-------------------------+----------------------------------------+
| 17 | Developer/Client        | This system user emulates client       |
|    |                         | applicants and holders of permits and  |
|    |                         | licenses for petroleum supply          |
|    |                         | operations.                            |
+----+-------------------------+----------------------------------------+ -->

Table 1: User Characteristics

|  |  |  |
| --- | --- | --- |
| # | System User | Characteristics |
| 1 | Commissioner | A user to emulate all system roles and granted permissions mandated to the head of the PSD by the Petroleum Supply Act and other enactments.  This involves emulating the following workflows:   * The administering of an effective and equitable licensing system for petroleum supply operations and installation under subsection (2) (b), section 7 of the petroleum supply act * The evaluation and processing of all applications for and approve the granting, renewal, assignment, suspension or revocation of all permits and licences under subsection (2) (c), section 7 of the petroleum supply act. * The ensured establishment, maintenance and periodic updates of the NPIS and the evaluation and dissemination of information derived from the NPIS under subsection (2) (d), section 7 of the petroleum supply act. * Prepare a classification of petroleum operations and projects and in consultation with NEMA, prepare guidelines for environmental impact assessments and audits issued under subsection (2) of section 33 of the Petroleum Supply Act.   Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 2 | Assistant Commissioner | A user authorised by the commissioner user to deputise the commissioner or all system roles and permissions mandated to the assistant head of the PSD by the Petroleum Supply Act and other enactments.  This involves emulating the following workflows:   * The administering of an effective and equitable licensing system for petroleum supply operations and installation under subsection (2) (b), section 7 of the petroleum supply act * The evaluation and processing of all applications for and approve the granting, renewal, assignment, suspension or revocation of all permits and licences under subsection (2) �, section 7 of the petroleum supply act. * The ensured establishment, maintenance and periodic updates of the NPIS and the evaluation and dissemination of information derived from the NPIS under subsection (2) (d), section 7 of the petroleum supply act.   Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 3 | Principal Petroleum Officer | A system user emulating the roles and permissions of an officer of the PSD for conducting:   * Reviews and Analyses (licensing & permits applications), * Evaluation (approves, rejects), * Interpretation of acquired data from instrumentation and measurement technologies for different downstream petroleum facilities like storage tanks, dispensing pumps, pipelines, transportation trucks and containers during preliminary workflows in the licencing process. * Participating in inspecting monitoring measurements equipment at installed downstream facilities to ensure they are well calibrated.   Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 4 | Senior Petroleum Officer | A system user who emulates roles and permissions of Senior Petroleum Officer in the PSD.  The roles emulated are:  participates in supervising and appraising petroleum officers in licencing of downstream petroleum facilities to ensure aspects of instrumentation and measurement are addressed. Participates in preliminary activities leading to licensing processes.  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 5 | Petroleum Officer | A system user who emulates roles and permissions of an individual who conducts systematic examination and reviews to determine whether or not a facility installation or petroleum supply operations of a licence applicant meet requirements issued under subsection (2) of section 17 of the Petroleum Supply Act.  Petroleum Officer reviews, audits licencing of downstream petroleum facilities standards.  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 10 | Environment Officer | A system user who emulates roles and permissions of an individual either internally or external to the PSD tasked to carry out environmental impact assessment which involves the systematic examination conducted in accordance with the National Environment Statute, 1995, to determine whether or not a project will have any adverse impact on the environment; and includes environmental reviews, environmental evaluations and environmental impact studies and all related procedures.  Also, the commissioner as head of the PSD by mandate as the lead agency within the meaning of the National Environment Statute, 199, can act as the environmental officer or authorise any officer of the PSD in the process of conducting environmental impact assessments and audits and implement other requirements for environmental protection in the supply chain, in accordance with the applicable laws issued under subsection (1) of section 33 of the Petroleum Supply Act.  And this grants the commissioner system user, the composite role to execute role and permissions  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 11 | Laboratory Sample Receptionist | A system user who emulates roles and permissions of an individual who as part of the Request for Analysis Workflow of petroleum samples or products at the Downstream Petroleum Testing Central Laboratory, executes tasks involving the reception, cataloguing, billing and logging of petroleum samples.  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 12 | Laboratory Assistant | A system user who emulates roles and permissions of an individual who as part of the Request for Analysis Workflow of petroleum samples or products at the Downstream Petroleum Testing Central Laboratory, executes tasks involving the receives, captures sample numbers, of petroleum samples.  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 13 | Laboratory Analyst | A system user who emulates roles and permissions of an individual who as part of the Request for Analysis Workflow of petroleum samples or products at the Downstream Petroleum Testing Central Laboratory, executes tasks involving the analysis, creation and storage of analysis data for petroleum samples.  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 14 | Laboratory Reviewer | A system user who emulates roles and permissions of an individual who as part of the Request for Analysis Workflow of petroleum samples or products at the Downstream Petroleum Testing Central Laboratory, executes tasks involving the analytical review of all created analysis data for petroleum samples.  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 15 | Laboratory Technical Officer | A system user who emulates roles and permissions of an individual who as part of the Request for Analysis Workflow of petroleum samples or products at the Downstream Petroleum Testing Central Laboratory, executes tasks involving the overall review and scrutiny of all Request for Analysis data.  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 16 | Head Laboratory | A system user who emulates roles and permissions of an individual who as part of the Request for Analysis Workflow of petroleum samples or products at the Downstream Petroleum Testing Central Laboratory is tasked to head all activities in the Request for Analysis Workflow and mandated to approve and offer the analysis certificate.  Emulating the above roles requires a technically qualified user, who is expected to be computer and Internet literate. |
| 17 | Developer/Client | This system user emulates client applicants and holders of permits and licenses for petroleum supply operations. |


### User Roles

Analysis of gathered functional as well as legal and regulatory
requirements for NPIS to automate petroleum supply operations, does
necessitate that all executed workflow-tasks, follow the approval
pathway up the correct delegation of authority within the ranks of the
PSD workforce.

A feat that requires modelling NPIS users with roles based on grouped
permissions and privileges that are granted to emulate delegated
authorization of authenticated users on who has access to what in the
system. Such characterization of user access is also to help model the
logging of accountable execution of workflows.

Forthcoming sections do introduce use case models and activity diagrams
for these extracted system user groups.

<!-- +----+---------------------------+--------------------------------------------------+
| \# | User Role                 | Responsibilities                                 |
+====+===========================+:=================================================+
| 1  | Administrator             | This user role emulates internal superuser       |
|    |                           | privileges and permissions that are only granted |
|    |                           | to a single user tasked with management and      |
|    |                           | maintenance of the system and all other roles in |
|    |                           | the system.                                      |
+----+---------------------------+--------------------------------------------------+
| 2  | Workflow-Modeler/Designer | This composite role does collectively encompass  |
|    |                           | the system requirements to provide the ability   |
|    | Form-Builder              | to build forms, model workflows, attach modeled  |
|    |                           | workflow-tasks to built forms, and all pre and   |
|    |                           | post workflow triggers.                          |
|    |                           |                                                  |
|    |                           | This role requires those to whom it is granted   |
|    |                           | to have the ability to model workflows in the    |
|    |                           | standard BPM Notation or simply BPMN.            |
+----+---------------------------+--------------------------------------------------+
| 3  | Client                    | This composite role does collectively encompass  |
|    |                           | all privileges and permissions granted to NPIS   |
|    |                           | users who at any one time are to execute         |
|    |                           | workflow-tasks involving the retrieval of forms, |
|    |                           | creation and submission of form-data, updating   |
|    |                           | and resubmission of form-data                    |
+----+---------------------------+--------------------------------------------------+
| 4  | Reviewer                  | This composite role does collectively encompass  |
|    |                           | all privileges and permissions granted to NPIS   |
|    |                           | users who at any one time are to execute         |
|    |                           | workflow-tasks involving the review of submitted |
|    |                           | form-data, request resubmission of form-data and |
|    |                           | evaluation of submitted form-data.               |
+----+---------------------------+--------------------------------------------------+
| 5  | Approver                  | This composite role does collectively encompass  |
|    |                           | all privileges and permissions granted to NPIS   |
|    |                           | users who at any one time are to execute         |
|    |                           | workflow-tasks involving the approval of created |
|    |                           | and submitted form-data with rejection or        |
|    |                           | approve.                                         |
+----+---------------------------+--------------------------------------------------+ -->

|  |  |  |
| --- | --- | --- |
| # | User Role | Responsibilities |
| 1 | Administrator | This user role emulates internal superuser privileges and permissions that are only granted to a single user tasked with management and maintenance of the system and all other roles in the system. |
| 2 | Workflow-Modeler/Designer  Form-Builder | This composite role does collectively encompass the system requirements to provide the ability to build forms, model workflows, attach modeled workflow-tasks to built forms, and all pre and post workflow triggers.  This role requires those to whom it is granted to have the ability to model workflows in the standard BPM Notation or simply BPMN. |
| 3 | Client | This composite role does collectively encompass all privileges and permissions granted to NPIS users who at any one time are to execute workflow-tasks involving the retrieval of forms, creation and submission of form-data, updating and resubmission of form-data |
| 4 | Reviewer | This composite role does collectively encompass all privileges and permissions granted to NPIS users who at any one time are to execute workflow-tasks involving the review of submitted form-data, request resubmission of form-data and evaluation of submitted form-data. |
| 5 | Approver | This composite role does collectively encompass all privileges and permissions granted to NPIS users who at any one time are to execute workflow-tasks involving the approval of created and submitted form-data with rejection or approve. |

## System Environment

The system environment presented here does specify the general
contextual view of the NPIS with regards to the environment in which it
operates and how the NPIS is interacted with by external entities like
users and other systems.

![Figure 2: System Environment](data:image/png;base64,[encoded data, 76384 characters])
## System Features

This section outlines the several software product feature requirements
as specified for the National Petroleum Information System.

<!-- +--------+--------------------+----------------------------------------+
| \#     | Requirement/Module | Description                            |
+========+====================+========================================+
| 1.     | **Licensing and    | - All OMCs will be given user accounts |
|        | Permits**          |   which will be used to capture, edit, |
|        |                    |   update or verify the company/outlet  |
|        |                    |   details.                             |
|        |                    |                                        |
|        |                    | - These accounts will be used to apply |
|        |                    |   for licenses, construction permits   |
|        |                    |   and completion certificates.         |
|        |                    |                                        |
|        |                    | - The internal licensing process will  |
|        |                    |   remain the same adding the URA       |
|        |                    |   verification, company & outlet       |
|        |                    |   verification before registration.    |
|        |                    |                                        |
|        |                    | - The system will send all import      |
|        |                    |   licenses to URA as well as capture   |
|        |                    |   their import figures.                |
|        |                    |                                        |
|        |                    | - All license types will be allowed to |
|        |                    |   have both parented and child         |
|        |                    |   certificates.                        |
|        |                    |                                        |
|        |                    | - Licenses will be sent to applicants  |
|        |                    |   in soft copy                         |
+--------+--------------------+----------------------------------------+
| 2.     | **Volume           | - The Storage and sales information    |
|        | Tracking**         |   will be availed and manipulated by   |
|        |                    |   the storage and transportation unit. |
|        |                    |                                        |
|        |                    | - This will be entered directly into   |
|        |                    |   the system for all stations.         |
|        |                    |                                        |
|        |                    | - The importation licensees will have  |
|        |                    |   it (import, storage as well as       |
|        |                    |   sales) mandatory as a requirement in |
|        |                    |   their licenses.                      |
|        |                    |                                        |
|        |                    | - This will also include the companies |
|        |                    |   that will be purchasing the products |
+--------+--------------------+----------------------------------------+
| 3.     | **Stock and        | - Be able to enter GIS data captured   |
|        | Storage**          |   on all licensed facilities           |
|        |                    |   installations                        |
|        |                    |                                        |
|        |                    | - Be able to generate a facilities map |
|        |                    |   as per search queries                |
|        |                    |                                        |
|        |                    | - Be able to update data on transport  |
|        |                    |   a storage facility showing the       |
|        |                    |   licensing status                     |
|        |                    |                                        |
|        |                    | - Be able to determine the total       |
|        |                    |   storage capacity in the country as   |
|        |                    |   per data entered.                    |
|        |                    |                                        |
|        |                    | - Be able to interact with other       |
|        |                    |   modules like FMP, Licensing and      |
|        |                    |   Quality assurance.                   |
+--------+--------------------+----------------------------------------+
| 4.     | **International,   | - This will include the local prices   |
|        | Regional and Local |   as provided by the OMCs on their     |
|        | Group Prices**     |   user accounts.                       |
|        |                    |                                        |
|        |                    | - All price changes will be monitored  |
|        |                    |   by the system according to the OMCs  |
|        |                    |   data provided.                       |
|        |                    |                                        |
|        |                    | - Regional and international prices    |
|        |                    |   will be manually monitored by the    |
|        |                    |   PSD officers and verified into the   |
|        |                    |   system.                              |
+--------+--------------------+----------------------------------------+
| 5.     | **Environmental    | - Environmental data will be captured  |
|        | data**             |   and manipulated in form similarly to |
|        |                    |   the evaluation page from licensing.  |
|        |                    |                                        |
|        |                    | - Capture of the applications will be  |
|        |                    |   provided to the OMC accounts and     |
|        |                    |   verification and certification will  |
|        |                    |   all be done online.                  |
+--------+--------------------+----------------------------------------+
| 6.     | **Monitoring and   | - Officers will be able to capture new |
|        | Inspection**       |   stations while in the field pending  |
|        |                    |   registration                         |
|        |                    |                                        |
|        |                    | - Inspection points will remain as     |
|        |                    |   they are right now                   |
|        |                    |                                        |
|        |                    | - Inspection reports will be shared on |
|        |                    |   the respective accounts and emails   |
|        |                    |   of the companies                     |
|        |                    |                                        |
|        |                    | - All findings will be approved by the |
|        |                    |   principle officer and forwarded      |
|        |                    |   accordingly for action.              |
+--------+--------------------+----------------------------------------+
| 7.     | **Enforcement**    | - Proceedings that require the         |
|        |                    |   enforcement team will not be         |
|        |                    |   communicated to the OMC accounts     |
|        |                    |   before action                        |
|        |                    |                                        |
|        |                    | - Mobile labs will be able to capture  |
|        |                    |   new stations while in the field      |
|        |                    |   pending registration                 |
|        |                    |                                        |
|        |                    | - Officers will be able to capture new |
|        |                    |   stations while in the field pending  |
|        |                    |   registration                         |
|        |                    |                                        |
|        |                    | - Actions already taken will be        |
|        |                    |   communicated by the system to the    |
|        |                    |   respective accounts.                 |
+--------+--------------------+----------------------------------------+
| 8.     | **Laboratories and | - This will be divided into the        |
|        | Quality            |   Headquarters and mobile lab.         |
|        | Assurance**        |                                        |
|        |                    | - Mobile labs will be able to capture  |
|        |                    |   new stations while in the field      |
|        |                    |   pending registration                 |
|        |                    |                                        |
|        |                    | - The HQ process will be maintained as |
|        |                    |   is with a few changes to the flow    |
|        |                    |   and certificates.                    |
|        |                    |                                        |
|        |                    | - The mobile lab will have a           |
|        |                    |   tailor-made page that will feed into |
|        |                    |   the company/outlet accounts          |
|        |                    |   directly.                            |
|        |                    |                                        |
|        |                    | - All results from the mobile lab will |
|        |                    |   be sent directly to the company      |
|        |                    |   account                              |
+--------+--------------------+----------------------------------------+
| 9.     | **LPG gas**        | - This will be used to capture LPG     |
|        |                    |   kits that have been issued and issue |
|        |                    |   details.                             |
|        |                    |                                        |
|        |                    | - The issuing OMC will be given an     |
|        |                    |   additional role of capturing this    |
|        |                    |   information into the system.         |
|        |                    |                                        |
|        |                    | - The NPIS will analyses the patterns  |
|        |                    |   and details of the LPG kit usage and |
|        |                    |   frequency.                           |
+--------+--------------------+----------------------------------------+
| 10.    | **Standards Unit** | - This will be used to upload the      |
|        |                    |   standard files and comments          |
|        |                    |   generated from the department users  |
|        |                    |                                        |
|        |                    | - The standards officers will also     |
|        |                    |   provide status reports on these      |
|        |                    |   standards for products, equipment    |
|        |                    |   and infrastructure.                  |
|        |                    |                                        |
|        |                    | - The finished standard/ gazette and   |
|        |                    |   draft standards will be availed to   |
|        |                    |   all staff members.                   |
+--------+--------------------+----------------------------------------+
| 11.    | **Workflows and    | - Support for a single person or group |
|        | form builders**    |   of persons to be responsible for an  |
|        |                    |   action in the execution process of   |
|        |                    |   the workflow with option of one or   |
|        |                    |   all persons being required to        |
|        |                    |   complete or approve an action        |
|        |                    |   defined in the workflow process      |
|        |                    |                                        |
|        |                    | - Workflow defined as in (a-c) above   |
|        |                    |   should be saved and reused by        |
|        |                    |   authorized users without them        |
|        |                    |   needing to modify the designed       |
|        |                    |   process                              |
|        |                    |                                        |
|        |                    | - Workflow should provide for the      |
|        |                    |   option of a blank action person for  |
|        |                    |   the first task to enable the         |
|        |                    |   submitter select the person to       |
|        |                    |   execute the first task in the series |
|        |                    |   of tasks comprising the workflow     |
|        |                    |   design.                              |
|        |                    |                                        |
|        |                    | - This feature is important to enable  |
|        |                    |   a single workflow to take multiple   |
|        |                    |   paths through selection of first     |
|        |                    |   task players at the time of          |
|        |                    |   assigning an automation sequence     |
|        |                    |                                        |
|        |                    | - Workflow should support dashboard    |
|        |                    |   notification and mail notification   |
|        |                    |   for assigned workflow tasks to       |
|        |                    |   assignees, assigners and supervisors |
|        |                    |                                        |
|        |                    | - Workflow should provide for          |
|        |                    |   notification of assigners on         |
|        |                    |   completion or delay in completion of |
|        |                    |   assigned tasks                       |
|        |                    |                                        |
|        |                    | - Workflow should provide for          |
|        |                    |   notification of assigners the        |
|        |                    |   successful completion of tasks       |
|        |                    |                                        |
|        |                    | - Workflow should provide for          |
|        |                    |   notification of assigners the        |
|        |                    |   rejection of an approval process     |
|        |                    |   originated by an assigner            |
|        |                    |                                        |
|        |                    | - Workflow should support inclusion of |
|        |                    |   supervisors in the chain for         |
|        |                    |   escalation of unfinished tasks       |
|        |                    |                                        |
|        |                    | - Workflow should allow for attachment |
|        |                    |   of additional content in the         |
|        |                    |   execution path apart from the main   |
|        |                    |   content which triggers process       |
|        |                    |                                        |
|        |                    | - Workflow should allow for the        |
|        |                    |   applying comments to content         |
|        |                    |                                        |
|        |                    | - Workflow should allow for editing    |
|        |                    |   content in workflow                  |
|        |                    |                                        |
|        |                    | - Workflow should allow for submission |
|        |                    |   of content from other applications   |
|        |                    |   to facilitate integration of         |
|        |                    |   processes from other                 |
|        |                    |                                        |
|        |                    | - The form builder should support easy |
|        |                    |   and dynamic building and updating of |
|        |                    |   the forms in the system              |
|        |                    |                                        |
|        |                    | - The form builder should allow easy   |
|        |                    |   updating, publishing and             |
|        |                    |   unpublishing of the organizational   |
|        |                    |   forms                                |
|        |                    |                                        |
|        |                    | - The form builder should be able to   |
|        |                    |   support building of sections of the  |
|        |                    |   data that is to be captured          |
|        |                    |                                        |
|        |                    | - The form builder must support both   |
|        |                    |   generic and user defined data types, |
|        |                    |   including integration of             |
|        |                    |   administrative units in Uganda up to |
|        |                    |   village level                        |
+--------+--------------------+----------------------------------------+
| 12.    | **Other services** | - Connection will single window will   |
|        |                    |   have to be maintained.               |
|        |                    |                                        |
|        |                    | - All users will have special roles    |
|        |                    |   that will be delegated by the Admin. |
|        |                    |   The Administrator will be able to    |
|        |                    |   edit, create and delete records      |
|        |                    |   within the system if need arises.    |
|        |                    |                                        |
|        |                    | - Verification with NEMA and local     |
|        |                    |   authorities might be required at     |
|        |                    |   some stages.                         |
|        |                    |                                        |
|        |                    | - Documents will be uploaded by the    |
|        |                    |   OMCs in PDF                          |
|        |                    |                                        |
|        |                    | - ALL OMCs must have user accounts in  |
|        |                    |   the system to interact with PSD and  |
|        |                    |   no paperwork will be given out by    |
|        |                    |   the department apart from PDF or     |
|        |                    |   excel documents.                     |
|        |                    |                                        |
|        |                    | - Running Backup server will be at     |
|        |                    |   NITA-U                               |
|        |                    |                                        |
|        |                    | - A place for the OMCs to request for  |
|        |                    |   information will be provided.        |
|        |                    |                                        |
|        |                    | - A mobile app for the field officers  |
|        |                    |   will be developed with easy to use   |
|        |                    |   GUI and able to store info in case   |
|        |                    |   of poor or no internet connection    |
|        |                    |   pending better connection.           |
|        |                    |                                        |
|        |                    | - Stations should have different       |
|        |                    |   statuses such as de-commissioned,    |
|        |                    |   active, sealed or halted.            |
+--------+--------------------+----------------------------------------+ -->

|  |  |  |
| --- | --- | --- |
| # | Requirement/Module | Description |
|  | **Licensing and Permits** | * All OMCs will be given user accounts which will be used to capture, edit, update or verify the company/outlet details. * These accounts will be used to apply for licenses, construction permits and completion certificates. * The internal licensing process will remain the same adding the URA verification, company & outlet verification before registration. * The system will send all import licenses to URA as well as capture their import figures. * All license types will be allowed to have both parented and child certificates. * Licenses will be sent to applicants in soft copy |
|  | **Volume Tracking** | * The Storage and sales information will be availed and manipulated by the storage and transportation unit. * This will be entered directly into the system for all stations. * The importation licensees will have it (import, storage as well as sales) mandatory as a requirement in their licenses. * This will also include the companies that will be purchasing the products |
|  | **Stock and Storage** | * Be able to enter GIS data captured on all licensed facilities installations * Be able to generate a facilities map as per search queries * Be able to update data on transport a storage facility showing the licensing status * Be able to determine the total storage capacity in the country as per data entered. * Be able to interact with other modules like FMP, Licensing and Quality assurance. |
|  | **International, Regional and Local Group Prices** | * This will include the local prices as provided by the OMCs on their user accounts. * All price changes will be monitored by the system according to the OMCs data provided. * Regional and international prices will be manually monitored by the PSD officers and verified into the system. |
|  | **Environmental data** | * Environmental data will be captured and manipulated in form similarly to the evaluation page from licensing. * Capture of the applications will be provided to the OMC accounts and verification and certification will all be done online. |
|  | **Monitoring and Inspection** | * Officers will be able to capture new stations while in the field pending registration * Inspection points will remain as they are right now * Inspection reports will be shared on the respective accounts and emails of the companies * All findings will be approved by the principle officer and forwarded accordingly for action. |
|  | **Enforcement** | * Proceedings that require the enforcement team will not be communicated to the OMC accounts before action * Mobile labs will be able to capture new stations while in the field pending registration * Officers will be able to capture new stations while in the field pending registration * Actions already taken will be communicated by the system to the respective accounts. |
|  | **Laboratories and Quality Assurance** | * This will be divided into the Headquarters and mobile lab. * Mobile labs will be able to capture new stations while in the field pending registration * The HQ process will be maintained as is with a few changes to the flow and certificates. * The mobile lab will have a tailor-made page that will feed into the company/outlet accounts directly. * All results from the mobile lab will be sent directly to the company account |
|  | **LPG gas** | * This will be used to capture LPG kits that have been issued and issue details. * The issuing OMC will be given an additional role of capturing this information into the system. * The NPIS will analyses the patterns and details of the LPG kit usage and frequency. |
|  | **Standards Unit** | * This will be used to upload the standard files and comments generated from the department users * The standards officers will also provide status reports on these standards for products, equipment and infrastructure. * The finished standard/ gazette and draft standards will be availed to all staff members. |
|  | **Workflows and form builders** | * Support for a single person or group of persons to be responsible for an action in the execution process of the workflow with option of one or all persons being required to complete or approve an action defined in the workflow process * Workflow defined as in (a-c) above should be saved and reused by authorized users without them needing to modify the designed process * Workflow should provide for the option of a blank action person for the first task to enable the submitter select the person to execute the first task in the series of tasks comprising the workflow design. * This feature is important to enable a single workflow to take multiple paths through selection of first task players at the time of assigning an automation sequence * Workflow should support dashboard notification and mail notification for assigned workflow tasks to assignees, assigners and supervisors * Workflow should provide for notification of assigners on completion or delay in completion of assigned tasks * Workflow should provide for notification of assigners the successful completion of tasks * Workflow should provide for notification of assigners the rejection of an approval process originated by an assigner * Workflow should support inclusion of supervisors in the chain for escalation of unfinished tasks * Workflow should allow for attachment of additional content in the execution path apart from the main content which triggers process * Workflow should allow for the applying comments to content * Workflow should allow for editing content in workflow * Workflow should allow for submission of content from other applications to facilitate integration of processes from other * The form builder should support easy and dynamic building and updating of the forms in the system * The form builder should allow easy updating, publishing and unpublishing of the organizational forms * The form builder should be able to support building of sections of the data that is to be captured * The form builder must support both generic and user defined data types, including integration of administrative units in Uganda up to village level |
|  | **Other services** | * Connection will single window will have to be maintained. * All users will have special roles that will be delegated by the Admin. The Administrator will be able to edit, create and delete records within the system if need arises. * Verification with NEMA and local authorities might be required at some stages. * Documents will be uploaded by the OMCs in PDF * ALL OMCs must have user accounts in the system to interact with PSD and no paperwork will be given out by the department apart from PDF or excel documents. * Running Backup server will be at NITA-U * A place for the OMCs to request for information will be provided. * A mobile app for the field officers will be developed with easy to use GUI and able to store info in case of poor or no internet connection pending better connection. * Stations should have different statuses such as de-commissioned, active, sealed or halted. |

## System Design and Implementation Constraints

In this section the consultant discusses the crucial design and
implementation constraints that justified his choices for the software
development stack and the deployment environment.

### Disparate Legacy Datasets

As part of this project's work products, the consultant did analyse and
documented NPIS data requirements that are necessary and needed from
stakeholders/partners that included Ministries, Departments, Agencies
(MDAs) as well as migration of legacy or old datasets from the old
existing data model to the new system data model.

### External System Interface Deadlocks and Blockages

NPIS does depend on externally interfacing with other systems. These do
manifest when NPIS microservices like the workflow management
microservice queries external systems for instance:

- **Request queries for evaluation reports and documents from MDAs:**
  like Environment Impact Assessment reports from NEMA for,
  environmental evaluations and environmental impact studies and all
  related procedures. Even these are done in accordance with the laws
  applicable to public health, public safety and the environment,
  granting the PSD commissioner as the "lead agency" to co-ordinate with
  NEMA and other appropriate authorities under the relevant laws,
  however, such replies may delay hence putting the whole workflow in
  halt or complete deadlock.

- **Payment confirmations from payment gateways and processors:** like
  querying URA for Payment Reference Numbers (PRNs) for confirmation of
  payments during facility construction permits, and operations
  licensing applications workflows. However, pinged systems respond
  using a best-effort mode with logged offline downtime spanning from
  days to weeks.

## Assumptions and Dependencies

The assumptions and dependencies made below, do derive from the many
implicit requirements and supplementary requirements that were not
explicitly mentioned but from the consultant's experience, they do come
off as hard to eliminate. These mostly cascade as dependencies from
which certain functionalities are derived from the previous section that
highlighted design constrained:

Besides the assumption that users do possess the technical ability to
use and navigate the system, with the right inputs and do comprehend
system outputs, most assumptions regard external system that NPIS
interfaces with. These have been extrapolated to much NPIS' non
functional requirements as listed below:

- **Performance:** this regards response-time of external systems that
  NPIS interfaces with, here the assumptions made are these external
  systems are performant to agreeable tolerances of NPIS itself as
  though they are deployed on the same computation and network
  infrastructure.

- **Reliability:** this assumption regards the Mean Time between
  Failures (MTBF) or Mean Time to Failures (MTTF) of external systems to
  which NPIS interfaces with to fetch or query like those processing
  payment confirmations.

- **Availability:** the assumption regards whether external systems as
  functional requirements provide an uptime of 95%. The uptime is
  calculated as the percentage of time during the year in which the
  software system is expected to be available to NPIS. A 95% uptime
  percentage allows for an average of 18.25 days per year, 36 hours per
  month, or 8.4 hours per week of downtime means a tolerable average of
  non-responsive queries, timeout queries, and unreachability network
  errors.

# 

# Requirement Specifications

## External Interface Requirements

This section of the SRS describes the interface requirements for the
system. Requirements for user, hardware, software, and communication
interfaces are defined.

### System Interfaces

The National Petroleum Information System is conceptualized to
interfaces with several system interfaces. These include the following:

### User Interfaces

This subsection of the SRS defines the UI requirements for the National
Petroleum Information System. However, to exhaust a deeper engagement
with the client, UI mockup wireframes have been compiled into a
dedicated User Interface Design Document that accompanies this document.

### Hardware Interfaces

All server-side components must execute on server-class computers. All
client-side components must execute on workstation-class and
personal-class computers and smartphones.

### Software Interfaces

Software interfaces to the National Petroleum Information System do
manifest primarily in the Workflow Management System microservices of
the system. These include the following:

Document creation or generation, modification, visualization and
printing software interfaces and office suite-packages like Microsoft
word, google docs, adobe pdf readers etc.

Global Position Systems for surveying and Geospatial Information Systems
for both desktop mapping and Web Mapping Tile Services (WMTS) that
provide base-layers on top of which all mapping and geolocations of
facility installations.

### Communication Interfaces

The communication architecture must follow the client-server model.
Communication between the client and server should utilize a
REST-compliant web service and must be served over HTTP Secure (HTTPS).
The client-server communication must be stateless. A uniform interface
must separate the client roles from the server roles.

### Memory Constraints

Both storage and processing of form and workflow data for Workflow
management for petroleum supply operations involving creating,
documenting, permits and licensing, volume storage and tracking,
pricing, environmental assessment, monitoring and inspection, compliance
enforcement, labs and quality assurance, LGP and standards processes
does require a consideration for memory and storage space. This relies
on the underlying hardware choices made for the operating environment of
the developed system.

## Database Requirement

By SRS documentation standards, this section is meant to discuss the
modelling of data for the National Petroleum Information System.
However, the logical data model and its subsequent conceptual and
physical data models have been documented in a dedicated database design
document in compliance with (IEEE, 1998) ISO/IEEE standard. Is presented
below as an Enhanced Entity Relation Diagram (EERD).

## Functional Requirements

This section discusses in detail, analysed functional requirements
documented and presented as use case models and activity diagrams or
tabular sequences to communicate use case scenarios, an SRS compliant
alternative to sequence diagrams in compliance with the ISO/IEC 12207
and ISO/IEC 15288 standards.

The National Petroleum Information System (NPIS), as a web-based system,
will be conceived as a client-server web application with microservices
that will conform to a Service Oriented Architecture (SOA) as the
software architectural pattern of choice. This will help enable ease of
change in scale of the NPIS implementation, as well as adding new units
of functionality as required.

In a Service Oriented Architecture (SOA), a service is a discrete unit
of functionality that can be accessed remotely and acted upon and
updated independently. SOA is also intended to be independent of
vendors, products and technologies hence giving the consultant freedom
of choice in technologies.

It is with the earlier adopted ISO/IEC/IEEE 29148 standard that every
requirement of the consultancy is to be analyzed to derive responding
microservice units of functionality for the NPIS Service Oriented
Architecture.

Below is the table that details the analyzed requirements and
microservices derived from functional requirements, the first column
identifies the functional requirements from requirements gathering and
the analyzed units of functionality.

<!-- +-------------+---------------------------------------------------------+
| Requirement | Derived Microservice Unit of Functionality              |
+=============+=========================================================+
| REQ.12      | The ToR specifies all users with roles including OMC    |
|             | accounts that will be used to interact with PSD. As     |
|             | well as an admin role that will create, edit and delete |
|             | records. Hence user management and accessibility as a   |
|             | unit of functionality for NPIS users, will              |
|             | architecturally be conceptualized in design with        |
|             | authorization as steps that precede authentication as a |
|             | means to confirming digital identification before       |
|             | accessibility. Using Single factor authentication as a  |
|             | category of credential for verification using Password  |
|             | Authentication Protocol (PAP). This will be             |
|             | computationally conceptualized as the **User            |
|             | Management, Access and Authentication Microservice.**   |
+-------------+---------------------------------------------------------+
| REQ.1       | All units of functionality related to execution of      |
|             | workflows by OMC accounts to capture, edit, updating    |
|             | and verification of company or outlet details like      |
|             | licenses, construction permits and completion           |
|             | certificates. These units of functionality will         |
|             | collectively be modelled into the **Licensing and       |
|             | Permits Microservice**.                                 |
+-------------+---------------------------------------------------------+
| REQ.2       | All units of functionality related to execution of      |
|             | workflows user accounts to capture, edit, updating of   |
|             | storage and sales details like importation, storage and |
|             | importation licenses as well as companies purchasing    |
|             | the products. These units of functionality will         |
|             | collectively be modelled into the **Volume Tracking     |
|             | Microservice**.                                         |
+-------------+---------------------------------------------------------+
| REQ.3       | The functional requirement to provide NPIS web-based    |
|             | users the ability to accomplish tasks and workflows     |
|             | involving geovisualizations and renderings of licensed  |
|             | facility installations, as geospatial data. This does   |
|             | require the adoption of the **Open Geospatial           |
|             | Consortium (OGC)** standards for web mapping.           |
|             |                                                         |
|             | Implementing OGC standards/protocols such as **WCS**    |
|             | (Web Coverage Service) **WFS** (Web Feature Service),   |
|             | **WMS** (Web Map Service -- provides map image),        |
|             | **WMTS** (Web Map Tile Service), **WPS** (Web           |
|             | Processing Service), **WTS** (Web Terrain Service),     |
|             | does require Geoprocessing and visualization units of   |
|             | functionality optimized without redundancy for the      |
|             | resource-constrained web environment. This will enable  |
|             | NPIS users to accomplish capture, generation, update    |
|             | and storage of licensed facility installation mapping,  |
|             | geoprocessing and geovisualizations tasks like zooming, |
|             | panning, rotating, annotating, extruding and overlaying |
|             | of geospatial aquifers information. This unit of        |
|             | functionality will be conceived as the **Stock and      |
|             | Storage Microservice**.                                 |
+-------------+---------------------------------------------------------+
| REQ.4       | Here, all units of functionality and workflows related  |
|             | to capturing of local prices from OMC accounts and      |
|             | regional and international prices captured, and         |
|             | monitored by the PSD accounts will be collectively      |
|             | modelled as the **Prices Microservice.**                |
+-------------+---------------------------------------------------------+
| REQ.5       | Here, all units of functionality and workflows related  |
|             | to capturing, storage, retrieval and visualization of   |
|             | environment data will be collectively modelled as the   |
|             | **Environment Data Microservice.**                      |
+-------------+---------------------------------------------------------+
| REQ.6       | Here, all units of functionality and workflows related  |
|             | to PSD field officers capturing, updating and reporting |
|             | data for stations pending registration on mobile using  |
|             | PSD accounts will be collectively modelled as the       |
|             | **Monitoring and Inspection Microservice.**             |
+-------------+---------------------------------------------------------+
| REQ.7       | Here, all units of functionality and workflows related  |
|             | to PSD field officers capturing, enforcement data for   |
|             | stations pending registration as well as new stations   |
|             | on mobile using PSD accounts will be collectively       |
|             | modelled as the **Enforcement Microservice.**           |
+-------------+---------------------------------------------------------+
| REQ.8       | Here, all units of functionality and workflows related  |
|             | to both mobile labs and those at the headquarters PSD   |
|             | field officers capturing quality assurance lab data for |
|             | stations pending registration as well as new stations   |
|             | which will directly feed into outlet or company         |
|             | accounts. These will be collectively modelled as the    |
|             | **Labs and Quality Assurance Microservice.**            |
+-------------+---------------------------------------------------------+
| REQ.9       | Here, all units of functionality and workflows related  |
|             | to PSD field officers capturing, updating and reporting |
|             | data for issued LPG kits as well as their usage and     |
|             | frequency on mobile using PSD accounts will be          |
|             | collectively modelled as the **LPG Gas Microservice.**  |
+-------------+---------------------------------------------------------+
| REQ.10      | Here, all units of functionality and workflows related  |
|             | to standards officers capturing, updating and reporting |
|             | standards files and comments generated from department  |
|             | users using standards accounts. This will also include  |
|             | the capture of standards data for products, equipment   |
|             | and infrastructure in form of a gazette and draft       |
|             | standards. These will be collectively modelled as the   |
|             | **Standards Unit Microservice.**                        |
+-------------+---------------------------------------------------------+
| REQ.11      | All microservices will be computationally in-linked as  |
|             | an integrated workflow management system which will     |
|             | executed to accomplish all tasks pertaining to          |
|             | capturing and storage, retrieval, viewing and           |
|             | reporting. These will be computationally handled by the |
|             | **Workflow Management Microservice** as a collective    |
|             | unit of functionality.                                  |
+-------------+---------------------------------------------------------+ -->

|  |  |
| --- | --- |
| Requirement | Derived Microservice Unit of Functionality |
| REQ.12 | The [ToR](./ToR.md#task-2-the-system) specifies all users with roles including OMC accounts that will be used to interact with PSD. As well as an admin role that will create, edit and delete records. Hence user management and accessibility as a unit of functionality for NPIS users, will architecturally be conceptualized in design with authorization as steps that precede authentication as a means to confirming digital identification before accessibility. Using Single factor authentication as a category of credential for verification using Password Authentication Protocol (PAP). This will be computationally conceptualized as the **User Management, Access and Authentication Microservice.** |
| REQ.1 | All units of functionality related to execution of workflows by OMC accounts to capture, edit, updating and verification of company or outlet details like licenses, construction permits and completion certificates. These units of functionality will collectively be modelled into the **Licensing and Permits Microservice**. |
| REQ.2 | All units of functionality related to execution of workflows user accounts to capture, edit, updating of storage and sales details like importation, storage and importation licenses as well as companies purchasing the products. These units of functionality will collectively be modelled into the **Volume Tracking Microservice**. |
| REQ.3 | The functional requirement to provide NPIS web-based users the ability to accomplish tasks and workflows involving geovisualizations and renderings of licensed facility installations, as geospatial data. This does require the adoption of the **Open Geospatial Consortium (OGC)** standards for web mapping.  Implementing OGC standards/protocols such as **WCS** (Web Coverage Service) **WFS** (Web Feature Service), **WMS** (Web Map Service � provides map image), **WMTS** (Web Map Tile Service), **WPS** (Web Processing Service), **WTS** (Web Terrain Service), does require Geoprocessing and visualization units of functionality optimized without redundancy for the resource-constrained web environment. This will enable NPIS users to accomplish capture, generation, update and storage of licensed facility installation mapping, geoprocessing and geovisualizations tasks like zooming, panning, rotating, annotating, extruding and overlaying of geospatial aquifers information. This unit of functionality will be conceived as the **Stock and Storage Microservice**. |
| REQ.4 | Here, all units of functionality and workflows related to capturing of local prices from OMC accounts and regional and international prices captured, and monitored by the PSD accounts will be collectively modelled as the **Prices Microservice.** |
| REQ.5 | Here, all units of functionality and workflows related to capturing, storage, retrieval and visualization of environment data will be collectively modelled as the **Environment Data Microservice.** |
| REQ.6 | Here, all units of functionality and workflows related to PSD field officers capturing, updating and reporting data for stations pending registration on mobile using PSD accounts will be collectively modelled as the **Monitoring and Inspection Microservice.** |
| REQ.7 | Here, all units of functionality and workflows related to PSD field officers capturing, enforcement data for stations pending registration as well as new stations on mobile using PSD accounts will be collectively modelled as the **Enforcement Microservice.** |
| REQ.8 | Here, all units of functionality and workflows related to both mobile labs and those at the headquarters PSD field officers capturing quality assurance lab data for stations pending registration as well as new stations which will directly feed into outlet or company accounts. These will be collectively modelled as the **Labs and Quality Assurance Microservice.** |
| REQ.9 | Here, all units of functionality and workflows related to PSD field officers capturing, updating and reporting data for issued LPG kits as well as their usage and frequency on mobile using PSD accounts will be collectively modelled as the **LPG Gas Microservice.** |
| REQ.10 | Here, all units of functionality and workflows related to standards officers capturing, updating and reporting standards files and comments generated from department users using standards accounts. This will also include the capture of standards data for products, equipment and infrastructure in form of a gazette and draft standards. These will be collectively modelled as the **Standards Unit Microservice.** |
| REQ.11 | All microservices will be computationally in-linked as an integrated workflow management system which will executed to accomplish all tasks pertaining to capturing and storage, retrieval, viewing and reporting. These will be computationally handled by the **Workflow Management Microservice** as a collective unit of functionality. |

: []Table 2: Analyzed Units of functionality and
microservices

### User Management, Access and Authentication Microservice Use Cases

To model User Management, Access and Authentication, respective use case
models have been sub modelled into access and authentication use cases
and user account management use cases.

The use cases in Figure 3, do model how NPIS users are authenticated and
given access to the system. These include log-in by supplying a username
and password that get validated or authenticated for access and
authorization. And in order to leave the system, users are modelled to
logout which expires their sessions.

![[]Figure 3: User Access and Authentication Use
Case
Model](data:image/png;base64,[encoded data, 87136 characters])

From the System Users and Characteristics section, different users did
exhibit differing needs and requirements as discussed in the next use
cases. Therefore, access and authentication use cases models do depict
that after authentication, access is affected based on user groups to
which differing roles and privileges are granted.

The use cases in Figure 4, do model how system user groups and their
respective accounts are created, edited, deleted, locked and unlocked in
the system by an authenticated system administrator or the super user.
Following account creation, authenticated users can activate their
respective accounts by following links sent to their respective email.
From within an activated account, users can change their passwords from
the default passwords that come pre-coded into the accounts.

A step by step behavioural table is presented in a tabular use case
scenario type of activity workflow.

#### Log in as admin

The Log in as admin use case is discussed in the table below:

Table 3: Log in as admin use case

|  |  |
| --- | --- |
| **UC1** | Log in as admin |
| **Description:** | The user requirement for an administrator to login and access the system |
| **Actors:** | * System administrator (super user) * User granted the admin user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The (administrator or user with admin privileges) user requires to access the system |
| **Inputs:** | * username (login) * password |
| **Preconditions:** | * user-account is available, active and not locked * user has access to the login-page |
| **Main Success scenario** | 1. the user opens the login page of the web application 2. the user enters the username 3. the user enters the password 4. the user clicks the login button 5. the system validates username and password and creates a new (http-session) |
| **Alternative**  **Scenarios:** | Automatic forwarding to the login page:   * accessing protected functions will automatically forward the user to the login page in case they are not logged in yet |
| **Success End**  **Condition:** | * the user has access to the system * the page that the user wanted to access prior to authentication is displayed (automatic forwarding) * the system created a new (http-session)   Optional: the system might want to set a cookie ("remember me") |
| **Failed End**  **Condition:** | Wrong password:   * the failed-login-counter is being incremented * if the number of failed login-attempts exceeds a configurable threshold then the user account is being locked * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system   Wrong username(login):   * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system |

#### Log out as admin

The Log out as admin use case is discussed in the table below:

Table 4: Log out as admin use case

|  |  |
| --- | --- |
| **UC2** | Log out as admin |
| **Description:** | The user closes their current session and stops accessing the system. |
| **Actors:** | * System administrator * User granted with the admin user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | * The (administrator or user with admin privileges) user requires to end their session |
| **Inputs:** | * none |
| **Preconditions:** | * The user is logged into the system |
| **Main Success scenario** | 1. User clicks the "Logout" button/link 2. The system closes the http session and forwards the user to the login page |
| **Alternative**  **Scenarios:** | * Users can although be logged out by a session timeout |
| **Success End**  **Condition:** | * The user is logged out |
| **Failed End**  **Condition:** | * The user is still logged in * An error message is displayed |

#### Log in as Workflow Designer

The Log in as Workflow Designer use case is discussed in the table below:

Table 5: Log in as Workflow Designer use case

|  |  |
| --- | --- |
| **UC3** | Log in as Workflow Designer |
| **Description:** | The user requirement for staff user group to login and access the system |
| **Actors:** | Users granted the Workflow Designer user role   * Commissioner * Administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | user granted the Workflow Designer user role and privilege requires to access the system |
| **Inputs:** | * username (login) * password |
| **Preconditions:** | * user-account is available, active and not locked * user has access to the login-page |
| **Main Success scenario** | 1. the user opens the login page of the web application 2. the user enters the username 3. the user enters the password 4. the user clicks the login button 5. the system validates username and password and creates a new (http-)session |
| **Alternative**  **Scenarios:** | Automatic forwarding to the login page:   * accessing protected functions will automatically forward the user to the login page in case they are not logged in yet |
| **Success End**  **Condition:** | * the user has access to the system * the page that the user wanted to access prior to authentication is displayed (automatic forwarding) * the system created a new (http-)session   Optional: the system might want to set a cookie ("remember me") |
| **Failed End**  **Condition:** | Wrong password:   * the failed-login-counter is being incremented * if the number of failed login-attempts exceeds a configurable threshold then the user account is being locked * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system   Wrong username(login):   * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system |

#### Log out as Workflow Designer

The Log out as staff use case is discussed in the table below:

Table 6: Log out as Workflow Designer use case

|  |  |
| --- | --- |
| **UC4** | Log out as Workflow Designer |
| **Description:** | The user closes their current session and stops accessing the system. |
| **Actors:** | Users granted with the Workflow Designer user role and privileges   * Commissioner * Administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | * Workflow Designer (user with Workflow Designer user group privileges) user requires to end their session |
| **Inputs:** | * none |
| **Preconditions:** | * The user is logged into the system |
| **Main Success scenario** | 1. User clicks the "Logout" button/link 2. The system closes the http session and forwards the user to the login page |
| **Alternative**  **Scenarios:** | * Users can although be logged out by a session timeout |
| **Success End**  **Condition:** | * The user is logged out |
| **Failed End**  **Condition:** | * The user is still logged in * An error message is displayed |

#### Log in as Reviewer

The Log in as Reviewer use case is discussed in the table below:

Table 7: Log in as Reviewer use case

|  |  |
| --- | --- |
| **UC5** | Log in as Reviewer |
| **Description:** | The user requirement for Reviewer user group to login and access the system |
| **Actors:** | * Petroleum Officer * Principal Petroleum Officer * Senior Petroleum Officer * User granted with the Reviewer user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Reviewer (user with Reviewer user role privileges) user requires to access the system |
| **Inputs:** | * username (login) * password |
| **Preconditions:** | * user-account is available, active and not locked * user has access to the login-page |
| **Main Success scenario** | 1. the user opens the login page of the web application 2. the user enters the username 3. the user enters the password 4. the user clicks the login button 5. the system validates username and password and creates a new (http-)session |
| **Alternative**  **Scenarios:** | Automatic forwarding to the login page:   * accessing protected functions will automatically forward the user to the login page in case they are not logged in yet |
| **Success End**  **Condition:** | * the user has access to the system * the page that the user wanted to access prior to authentication is displayed (automatic forwarding) * the system created a new (http-)session   Optional: the system might want to set a cookie ("remember me") |
| **Failed End**  **Condition:** | Wrong password:   * the failed-login-counter is being incremented * if the number of failed login-attempts exceeds a configurable threshold then the user account is being locked * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system   Wrong username(login):   * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system |

#### Log out as Reviewer

The Log out as Reviewer use case is discussed in the table below:

Table 8: Log out as Reviewer use case

|  |  |
| --- | --- |
| **UC6** | Log out as Reviewer |
| **Description:** | The user closes their current session and stops accessing the system. |
| **Actors:** | * Petroleum Officer * Principal Petroleum Officer * Senior Petroleum Officer * User granted with the Reviewer user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | * Reviewer (user with Reviewer user group privileges) user requires to end their session |
| **Inputs:** | * none |
| **Preconditions:** | * The user is logged into the system |
| **Main Success scenario** | 1. User clicks the "Logout" button/link 2. The system closes the http session and forwards the user to the login page |
| **Alternative**  **Scenarios:** | * Users can although be logged out by a session timeout |
| **Success End**  **Condition:** | * The user is logged out |
| **Failed End**  **Condition:** | * The user is still logged in * An error message is displayed |
| **Failed End**  **Condition:** | * The user is still logged in * An error message is displayed |

#### Log in as Approver

The Log in as Approver use case is discussed in the table below:

Table 9: Log in as Approver use case

|  |  |
| --- | --- |
| **UC7** | Log in as Approver |
| **Description:** | The user requirement for Approver user role to login and access the system |
| **Actors:** | * Commissioner * Principal Petroleum Officer * User granted with the Approver user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Approver (user granted with Approver user role privileges) user requires to access the system |
| **Inputs:** | * username (login) * password |
| **Preconditions:** | * user-account is available, active and not locked * user has access to the login-page |
| **Main Success scenario** | 1. the user opens the login page of the web application 2. the user enters the username 3. the user enters the password 4. the user clicks the login button 5. the system validates username and password and creates a new (http-)session |
| **Alternative**  **Scenarios:** | Automatic forwarding to the login page:   * accessing protected functions will automatically forward the user to the login page in case they are not logged in yet |
| **Success End**  **Condition:** | * the user has access to the system * the page that the user wanted to access prior to authentication is displayed (automatic forwarding) * the system created a new (http-)session   Optional: the system might want to set a cookie ("remember me") |
| **Failed End**  **Condition:** | Wrong password:   * the failed-login-counter is being incremented * if the number of failed login-attempts exceeds a configurable threshold then the user account is being locked * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system   Wrong username(login):   * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system |

#### Log out as Approver

The Log out as Approver use case is discussed in the table below:

Table 10: Log out as Approver use case

|  |  |
| --- | --- |
| **UC8** | Log out as Approver |
| **Description:** | The user closes their current session and stops accessing the system. |
| **Actors:** | * Commissioner * Principal Petroleum Officer * User granted with the Approver user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | * Approver (user granted with Approver user role and privileges) user requires to end their session |
| **Inputs:** | * none |
| **Preconditions:** | * The user is logged into the system |
| **Main Success scenario** | 1. User clicks the "Logout" button/link 2. The system closes the http session and forwards the user to the login page |
| **Alternative**  **Scenarios:** | * Users can although be logged out by a session timeout |
| **Success End**  **Condition:** | * The user is logged out |
| **Failed End**  **Condition:** | * The user is still logged in * An error message is displayed |
| **Failed End**  **Condition:** | * The user is still logged in * An error message is displayed |

#### Log in as Client

The Log in as Client use case is discussed in the table below:

Table 11: Log in as Client use case

|  |  |
| --- | --- |
| **UC9** | Log in as Client |
| **Description:** | The user requirement for Client user role to login and access the system |
| **Actors:** | * Petroleum Developer * Commissioner * Petroleum Officer * Principal Petroleum Officer * Senior Petroleum Officer * User granted with the client user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Client (user with Client user role and privileges) user requires to access the system |
| **Inputs:** | * username (login) * password |
| **Preconditions:** | * user-account is available, active and not locked * user has access to the login-page |
| **Main Success scenario** | 1. the user opens the login page of the web application 2. the user enters the username 3. the user enters the password 4. the user clicks the login button 5. the system validates username and password and creates a new (http-)session |
| **Alternative**  **Scenarios:** | Automatic forwarding to the login page:   * accessing protected functions will automatically forward the user to the login page in case they are not logged in yet |
| **Success End**  **Condition:** | * the user has access to the system * the page that the user wanted to access prior to authentication is displayed (automatic forwarding) * the system created a new (http-)session   Optional: the system might want to set a cookie ("remember me") |
| **Failed End**  **Condition:** | Wrong password:   * the failed-login-counter is being incremented * if the number of failed login-attempts exceeds a configurable threshold then the user account is being locked * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system   Wrong username(login):   * an error message is being displayed (the message must not contain any hints that can help an attacker to guess if it's the password or the username that's wrong) * the user has no access to the system |

#### Log out as Client

The Log out as Client use case is discussed in the table below:

Table 12: Log out as Client use case

|  |  |
| --- | --- |
| **UC10** | Log out as Client |
| **Description:** | The user closes their current session and stops accessing the system. |
| **Actors:** | * Petroleum Developer * Commissioner * Petroleum Officer * Principal Petroleum Officer * Senior Petroleum Officer * User granted with the client user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | * Client (user with Client user group privileges) user requires to end their session |
| **Inputs:** | * none |
| **Preconditions:** | * The user is logged into the system |
| **Main Success scenario** | 1. User clicks the "Logout" button/link 2. The system closes the http session and forwards the user to the login page |
| **Alternative**  **Scenarios:** | * Users can although be logged out by a session timeout |
| **Success End**  **Condition:** | * The user is logged out |
| **Failed End**  **Condition:** | * The user is still logged in * An error message is displayed |
| **Failed End**  **Condition:** | * The user is still logged in * An error message is displayed |
: []Table 12: Log out as Client use case

![[]Figure 4: User Account Management Use Case
Model](data:image/png;base64,[encoded data, 167104 characters])

#### Create User Group

The Create User Group use case is discussed in the table below:

Table 13: Create User Group use case

|  |  |
| --- | --- |
| **UC7** | Create User Group |
| **Description:** | The system admin creates user group. After that the user group is ready to be assigned to users. |
| **Actors:** | * System administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system administrator requires to create a user group |
| **Inputs:** | Group Data:   * Group name (unique) -allowed characters: a-z, A-Z, 0-9 * Description -allowed characters: a-Z, A-Z, `, mutation characters, -, blank * Privileges and roles |
| **Preconditions:** | * The system administrator is logged into the system. |
| **Main Success scenario** | 1. The system admin clicks the "Add Group" link. 2. The system opens the "Add Group" form 3. The system admin enters the user group's data (name, description, privileges and roles) 4. The system admin selects the group's roles 5. The system admin assigns the roles to the group 6. The system admin clicks the 'create' button 7. The system validates the entered data 8. The system creates the user group |
| **Alternative**  **Scenarios:** | The system developer creates the user group |
| **Success End**  **Condition:** | * The user group is created. |
| **Failed End**  **Condition:** | * An error message is displayed * no user group was created |

#### Edit User Group

The Edit User Group use case is discussed in the table below:

Table 14: Edit User Group

|  |  |
| --- | --- |
| **UC8** | Edit User Group |
| **Description:** | The system admin updates the user group. |
| **Actors:** | * System administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system administrator requires to update user group . |
| **Inputs:** | Changed user group detail |
| **Preconditions:** | * The system administrator is logged into the system. * User account has been created |
| **Main Success scenario** | 1. The system admin searches the group in a list and clicks on it. 2. The system opens the group's detail page. 3. The system admin edits and provides the changed user group data. 4. The system admin saves the updated data by clicking the 'update' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the system admin back to the group list |
| **Success End**  **Condition:** | * The user group details are updated. |
| **Failed End**  **Condition:** | * An error message is displayed * The group�s details are not updated. |

#### Delete User Group

The Delete User Group use case is discussed in the table below:

Table 15: Delete User Group Use Case

|  |  |
| --- | --- |
| **UC9** | Delete User Group |
| **Description:** | The system admin deletes a user group.  Note that user groups are not deleted physically, but instead they' remarked as deleted (and invisible to all users) and their information is still available on the database level. |
| **Actors:** | * System administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system administrator wants User Group deleted |
| **Inputs:** | Group name of the group that shall be deleted |
| **Preconditions:** | * The user group as identified by the group name is available |
| **Main Success scenario** | 1. The system admin opens the group management menu 2. The system admin searches the group name in a list and clicks on it. 3. The system opens the group�s detail page. 4. The system admin clicks the ' delete group button. 5. The system must validate his decision (popup or something similar) 6. The system marks the group as being deleted.   Note that the group isn't deleted physically. Instead of that it's marked as deleted and no longer accessible and all user accounts that reference it default to the system�s set user group. |
| **Alternative**  **Scenarios:** | Only a system Administrator does this. |
| **Success End**  **Condition:** | * User group is deleted (logically). * The user group data is still stored in the system, but marked as deleted. |
| **Failed End**  **Condition:** | * An error message is displayed * The user group still exists and is left unchanged |

#### Create User Account

The Create User Account use case is discussed in the table below:

Table 16: Create User Account use case

|  |  |
| --- | --- |
| **UC10** | Create User Account |
| **Description:** | The system admin creates the user account. After that the user has access to the system (once they activate their account). |
| **Actors:** | * System administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system administrator requires to create a user |
| **Inputs:** | User Data:   * username (unique) -allowed characters: a-z, A-Z, 0-9 * real name (first name, surname) -allowed characters: a-Z, A-Z, , `, mutation characters, -, blank * email-address -allowed characters: a-z, A-Z, ., \_, -, 0-9, @ * roles � editor, author |
| **Preconditions:** | * The system administrator is logged into the system. |
| **Main Success scenario** | 1. The system admin clicks the "Add User" link. 2. The system opens the "Add user" form 3. The system admin enters the user's data (login, real name, email) 4. The system admin selects the user's roles 5. The system admin assigns the roles to the user 6. The system admin clicks the 'create' button 7. The system validates the entered data 8. The system creates the account   Note: The account has no password yet. The account is inactive until the password has been set by the new user. |
| **Alternative**  **Scenarios:** | The system developer creates the user account |
| **Success End**  **Condition:** | * The user account is created, but still inactive.   Typically, the system admin would now inform the user about the successfully created account and provide him/her with the username for the first login. This is out of the system's scope. |
| **Failed End**  **Condition:** | * An error message is displayed * no user account was created |

#### Edit User Account

The Edit User Account use case is discussed in the table below:

Table 17: Edit User Account Use Case

|  |  |
| --- | --- |
| **UC11** | Edit User Account |
| **Description:** | The system admin updates the user's credentials. |
| **Actors:** | * System administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system administrator requires to update his credentials. |
| **Inputs:** | Changed user credentials |
| **Preconditions:** | * The system administrator is logged into the system. * User account has been created |
| **Main Success scenario** | 1. The system admin searches the account in a list and clicks on it. 2. The system opens the account's detail page. 3. The system admin edits and provides the changed user account data. Note that the login (username) can't be changed and that the password can only be reset by the system administrator, but there's no way to set the password to a predefined string or have the password being visible to the system admin. 4. The system admin saves the updated data by clicking the 'update' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the system admin back to the user list |
| **Success End**  **Condition:** | * The user's credentials are updated. |
| **Failed End**  **Condition:** | * An error message is displayed * The user's credentials are not updated. |

#### Delete User Account

The Delete User Account use case is discussed in the table below:

Table 18: Delete User Account Use Case

|  |  |
| --- | --- |
| **UC12** | Delete User Account |
| **Description:** | The system admin deletes a user account.  Note that user accounts are not deleted physically, but instead they' remarked as deleted (and invisible to all users) and their information is still available on the database level. |
| **Actors:** | * System administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system administrator wants User account deleted |
| **Inputs:** | Username of the account that shall be deleted |
| **Preconditions:** | * The user account as identified by the login (username) is available (locked or unlocked) |
| **Main Success scenario** | 1. The system admin opens the account management page 2. The system admin searches the account in a list and clicks on it. 3. The system opens the account's detail page. 4. The system admin clicks the ' delete account ' button. 5. The system must validate his decision (popup or something similar) 6. The system marks the account as being deleted.   Note that the account isn't deleted physically. Instead of that it's marked as deleted and no longer accessible. There's no way to 'undelete' a user's account. |
| **Alternative**  **Scenarios:** | Only a system Administrator does this. |
| **Success End**  **Condition:** | * User account is deleted (logically). * The user account data is still stored in the system, but marked as deleted. |
| **Failed End**  **Condition:** | * An error message is displayed * The user account (locked or unlocked) still exists and is left unchanged |

#### Reset Password

The Reset Password use case is discussed in the table below:

Table 19: Reset Password Use Case

|  |  |
| --- | --- |
| **UC13** | Reset Password |
| **Description:** | A user can't access the system because he has forgotten his password.  The system admin resets the account's password and thus inactivates the account. The user has to activate the account again by setting his new password. |
| **Actors:** | * System administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | User wants access to the system again and informs the system admin about  the forgotten password |
| **Inputs:** | Trigger from the user that he has forgotten his password |
| **Preconditions:** | * User account has been created. * The system administrator has checked the user's identity. * The system admin is logged in. |
| **Main Success scenario** | 1. The system admin opens the account management page 2. The system admin searches the account in a list and clicks on it. 3. The system opens the account's detail page. 4. The system admin clicks the ' reset password' link/button. 5. The system inactivates the account and resets the Password   Note that in order to use the account again the user has to set his new password (see 'activate account'). |
| **Alternative**  **Scenarios:** | none |
| **Success End**  **Condition:** | * The user account is inactive and has no password set |
| **Failed End**  **Condition:** | * User can't log in unless he remembers his password * User has no access to the system * The user's account is still active |

#### Activate Account

The Activate account use case is discussed in the table below:

Table 20: Activate account Use Case

|  |  |
| --- | --- |
| **UC14** | Activate account |
| **Description:** | The user must activate his account before using it once. Activation is done by opening the account activation page - the URL is sent by the client's system administrator or on the mobile client- and providing a new password. |
| **Actors:** | * User |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The account's owner wants to activate his account (usually he gets informed by the system administrator) |
| **Inputs:** | The new password |
| **Preconditions:** | * The account has been created and is not locked, nor deleted. * The account is inactive.   Note that the user is not logged in when he activates his account. |
| **Main Success scenario** | 1. The account's owner opens the account activation page. 2. The account's owner provides his password (twice) and clicks the 'activate' button. 3. The system validates the passwords. 4. The system stores the password (encrypted) and activates the account. |
| **Alternative**  **Scenarios:** | none |
| **Success End**  **Condition:** | * The account is active * The password has been set |
| **Failed End**  **Condition:** | * If the user doesn't provide a valid password then the account is not being activated. An error message is shown. * If the account activation link is older than 7 days then an error message is displayed and the account can't be activated any more. The system administrator might decide to delete it. |
| **Failed End**  **Condition:** | * If the user doesn't provide a valid password then the account is not being activated. An error message is shown. * If the account activation link is older than 7 days then an error message is displayed and the account can't be activated any more. The system administrator might decide to delete it. |

### Workflow and Form Management Use Cases

The documented use case model depicted in Figure 5 **Error! Reference
source not found.**, features the workflow and form management use
cases. These do model respective units of functionality that encompass
the creation, retrieval, updating and deletion of workflows and forms
involved in the petroleum supply operations by the respective
authenticated system users. The microservice does meet a dual set of
functional requirements.

Forms management providing functionality for building forms that aid in
data collection from the field during petroleum supply operations as
well as information submitted by applicants and holders of operation
license and construction permits called clients or petroleum developers.

Workflow management providing the functionality for modelling or
designing workflows, for execution of tasks during permits and
licensing, volume storage and tracking, pricing, environmental
assessment, monitoring and inspection, compliance enforcement, labs and
quality assurance, LGP and standards processes.

The Workflow and Form Management Microservices does aggregate and
interfaces with other microservices as a gateway. This way, it provides
the ability for those microservices to extend its services when
providing parts of their functionality in executing processes during
petroleum supply operations.

All technical details for each use case are detailed in the preceding
sections in a tabular use case scenario type of activity workflow.

![[]Figure 5: Workflow and Form Management Use
Cases
Model](data:image/png;base64,[encoded data, 121696 characters])

#### Create Workflow

The Create Workflow use case is discussed in the table below:

Table 21: Create Workflow use case

|  |  |
| --- | --- |
| **UC15** | Create Workflow |
| **Description:** | A system user granted with a workflow-modeler user role requires to create a Workflow. |
| **Actors:** | * Designer/modeler * Administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | User granted with a workflow-modeler user role requires to create a Workflow. |
| **Inputs:** | Workflow Data:   * Click Create New Button * Model or design a Business Process Diagram (BPD) using Business Process Model and Notation (BPMN) in the model canvas. * Workflow name (unique) -allowed characters: a-z, A-Z, 0-9 * ID -allowed characters: a-Z, A-Z, `, mutation characters, -, blank * Workflow Tag Version -allowed characters: 0-9 * Element Documentation -allowed characters: a-z, A-Z, 0-9 * Execution Priority -allowed 0-9 * Click the Deploy Button * Click the Export Button |
| **Preconditions:** | * A user with a workflow-modeler user role is logged into the system. |
| **Main Success scenario** | 1. The system user granted with a workflow-modeler user role clicks the "Create New" button. 2. The system opens the "Create Workflow" Button 3. The system user granted with the workflow designer or modeler user role enters the Workflow data (BPD, name, ID, version Tag, element documentation and execution priority) 4. The system user granted with the workflow designer or modeler user role clicks the 'Deploy Workflow' button 5. The system validates the Business Process Diagram (BPD) using BPMN open standards entered workflow identifier textual data 6. The system creates and deploys the Workflow |
| **Alternative**  **Scenarios:** | The system developer pre-deploys workflows as part of the system or system user granted with the workflow designer or modeler user role uploads a pre-existing workflow file for the Workflow. |
| **Success End**  **Condition:** | * The Workflow is created and deployed. |
| **Failed End**  **Condition:** | * An error message is displayed * no Workflow was created |

#### Edit Workflow

The Edit Workflow use case is discussed in the table below:

Table 22: Edit Workflow

|  |  |
| --- | --- |
| **UC16** | Edit Workflow |
| **Description:** | The system user granted with the workflow designer or modeler user role requires to update a pre-existing Workflow. |
| **Actors:** | * System user granted with the workflow designer or modeler user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system user granted with the workflow designer or modeler user role requires to update Workflow. |
| **Inputs:** | Changed Workflow details |
| **Preconditions:** | * The system user granted with the workflow designer or modeler user role is logged into the system. * Workflow has been created |
| **Main Success scenario** | 1. The system user granted with the workflow designer or modeler user role searches the Workflow in a list and clicks on it. 2. The system opens the Workflow detail page. 3. The system user granted with the workflow designer or modeler user role edits and provides the changed Workflow BPD and metadata. 4. The system user granted with the workflow designer or modeler user role saves the updated data by clicking the 'update' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the system user back to the Workflow list |
| **Success End**  **Condition:** | * The Workflow BPD and metadata details are updated. |
| **Failed End**  **Condition:** | * An error message is displayed * The Workflow BPD and metadata are not updated. |

#### Delete Workflow

The Delete Workflow use case is discussed in the table below:

Table 23: Delete Workflow Use Case

|  |  |
| --- | --- |
| **UC17** | Delete Workflow |
| **Description:** | The system user granted with the workflow designer or modeler user role requires to delete a Workflow.  Note that Workflow are not deleted physically, but instead they' remarked as deleted (and invisible to all users) and their information is still available on the database level but all links to these resources are no longer functional. |
| **Actors:** | * System user granted with the workflow designer or modeler user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system user granted with the workflow designer or modeler user role requires to have a Workflow deleted |
| **Inputs:** | Workflow name that shall be deleted |
| **Preconditions:** | * The Workflow as identified by the Workflow name is available |
| **Main Success scenario** | 1. The system user granted with the workflow designer or modeler user role accesses the Workflow menu. 2. The system user granted with the workflow designer or modeler user role searches the Workflow name in a list and clicks on it. 3. The system opens the Workflow detail page. 4. The system user granted with the workflow designer or modeler user role clicks the delete Workflow button. 5. The system must validate his decision (popup or something similar) 6. The system marks the Workflow as being deleted.   Note that the Workflow isn't deleted physically. Instead of that it's marked as deleted and no longer accessible and all resources that reference it. |
| **Alternative**  **Scenarios:** | The system Administrator does the deletion from the backend or flags the workflow as deleted from within the database. |
| **Success End**  **Condition:** | * Workflow is deleted (logically). * The Workflow data is still stored in the system, but marked as deleted. |
| **Failed End**  **Condition:** | * An error message is displayed * The Workflow still exists and is left unchanged |

#### Create Form

The Create Form use case is discussed in the table below:

Table 24: Create Form use case

|  |  |
| --- | --- |
| **UC18** | Create Form |
| **Description:** | A system user granted with a designer-modeler user role requires to create a Form. |
| **Actors:** | * Designer/modeler * Administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | User granted with a designer-modeler user role requires to create a Form. |
| **Inputs:** | Form Data:   * Click Create Form Button * Form title (unique) -allowed characters: a-z, A-Z, 0-9 * Form name (unique) -allowed characters: a-z, A-Z, 0-9 * Form display type dropdown * Form path -allowed characters: a-z, A-Z, 0-9 * Execution Priority -allowed 0-9 * Form visibility checkbox * Build the form using the provided International Standard ISO/IEC 15445 html components in the form builder canvas. * Click Save and Preview Button * Click the Export Button |
| **Preconditions:** | * A user with a Form-modeler user role is logged into the system. |
| **Main Success scenario** | 1. The system user granted with a Form-modeler user role clicks the "Create Form" button. 2. The system opens the "Create Form" window 3. The system user granted with the Form designer or modeler user role enters the Form data (Form title, name, display type, path, visibility, ISO/IEC 15445 html components) 4. The system user granted with the Form designer or modeler user role clicks the 'Save and Preview' button 5. The system validates the forms components using ISO/IEC 15445 open standards and entered Form identifier textual metadata 6. The system creates and previews the Form |
| **Alternative**  **Scenarios:** | The system developer pre-deploys Forms as part of the system or system user granted with the Form designer or modeler user role uploads a pre-existing Form file for the Form. |
| **Success End**  **Condition:** | * The Form is created and previewed. |
| **Failed End**  **Condition:** | * An error message is displayed * no Form was created |

#### Edit Form

The Edit Form use case is discussed in the table below:

Table 25: Edit Form

|  |  |
| --- | --- |
| **UC19** | Edit Form |
| **Description:** | The system user granted with the Form designer or modeler user role requires to update a pre-existing Form. |
| **Actors:** | * System user granted with the Form designer or modeler user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system user granted with the Form designer or modeler user role requires to update Form. |
| **Inputs:** | Changed Form details |
| **Preconditions:** | * The system user granted with the Form designer or modeler user role is logged into the system. * Form has been created |
| **Main Success scenario** | 1. The system user granted with the Form designer or modeler user role searches the Form in a list and clicks on it. 2. The system opens the Form detail page. 3. The system user granted with the Form designer or modeler user role edits and provides the changed forms components using ISO/IEC 15445 open standards and entered form metadata. 4. The system user granted with the Form designer or modeler user role saves the updated data by clicking the 'update' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the system user back to the Form list |
| **Success End**  **Condition:** | * The Form�s ISO/IEC 15445 components and metadata details are updated. |
| **Failed End**  **Condition:** | * An error message is displayed * The Form�s ISO/IEC 15445 components and metadata are not updated. |

#### Delete Form

The Delete Form use case is discussed in the table below:

Table 26: Delete Form Use Case

|  |  |
| --- | --- |
| **UC20** | Delete Form |
| **Description:** | The system user granted with the Form designer or modeler user role requires to delete a Form.  Note that Form are not deleted physically, but instead they' remarked as deleted (and invisible to all users) and their information is still available on the database level but all links to these resources are no longer functional. |
| **Actors:** | * System user granted with the Form designer or modeler user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system user granted with the Form designer or modeler user role requires to have a Form deleted |
| **Inputs:** | Form name that shall be deleted |
| **Preconditions:** | * The Form as identified by the Form name is available |
| **Main Success scenario** | 1. The system user granted with the Form designer or modeler user role accesses the Form menu. 2. The system user granted with the Form designer or modeler user role searches the Form name in a list and clicks on it. 3. The system opens the Form detail page. 4. The system user granted with the Form designer or modeler user role clicks the delete Form button. 5. The system must validate his decision (popup or something similar) 6. The system marks the Form as being deleted.   Note that the Form isn't deleted physically. Instead of that it's marked as deleted and no longer accessible and all resources that reference it. |
| **Alternative**  **Scenarios:** | The system Administrator does the deletion from the backend or flags the Form as deleted from within the database. |
| **Success End**  **Condition:** | * Form is deleted (logically). * The Form data is still stored in the system, but marked as deleted. |
| **Failed End**  **Condition:** | * An error message is displayed * The Form still exists and is left unchanged |

#### Create Workflow-Form Association

The Create Workflow-Form Association use case is discussed in the table below:

Table 27: Create Workflow-Form Association use case

|  |  |
| --- | --- |
| **UC18** | Create Workflow-Form Association |
| **Description:** | A system user granted with a designer-modeler user role requires to create a Workflow-Form Association. |
| **Actors:** | * Designer/modeler * Administrator |
| **Trigger Type:** | Event triggered |
| **Trigger:** | User granted with a designer-modeler user role requires to create a Workflow-Form Association. |
| **Inputs:** | Workflow-Form Association Data:   * Click Create Workflow-Form Association Button * Workflow-Form Association title (unique) -allowed characters: a-z, A-Z, 0-9 * Workflow-Form Association name (unique) -allowed characters: a-z, A-Z, 0-9 * Workflow-Form Association display type dropdown * Workflow-Form Association path -allowed characters: a-z, A-Z, 0-9 * Execution Priority -allowed 0-9 * Workflow-Form Association visibility checkbox * Build the Workflow-Form Association using the provided International Standard ISO/IEC 15445 html components in the Workflow-Form Association builder canvas. * Click Save and Preview Button * Click the Export Button |
| **Preconditions:** | * A user with a Form-modeler user role is logged into the system. |
| **Main Success scenario** | 1. The system user granted with a Form-modeler user role clicks the "Create Workflow-Form Association" button. 2. The system opens the "Create Workflow-Form Association" window 3. The system user granted with the Form designer or modeler user role enters the Workflow-Form Association data (Workflow-Form Association title, name, display type, path, visibility, ISO/IEC 15445 html components) 4. The system user granted with the Form designer or modeler user role clicks the 'Save and Preview' button 5. The system validates the Workflow-Form Associations components using ISO/IEC 15445 open standards and entered Workflow-Form Association identifier textual metadata 6. The system creates and previews the Workflow-Form Association |
| **Alternative**  **Scenarios:** | The system developer pre-deploys Workflow-Form Associations as part of the system or system user granted with the Form designer or modeler user role uploads a pre-existing Form file for the Form. |
| **Success End**  **Condition:** | * The Workflow-Form Association is created and previewed. |
| **Failed End**  **Condition:** | * An error message is displayed * no Workflow-Form Association was created |

#### Edit Workflow-Form Association

The Edit Workflow-Form Association use case is discussed in the table below:

Table 28: Edit Workflow-Form Association

|  |  |
| --- | --- |
| **UC19** | Edit Workflow-Form Association |
| **Description:** | The system user granted with the Form designer or modeler user role requires to update a pre-existing Workflow-Form Association. |
| **Actors:** | * System user granted with the Form designer or modeler user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system user granted with the Form designer or modeler user role requires to update Workflow-Form Association. |
| **Inputs:** | Changed Workflow-Form Association details |
| **Preconditions:** | * The system user granted with the Form designer or modeler user role is logged into the system. * Workflow-Form Association has been created |
| **Main Success scenario** | 1. The system user granted with the Form designer or modeler user role searches the Workflow-Form Association in a list and clicks on it. 2. The system opens the Form detail page. 3. The system user granted with the Form designer or modeler user role edits and provides the changed Workflow-Form Associations components using ISO/IEC 15445 open standards and entered Workflow-Form Association metadata. 4. The system user granted with the Form designer or modeler user role saves the updated data by clicking the 'update' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the system user back to the Form list |
| **Success End**  **Condition:** | * The Workflow-Form Association�s ISO/IEC 15445 components and metadata details are updated. |
| **Failed End**  **Condition:** | * An error message is displayed * The Form�s ISO/IEC 15445 components and metadata are not updated. |

#### Delete Workflow-Form Association

The Delete Workflow-Form Association use case is discussed in the table below:

Table 29: Delete Workflow-Form Association Use Case

|  |  |
| --- | --- |
| **UC20** | Delete Workflow-Form Association |
| **Description:** | The system user granted with the Form designer or modeler user role requires to delete a Workflow-Form Association.  Note that Workflow-Form Association are not deleted physically, but instead they' remarked as deleted (and invisible to all users) and their information is still available on the database level but all links to these resources are no longer functional. |
| **Actors:** | * System user granted with the Form designer or modeler user role |
| **Trigger Type:** | Event triggered |
| **Trigger:** | The system user granted with the Form designer or modeler user role requires to have a Workflow-Form Association deleted |
| **Inputs:** | Workflow-Form Association name that shall be deleted |
| **Preconditions:** | * The Workflow-Form Association as identified by the Form name is available |
| **Main Success scenario** | 1. The system user granted with the Form designer or modeler user role accesses the Form menu. 2. The system user granted with the Form designer or modeler user role searches the Form name in a list and clicks on it. 3. The system opens the Form detail page. 4. The system user granted with the Form designer or modeler user role clicks the delete Form button. 5. The system must validate his decision (popup or something similar) 6. The system marks the Workflow-Form Association as being deleted.   Note that the Workflow-Form Association isn't deleted physically. Instead of that it's marked as deleted and no longer accessible and all resources that reference it. |
| **Alternative**  **Scenarios:** | The system Administrator does the deletion from the backend or flags the Workflow-Form Association as deleted from within the database. |
| **Success End**  **Condition:** | * Workflow-Form Association is deleted (logically). * The Workflow-Form Association data is still stored in the system, but marked as deleted. |
| **Failed End**  **Condition:** | * An error message is displayed * The Workflow-Form Association still exists and is left unchanged |

### 

### Petroleum Facility Construction Permit Use Cases

The documented use case models depicted in Figure 7, and Figure 8 do
collectively feature the Petroleum Facility Construction Permit use
cases. These model respective units of functionality that encompass the
management of petroleum facility construction permits information, from
permit application to management of existing permits.

The use case model for petroleum facility construction permit
application Figure 7 does model all use cases for executing workflow
tasks involved in petroleum supply operations regarding petroleum
facility construction permits application.

Unlike other use case models whose behaviour has so far been modelled as
tabular sequences, the petroleum facility construction permit
application use case model in Figure 7, models behaviour as a UML
standard 2.0 activity diagram.

This type of UML behavioural diagram helps to describe dynamic aspects
of the system that model the flow from one activity to another activity.
Further, this activity diagram will further be modelled as Business
Process Models using Business Process Model Notation (BPMN) for
execution in an enactment engine of a workflow management system.

![[]Figure 6: Petroleum Facility Construction
Permit Application Activity
Diagram](data:image/png;base64,[encoded data, 115212 characters])

![](data:image/png;base64,[encoded data, 163180 characters])

[]Figure 7: Petroleum Facility Construction
Permit Application Use Case Model

After executing a successful petroleum facility construction permits and
facility application workflow, software functionality for the creation,
retrieval, updating, deletion, renewal, suspension, revocation, and
termination of petroleum facility construction permits by the respective
authenticated system users is presented in the use case model. The
Petroleum Facility Construction Permit microservice does extent and
depend on both workflow and form data created during the execution of
Petroleum Facility Construction Permit workflows.

![[]Figure 8: Petroleum Facility Construction
Permit microservice Use
Cases](data:image/png;base64,[encoded data, 128728 characters])

#### Create Petroleum Facility Construction Permit

The Create Petroleum Facility Construction Permit use case is discussed in the table below:

Table 30: Create Petroleum Facility Construction Permit Use Case

|  |  |
| --- | --- |
| **UC21** | Create Petroleum Facility Construction Permit |
| **Description:** | A user granted with an approver user role requires to create Petroleum Facility Construction Permit. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application workflow, and user granted with an approver user role requires to create Petroleum Facility Construction Permit. |
| **Inputs:** | Petroleum Facility Construction Permit Application ID, Permit Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Facility Construction Permit Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Facility Construction Permit Application ID in a list and clicks on it. 2. The system opens the Petroleum Facility Construction Permit Application detail page. 3. User granted with an approver user role generates and awards Petroleum Facility Construction Permit Application with a permit serial number. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Facility Construction Permit Applications list |
| **Success End**  **Condition:** | * The Petroleum Facility Construction Permit Application is award with a permit serial number. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Facility Construction Permit Application is not award with a permit serial number. |

#### Update Petroleum Facility Construction Permit

The Update Petroleum Facility Construction Permit use case is discussed in the table below:

Table 31: Update Petroleum Facility Construction Permit Use Case

|  |  |
| --- | --- |
| **UC22** | Update Petroleum Facility Construction Permit |
| **Description:** | A user granted with an approver user role requires to Update Petroleum Facility Construction Permit. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application workflow, and user granted with an approver user role requires to Update Petroleum Facility Construction Permit. |
| **Inputs:** | Petroleum Facility Construction Permit Application ID, Permit Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Facility Construction Permit Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Facility Construction Permit Application ID in a list and clicks on it. 2. The system opens the Petroleum Facility Construction Permit Application detail page. 3. User granted with an approver user role generates and awards Petroleum Facility Construction Permit Application with a permit serial number. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Facility Construction Permit Applications list |
| **Success End**  **Condition:** | * The Petroleum Facility Construction Permit Application is updated with a permit serial number. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Facility Construction Permit Application is updated with a permit serial number. |

#### Renew Petroleum Facility Construction Permit

The Renew Petroleum Facility Construction Permit use case is discussed in the table below:

Table 32: Renew Petroleum Facility Construction Permit Use Case

|  |  |
| --- | --- |
| **UC23** | Renew Petroleum Facility Construction Permit |
| **Description:** | A user granted with an approver user role requires to Renew Petroleum Facility Construction Permit. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application workflow, and user granted with an approver user role requires to Renew Petroleum Facility Construction Permit. |
| **Inputs:** | Petroleum Facility Construction Permit Application ID, Permit Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Facility Construction Permit Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Facility Construction Permit Application ID in a list and clicks on it. 2. The system opens the Petroleum Facility Construction Permit Application detail page. 3. User granted with an approver user role edits status of Petroleum Facility Construction Permit Application as renewed. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Facility Construction Permit Applications list |
| **Success End**  **Condition:** | * The Petroleum Facility Construction Permit Application is updated with a permit renewed status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Facility Construction Permit Application is updated with a permit renewed status. |

#### Suspend Petroleum Facility Construction Permit

The Suspend Petroleum Facility Construction Permit use case is discussed in the table below:

Table 33: Suspend Petroleum Facility Construction Permit Use Case

|  |  |
| --- | --- |
| **UC22** | Suspend Petroleum Facility Construction Permit |
| **Description:** | A user granted with an approver user role requires to Suspend Petroleum Facility Construction Permit. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application workflow, and user granted with an approver user role requires to Suspend Petroleum Facility Construction Permit. |
| **Inputs:** | Petroleum Facility Construction Permit Application ID, Permit Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Facility Construction Permit Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Facility Construction Permit Application ID in a list and clicks on it. 2. The system opens the Petroleum Facility Construction Permit Application detail page. 3. User granted with an approver user role edits status of Petroleum Facility Construction Permit Application as suspended. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Facility Construction Permit Applications list |
| **Success End**  **Condition:** | * The Petroleum Facility Construction Permit Application is updated with a permit suspended status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Facility Construction Permit Application is updated with a permit suspended status. |

#### Revoke Petroleum Facility Construction Permit

The Revoke Petroleum Facility Construction Permit use case is discussed in the table below:

Table 34: Revoke Petroleum Facility Construction Permit Use Case

|  |  |
| --- | --- |
| **UC24** | Revoke Petroleum Facility Construction Permit |
| **Description:** | A user granted with an approver user role requires to Revoke Petroleum Facility Construction Permit. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application workflow, and user granted with an approver user role requires to Revoke Petroleum Facility Construction Permit. |
| **Inputs:** | Petroleum Facility Construction Permit Application ID, Permit Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Facility Construction Permit Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Facility Construction Permit Application ID in a list and clicks on it. 2. The system opens the Petroleum Facility Construction Permit Application detail page. 3. User granted with an approver user role edits status of Petroleum Facility Construction Permit Application as revoked. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Facility Construction Permit Applications list |
| **Success End**  **Condition:** | * The Petroleum Facility Construction Permit Application is updated with a permit revoked status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Facility Construction Permit Application is updated with a permit revoked status. |

#### Terminate Petroleum Facility Construction Permit

The Terminate Petroleum Facility Construction Permit use case is discussed in the table below:

Table 35: Terminate Petroleum Facility Construction Permit Use Case

|  |  |
| --- | --- |
| **UC25** | Terminate Petroleum Facility Construction Permit |
| **Description:** | A user granted with an approver user role requires to Terminate Petroleum Facility Construction Permit. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application workflow, and user granted with an approver user role requires to Terminate Petroleum Facility Construction Permit. |
| **Inputs:** | Petroleum Facility Construction Permit Application ID, Permit Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Facility Construction Permit Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Facility Construction Permit Application ID in a list and clicks on it. 2. The system opens the Petroleum Facility Construction Permit Application detail page. 3. User granted with an approver user role edits status of Petroleum Facility Construction Permit Application as terminated. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Facility Construction Permit Applications list |
| **Success End**  **Condition:** | * The Petroleum Facility Construction Permit Application is updated with a permit terminated status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Facility Construction Permit Application is updated with a permit terminated status. |

### 

### Petroleum Operating License Use Cases

The documented use case models depicted in Figure 7, and Figure 10 do
collectively feature the Petroleum Operating License use cases. These
model respective units of functionality that encompass the management of
petroleum operating license information, from Operating License
application to management of existing Operating Licenses.

The use case model for petroleum Operating License application Figure 11
does model all use cases for executing workflow tasks involved in
petroleum supply operations regarding petroleum operating license
application.

Unlike other use case models whose behaviour has so far been modelled as
tabular sequences, the petroleum operating license application use case
model in Figure 9, models behaviour as a UML standard 2.0 activity
diagram.

This type of UML behavioural diagram helps to describe dynamic aspects
of the system that model the flow from one activity to another activity.
Further, this activity diagram will further be modelled as Business
Process Models using Business Process Model Notation (BPMN) for
execution in an enactment engine of a workflow management system.

![[]Figure 9: Petroleum Operating License
Application Activity
Diagram](data:image/png;base64,[encoded data, 119304 characters])

![](data:image/png;base64,[encoded data, 155844 characters])

[]Figure 10: Petroleum Operating Application Use
Case Model

After executing a successful petroleum operating license application
workflow, software functionality for the creation, retrieval, updating,
deletion, renewal, suspension, revocation, and termination of petroleum
operating licenses by the respective authenticated system users is
presented in the use case model. The Petroleum Operating License
microservice does extent and depend on both workflow and form data
created during the execution of Petroleum Operating License workflows.

![[]Figure 11: Petroleum Operating License
microservice Use
Cases](data:image/png;base64,[encoded data, 127132 characters])

#### Create Petroleum Operating License

The Create Petroleum Operating License use case is discussed in the table below:

Table 36: Create Petroleum Operating License Use Case

|  |  |
| --- | --- |
| **UC26** | Create Petroleum Operating License |
| **Description:** | A user granted with an approver user role requires to create Petroleum Operating License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Operating License Application workflow, and user granted with an approver user role requires to create Petroleum Operating License. |
| **Inputs:** | Petroleum Operating License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Operating License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Operating License Application ID in a list and clicks on it. 2. The system opens the Petroleum Operating License Application detail page. 3. User granted with an approver user role generates and awards Petroleum Operating License Application with a license serial number. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Operating License Applications list |
| **Success End**  **Condition:** | * The Petroleum Operating License Application is award with a license serial number. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Operating License Application is not award with a license serial number. |

#### Update Petroleum Operating License

The Update Petroleum Operating License use case is discussed in the table below:

Table 37: Update Petroleum Operating License Use Case

|  |  |
| --- | --- |
| **UC27** | Update Petroleum Operating License |
| **Description:** | A user granted with an approver user role requires to Update Petroleum Operating License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Operating License Application workflow, and user granted with an approver user role requires to Update Petroleum Operating License. |
| **Inputs:** | Petroleum Operating License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Operating License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Operating License Application ID in a list and clicks on it. 2. The system opens the Petroleum Operating License Application detail page. 3. User granted with an approver user role generates and awards Petroleum Operating License Application with a license serial number. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Operating License Applications list |
| **Success End**  **Condition:** | * The Petroleum Operating License Application is updated with a license serial number. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Operating License Application is updated with a license serial number. |

#### Renew Petroleum Operating License

The Renew Petroleum Operating License use case is discussed in the table below:

Table 38: Renew Petroleum Operating License Use Case

|  |  |
| --- | --- |
| **UC28** | Renew Petroleum Operating License |
| **Description:** | A user granted with an approver user role requires to Renew Petroleum Operating License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Operating License Application workflow, and user granted with an approver user role requires to Renew Petroleum Operating License. |
| **Inputs:** | Petroleum Operating License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Operating License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Operating License Application ID in a list and clicks on it. 2. The system opens the Petroleum Operating License Application detail page. 3. User granted with an approver user role edits status of Petroleum Operating License Application as renewed. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Operating License Applications list |
| **Success End**  **Condition:** | * The Petroleum Operating License Application is updated with a license renewed status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Operating License Application is updated with a license renewed status. |

#### Suspend Petroleum Operating License

The Suspend Petroleum Operating License use case is discussed in the table below:

Table 39: Suspend Petroleum Operating License Use Case

|  |  |
| --- | --- |
| **UC29** | Suspend Petroleum Operating License |
| **Description:** | A user granted with an approver user role requires to Suspend Petroleum Operating License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Operating License Application workflow, and user granted with an approver user role requires to Suspend Petroleum Operating License. |
| **Inputs:** | Petroleum Operating License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Operating License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Operating License Application ID in a list and clicks on it. 2. The system opens the Petroleum Operating License Application detail page. 3. User granted with an approver user role edits status of Petroleum Operating License Application as suspended. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Operating License Applications list |
| **Success End**  **Condition:** | * The Petroleum Operating License Application is updated with a license suspended status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Operating License Application is updated with a license suspended status. |

#### Revoke Petroleum Operating License

The Revoke Petroleum Operating License use case is discussed in the table below:

Table 40: Revoke Petroleum Operating License Use Case

|  |  |
| --- | --- |
| **UC30** | Revoke Petroleum Operating License |
| **Description:** | A user granted with an approver user role requires to Revoke Petroleum Operating License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Operating License Application workflow, and user granted with an approver user role requires to Revoke Petroleum Operating License. |
| **Inputs:** | Petroleum Operating License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Operating License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Operating License Application ID in a list and clicks on it. 2. The system opens the Petroleum Operating License Application detail page. 3. User granted with an approver user role edits status of Petroleum Operating License Application as revoked. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Operating License Applications list |
| **Success End**  **Condition:** | * The Petroleum Operating License Application is updated with a license revoked status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Operating License Application is updated with a license revoked status. |

#### Terminate Petroleum Operating License

The Terminate Petroleum Operating License use case is discussed in the table below:

Table 41: Terminate Petroleum Operating License Use Case

|  |  |
| --- | --- |
| **UC31** | Terminate Petroleum Operating License |
| **Description:** | A user granted with an approver user role requires to Terminate Petroleum Operating License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Operating License Application workflow, and user granted with an approver user role requires to Terminate Petroleum Operating License. |
| **Inputs:** | Petroleum Operating License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Operating License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Operating License Application ID in a list and clicks on it. 2. The system opens the Petroleum Operating License Application detail page. 3. User granted with an approver user role edits status of Petroleum Operating License Application as terminated. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Operating License Applications list |
| **Success End**  **Condition:** | * The Petroleum Operating License Application is updated with a license terminated status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Operating License Application is updated with a license terminated status. |

### 

### Petroleum Transportation License Use Cases

The documented use case models depicted in Figure 7, and Figure 10 do
collectively feature the Petroleum Transportation License use cases.
These model respective units of functionality that encompass the
management of Petroleum Transportation License information, from
Operating License application to management of existing Operating
Licenses.

The use case model for Petroleum Transportation License application
Figure 11 does model all use cases for executing workflow tasks involved
in petroleum supply operations regarding Petroleum Transportation
License application.

Unlike other use case models whose behaviour has so far been modelled as
tabular sequences, the Petroleum Transportation License application use
case model in Figure 9, models behaviour as a UML standard 2.0 activity
diagram.

This type of UML behavioural diagram helps to describe dynamic aspects
of the system that model the flow from one activity to another activity.
Further, this activity diagram will further be modelled as Business
Process Models using Business Process Model Notation (BPMN) for
execution in an enactment engine of a workflow management system.

![[]Figure 12: Petroleum Transportation License
Application Activity
Diagram](data:image/png;base64,[encoded data, 122016 characters])

![](data:image/png;base64,[encoded data, 156912 characters])

[]Figure 13: Petroleum Operating Application Use
Case Model

After executing a successful Petroleum Transportation License
application workflow, software functionality for the creation,
retrieval, updating, deletion, renewal, suspension, revocation, and
termination of petroleum operating licenses by the respective
authenticated system users is presented in the use case model. The
Petroleum Transportation License microservice does extent and depend on
both workflow and form data created during the execution of Petroleum
Transportation License workflows.

![[]Figure 14: Petroleum Transportation License
microservice Use
Cases](data:image/png;base64,[encoded data, 163668 characters])

#### Create Petroleum Transportation License

The Create Petroleum Transportation License use case is discussed in the table below:

Table 42: Create Petroleum Transportation License Use Case

|  |  |
| --- | --- |
| **UC26** | Create Petroleum Transportation License |
| **Description:** | A user granted with an approver user role requires to create Petroleum Transportation License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Transportation License Application workflow, and user granted with an approver user role requires to create Petroleum Transportation License. |
| **Inputs:** | Petroleum Transportation License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Transportation License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Transportation License Application ID in a list and clicks on it. 2. The system opens the Petroleum Transportation License Application detail page. 3. User granted with an approver user role generates and awards Petroleum Transportation License Application with a license serial number. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Transportation License Applications list |
| **Success End**  **Condition:** | * The Petroleum Transportation License Application is award with a license serial number. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Transportation License Application is not award with a license serial number. |

#### Update Petroleum Transportation License

The Update Petroleum Transportation License use case is discussed in the table below:

Table 43: Update Petroleum Transportation License Use Case

|  |  |
| --- | --- |
| **UC27** | Update Petroleum Transportation License |
| **Description:** | A user granted with an approver user role requires to Update Petroleum Transportation License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Transportation License Application workflow, and user granted with an approver user role requires to Update Petroleum Transportation License. |
| **Inputs:** | Petroleum Transportation License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Transportation License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Transportation License Application ID in a list and clicks on it. 2. The system opens the Petroleum Transportation License Application detail page. 3. User granted with an approver user role generates and awards Petroleum Transportation License Application with a license serial number. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Transportation License Applications list |
| **Success End**  **Condition:** | * The Petroleum Transportation License Application is updated with a license serial number. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Transportation License Application is updated with a license serial number. |

#### Renew Petroleum Transportation License

The Renew Petroleum Transportation License use case is discussed in the table below:

Table 44: Renew Petroleum Transportation License Use Case

|  |  |
| --- | --- |
| **UC28** | Renew Petroleum Transportation License |
| **Description:** | A user granted with an approver user role requires to Renew Petroleum Transportation License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Transportation License Application workflow, and user granted with an approver user role requires to Renew Petroleum Transportation License. |
| **Inputs:** | Petroleum Transportation License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Transportation License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Transportation License Application ID in a list and clicks on it. 2. The system opens the Petroleum Transportation License Application detail page. 3. User granted with an approver user role edits status of Petroleum Transportation License Application as renewed. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Transportation License Applications list |
| **Success End**  **Condition:** | * The Petroleum Transportation License Application is updated with a license renewed status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Transportation License Application is updated with a license renewed status. |

#### Suspend Petroleum Transportation License

The Suspend Petroleum Transportation License use case is discussed in the table below:

Table 45: Suspend Petroleum Transportation License Use Case

|  |  |
| --- | --- |
| **UC29** | Suspend Petroleum Transportation License |
| **Description:** | A user granted with an approver user role requires to Suspend Petroleum Transportation License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Transportation License Application workflow, and user granted with an approver user role requires to Suspend Petroleum Transportation License. |
| **Inputs:** | Petroleum Transportation License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Transportation License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Transportation License Application ID in a list and clicks on it. 2. The system opens the Petroleum Transportation License Application detail page. 3. User granted with an approver user role edits status of Petroleum Transportation License Application as suspended. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Transportation License Applications list |
| **Success End**  **Condition:** | * The Petroleum Transportation License Application is updated with a license suspended status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Transportation License Application is updated with a license suspended status. |

#### Revoke Petroleum Transportation License

The Revoke Petroleum Transportation License use case is discussed in the table below:

Table 46: Revoke Petroleum Transportation License Use Case

|  |  |
| --- | --- |
| **UC30** | Revoke Petroleum Transportation License |
| **Description:** | A user granted with an approver user role requires to Revoke Petroleum Transportation License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Transportation License Application workflow, and user granted with an approver user role requires to Revoke Petroleum Transportation License. |
| **Inputs:** | Petroleum Transportation License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Transportation License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Transportation License Application ID in a list and clicks on it. 2. The system opens the Petroleum Transportation License Application detail page. 3. User granted with an approver user role edits status of Petroleum Transportation License Application as revoked. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Transportation License Applications list |
| **Success End**  **Condition:** | * The Petroleum Transportation License Application is updated with a license revoked status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Transportation License Application is updated with a license revoked status. |

#### Terminate Petroleum Transportation License

The Terminate Petroleum Transportation License use case is discussed in the table below:

Table 47: Terminate Petroleum Transportation License Use Case

|  |  |
| --- | --- |
| **UC31** | Terminate Petroleum Transportation License |
| **Description:** | A user granted with an approver user role requires to Terminate Petroleum Transportation License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Transportation License Application workflow, and user granted with an approver user role requires to Terminate Petroleum Transportation License. |
| **Inputs:** | Petroleum Transportation License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Transportation License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Transportation License Application ID in a list and clicks on it. 2. The system opens the Petroleum Transportation License Application detail page. 3. User granted with an approver user role edits status of Petroleum Transportation License Application as terminated. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Transportation License Applications list |
| **Success End**  **Condition:** | * The Petroleum Transportation License Application is updated with a license terminated status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Transportation License Application is updated with a license terminated status. |

: []Table 47: Terminate Petroleum Transportation
License Use Case

### 

### Petroleum Storage License Use Cases

The documented use case models depicted in Figure 7, and Figure 10 do
collectively feature the Petroleum Storage License use cases. These
model respective units of functionality that encompass the management of
Petroleum Storage License information, from Operating License
application to management of existing Operating Licenses.

The use case model for Petroleum Storage License application Figure 11
does model all use cases for executing workflow tasks involved in
petroleum supply operations regarding Petroleum Storage License
application.

Unlike other use case models whose behaviour has so far been modelled as
tabular sequences, the Petroleum Storage License application use case
model in Figure 9, models behaviour as a UML standard 2.0 activity
diagram.

This type of UML behavioural diagram helps to describe dynamic aspects
of the system that model the flow from one activity to another activity.
Further, this activity diagram will further be modelled as Business
Process Models using Business Process Model Notation (BPMN) for
execution in an enactment engine of a workflow management system.

![[]Figure 15: Petroleum Storage License
Application Activity
Diagram](data:image/png;base64,[encoded data, 121420 characters])

![](data:image/png;base64,[encoded data, 153292 characters])

[]Figure 16: Petroleum Operating Application Use
Case Model

After executing a successful Petroleum Storage License application
workflow, software functionality for the creation, retrieval, updating,
deletion, renewal, suspension, revocation, and termination of petroleum
operating licenses by the respective authenticated system users is
presented in the use case model. The Petroleum Storage License
microservice does extent and depend on both workflow and form data
created during the execution of Petroleum Storage License workflows.

![[]Figure 17: Petroleum Storage License
microservice Use
Cases](data:image/png;base64,[encoded data, 161100 characters])


#### Create Petroleum Storage License

The Create Petroleum Storage License use case is discussed in the table below:

Table 48: Create Petroleum Storage License Use Case

|  |  |
| --- | --- |
| **UC26** | Create Petroleum Storage License |
| **Description:** | A user granted with an approver user role requires to create Petroleum Storage License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Storage License Application workflow, and user granted with an approver user role requires to create Petroleum Storage License. |
| **Inputs:** | Petroleum Storage License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Storage License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Storage License Application ID in a list and clicks on it. 2. The system opens the Petroleum Storage License Application detail page. 3. User granted with an approver user role generates and awards Petroleum Storage License Application with a license serial number. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Storage License Applications list |
| **Success End**  **Condition:** | * The Petroleum Storage License Application is award with a license serial number. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Storage License Application is not award with a license serial number. |

#### Update Petroleum Storage License

The Update Petroleum Storage License use case is discussed in the table below:

Table 49: Update Petroleum Storage License Use Case

|  |  |
| --- | --- |
| **UC27** | Update Petroleum Storage License |
| **Description:** | A user granted with an approver user role requires to Update Petroleum Storage License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Storage License Application workflow, and user granted with an approver user role requires to Update Petroleum Storage License. |
| **Inputs:** | Petroleum Storage License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Storage License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Storage License Application ID in a list and clicks on it. 2. The system opens the Petroleum Storage License Application detail page. 3. User granted with an approver user role generates and awards Petroleum Storage License Application with a license serial number. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Storage License Applications list |
| **Success End**  **Condition:** | * The Petroleum Storage License Application is updated with a license serial number. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Storage License Application is updated with a license serial number. |

#### Renew Petroleum Storage License

The Renew Petroleum Storage License use case is discussed in the table below:

Table 50: Renew Petroleum Storage License Use Case

|  |  |
| --- | --- |
| **UC28** | Renew Petroleum Storage License |
| **Description:** | A user granted with an approver user role requires to Renew Petroleum Storage License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Storage License Application workflow, and user granted with an approver user role requires to Renew Petroleum Storage License. |
| **Inputs:** | Petroleum Storage License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Storage License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Storage License Application ID in a list and clicks on it. 2. The system opens the Petroleum Storage License Application detail page. 3. User granted with an approver user role edits status of Petroleum Storage License Application as renewed. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Storage License Applications list |
| **Success End**  **Condition:** | * The Petroleum Storage License Application is updated with a license renewed status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Storage License Application is updated with a license renewed status. |

#### Suspend Petroleum Storage License

The Suspend Petroleum Storage License use case is discussed in the table below:

Table 51: Suspend Petroleum Storage License Use Case

|  |  |
| --- | --- |
| **UC29** | Suspend Petroleum Storage License |
| **Description:** | A user granted with an approver user role requires to Suspend Petroleum Storage License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Storage License Application workflow, and user granted with an approver user role requires to Suspend Petroleum Storage License. |
| **Inputs:** | Petroleum Storage License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Storage License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Storage License Application ID in a list and clicks on it. 2. The system opens the Petroleum Storage License Application detail page. 3. User granted with an approver user role edits status of Petroleum Storage License Application as suspended. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Storage License Applications list |
| **Success End**  **Condition:** | * The Petroleum Storage License Application is updated with a license suspended status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Storage License Application is updated with a license suspended status. |

#### Revoke Petroleum Storage License

The Revoke Petroleum Storage License use case is discussed in the table below:

Table 52: Revoke Petroleum Storage License Use Case

|  |  |
| --- | --- |
| **UC30** | Revoke Petroleum Storage License |
| **Description:** | A user granted with an approver user role requires to Revoke Petroleum Storage License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Storage License Application workflow, and user granted with an approver user role requires to Revoke Petroleum Storage License. |
| **Inputs:** | Petroleum Storage License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Storage License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Storage License Application ID in a list and clicks on it. 2. The system opens the Petroleum Storage License Application detail page. 3. User granted with an approver user role edits status of Petroleum Storage License Application as revoked. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Storage License Applications list |
| **Success End**  **Condition:** | * The Petroleum Storage License Application is updated with a license revoked status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Storage License Application is updated with a license revoked status. |

#### Terminate Petroleum Storage License

The Terminate Petroleum Storage License use case is discussed in the table below:

Table 53: Terminate Petroleum Storage License Use Case

|  |  |
| --- | --- |
| **UC31** | Terminate Petroleum Storage License |
| **Description:** | A user granted with an approver user role requires to Terminate Petroleum Storage License. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Storage License Application workflow, and user granted with an approver user role requires to Terminate Petroleum Storage License. |
| **Inputs:** | Petroleum Storage License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum Storage License Application workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Storage License Application ID in a list and clicks on it. 2. The system opens the Petroleum Storage License Application detail page. 3. User granted with an approver user role edits status of Petroleum Storage License Application as terminated. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | Clicking the cancel button returns the user back to the Petroleum Storage License Applications list |
| **Success End**  **Condition:** | * The Petroleum Storage License Application is updated with a license terminated status. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Storage License Application is updated with a license terminated status. |

: []Table 53: Terminate Petroleum Storage
License Use Case

### 

### Petroleum Monitoring and Enforcement Use Cases

The documented use case models depicted in Figure 7, and Figure 10 do
collectively feature the Petroleum Monitoring and Enforcement use cases.
These model respective units of functionality that encompass the
management of Petroleum Monitoring and Enforcement information, from
carrying out monitoring to taking enforcement actions on monitored
stations.

The use case model for Petroleum Monitoring and Enforcement application
Figure 11 does model all use cases for executing workflow tasks involved
in petroleum supply operations regarding Petroleum Monitoring and
Enforcement application.

Unlike other use case models whose behaviour has so far been modelled as
tabular sequences, the Petroleum Monitoring and Enforcement application
use case model in Figure 9, models behaviour as a UML standard 2.0
activity diagram.

This type of UML behavioural diagram helps to describe dynamic aspects
of the system that model the flow from one activity to another activity.
Further, this activity diagram will further be modelled as Business
Process Models using Business Process Model Notation (BPMN) for
execution in an enactment engine of a workflow management system.

![[]Figure 18: Petroleum Monitoring and
Enforcement Application Activity
Diagram](data:image/png;base64,[encoded data, 65484 characters])

![](data:image/png;base64,[encoded data, 87132 characters])

[]Figure 19: Petroleum Monitoring Use Case Model

After executing a successful Petroleum Monitoring and Enforcement
application workflow, software functionality for the creation,
retrieval, updating, deletion, renewal, suspension, revocation, and
termination of petroleum operating licenses by the respective
authenticated system users is presented in the use case model. The
Petroleum Monitoring and Enforcement microservice does extent and depend
on both workflow and form data created during the execution of Petroleum
Monitoring and Enforcement workflows.

![[]Figure 20: Petroleum Monitoring and
Enforcement microservice Use
Cases](data:image/png;base64,[encoded data, 65336 characters])

#### Activate Enforcement Action

The Activate Enforcement Action use case is discussed in the table below:

Table 54: Activate Enforcement Action Use Case

|  |  |
| --- | --- |
| **UC32** | Activate Enforcement Action |
| **Description:** | A user granted with an approver user role requires to Activate Enforcement Action on monitored stations. |
| **Actors:** | User granted with an approver user role:   * Commissioner * Assistant Commissioner |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Monitoring workflow, and user granted with an approver user role requires to Activate Enforcement Action. |
| **Inputs:** | Petroleum Storage License Application ID, License Serial Number |
| **Preconditions:** | * User granted with an approver user role is logged into the system. * Petroleum monitoring workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with an approver user role searches Petroleum Monitored Station ID in a list and clicks on it. 2. The system opens the Petroleum Monitored Station detail page. 3. User granted with an approver user role activates enforcement for action status. 4. User granted with an approver user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Monitored Stations list |
| **Success End**  **Condition:** | * The Petroleum Monitored Stations is changed with the enforcement for action flag. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Monitored Stations is not changed with the enforcement for action flag. |

#### Capture Enforcement Information

The Capture Enforcement Information use case is discussed in the table below:

Table 55: Capture Enforcement Information Use Case

|  |  |
| --- | --- |
| **UC33** | Capture Enforcement Information |
| **Description:** | A user granted with an approver user role requires to Capture Enforcement Information on monitored stations. |
| **Actors:** | User granted with a client user role:   * Petroleum Officer (Monitoring and Enforcement) * Senior Petroleum Officer (Monitoring and Enforcement) |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Monitoring workflow, and user granted with a client user role requires to Capture Enforcement Information. |
| **Inputs:** | Petroleum enforcement data |
| **Preconditions:** | * User granted with a client user role is logged into the system. * Petroleum monitoring workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with a client user role searches Petroleum Monitored Station ID in a list and clicks on it. 2. The system opens the Petroleum Monitored Station detail page. 3. User granted with a client user role enters gathered enforcement data in a standard enforcement form. 4. User granted with a client user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Monitored Stations list |
| **Success End**  **Condition:** | * The Petroleum Monitored Station�s enforcement data is captured. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Monitored Stations enforcement data is not captured. |

#### File and Review Enforcement Report

The File and Review Enforcement Report use case is discussed in the table below:

Table 56: File and Review Enforcement Report Use Case

|  |  |
| --- | --- |
| **UC34** | File and Review Enforcement Report |
| **Description:** | A user granted with a reviewer user role requires to File and Review Enforcement Report on monitored stations. |
| **Actors:** | User granted with a client user role:   * Principle Petroleum Officer (Monitoring and Enforcement) * Senior Petroleum Officer (Monitoring and Enforcement) |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Monitoring workflow, and user granted with a reviewer user role requires to File and Review Enforcement Report. |
| **Inputs:** | Petroleum enforcement data |
| **Preconditions:** | * User granted with a reviewer user role is logged into the system. * Petroleum monitoring workflow must have been created and completed |
| **Main Success scenario** | 1. User granted with a reviewer user role clicks the �Generate Enforcement Report� from captured enforcement information. 2. User granted with a reviewer user role previews generated Enforcement Report. 3. User granted with a reviewer user role saves the Reviewed Enforcement Report by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Monitored Stations list |
| **Success End**  **Condition:** | * The Petroleum Enforcement Report is Generated and Reviewed. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Enforcement Report is not Generated and Reviewed. |

### 

### Petroleum Standards Use Cases

The documented use case model depicted in Figure 21 does feature the
Petroleum standards use cases. These model respective units of
functionality that encompass the management of Petroleum standards
information. These include the creation, retrieval, purchase and
commenting on petroleum and petroleum facility standards by system users
granted with a reviewer role and client roles respectively.

![[]Figure 21: Petroleum Standards microservice
Use
Cases](data:image/png;base64,[encoded data, 70028 characters])

#### Create Petroleum Standards Catalogue

The Create Petroleum Standards Catalogue use case is discussed in the table below:

Table 57: Create Petroleum Standards Catalogue Use Case

|  |  |
| --- | --- |
| **UC36** | Create Petroleum Standards Catalogue |
| **Description:** | A user granted with a reviewer user role requires to Create Petroleum Standards Catalogue on monitored stations. |
| **Actors:** | User granted with a reviewer user role:   * Petroleum Officer (Standards) * Senior Petroleum Officer (Standards) |
| **Trigger Type:** | Event triggered |
| **Trigger:** | User granted with a reviewer user role requires to Create Petroleum Standards Catalogue. |
| **Inputs:** | Petroleum Standards Catalogue data |
| **Preconditions:** | * User granted with a reviewer user role is logged into the system. |
| **Main Success scenario** | 1. User granted with a reviewer user role enters Standards Catalogue data. 2. User granted with a reviewer user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Standards Catalogue list |
| **Success End**  **Condition:** | * The Petroleum Standards Catalogue data is captured. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Standards Catalogue data is not captured. |

#### Purchase Petroleum Standards

The Purchase Petroleum Standards use case is discussed in the table below:

Table 58: Purchase Petroleum Standards Use Case

|  |  |
| --- | --- |
| **UC35** | Purchase Petroleum Standards |
| **Description:** | A user granted with a client user role requires to Purchase Petroleum Standards. |
| **Actors:** | User granted with a reviewer user role:   * Petroleum Developer |
| **Trigger Type:** | Event triggered |
| **Trigger:** | User granted with a client user role requires to Purchase Petroleum Standards. |
| **Inputs:** | Petroleum Standards Catalogue data |
| **Preconditions:** | * User granted with a client user role is logged into the system. |
| **Main Success scenario** | 1. User granted with a client user role selects the petroleum Standards. 2. User granted with a client user role clicks the �Buy Button�. 3. User granted with a client user role proceeds to checkout with available payment options. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum Standards Catalogue list |
| **Success End**  **Condition:** | * The Petroleum Standards is purchased with payment confirmation. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Standards is not purchased. |

### 

### Petroleum Environment Assessment and Review Use Cases

The documented use case model depicted in Figure 21 does feature the
Petroleum Environment Assessment and Review use cases. These model
respective units of functionality that encompass the management of
Petroleum environment assessment and review information. These include
the creation, retrieval, review and approval of petroleum environmental
social impact and assessment by system users granted with a reviewer
role and approver roles respectively.

![[]Figure 22: Petroleum Environment Assessment
and Review microservice Use
Cases](data:image/png;base64,[encoded data, 58020 characters])

#### Submit Environmental Social Impact Assessment Report

The Submit Environmental Social Impact Assessment Report use case is discussed in the table below:

Table 59: Submit Environmental Social Impact Assessment Report Use Case

|  |  |
| --- | --- |
| **UC37** | Submit Environmental Social Impact Assessment Report |
| **Description:** | A user granted with a reviewer user role requires to Submit Environmental Social Impact Assessment Report on license applications. |
| **Actors:** | User granted with a reviewer user role:   * Petroleum Officer (Environment) * Senior Petroleum Officer (Environment) |
| **Trigger Type:** | Event triggered |
| **Trigger:** | User granted with a reviewer user role requires to Submit Environmental Social Impact Assessment Report. |
| **Inputs:** | Petroleum Environmental Social Impact Assessment Report document |
| **Preconditions:** | * User granted with a reviewer user role is logged into the system. |
| **Main Success scenario** | 1. User granted with a reviewer user role select license applications and click the submit �Environmental Social Impact Assessment Report� button. 2. User granted with a reviewer user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum license applications list |
| **Success End**  **Condition:** | * The Petroleum Environmental Social Impact Assessment Report is submitted. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Environmental Social Impact Assessment Report is not submitted. |

#### File ESIA Review Report

The File ESIA Review Report use case is discussed in the table below:

Table 60: File ESIA Review Report Use Case

|  |  |
| --- | --- |
| **UC38** | File ESIA Review Report |
| **Description:** | A user granted with a reviewer user role requires to File ESIA Review Report on license applications. |
| **Actors:** | User granted with a reviewer user role:   * Petroleum Officer (Environment) * Senior Petroleum Officer (Environment) |
| **Trigger Type:** | Event triggered |
| **Trigger:** | User granted with a reviewer user role requires to File ESIA Review Report. |
| **Inputs:** | Petroleum Environmental Social Impact Assessment Report document |
| **Preconditions:** | * User granted with a reviewer user role is logged into the system. |
| **Main Success scenario** | 1. User granted with a reviewer user role select license applications and click the submit �ESIA Review Report� button. 2. User granted with a reviewer user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button returns the user back to the Petroleum license applications list |
| **Success End**  **Condition:** | * The Petroleum ESIA Review Report is submitted. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum ESIA Review Report is not submitted. |

: []Table 60: File ESIA Review Report Use Case

### 

### Petroleum Imports Prices and Stocks Use Cases

The documented use case model depicted in Figure 21 does feature the
Petroleum Imports Prices and Stocks use cases. These model respective
units of functionality that encompass the management of Petroleum
imports, prices and stocks information. These include the capturing and
retrieval of petroleum imports, local, regional and international prices
and company opening and closing stocks information by system users
granted with a reviewer role and client roles respectively.

![[]Figure 23: Petroleum Imports Prices and
Stocks microservice Use
Cases](data:image/png;base64,[encoded data, 83136 characters])

#### Capture Local Pump Prices

The Capture Local Pump Prices use case is discussed in the table below:

Table 55: Capture Local Pump Prices Use Case

|  |  |
| --- | --- |
| **UC34** | Capture Local Pump Prices |
| **Description:** | A user granted with a client user role requires to Capture Local Pump Prices at petroleum facility or stations. |
| **Actors:** | User granted with a client user role:   * Petroleum developer |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application and Petroleum Operating Licensing Application workflows, and user granted with a client user role requires to Capture Local Pump Prices. |
| **Inputs:** | Petroleum Local Pump Prices data |
| **Preconditions:** | * User granted with a client user role is logged into the system. * Petroleum Facility Construction Permit Application and Petroleum Operating Licensing Application workflows must have been created and completed |
| **Main Success scenario** | 1. User granted with a client user role clicks the add Local Pump Prices button. 2. The system opens the Petroleum Local Pump Prices data entry form. 3. User granted with a client user role enters Local Pump Prices data into and gets validated. 4. User granted with a client user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button discards entered Local Pump Prices data |
| **Success End**  **Condition:** | * The Petroleum Local Pump Prices data is captured. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Local Pump Prices data is not captured. |

#### Capture Opening and Closing Stocks

The Capture Opening and Closing Stocks use case is discussed in the table below:

Table 55: Capture Opening and Closing Stocks Use Case

|  |  |
| --- | --- |
| **UC35** | Capture Opening and Closing Stocks |
| **Description:** | A user granted with a client user role requires to Capture Opening and Closing Stocks at petroleum facility or stations. |
| **Actors:** | User granted with a client user role:   * Petroleum developer |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application and Petroleum Operating Licensing Application workflows, and user granted with a client user role requires to Capture Opening and Closing Stocks. |
| **Inputs:** | Petroleum Opening and Closing Stocks data |
| **Preconditions:** | * User granted with a client user role is logged into the system. * Petroleum Facility Construction Permit Application and Petroleum Operating Licensing Application workflows must have been created and completed |
| **Main Success scenario** | 1. User granted with a client user role clicks the add Opening and Closing Stocks button. 2. The system opens the Petroleum Opening and Closing Stocks data entry form. 3. User granted with a client user role enters Opening and Closing Stocks data into and gets validated. 4. User granted with a client user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button discards entered Opening and Closing Stocks data |
| **Success End**  **Condition:** | * The Petroleum Opening and Closing Stocks data is captured. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum Opening and Closing Stocks data is not captured. |

#### Capture LPG Kits Data

The Capture LPG Kits Data use case is discussed in the table below:

Table 55: Capture LPG Kits Data Use Case

|  |  |
| --- | --- |
| **UC36** | Capture LPG Kits Data |
| **Description:** | A user granted with a client user role requires to Capture LPG Kits Data at petroleum facility or stations. |
| **Actors:** | User granted with a client user role:   * Petroleum developer |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application and Petroleum Operating Licensing Application workflows, and user granted with a client user role requires to Capture LPG Kits Data. |
| **Inputs:** | Petroleum Opening and Closing Stocks data |
| **Preconditions:** | * User granted with a client user role is logged into the system. * Petroleum Facility Construction Permit Application and Petroleum Operating Licensing Application workflows must have been created and completed |
| **Main Success scenario** | 1. User granted with a client user role clicks the add LPG Kits Data button. 2. The system opens the LPG Kits Data entry form. 3. User granted with a client user role enters LPG Kits Data into and gets validated. 4. User granted with a client user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button discards entered LPG Kits Data |
| **Success End**  **Condition:** | * The LPG Kits Data is captured. |
| **Failed End**  **Condition:** | * An error message is displayed * The LPG Kits Data is not captured. |

#### Capture International and Regional Prices

The Capture International and Regional Prices use case is discussed in the table below:

Table 55: Capture International and Regional Prices Use Case

|  |  |
| --- | --- |
| **UC34** | Capture International and Regional Prices |
| **Description:** | A user granted with a client user role requires to Capture International and Regional Prices at petroleum facility or stations. |
| **Actors:** | User granted with a client user role:   * Petroleum officer |
| **Trigger Type:** | Event triggered |
| **Trigger:** | Successful execution of a Petroleum Facility Construction Permit Application and Petroleum Operating Licensing Application workflows, and user granted with a client user role requires to Capture International and Regional Prices. |
| **Inputs:** | Petroleum International and Regional Prices data |
| **Preconditions:** | * User granted with a client user role is logged into the system. * Petroleum Facility Construction Permit Application and Petroleum Operating Licensing Application workflows must have been created and completed |
| **Main Success scenario** | 1. User granted with a client user role clicks the add International and Regional Prices button. 2. The system opens the Petroleum International and Regional Prices data entry form. 3. User granted with a client user role enters International and Regional Prices data into and gets validated. 4. User granted with a client user role saves the data by clicking the 'Save' button. |
| **Alternative**  **Scenarios:** | clicking the cancel button discards entered International and Regional Prices data |
| **Success End**  **Condition:** | * The Petroleum International and Regional Prices data is captured. |
| **Failed End**  **Condition:** | * An error message is displayed * The Petroleum International and Regional Prices data is not captured. |

## Non-Functional Requirements

The requirements in this section do discuss the specification for user
interaction with the software and measurements placed on the system
performance like: reliability, availability, security and
maintainability of the software system.

### Performance Requirements

Given the system stores raw geospatial data, including satellite
imagery, nation-wide cadastral maps and land parcels, with requirement
for hardware accelerated to read, write, render and geoprocessing, the
response-time for the system should be minimized using industry
recommended practices. All other performance related to storage, memory,
and processing should follow industry recommended practices to ensure
resource requirements are minimized.

### Reliability Requirements

There are no requirements for Mean Time between Failures (MTBF) or Mean
Time to Failures (MTTF) for the software system defined in this SRS.
However, in accordance with industry recommended practices, the software
system should undergo feature testing, load testing, and regression
testing prior to release and/or deployment.

### Availability Requirements

Being an online system with availability envisioned as anywhere and
anytime, the National Petroleum Information System, with reasonable
efforts should be made to ensure the software system is available with
an uptime of 95%. The uptime is calculated as the percentage of time
during the year in which the software system was available to the users.
A 95% uptime percentage allows for an average of 18.25 days per year, 36
hours per month, or 8.4 hours per week of downtime. This is so because,
even if the system is intended for users within the energy ministry,
peak usage does spans almost to power line projects across the nation,
with users in a such a wide geography, a downtime does leave a wide
service gap.

### Security Requirements

The National Petroleum Information System, must follow industry
recommended practices for secure software development. At a minimum, the
software development must practice the principle of least privilege for
defining access-level requirements of the software system and its
associated services. The production-release version of the software
system must pass an automated dynamic application security testing tool
(e.g., HP WEBINSPECT).

### Maintainability Requirements

Since a micro service oriented architectural as design pattern and
approach was adopted, the system can easily be maintained service by
service without risking disruption from errors and faults. The maximum
person-time required to fix a security defect (including regression
testing and documentation update) must not exceed two person days.
Otherwise, the software system must be taken offline or the offending
feature disabled. The average person-time required to make a minor
enhancement (including testing and documentation update) must not exceed
one-person week.

### Portability Requirements

Having proposed a containerized mode of deployment, the National
Petroleum Information System can easily be migrated, to a new
environment in the shortest of time.

# References

IEEE. (1998). 830-1998 - IEEE Recommended Practice for Software
Requirements Specifications. *IEEE Explorer*.
doi:10.1109/IEEESTD.1998.88286

IEEE. (1998). IEEE Standard for Conceptual Modeling Language Syntax and
Semantics for IDEF1X/Sub 97/ (IDEF/Sub Object/). *IEEE Std 1320.2-1998*.
doi:10.1109/IEEESTD.1998.89426

IEEE. (2018). ISO/IEC/IEEE International Standard - Systems and software
engineering \-- Life cycle processes \-- Requirements engineering.
*IEEE*. From
https://standards.ieee.org/ieee/29148/6937/#:\~:text=29148%2D2011,-ISO%2FIEC%2FIEEE&text=ISO%2FIEC%2FIEEE%2029148%3A,and%20their%20content%20are%20defined.
