2.7 MiB
Executable File
sidebar_position
| sidebar_position |
|---|
| 2 |
Software Requirements Specification
A single source of truth documenting the collection, interpretation, analysis and engineering of NPIS requirments
Table of Contents
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.
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.
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) <20>, 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 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.
System Features
This section outlines the several software product feature requirements as specified for the National Petroleum Information System.
| # | 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 <20> 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.
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
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<75>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<75>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<65>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 <20> 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.
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<72>s ISO/IEC 15445 components and metadata details are updated. |
| Failed End Condition: | * An error message is displayed * The Form<72>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<6F>s ISO/IEC 15445 components and metadata details are updated. |
| Failed End Condition: | * An error message is displayed * The Form<72>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 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.
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 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.
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 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.
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 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.
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 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.
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<6F>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 <20>Generate Enforcement Report<72> 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.
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 <20>Buy Button<6F>. 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.
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 <20>Environmental Social Impact Assessment Report<72> 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 <20>ESIA Review Report<72> 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.
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.