FUNCTIONAL SPECIFICATIONS

DOCUMENTS
Functional Specification Document................................................................22
Sub Module: Customer Registration........................................................23
Overview..............................................................................................23
Software Requirement Analysis............................................................23
High-level Architecture.........................................................................24
Purpose / Description...........................................................................24
Use Cases.............................................................................................25
Screen/UI Design..................................................................................28
Field-level Specifications......................................................................28
Business Rules and Dependencies.......................................................29
Buttons, Links, and Icons.....................................................................29
Risk Assessment...................................................................................29
Updated Non-Functional Requirements................................................30
Sub Module: Enquiry Generation.............................................................31
Overview..............................................................................................31
Software Requirement Analysis............................................................31
High-Level Architecture........................................................................31
Use Cases.............................................................................................32
Screen/UI Design..................................................................................38
Field-Level Specifications.....................................................................38
Business Rules and Dependencies.......................................................39
Buttons, Links, and Icons.....................................................................39
Risk Assessment...................................................................................40
Updated Non-Functional Requirements................................................40
Sub Module: Customer Portal..................................................................41
Overview..............................................................................................41
Software Requirement Analysis............................................................41
High-level Architecture.........................................................................42
Module Name: Customer Portal............................................................42
Sub Module Name: Enquiry Tracking....................................................42
Use Cases.............................................................................................43
 Screen/UI Design..................................................................................47
Field Level Specifications.....................................................................48
Business Rules and Dependencies.......................................................48
Buttons, Links and Icons.......................................................................49
Risk Assessment...................................................................................49
Updated Non-Functional Requirements................................................50
Sub Module: Management Portal..........................................................51
Overview..............................................................................................51
Software Requirement Analysis............................................................51
System Integration Requirements........................................................52
Sub-Module Name................................................................................53
Management Portal – Enquiry Oversight..............................................53
Purpose / Description...........................................................................53
Use Cases.............................................................................................54
Screen/UI Design (to be visualized with Figma/Adobe XD)...................58
Field-Level Specifications.....................................................................59
Business Rules and Dependencies.......................................................59
Buttons, Links, Icons............................................................................60
Risk Assessment...................................................................................60
Updated Non-Functional Requirements................................................61
Sub Module: Alerts & Notification Module.............................................62
Overview..............................................................................................62
Software Requirement Analysis............................................................62
High-Level Architecture........................................................................63
Module: Enquiry Management System.................................................63
Sub-Module: Alerts & Notification.........................................................63
Purpose/Description.............................................................................63
Use Cases.............................................................................................64
Screen/UI Design..................................................................................67
Field Level Specifications.....................................................................68
Business Rules and Dependencies.......................................................68
 Buttons, Links, and Icons.....................................................................69
Risk Assessment...................................................................................69
Updated Non-Functional Requirements................................................69
Test Management System...........................................................................70
Sub Module: Test Parameters..................................................................70
Overview..............................................................................................70
Software Requirement Analysis............................................................70
High-Level Architecture........................................................................70
Module Name: Testing & Parameterization...........................................71
Use Cases – Testing & Parameterization Module..................................72
Screen/UI Design..................................................................................80
Field-Level Specifications.....................................................................80
Business Rules and Dependencies.......................................................82
Buttons, Links, and Icons.....................................................................82
Risk Assessment...................................................................................83
Updated Non-Functional Requirements................................................83
Sub Module: Quotation, Invoicing, and Payment.....................................84
Overview..............................................................................................84
Software Requirement Analysis............................................................84
High-Level Architecture........................................................................85
Module Name: Quotation, Invoicing, and Payment...............................86
Use Cases.............................................................................................86
UI/Screen Design..................................................................................88
Field-Level Specifications.....................................................................89
Business Rules and Dependencies.......................................................90
Buttons, Links, and Icons.....................................................................90
Risk Assessment...................................................................................91
Updated Non-Functional Requirements................................................91
Sub-Module: Sample Management..........................................................92
Overview..............................................................................................92
Software Requirement Analysis............................................................92
 High-Level Architecture........................................................................93
Module Name: Analytical Testing..........................................................94
Use Cases.............................................................................................94
Screen/UI Design..................................................................................96
Field-Level Specifications.....................................................................96
Business Rules and Dependencies.......................................................97
Buttons, Links and Icons.......................................................................97
Risk Assessment...................................................................................97
Updated Non-Functional Requirements................................................98
Sub-Module: Case Management...........................................................99
Overview..............................................................................................99
Software Requirement Analysis............................................................99
High-Level Architecture......................................................................100
Module Name: Analytical Testing........................................................101
Purpose / Description.........................................................................101
Use Cases...........................................................................................101
Screen/UI Design................................................................................104
Field-Level Specifications...................................................................104
Business Rules and Dependencies.....................................................105
Buttons, Links, and Icons...................................................................106
Risk Assessment.................................................................................106
Updated Non-Functional Requirements..............................................106
Sub-Module: Special Cases....................................................................108
Overview............................................................................................108
Software Requirement Analysis..........................................................108
High-Level Architecture......................................................................109
Module Name: Analytical Testing Module...........................................109
Purpose/ Description:.........................................................................109
Use Cases...........................................................................................110
Field-Level Specifications...................................................................113
Business Rules and Dependencies.....................................................114
 Buttons, Links, and Icons...................................................................114
Risk Assessment.................................................................................115
Updated Non-Functional Requirements..............................................115
Research Program Management System..................................................116
R&D.......................................................................................................116
Overview............................................................................................116
Software Requirement Analysis..........................................................116
High-Level Architecture......................................................................117
Module: Research Program Management System..............................118
Screen/UI Design................................................................................124
Field-Level Specifications...................................................................124
Business Rules and Dependencies.....................................................125
Buttons, Links, and Icons...................................................................125
Risk Assessment.................................................................................126
Updated Non-Functional Requirements..............................................126
Technical Assistance and Consultancy Management System...................127
Module: Technical Assistance and Consultancy Management System
(TACMS).................................................................................................127
Overview............................................................................................127
Software Requirement Analysis..........................................................127
High-level Architecture.......................................................................128
Module: Technical Assistance and Consultancy Management System
...........................................................................................................129
Use Cases...........................................................................................129
Screen/UI Design................................................................................136
Field Level Specifications...................................................................136
Business Rules....................................................................................138
Risk Management and Mitigation.......................................................138
Non-Functional Requirements............................................................139
Publication Management System.............................................................140
Sub Module: Publication Database Management System......................140
 Overview............................................................................................140
Software Requirement Analysis..........................................................140
High-level Architecture.......................................................................140
Sub-Module Name: Publication Metadata Capture.............................141
Use Cases:..........................................................................................141
Screen/UI Design................................................................................144
Field Level Specifications...................................................................145
Business Rules and Dependencies.....................................................148
Buttons, Links, and Icons...................................................................149
Risk Assessment.................................................................................150
Updated Non-Functional Requirements..............................................150
Sub-Module Name: Journal Master Data Management..........................151
Overview............................................................................................151
Software Requirement Analysis..........................................................151
High-level Architecture.......................................................................151
Sub-Module Name: Journal Master Data Management.......................152
Use Cases...........................................................................................152
Screen/UI Design................................................................................154
Field Level Specifications...................................................................154
Business Rules and Dependencies.....................................................156
Buttons, Links, and Icons...................................................................156
Risk Assessment.................................................................................157
Updated Non-Functional Requirements..............................................157
Sub Module: Author and Co-Author Information Management..............159
Overview............................................................................................159
Software Requirement Analysis..........................................................159
High-level Architecture.......................................................................159
Sub-Module Name: Author and Co-Author Information Management 160
Use Cases...........................................................................................160
Screen/UI Design................................................................................162
Field Level Specifications...................................................................162
 Business Rules and Dependencies.....................................................164
Buttons, Links, and Icons...................................................................164
Risk Assessment.................................................................................165
Updated Non-Functional Requirements..............................................166
Sub Module: Publication Information Management...............................167
Overview............................................................................................167
Software Requirement Analysis..........................................................167
High-level Architecture.......................................................................167
Sub-Module Name: Publication Information Management..................168
Use Cases...........................................................................................168
Screen/UI Design................................................................................169
Field Level Specifications...................................................................170
Business Rules and Dependencies.....................................................171
Buttons, Links, and Icons...................................................................172
Risk Assessment.................................................................................172
Updated Non-Functional Requirements..............................................173
Sub Module: Publication Workflow, Alerts & Notifications, and Automatic
KPI Calculation and Evaluation..............................................................174
Overview............................................................................................174
Software Requirement Analysis..........................................................174
High-level Architecture.......................................................................174
Sub-Module Name: Workflow, Alerts & Notifications, KPI Calculation.175
Use Cases...........................................................................................175
Screen/UI Design................................................................................177
Field Level Specifications...................................................................177
Business Rules and Dependencies.....................................................179
Buttons, Links, and Icons...................................................................179
Risk Assessment.................................................................................180
Updated Non-Functional Requirements..............................................180
Process Management System...................................................................182
Module Name: PCSIR ERP – Process Management System.................182
 Overview............................................................................................182
Software Requirement Analysis..........................................................182
High-level Architecture.......................................................................183
Sub-Module: Industry & Field Setup...................................................183
Use Cases...........................................................................................184
Screen/UI Design................................................................................188
Field-Level Specifications...................................................................188
Buttons, Links, and Icons...................................................................189
Risk Assessment.................................................................................190
Updated Non-Functional Requirements:.............................................190
Module: Product Management System.....................................................191
Overview:...........................................................................................191
Software Requirement Analysis:.........................................................191
High-Level Architecture:.....................................................................192
Sub Module Name: Product Definition and Approval Workflow..........192
Use Cases...........................................................................................192
Screen/UI Design................................................................................199
Field Level Specifications...................................................................199
Business Rules and Dependencies.....................................................200
Buttons, Links, and Icons...................................................................200
Risk Assessment.................................................................................200
Updated Non-Functional Requirements..............................................201
Patent Management System.....................................................................202
Sub Module Name: Patents Database...................................................202
Overview............................................................................................202
Software Requirement Analysis..........................................................202
High-level Architecture.......................................................................202
Purpose/ Description..........................................................................203
Use Cases...........................................................................................203
Screen/UI Design................................................................................204
Field Level Specifications...................................................................205
 Business Rules and Dependencies.....................................................206
Buttons, Links and Icons....................................................................207
Risk Assessment.................................................................................207
Updated Non-Functional Requirements..............................................207
Sub Module: The Patent Office Database..............................................209
Overview............................................................................................209
Software Requirement Analysis..........................................................209
High-Level Architecture......................................................................209
Sub Module Name: Patent Office Database........................................209
Use Cases...........................................................................................210
Screen/UI Design................................................................................211
Field Level Specifications...................................................................211
Business Rules and Dependencies.....................................................212
Buttons, Links and Icons....................................................................212
Risk Assessment.................................................................................212
Updated Non-Functional Requirements..............................................213
Sub Module: The Author and Co-Author Information.............................214
Overview............................................................................................214
Software Requirement Analysis..........................................................214
High-level Architecture.......................................................................215
Sub Module Name: Author and Co-Author Information......................215
Use Cases...........................................................................................215
Screen/UI Design................................................................................216
Field Level Specifications...................................................................216
Business Rules and Dependencies.....................................................217
Buttons, Links, and Icons...................................................................217
Risk Assessment.................................................................................218
Updated Non-Functional Requirements..............................................218
Sub Module: The "Patent File Information"............................................219
Overview............................................................................................219
Software Requirement Analysis..........................................................219
 High-Level Architecture......................................................................219
Sub Module Name: Patent File Information........................................219
Use Cases...........................................................................................219
Screen/UI Design................................................................................220
Field Level Specifications...................................................................220
Business Rules and Dependencies.....................................................221
Buttons, Links, and Icons...................................................................222
Risk Assessment.............................................................................222
Updated Non-Functional Requirements..............................................222
Sub Module: The "Patent Obtained Information"...................................223
Overview............................................................................................223
Software Requirement Analysis..........................................................223
High-level Architecture.......................................................................223
Sub Module Name: Patent Obtained Information...............................223
Use Cases...........................................................................................224
Screen/UI Design................................................................................224
Field Level Specifications...................................................................224
Business Rules and Dependencies.....................................................225
Buttons, Links, and Icons...................................................................225
Risk Assessment.................................................................................226
Updated Non-Functional Requirements..............................................226
Sub Module: The "Patent Files/Obtained Approval Workflow.................227
Overview............................................................................................227
Software Requirement Analysis..........................................................227
High-level Architecture.......................................................................227
Sub Module Name..............................................................................228
Patent Files/Obtained Approval Workflow...........................................228
Use Cases...........................................................................................228
Alerts and Notifications......................................................................229
Use Cases...........................................................................................229
Automatic KPI Calculation and Evaluation..........................................229
 Use Cases...........................................................................................229
Screen/UI Design................................................................................230
Field Level Specifications...................................................................230
Business Rules and Dependencies.....................................................230
Buttons, Links, Icons..........................................................................231
Risk Assessment.................................................................................231
Updated Non-Functional Requirements..............................................231
Design and Fabrication Management System...........................................232
Sub Module: Industries Database Management and Measurement Units
Definition:..............................................................................................232
Overview:...........................................................................................232
Software Requirement Analysis:.........................................................232
High-Level Architecture:.....................................................................232
Sub-Module: Industries Database:......................................................233
Use Cases:..........................................................................................233
Screen/UI Design:...............................................................................233
Field Level Specifications:..................................................................233
Business Rules and Dependencies:....................................................234
Buttons, Links, and Icons:..................................................................234
Risk Assessment:...............................................................................234
Sub-Module: Measurement Units Definition:.........................................235
Use Cases:..........................................................................................235
Screen/UI Design:...............................................................................235
Field Level Specifications:..................................................................235
Business Rules and Dependencies:....................................................236
Buttons, Links, and Icons:..................................................................236
Risk Assessment:...............................................................................236
Updated Non-Functional Requirements:.............................................236
Design and Fabrication Information Management & Search..................237
Overview............................................................................................237
Software Requirement Analysis..........................................................237
 High-Level Architecture......................................................................237
Sub-Module Name: Design and Fabrication Information Management &
Search................................................................................................238
Use Cases...........................................................................................238
Screen/UI Design................................................................................240
Field Level Specifications...................................................................240
Business Rules and Dependencies.....................................................241
Buttons, Links and Icons....................................................................241
Risk Assessment.................................................................................242
Updated Non-Functional Requirements..............................................242
Sub Module Name: Equipment Contract Management &
Repair/Maintenance Tracking.................................................................243
Overview............................................................................................243
Software Requirement Analysis..........................................................243
High-level Architecture.......................................................................243
Purpose/ Description..........................................................................243
Use Cases...........................................................................................244
Screen/UI Design................................................................................245
Field Level Specifications...................................................................245
Business Rules and Dependencies.....................................................246
Buttons, Links, and Icons...................................................................247
Risk Assessment.................................................................................247
Updated Non-Functional Requirements..............................................247
Sub-Module Name: Approval Workflow, Alerts and Notifications, KPI
Evaluation..............................................................................................248
Overview............................................................................................248
Software Requirement Analysis..........................................................248
High-Level Architecture......................................................................248
Sub-Module Name: Approval Workflow, Alerts and Notifications, KPI
Evaluation..........................................................................................249
Use Cases...........................................................................................249
 Screen/UI Design................................................................................250
Field Level Specifications...................................................................251
Business Rules and Dependencies.....................................................251
Buttons, Links and Icons....................................................................251
Risk Assessment.................................................................................252
Updated Non-Functional Requirements..............................................252
Calibration Management System..............................................................253
Calibration Parameters..........................................................................253
Overview............................................................................................253
Software Requirement Analysis..........................................................253
High-Level Architecture......................................................................253
Module Name: Calibration Parameters Management.........................254
Use Cases...........................................................................................254
Screen / UI Design..............................................................................256
Field Level Specifications...................................................................257
Business Rules and Dependencies.....................................................257
Buttons, Links, and Icons...................................................................258
Risk Assessment.................................................................................258
Updated Non-Functional Requirements..............................................259
Quotation, Invoicing, and Payment........................................................260
Overview............................................................................................260
Software Requirement Analysis..........................................................260
High-Level Architecture......................................................................260
Sub-Module Name: Quotation and Payment Processing.....................261
Use Cases...........................................................................................261
Screen/UI Design................................................................................263
Field Level Specifications...................................................................263
Business Rules and Dependencies.....................................................264
Buttons, Links, Icons..........................................................................264
Risk Assessment.................................................................................265
Updated Non-Functional Requirements..............................................265
Sub Module Name: Equipment Management........................................266
Overview............................................................................................266
Software Requirement Analysis..........................................................266
High-Level Architecture......................................................................266
Sub Module: Equipment Management................................................267
Use Cases...........................................................................................267
Screen/UI Design................................................................................268
Field Level Specifications...................................................................268
Business Rules and Dependencies.....................................................269
Buttons, Links, Icons..........................................................................270
Risk Assessment.................................................................................270
Updated Non-Functional Requirements..............................................270
Sub Module Name: Case Management..................................................271
Overview............................................................................................271
Software Requirement Analysis..........................................................271
High-level Architecture.......................................................................271
Purpose/Description...........................................................................271
Use Cases...........................................................................................272
Screen/UI Design................................................................................274
Field Level Specifications...................................................................274
Business Rules and Dependencies.....................................................275
Buttons, Links, and Icons...................................................................275
Risk Assessment.................................................................................276
Updated Non-Functional Requirements..............................................276
Sub Module Name: Return of Equipment...............................................277
Overview............................................................................................277
Software Requirement Analysis..........................................................277
High-level Architecture.......................................................................277
Purpose/Description...........................................................................277
Use Cases...........................................................................................278
Screen/UI Design................................................................................279
 Field Level Specifications...................................................................279
Business Rules and Dependencies.....................................................280
Buttons, Links, and Icons...................................................................281
Risk Assessment.................................................................................281
Updated Non-Functional Requirements..............................................281
Sub Module Name: Special Case Handling and Confidential Calibration
Workflows..............................................................................................282
Overview............................................................................................282
Software Requirement Analysis..........................................................282
High-Level Architecture......................................................................282
Purpose/Description...........................................................................283
Use Cases...........................................................................................283
Screen/UI Design................................................................................284
Field-Level Specifications...................................................................284
Business Rules and Dependencies.....................................................285
Buttons, Links and Icons....................................................................286
Risk Assessment.................................................................................286
Updated Non-Functional Requirements..............................................286
Student Supervision and Internship Management System.......................288
Student Supervision..............................................................................288
Overview............................................................................................288
Software Requirement Analysis..........................................................288
High-level Architecture.......................................................................289
Sub-Module: University, Degree, and Discipline Master Data............289
Sub-Module: Student Supervision Management.................................289
Use Cases...........................................................................................290
Screen/UI Design................................................................................293
Field Level Specifications...................................................................293
Business Rules and Dependencies.....................................................294
Buttons, Links, and Icons...................................................................294
Risk Assessment.................................................................................295
 Updated Non-Functional Requirements..............................................295
Internship Management – Student Supervision & Internship Approval
Workflow................................................................................................296
Overview............................................................................................296
Software Requirement Analysis..........................................................296
High-level Architecture.......................................................................296
Sub-Module: Internship Management.................................................297
Use Cases...........................................................................................297
Screen/UI Design................................................................................299
Field Level Specifications...................................................................299
Business Rules and Dependencies.....................................................300
Buttons, Links, and Icons...................................................................301
Risk Assessment.................................................................................301
Updated Non-Functional Requirements..............................................302
Training Management System..................................................................303
Sub Module: Training Initiation with Visits/Meetings, Fields of Studies,
Industry Type, and Multi-Channel Payment Methods.............................303
Overview............................................................................................303
Software Requirement Analysis..........................................................303
High-level Architecture.......................................................................303
Sub Module Name 1: Training Initiation with Visits/Meetings, Fields of
Studies, Industry Type........................................................................304
Use Cases...........................................................................................304
Sub Module Name 2: Multi-Channel Payment Methods......................304
Screen/UI Design................................................................................305
Field Level Specifications...................................................................305
Business Rules and Dependencies.....................................................306
Buttons, Links and Icons....................................................................306
Risk Assessment.................................................................................307
Updated Non-Functional Requirements..............................................307
Sub Module: Case Management, Trainer Information, and Training
Workflows..............................................................................................308
Overview............................................................................................308
Software Requirement Analysis..........................................................308
High-level Architecture.......................................................................308
Sub Module Name: Case Management, Trainer Information, Training
Workflows...........................................................................................308
Use Cases...........................................................................................309
Screen/UI Design................................................................................310
Field Level Specifications...................................................................310
Business Rules and Dependencies.....................................................310
Buttons, Links, and Icons...................................................................311
Risk Assessment.................................................................................311
Updated Non-Functional Requirements..............................................312
Sub Module Name: Training Search, Report Compilation, KPI Evaluation
..............................................................................................................313
Overview............................................................................................313
Software Requirement Analysis..........................................................313
High-level Architecture.......................................................................313
Sub Module: Training Search using Keywords and Wildcard Search...313
Use Cases...........................................................................................314
Sub Module: Report Compilation and Generation..............................314
Use Cases...........................................................................................314
Sub Module: Automatic KPI Calculation and Evaluation.....................315
Use Cases...........................................................................................315
Screen/UI Design................................................................................315
Field Level Specifications...................................................................315
Business Rules and Dependencies.....................................................316
Buttons, Links and Icons....................................................................316
Risk Assessment.................................................................................317
Updated Non-Functional Requirements..............................................317
Visits Management System......................................................................318
Sub Module: Industrial Visits Management System – Visit Information. 318
Overview............................................................................................318
Software Requirement Analysis..........................................................318
High-level Architecture.......................................................................318
Sub Module Name: Visit Information..................................................319
Use Cases...........................................................................................319
Screen/UI Design................................................................................321
Field Level Specifications...................................................................321
Business Rules and Dependencies.....................................................323
Buttons, Links and Icons....................................................................323
Risk Assessment.................................................................................324
Updated Non-Functional Requirements..............................................324
Sub Module: Visit Search Using Keywords and Wildcard Search and
Automatic KPI Calculation and Evaluation.............................................326
Overview............................................................................................326
Software Requirement Analysis..........................................................326
High-level Architecture.......................................................................326
Sub Module Name: Visit Search Using Keywords and Wildcard Search
...........................................................................................................327
Use Cases...........................................................................................327
Screen/UI Design................................................................................328
Field Level Specifications...................................................................328
Business Rules and Dependencies.....................................................329
Buttons, Links and Icons....................................................................329
Risk Assessment.................................................................................329
Updated Non-Functional Requirements..............................................330
Sub Module Name: Automatic KPI Calculation and Evaluation...........330
Use Cases...........................................................................................330
Screen/UI Design................................................................................331
Field Level Specifications...................................................................331
 Business Rules and Dependencies.....................................................332
Buttons, Links and Icons....................................................................332
Risk Assessment.................................................................................333
Updated Non-Functional Requirements..............................................333
Quality Management System (ISO/IEC 17025).........................................334
Document Management System for ISO...............................................334
Overview............................................................................................334
Software Requirement Analysis..........................................................334
High-Level Architecture......................................................................334
Module Name: ISO Document Management System..........................335
Use Cases...........................................................................................335
Screen/UI Design................................................................................337
Field-Level Specifications...................................................................337
Business Rules and Dependencies.....................................................338
Buttons, Links and Icons....................................................................339
Risk Assessment.................................................................................339
Updated Non-Functional Requirements..............................................340
Sub Module: The Opportunities and Risk Management System............341
Overview............................................................................................341
Software Requirement Analysis..........................................................341
High-level Architecture.......................................................................341
Purpose/Description of Sub-Module....................................................341
Use Cases...........................................................................................342
Screen/UI Design................................................................................343
Field Level Specifications...................................................................343
Business Rules and Dependencies.....................................................345
Buttons, Links, and Icons...................................................................345
Risk Assessment.................................................................................345
Updated Non-Functional Requirements..............................................346
Sub Module: The "Committee Management System"............................347
Overview............................................................................................347
 Software Requirement Analysis..........................................................347
High-level Architecture.......................................................................347
Sub Module Name: Committee Setup and Meeting Lifecycle.............348
Use Cases...........................................................................................348
Screen/UI Design................................................................................350
Field Level Specifications...................................................................350
Business Rules and Dependencies.....................................................351
Buttons, Links and Icons....................................................................352
Risk Assessment.................................................................................352
Updated Non-Functional Requirements..............................................353
Sub Module: The Internal and External Audit Management System......354
Overview............................................................................................354
Software Requirement Analysis..........................................................354
High-Level Architecture......................................................................354
Sub Module Name: Internal and External Audit Management........354
Use Cases...........................................................................................355
Screen/UI Design................................................................................356
Field Level Specifications...................................................................356
Business Rules and Dependencies.....................................................357
Buttons, Links and Icons....................................................................357
Risk Assessment.................................................................................358
Updated Non-Functional Requirements..............................................358
Sub Module: The Corrective Actions Request (CAR) system..................359
Overview............................................................................................359
Software Requirement Analysis..........................................................359
High-Level Architecture......................................................................359
Purpose / Description.........................................................................360
Use Cases...........................................................................................360
Screen/UI Design................................................................................361
Field Level Specifications...................................................................362
Business Rules and Dependencies.....................................................363
 Buttons, Links and Icons....................................................................363
Risk Assessment.................................................................................364
Updated Non-Functional Requirements..............................................364

Functional Specification Document

System: Scientific Information Management System (SIMS)
Module: Enquiry Management System (EMS)
Sub Module: Customer Registration
Overview
The Customer Registration sub-module is a foundational component of the
Enquiry Management System (EMS) developed for the Pakistan Council of
Scientific and Industrial Research (PCSIR). The purpose of this sub-module is
to facilitate seamless and centralized registration of customers intending to
avail themselves of PCSIR's testing, consultation, and research services
through its various laboratories and Industrial Liaison Offices (ILOs) spread
across Pakistan. This system ensures that customers are authenticated,
verified, and uniquely identifiable across all PCSIR units, thereby enabling a
streamlined enquiry and service provisioning process.
The system provides multiple entry points for customer registration: mobile
application, web portal, telephone interface (operator-assisted), and walk-in
registration at any ILO. The module is designed to validate customer
credentials, generate a unique registration number, and enforce business
rules ensuring data integrity, user verification, and consistency. Additionally,
it empowers ILO personnel to manage customer records with the ability to
modify or cancel registrations when necessary.
Software Requirement Analysis
This module requires the following software functionalities and integrations:
 Customer Identity Management: Capability to uniquely identify each
customer based on provided information such as CNIC and mobile
number.
 Multi-Channel Registration Interface: Accessible and responsive UI/UX
for mobile, web, telephone, and physical registration workflows.
 SMS Gateway Integration: Real-time OTP (One-Time Password) delivery
and verification functionality using local mobile service providers.
 OTP Expiry and Resend Logic: Robust logic to handle expiry (e.g., 5
minutes) and resend limits (e.g., 3 attempts per hour).
  Audit Logging: Comprehensive logs for registration attempts, edits, and
deletions for compliance and auditing purposes.
 Role-Based Access Control (RBAC): Differentiated access rights for
system administrators, ILO operators, and external users.
 Data Validation and Masking: Format and logic validation of fields such
as CNIC, mobile number, email address, etc.
 Notifications: Confirmation messages upon successful registration and
alerts for registration issues.
 Real-Time Synchronization: Ensures that registration data is updated
across all PCSIR systems and accessible to authorized personnel.
High-level Architecture
The Customer Registration module is composed of multiple layers and
components that collectively ensure its functionality, integrity, and
scalability.
 Presentation Layer:
o Web Frontend (HTML5/JS, Responsive Design)
o Mobile Application (Android/iOS)
o Operator Interface (Web-based Admin Portal)
 Business Logic Layer:
o Customer Registration Handler
o OTP Management Module
o User Profile Management
o Logging and Auditing Engine
 Data Access Layer:
o Centralized Relational Database (e.g., PostgreSQL, MySQL)
o Data Synchronization Services
 External Services:
o SMS Gateway (with retry, fallback provider)
o Email Server (optional for confirmation emails)
 Security Components:
o Encryption Library (for passwords, personal data)
o RBAC Module
o API Security Layer (OAuth2, API key management)

Purpose / Description
The primary objective of the Customer Registration sub-module is to register
and verify customers seeking services from PCSIR. This process captures
essential customer details, ensures that the identity of the customer is
verified through OTP (One-Time Password) verification, and stores the data in
a central repository. Once registered, customers receive a unique Customer
Registration Number and are granted access to all subsequent modules of
EMS, including Enquiry Submission, Payment, and Service Delivery.
This system also includes a mechanism for ILO operators to manually update,
correct, or cancel customer records. These modifications are subject to role-
based access controls and are logged for audit purposes.
This sub-module also acts as a gateway to various downstream processes
such as:
 Quotation Management
 Sample Submission Tracking
 Invoicing
 Test Report Delivery

Use Cases
Use Case ID: EMS-CR-001
Use Case Name: Customer Self Registration via Mobile/Web Primary Actor(s):
Unregistered Customer Pre-conditions:
 The user has access to the internet via a mobile device or computer.
 The mobile number is valid and able to receive SMS.
Post-conditions:
 Customer receives a unique registration ID.
 Customer is marked as "Verified" in the system.
Main Success Scenario:
1. Customer navigates to the registration form on the mobile/web
application.
2. Customer fills out required fields: Name, Mobile Number, Email, CNIC
(if individual), City, and Company (optional).
3. The system validates the inputs and sends a 6-digit OTP to the mobile
number.
4. Customer enters the OTP within 5 minutes.
5. The system validates OTP and confirms registration.
6. The system generates a Customer Registration Number and a
temporary password.
Alternative Paths:
 If OTP is incorrect, the system allows 2 more attempts.
 If all attempts fail or the OTP expires, a new OTP can be requested.

Business Rules:
 The mobile number must be unique.
 CNIC is mandatory for individual customers.
 OTP is valid for 5 minutes.
  OTP resend is allowed a maximum of 3 times in an hour.

Use Case ID: EMS-CR-002

Use Case Name: Operator-Assisted Registration via Telephone or Walk-In
Primary Actor(s): ILO Operator, Customer Pre-conditions:
 Operator has access to the admin registration interface.
 Customer provides valid mobile number.
Post-conditions:
 Customer is registered and marked as verified.
Main Success Scenario:
1. Customer calls or visits ILO.
2. Operator inputs customer data into system.
3. System sends OTP to customer’s mobile.
4. Customer reads the OTP aloud to the operator.
5. The operator inputs OTP into the system.
6. System verifies OTP and registers the customer.
Alternative Paths:
 OTP not received: Retry or use an alternate number.
 Verification fails: Retry registration process.
Business Rules:
 The ILO operator must log the registration channel.
  The operator must confirm CNIC if the customer is an individual.

Use Case ID: EMS-CR-003

Use Case Name: Customer Record Modification/Cancellation Primary Actor(s):
ILO Operator Pre-conditions:
 The operator has role-based access.
Post-conditions:
 Customer record is updated or marked as cancelled.
Main Success Scenario:
1. The operator searches the customer using ID or mobile number.
2. The operator accesses the edit form.
3. Makes required updates (e.g., email, mobile number).
4. Saves changes.
5. System logs the change with timestamp and operator ID.
Alternative Paths:
 Unauthorized user attempts edit: Access denied.
Business Rules:
 Changes are not allowed for verified CNIC unless authorized.
 Cancelled records cannot be reactivated without a supervisor override.
Screen/UI Design
Mockups/Wireframes:
 Registration Form (Web/Mobile)
 OTP Entry Screen
 Operator Admin Dashboard
 Customer Profile View/Edit Screen
 Cancellation Confirmation Dialog
(Note: To be attached separately in design documentation)
Field-level Specifications
Defaul
Data Value
Field Label Field Type Mandatory t Comments
Type Set
Value
Name of Max length
Text Box Yes String N/A N/A
Customer 50 chars
11 digits,
format:
Mobile Number Text Box Yes Numeric N/A N/A
03XXXXXXX
XX
Standard
Email Address Text Box No String Email N/A email
validation
Company/ Optional for
Text Box No String N/A N/A
Organization individuals
All
major
cities Standard
City Dropdown Yes String N/A
of dropdown
Pakista
n
Required if
the individual
Conditionall selected,
CNIC No. Text Box Numeric N/A N/A
y Yes format 13
digits with a
mask
000000 One-time
OTP Text Box Yes Numeric – N/A password
999999 validation
Business Rules and Dependencies
Data
Field Label Validation Rules Error Messages
Dependencies
Mobile Must be 11 digits, "Invalid or duplicate SMS gateway for
Number unique, starts with 03 mobile number" OTP
Email If present, must be "Please enter a valid
Optional
Address valid format email address"
Mandatory for "CNIC must be 13 Conditional on user
CNIC No.
individuals, 13 digits digits" type
Matches OTP sent via "Incorrect or expired Tied to mobile
OTP
SMS, within 5 mins OTP" number entry

Buttons, Links, and Icons

Other Visibl
Label On Click Event Enabled Navigate To
Event e
Register/ Validate the form OTP
N/A Yes Yes
Submit and send OTP Verification
Confirm OTP and
Verify OTP finalize N/A Yes Yes Success Page
registration
Load customer
On the row Condition Edit Profile
Edit details in the Yes
click al Screen
form
Cancel Set status to Confirm Condition Confirmation
Yes
Registration inactive dialog al Prompt
After the
Trigger OTP Condition OTP Entry
Resend OTP timer Yes
resend logic al Screen
expires

Risk Assessment
Risk Description Mitigation Strategy
Use multiple SMS gateway vendors
OTP not delivered to the customer
with a failover mechanism
Duplicate registrations due to user Validate mobile/CNIC uniqueness in
error real-time
Unauthorized access to customer RBAC with detailed activity logging and
edit/delete functionality audit trails
Data corruption during concurrent Use transaction locking and validation
registrations layers

Updated Non-Functional Requirements

 Performance: Able to handle 500 concurrent registration requests with
response time < 2 seconds.
 Scalability: Microservices architecture to allow independent scaling of
OTP and registration handlers.
 Availability: 99.9% uptime, with automatic failover for SMS delivery.
 Security: All personal data encrypted in transit and at rest using AES-
256. OTPs hashed using SHA-256.
 Compliance: Aligns with local data protection regulations (e.g., NADRA
CNIC handling norms).
 Auditability: All changes in registration data are logged with
timestamps and user IDs.
 User Experience: Simple, multilingual UI with auto-form validation and
error hints.
Sub Module: Enquiry Generation
Overview
This Functional Specification Document (FSD) defines the detailed
functionality of the Enquiry Management System for PCSIR's ERP platform.
The module is responsible for capturing customer enquiries from various
channels, routing them to the appropriate PCSIR Lab or Unit, and facilitating
responses from technical teams. The system is also responsible for
automatic tracking, quotation generation, and enabling centralized
monitoring through the ILO.

This document provides an in-depth breakdown of all functionalities, screens,

data validations, business rules, and technical dependencies required to
implement the Enquiry Management Module.

Software Requirement Analysis

 Target Users: Enquiry Operators, Head ILO, Center Heads, Technical

Staff (Engineers, Scientists), System Admin, Registered Customers

 Access Platforms: Web Portal, Mobile App (iOS/Android), Admin

Dashboard

 Input Interfaces: Web Forms, Email Parsing, Mobile Forms, Phone Logs,
Fax Image Upload, Walk-in Manual Entry

 Integration: Customer Registration Module, Notification Module

(SMS/Email), Quotation Module, Invoicing Module, Master Data
(Labs/Units, Services)

High-Level Architecture

 Frontend: React-based responsive UI for Web and Flutter-based mobile

interface

 Backend: Node.js (API layer), PostgreSQL (Database), RabbitMQ

(Notification Queue), Microservices for Quotation & Invoicing

 Security: OAuth2.0 with Role-based Access Control (RBAC), Input

Validation, Document Upload Sanitization

 Hosting Environment: Kubernetes Cluster with CI/CD pipeline,

containerized using Docker
Use Cases

Use Case ID: ENQ-001

Use Case Name: Enquiry Based on Nature (Testing, Calibration, Process Lease
Out, Production, etc.)

Primary Actor(s): Enquiry Operator, Registered Customer

Pre-conditions:

 Customer must exist in the PCSIR ERP customer master database.

 Enquiry Operator must have valid login credentials and necessary role
permissions.

 Enquiry module must be active and accessible within the system.

Post-conditions:

 Enquiry record is created and stored in the database.

 Nature-specific fields are recorded.

 The enquiry becomes accessible to ILO Head and other concerned

roles.

Main Success Scenario:

1. Enquiry Operator logs into the PCSIR ERP system using secure
authentication.

2. Navigates to the Enquiry Generation module.

3. Enters customer identification parameters such as Customer ID, Name,

CNIC, Mobile, Email.

4. System performs an advanced search and lists possible matches.

5. Operator selects the correct customer profile.

6. System loads customer's historical enquiry data for reference.

7. Operator selects the relevant PCSIR Lab/Unit from a dropdown menu

(populated via master data).

8. Operator selects the ‘Nature of Enquiry’:

o Analytical Testing
 o Calibration

o Repair and Maintenance

o Production (Product Development)

o Design and Fabrication

o Process Lease Out

o Technical Assistance and Consultancy

o Industrial Training

o Other

9. Based on selection, the system dynamically renders a specific sub-

form:

o Example: For Calibration, shows fields like Instrument Name, On-

site/In-lab.

10. Operator enters required fields.

11. Attaches any scanned documents, letters, email snapshots.

12. Validates the form; the system checks for required fields.

13. Operator submits the enquiry.

14. System shows confirmation and moves to the next process.

Alternative Path:

 If customer not found:

o System prompts for customer registration.

o Redirects to the Customer Registration module.

o On successful registration, process resumes from step 3.

Business Rules:

 System must enforce mandatory fields as per enquiry nature.

 Only customers with ‘Active’ status can raise enquiries.

 File uploads must not exceed configured limits (e.g., 10MB per file).

Use Case ID: ENQ-002

Use Case Name: Auto-Enquiry Number Generation and Tracking

Primary Actor(s): System, Enquiry Operator

Pre-conditions:

 Enquiry successfully filled and validated.

Post-conditions:

 Unique Enquiry Number is generated.

 Timestamp and submission logs recorded.

 Customer notified.

Main Success Scenario:

1. Upon clicking 'Submit', system validates final data.

2. System generates Enquiry Number using format:

o Format: ILO/ENQ/YYYY/####

o Year auto-derived from current system date.

o Sequence #### fetched from a system-maintained counter.

3. System stamps current date-time against the Enquiry record.

4. SMS is triggered to customer via SMS gateway.

5. Email with enquiry summary and reference number sent to registered

email ID.

6. System logs the event into Enquiry Activity Log for traceability.

Business Rules:

 Enquiry Numbers must be unique.

 If system encounters concurrency (multiple entries within a second),

increment sequence.

 SMS/Email failures should be retried 3 times; if all fail, alert admin.

Use Case ID: ENQ-003

Use Case Name: Enquiry Distribution to the Concerned Center

Primary Actor(s): Head ILO

Pre-conditions:

 Enquiry must be in the status "Pending Distribution".

Post-conditions:

 One or more Centers receive the Enquiry.

Main Success Scenario:

1. Head ILO logs into the system.

2. Navigates to the ‘Pending Enquiries’ dashboard.

3. Reviews submitted Enquiry details.

4. Selects center(s) from the pre-configured center directory.

5. Optionally adds remarks for the center.

6. Clicks 'Forward to Center(s)'.

7. System logs forwarding timestamp, actor ID, and remarks.

8. Notification sent to selected center(s).

9. Enquiry status updates to “Routed to Center”.

Alternative Path:

 If ILO opts to respond directly:

o Selects 'Respond from ILO'.

o System allows quotation creation by ILO.

o Enquiry marked as “Processed by ILO”.

Business Rules:

 Distribution must be completed within 24 working hours.

 Centers must be selected from active list only.

 All routing events logged with user ID and timestamps.

Use Case ID: ENQ-004

Use Case Name: Enquiry Response by the Concerned Center

Primary Actor(s): Center Head, Technical Officers, Section Heads

Pre-conditions:

 Enquiry must be assigned to the center.

 Assigned personnel must have response permissions.

Post-conditions:

 Response data is captured in system.

 Optionally, new parameters proposed and logged.

Main Success Scenario:

1. Center Head logs into the system.

2. Navigates to the ‘Assigned Enquiries’ tab.

3. Opens enquiry and reviews full details.

4. Technical officer selects response parameters from master data.

5. Inputs pricing, delivery period, conditions.

6. If parameter not available:

o Clicks “Propose New Parameter”

o Fills in scientific and commercial data.

o Submission sent for dual approval (Section Head + Center Head)

7. After validation, response submitted.

8. ILO receives system alert that response is available.

Alternative Path:

 If Center needs clarification:

o Sends a clarification request via system to ILO.

o Status set as “Pending Clarification.”

Business Rules:

 New parameters must go through workflow approval.

 All actions logged with user ID and audit trail.

 Response must include pricing breakdown and conditions.

Use Case ID: ENQ-005

Use Case Name: Automatic Quotation Generation

Primary Actor(s): ILO Officer, System

Pre-conditions:

 Response from center or direct quotation data is available.

Post-conditions:

 Quotation document generated and saved.

 Customer receives PDF via email.

Main Success Scenario:

1. ILO clicks on 'Generate Quotation' for a particular enquiry.

2. System auto-fills quotation template:

o Customer Info

o Enquiry ID

o Service Details

o Pricing

o Taxes

o Validity (default: 30 days)

o Delivery Period

o Terms & Conditions (standard + special)

3. Preview generated for verification.

4. If verified, ILO clicks ‘Finalize & Send’.

5. System generates secured, timestamped PDF.

6. PDF emailed to customer; copy archived in system.

Business Rules:

 Quotation must follow PCSIR standard format.

  Prices fetched from master data must not be editable without
authorization.

 Quotation ID follows format: QTN/YYYY/#####.

 Quotation expiry (30 days) must be visible

Screen/UI Design

(Screen mockups will be appended separately in design documents.

Wireframes include: Customer Search Panel, Enquiry Details Form,
Document Upload Panel, Enquiry Summary Page)

Field-Level Specifications

(Example for Analytical Testing Enquiry)

Field Mandator Data Default Comment

Field Label Value Set
Type y Type Value s

Master List
Commodity Dropdow of
Yes Text Lookup
Name n Commoditie
s

Test
Radio [Package, Packag Toggles
Package/Paramet Yes Text
Button Parameter] e visibility
er

List of
Visible if
Test Package Dropdow Condition Packages
Text Package is
Name n al based on
selected
commodity

Visible if
List of Multi- Condition Based on Parameter
Text
Parameters Select al commodity is
selected

Numeri Validation
Sample Quantity Text Box Yes -
c : >0

Dropdow [Normal,
Test Priority Yes Text Normal
n Urgent]
Expert Opinion Checkbo Boolea
No [Yes, No] No
Required x n

[Email,
Report Delivery Dropdow
Yes Text Courier, By Email
Mode n
Hand]

Special
Text Area No Text - Optional
Requirements

Business Rules and Dependencies

Validation/Business Data
Field Label Error Messages
Rules Dependencies

Sample Must be a positive "Sample size must be Commodity

Quantity number greater than 0" Name

Test Package Must belong to selected "Invalid package for Commodity

Name commodity commodity" Name

Report
Must select at least one "Please choose a
Delivery -
mode delivery mode"
Mode

Buttons, Links, and Icons

Button Other Visibl Enable

On Click Event Navigate To
Label Event e d

Validate form and

Submit - Yes Yes Dashboard Page
save

Generate preview of Quotation Preview

Preview - Yes Yes
enquiry Module

Upload
Open file chooser On Hover Yes Yes -
Doc
Risk Assessment

 Risk 1: Enquiry Routing Delays → Mitigation: Automated escalation

notification after 48 hours.

 Risk 2: Incorrect Parameter Pricing → Mitigation: Price lock with version

control and approval logs.

 Risk 3: Duplicate Enquiry Entry → Mitigation: Duplicate detection using

Customer ID + Date range.

Updated Non-Functional Requirements

 Performance: All enquiry forms must load within 3 seconds.

 Scalability: Must support 10,000+ concurrent enquiries.

 Reliability: 99.9% uptime guaranteed with failover backups.

 Auditability: All changes to enquiries logged with user ID, timestamp,

and field-level details.

 Mobile Compatibility: Fully functional and responsive design for tablets

and smartphones.

Sub Module: Customer Portal

Overview
The Customer Portal is a multi-access platform designed for customers
interacting with PCSIR (Pakistan Council of Scientific and Industrial Research).
It enhances accessibility and usability for tracking enquiries, submitting
service requests (testing, calibration, fabrication, repair), and managing user
credentials. The platform supports interactions via web applications, mobile
apps, phone calls, and in-person visits to ILO offices. The portal
accommodates both one-time and ongoing interactions through mechanisms
like draft enquiry saving, dynamic field validation, and personalized
dashboards.

Software Requirement Analysis

 Platform Compatibility:

o Web browsers: Chrome, Firefox, Safari, Edge (latest versions)

o Mobile platforms: Android (v8+), iOS (v12+)

 User Access:

o Anonymous users (limited enquiry tracking)

o Registered users (full access to enquiry submission, drafts, and

settings)

 Security Requirements:

o Two-factor authentication (2FA) for password changes

o SSL encryption for data transmission

o Encrypted database fields for sensitive data (passwords, contact

details)

 Functional Requirements:

o Enquiry submission with draft capability

o Real-time status tracking with multi-filter search

o Role-based dashboard for customers

o Change password functionality with validations

o Automated notifications (email/SMS/app notifications)

 Non-Functional Requirements:

o High Availability: 24/7 service with 99.5% uptime

o Performance: <2s average response for database retrievals

o Scalability: Up to 10,000 concurrent users

 o Localization: Support for Urdu and English

o Accessibility: WCAG 2.1 compliant

High-level Architecture
 Client Layer:

o Web UI: React.js-based responsive web application

o Mobile App: Flutter cross-platform hybrid app

 Application Layer:

o API Gateway: Centralized authentication and request routing

o Microservices: Modular services for Enquiry, User Management,

Notification

o Authentication Service: OAuth2.0 and JWT-based token validation

 Data Layer:

o PostgreSQL Database for transactional records

o Redis for session and notification caching

o Audit Log DB (separate): Stores all access and change logs

 Integration Layer:

o REST APIs for communication with PCSIR internal systems

o SMS Gateway and Email Server for notifications

o Admin Console for PCSIR staff interactions

Module Name: Customer Portal

Sub Module Name: Enquiry Tracking
Purpose/ Description: Allows customers to search, view, and monitor the
status of their submitted enquiries. It supports flexible search criteria
including Enquiry Number, Customer Name, Company Name, and Enquiry
Date. The module is integrated with PCSIR’s internal tracking system and
reflects real-time updates.
Use Cases
Use Case ID: CP-ET-01
Use Case Name: Track Enquiry Status
Primary Actor(s): Customer (Registered or Guest)

Pre-conditions:

 The enquiry must have been previously submitted through one of the
available channels: web portal, mobile application, phone call, or
physical submission at ILO office.

 Customer must have at least one identifying detail such as Enquiry

Number, Customer Name, Company Name, or Enquiry Date.

Post-conditions:

 The system retrieves and displays all available enquiry metadata,

including:

o Enquiry Status (e.g., Under Review, Forwarded, In Process,

Completed)

o Submission Date

o Assigned Laboratory/Department

o Estimated Turnaround Time (TAT)

o Current Phase of Progress (e.g., Verification, Sample Collection,

Result Compilation)

Main Success Scenario:

1. Customer accesses the “Track Enquiry” interface via mobile or web

portal.

2. Interface presents input fields: Enquiry Number, Customer Name,

Company Name, Enquiry Date.

3. Customer inputs at least one field.

4. Customer clicks “Track Now” button.

5. System validates input for format and sufficiency.

6. Backend services search the database for a matching record using

secure API calls.
 7. If one matching enquiry is found, details are fetched and rendered on
the UI.

8. Metadata such as status, date, lab, and progress are shown in a well-
structured table or timeline view.

Alternative Path:

 Invalid Search Input:

o User provides incorrect or insufficient input (e.g., invalid Enquiry

Number).

o System responds with: “No record found. Please check your

input.”

 Multiple Matching Records:

o If search query returns more than one record, a paginated list is

shown.

o User can apply additional filters or sort results (e.g., by date).

Business Rules:

 User must fill in at least one search field; form submission is

disabled until one field is populated.

 Enquiry records older than 5 years are archived and not visible
through this interface.

 System shall use secure HTTPS-based service calls to fetch records.

 Rate-limiting should be enforced to prevent brute-force searches.

Sub Module Name: Password Management

Purpose/ Description: This sub-module facilitates the secure modification
of account passwords by registered customers in accordance with PCSIR's
cybersecurity policy. The policy mandates strong authentication and
password hygiene, including complexity requirements, password history
enforcement, and expiration timelines.

Use Case ID: CP-PM-01

Use Case Name: Change Account Password
Primary Actor(s): Registered Customer

Pre-conditions:
  Customer must have an active and authenticated session.

 If Two-Factor Authentication (2FA) is enabled for the account, the

customer must complete verification (e.g., OTP via email or SMS).

Post-conditions:

 Password is successfully updated in the encrypted user database.

 Any active session tokens using the old password are invalidated.

 A notification (email/SMS) is dispatched confirming the password

change.

Main Success Scenario:

1. Customer logs into the PCSIR portal using credentials.

2. Navigates to Account Settings > Change Password.

3. Inputs the following:

o Current Password

o New Password (must meet strength criteria)

o Confirm New Password

4. System validates that the current password is correct.

5. Checks that the new password:

o Meets minimum complexity (length, character types)

o Does not match last 5 used passwords

6. If validations pass, system updates the password in the backend.

7. User is logged out from all other sessions.

8. Confirmation message is displayed and notification is sent.

Alternative Path:

 Incorrect Current Password:

o Display error: “The current password entered is incorrect.”

 Weak Password:

o System displays real-time strength meter.

 o Error: “Password must contain at least 8 characters, including an
uppercase letter, a lowercase letter, a digit, and a special
symbol.”

Business Rules:

 Password must be minimum 8 characters and must include:

o 1 uppercase letter

o 1 lowercase letter

o 1 numeric character

o 1 special symbol (e.g., !, @, #)

 Password must not match any of the last 5 previously used

passwords.

 Password expires every 180 days and system enforces periodic

change.

 3 failed attempts trigger a temporary lockout (configurable via admin

settings).

Sub Module Name: Draft Enquiry Submission

Purpose/ Description: Enables customers to partially complete and save
enquiry forms involving services such as testing, calibration, fabrication, or
repair. The system allows saving the form as a draft for iterative updates,
thus supporting complex submissions that require time or consultation.
Drafts improve user convenience and minimize data loss.

Use Case ID: CP-DES-01

Use Case Name: Save and Resume Draft Enquiry
Primary Actor(s): Registered Customer

Pre-conditions:

 Customer is logged into the PCSIR portal.

 At least one of the parameter input fields (service, item, or description)

is populated.

Post-conditions:

 Enquiry is saved in “Draft” state.

 System assigns a unique Draft ID.

  Timestamp and version number are logged.

 Draft is retrievable via “My Drafts” section.

Main Success Scenario:

1. Customer initiates new enquiry via “New Enquiry” form.

2. Selects one or more services (Testing, Calibration, Fabrication, or

Repair).

3. Inputs available parameters and selects “Save Draft.”

4. System validates mandatory draft save rules.

5. System auto-generates a unique Draft ID and logs creation time.

6. Draft is stored in user’s profile under “My Drafts.”

7. User notified: “Draft saved successfully. Resume anytime from your

dashboard.”

Alternative Path:

 System Error:

o Backend/database error prevents draft saving.

o Display: “Unable to save draft. Please try again later.”

Business Rules:

 Drafts are auto-saved every 5 minutes during form interaction.

 A draft is retained for 30 days of inactivity, after which it is deleted.

 Only one active draft per service type (e.g., cannot have two drafts
for Calibration simultaneously).

 Draft version history is maintained (max 5 versions).

 Resume opens latest version for editing.

 Upon final submission, draft is marked as closed and cannot be edited.

Screen/UI Design
(Diagrams and mockups will be included in an annex document or interactive
prototype file. Example wireframes will show Enquiry Search Panel, Draft List
Page, and Change Password Modal.)
Field Level Specifications
Field Field Mandato Data Defaul
Value Set Comments
Label Type ry Type t Value

Auto-format
Enquiry
Text Box No String N/A Blank validation, 10
Number
chars

Autocomplete
Customer
Text Box No String N/A Blank based on
Name
profile

Company
Text Box No String N/A Blank Optional
Name

Enquiry Date Current Cannot exceed

No Date N/A
Date Picker Date current date

[Testing,
Service Dropdow Calibration, Mandatory for
Yes Enum Blank
Type n Fabrication, new enquiries
Repair]

Save
Saves data
Draft Button Yes N/A N/A N/A
with timestamp
Button

Change Includes modal

Button Yes N/A N/A N/A
Password validation
Business Rules and Dependencies
Data
Field Label Validation/Business Rules Error Messages
Dependencies

"Password too weak",

Must follow strength Internal Audit
Password "Cannot reuse
policy, check history Log
password"

Enquiry PCSIR Enquiry

Must exist in PCSIR DB "No record found"
Number DB

Enquiry
Cannot be in the future "Invalid date selected" None
Date

Service Must be selected for new "Please select a service Draft

Type submission type" Management

Buttons, Links and Icons

Button Visibl Enabled vs
OnClick Event Other Event Navigate To
Label e Displayed

Query backend & Enabled if

Track Enter Key Status
show status Yes criteria
Enquiry Press Results Page
result entered

Save current Auto-Save Always

Save Draft Yes None
state to DB (5 mins) Enabled

Submit
Submit Validation Enabled when Confirmation
completed form Yes
Enquiry Complete all mandatory Page
for processing

Change Trigger password Enabled when Profile

Submit Key Yes
Password update modal valid fields Settings

Risk Assessment
 Data Loss Risk:

o Mitigated via auto-save drafts, version control

 Security Risk:

o Password encryption, audit logs, IP-based rate limiting

  Accessibility Risk:

o WCAG testing required to support visual impairments

 Interruption Risk:

o Offline draft saving on mobile (to be synced later)

Updated Non-Functional Requirements

 Performance: Under 2 seconds response for search and submission
endpoints

 Reliability: Redundant servers and database failover

 Availability: 99.5% monthly uptime guarantee

 Security: AES encryption for sensitive fields, secure token-based auth

 Auditability: Every user action logged with IP, timestamp, record ID

 Maintainability: Modular microservice design with independent

deployment

 Scalability: Horizontal scaling via container orchestration

(Kubernetes)
Sub Module: Management Portal
Overview

The Management Portal sub-module of the PCSIR Enquiry Management

System is designed to provide an intelligent, secure, and role-specific
dashboard interface to PCSIR’s top management, enabling efficient oversight
of the organization’s enquiry handling processes. This sub-module empowers
management personnel with actionable data-driven insights, thus enabling
strategic decision-making at all organizational levels.

It ensures complete visibility over the enquiry lifecycle, including the status
of each enquiry, deadlines for resolution, average time taken to address
enquiries, and business conversion rates. The portal also integrates real-time
visibility of customer-specific data linked to the enquiries, helping PCSIR
leadership understand patterns, performance gaps, and growth
opportunities.

Software Requirement Analysis

Target Users

Role Access Scope

Enquiries relevant to their

Section In-Charge
department/section

Enquiries routed through their respective

Head of Centers
centers

Director Planning & All active enquiries across centers with

Development planning relevance

Director Lab/Unit Enquiries related to their laboratories or

Role Access Scope

specialized units

Director General Laboratories

Oversight of consolidated lab data
Complex

Broad analytical view across scientific

Member Science
divisions

Chairman PCSIR Full-system visibility with drill-down access

System Integration Requirements

 Authentication System: SSO or LDAP-based with Two-Factor
Authentication (2FA)

 Data Source:

o CRM Database (Customer & Enquiry Data)

o HRMS (User role validation)

o Analytics Engine (reporting metrics computation)

 Technology Stack:

o Frontend: Angular / React

o Backend: NodeJS / Django

o Database: PostgreSQL / Oracle

o Reporting: Highcharts / D3.js or custom analytics engine

o Hosting: PCSIR Central Server Infrastructure with AWS/GovCloud

failover

Security Considerations

 Role-based Access Control (RBAC)

 Fine-grained permissions at dashboard widget level

 End-to-end encryption
  Session timeout management

 Audit logging for all access and data fetch events

3. High-Level Architecture

Architectural Layers

1. Presentation Layer

o Responsive UI compatible with desktops, tablets, and mobile

devices.

o Interface adapts based on logged-in user’s role and access

privileges.

2. Business Logic Layer

o Retrieves enquiry data filtered by role and time constraints.

o Computes metrics (response time, conversion ratios).

o Applies validation and access policies.

3. Data Access Layer

o Performs secure SQL/ORM queries.

o Pulls real-time data from CRM, HRMS, and Enquiry Transaction

Tables.

o Caches summary statistics for performance.

4. Integration Layer

o RESTful API endpoints

o Scheduled jobs for daily refresh of analytics

o Notification push to authorized users (email, SMS)

Sub-Module Name
Management Portal – Enquiry Oversight
Purpose / Description
The purpose of this sub-module is to enable PCSIR’s management at
different levels to access a real-time operational intelligence layer over the
enquiries processed by the organization. By consolidating metrics, KPIs, and
role-specific enquiry data, the portal acts as a centralized decision-support
tool for directors, lab/unit heads, and executive leadership.
Key Capabilities:

 Track real-time status of ongoing, resolved, and escalated enquiries.

 Measure average enquiry handling time per center/unit.

 Monitor compliance with enquiry resolution deadlines.

 View conversion ratios (enquiries that became business).

 Filter data based on centers, sections, customers, time range, and

status.

 Export summarized reports in Excel/PDF formats.

 Drill-down capability from macro stats to individual enquiry details.

 Customer profiles embedded with enquiry histories.

Use Cases

Use Case: EMS-MGT-01

View Summary Dashboard

Primary Actor(s):

All authorized management-level PCSIR personnel, including but not limited

to:

 Section In-Charge

 Head of Centers

 Director Lab/Unit

 Director General (Laboratories Complex)

 Director Planning & Development (P&D)

 Member Science

 Chairman PCSIR

These actors must be authenticated through the PCSIR Central

Authentication System (CAS) and granted role-specific access to the Enquiry
Management Portal (EMP) via the Role-Based Access Control Matrix (RBACM).
Pre-conditions:

1. User Authentication:

o The user must be logged in through the PCSIR ERP secure

authentication mechanism.

o The user's session must be valid and not expired.

o Multi-factor authentication (MFA), if enabled for higher roles (e.g.,

Chairman), must be completed.

2. Authorization & Role Mapping:

o The user must be mapped to a valid management role in the

PCSIR HRMS system.

o The user must have access rights to at least one cost center, lab,
or administrative unit.

3. Data Availability:

o At least one enquiry must exist in the system that is accessible

to the user based on their role, center assignment, or data
privileges.

o System KPIs (key performance indicators), such as "Average

Response Time" and "Conversion Rate," must have been
generated from the Enquiry Analytics Engine.

4. System Readiness:

o The dashboard rendering engine, analytics services, and API

backends must be operational.

o Connection to underlying data warehouses (DW) and ETL

pipelines should be healthy.

Post-conditions:

1. Dashboard Visibility:

o The user sees a dynamic dashboard tailored to their level of

access, populated with real-time metrics and visualizations.

2. Filter Functionality:
 o Users can apply various filters (e.g., date range, center, status)
to refine data views and graphs.

3. Export Capability:

o Users can export summaries and detailed views of enquiries

based on the filters applied.

4. Drill-down Capability:

o Users can click on graphs or KPIs to view underlying enquiry

details in tabular format or as individual records.

5. Caching and Fallback:

o If live data is temporarily unavailable, the dashboard displays the

most recently cached dataset along with a timestamp indicating
data freshness.

Main Success Scenario:

1. User Logs In:

The management user accesses the PCSIR ERP portal and navigates to
the Enquiry Management Module.

2. System Authentication:
The system validates the credentials and retrieves the user’s access
roles, designated centers/labs, and privileges from the HRMS and IAM
(Identity Access Management) module.

3. Dashboard Initialization:
Based on the user's role and domain, the system fetches relevant KPIs
and enquiry metrics from the analytics engine (e.g., total enquiries,
resolved %, converted %, deadline compliance rate).

4. Dynamic Rendering:
The system renders the dashboard with key components:

o KPI Cards: Total Enquiries, Resolved, Converted, Avg Handling

Time

o Visual Charts: Line graphs for time trends, pie charts for status
distribution
 o Tabular Summary: List of individual enquiries with columns such
as: Title, ID, Customer Name, Center, Status, Submission Date,
Deadline

5. Filter Interaction:
The user applies filters to view data for a specific center, date range,
enquiry type, or status.

6. Export Functionality:
The user clicks on "Export to Excel/PDF" to download the currently
visible enquiry dataset (max 5,000 records per session) for further
analysis or reporting.

Alternative Paths:

 A1. No Data Found:

If the filters applied return no matching enquiries, the dashboard will
display a clean, visually styled message:

“No Enquiries Found matching your criteria. Please modify your filters and try
again.”

 A2. Backend Analytics Failure:

If the analytics engine fails to respond within the set timeout (e.g., 5
seconds), the dashboard loads the last cached version of data with an
alert:

“You are viewing cached analytics as of [timestamp]. Live data currently

unavailable.”

 A3. Unauthorized Data Access Attempt:

If a user attempts to access a center or lab outside their privileges, the
system blocks the operation and logs the attempt:

“Access denied: You do not have permission to view this data.”

Business Rules:

Role-Specific Data Visibility:

 Chairman PCSIR: Can access and view *all* enquiries system-wide
across all centers and units.
 Member Science, DGs: Access limited to designated domain/lab
clusters.
 Directors and Section In-Charges: Can only view data assigned to their
lab/unit/section.
Data Freshness:
 KPI data is updated every 6 hours through scheduled ETL jobs. On-
demand refresh is possible via the “Refresh Dashboard” action.
Export Limitation:
 Only 5,000 records can be exported per session to ensure performance
stability.
 File format options: .CSV (default), .XLSX, and .PDF.
Audit Logging:
 All dashboard interactions (login, filter change, export, drill-down) are
logged for audit purposes with timestamp, user ID, and IP address.
Field Access Restrictions:
 Certain fields, like customer email or phone number, are masked or
hidden for roles below the Director level unless explicit access is
granted.
Caching Strategy:
 In case of backend failure, the dashboard must serve data from
Redis/Memcached for the last successful analytics run within a 24-hour
window.

Filter Persistence:
 Filters last used by the user in the previous session are retained and re-
applied on next login unless reset.

Screen/UI Design (to be visualized with Figma/Adobe XD)

Sections

1. Top Bar:

o Welcome message, role badge, logout

o Filter Date Range / Center / Status

2. Dashboard Cards:

o Total Enquiries

o Enquiries Resolved

o Average Response Time (Days)

o Conversion %
 o Enquiries Nearing Deadline

3. Graphs:

o Line Chart: Avg Time Trend

o Funnel: Enquiry to Business Flow

o Pie: Enquiry Categories

4. Data Table View:

o ID, Title, Customer, Date Received, Current Status, Deadline,

Assigned Dept

5. Action Buttons:

o Filter

o Export to Excel / PDF

o View Details (per enquiry row)

Field-Level Specifications

Field Field Mandato Defaul

Data Type Value Set Comments
Label Type ry t

Alphanumer System- Unique

Enquiry ID Label Yes N/A
ic generated Identifier

Dropdow List of PCSIR User Pull from

Center Yes String
n Centers Default HRMS

New, In
Dropdow Progress,
Status No String All Color-coded
n Resolved,
Converted

Deadline Date No Date Valid - Highlight if

Field Field Mandato Defaul
Data Type Value Set Comments
Label Type ry t

Calendar
Picker overdue
Date

Avg (Resolved
Response Label No Decimal Computed - Date – Start
Time Date)

Displayed
Conversio
Label No Percent Calculated - on
n Ratio
Dashboard

Business Rules and Dependencies

Field Validation Rule Error Message Dependency

Date
From ≤ To "Invalid Date Range" Filter Logic
Range

HRMS
Center Must match user role "Unauthorized Center"
Mapping

Cannot be in past on new "Deadline must be in the

Deadline Current Date
enquiry future"

Read-only if enquiry "Cannot edit closed Enquiry

Status
resolved status" Lifecycle

Buttons, Links, Icons

Other Visibl Enabled/ Navigati

Label OnClick Event
Events e Disabled on

Export Triggers data Enabled if rows ≥

- Yes -
Report download (CSV/PDF) 1

Apply Refreshes dashboard Enter key Enabled on valid

Yes -
Filter with filtered data triggers filters

View Loads modal or new Double- Yes Enabled if row /

 Other Visibl Enabled/ Navigati
Label OnClick Event
Events e Disabled on

page with enquiry enquiry/:i

Details click row selected
info d

Clear
Resets filter section - Yes Enabled always -
Filters

Risk Assessment

Probabili
Risk Impact Mitigation
ty

Enquiry volume Slow response Backend pagination and

Medium
overload time caching

Unauthorized Enforce RBAC and session

Data leakage Low
access monitoring

Analytics Schedule daily ETL

Data discrepancy High
misalignment validation

Misuse of
Lack of training Medium Provide training/manuals
dashboard

Updated Non-Functional Requirements

 Performance:

o Dashboard loads within 2–4 seconds for 90% of users.

o Filters applied should update data within 1.5 seconds.

 Scalability:

o Should support up to 10,000 concurrent sessions without

performance drop.

o Microservices architecture recommended.

 Security:
 o Token-based authentication + Role authorization

o Auto-logout after 15 min idle

 Reliability:

o 99.8% uptime

o Daily data integrity checks

 Maintainability:

o Modular service structure

o Detailed logs and error tracing

 Auditability:

o Every access is logged with timestamp, IP, and operation

o Historical reporting retained for 3 years

 Responsiveness:

o Mobile-first design

o Fully functional on Chrome, Edge, Firefox

Sub Module: Alerts & Notification Module

Overview

The "Alerts & Notification Module" is a cross-cutting, real-time

communication system integrated into the PCSIR Enquiry Management
Framework. It enables timely and role-sensitive communication through
Short Messaging Service (SMS) and push notifications on the PCSIR mobile
application (Android and iOS). This ensures prompt information dissemination
across stakeholders, both internal and external, thereby streamlining
operations, reducing response times, and enhancing transparency in PCSIR
services.

This module is engineered to:

  Notify customers upon successful registration, enquiry submission, and
quotation issuance.

 Alert internal PCSIR officers upon assignment, escalation, or

completion of enquiries.

 Facilitate a multi-channel, template-driven communication

infrastructure.

 Maintain a complete audit trail and message delivery status.

Software Requirement Analysis

Functional Requirements:

 Auto-triggered notification dispatch based on pre-configured events.

 SMS integration via telecom gateway APIs (Zong, Jazz, Twilio, etc.).

 Mobile app push notifications using Firebase Cloud Messaging (FCM).

 Admin interface for managing templates, audiences, and message

history.

 Delivery status and retry mechanisms.

Non-Functional Requirements:

 High availability (99.9%) and scalability.

 Secure communication with encrypted APIs.

 Unicode support for multilingual messages.

 Delivery within 5 seconds for SMS and <2 seconds for app
notifications.

High-Level Architecture
 Frontend Interfaces: Admin Dashboard, Mobile App Notification
Panel

 Backend Components: Notification Engine, Event Bus, SMS

Dispatcher, Push Dispatcher

 Third-party Integrations:

o SMS Gateway API

 o Firebase Cloud Messaging

 Databases:

o Notification Logs

o Template Definitions

o Delivery Reports

Module: Enquiry Management System

Sub-Module: Alerts & Notification
Purpose/Description
This sub-module governs how the system informs various stakeholders at
critical workflow points, such as:

 User registration

 Enquiry initiation

 Quotation creation and delivery

 Enquiry status changes (assigned, resolved, escalated)

 Monthly or periodic summary alerts

These notifications are critical to keeping all parties informed and enabling
quick response and follow-up actions.

Use Cases
Use Case ID: AN-001

Use Case Name: Customer Registration Notification

Primary Actor(s): Registered Customer, System Notification Engine
Pre-conditions:

 Customer has completed and submitted the registration form

successfully.
  Valid mobile number and app access credentials (if applicable) are
provided.

 SMS gateway and App Notification services are functional.

Post-conditions:

 Customer receives a notification (SMS and/or App) confirming

successful registration.

 Registration ID and initial instructions for portal login are shared.

 Notification log is created in the audit trail.

Main Success Scenario:

1. Customer submits the registration form.

2. Backend service validates the form.

3. Upon successful validation, customer record is saved in the database.

4. System invokes the notification module.

5. A predefined welcome message template is populated with the

Registration ID.

6. SMS is sent using integrated SMS gateway.

7. App notification is triggered through Firebase/OneSignal/Push

Notification Service.

8. Customer receives both SMS and App alert.

Alternative Path:

 If SMS fails:

o System retries up to 3 times with incremental back-off.

o If still unsuccessful, error is logged and flagged in the admin

panel.

o Admin receives email or internal alert for manual intervention.

 If App Notification fails:

o Similar retry and escalation protocol is followed.

Business Rules:
  Notification body must not contain confidential or sensitive information
(e.g., passwords).

 Language must comply with PCSIR communication policy.

 Only pre-approved templates are allowed.

 Message must include Registration ID, login link (if applicable), and
contact help desk reference.

Use Case ID: AN-002

Use Case Name: Enquiry Submission Notification

Primary Actor(s): Customer, Enquiry Handler, System Notification Engine
Pre-conditions:

 Customer has successfully filled out and submitted the enquiry form.

 Enquiry details are validated and stored.

 Enquiry ID is generated.

 Notification services are active.

Post-conditions:

 SMS/App acknowledgment is sent to the customer.

 Internal notification is optionally sent to the Enquiry Handler or Section

In-Charge.

 Log of message delivery is stored.

Main Success Scenario:

1. Customer completes and submits an enquiry.

2. System saves the enquiry and generates an Enquiry Reference ID.

3. Notification module is triggered.

4. SMS and App Notification template is fetched, populated with dynamic

values (e.g., Enquiry ID).

5. Message dispatched via SMS and App.

6. Audit record saved with delivery status.

7. Customer and internal handler are informed.

Alternative Path:
  If message dispatch fails:

o Retry logic initiated with up to 3 attempts.

o On continued failure, logs are updated, and alert is triggered to

Admin.

Business Rules:

 Only the Enquiry Reference ID is allowed in the message.

 Message format must adhere to approved content templates.

 No details of services or pricing may be shared via SMS.

 Timestamp of submission and contact reference is optional.

Use Case ID: AN-003

Use Case Name: Quotation Generation Notification

Primary Actor(s): Customer, Lab Director, Notification Engine, Admin Panel
Pre-conditions:

 Quotation has been finalized and approved by designated authority.

 Quotation record is saved and assigned a unique Quotation ID.

 Customer details (especially contact information) are valid.

Post-conditions:

 SMS and App notification are sent to customer.

 Notification includes Quotation ID and link to login.

 Log created for delivery and traceability.

Main Success Scenario:

1. Lab Director or Enquiry Handler approves quotation.

2. System saves final quotation and assigns Quotation ID.

3. The notification engine retrieves the appropriate message template.

4. The template is populated with Quotation ID and secure portal login

URL.

5. SMS is dispatched through the SMS gateway.

6. App notification pushed via push service.

 7. The message is received by the customer.

8. System logs the message, updates the audit trail.

Alternative Path:

 If SMS dispatch fails:

o Retry is initiated with increasing intervals.

o If all attempts fail, the admin is notified via dashboard

alert/email.

 If App notification fails:

o Retry with two alternate delivery strategies.

o If the customer device is unreachable, the message is marked as

pending in the backend until the next login.

Business Rules:

 No price, value, or monetary figure can be present in SMS body.

 Quotation ID and secure login instructions are the only dynamic

elements allowed.

 All messages must be logged with delivery status and timestamp.

 Admin can manually resend notifications if automated attempts fail.

Screen/UI Design
(Screen mockups not attached, to be designed using Figma/Adobe XD)

 Notification Template Management Interface

 Message Log Viewer (filters for event, status, user, etc.)

 Mobile App Notification Panel with bell icon

Field Level Specifications

Field Field Mandato Data Defaul
Value Set Comments
Label Type ry Type t Value

Message Text Area Yes Text N/A N/A Supports

Template variable
 placeholders

Default can be
Delivery Dropdow
Yes Enum SMS, App, Both SMS user
Channel n
preference

Registration,
Used to map
Trigger Dropdow Enquiry
Yes Enum None events to
Event n Submission,
templates
Quotation, etc.

Customer,
Dynamically
Recipient Dropdow Employee,
Yes Enum N/A fetched based
Type n Director,
on event
Chairman

Business Rules and Dependencies

Field Label Validation/Business Rules Error Messages Data Dependencies

Cannot be empty; must

Message "Template body Linked to Trigger
include at least one
Template is required" Event
variable

Recipient "Invalid mobile Pulled from

Must be a valid format
Phone No. number" registration/profile

SMS API "SMS Gateway Stored in the

Must be active and verified
Key not responding" configuration table

Buttons, Links, and Icons

Other Enable
Label On Click Event Visible Navigate To
Event d

Test Sends a test message

- Yes Yes N/A
Notification using sample data

Save Saves a new template

- Yes Yes -
Template definition
Message /notification/
Redirects to log viewer - Yes Yes
Log log

Deletes message logs No (Admin

Clear Logs - Yes -
older than X days only)

Risk Assessment

Probabilit
Risk Impact Mitigation Strategy
y

SMS API
Medium High Fallback provider configuration
Downtime

Notification Mediu
Low Daily quota and opt-in setting
Spam m

Language Mediu Use UTF-8 with Unicode

Medium
Encoding m templates

Use queuing with priority

Delivery Delays Medium High
dispatching

Updated Non-Functional Requirements

 Performance: Notifications delivered within 2–5 seconds

 Availability: 24/7 availability with 99.9% uptime SLA

 Security: HTTPS, Tokenized APIs, Audit logs

 Localization: Urdu and English template support

 Scalability: Horizontally scalable dispatch engines

 Logging & Monitoring: Real-time dashboards + scheduled reports

Test Management System
Sub Module: Test Parameters
Overview
The Testing & Parameterization module of PCSIR’s ERP aims to provide a
comprehensive framework to define, maintain, and manage test parameters,
associated commodities, matrices, laboratory allocation, test methods,
standards, and associated test rates. This module ensures consistency,
standardization, and traceability in managing technical testing requirements
across all PCSIR units including Laboratories Complexes, Mono-Functional
Labs, and Training Institutes.

This document defines the complete functional specification in line with

PCSIR’s operational requirements and quality control mandates. It also
incorporates hierarchical approvals, standard assignment, rate revision
mechanisms, and parameter packaging for streamlined customer service.

Software Requirement Analysis

 Enable centralized management of testing parameters.

 Maintain hierarchical structure of PCSIR units, centers, and sections.

 Allow commodity-to-parameter mapping (many-to-many relationship).

 Allow matrix definition per commodity-parameter combination.

 Enable allocation of laboratories down to the section level.

 Provide ability to define test methods and link standards.

 Track accreditation, result types, turnaround time, and measurement

uncertainties.

 Facilitate test rate management with revision histories.

 Enable hierarchical approvals for parameter activation.

 Allow creation of test parameter packages.

High-Level Architecture
 Frontend: Angular/React-based UI for form entry, dashboard, and
hierarchical views.

 Backend: RESTful API built using Django/Node.js connected to

relational database (PostgreSQL/MySQL).
  Database: Relational schema with referential integrity to manage
units, centers, commodities, parameters, standards, and test data.

 Security Layer: RBAC-based access for Scientist, Section Head, and

Center Head.

 Workflow Engine: BPMN-based configurable engine to manage

approval flows.

Module Name: Testing & Parameterization

Sub-Module: Unit-Center-Section Setup

Purpose / Description

Defines the structure of PCSIR's organization in the context of laboratories

and training institutes. Allows mapping of Units to Centers and Centers to
Sections, which serve as the foundation for assigning test responsibilities.

Sub-Module: Commodity and Parameter Definition

Purpose / Description

Enables creation of parameters and commodities with many-to-many

mapping. Allows users to define new commodities, associate them with one
or more test parameters, and further classify them into sample matrices.

Sub-Module: Sample Matrix Assignment

Purpose / Description

Allows the mapping of test parameters to commodity-specific sample

matrices such as Solid, Liquid, Gas, etc. This layer facilitates lab allocation
and test methodology.

Sub-Module: Laboratory & Method Mapping

Purpose / Description

Defines the laboratory responsible for the test by assigning Units → Centers
→ Sections. Allows further configuration of the test method, accreditation,
result type, turnaround time, and measurement uncertainty.

Sub-Module: Standard and Range Assignment

Purpose / Description
Provides mechanisms to assign multiple standards to a single test method,
including value ranges, and handles validation logic for limits.

Sub-Module: Rate Management and Revisions

Purpose / Description

Handles rate definitions and revisions for both standard and urgent test
scenarios. Allows bulk and individual rate updates across multiple
organizational levels.

Sub-Module: Parameter Approval Workflow

Purpose / Description

Implements an approval chain from Scientist → Section Head → Center Head

before a test parameter is marked Active. Provides audit trail and rollback
mechanism.

Sub-Module: Test Package Creation

Purpose / Description

Facilitates grouping of test parameters into serviceable packages to

streamline offerings for external clients.

Use Cases – Testing & Parameterization Module

Use Case 1: Define New Test Parameter

 Use Case ID: UC-TST-001

 Use Case Name: Define New Test Parameter

 Module: Testing & Parameterization

 Sub-Module: Test Parameter Definition

 Primary Actor(s): Scientist/Engineer

Stakeholders:

 Scientist/Engineer (Initiator)

 Section Head (Reviewer)

 Center Head (Approver)

 System Administrator (Audit and Logs)

Pre-conditions:
  The user must be authenticated in the system via valid login
credentials.

 The commodity and unit (center, section) must be pre-defined in the

system.

 User must belong to a valid organizational unit with permission to

create parameters.

Post-conditions:

 The new Test Parameter is stored in Draft status.

 The parameter record is routed through a workflow engine for

approval.

 System logs are updated with user ID, timestamp, and operation
details.

Main Success Scenario:

1. Scientist logs into the system and navigates to "Create New Test
Parameter".

2. Scientist fills in the following details:

o Test Parameter Name

o Related Commodities (multiple selection allowed)

o Sample Matrix for each Commodity

o Laboratory hierarchy (Unit → Center → Section)

o Testing Method

o Accreditation Status

o Result Type (Quantitative/Qualitative)

o Time to Complete

o Test Rate (Normal and Urgent)

o Measurement of Uncertainty

o Applicable Standards (WHO, PSQCA, etc.)

3. Scientist clicks “Submit for Approval”.

4. The parameter is saved in Draft and sent to the Section Head.

 5. An audit trail is generated.

Alternative Paths:

 A1: If the Scientist clicks “Cancel”, the operation is aborted, and no

data is saved.

 A2: If required fields are left empty, validation messages appear (e.g.,
“Commodity is required”, “Test Rate must be numeric”).

 A3: If the parameter-commodity combination already exists, the

system displays: “Duplicate entry not allowed”.

Business Rules:

 Each combination of Test Parameter + Commodity must be unique.

 Mandatory fields must be validated before submission.

 Maximum character limits for fields must be enforced (e.g., Parameter

Name: 100 characters).

 If a commodity is already assigned to a parameter, a warning must

appear before duplicate mapping.

Use Case 2: Approve Test Parameter

 Use Case ID: UC-TST-002

 Use Case Name: Approve Test Parameter

 Module: Testing & Parameterization

 Sub-Module: Test Parameter Approval

 Primary Actor(s): Section Head, Center Head

Stakeholders:

 Section Head (Level 1 Approver)

 Center Head (Final Approver)

 Scientist/Engineer (Request Initiator)

 Admin (Workflow Configuration)

Pre-conditions:

 Test Parameter must be in Submitted state by Scientist.

  Approvers must be part of valid approval hierarchy for the Center and
Section.

Post-conditions:

 The Test Parameter is marked as Active in the system.

 Audit log of approval is created with timestamps and approver IDs.

 Notifications are sent to the requesting Scientist.

Main Success Scenario:

1. Section Head logs into the system and navigates to “Pending

Approvals”.

2. Section Head reviews all test parameter details and clicks Approve.

3. Notification is sent to Center Head.

4. Center Head logs in, reviews, and approves the parameter.

5. System updates the status to Active, with the current timestamp.

Alternative Paths:

 A1: Section Head rejects the parameter. The record is marked

“Rejected”, and Scientist receives feedback/comments.

 A2: Center Head rejects after Section Head approval. Record is

returned to Section Head with remarks.

 A3: If approver is not available (leave, unassigned), system escalates

after a defined period (e.g., 3 business days).

Business Rules:

 Approval must follow strict sequence: Section Head → Center Head.

 Rejected items must allow Scientist to re-submit after editing.

 Only one active version of a Test Parameter for a Commodity may exist
across the system.

 Approvers must digitally sign/confirm their action (via password or

biometric where applicable).

Use Case 3: Revise Test Rate

 Use Case ID: UC-TST-003

  Use Case Name: Revise Test Rate

 Module: Testing & Parameterization

 Sub-Module: Test Rate Management

 Primary Actor(s): Scientist, Admin

Stakeholders:

 Scientist/Engineer (Parameter Owner)

 System Admin (Bulk Revision)

 Section Head (Reviewer)

Pre-conditions:

 Test Parameter must be in Active status.

 User must have permission to manage test rates.

Post-conditions:

 New rate is saved with percentage and reason.

 System retains previous rate for audit history.

 Timestamp, modifier name, and change notes are recorded.

Main Success Scenario:

1. User accesses "Revise Test Rate" interface.

2. Selects a Test Parameter.

3. Enters either:

o Flat New Rate (manual input)

o Percentage Increment (e.g., 10%)

4. System calculates the new rate based on the previous rate.

5. User provides a justification note and submits.

6. Revised rate becomes effective with timestamp.

Alternative Paths:
  A1: If user clicks “Preview Revision”, the system shows the
before/after rate impact.

 A2: If manual override is enabled, user enters the new rate directly
(bypassing % rule).

 A3: If revision date is set in the future, the rate is scheduled with an
effective date.

Business Rules:

 Historical rates must never be overwritten.

 Revisions must include: Reason, Approver (if applicable), and

Timestamp.

 Revision can be applied system-wide, Unit-wise, Center-wise, Section-

wise, or Parameter-specific.

 Scheduled revision feature must allow batch updates with preview and
rollback.

Use Case 4: Define Test Package

 Use Case ID: UC-TST-004

 Use Case Name: Define Test Package

 Module: Testing & Parameterization

 Sub-Module: Test Package Management

 Primary Actor(s): Scientist, Admin

Stakeholders:

 Scientist (Package Creator)

 Section Head (Reviewer)

 Center Head (Approver)

 Billing Department (Pricing & Invoicing)

Pre-conditions:

 User must be authenticated and have permission to create packages.

 Test Parameters included in the package must exist and be Active.

Post-conditions:

 Test Package is created in Draft status and routed for approval.

 Package pricing and discount rules are associated.

 Audit trail records package creation.

Main Success Scenario:

1. Scientist navigates to “Create Test Package”.

2. Enters package details:

o Package Name

o Description

o List of Test Parameters (select multiple)

o Package Pricing (fixed or calculated based on parameters)

o Applicable Commodities

o Validity Period

3. Submits package for approval.

4. Section Head reviews and approves.

5. Center Head finalizes approval and activates the package.

6. Package is available for sample testing orders.

Alternative Paths:

 A1: Package creation cancelled before submission; no data saved.

 A2: Invalid or inactive parameters selected; system blocks submission

with error messages.

 A3: Package sent back to Scientist for modification on rejection.

Business Rules:

 Package name must be unique within the center.

 Package must include at least one active parameter.

  Pricing must comply with current rate revisions and discount policies.

 Only approved packages are available for customer quoting and billing.

Use Case 5: Map Sample Matrix to Laboratory Section

 Use Case ID: UC-TST-005

 Use Case Name: Map Sample Matrix to Laboratory Section

 Module: Testing & Parameterization

 Sub-Module: Sample Matrix Management

 Primary Actor(s): Scientist, Lab Manager

Stakeholders:

 Scientist (Mapping Initiator)

 Laboratory Manager (Approver)

 Quality Control (QC) Team

Pre-conditions:

 Sample Matrices and Laboratory Sections must be predefined in the

system.

 User must have permission to manage mappings.

Post-conditions:

 Mapping saved and active in the system.

 Notifications sent to QC team and related personnel.

 Audit logs updated with mapping details.

Main Success Scenario:

1. The scientist opens the “Map Sample Matrix” interface.

2. Selects a Sample Matrix (e.g., Water, Soil, Air).

3. Selects one or more Laboratory Sections for analysis.

 4. Defines special handling instructions or test limitations if applicable.

5. Saves and submits mapping for Lab Manager approval.

6. Lab Manager reviews and approves the mapping.

7. Mapping becomes active and usable in test orders.

Alternative Paths:

 A1: User cancels operation; no changes saved.

 A2: Mapping conflicts with existing restrictions; system warns and

blocks submission.

 A3: Mapping rejected and sent back with comments.

Business Rules:

 Each Sample Matrix can be linked to multiple sections but cannot

conflict with safety or quality policies.

 Special handling instructions must comply with laboratory safety

standards.

 Mappings must be reviewed annually for validity.

Screen/UI Design
(To be attached as UI wireframes in design document)

 Parameter Creation Form

 Commodity Management Dashboard

 Sample Matrix Assignment Wizard

 Lab Allocation Screen

 Method & Standards Interface

 Rate Management Grid

 Parameter Approval Workflow Interface

 Package Creation Screen

Field-Level Specifications
Field Label Field Mandato Data Value Set Default Comments
 Type ry Type Value

Linked to
Dropdow PCSIR Unit
Unit Name Yes String - database of
n List
units

Center Dropdow Dynamic Cascading

Yes String -
Name n by Unit field

Section Dropdow Dynamic Cascading

Yes String -
Name n by Center field

Must be
Parameter
Text Box Yes String - - unique with
Name
Commodity

Multi- Multiple
Commodity Select Predefined commodities
Yes String -
Name Dropdow list can be
n linked

Multi-
Liquid, Commodity-
Sample Select
Yes Enum Solid, Gas, - specific
Matrix Dropdow
etc. matrices
n

Method used
Test Method Text Box Yes String - -
for test

Accredited, Non-
Radio Boolea
Accreditation Yes non- Accredite -
Button n
accredited d

Qualitative,
Dropdow
Result Type Yes Enum Quantitativ - -
n
e

Default Test Decima Initial test

Text Box Yes - 0.00
Rate l rate

Optional
Urgent Test Decima
Text Box No - 0.00 urgent test
Rate l
rate
 Format:
Turnaround Time
No String - - Days-Hours-
Time Picker
Minutes

Measuremen
Lab input
t of Text Box No String - -
field
Uncertainty

Multi-
PSQCA, Standards
Select
Standard No String WHO, - assigned to
Dropdow
NEQS, etc. method
n

Applicable
for
Min Value Number No Float - -
quantitative
tests

Must be
greater than
Max Value Number No Float - -
Min if
present

Controls
Boolea
Active Status Checkbox Yes - True visibility and
n
usage

Business Rules and Dependencies

Validation/Business Data
Field Label Error Messages
Rule Dependencies

Parameter Must be unique per "Parameter already Commodity

Name Commodity exists" Selection

Min/Max "Max value must Result Type =

Max must be > Min
Value exceed Min" Quantitative

Must be positive
Test Rate "Rate must be > 0" -
decimal
Buttons, Links, and Icons
Enable
Label OnClick Event Visible Navigate To
d

Submit for Submit form to

Scientist only True Approval Queue
Approval workflow engine

Marks parameter Approvers

Approve True Main Dashboard
Active only

Sends back with Approvers

Reject True Edit Screen
remarks only

Authorized Rate Revision

Revise Rate Opens revision modal True
Roles History

Add to Opens packaging Package

Admin only True
Package screen Management

Risk Assessment
 Data Complexity: High data inter-dependencies may require tight
referential constraints.

 Approval Workflow: Improper rejection routing may disrupt

workflows.

 Rate Revision Conflicts: Overlapping revisions can lead to incorrect

rate application.

 Role Mismanagement: Unauthorized access can lead to

misconfiguration of test methods.

Updated Non-Functional Requirements

 Performance: Each form load should not exceed 2 seconds.

 Availability: 99.9% uptime required.

 Scalability: System should support >500 simultaneous users.

 Security: Role-Based Access Control (RBAC), encryption at rest and

transit.

 Audit Trail: All rate changes, approvals, and revisions should be

logged.
  Mobile Responsive: Should be usable on tablets and mobile devices
by field scientists.

 Integration Ready: Should allow integration with central PCSIR ERP

and external lab equipment interfaces in future phases.

Sub Module: Quotation, Invoicing, and Payment

Overview
The Quotation, Invoicing, and Payment module is an essential part of the
PCSIR ERP system that bridges the interaction between customer enquiries
and the financial settlement process. This module is triggered once a
customer raises an enquiry via the Enquiry Management System. The
outcomes of such enquiries include notification of unavailability of services,
requests for meetings or visits, or a quotation detailing cost and terms for
the requested services.

The main goals of the module are:

 Automating quotation and invoice generation.

 Embedding detailed technical and financial data into documents.

 Allowing dynamic integration of payment instructions and account

details.

 Supporting multiple modes of payment including online payment

mechanisms with PSID generation.

 Facilitating printing, archiving, and digital communication of all

financial documents.

 Ensuring compliance with financial, tax, and operational regulations.

Software Requirement Analysis

Functional Requirements:
  Integration with the Enquiry Management System to fetch enquiry
details.

 Generate quotation documents with detailed information, covering

letters, bank instructions, and special clauses.

 Allow selection from a dynamic list of bank accounts for payment.

 Support definition and attachment of special instructions to be

displayed on quotations and invoices.

 Allow generation of invoices against approved quotations.

 Enable PSID (Payment Slip ID) generation and integration with online
banking channels.

 Maintain status and logs for each payment method and transaction.

 Handle offline payment mechanisms such as Cheques, Demand Drafts

(DD), and Pay Orders (PO).

 Provide validation rules and dependencies for financial document

generation.

 Role-based access to prevent unauthorized operations.

Non-Functional Requirements:

 Scalability to support new accounts, services, and payment

mechanisms.

 High availability (24/7 service support).

 Data encryption and security compliance.

 Audit trail for document generation, user actions, and transactions.

 Seamless API integrations with payment gateways and reference

systems.

High-Level Architecture
 Frontend: ReactJS with Redux for state management, integrated via
REST APIs.

 Backend: NodeJS/Express or Spring Boot with RESTful web services.

 Database: PostgreSQL with relational data design and indexing.

 Integration Layers:
 o Enquiry Management System

o Reference Data System

o Bank Payment Gateways (e.g., 1LINK, JazzCash, Easypaisa)

o Document Management System (for archiving)

 Authentication and Authorization: OAuth 2.0 and PCSIR Central

Identity Management.

 Document Generation Engine: JasperReports or Docmosis with

dynamic template injection.

 Payment Gateway Integration: HTTPS with tokenized

authentication; PSID APIs

Module Name: Quotation, Invoicing, and Payment

Sub-Module: Quotation Generation

Purpose/Description: This sub-module enables users (typically ILOs and

center staff) to generate customized quotations based on an enquiry. The
quotation includes detailed line items corresponding to requested testing,
calibration, or repair services, and can embed tax-related exemptions, terms,
and bank instructions.

Sub-Module: Invoice Management

Purpose/Description: Facilitates invoice creation against approved

quotations. Each invoice includes legal disclaimers, structured payment
details, payment due dates, and links to customer information, services
rendered, and accounts.

Sub-Module: Payment Handling

Purpose/Description: This component deals with the execution and

tracking of payments. It supports multiple payment methods and integrates
with national bank APIs to generate PSIDs for electronic payment
reconciliation.

Use Cases
Use Case ID: QIP-UC-001
Use Case Name: Generate Quotation Primary Actors: ILO, Center Officer
Preconditions:

 A valid enquiry must exist.

 Services requested must be mapped to valid PCSIR services.

Postconditions:

 A system-generated quotation (PDF + DB entry).

 Notification sent to the customer.

Main Success Scenario:

1. ILO accesses Enquiry Management interface.

2. Filters enquiries eligible for quotation.

3. Opens quotation form, selects required bank account.

4. Adds one or more special instructions.

5. Selects services from approved lists.

6. System auto-generates quotation including costs, terms, parameters.

7. A printable Quotation Cover Letter is generated.

Alternative Paths:

 If no valid service → System shows “Service Unavailable” notice.

 If additional meeting required → Generates Request for Meeting form.

Business Rules:

 Quotation must be linked to only one enquiry.

 At least one service/test parameter must be selected.

 A valid PCSIR account number must be chosen.

Use Case ID: QIP-UC-002

Use Case Name: Generate Invoice Primary Actors: ILO, Accounts Staff
Preconditions:

 Quotation must be in ‘Approved’ status.

Postconditions:
  Invoice stored in system and available for printing/email.

Main Success Scenario:

1. User selects approved quotation.

2. System auto-fills customer and service details.

3. User adds payment instructions.

4. Invoice is generated with legal identifiers and invoice number.

Alternative Paths:

 Attempt to invoice unapproved quotation → Error shown.

Business Rules:

 Each invoice maps to only one quotation.

 Invoice number must be unique and auto-incremented.

Use Case ID: QIP-UC-003

Use Case Name: Record Payment Primary Actors: Customer, Accounts

Department Preconditions:

 Valid invoice must exist.

Postconditions:

 Payment marked as completed.

 Receipt generated.

Main Success Scenario:

1. Customer initiates payment via PSID or traditional method.

2. System verifies and logs transaction.

3. Receipt is auto-generated and status is updated.

Alternative Paths:

 If PSID fails to generate → User redirected to offline payment.

Business Rules:

 Duplicate PSIDs are not allowed.

 Only full payment marks invoice as ‘Paid’. Partial payments trigger

‘Pending’.

UI/Screen Design
 Quotation Generation Form (Grid View with services + bank account
dropdown)

 Special Instructions Modal

 Quotation Preview Page

 Invoice Form

 Invoice Preview and Print Page

 PSID Generation Screen

 Payment Entry Interface

Field-Level Specifications
Field Mandator Default Comment
Type Data Type Value Set
Label y Value s

Auto- Linked to
Enquiry
Text Box Yes String N/A generate Enquiry
Number
d Module

Lookup
Customer Auto-
Text Box Yes String N/A from
Name filled
Enquiry

Testing, Affects
Nature of Dropdow
Yes Enum Calibratio Testing template
Work n
n, Repair population

PCSIR Reference PCSIR- Dynamic

Dropdow
Bank Yes String Account NIDA-16- from Ref
n
Account List 3 Data
Special From
Multi-
Instruction No String Clause list None Reference
select
s Data Table

System-
Invoice Auto- Unique,
Text Box Yes String generate
Number generated sequential
d

Cheque,
Payment Dropdow Required
Yes Enum DD, PO, Online
Method n for receipt
Online

Only when
Conditionall Alphanumer Auto via
PSID Text Box None Payment
y ic API
= Online

Receipt Auto- For printed

Text Box No String N/A
Number generated record

Business Rules and Dependencies

Field Label Business Rules Error Message Data Dependencies

"Duplicate PSID Generated if

PSID Must be unique
detected" Payment = Online

Quotation Must be linked to "Invalid quotation Lookup from Enquiry

Number valid enquiry context" module

PCSIR Bank "Bank account must List managed by

Cannot be null
Account be selected" Admin module

Invoice Auto-generated in "System error in Depends on last

Number ascending order invoice generation" invoice ID

Buttons, Links, and Icons

Visibl Redirect/
Label OnClick Event Enabled
e Navigate To
Generate Calls quotation API, Quotation
Yes Yes
Quotation renders preview Preview

Generate Validates quotation, Conditional (If

Yes Invoice Screen
Invoice calls invoice API Approved)

Generate API call to bank Conditional

Yes PSID Info Modal
PSID system (Online Payment)

Submit Validates fields,

Yes Yes Payment Receipt
Payment stores record

Risk Assessment

Risk Mitigation Strategy

Implement retries and fallback to offline

Online payment gateway timeout
options

Incorrect special instruction Controlled via centralized reference data

display admin panel

Manual entry errors in payment Add field validations and date/number

data masking

Data duplication in invoices or

System-level checks for uniqueness
quotations

Bank account obsolescence Periodic sync with Finance Department

Updated Non-Functional Requirements

NFR Category Requirement Detail

System should be available 99.95% of the time excluding

Availability
maintenance windows
 Quotations/Invoices should be generated within 2-5
Performance
seconds

Role-based access, TLS encryption for PSID, field-level

Security
validation

Scalability Support for unlimited accounts, services, instructions

Logging and
Track user actions, timestamp events for compliance
Auditing

Must support JSON/XML-based API exchanges with banks

Interoperability
and ERP modules

Sub-Module: Sample Management

Overview
The Sample Management sub-module is an integral component of the
Analytical Testing Module within the PCSIR ERP system. It is designed to
comprehensively handle all operational processes involving the intake,
registration, identification, and categorization of physical samples submitted
by clients for analytical testing. The sub-module comes into operation
immediately after the successful processing of the payment (via online
channel, POS, or traditional instruments such as bank drafts), or in case of
gratis testing services, upon approval by the Head of the Unit.

This sub-module ensures strict traceability, error-free data entry, barcode/QR

code tagging for each testable sample, and includes provisions for the
handling of irregular samples, such as those too small or fragile to support
direct code labeling. The system allows for efficient batch handling of
identical samples, supports reusable identification tagging (e.g., zip ties),
and integrates with external hardware (printers, barcode scanners) to
facilitate end-to-end digital traceability.

Software Requirement Analysis

Functional Requirements:

1. Case Initialization:
 o Only authorized ILO Operators can initiate case creation post
payment or gratis approval.

o Case must be associated with an existing, verified Enquiry.

2. Sample Data Entry:

o Sample Collection Operators can fetch associated Enquiry data.

o Allow batch entry for identical samples (e.g., 5 bags of 1kg rice).

o Support for both detailed and minimal sample information entry

depending on complexity.

3. Barcode/QR Code Management:

o Generate individual barcodes/QR codes per quantity specified.

o Preview and print functionality built into the UI.

o Attach each generated code to a physical tag or label.

4. Small Sample Handling:

o Provide an alternate mechanism (e.g., zip tie tags) for samples

where pasting is impractical.

o Maintain mapping of code to sample even if external tagging is

used.

5. Validation & Audit Trail:

o Validate that no duplicate entries exist within a case.

o Each action logged with timestamp, operator identity, and

location.

6. Error Handling & Notifications:

o Alert users in case of invalid data, unverified payment, or

hardware failure.

o Maintain logs of failed barcode print attempts.

7. Integration Requirements:

o Payment Gateway (to verify payment status).

o Enquiry Management System (for fetching enquiry metadata).

 o Barcode Printer API (e.g., Zebra, Dymo).

o Sample Storage Mapping (optional in later phase).

High-Level Architecture
Frontend: Angular-based responsive user interface using PCSIR Design
System components
Backend: Node.js (Express) RESTful API Layer
Database: PostgreSQL with support for JSONB fields for flexible sample
metadata
Security: JWT-based authentication, role-based access control
Middleware: Integration module for hardware interface (barcode printers)
Logging: Audit Trail and Transactional Logs stored in centralized logging
service (e.g., Elastic Stack)
Hosting: Deployed on PCSIR’s private cloud infrastructure (VMs +
Kubernetes)

Module Name: Analytical Testing

Sub-Module Name: Sample Management

Purpose/Description:

The purpose of the Sample Management sub-module is to digitize and

streamline the operational workflows related to the handling of physical
samples in analytical testing scenarios. From the moment a sample is
physically received, this sub-module governs its digital representation,
ensures regulatory compliance through traceable identifiers, and prepares it
for downstream workflows including testing, reporting, and archiving. It plays
a critical role in ensuring sample integrity, avoiding duplication, and
supporting laboratory accreditation through robust record-keeping.

Use Cases
Use Case 1

 Use Case ID: SM-001

 Use Case Name: Create Analytical Testing Case

  Primary Actor(s): ILO Operator

 Pre-conditions:

o Valid Payment Transaction or Gratis Approval

o Active Enquiry Record

 Post-conditions:

o Unique Case ID generated and stored

o Case linked with Enquiry and visible in dashboard

 Main Success Scenario:

1. ILO Operator logs in with role-based credentials.

2. Selects the Enquiry via dropdown list.

3. Verifies payment or gratis approval status.

4. Enters basic sample description.

5. Submits form.

6. Case ID is generated and acknowledged.

 Alternative Path:

o Payment unverified → block submission.

o Duplicate case attempt → system warning.

 Business Rules:

o Only one active case per Enquiry ID.

o Gratis cases must be approved in workflow before this step.

Use Case 2

 Use Case ID: SM-002

 Use Case Name: Record Sample Entry and Generate Codes

 Primary Actor(s): Sample Collection Operator

 Pre-conditions:

o Case must be already created and active

o Operator must be authenticated

  Post-conditions:

o Sample data saved with metadata

o Unique QR codes/barcodes generated and printable

 Main Success Scenario:

1. Operator navigates to Sample Entry screen.

2. Selects Case ID.

3. Enters commodity name, quantity, type, and packaging info.

4. Selects code tagging method (QR/Zip).

5. Saves record.

6. System generates codes and activates print dialog.

 Alternative Path:

o Invalid quantity (e.g., zero) → system blocks submission.

o Printer not connected → system displays alert.

 Business Rules:

o One sample entry per unique commodity per case.

o Quantity above 1 triggers code cloning logic.

Screen/UI Design
Screen 1: Case Creation
Fields: Case ID (auto), Enquiry Dropdown, Commodity Name, Sample
Summary, Submit Button

Screen 2: Sample Entry

Fields: Case ID (auto), Sample Type, Sample Quantity, Handling Method,
Code Preview Grid, Save Button, Print Button

Screen 3: QR Code Preview/Print

Components: Dynamic QR Code Table, Preview Toggle, Print Queue Status

Field-Level Specifications
Field Mandato Data Defaul
Field Label Value Set Comments
Type ry Type t

Case ID Auto-ID Yes UUID System Auto Hidden in UI

 Generated

Lookup-based
Dropdow Linked
Enquiry ID Yes UUID None from Enquiry
n Enquiries
Module

Commodity Validated against

Text Yes String - -
Name master data list

Sample Default value of

Numeric Yes Integer >0 1
Quantity 1

Zip Tie used if

Handling Dropdow QR Code, QR
Yes Enum QR not
Method n Zip Tie Code
applicable

Generate 1 QR per unit of

QR Code ID Yes String Auto -
d sample

Business Rules and Dependencies

Field Label Validation Rules Error Message Dependencies

Must exist and be

"Invalid or unpaid Enquiry
Enquiry ID linked to valid
enquiry selected" Management
payment

Sample Must be a positive "Sample quantity

None
Quantity integer must be at least 1"

Handling QR allowed only if "QR code cannot be Sample size/type

Method sample allows label pasted on sample" detection

Buttons, Links and Icons

Other Visibl Enable
Label OnClick Event Navigate To
Events e d

Validate and Save Refresh current

Submit None Yes Yes
Record screen
Generate QR Trigger QR QR Preview
None Yes Yes
Codes Generator API Screen

Open Printer
Print None Yes Yes Print Preview
Dialog

Cancel Clear Form None Yes Yes Same Screen

Risk Assessment
Severit Likelihoo
Risk Description Mitigation Strategy
y d

Missing QR on sample due to Operator checklists + visual

High Medium
manual error verification

Mediu Retry logic and manual code

Printer connectivity failure High
m assignment

Unapproved enquiry selected Block submission at

High Low
for case frontend

Mismatch in sample quantity Mediu Barcode reconciliation

Medium
vs. received samples m module (future phase)

Updated Non-Functional Requirements

NFR Category Description

Support concurrent barcode generation within 3 seconds

Performance
per 10 entries

Security Only authenticated users can create/edit sample entries

Each record change should be audit logged with user and

Traceability
timestamp

Should support 1,000+ samples per day without

Scalability
performance degradation

Maintainability Configurable dropdowns and dynamic validation logic

Hardware Seamless support for Zebra and Dymo printer libraries via
Integration API

Screen readers and keyboard navigation must be

Accessibility
supported

Sub-Module: Case Management

Overview
The Case Management sub-module of the Analytical Testing component of
PCSIR's ERP plays a pivotal role in tracking, assigning, processing, reviewing,
and completing analytical testing requests. It spans a wide array of actors,
including ILO Operators, Scientists, Section In Charges, Head of Centers, and
customers. The sub-module ensures process transparency, cross-center
collaboration, efficient resource allocation, and timely customer
communication.

This system is designed to digitize and streamline the lifecycle of analytical

test cases, beginning from data entry and center allocation, progressing
through internal approvals, environmental monitoring, report generation,
validation, printing, and concluding with delivery and customer notification. It
supports inter-center workflows, primary center designation, equitable
revenue share allocation, and a robust approval hierarchy. Integrated SMS
alerts enhance user awareness and transparency.
Software Requirement Analysis
Functional Requirements

 Case data entry with support for scanned documents

 Assignment to one or more centers with percentage share allocation

 Automatic and manual designation of primary center

 Validation of cumulative center share to ensure 100% distribution

 Approval workflows: ILO → Head ILO → Head(s) of Center → Section In

Charge → Scientist

 Uploading of environmental data and test reports by analysts

 Automatic locking of reports post submission

 Restricted editing rights: only assigned analyst can edit pre-approval

 SMS notification for case receipt, sample receipt, and delays

 Approval/rejection workflow for reports with feedback loop

 Printing and scanning of final signed reports

 Recording and dispatch of reports (including courier details)

 Daily workload and financial summary reports for ILOs

 Customer search and retrieval by name, organization, or contact

number

Non-Functional Requirements

 Secure file management for document uploads

 Audit trail for all changes in workflow and data

 Scalable database to manage high volume of cases

 Redundant SMS gateway integration with delivery confirmation

 Sub-second query response for critical screens (dashboard, search)

 Support for multiple roles and concurrent sessions (min 100 concurrent
users)

High-Level Architecture
 Presentation Layer:
 o Developed using React with Tailwind CSS for responsive UI

o Role-based UI rendering depending on user access level

 Business Logic Layer:

o Written in Node.js/Python for robust workflow orchestration

o Contains rule engine for validations, role routing, report locking

 Data Access Layer:

o ORM layer using Sequelize/Django ORM for PostgreSQL

interaction

o Provides secure CRUD operations with transaction management

 Database Layer:

o PostgreSQL: relational schema with tables for cases, centers,

users, roles, uploads, reports, SMS logs

o Full-text indexing for customer search capabilities

 Integration Layer:

o Twilio or local telco SMS gateway for notifications

o REST API interface for optional courier tracking API

o Document Management System integration for storing scans

securely

Module Name: Analytical Testing

Sub Module Name: Case Management

Purpose / Description
The Case Management sub-module is engineered to manage the life cycle of
testing cases submitted by customers to PCSIR for analytical processing. The
system enables ILO operators to capture detailed metadata and scanned
documents, assign centers responsible for testing, define the primary center,
and allocate share percentages. The workflow supports inter-departmental
approvals, environmental monitoring by analysts, report submission, multi-
level approvals, and secure delivery mechanisms. The use of SMS-based
communication ensures that customers remain informed at every step of the
testing process, from sample receipt to final report dispatch.
The design supports centralization of records, decentralized execution across
centers, and maintains detailed logs and audit trails for traceability and
compliance.

Use Cases
Use Case 1: Create and Assign Case

 Use Case ID: CM-001

 Use Case Name: Case Creation and Center Assignment

 Primary Actor(s): ILO Operator

 Pre-conditions: User must be authenticated and authorized with ILO

role

 Post-conditions: Case created and forwarded to Head ILO for

approval

Main Success Scenario:

1. ILO Operator logs in and navigates to the “New Case” section

2. Fills in basic metadata such as case title, customer ID, sample details,
urgency level

3. Uploads scanned documents (e.g., request forms, sample submission

forms)

4. Selects one or more centers for analytical testing

5. Assigns percentage share to each center ensuring sum = 100%

6. Selects one center as primary (must have highest share)

7. Saves and submits the case for Head ILO review

Alternative Paths:

 Share percentage total ≠ 100% → validation error

 Primary center not having largest share → validation error

Business Rules:

 All assigned centers must have > 0% share

 Primary center must have largest share value

  Case status changes to “Pending Head ILO Approval” after submission

Use Case 2: Head ILO Review and Dispatch to Centers

 Use Case ID: CM-002

 Use Case Name: Case Review and Center Dispatch

 Primary Actor(s): Head ILO

 Pre-conditions: Case must be in “Pending Head ILO Approval” state

 Post-conditions: Case assigned to selected centers and marked in

workflow

Main Success Scenario:

1. Head ILO reviews case details, centers selected, and share allocation

2. Approves or rejects the case

3. Upon approval, system dispatches the case to selected center heads

Alternative Paths:

 Head ILO rejects the case: case returns to ILO operator for correction

Business Rules:

 Approval cannot be overridden or delegated

 System logs timestamp of approval and approver ID

Use Case 3: Section Assignment and Testing

 Use Case ID: CM-003

 Use Case Name: Section and Scientist Assignment

 Primary Actor(s): Center Head, Section In Charge

 Pre-conditions: Case must be assigned to the center

 Post-conditions: Assigned analyst begins work

Main Success Scenario:

1. Center Head forwards case to relevant section

2. Section In Charge assigns it to available analyst/scientist

3. Analyst records environmental data (temperature, humidity, etc.)

 4. Analyst performs the test and uploads partial/full report

5. Analyst marks task as complete

Business Rules:

 Only the assigned analyst can upload the report

 Upload is timestamped and cannot be edited post-approval

Use Case 4: Final Approval and Report Printing

 Use Case ID: CM-004

 Use Case Name: Final Review and Report Printing

 Primary Actor(s): Section In Charge, Center Head, ILO Printing

Operator

Main Success Scenario:

1. Section In Charge reviews the submitted report

2. Approves and forwards to Head of Center

3. Head of Center approves final report

4. System unlocks report for printing

5. ILO Printing Operator prints and gets signatures

6. Report is scanned and uploaded

7. SMS sent to customer for pickup readiness

Alternative Path:

 Section or Center Head rejects report: routed back to analyst for

corrections

Business Rules:

 No edits allowed after approval by Center Head

 SMS delivery confirmation stored in logs

Screen/UI Design
(Wireframes to be attached separately)

 Case Entry Screen

  Center and Share Assignment Interface

 Case Review Dashboard (for Head ILO)

 Section In Charge Assignment Panel

 Analyst Report Upload Form

 Final Report Approval Workflow UI

 Printing & Dispatch Tracking Interface

Field-Level Specifications
Field Mandato Data Value Defaul
Field Label Comments
Type ry Type Set t Value

Alphanumeric
Case Title Text Box Yes String N/A - with max
length 150

Sample
Text Area Yes String N/A - -
Description

Center
Centers Multi-
Yes List Master - Lookup
Assigned select
Table

Assigned
Primary Dropdow Must have
Yes Ref ID Centers -
Center n highest share
Only

Share % per Number Decima Total must

Yes 0–100 -
Center Box l equal 100%

Scanned
File .pdf, .jpg,
Document No File - Max 5 MB each
Upload .doc
Upload

Temp,
Environmental
Text Area Yes String - - Humidity,
Conditions
Pressure fields

File Analyst
Report Upload Yes File .pdf -
Upload uploads only

Dispatch Dropdow Yes Enum Courier, Courier Determines

 Self- which fields
Mode n
Pickup are shown

Required if
Courier
Text Box No String - - Dispatch Mode
Tracking No.
is Courier

Business Rules and Dependencies

Field
Validation/Rule Error Message Dependencies
Label

Total across centers must = "Total share must be Center

Share %
100% exactly 100%" Assignment

Primary Must be one of the assigned "Invalid primary Center Share

Center centers & have highest share center selection" Values

Report Only assigned analyst can "Unauthorized user Case

Upload upload for report upload" Assignment

Dispatch If mode is courier, tracking "Tracking number is

Dispatch Mode
Info no. required mandatory"

Buttons, Links, and Icons

Visibl Enabled
Label OnClick Event Navigate To
e Condition

Submit Validates and If required fields Head ILO Approval

Yes
Case submits to Head ILO are filled Dashboard

Upload Validates file and If user is

Yes -
Report locks report assigned analyst

Dispatch Opens form to enter Yes If report is Dispatch Tracking

Report delivery details scanned and Screen
 signed

Retrieves existing
Search Customer Profile or
customer by Yes Always
Customer Enquiry Module
ID/name

Risk Assessment
Likelihoo
Risk Description Impact Mitigation Strategy
d

Improper share allocation UI validation and business

High Medium
between centers logic enforcement

Unauthorized report Role-based access + backend

High Low
changes post submission locks

Mediu Dual SMS gateway support +

SMS delivery failure High
m logs + retry mechanism

File size issues during File compression and size

Low Medium
upload validation

Updated Non-Functional Requirements

Requirement Specification

Sub < 3 second load and submission time on 90% of

Performance
transactions

Uptime 99.9% per month

Concurrent
Minimum 100 concurrent active users
Users

AES 256 encryption for documents, role-based access

Data Security
control

Audit Logs Immutable logs for all key operations

SMS
High-throughput SMS API with delivery status logging
Integration

Scalability Support for 10,000+ cases per month with horizontal

 scalability

Sub-Module: Special Cases

Overview
This Functional Specification Document (FSD) outlines the detailed
functional, operational, and business requirements for managing Special
Cases within the Analytical Testing Module of the PCSIR ERP System.
Special cases arise due to exceptions in standard laboratory operations and
business workflows. These include internal service requests from one PCSIR
unit to another, handling of overdue cases beyond their standard timelines,
real-time tracking of analytical test status, provision for gratis (free-of-cost)
testing for state institutions, and confidential testing processes.

The goal of this sub-module is to ensure that all exception-based scenarios

are managed systematically within the ERP to maintain data integrity, ensure
audit trails, enforce security for sensitive data, and support process
transparency.

Software Requirement Analysis

Functional Requirements:

1. Ability to identify and manage internal PCSIR customers distinct from

external clients.

2. Mechanism to flag and monitor overdue test cases based on defined

default and custom turnaround times.

3. Real-time tracking of the progress of a specific test, including

responsible personnel and task completion statuses.

4. Management of gratis cases where no charges are levied due to

customer classification (e.g., Courts, State Institutions).

5. Mechanisms to mark and handle confidential tests, including access

restrictions and secured report generation/printing workflows.

Non-Functional Requirements:

1. Role-Based Access Control (RBAC) to restrict features and data views.

2. Secure encryption protocols for data, especially for confidential results.

3. High system availability (uptime > 99.5%) for test tracking.

4. Efficient performance – system must respond to queries within 2

seconds.

5. Scalable architecture to accommodate growth in special case volumes.

High-Level Architecture
Application Layers:

 Presentation Layer: Angular/React-based UI

 Application Layer: RESTful Java Spring Boot APIs

 Persistence Layer: PostgreSQL or Oracle Relational Database

  Reporting Engine: JasperReports integrated for dynamic PDF/Excel
reports

 Notification System: Email/SMS gateway (SMTP, Twilio or similar)

 Security Layer: TLS 1.3, AES-256, RBAC, IP Whitelisting for report

access

Module Name: Analytical Testing Module

Sub Module Name: Special Cases Management

Purpose/ Description:
The Special Cases Management Sub-Module of the Analytical Testing Module
is dedicated to handling exceptions and advanced workflows in the test
lifecycle. These include but are not limited to:

 Internal PCSIR requests

 Overdue test flagging

 Test tracking by test ID/case ID

 Gratis test case handling

 Confidential testing and restricted report viewing

This sub-module ensures seamless integration with other ERP components

like Enquiry Management, Case Management, Laboratory Execution, Billing,
and Document Management to provide a cohesive user experience.

Use Cases
Use Case 1

 Use Case ID: SC-001

 Use Case Name: Internal Customer Request Handling

 Primary Actors: Lab Coordinator, Case Entry Operator

  Preconditions: The sending and receiving laboratories must be PCSIR
units registered in the master data.

 Postconditions: Internal test case created with appropriate routing

and without external billing.

 Main Success Scenario:

1. Lab A sends a service request to Lab B.

2. System identifies both as internal PCSIR units.

3. The case is routed as an internal test without an invoice

generation step.

4. Notification is sent to Lab B’s coordinator.

 Alternative Paths:

o If one of the labs is not recognized as a PCSIR unit, the system

throws a validation error.

 Business Rules:

o All PCSIR labs must be maintained in an Organizational Master

Table with a flag indicating internal classification.

Use Case 2

 Use Case ID: SC-002

 Use Case Name: Overdue Test Case Flagging

 Primary Actors: QA Officer, Technical Manager

 Preconditions: Default test duration must be defined per SOP/Test

Matrix.

 Postconditions: Case marked as “Overdue” and alert issued.

 Main Success Scenario:

1. User creates a case with an associated test having a predefined

TAT (turnaround time).

2. System monitors TAT using a background job scheduler (runs

every 15 minutes).

3. If the current time exceeds start time + TAT, the case is flagged
as overdue.
 4. Alerts shown on QA Dashboard and emails sent to concerned
roles.

 Alternative Paths:

o TAT manually overridden during case creation, then the

scheduler considers the overridden value.

 Business Rules:

o Override permissions are restricted to Level-3 staff and above.

Use Case 3

 Use Case ID: SC-003

 Use Case Name: Real-Time Test Status Tracking

 Primary Actors: QA Manager, Lab Technologist

 Preconditions: Valid Test ID or Case ID must exist.

 Postconditions: Status displayed with logs and assigned personnel.

 Main Success Scenario:

1. QA Manager opens the test tracking dashboard.

2. Enters a valid Test ID.

3. System retrieves logs: Assigned To, Start Time, Completion

Status, % Complete, Last Updated.

4. Displays remaining steps and current handler.

 Alternative Paths:

o No log found → shows status as “Unassigned”.

Business Rules:

o All users must record timestamped logs at each stage using the
Test Execution Interface.

Use Case 4

 Use Case ID: SC-004

  Use Case Name: Gratis Test Case Processing

 Primary Actors: Case Entry Operator, Accounts Officer

 Preconditions: Customer must be listed as “Gratis Eligible” in master

data.

 Postconditions: Billing skipped or invoice generated with zero

charges.

 Main Success Scenario:

1. Case Entry Operator selects customer.

2. System auto-checks if marked as “Gratis.”

3. Invoice not generated or generated with “No Charges – Gratis

Case” note.

 Alternative Paths:

o Customer is not listed → invoice generated with actual rates.

 Business Rules:

o Gratis eligibility list must be updated monthly by admin users.

Use Case 5

 Use Case ID: SC-005

 Use Case Name: Confidential Case Management

 Primary Actors: ILO, Director, Printing Operator

 Preconditions: Case must be flagged as confidential at case creation

stage.

 Postconditions: Access restricted to authorized roles, logs

maintained, reports securely printed.

 Main Success Scenario:

1. ILO marks a case as confidential during case sheet preparation.

2. Case is auto-tagged and results hidden from general lab staff.

3. Only Director-level and above users can view/print reports.

4. Report printing interface uses watermarking and password

protection.
  Alternative Paths:

o Emergency access granted via Director override (OTP/email

confirmation).

 Business Rules:

o All access/view/print attempts are logged with timestamps and

user IDs.

Field-Level Specifications
(Selected fields shown for brevity; full table available on request)

Field Field Mandato Data Default Commen

Value Set
Label Type ry Type Value ts

Determin
es
Customer Dropdow
Yes String Internal, External External workflow
Type n
and billing
logic

Restricts
Confidenti Checkbo Boolea Checked/ Unchecke visibility
No
al Case x n Unchecked d to limited
users

In hours;
Override superviso
Number No Integer N/A NULL
TAT r access
only

Test Accepts
Tracking Text Box Yes String N/A NULL Case
Input ID/Test ID

Auto-
applies
Gratis Checkbo Boolea Checked/ Unchecke
No invoice
Case x n Unchecked d
exemptio
n logic

Business Rules and Dependencies

Field Label Business Rules Error Messages Data
 Dependencies

Confidential Only senior roles can

"Access Denied" User Role Table
Case access marked cases

Must be <= 200% of

"Override exceeds
Override TAT original TAT; justification Test Master Data
permitted limit"
mandatory

Internal customers must "Customer not

Customer PCSIR Master
match PCSIR Org Unit recognized as PCSIR
Type Organizations
Code entity"

"Customer not
Must be listed in Gratis Gratis Customer
Gratis Case eligible for gratis
Eligibility Master Master
case"

Buttons, Links, and Icons

Other
Button Label OnClick Event Visible Enabled Navigate To
Events

Track Test Fetch real-time

NA Yes True /track/test
Status log from DB

Mark Set confidential Role-

NA Yes NA
Confidential flag on case Based

Override Enable TAT edit Condition

NA True NA
Duration field al

Generate Invoke secure Condition /report/

NA Yes
Report report renderer al confidential
Risk Assessment
Risk Likelihoo
Description Impact Mitigation Strategy
ID d

R- Unauthorized access to Use RBAC, encryption,

Medium High
001 confidential cases and audit logs

Gratis eligibility list not Monthly review and

R- Mediu
updated, causing incorrect High approval by finance
002 m
billing admin

Enforce logging and

R- Test log missing stages
Medium High validation on every
003 affecting tracking accuracy
action

Implement failover
R- Overdue alert missed due to
Low High mechanism and retry
004 scheduler failure
logic

Updated Non-Functional Requirements

NFR ID Requirement Description

NFR-
Role-Based Access Control with 4-tier user hierarchy
001

NFR-
Encryption of confidential test data and reports (AES-256)
002

NFR- Notification system sends overdue alerts within 15 minutes of

003 breach detection

NFR- Gratis billing logic handles zero invoicing with appropriate audit
004 trail

NFR-
Test status retrieval latency must not exceed 2 seconds
005
Research Program Management System
R&D
Overview
The Research Program Management System (RPMS) is a core module
of the PCSIR ERP aimed at digitalizing the complete lifecycle of research
program management. It enables seamless tracking, approval, monitoring,
documentation, and evaluation of R&D programs across PCSIR's laboratories
and research centers. This module ensures structured initiation of R&D
activities, rigorous scrutiny and linkage with funding sources, and
comprehensive progress tracking aligned with strategic goals and national
science and technology objectives.

This FSD documents the system’s functional, architectural, and design

specifications in detail, covering all sub-modules and functional requirements
as per PCSIR’s guidelines.

Software Requirement Analysis

Functional Requirements:

 Categorize R&D as National or International.

 Define and maintain various Sources of R&D including PSDP, RD&I,

SGF, Collaborative Research, Other Agencies, etc.

 Link R&D to specific PSDP Projects if applicable.

 Maintain a master list of Funding Agencies as a setup module.

 Generate unique R&D Program IDs incorporating Lab Complex Code,

Lab Code, Year, and R&D Number.

 Track R&D duration, alert for deadline lapse, and support

extensions with appropriate authority approvals.

 Enable periodic progress reporting by R&D Team Leads and

monitoring by PCSIR Management.

 Maintain and select multiple Fields of Study for each R&D.

  Enable a comprehensive search facility including wild card searches.

 Facilitate submission of new R&Ds by Director P&D (Lab Complex) or

Director Office (Mono Lab) and forward to Head Office.

 Provide edit/scrutiny rights to Director R&D at PCSIR HQ.

 Allow approval/rejection/objection by Director R&D.

 Consolidate and generate Annual R&D Program in PDF.

 Record historical R&Ds entered outside the digitalized system.

Non-Functional Requirements:

 Role-based secure access

 High system availability and audit trails

 Responsive web-based UI/UX

 Interoperability with PCSIR Human Resource, Finance, and Document

Management Modules

 Compliant with PCSIR Data Privacy Policies

High-Level Architecture
Architecture Type: Modular, Service-Oriented Architecture (SOA)

Components:

 Web Front-End (Angular/React)

 Application Layer (Spring Boot/.NET Core)

 Database Layer (PostgreSQL/Oracle)

 Integration Layer (RESTful APIs for HRM, Finance, DMS, etc.)

Key Modules:

 R&D Program Initiation

 Source and Funding Setup

 Progress Tracking and Reporting

 Scrutiny and Approval Workflow

 Annual Program Compilation

 Search and Retrieval Engine

Module: Research Program Management System
Module: Research Program Management System

Sub-Module: R&D Program Database

Purpose/Description:

This sub-module serves as the central repository for all registered R&D
programs across PCSIR Laboratories. It maintains historical and current R&D
data, uniquely identified through structured R&D IDs. It ensures traceability,
cross-referencing with associated PSDP projects, funding agencies, team
leads, fields of study, and progress updates.

Use Case 1: Register New R&D in Program Database

 Use Case ID: RND-DB-001

 Use Case Name: Register New R&D

 Primary Actor(s): Research Officer, Director P&D

 Pre-conditions: R&D must be initiated and filled through the R&D

Initiation Form.

 Post-conditions: A structured record is created in the centralized

R&D Program Database.

 Main Success Scenario:

1. User accesses the R&D Program Database form.

2. System fetches data from R&D Initiation.

3. User reviews, updates, and submits the R&D details.

4. System generates a unique R&D ID (e.g., LC01-LAB03-2025-

RD017).

5. Data is saved and becomes viewable in the program database.

 Alternative Path:

o If mandatory fields (like title, lab, source) are missing, system

prompts: “Please complete all required fields before submission.”

 Business Rules:
 o R&D ID format must follow Lab Complex Code + Lab Code + Year
+ Sequential R&D Number.

o Duplicate R&D IDs are not allowed.

o A record remains in “Draft” until approved by Head Office.

Sub-Module: Linking R&D Program with Related R&D Project

Purpose/Description:

This sub-module facilitates establishing links between an R&D Program and

specific PSDP Projects or agency-funded initiatives. It ensures traceability
and financial accountability by tying R&D objectives with their funding and
project origins.

Use Case 2: Link R&D to PSDP Project

 Use Case ID: RND-LINK-001

 Use Case Name: Link R&D to PSDP

 Primary Actor(s): Research Officer, Director P&D

 Pre-conditions: R&D source must be selected as "PSDP Project".

 Post-conditions: PSDP reference is stored as a foreign key to the

R&D.

 Main Success Scenario:

1. User selects “PSDP Project” in the Source of R&D field.

2. System prompts “Select PSDP Project from the list”.

3. User selects project from dropdown.

4. System validates the selection.

5. System saves reference to the PSDP table.

 Alternative Path:

o If no PSDP is selected after choosing "PSDP", system prompts:

“Please link the associated PSDP Project to continue.”

 Business Rules:

o Only approved PSDP projects should appear in the dropdown.

 o A PSDP project can be linked to multiple R&Ds but not duplicated
within the same R&D ID.

Sub-Module: Funding Agencies Information

Purpose/Description:

This sub-module maintains the master list of domestic and international

funding agencies. It acts as a configuration/reference dataset to ensure
standardized selection during R&D initiation and linkage.

Use Case 3: Maintain Funding Agencies

 Use Case ID: RND-FUND-001

 Use Case Name: Maintain Funding Agency List

 Primary Actor(s): System Admin, P&D Officer

 Pre-conditions: User must have configuration rights.

 Post-conditions: Funding agency appears in dropdowns where

needed.

 Main Success Scenario:

1. Admin accesses the Funding Agency configuration form.

2. Admin adds "Agency Name", "Type" (Govt/International/Other),

and status.

3. Admin submits the form.

4. System saves and displays agency in future R&D entries.

 Alternative Path:

o If agency name already exists, system prompts: “Agency already

exists. Try editing it.”

 Business Rules:

o No duplication allowed.

o Inactive agencies won’t appear in user-facing dropdowns.

Sub-Module: R&D Searching using Keywords and Wildcard Search

Purpose/Description:

This sub-module provides comprehensive search features for locating R&Ds

using exact match, partial match, and wildcard queries across multiple fields
like Title, Lead Name, Keywords, Lab, and more.

Use Case 4: Search R&D Program

 Use Case ID: RND-SEARCH-001

 Use Case Name: Search R&D Records

 Primary Actor(s): Any Authorized User

 Pre-conditions: User must be authenticated.

 Post-conditions: Results are displayed in a structured searchable

grid.

 Main Success Scenario:

1. User accesses search screen.

2. User enters keyword: “Biofuel” or uses wildcard: “Bio*”.

3. System searches across fields: title, keywords, objectives, field of

study.

4. System displays paginated results with filters and export options.

 Alternative Path:

o If no matches found, system shows: “No R&Ds found for the

specified criteria.”

 Business Rules:

o Searches must be fuzzy (case insensitive and partial matches

allowed).

o Pagination and export (CSV/PDF) should be supported.

Sub-Module: R&D Scrutiny and Selection by Authorities

Purpose/Description:

This sub-module enables hierarchical approval, rejection, or objection

workflows involving Director P&D, Director R&D (Head Office), Member
Science, and Council. It formalizes institutional R&D selection.

Use Case 5: Scrutinize and Approve R&D

 Use Case ID: RND-SCRUTINY-001

 Use Case Name: Approve/Reject R&D

 Primary Actor(s): Director R&D, Member Science

 Pre-conditions: R&D must be submitted by Lab Complex Director.

 Post-conditions: Status changes to Approved/Rejected/Objected.

 Main Success Scenario:

1. Director R&D opens list of submitted R&Ds.

2. Opens a specific R&D.

3. Reviews details.

4. Clicks “Approve” and adds remarks.

5. System marks it as “Approved” and generates R&D ID.

 Alternative Path:

o If “Reject” is selected, user must enter justification.

 Business Rules:

o Only one user at a time can edit an R&D record.

o All R&Ds must go through this flow before becoming part of the
Annual Program.

Sub-Module: Automatic R&D Program Generation

Purpose/Description:

This sub-module generates a complete Annual R&D Program document in

PDF format using all approved R&Ds. It includes summaries, fields of study,
funding info, and progress status.
Use Case 6: Generate Annual R&D Program PDF

 Use Case ID: RND-GEN-001

 Use Case Name: Generate Consolidated R&D Program

 Primary Actor(s): Director R&D

 Pre-conditions: At least one R&D must be approved.

 Post-conditions: PDF is generated and saved/exported.

 Main Success Scenario:

1. Director R&D opens Generate Program screen.

2. Selects Fiscal Year.

3. Clicks “Generate Program”.

4. System compiles data and exports downloadable PDF.

 Alternative Path:

o If no R&D is approved, system prompts: “No approved R&Ds

found for the selected fiscal year.”

 Business Rules:

o Format must be as per PCSIR reporting standards.

o Includes graphical abstracts, keywords, collaborators, financials.

Sub-Module: R&D Tracking and Progress Management

Purpose/Description:

This sub-module tracks duration, progress updates, missed deadlines, and

approved extensions. It supports milestone entry and visibility by PCSIR
management.

Use Case 7: Update R&D Progress

 Use Case ID: RND-TRACK-001

 Use Case Name: Submit Progress Update

 Primary Actor(s): R&D Team Lead

 Pre-conditions: R&D must be approved and in-progress.

  Post-conditions: Progress update is saved and visible to PCSIR
Management.

 Main Success Scenario:

1. Team Lead opens the R&D tracking dashboard.

2. Clicks on an active R&D.

3. Enters progress milestones, current status, and targets for next

fiscal.

4. System logs progress and updates timeline.

 Alternative Path:

o If scheduled completion date has passed, system prompts for

Extension Request.

 Business Rules:

o Progress updates must be timestamped.

o Extensions require justification and Director approval.

Screen/UI Design
(To be submitted in design mockup phase. Screens include R&D Initiation,
Funding Agency Setup, R&D Scrutiny Dashboard, Progress Entry Form,
Program Generator.)

Field-Level Specifications
Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

Title of 250 chars

Text Box Yes String - -
R&D max

National,
R&D Type Dropdown Yes Enum National
International

PSDP, RD&I, PSDP

Source of SGF, In-house, triggers
Dropdown Yes Enum -
R&D Collaborative, PSDP Ref
Other Agency input

Funding Dropdown Condition FK [Configured] - Only visible

Agency al if Source =
 Other
Agency

Fields of Multi- Multiple

Yes FK [Configured] -
Study Select allowed

Team Lead Searchabl

Auto-fetch
Employee e Yes FK From HRM -
name
ID Dropdown

Intege
Duration Number Yes 1–10 - Years
r

Auto-calc
Scheduled from
Date
Completion Yes Date - initiation
Picker
Date +
duration

Graphical Image Image

No - - Optional
Abstract Upload File

Business Rules and Dependencies

Field
Validation/Business Rule Error Message Data Dependencies
Label

Source of If PSDP, then PSDP "PSDP Reference is

Conditional display
R&D Reference is required mandatory"

"Invalid duration Completion date

Duration Must be > 0 and <= 10
specified" auto-calculated

Fields of At least one field must be "Please select at

None
Study selected least one field"

"Title already
Title of
Unique within year exists for this Year of initiation
R&D
year"

Buttons, Links, and Icons

Label OnClick Event Other Visibl Enabled vs Navigate
 Event e Displayed To

Save Draft Save to draft state - Yes Enabled -

Submit form to Enabled when

Submit to HQ - Yes -
Director R&D HQ complete

Add Funding Enabled for Modal

Opens setup form - Yes
Agency Admin Popup

Risk Assessment
Likelihoo
Risk Description Impact Mitigation Strategy
d

Delay in defining source & Pre-populate agency list;

Medium High
funding agency training for staff

Mediu
Duplicate R&D entries Medium Enforce unique titles and IDs
m

Inaccurate progress data

High High Audit trail, role-based access
entry

Data integration failure with Fallback to manual entry with

Low High
HRM audit flags

Updated Non-Functional Requirements

Requirement Specification

Availability 99.5% uptime

Scalability Supports >500 concurrent users

Audit Trail Full audit for create/update/delete

PCSIR Single Sign-On (SSO)

Authentication
integration

In compliance with PCSIR data

Data Privacy
protection
 Max 3 seconds response time per
Performance
operation

Backup & Recovery Daily backups, retention for 3 years

REST APIs with PCSIR HRM, DMS,

Integration
Finance

Browser
Chrome, Firefox, Edge
Compatibility

Accessibility WCAG 2.1 compliant UI

Technical Assistance and Consultancy Management

System
Module: Technical Assistance and Consultancy Management
System (TACMS)
Overview
The Technical Assistance and Consultancy Management System (TACMS) is a
critical ERP module designed to manage the entire lifecycle of technical
assistance and consultancy services at PCSIR. This system ensures smooth
interaction between customers, ILO operators, scientists/engineers, centers,
and management authorities. From inquiry generation to case closure,
TACMS supports service availability validation, payment verification, case
tracking, multi-center coordination, document handling, report generation,
and performance measurement.

Software Requirement Analysis

 User Roles:

o Customer (External User)

o ILO Operator (Internal Liaison Officer)

o Head ILO

o Head of Center(s)
 o Section In Charge(s)

o Scientists/Engineers (Lead and Associate Consultants)

o ILO Printing Operator

o Director P&D

o Director-General PCSIR Complex

 Functional Requirements:

o Inquiry Management and Response Generation

o Payment Integration and Verification

o Case Sheet Generation with Auto-Numbering

o Fields of Study and Industry Classification Management

o Document Upload and Management

o Multi-Center Assignment and Share Distribution

o Approval Workflows at multiple levels

o Consultancy Report Upload and Correction Cycle

o Progress Report Consolidation and KPI Updating

o Search with Wildcard and Advanced Filters

o Notification and Alert System

 Non-Functional Requirements:

o System Availability: 99.5% uptime

o Performance: Response times under 2 seconds for major

operations

o Security: Role-based access control, audit trails, encrypted data

transmission

o Scalability: Support for concurrent users from multiple centers

o Usability: Intuitive UI with accessibility support

High-level Architecture
 Presentation Layer: Responsive web UI designed with
ReactJS/Angular for accessibility by multiple user roles
  Business Logic Layer: Workflow engines to automate case handling,
multi-center assignment, report handling, and approval routing

 Data Layer: Relational database managing inquiries, cases, fields of

study, industries, employee details, document metadata, and KPI
records

 Integration Layer: REST APIs for seamless communication with

Inquiry Management System, PCSIR HR System, KPI and Reporting
Systems, and Payment Gateways

 Security Layer: Implements TLS encryption, RBAC, multi-factor

authentication, and activity logging

Module: Technical Assistance and Consultancy Management System

Sub-Module 1: Consultancy Initiation through Enquiry and
Meetings/Visits

Purpose / Description

This sub-module enables customers to initiate inquiries for technical

assistance or consultancy services. The system processes inquiries and
generates responses: non-availability intimation, request for further
interaction, or quotations including costs and terms. This acts as the front-
end for capturing customer service demands.

Use Cases
Use Case ID: TACMS-01

Use Case Name: Submit Consultancy Inquiry

Primary Actor: Customer
Pre-conditions:

 Customer registered and authenticated

 Inquiry Management System accessible

Post-conditions:

 Inquiry recorded with status

  Customer receives response (non-availability, meeting request,
quotation)

Main Success Scenario:

1. Customer logs into the portal

2. Navigates to the technical assistance enquiry page

3. Enters required information: nature of assistance, contact details,

description

4. Submits inquiry

5. System validates request and cross-checks service availability

6. System generates appropriate response:

o Service not available: notification sent

o Meeting/visit requested: system schedules or requests further

info

o Quotation prepared: sent for approval and then shared with

customer

Alternative Path:

 If the system is offline or inquiry data invalid, error message displayed

 Customer can retry submission after correction

Business Rules:

 Quotation must be approved by Head ILO before dispatch

 Inquiry cannot be duplicated within 7 days for same customer and

same service

Use Case ID: TACMS-02

Use Case Name: Create Technical Assistance Case

Primary Actor: ILO Operator
Pre-conditions:

 Payment has been verified and linked to inquiry

 Inquiry status allows case creation

Post-conditions:

 Case sheet created with system-generated case number

 Case linked to inquiry and customer

Main Success Scenario:

1. ILO Operator logs in and verifies payment status

2. Selects inquiry to create case from

3. Enters required basic information (customer, inquiry ref, description)

4. Selects applicable Field(s) of Study (multi-select from maintained list)

5. Selects Industry from pre-defined list

6. System generates unique case number and case sheet

7. Case saved and ready for further processing

Alternative Path:

 Payment not verified → case creation denied with error message

 Mandatory field missing → validation error prompted

Business Rules:

 Fields of Study must be selected for every case

 Industry must be selected from predefined list only

 Case number format: TAC-[Year]-[CenterCode]-[SequentialNumber]

Use Case ID: TACMS-03

Use Case Name: Add Detailed Case Information and Document Upload
Primary Actor: ILO Operator
Pre-conditions: Case created and assigned to Operator
Post-conditions: Detailed information and documents attached to case
Main Success Scenario:

1. ILO Operator accesses case details page

2. Adds detailed case description, deadlines, and special instructions

3. Uploads scanned supporting documents (PDF/DOCX formats)

 4. Saves updates

5. System confirms attachment and indexing of documents

Alternative Path:

 Invalid file type or size → upload rejected with error message

 Network failure → retry or save draft feature

Business Rules:

 Max document size 10MB

 Supported formats: PDF, DOCX, JPEG (for scanned images)

 Document metadata includes upload timestamp and uploader ID

Use Case ID: TACMS-04

Use Case Name: Assign Case to Center(s) and Define Shares

Primary Actor: ILO Operator
Pre-conditions: Case created with basic and detailed info
Post-conditions: Case assigned to one or more centers with share
percentages defined
Main Success Scenario:

1. ILO Operator selects case for assignment

2. Assigns case to relevant center(s) based on expertise

3. Designates one center as primary center

4. Allocates percentage share to each center ensuring total equals 100%

5. Primary center has largest share

6. Saves assignment

Alternative Path:
  Shares sum ≠ 100% → validation error

 Primary center not having highest share → validation error

Business Rules:

 At least one center must be assigned

 Primary center must have the highest share of workload (> any other
center)

 Total share distribution = 100%

Use Case ID: TACMS-05

Use Case Name: Approve Case and Route to Centers

Primary Actor: Head ILO
Pre-conditions: Case assigned and ready for approval
Post-conditions: Case approved and dispatched to assigned centers
Main Success Scenario:

1. Head ILO reviews case details and assignments

2. Approves case or rejects for further revision

3. On approval, system routes case electronically to assigned centers

4. Notifications sent to center heads

Alternative Path:

 Case rejected → sent back to ILO Operator for correction

 Approval timeout → reminder notifications sent

Business Rules:

 Only Head ILO can approve or reject

 Approval status triggers downstream workflow

Use Case ID: TACMS-06

Use Case Name: Section In Charge Assigns Scientist/Engineer

Primary Actor: Section In Charge
Pre-conditions: Case received at center level
Post-conditions: Case assigned to responsible scientist/engineer
Main Success Scenario:

1. Section In Charge logs in

 2. Views cases assigned to their section

3. Selects and assigns case to Lead or Associate Consultant(s)

4. Marks assignment electronically in the system

5. Assigned staff notified

Alternative Path:

 If no suitable consultant available, escalation triggered

Business Rules:

 Multiple consultants may be assigned

 Assignment must be logged with timestamp and user ID

Use Case ID: TACMS-07

Use Case Name: Upload Technical/Consultancy Report and Mark Completion

Primary Actor: Lead or Associate Consultant (Scientist/Engineer)
Pre-conditions: Consultant assigned to case
Post-conditions: Report uploaded and case marked completed by
consultant
Main Success Scenario:

1. Consultant accesses assigned case

2. Prepares report offline and uploads it to the system

3. Marks case as 'Completed'

4. System logs submission and notifies Section In Charge

Alternative Path:

 File upload failure → retry or contact support

Business Rules:

 Report format standards enforced (e.g., PDF)

  No direct edits allowed after upload; corrections only through
resubmission cycle

Use Case ID: TACMS-08

Use Case Name: Accept or Reject Consultant Report

Primary Actor: Section In Charge
Pre-conditions: Report uploaded and case marked completed
Post-conditions: Case either forwarded or returned for correction
Main Success Scenario:

1. Section In Charge reviews report

2. Accepts report → case forwarded to Head of Center

3. Rejects report → sent back to consultant for corrections

4. System logs status and sends notifications accordingly

Alternative Path:

 If no response within SLA, escalations triggered

Business Rules:

 No edits allowed by Section In Charge; only consultant can revise

report

Use Case ID: TACMS-09

Use Case Name: Final Approval and Printing of Report

Primary Actor: Head of Center and ILO Printing Operator
Pre-conditions: Report accepted by Section In Charge and Head of Center
Post-conditions: Final report printable and archived
Main Success Scenario:

1. Head of Center reviews and approves final report

2. System unlocks report for printing by ILO Printing Operator

3. Operator prints copies as per specification in case details

4. Report archived in system repository

Alternative Path:

 Report rejected by Head → returns to Section In Charge

Business Rules:

 Print count and copies logged for audit

Use Case ID: TACMS-10

Use Case Name: Generate Consolidated Progress Report and KPI Update
Primary Actor: Director P&D and Director-General PCSIR Complex
Pre-conditions: Cases and reports approved and closed
Post-conditions: Consolidated report visible and KPI scores updated
Main Success Scenario:

1. System aggregates data from approved cases and reports

2. Generates progress report with metrics per center and consultant

3. Director P&D reviews and approves the consolidated report

4. Director-General accesses report and forwards publication info to head

office

5. KPI system updated accordingly

Alternative Path:

 Data inconsistencies detected → manual reconciliation requested

Business Rules:

 Only approved and closed cases are included

 KPIs updated only after Director-General approval

Screen/UI Design
 Inquiry Submission Screen: Customer fills inquiry with fields such as
service type, description, and contact info

 Case Creation Screen: ILO Operator enters basic case info, selects
Fields of Study and Industry from dropdowns

 Field of Study Management: Admin interface for CRUD operations

on fields of study

 Industry Management: Dropdown list management for industries

 Document Upload Screen: Multiple file upload support with

validation and preview
  Center Assignment Screen: Multi-select centers, assign shares with
validation

 Approval Dashboard: View pending approvals, approve/reject with

comments

 Report Upload Screen: Upload reports, mark complete

 Search Interface: Keyword and wildcard search, filter by consultant,

field, date range, industry, center

Field Level Specifications

Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

Technical Determines
Inquiry Dropdow Consultanc
Yes String Assistance, nature of
Type n y
Consultancy inquiry

Customer
Customer
Text Yes String - - full legal
Name
name

Format:
Validated
Contact +country
Text Yes String - phone
Number code and
format
number

Email Valid email

Text No String - Optional
Address format

Can select
Field(s) of Multi- Predefined
Yes String[] - multiple
Study Select field list
fields

Required to
Dropdow Predefined
Industry Yes String - link case to
n industry list
industry

Format: TAC- Unique

Auto-
Case [Year]- identifier
generate Yes String -
Number [CenterCode]- for each
d
[SeqNo] case

Document File No File PDF, DOCX, - Attach

Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

supporting
JPEG; Max
Upload Upload scanned
10MB
documents

Sum across
Share Numbe Validate
Numeric assigned
Percentag Yes r (0- - sum of
(Decimal) centers must
e 100) shares
be 100

Uploaded
Report File
Yes File PDF only - technical
File Upload
report

Pending,
Approval Dropdow Workflow
Yes String Approved, Pending
Status n status
Rejected

Business Rules
 Duplicate inquiries by the same customer for identical services must
be rejected if submitted within 7 days of the last inquiry.

 Case numbers must be unique and follow the defined format to enable
easy reference and tracking.

 Fields of Study and Industry must be chosen from curated lists

maintained by authorized users only.

 Multi-center case share allocations must total 100% with one primary
center holding the largest share.

 Only authorized roles (Head ILO, Section In Charge, Head of Center)

can approve or reject at their respective workflow stages.

 Reports must be uploaded in PDF format only; corrections must be

submitted as new uploads after rejection.

 KPI updates depend strictly on closed and approved cases.

 All user actions must be logged with timestamps and user identifiers
for auditing purposes.
Risk Management and Mitigation
Probabili Impac
Risk Mitigation Strategy
ty t

Payment Verification Integrate robust payment gateway;

Medium High
Failures alert on failed verifications

Document Upload Mediu File validation, retry mechanism,

Medium
Failures m offline save

Multi-Center Share Real-time validation and supervisor

Low High
Misallocation approval

Mediu Automated reminders, escalation

Delays in Approvals High
m workflows

Mediu Unique constraints and duplicate

Data Duplication Low
m inquiry checks

Role-based access control, multi-

Unauthorized Access Low High
factor authentication

Non-Functional Requirements
 The system must support 24/7 operation with maintenance windows
notified in advance.

 User interface must be responsive and support accessibility standards

(WCAG 2.1).

 Data encryption at rest and in transit must comply with PCSIR security
policies.

 System must be able to handle concurrent usage by at least 200 users

without performance degradation.

 Audit logs should be maintained for minimum 7 years.

Publication Management System
Sub Module: Publication Database Management System
Overview
The Publication Database Management System module enables PCSIR
scientists and administrators to comprehensively capture, classify, and
manage all research publications produced under PCSIR. This includes the
capture of metadata such as the source of publication (e.g., R&D,
Collaborative Research, Student Supervision), publication category (Article,
Research Paper, Book Chapter, Review, Conference Proceedings, etc.),
medium of publication (Journal, Book), fields of study, DOI number, and other
relevant details. The system provides features for entering publication data,
validation of inputs, multi-level approval workflows, reporting, and
integration with other PCSIR modules such as HR and R&D programs. The
purpose of this module is to maintain an authoritative, searchable database
of publications to support tracking, evaluation, and KPI generation.

Software Requirement Analysis

 User Roles: Scientist, Publication Admin, Head of Center (HoC), Director
P&D

 Platform: Web-based ERP module integrated with PCSIR ERP

 Database: Centralized relational database with strict referential

integrity

 Integration: PCSIR HR for author data, R&D Program Management for

linking publications to projects

 Security: Role-based access, encryption in transit and at rest

 Workflow: Multi-level approval (HoC, Director P&D) with notifications

 Reporting: Dynamic reports by source, category, field, author, and

approval status
  Backup & Recovery: Daily backups with disaster recovery options

High-level Architecture
 Client Layer: Web UI for data entry, approval, and reporting

 Application Layer: Business logic including validation, workflow, KPI

calculations

 Data Layer: Relational database storing publications, categories, fields,

users, and approvals

 Integration Layer: APIs for HR and R&D program lookup

 Notification System: Email/SMS alerts for status changes

 Security Layer: Authentication and authorization services

Sub-Module Name: Publication Metadata Capture

Purpose/Description

This sub-module provides the interface and backend functionality to capture

detailed metadata of publications such as source, category, medium, fields
of study, DOI, and author information. It ensures data integrity and enforces
business rules related to publication data entry.

Use Cases:
Use Case ID UC-PUB-001

Use Case
Capture Source of Publication
Name

Primary
Scientist, Publication Admin
Actor(s)

Pre-conditions User is authenticated and authorized for data entry

Post- Source of publication saved and linked to

conditions publication record

Main Success Scenario:

1. User opens publication entry form.

2. Selects source of publication from dropdown (R&D, Collaborative

Research, Student Supervision, Other).
 3. If "R&D" is selected, links relevant R&D program via lookup.

4. Saves the source data successfully.

 Alternative Path
 User selects "Other" and manually enters description.
 Business Rules | Source must be selected; if "R&D" chosen, R&D
Program reference is mandatory and must exist in R&D Program
database. |

Use Case ID UC-PUB-002

Use Case Name Manage Publication Category

Primary Actor(s) Publication Admin

Pre-conditions Admin logged in

Categories created/edited/deleted and reflected in

Post-conditions
dropdown lists

Main Success
1. Admin navigates to category management.
Scenario

Main Success Scenario

1. Admin navigates to category management.

2. Adds new category (Article, Research Paper, Book Chapter, Review,

Conference Proceedings, etc.).

3. Saves changes.

 Alternative Path
 Admin edits the existing category or deletes the category if unused.
 Business Rules Categories must have unique names; deletion is
blocked if linked to any publication.
Use Case ID UC-PUB-003

Use Case Name Select Medium of Publication

Primary Actor(s) Scientist

Pre-conditions User authorized for data entry

Medium selected and related fields enabled/disabled

Post-conditions
accordingly

Main Success
1. User selects medium from options: Journal or Book.
Scenario

Main Success Scenario:

1. User selects medium from options: Journal or Book.

2. Depending on selection, appropriate fields are displayed (Journal

Name, ISSN for Journal; Book Title, ISBN for Book).

3. Saves publication data. |

| Alternative Path | User switches medium selection; fields dynamically
updated. |
| Business Rules | Medium selection is mandatory; related fields must
be filled as per selection. |

Use Case ID UC-PUB-004

Use Case Name Enter DOI Number

Primary Actor(s) Scientist

Pre-conditions User entering publication details

Post-conditions DOI stored and validated

Main Success 1. User enters DOI number in

Scenario text box.

Main Success Scenario:

 1. User enters the DOI number in the text box.

2. The system validates the DOI format.

3. DOI saved if valid. |

| Alternative Path | User leaves DOI blank (optional field). |
| Business Rules | DOI must conform to standard DOI syntax if entered.
|

Use Case ID UC-PUB-005

Use Case
Assign Fields of Study
Name

Primary
Scientist
Actor(s)

Pre-conditions User authorized for data entry

Post- Fields of Study tagged with

conditions publication

Main Success Scenario:

1. User selects one or more fields of study from a multi-select dropdown.

2. Saves publication record. |

| Alternative Path | No field selected (allowed but discouraged). |
| Business Rules | At least one field of study is recommended but not
mandatory. |

Screen/UI Design
 Publication Entry Screen:

o Section 1: Source of Publication (Dropdown + R&D Program

lookup if applicable)

o Section 2: Category (Dropdown)

o Section 3: Medium of Publication (Radio buttons Journal/Book)

 o Section 4: Journal Details (Dropdown for Journal Name, ISSN,
Scopus Indexed checkbox)

o Section 5: Book Details (Book Title, ISBN, Publisher)

o Section 6: Fields of Study (Multi-select dropdown)

o Section 7: DOI Number (Text box)

o Section 8: Authors (Multi-select linked to HR module)

o Buttons: Save, Submit for Approval, Cancel

 Category Management Screen:

o Grid with Add, Edit, Delete options for publication categories

 Journal Management Screen:

o Form with fields: Journal Name, ISSN, Country, Scopus Indexed

(Yes/No)

Field Level Specifications

Field
Source of Publication
Label

Field Type Dropdown

Mandatory Yes

Data Type String

R&D, Collaborative Research, Student Supervision,

Value Set
Other

Default
None
Value

If R&D selected, R&D Program reference lookup

Comments
mandatory

Field
R&D Program Reference
Label
Field
Source of Publication
Label

Field Type Lookup/Text Box

Mandatory Conditional (If Source = R&D)

Data Type String (Program Code)

Value Set Existing R&D Programs from R&D module

Default
None
Value

Comments Must validate existence in R&D program database

Field
Publication Category
Label

Field Type Dropdown

Mandatory Yes

Data Type String

Article, Research Paper, Book Chapter, Review, Conference

Value Set
Proceedings, etc.

Default
None
Value

Comments Admin can maintain category list

Field
Medium of Publication
Label

Field Type Radio Button

Mandatory Yes

Data Type String

Value Set Journal, Book

Default
None
Value
Field
Publication Category
Label

Comments Dynamic field display depending on selection

Field
Journal Name
Label

Field Type Dropdown

Mandatory Conditional (if Medium=Journal)

Data Type String

Journals maintained in Journal

Value Set
Master

Default
None
Value

Comments Linked to Journal database

Field
ISSN
Label

Field Type Text Box

Mandatory Conditional (if Medium=Journal)

Data Type String

Value Set Valid ISSN format

Default
None
Value

Comments Format validation applied

Field
Book Title
Label

Field Type Text Box

Conditional (if
Mandatory
Medium=Book)

Data Type String

Field
Book Title
Label

Default
None
Value

Max length 255

Comments
characters

Field
DOI Number
Label

Field Type Text Box

Mandatory No

Data Type String

Default
None
Value

Validate against DOI

Comments
format

Field
Fields of Study
Label

Field Type Multi-select Dropdown

Mandatory No (Recommended)

Data Type String List

PCSIR pre-defined fields of

Value Set
study list

Default
None
Value

Lookup from Fields of Study

Comments
master
Business Rules and Dependencies
Validation/ Business Data
Field Label Error Messages
Rules Dependencies

Must be selected; if "Source of Publication

Depends on R&D
Source of R&D chosen, valid is required." / "Valid
Program
Publication R&D Program ref R&D Program must be
database
mandatory selected."

Must be selected; Category list

Publication "Publication Category is
unique per category maintained by
Category required."
list admin

"Medium of Publication
Must select Journal or
Medium of is required." / "Journal Dependent on
Book; related fields
Publication details required if Journal master
must be completed
medium is Journal."

Optional; if entered
DOI
must conform to DOI "Invalid DOI format." None
Number
format

Fields of Recommended to Fields of Study

None
Study select at least one master data

Buttons, Links, and Icons

Other Visibl Enabled vs Navigate
Button Label OnClick Event
Event e Displayed To

Show
Validate form,
validation Enabled if Stay on
Save save data to Yes
errors if form valid page
database
any

Validate form,
Enabled if
save data, Disable Navigate to
Submit for all
change status to button Yes Publication
Approval mandatory
"Submitted" and after click List page
fields valid
notify approvers
 Other Visibl Enabled vs Navigate
Button Label OnClick Event
Event e Displayed To

Discard changes Confirm Navigate to

Always
Cancel and navigate discard Yes Publication
enabled
back popup List page

Add Category
(on Category Open category Show popup
Yes Enabled
Management add form form
screen)

Enabled if
Open category Show popup
Edit Category Yes category
edit form form
selected

Enabled if
Validate no linked Show
Delete category
publications, error if Yes Refresh list
Category selected and
delete category linked
unused

Risk Assessment
Impac Likeliho
Risk Mitigation
t od

Missing mandatory fields on

Form validations and
publication causing incomplete High Medium
user training
data

Incorrect linking of R&D Program Periodic sync with R&D

High Low
due to outdated data database

User role misuse (e.g.,

Strict role-based
unauthorized publication entry or High Low
access control
approval)

Loss of publication metadata or Regular backups and

High Low
documents archival
 Impac Likeliho
Risk Mitigation
t od

Automated
Delay in approval workflow Mediu
Medium notifications and
impacting KPI updates m
escalation

Updated Non-Functional Requirements

 Performance: Publication data entry and retrieval response time
under 3 seconds under normal load.

 Reliability: 99.9% uptime with failover mechanisms.

 Security: HTTPS enforced; role-based access control; audit logs for

changes.

 Usability: Responsive UI with form validations and inline help tooltips.

 Maintainability: Modular design with clear API interfaces for

integration.

 Scalability: Support for growing data volume and concurrent users.

 Backup & Recovery: Nightly backups and tested recovery

procedures.

Sub-Module Name: Journal Master Data Management

Overview
The Journal Database Management System module is designed to maintain a
comprehensive repository of scholarly journals relevant to PCSIR’s research
activities. It includes key bibliographic and indexing details such as Scopus
indexing status, Journal Name, ISSN, Country of publication, and other
relevant metadata. The system enables PCSIR users to accurately reference
journal information during publication data entry and reporting. This module
supports ongoing updates to journal data, ensuring that all publications
linked to journals are correctly classified and validated against this master
data. The purpose is to standardize journal information, facilitate integration
with publication workflows, and improve the accuracy of research output
reporting.

Software Requirement Analysis

 User Roles: Publication Admin, Scientist, Head of Center (HoC), System
Administrator

 Platform: Web-based module integrated within PCSIR ERP

 Database: Centralized relational database to store journal metadata

 Integration: Linked to Publication Database module for validation and

dropdown population

 Security: Role-based access controls for data entry, update, and

deletion

 Workflow: Journal data management performed by authorized admins

only

 Reporting: Journal listing and indexing reports for analytics and KPI
support

 Backup & Recovery: Regular backups and audit logs of journal data
changes

High-level Architecture
 Client Layer: Web UI for journal data management (CRUD operations)

 Application Layer: Business logic for validations, indexing status

management

 Data Layer: Relational database tables for journals and indexing data

 Integration Layer: API hooks for publication module dropdown

population and validation

 Security Layer: Authentication, authorization, and audit logging

Sub-Module Name: Journal Master Data Management

Purpose/Description

This sub-module provides full CRUD (Create, Read, Update, Delete)

functionality for managing journals relevant to PCSIR research publications. It
allows publication administrators to maintain up-to-date and validated
information on journal attributes including Scopus indexing status, ISSN,
journal name, country of publication, and other metadata. This ensures
consistency and accuracy when journals are referenced in the publication
database.

Use Cases
Use Case ID UC-JRN-001

Use Case Name Add New Journal Record

Primary Actor(s) Publication Admin

Pre-conditions Admin logged in and authorized

New journal record added to the

Post-conditions
database

Main Success
1. Admin opens "Add Journal" form.
Scenario

2. Enters journal details: Journal Name, ISSN, Country, Scopus Status.

3. Validates input and submits.

4. System saves record and confirms success. |

| Alternative Path | Admin cancels operation; no data saved. |
| Business Rules | ISSN must be unique; Journal Name mandatory;
Scopus Status must be selected from predefined values. |

Use Case ID UC-JRN-002

Use Case Name Edit Existing Journal

Primary Actor(s) Publication Admin

Admin logged in, journal record

Pre-conditions
exists

Journal record updated with new

Post-conditions
data

Main Success 1. Admin selects journal from

Scenario list.

2. Updates necessary fields.

3. Saves changes; system validates and commits updates. |

| Alternative Path | Admin discards changes, no update made. |
 | Business Rules | ISSN uniqueness checked on update; mandatory
fields enforced.

Use Case ID UC-JRN-003

Use Case Name Delete Journal Record

Primary Actor(s) Publication Admin

Admin logged in; journal record not linked to any

Pre-conditions
publication

Post-conditions Journal record deleted

Main Success
1. Admin selects journal.
Scenario

2. Deletes journal after confirmation.

3. System checks dependencies and deletes record. |

| Alternative Path | System blocks deletion if linked publications exist. |
| Business Rules | Journals linked to publications cannot be deleted;
deletion requires confirmation. |

Use Case ID UC-JRN-004

Use Case Name View/Search Journals

Primary Actor(s) Scientist, Publication Admin

Pre-conditions User logged in with appropriate access

Post-conditions Journals listed matching search criteria

Main Success 1. User enters search criteria (Journal Name, Country,

Scenario Scopus Status).

2. System filters and displays matching journals. |

| Alternative Path | No matching journals found; display "No records
found." |
| Business Rules | Search fields optional; partial matches allowed. |
Screen/UI Design
 Journal Management Screen:

o Grid/List View with columns: Journal Name, ISSN, Country, Scopus

Indexed (Yes/No)

o Buttons: Add Journal, Edit Selected, Delete Selected, Search Bar

o Add/Edit Form:

 Journal Name (Text Box)

 ISSN (Text Box)

 Country (Dropdown)

 Scopus Indexed (Dropdown: Yes/No)

 Save, Cancel Buttons

Field Level Specifications

Field
Journal Name
Label

Field Type Text Box

Mandatory Yes

Data Type String

Value Set N/A

Default
None
Value

Comments Max length 255 characters

Field
ISSN
Label

Field Type Text Box

Mandatory Yes

Data Type String

Must conform to ISSN format (e.g.,

Value Set
XXXX-XXXX)
Field
Journal Name
Label

Default
None
Value

Comments Unique identifier; validated format

Field
Country
Label

Field Type Dropdown

Mandatory Yes

Data Type String

Value Set List of countries (ISO standard)

Default
None
Value

Comments Used to indicate journal origin

Field
Scopus Indexed
Label

Field Type Dropdown

Mandatory Yes

Data Type String

Value Set Yes, No

Default
No
Value

Indicates whether the journal is indexed in

Comments
Scopus

Business Rules and Dependencies

Field Validation / Business Data
Error Messages
Label Rules Dependencies

Journal Mandatory; must not "Journal Name is None

Field Validation / Business Data
Error Messages
Label Rules Dependencies

Name exceed 255 characters required."

Mandatory; must follow "Valid ISSN is

Uniqueness checked
ISSN ISSN format; unique required." / "ISSN
against Journal table
across all records already exists."

Mandatory; must be
"Country selection
Country selected from predefined Country master list
is required."
list

"Please specify if
Scopus Mandatory; must be
journal is Scopus None
Indexed either Yes or No
indexed."

Buttons, Links, and Icons

Button Visibl Enabled vs
OnClick Event Other Event Navigate To
Label e Displayed

Stays on
Add Opens Add Journal
None Yes Enabled
Journal Journal Form Management
page

Opens Edit form Enabled only

Edit Disabled if no Stays on
for selected Yes if a journal is
Selected selection page
journal selected

Confirms
Disabled if no Enabled only
deletion,
Delete selection or if journal is Refresh list
deletes journal Yes
Selected dependencies unlinked and after deletion
if no
exist selected
dependencies

Returns to
Save (in Shows
Validates and Enabled only Journal
Add/Edit validation Yes
saves record if form valid Management
form) errors if any
list

Cancel Cancels None Yes Always Returns to

Button Visibl Enabled vs
OnClick Event Other Event Navigate To
Label e Displayed

(in Journal
operation and
Add/Edit enabled Management
closes form
form) list

Risk Assessment
Impac Likeliho
Risk Mitigation
t od

ISSN uniqueness
Duplicate ISSN entries leading to
High Medium validation on entry and
inconsistent journal data
update

Incorrect Scopus indexing status Mediu Regular verification and

Low
affecting reports m admin training

Deletion of journals linked to Referential integrity

publications causing data High Low checks and deletion
integrity issues blocking

User unauthorized data Role-based access

High Low
modification control and audit logging

Updated Non-Functional Requirements

 Performance: Journal records must load within 2 seconds for typical
queries; CRUD operations should complete under 3 seconds.

 Reliability: System uptime target 99.9%, with transaction rollback on

failures.

 Security: HTTPS encryption, RBAC, audit logs of journal data changes.

 Usability: Intuitive UI with validation messages, tooltips, and

accessible dropdowns.

 Maintainability: Modular architecture allowing easy addition of new

journal attributes or integrations.

 Scalability: Supports growing journal records and concurrent admin

users.
  Backup & Recovery: Daily backups with journaling and restoration
capabilities.

Sub Module: Author and Co-Author Information Management

Overview
The Author and Co-Author Information Management sub-module is designed
to capture, maintain, and validate detailed information about authors
involved in scholarly publications. This includes the primary author, co-
authors, and their relative positions (e.g., first author, corresponding author,
co-author). Accurate author information is critical for publication attribution,
reporting, and analytics. This sub-module integrates with the Publication
Database to link author data with publications. It supports multiple authors
per publication, assigns author roles, and ensures data consistency and
completeness.

Software Requirement Analysis

 User Roles: Publication Admin, Scientist, Researcher, System
Administrator

 Platform: Web-based interface integrated within PCSIR ERP Publication

Module

 Database: Relational database to store author and publication

relationship data

 Integration: Linked with Publication Database for cross-referencing and

reporting

 Security: Role-based access and data protection, preventing

unauthorized edits

 Workflow: Author data entry performed during publication record

creation or editing

 Validation: Ensures uniqueness of author order per publication and

mandatory fields filled

 Reporting: Supports author contribution reports and citation tracking

High-level Architecture
 Client Layer: Web UI for author and co-author data entry and
management

 Application Layer: Business logic handling author position assignment

and validation

 Data Layer: Tables for authors, co-authors, author-publication

mappings, and roles

 Integration Layer: Interfaces with publication records and researcher

profiles

 Security Layer: Authentication and authorization controls, audit trails

Sub-Module Name: Author and Co-Author Information Management
Purpose/Description

This sub-module manages all data related to authors and co-authors

associated with research publications. It captures personal details, author
order (position), roles (e.g., corresponding author), and affiliation data. It
ensures that for each publication, the author list is complete, ordered, and
roles are correctly assigned. This information supports publication credit
assignment and downstream reporting.

Use Cases
Use Case ID UC-AUTH-001

Use Case Name Add Author to Publication

Primary Actor(s) Publication Admin, Researcher

User logged in with permission; publication record

Pre-conditions
exists

Author linked to publication with assigned position

Post-conditions
and role

Main Success 1. User opens publication author management

Scenario screen.

2. Selects or adds author details.

3. Assigns author position (e.g., 1st author, 2nd author).

4. Saves the author data linked to the publication. |

| Alternative Path | User cancels without saving; no changes made. |
| Business Rules | Author positions must be unique per publication;
mandatory fields must be filled. |

Use Case ID UC-AUTH-002

Use Case Name Edit Author Details

Primary Actor(s) Publication Admin

Pre-conditions User logged in; author linked to

Use Case ID UC-AUTH-002

publication

Post-conditions Updated author information saved

Main Success
1. User selects author from list.
Scenario

2. Modifies details or author position.

3. Saves changes after validation. |

| Alternative Path | User cancels edits; original data retained. |
| Business Rules | Position changes must not conflict with other
authors. |

Use Case ID UC-AUTH-003

Use Case Name Remove Author from Publication

Primary Actor(s) Publication Admin

User logged in; author linked to

Pre-conditions
publication

Author removed from publication

Post-conditions
record

Main Success
1. User selects author to remove.
Scenario

2. Confirms removal action.

3. System deletes author-publication link. |

| Alternative Path | User cancels removal; author remains linked. |
| Business Rules | At least one author must remain linked to
publication. |

Use Case ID UC-AUTH-004

Use Case Name View Authors of a Publication

Primary Actor(s) Scientist, Publication Admin

Pre-conditions User logged in; publication exists

Post-conditions Displays ordered list of authors with

Use Case ID UC-AUTH-004

roles

Main Success 1. User navigates to publication

Scenario detail page.

2. Views list of linked authors with positions and roles. |

| Alternative Path | No authors linked; displays “No authors found”
message. |
| Business Rules | Authors listed in order of position ascending. |

Screen/UI Design
 Author Management Screen:

o Grid/List displaying Authors linked to a publication, showing:

 Author Full Name

 Author Position (e.g., 1, 2, 3)

 Author Role (e.g., Corresponding Author, Co-Author)

 Affiliation

o Buttons: Add Author, Edit Author, Remove Author, Save, Cancel

o Add/Edit Author Form:

 Author Name (Lookup or New Entry Text Box)

 Position (Dropdown/Number)

 Role (Dropdown)

 Affiliation (Text Box or Dropdown)

Field Level Specifications

Field
Author Name
Label

Field Type Lookup Text Box

Field
Author Name
Label

Mandatory Yes

Data Type String

Value Set Pre-existing authors from database or new entry

Default
None
Value

Supports search-as-you-type lookup; option to add new author

Comments
if not found

Field
Author Position
Label

Field Type Number Dropdown

Mandatory Yes

Data Type Integer

Value Set 1 to total number of authors

Default
None
Value

Comments Must be unique per publication; controls author order

Field
Author Role
Label

Field Type Dropdown

Mandatory Yes

Data Type String

Corresponding Author, First Author, Co-Author, Editor,

Value Set
Reviewer

Default
Co-Author
Value

Comments Role describes the author’s contribution type

Field
Author Role
Label

Field
Affiliation
Label

Field Type Text Box or Dropdown

Mandatory No

Data Type String

Value Set Optional based on organizational units

Default
None
Value

Comments Organization/institution name of author

Business Rules and Dependencies

Field Validation /
Error Messages Data Dependencies
Label Business Rules

Mandatory; must
Author exist in author "Author Name is
Author master data
Name master or newly required."
added

Mandatory; must be "Author Position is Position uniqueness

Author unique for each required." / "Position checked against authors
Position publication; integer already assigned to linked to the same
>0 another author." publication

Mandatory; must be
Author "Author Role must
selected from Role master list
Role be selected."
predefined set
Field Validation /
Error Messages Data Dependencies
Label Business Rules

Optional; if entered,
validate against Organization master
Affiliation N/A
organization list (if data if dropdown used
dropdown)

Buttons, Links, and Icons

Button OnClick Visibl Enabled vs
Other Event Navigate To
Label Event e Displayed

Stays on
Add Opens author Author
None Yes Enabled
Author add form Management
screen

Opens edit
Disabled if no Enabled only
Edit form for Stays on
author Yes when author
Author selected current page
selected selected
author

Disabled if no Enabled only

Prompts
author if multiple
Remove confirmation, Refresh list on
selected or if Yes authors exist
Author removes success
only one and one
author link
author linked selected

Returns to
Save Validates and Shows
Enabled only Author
(Add/Edit saves author validation Yes
if form valid Management
Form) info errors if any
list

Returns to
Cancel Cancels
Always Author
(Add/Edit operation and None Yes
enabled Management
Form) closes form
list
Risk Assessment
Impac Likeliho
Risk Mitigation
t od

Duplicate or conflicting author Enforce unique position

High Medium
positions causing credit errors validation per publication

Mandatory field
Missing mandatory author data Mediu
Low validations and form-level
resulting in incomplete records m
checks

Unauthorized changes to author Role-based access control

High Low
roles or positions and audit logging

Removal of all authors from a

Restrict deletion if only
publication leaving orphan High Low
one author linked
records

Updated Non-Functional Requirements

 Performance: Author list and operations to load/update within 2
seconds under normal conditions.

 Reliability: Ensure no data loss or corruption during author edits or

deletions.

 Security: Only authorized roles can add/edit/remove author data; all

actions logged.

 Usability: User-friendly lookup for authors; clear validation messages

and tooltips.

 Maintainability: Modular design to add new author roles or fields

easily.

 Scalability: Supports publications with large numbers of authors

without degradation.

 Backup & Recovery: Regular backup of author-publication data;

rollback on error.
Sub Module: Publication Information Management
Overview
The Publication Information sub-module is responsible for managing detailed
bibliographic data related to scholarly publications. This includes the
publication year, volume number, page range, issue number, and other
relevant metadata necessary for accurate cataloging, referencing, and
reporting. This sub-module ensures standardized data capture, validation,
and seamless integration with other publication management functions such
as author details, journal information, and DOI assignment.

Software Requirement Analysis

 User Roles: Publication Admin, Researcher, Librarian, System
Administrator

 Platform: Web-based interface integrated within the PCSIR ERP

Publication Module
  Database: Relational database with tables for publication metadata

 Integration: Linked with Author, Journal, and DOI databases for

comprehensive publication data

 Security: Role-based access control to prevent unauthorized

modifications

 Workflow: Publication information entered/edited during publication

record creation or update

 Validation: Enforces mandatory fields, valid date ranges, numeric

constraints for volume and issue

 Reporting: Supports generation of citation reports, bibliographic

exports, and indexing

High-level Architecture
 Client Layer: Responsive web UI for entering and editing publication
details

 Application Layer: Business logic validating publication metadata

and managing data consistency

 Data Layer: Storage tables for publication year, volume, issue

number, pages, and related metadata

 Integration Layer: Connects with journal database, author data, and

DOI systems

 Security Layer: Implements access control, logging, and audit trail

mechanisms

Sub-Module Name: Publication Information Management

Purpose / Description

This sub-module captures and maintains key publication metadata fields

including publication year, volume number, pages, and issue number. These
fields are essential for uniquely identifying and referencing academic
publications. The sub-module ensures data validity, facilitates integration
with bibliographic databases, and supports downstream reporting and
analytics functions.
Use Cases
Use Case ID UC-PUBINFO-001

Use Case Name Add Publication Information

Primary Actor(s) Publication Admin, Researcher

User logged in with appropriate permissions; publication

Pre-conditions
record creation in progress

Publication metadata saved and linked to publication

Post-conditions
record

Main Success
1. User accesses publication metadata entry form.
Scenario

2. Enters publication year, volume, issue number, and pages.

3. Validates inputs and submits form.

4. System saves data successfully. |

| Alternative Path | User cancels operation; no data saved. |
| Business Rules | Publication year must be valid year; pages must be
numeric and logical range; volume and issue must be positive integers.
|

Use Case ID UC-PUBINFO-002

Use Case Name Edit Publication Information

Primary Actor(s) Publication Admin

User logged in; existing publication metadata

Pre-conditions
present

Post-conditions Updated publication metadata saved

Main Success
1. User selects publication record.
Scenario

2. Modifies year, volume, pages, or issue number.

3. Saves updated information. |

| Alternative Path | User cancels edits; original data remains
 unchanged. |
| Business Rules | Same validations as in Add scenario apply. |

Use Case ID UC-PUBINFO-003

Use Case Name View Publication Information

Primary Actor(s) Researcher, Publication Admin

Pre-conditions Publication record exists

Displays publication metadata fields

Post-conditions
clearly

Main Success 1. User views publication details

Scenario page.

2. Publication year, volume, pages, and issue number are displayed. |

| Alternative Path | Data missing; display placeholders or “Not
Available” |
| Business Rules | Data displayed in standardized formats. |

Screen/UI Design
 Publication Information Entry Form:

o Fields: Publication Year, Volume, Issue Number, Pages (From - To)

o Buttons: Save, Cancel, Clear

o Validation messages appear inline adjacent to fields

 Publication Details View:

o Read-only display of all publication metadata

o Edit button visible to authorized users

Field Level Specifications

Field
Publication Year
Label

Field Type Text Box (with Date Picker or Year Selector)

Mandatory Yes
Field
Publication Year
Label

Data Type Integer (4 digits)

Value Set Valid years from 1900 to current year + 1

Default
Current year
Value

Must be a valid 4-digit year; future year allowed only up to next

Comments
calendar year

Field
Volume Number
Label

Field Type Number Text Box

Mandatory No

Data Type Integer

Value Set Positive integers only

Default
None
Value

Comments Used to identify journal volume; blank if not applicable

Field
Issue Number
Label

Field Type Number Text Box

Mandatory No

Data Type Integer

Value Set Positive integers only

Default
None
Value

Comments Represents journal issue; blank if not applicable

Field
Issue Number
Label

Field
Pages
Label

Field Type Two Text Boxes (From Page, To Page)

Mandatory Yes

Data Type Integer

Value Set Positive integers; From Page ≤ To Page

Default
None
Value

Validates logical page range; supports numeric page

Comments
numbers only

Business Rules and Dependencies

Field Validation / Business Data
Error Messages
Label Rules Dependencies

"Enter valid
Must be 4-digit year
Publication publication year System date for
between 1900 and next
Year between 1900 and max year check
calendar year
[next year]."

Volume If entered, must be "Volume number must

N/A
Number positive integer be a positive integer."

Issue If entered, must be "Issue number must

N/A
Number positive integer be a positive integer."

"Enter valid page

Both From and To pages
numbers with 'From'
Pages mandatory; From ≤ To; N/A
less than or equal to
positive integers only
'To'."
Buttons, Links, and Icons
Button Visibl Enabled vs
OnClick Event Other Event Navigate To
Label e Displayed

Stays on
Validates fields; Shows Enabled
publication
Save saves publication validation Yes when form is
information
info on success errors inline valid
page

Cancels current Returns to

Always
Cancel operation; None Yes publication
enabled
discards changes details view

Confirms with Enabled

Clears all input Stays on same
Clear user before Yes when form
fields on form form
clearing has data

Risk Assessment
Impac Likeliho
Risk Mitigation
t od

Enforce strict year

Invalid publication year causing
High Low validation with system
inaccurate bibliographic records
date check

Incorrect page range input Mediu Validate page numbers

Medium
causing citation errors m with logical checks

Missing volume/issue information

Mediu Allow but prompt
reducing publication Medium
m warnings if missing
discoverability

Unauthorized edits to publication Role-based access and

High Low
metadata audit logs
Updated Non-Functional Requirements
 Performance: Publication metadata load and save operations to
complete within 1-2 seconds.

 Reliability: System ensures no partial or corrupt data entries.

 Security: Only authorized roles can modify metadata; full audit trail
maintained.

 Usability: User-friendly error prompts; year selector facilitates correct

input.

 Maintainability: Easily extendable to add new publication metadata

fields in future.

 Scalability: Handles high volumes of publication records without

degradation.

 Backup & Recovery: Regular database backups with recovery options

to prevent data loss.
Sub Module: Publication Workflow, Alerts & Notifications, and
Automatic KPI Calculation and Evaluation
Overview
This sub-module manages the end-to-end workflow of publication processing
within the system, including task assignment, status tracking, alerts, and
notifications to stakeholders. Additionally, it automates the calculation and
evaluation of Key Performance Indicators (KPIs) related to publications to
enable performance monitoring and reporting. The system ensures timely
progression of publications through defined stages, proactive communication
via alerts, and real-time KPI insights.

Software Requirement Analysis

 Actors: Publication Admin, Researchers, Reviewers, Supervisors,
System Administrator

 Platform: Web-based, integrated with the PCSIR ERP Publication

Management System

 Workflows: Multi-step publication lifecycle management with status

transitions and user roles

 Alerts & Notifications: Real-time email, SMS, and in-app notifications

based on workflow events

 KPI Automation: Rules-based engine to calculate publication KPIs

(e.g., publications per month, average review time)

 Security: Role-based permissions on workflow actions and KPI access

 Logging: Audit trails for workflow changes, alerts triggered, and KPI
calculations

 Integration: Interfaces with Author, Publication, and Journal

databases

High-level Architecture
 Workflow Engine: Manages publication process states, transitions,
and task assignments

 Notification System: Sends alerts via email, SMS, and in-app

messages triggered by workflow events
  KPI Engine: Calculates KPIs automatically based on configured
formulas and publication data

 UI Layer: Interfaces for managing workflows, viewing alerts, and

monitoring KPIs

 Database: Stores workflow states, alerts, notification history, and KPI

metrics

 Security Module: Controls access and ensures data integrity

Sub-Module Name: Workflow, Alerts & Notifications, KPI Calculation

Purpose / Description

This sub-module automates the management of publication workflows,

ensures stakeholders receive timely alerts and notifications, and computes
KPIs for performance evaluation. It supports configurable workflows for
different publication types and roles, proactive communication to prevent
delays, and automated KPI dashboards for management insight.

Use Cases
Use Case ID UC-PUB-WORKFLOW-001

Use Case Name Initiate Publication Workflow

Primary Actor(s) Publication Admin

Publication record created and ready for workflow

Pre-conditions
initiation

Post-conditions Publication enters workflow with assigned tasks

Main Success
1. Admin initiates workflow for a publication.
Scenario

2. System assigns tasks to relevant actors based on workflow

configuration.

3. Status updates to “In Progress”.

4. Alerts sent to assigned users. |

| Alternative Path | Workflow initiation aborted by admin; publication
remains in draft. |
 | Business Rules | Workflow stages must follow predefined sequences;
users are notified on task assignment. |

Use Case ID UC-PUB-WORKFLOW-002

Use Case Name Send Alerts and Notifications

Primary Actor(s) System (automated)

Pre-conditions Workflow stage changes or deadlines approaching

Post-conditions Alerts/notifications delivered successfully

Main Success 1. Workflow stage changes or deadline triggers alert

Scenario condition.

2. The system sends email, SMS, and in-app notification to relevant users.

3. Users acknowledge or act on notifications. |

| Alternative Path | Notification delivery failure triggers retry or admin
alert. |
| Business Rules | Alerts configured per workflow event; notification
preferences respected. |

Use Case ID UC-PUB-KPI-001

Use Case Name Automatic KPI Calculation and Evaluation

Primary Actor(s) System (automated), Publication Manager

Publication data updated; KPI calculation schedule

Pre-conditions
triggered

Post-conditions KPIs updated and dashboards refreshed

Main Success 1. System extracts publication data per KPI

Scenario definitions.

2. Calculates KPIs such as publication count, average processing time,

approval rates.

3. Stores KPI values and updates dashboards for management review. |

| Alternative Path | Calculation error logged and reported to admin. |
 | Business Rules | KPIs calculated on schedule (e.g., daily, monthly);
configurable formulas applied. |

Screen/UI Design
 Workflow Dashboard:

o Displays publications by workflow stage

o Task assignment and status update controls

o Visual indicators for overdue tasks

 Alerts & Notifications Center:

o List of recent alerts with filters (Unread, Read, Date)

o Notification preference settings

 KPI Dashboard:

o Graphical representation of KPIs over time

o Drill-down by publication type, center, or user

o KPI configuration panel

Field Level Specifications

Field
Workflow Stage
Label

Field Type Dropdown

Mandatory Yes

Data Type String

Draft, Submitted, In Review, Approved, Published,

Value Set
Rejected

Default
Draft
Value
Field
Workflow Stage
Label

Comments Controls current workflow status of publication

Field
Assigned User
Label

Field Type Lookup Dropdown

Mandatory Yes

Data Type String (User ID)

Value Set List of users with publication workflow roles

Default
None
Value

User assigned responsibility at current workflow

Comments
stage

Field
Alert Type
Label

Field Type Dropdown

Mandatory Yes

Data Type String

Email, SMS, In-App

Value Set
Notification

Default
Email
Value

Specifies notification
Comments
channel

Field
KPI Name
Label

Field Type Text Box

Mandatory Yes
Field
Alert Type
Label

Data Type String

Value Set Predefined KPI list

Default
None
Value

Name of KPI being

Comments
calculated

Field
KPI Value
Label

Field Type Read-only Text

Mandatory Yes

Data Type Numeric (Integer/Decimal)

Value Set N/A

Default
N/A
Value

Calculated KPI value

Comments
displayed

Business Rules and Dependencies

Field Validation / Data
Error Messages
Label Business Rules Dependencies

Workflow Must follow defined "Invalid workflow stage Workflow

Stage sequence transition." configuration

Assigned Must have role "User not authorized for User roles
User permission this workflow stage." database

Must be valid "Unsupported alert type Notification

Alert Type
notification method selected." preferences

KPI Value Must be numeric and "KPI calculation error." Publication data
Field Validation / Data
Error Messages
Label Business Rules Dependencies

within expected range

Buttons, Links, and Icons

Button Other Visibl Enabled vs Navigate
OnClick Event
Label Event e Displayed To

Initiates Enabled if
Start Workflow
publication None Yes publication
Workflow dashboard
workflow status = Draft

Manually triggers Enabled for Alerts

Send Alert None Yes
alert notification authorized users center

Triggers manual Enabled for KPI

Calculate KPI None Yes
KPI recalculation admin roles dashboard

Acknowledge Marks alert as Enabled when Alerts

None Yes
Alert read alert selected center

Risk Assessment
Impac Likeliho
Risk Mitigation
t od

Workflow delays due to Automated alerts, escalation

High Medium
missed notifications procedures

Incorrect KPI calculation due Data validation, error logging,

High Low
to data errors manual overrides

Unauthorized access to
High Low Strict RBAC and audit trails
workflow or KPI data

Mediu Retry mechanisms and

Notification system failure Low
m failover alerts
Updated Non-Functional Requirements
 Performance: Workflow transitions and KPI calculations to occur
within seconds/minutes without user perceptible delay.

 Reliability: Notification delivery with retry and failure reporting; KPI

calculations accurate and consistent.

 Security: Enforced role-based access, encrypted notification channels,

secure audit logs.

 Usability: Clear UI with status indicators, alert badges, and KPI trend
graphs.

 Maintainability: Modular workflow and KPI configurations; easy

updates without system downtime.

 Scalability: Handles increasing publication volume and user base

without degradation.

 Availability: 99.9% uptime for notification and KPI services.

Process Management System
Module Name: PCSIR ERP – Process Management System
Overview
The Process Management System (PMS) module is part of PCSIR's ERP suite
designed to handle the lifecycle of process innovations developed within
PCSIR. This includes capturing newly developed processes, linking them with
R&D efforts, managing inventor records, handling inter-departmental
approvals, generating progress reports, and integrating lease contract data
with CRM and Financial Management Systems. The PMS serves as a
centralized platform to ensure that processes are properly tracked,
evaluated, approved, and commercialized.

Software Requirement Analysis

Functional Requirements:

 Maintain an industries database

 Define source of process (R&D or Demand Driven)

 Link processes with R&D Programs

 Capture fields of study and assign multiple per process

 Allow detailed process entry with meta-data and inventor info

 Auto-generate unique process IDs

 Manage lead and associate inventor records

 Handle multi-level approval workflows

  Generate progress reports

 Record lease contract info

 Interface with CRM (contact info) and Financial Management

(payments)

 Allow wildcard and keyword-based search

 Reassign lead inventor on retirement or deputation

 Backdate entry for legacy processes

Non-Functional Requirements:

 System uptime ≥ 99.9%

 Support for 1000+ concurrent users

 Secure login with role-based access control

 Real-time data sync across ERP modules

High-level Architecture
 Frontend: Web-based UI (React/Angular)

 Backend: RESTful APIs (Node.js/.NET Core)

 Database: PostgreSQL/MySQL

 Integration Services:

o HRMS for employee information

o R&D Program DB for linking sources

o CRM Module for client party info

o Financial Management System for contracts and payments

 Reporting Layer: JasperReports/Power BI for progress reports

 Authentication: OAuth 2.0, PCSIR SSO

Sub-Module: Industry & Field Setup

Purpose/Description: To define the scope and classification of each
process, the system provides a backend list for industry categories and fields
of study. These classifications enable filtered search, reporting, and metadata
enrichment.

Use Cases
Use Case ID: PMS-PMC-01

Use Case Name: Maintain Industries Database

Primary Actor(s): Admin (with industry maintenance rights)
Pre-conditions: User has authenticated session and appropriate privileges
Post-conditions: Industry categories are stored and available for
classification
Main Success Scenario:

1. Admin navigates to Industries Management section.

2. Adds or edits a category (e.g., Cement, Chemicals).

3. Saves entry; the updated list reflects instantly across the system.
Alternative Path:

 Admin attempts to add a duplicate industry → error message shown.

Business Rules:

 Industry names must be unique.

 List is read-only to general users.

Use Case ID: PMS-PMC-02

Use Case Name: Enter Process Metadata

Primary Actor(s): Scientist/Engineer
Pre-conditions: User is logged in and has 'Create Process' role
Post-conditions: Metadata stored; process saved in 'Draft' state with
unique ID
Main Success Scenario:
 1. User selects laboratory/unit/center from hierarchy.

2. Enters Process Title, Year Developed, Keywords (≤10), Features,

Summary.

3. Selects Industry and Fields of Study (multi-select enabled).

4. Adds Lead and Co-Inventors (via HRMS integration or dropdown).

5. Defines Source: R&D (selects associated R&D Program) or Demand

Driven.

6. System generates Process ID: [Lab/Center]-[Year]-[Serial].

7. Saves record.
Alternative Paths:

 Inventor not found in HRMS → dropdown manual selection

 Year > current → error displayed

Business Rules:

 Keywords max: 10 (alphanumeric, comma-separated)

 Year Developed cannot be in the future

 Process ID must be unique

Use Case ID: PMS-PMC-03

Use Case Name: Link Process with R&D Program

Primary Actor(s): Scientist/Engineer
Pre-conditions: Source of Process = R&D
Post-conditions: R&D Program linkage created
Main Success Scenario:

1. User marks 'Source' as R&D during process entry.

2. System prompts for R&D Program.

3. User selects program from dropdown.

4. Link stored in process metadata.

Alternative Path:

 No program selected → system prevents saving.

Business Rules:
  R&D Program must exist in R&D database

 Multiple processes can link to a single R&D program

Use Case ID: PMS-PMC-04

Use Case Name: Search Process Records

Primary Actor(s): Any authenticated user
Pre-conditions: User is logged in
Post-conditions: Matching results displayed
Main Success Scenario:

1. User navigates to Search interface.

2. Inputs one or more filters: keyword, inventor, center, title, field, date
range.

3. System applies wildcard search (case-insensitive).

4. Results sorted by relevance and date.

Alternative Path:

 No results found → ‘No match found’ message

Business Rules:

 Maximum 100 results per page

 Support for partial strings and Boolean queries

Use Case ID: PMS-PMC-05

Use Case Name: Process Approval Workflow

Primary Actor(s): HoC, Director P&D
Pre-conditions: Process has been submitted by inventor
Post-conditions: Status updated as Approved, Rejected, or Objected
Main Success Scenario:

1. HoC reviews submission → approves or returns with objections.

2. If approved & lab is in complex → escalated to Director P&D.

3. Director P&D performs inquiry and takes final decision.

4. Approved → Process marked final; KPIs updated.

Alternative Path:

 Any reviewer objects → returned to Lead Inventor for corrections

Business Rules:
  Approval actions logged with timestamp

 Only fully approved processes trigger KPI update

Use Case ID: PMS-PMC-06

Use Case Name: Record Lease Contract

Primary Actor(s): Contracts Admin, Director General
Pre-conditions: Process is in Approved state
Post-conditions: Lease contract is recorded and shared with CRM & FMS
Main Success Scenario:

1. Admin navigates to lease management

2. Selects approved process

3. Enters contract details: type, lease rights, dates, value, parties, etc.

4. Saves → contract linked with Process ID

5. Data shared with CRM (party info) and FMS (payment/value)

Alternative Path:

 Process not yet approved → error: 'Approval Pending'

Business Rules:

 Contract must include party details, termination clause, and effective

dates

 Only DG or Director can finalize lease registration

Use Case ID: PMS-PMC-07

Use Case Name: Alerts and Notifications

Primary Actor(s): System, HoC, Director P&D, Lead Inventor
Pre-conditions: Process event occurs (submission, approval, objection,
lease)
Post-conditions: Timely notification is sent
Main Success Scenario:

1. Event triggered (e.g., process submitted)

2. System sends notification to relevant actor (e.g., HoC)

3. Action taken (approval/return) → notification cascades accordingly

Alternative Path:
  Email server down → notification queued
Business Rules:

 Notifications logged in audit trail

 Time-stamped alerts visible in user dashboard

Use Case ID: PMS-PMC-08

Use Case Name: Automatic KPI Score Update

Primary Actor(s): System
Pre-conditions: Final approval is completed
Post-conditions: KPI records updated based on process weight
Main Success Scenario:

1. Director P&D approves a process.

2. System evaluates KPI weight (based on complexity, domain, field)

3. KPIs assigned to individual, unit, and center scorecards

Alternative Path:

 Data entry anomaly → error flagged to admin

Business Rules:

 KPI calculation formulas stored in configurable rule base

 Rejected/Objection cases do not affect KPIs

Screen/UI Design
(Wireframes to be appended separately; include sections for Process Form,
Approval Status, Lease Contracts, and Search Filters)

Field-Level Specifications
Field Field Mandator Data Value Defaul
Comments
Label Type y Type Set t Value

Process Max 200

Textbox Yes String NA NA
Title chars

[R&D, If R&D →
Source of Dropdow
Yes Enum Demand R&D show R&D
Process n
Driven] Program field

R&D Dropdow Conditionall FK Linked NA Mandatory if

 R&D
Program n y R&D selected
Programs

Fields of Multi- Array[Strin Must choose

Yes Dynamic NA
Study select g] at least one

If ID
Lead Dropdow From unknown,
Yes FK NA
Inventor n HRMS search by
name

Co- List From Add/remove

No List NA
Inventors control HRMS co-inventors

Year Date ≤ Current Year only, no

Yes Integer NA
Developed Picker Year month/day

Keywords Tag Input No List[String] NA NA Max 10 items

Summary Textarea No String NA NA Optional field

Business Rules and Dependencies

Data
Field Label Validation/Rule Error Message
Dependency

Process Title Not empty Title is required None

Year Must be ≤ current

Invalid year None
Developed year

Invalid Employee
Lead Inventor Must exist in HRMS Lookup HRMS
ID

Source = Must select R&D Trigger R&D

Missing R&D Link
R&D Program field

Contract type
Contract Type Must be selected None
required

Buttons, Links, and Icons

Label OnClick Other Visible Enabled Navigate
 Event Event To

Save
Save Draft NA Yes Yes NA
process data

Submit for Enabled if all

Submit NA Yes NA
HoC required fields filled

Approve Role-
Approve NA Conditional NA
Process based

View Progress Generate & On Report

Yes Yes
Report Show approval Page

Risk Assessment
Likelihoo
Risk Impact Mitigation Strategy
d

Lead Inventor leaves Allow assignment of Acting Lead from

Medium High
PCSIR Co-Inventors

Legacy processes Mediu Allow backdated entry and limited

High
lack data m fields

Implement duplicate check using

Duplicate processes Medium High
Title + Year + Center

Incomplete HRMS Mediu Implement fallback search by name,

Medium
integration m not just ID

Updated Non-Functional Requirements:

 Performance: System must respond to queries within 2 seconds

 Availability: 24/7 availability with planned maintenance window

 Security: AES 256 encryption, RBAC, Audit Trails

 Auditability: Log changes to inventor roles, approval history, and

lease changes

 Scalability: Support for 1000+ concurrent users with elastic scaling

  Localization: English (default), provision for Urdu in future

 Accessibility: WCAG 2.1 compliant UI

Module: Product Management System

Overview:
The Product Management System is a key module within the PCSIR ERP
aimed at maintaining and managing all PCSIR-developed products, whether
originating from R&D or market demand. This system ensures complete
traceability of developed products, facilitates scientific documentation,
integrates product lifecycle workflows, manages feasibility analysis, and
allows KPI evaluation. It streamlines approvals, provides historical visibility
into legacy products, and fosters data reuse and transparency across the
organization.

Software Requirement Analysis:

 Functional Requirements:

o Manage product data including product source, dimensions,

features, specifications, inventor details.

o Support multi-level approval workflow from Inventor → Head of

Center → Director P&D → DG PCSIR.

o Integration with PCSIR Human Resource System for

inventor/employee info.

o Maintain industry-wise product categorization.

 o Facilitate feasibility studies and record production-related
contracts.

o Offer KPI evaluation based on finalized products.

o Support bulk product data entry for legacy systems.

o Provide role-based access for Inventors, HoCs, Directors, DGs.

o Enable auto-generated IDs, pictorial uploads, and literature

additions.

o Enable full-text and wild card search.

 Non-Functional Requirements:

o Highly available with a 99.9% uptime guarantee.

o Scalable and capable of supporting 10,000+ product records.

o Secure access control with RBAC and data encryption.

o Responsive UI optimized for tablet and desktop.

High-Level Architecture:
 Frontend: ReactJS/Angular

 Backend: NodeJS/Django + PostgreSQL

 Integrations:

o PCSIR HR System

o KPI Engine

o Notification System (Email/SMS)

 Authentication: OAuth2 / LDAP

 Storage: S3-compatible for image/literature uploads

 Deployment: Dockerized services hosted on hybrid cloud (GovDC)

Sub Module Name: Product Definition and Approval Workflow

Purpose / Description

This sub-module is responsible for the lifecycle management of PCSIR-

developed products. It facilitates the entry, editing, review, approval,
feasibility validation, contract linkage, and KPI score allocation of new and
legacy products. It supports data-rich entries including inventor profiles,
specifications, raw material needs, and commercial feasibility parameters

Use Cases
Use Case 1

Use Case ID: PMS-UC01

Use Case Name: Add New Product
Primary Actor(s): Lead Inventor, Associate Inventors
Supporting Actors: System (Auto-generates ID), Human Resource System
(fetches employee details), R&D Program Management Module

Pre-conditions:

 User must be authenticated and have a valid PCSIR scientist account.

 The R&D Program (if applicable) must be pre-existing and approved in

the system.

 Fields of Study must be populated from the master database.

Post-conditions:

 A new product is saved in the system with a status of 'Draft' or

'Submitted' depending on the submission action.

 Product is assigned a unique identifier.

 Notification is triggered to HoC for approval workflow.

Main Success Scenario:

1. Scientist logs into the system.

2. Navigates to “Product Management → Add Product”.

3. Selects the Source of Product as either “R&D” or “Demand Driven”.

o If R&D is selected, the system prompts for an R&D reference

number.

o Fields of Study are auto-filled if linked to the R&D program.

4. Enters:

o Laboratory/Center/Division Info

o Product Name, Year of Development

o Lead and Co-Inventors (selected via HR integration)

 o Fields of Study (multi-select)

o Keywords, Summary, Specifications, Dimensions, Materials,

Expiry

o Pictorials and literature uploads

5. System generates a Product ID using a defined naming scheme.

6. Product is saved in draft OR submitted for approval.

7. Success message and Product ID displayed to the user.

Alternative Paths:

 If the Source is R&D:

o System auto-populates relevant data from the associated R&D

Program.

 If the Product is marked as “Legacy”:

o Submission skips approval and is directly marked with the status

"Legacy".

Business Rules:

 Unique Product ID Format: [LabCode]-[CenterCode]-[YYYY]-[Serial]

 All required fields (marked as mandatory) must be filled before

submission.

 Duplicate Product Names under the same year and center are not
allowed.

 Auto-save feature every 5 minutes while in draft.

Use Case 2

Use Case ID: PMS-UC02

Use Case Name: Approve Product (Initial Approval by Head of Center - HoC)
Primary Actor(s): Head of Center (HoC)
Supporting Actors: Lead Inventor

Pre-conditions:

 Product must have been submitted by inventor(s).

 Product is in "Submitted" status and under the purview of the HoC’s

center.
Post-conditions:

 Product is marked as “Initially Approved”, “Rejected”, or “Sent Back for

Rework”.

 Notification sent to relevant stakeholders.

 Approval timestamp logged.

Main Success Scenario:

1. HoC logs into the system dashboard.

2. Navigates to “Pending Product Approvals”.

3. Reviews Product metadata including inventors, fields of study,

specifications, R&D source (if any), feasibility attachments, and
uploaded images.

4. HoC conducts manual inquiry if required.

5. Selects one of three actions:

o Approve → product moves to Director P&D

o Reject → product status marked as “Rejected”

o Object → product is returned to inventor with comments

Alternative Paths:

 If HoC raises objections:

o Product is returned to inventor’s inbox with a message log.

o Status updated to “Returned for Clarification”.

Business Rules:

 Only the HoC of the product’s originating center may take action.

 Approvals/rejections must include digital signature and remarks.

 Once approved, a notification is auto-generated to Director P&D.

Use Case 3

Use Case ID: PMS-UC03

Use Case Name: Final Approval by Director P&D
Primary Actor(s): Director Planning & Development (P&D)
Supporting Actors: Head of Center, Lead Inventor
Pre-conditions:

 Product must be approved by HoC.

 Product must not be a legacy product.

Post-conditions:

 Product marked as “Final Approved” and considered officially

developed.

 Product included in KPI scoring engine.

 Progress report updated for DG PCSIR viewing.

Main Success Scenario:

1. Director P&D logs in and accesses “Pending Final Approvals”.

2. Reviews Product metadata, prior approval trail, feasibility data (if any),
and inventor profile.

3. Cross-checks specifications and Fields of Study.

4. Issues Final Approval.

5. Product becomes part of the official PCSIR product database.

6. KPI module triggered to update relevant scientist scores.

Alternative Paths:

 If objections raised:

o Returned to HoC or Inventor for resubmission.

 If rejected:

o Product sent to "Rejected List".

Business Rules:

 Final approval must be accompanied by remarks.

 KPI auto-calculation uses Product metadata and approval timestamps.

Use Case 4

Use Case ID: PMS-UC04

Use Case Name: Conduct Feasibility Study
Primary Actor(s): Pilot Plant Team, Inventor
Supporting Actors: P&D Unit, Finance Team

Pre-conditions:

 Product has received final approval from Director P&D.

 Inventor formally submits for feasibility evaluation.

Post-conditions:

 Feasibility data is stored and attached to the Product record.

 Editable only until locked by agreement from all parties.

Main Success Scenario:

1. Pilot Plant Team accesses “Feasibility Forms”.

2. Inputs:

o Raw Materials (with Cost Breakdown)

o Utility Costs (Gas, Water, Steam, Electricity)

o Manpower (with per-day cost)

o Machine Depreciation

o Area Rent and Overheads

3. Collaborates with Inventor and Finance.

4. Saves and submits.

5. Agreement status is tracked, and form is locked post-finalization.

Business Rules:

 Editable only until finalized by all parties.

 All cost fields must be numeric and non-negative.

Use Case 5

Use Case ID: PMS-UC05

Use Case Name: Upload Legacy Product
Primary Actor(s): System Admin, Inventor
Supporting Actors: None

Pre-conditions:
  Product must have been developed before the ERP system's
implementation.

Post-conditions:

 Product is saved with status “Legacy” and excluded from KPI scoring.

 Visible in historical records.

Main Success Scenario:

1. Admin or inventor selects “Upload Legacy Product”.

2. Enters all available product information (same as new product).

3. Tags the product as “Legacy”.

4. Submits for archival.

5. Product becomes visible in search with legacy tag.

Alternative Paths:

 If fields are incomplete, system allows partial save but marks missing
elements.

Business Rules:

 Legacy products bypass approval workflows.

 Must be marked as “Non-editable” once archived.

Use Case 6

Use Case ID: PMS-UC06

Use Case Name: Replace Lead Inventor
Primary Actor(s): HR/Admin
Supporting Actors: Associate Inventors, PCSIR HR System

Pre-conditions:

 Existing Lead Inventor is retired, deceased, or on long-term deputation.

 Product must be previously approved or in-progress.

Post-conditions:

 A new Acting Lead Inventor is assigned.

  Historical log updated with reason and timestamp.

Main Success Scenario:

1. HR initiates “Replace Lead Inventor” process.

2. System lists all associate inventors for eligible selection.

3. Admin selects new acting lead from the list.

4. Updates saved and reflected in the product record.

5. Notification sent to new and previous inventors.

Alternative Paths:

 If no associate is present:

o Manual override must be done via admin access with

justification.

Business Rules:

 Only one acting lead allowed per product.

 Replacement reason must be logged.

Screen/UI Design
[UI wireframes and screen mockups will be designed separately. Key
interfaces include:]

 Add/Edit Product Form

 Product Search Screen

 Product Approval Dashboard (HoC and Director)

 Feasibility Study Entry

 Contract Entry Form

 Product Profile Page

Field Level Specifications

Field Mandato Data Default
Field Label Value Set Comments
Type ry Type Value
Product Unique
Text Box Yes String N/A N/A
Name constraint

[R&D,
Source of Dropdow If R&D, show
Yes Enum Demand N/A
Product n R&D Ref field
Driven]

Year Dropdow Year Dynamic Current Past & current

Yes
Developed n (Int) list Year years

Inventor Dropdow PCSIR HR Autocomplete +

Yes Emp ID N/A
Team Lead n DB manual

String[ For search

Keywords Multi-tag No N/A N/A
] purposes

Fields of Multi- String[ From Linked to R&D if

Yes N/A
Study select ] master list selected

Add/Edit/Delete
Material List Multi-row No String Custom N/A
rows

Composit Validate units in

Dimensions No Float N/A N/A
e cm

Business Rules and Dependencies

Data
Field Label Rule Error Message
Dependencies

Source of If R&D selected, R&D Ref "R&D reference is Link to R&D

Product mandatory required" module

"Invalid Employee PCSIR HR

Inventor ID Must exist in HR DB
ID" integration

"Only numbers
Dimensions Must be numeric None
allowed"

Buttons, Links, and Icons

Visibl Enable
Label OnClick Event Other Event Navigate To
e d

Submit for SubmitProduct( N/A Yes True Approval

Approval ) Queue

Upload Literature UploadFile() Drag-Drop Yes True N/A

AutoGenerateI On field Auto-filled

Generate ID Yes True
D() update field

Risk Assessment
Likelihoo
Risk Impact Mitigation
d

Improper inventor
Medium High Integration with HR System
info

Mediu Notification triggers and

Approval delays High
m escalations

Duplicate products Medium High Enforce unique ID & validation

Updated Non-Functional Requirements

Requirement Description

Performance System shall load product data under 2 seconds

Security Role-based access, audit logs, and encrypted storage

Availability 99.9% uptime

Scalability Support 10,000+ products, 1,000 concurrent users

Usability Modern responsive UI with accessibility standards

Maintainabili Modular microservices with isolated services for approval,

ty contracts, and feasibility
Patent Management System
Sub Module Name: Patents Database

Overview
The Patents Database sub-module within the PCSIR Patent Management
System is designed to digitally store, retrieve, manage, and report all
information related to patents, including their source, category, fields of
study, associated inventors, and filing/acceptance data. It facilitates
centralized storage and structured access to data for patents filed or
obtained through PCSIR’s various research and innovation activities.

Software Requirement Analysis

 Integration with PCSIR HRMS (to fetch Inventor/Co-Inventor details)

 Integration with R&D Module (for Source linkage if R&D Program)

 CRUD operations on patent-related data

 Secure access control and user-specific data visibility

  Digital document upload and retrieval (Filed and Acceptance Letters)

 Automated KPI scoring based on approved patents

 Advanced wildcard search and filtering options

High-level Architecture
 Frontend: React.js + TailwindCSS

 Backend: Node.js (Express) / .NET Core

 Database: PostgreSQL

 Document Storage: AWS S3 or on-premises DMS

 Authentication: OAuth2 with Role-based Access Control (RBAC)

 APIs: RESTful APIs for all CRUD and integration operations

 Search Engine: ElasticSearch for Wildcard Search

Purpose/ Description
This sub-module ensures the comprehensive capture of metadata related to
patents, linking them with internal R&D, Fields of Study, categories (product,
process, formula, etc.), and organizations involved. It provides user-level
management for patent data entry, retrieval, approvals, and historical
uploads for legacy patents.

Use Cases
Use Case 1

 Use Case ID: UC-PAT-01

 Use Case Name: Add New Patent Entry

 Primary Actor(s): Scientist/Engineer

 Pre-conditions:

o Actor is logged in

o Actor has relevant role permissions

 Post-conditions:
 o Patent saved in database; pending HoC approval

 Main Success Scenario:

1. Actor selects 'Add New Patent'

2. Enters patent metadata (source, category, fields, office, fee, etc.)

3. Uploads patent letter

4. Saves record

 Alternative Path:

o If Patent Office not found, user alerts admin to add

 Business Rules:

o Mandatory fields must be populated before saving

o At least one inventor must be added

Use Case 2

 Use Case ID: UC-PAT-02

 Use Case Name: Edit Existing Patent Record

 Primary Actor(s): Scientist/Engineer, Admin

 Pre-conditions:

o Patent exists and actor has access

 Post-conditions:

o Patent record updated with audit trail

 Main Success Scenario:

1. Actor searches and selects patent

2. Makes edits and submits

3. Approval workflow resets if critical fields change

 Alternative Path:

o Unauthorized users cannot edit

Screen/UI Design
(Note: Visual wireframes can be appended separately or created using a tool
like Figma)

Main Screens:

 Add/Edit Patent Form

 Patent List View with Filters

 Approval Workflow Panel

 Patent Document Viewer

Field Level Specifications

Defaul
Field Mandato Data
Field Label Value Set t Comments
Type ry Type
Value

255
Patent Title Text Box Yes String N/A N/A character
max

R&D Program,
Link to R&D
In-house R&D,
Dropdow module if
Patent Source Yes Enum Collaborative N/A
n R&D
Research,
Program
Other

Process,
From
Product,
Patent Dropdow maintained
Yes Enum Equipment, N/A
Category n category
Formula,
list
Design

Fields of Multi- Yes String[] From N/A At least one

Study select maintained required
list in Fields of
 Study table

Admin can
Dropdow From Patent
Patent Office Yes FK N/A add missing
n Office table
values

Patent
Unique
File/Receipt Text Box Yes String N/A N/A
constraint
No.

Patent File Date Cannot be

Yes Date N/A N/A
Date Picker future date

Patent Filing Decima Must be

Text Box Yes N/A N/A
Fee l positive

Enables fee
Fee Paid by Checkbo Boolea
Yes Yes/No No receipt
PCSIR x n
input

Mandatory
PO/DD/ if fee paid
Text Box No String N/A N/A
Cheque No. by PCSIR =
Yes

PO/DD/ Date
No Date N/A N/A Conditional
Cheque Date Picker

Mandatory
if fee paid
Bank Name Text Box No String N/A N/A
by PCSIR =
Yes

Scanned Filed File Max size:

Yes File PDF, JPG, PNG N/A
Letter Upload 10MB

Remarks Text Area No String N/A N/A Optional

Business Rules and Dependencies

Validation/ Business
Field Label Error Messages Data Dependencies
Rules

Patent Cannot be empty, Max "Title is required" None

Title 255 chars

Patent Must select one from If R&D, fetch

"Select a source"
Source dropdown program reference

Fields of At least one must be "Select at least one Loaded from Fields of
Study selected field of study" Study DB

"Patent Office not

Patent Must be selected or
found. Contact Editable by Admin
Office created
admin."

If checked, all receipt

Fee Paid "Enter fee receipt PO/DD/Cheque
fields become
by PCSIR details" No./Bank Name etc.
mandatory

Buttons, Links and Icons

Visibl
Label Name OnClick Event Other Event Enabled Navigate To
e

Validate all
Save Patent Save entered data Yes Yes N/A
fields

Upload
Opens file upload None Yes Yes N/A
Letter

Approval
Submit for Sends record for Checks
Yes Yes Workflow
Approval HoC approval validation
Screen

Generates Report
Condition
View Report consolidated N/A Yes Generation
al
report Module

Risk Assessment
Likelihoo
Risk Impact Mitigation Strategy
d
Incorrect linkage with R&D
Medium High Validation with live R&D data
Programs

Missing historical patent Mediu Manual data import from

High
information m legacy records

Role-based access with audit

Unauthorized data edits Low High
trail

Uploads of unsupported file File type validation on client

Medium Low
types and server

Updated Non-Functional Requirements

 Performance: Patent search queries should execute under 2 seconds
for 10,000+ records.

 Security: RBAC, input sanitization, and audit trails for every field-level
change.

 Availability: 99.9% uptime with nightly backups

 Scalability: Designed to accommodate up to 1 million patent records

 Usability: UI with clear field prompts, contextual help, and keyboard

navigation

 Accessibility: Compliant with WCAG 2.1 Level AA

Sub Module: The Patent Office Database
Overview
The Patent Office Database is a core sub-module of the PCSIR ERP Patent
Management System. It is responsible for maintaining detailed information
about national and international patent offices, including their country of
operation, average time required to obtain a patent, and additional
administrative details. This centralized repository facilitates streamlined
integration with patent filing processes and assists in analytical reporting and
decision-making for scientists and administrative authorities.

Software Requirement Analysis

 Maintain CRUD functionality for patent offices

 Link patent offices with patent applications

 Fetch data dynamically for patent filing forms

 Ensure validation and uniqueness constraints

 Allow admin to add new offices when missing

 Support national and international differentiation via country field

High-Level Architecture
 Frontend: Angular/React UI Components for CRUD operations

 Backend: RESTful API with Spring Boot

 Database: PostgreSQL – Tables for PatentOffice

 Security: Role-based access (Admin/User)

 Integration: Connected to Patent Filing Sub-Module

Sub Module Name: Patent Office Database

Purpose/Description:

The Patent Office Database sub-module captures and manages metadata

related to official patent bodies involved in patent processing. It enables
seamless patent form filling, prevents duplicate entries, and provides
accurate timelines for obtaining patents based on office-specific durations.

Use Cases
Use Case ID: POF-01

Use Case Name: Add a New Patent Office Primary Actor(s): Admin Pre-
conditions:

 User must have admin privileges

Post-conditions:
  New patent office entry is saved and available in selection dropdowns
Main

Success Scenario:

1. Admin navigates to 'Patent Office Database'

2. Clicks on 'Add New Office'

3. Enters all required details and submits

4. System validates and saves data

Alternative Path:

 If validation fails, system prompts with specific error message

Business Rules:

 Patent Office name must be unique

 Country must be selected from valid list

 Average Time must be numeric

Use Case ID: POF-02

Use Case Name: Edit Patent Office Entry Primary Actor(s): Admin Pre-
conditions:

 Patent office entry exists

Post-conditions:

 Office information is updated successfully

Main Success Scenario:

1. Admin selects office to edit

2. Updates field(s) and submits

3. System validates and updates record

Alternative Path:

 Duplicate names or invalid fields trigger error messages Business

Rules:

 Historical tracking of changes (audit trail)

Screen/UI Design
(To be attached separately as a wireframe/prototype)

 Search bar

 Grid view of existing offices

 Button: Add New Office

 Button: Edit / Delete on each row

Field Level Specifications

Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

Patent
Unique, max
Office Text Box Yes String N/A N/A
100 characters
Name

Patent List of ISO Country selector

Dropdow
Office Yes String Country N/A with search
n
Country Codes option

Average
Only numbers,
Time (in Text Box Yes Integer N/A 24
max 3 digits
months)

Optional 500-
Remarks Text Area No String N/A N/A
character notes

Business Rules and Dependencies

Validation / Business Data
Field Label Error Messages
Rules Dependencies

Patent Office Must be unique, "Patent Office Name None

Name required must be unique"

Patent Office Required, must be from "Please select a valid

None
Country predefined list country"

Required, must be "Enter a valid number

Average Time None
positive integer ≤ 999 for average time"

Buttons, Links and Icons

Other Visibl Enabled vs
Label OnClick Event Navigate To
Event e Displayed

Add New Opens new Enabled Same page

N/A Yes
Office office form (Always) modal popup

Saves form to
Save N/A Yes Enabled if valid None
database

Enabled on row
Edit Opens edit form N/A Yes None
select

Deletes Enabled on row

Delete Confirm Yes None
selected office select

Risk Assessment
 Risk: Duplicate entries of Patent Offices

o Mitigation: Enforce uniqueness validation on Patent Office

Name

 Risk: User confusion with international/national distinction

o Mitigation: Use country flags or tooltips

 Risk: Unvalidated entries added without admin control

o Mitigation: Restrict access to admin role only

Updated Non-Functional Requirements

 Performance: Office dropdowns must load in under 1 second

 Scalability: Supports unlimited office records

 Security: Admin-only write access, user-level read-only access

  Audit Trail: Log each add/edit/delete with timestamp and user

 Availability: 99.5% uptime with real-time backup of database

Sub Module: The Author and Co-Author Information

Overview
The Author and Co-Author Information sub-module is a component of the
PCSIR ERP Patent Management System. This sub-module facilitates the entry,
validation, tracking, and management of detailed authorship information
related to patents, including primary and co-author details, their respective
roles, designations, and affiliations. It ensures clear attribution, proper author
hierarchy, and traceability of inventors across PCSIR centers and
collaborative entities.

Software Requirement Analysis

This sub-module requires integration with:
  Patent Registration Sub-Module

 PCSIR Employee Directory

 Collaboration Management Sub-Module

 External Inventor Repository

Functional requirements:

 Add/edit/delete primary author and co-authors

 Assign author roles (e.g., Inventor, Contributor)

 Manage author position (e.g., Lead, Second, Corresponding)

 Link authors to organizational units

 Validate against internal directory or allow external author entry

Non-functional requirements:

 Secure access and data encryption

 Multi-user concurrency handling

 Audit logs for author modifications

High-level Architecture
 Frontend: React-based UI with role-based input forms for authorship
entry

 Backend: RESTful API, Node.js with PostgreSQL database

 Integration Layer: Author lookup via Employee Directory API

 Security: JWT-based authentication, role-based access

Sub Module Name: Author and Co-Author Information

Purpose/Description
To maintain a structured database of authors and co-authors for patents,
including positions and contributions. This ensures proper recognition, clarity
of intellectual contribution, and linkage to patent metadata for analytical,
legal, and reporting purposes.

Use Cases
Use Case 1

 Use Case ID: ACI-01

 Use Case Name: Add Primary Author

 Primary Actor(s): Patent Officer, Researcher

 Pre-conditions: Patent application exists and is editable

 Post-conditions: Author is added and linked to patent

 Main Success Scenario: User selects patent → clicks "Add Author" →

enters author details → submits → Author added

 Alternative Path: If author not found in directory, user manually

enters data

 Business Rules: Only one primary author can be assigned

Use Case 2

 Use Case ID: ACI-02

 Use Case Name: Assign Author Position

 Primary Actor(s): Admin, Patent Officer

 Pre-conditions: Author exists in system

 Post-conditions: Author position updated

 Main Success Scenario: Admin selects author → assigns position

from dropdown → saves

 Alternative Path: System prevents duplicate positions

 Business Rules: Position is unique per patent

Screen/UI Design
(Placeholder for wireframe)

 Add/Edit Author Form

 Author List with Roles and Position columns

Field Level Specifications

Defaul
Field Field Mandato Data
Value Set t Comments
Label Type ry Type
Value

Autocomplete
Author Strin
Text Box Yes - - from
Name g
employee DB

[Primary
Dropdow Strin Mandatory
Author Type Yes Author, Co- -
n g selection
Author]

[Lead, Second, Unique per

Author Dropdow Strin
Yes Corresponding, - author per
Position n g
Contributor] patent

Affiliated Defaults to
Strin
Organizatio Text Box No - PCSIR PCSIR if
g
n internal

Email Validation for

Text Box No Email - -
Address format

Contact Strin Numeric +

Text Box No - -
Number g validation

Business Rules and Dependencies

Data
Field Label Validation / Business Rules Error Messages
Dependencies

Must exist in employee DB "Author name is

Author Employee
or manually entered if required or not
Name Directory API
external found."

Author Required; only one Primary "Only one primary Patent metadata
Type allowed author is allowed."

Author Unique for each author per "Duplicate author Author list of
Position patent position detected." same patent

Email "Invalid email

Must match email format -
Address format."

Contact Must be numeric and of "Invalid contact

-
Number valid length number."

Buttons, Links, and Icons

Other Visibl Enable
Label OnClick Event Navigate To
Event e d

Add
Opens Author Entry form - Yes Yes -
Author

Edit Opens Author Edit form - Yes Yes -

Prompts deletion
Delete - Yes Yes -
confirmation

Saves entered author Refreshes Author

Save - Yes Yes
data List

Returns to author
Cancel Cancels entry/edit - Yes Yes
list

Risk Assessment
Probabilit
Risk Impact Mitigation Plan
y

Mediu Enforce unique constraints and

Duplicate author entries Medium
m validations

External author not Mediu Manual verification and admin

Low
verifiable m review

Incorrect position Low High Mandatory validation and role

hierarchy assignment logic enforcement

Updated Non-Functional Requirements

 Response Time: UI must respond within 2 seconds for data submission

 Availability: Sub-module must maintain 99.9% uptime

 Security: Role-based access to author editing

 Audit Trail: All changes to authorship logged with timestamp and user
ID

 Scalability: Must support up to 50,000 authors across all patents

Sub Module: The "Patent File Information"

Overview
The "Patent File Information" sub-module is part of the PCSIR ERP Patent
Management System. This sub-module is designed to capture, store,
manage, and retrieve detailed metadata associated with patent filing
activities. It ensures PCSIR intellectual property data is accurately stored,
monitored, and accessed efficiently for internal review, compliance, and
reporting.
Software Requirement Analysis
This sub-module must allow authorized users to input, edit, and retrieve
detailed information about patents, such as Patent Number, Title, File
Number, Filing Date, and Fee Payment Details. It must ensure validation of
fields, enable historical tracking, and be integrated with patent workflow
approval and fee tracking modules.

High-Level Architecture
 Frontend: React.js with Tailwind CSS

 Backend: Node.js with Express.js

 Database: PostgreSQL

 APIs: RESTful APIs

 Security: Role-based access control, audit trails, SSL encryption

Sub Module Name: Patent File Information

Purpose/Description

This sub-module facilitates data entry, storage, and access to critical patent
file metadata. It ensures systematic management of intellectual property,
prevents data redundancy, enables real-time tracking of fees and filing
status, and supports downstream workflows.

Use Cases
Use Case 01

 Use Case ID: PF-001

 Use Case Name: Add New Patent File

 Primary Actor(s): IP Management Officer, R&D Officer

 Pre-conditions:

o User must be authenticated.

o Patent Database record must exist.

 Post-conditions:

o New patent file metadata is saved and linked to existing records.

 Main Success Scenario:

1. User logs in.

 2. Navigates to "Patent File Information" screen.

3. Enters mandatory fields.

4. Submits the form.

5. System validates and saves data.

 Alternative Path:

o Validation error if fields are left blank or incorrect formats are

entered.

 Business Rules:

o Patent No. must be unique.

o Fee Amount must be numeric.

Screen/UI Design
[To be generated upon request – includes fields and buttons as per below
specifications.]

Field Level Specifications

Field Field Mandato Default Comment
Data Type Value Set
Label Type ry Value s

Patent Alphanumer Must be

Text Box Yes N/A N/A
Number ic unique

Patent Max 255

Text Box Yes String N/A N/A
Title characters

File/ Auto- Uniquely

Alphanumer
Receipt Text Box Yes N/A generate identifies
ic
Number d the file

Cannot be
Date Today’s
File Date Yes Date N/A a future
Picker date
date

Must be
Filing Fee Text Box Yes Decimal N/A N/A
positive
Fee Paid,
Dropdow Controlled
Payment Yes Enum Unpaid, Unpaid
n set
Status Partial

Fee Upload
File .pdf/.jpg/.pn
Receipt No File N/A scanned
Upload g
Upload copy

Business Rules and Dependencies

Data
Field Label Validation/Business Rules Error Messages
Dependencies

Patent "Patent Number is Patent Database

Must be unique, not null
Number required or exists" Table

File Date Cannot be future date "Invalid filing date" System Date

Must be numeric,
Filing Fee "Enter valid amount" None
positive

Fee Receipt File size < 5MB; "Invalid file format or

None
Upload formats .pdf/.jpg/.png size"

Buttons, Links, and Icons

Other Visibl Enable
Label OnClick Event Navigate To
Event e d

Validate form and Refresh current

Save N/A Yes Yes
save data screen

Cancel Discard changes N/A Yes Yes Previous page

View Patent Load patent Modal view or

N/A Yes Yes
Details metadata popup new tab

Upload
Trigger file dialog N/A Yes Yes N/A
Receipt
Risk Assessment
 Data Entry Errors: Risk of incorrect fee input or date formatting.
Mitigated through front-end validation.

 Duplicate Patent Numbers: Controlled via backend validation and

unique constraints in DB.

 Missing Uploads: Optional, but flagged in UI to ensure awareness.

 Loss of Receipt Files: Stored in secure cloud storage with backup.

Updated Non-Functional Requirements

 Performance: Data entry form must load in under 3 seconds.

 Availability: 99.9% uptime, accessible through secure login.

 Security: Encrypted data in transit and at rest. Access restricted to

authorized personnel.

 Scalability: Supports concurrent users across PCSIR centers.

 Auditability: All actions logged with timestamp, user ID, and IP.

Sub Module: The "Patent Obtained Information"

Overview
The "Patent Obtained Information" module is part of the Intellectual Property
Management System (IPMS) within PCSIR's ERP. This module captures
detailed information about patents that have been successfully obtained,
including metadata such as Patent Number, Title, Receipt Numbers, Dates,
and Acceptance Validity. The goal is to maintain a traceable, query able, and
audit-compliant repository of all patents received.

Software Requirement Analysis

This module must:

 Store and manage patent receipt details.

 Provide status monitoring and notifications for patent validity.

  Enable linkage with other modules (e.g., R&D, Author Information).

 Ensure role-based access control for sensitive legal and financial data.

 Be searchable with advanced filters.

 Allow export to PDF, Excel, or system print formats.

High-level Architecture
 Frontend: React.js + Tailwind CSS

 Backend: Node.js + Express

 Database: PostgreSQL

 Authentication: Role-based OAuth2

 Integration APIs: Document Management System, Notification

Service, Reporting Engine

Sub Module Name: Patent Obtained Information

Purpose/ Description

This sub-module provides a structured interface for storing and managing

data related to patents that have been officially granted to PCSIR or its
researchers. It serves as the final step in the patent lifecycle workflow. It
ensures auditability, compliance tracking, and integration with the
organization’s research output metrics.

Use Cases
Use Case ID: POBT001

Use Case Name: Add New Patent Obtained Record

Primary Actor(s): IP Officer, Patent Clerk
Pre-conditions: Patent must be granted and relevant documentation
available
Post-conditions: Patent record is successfully saved and linked with prior
Patent File Info
Main Success Scenario: User fills all fields > submits form > system
validates > data saved
Alternative Path: Missing mandatory fields > system throws validation
error
Business Rules: Acceptance Validity should be in future; Patent No. must be
unique
Screen/UI Design
(Sample wireframe to be attached during UI/UX phase)

Field Level Specifications

Field Mandato Data Value Default
Field Label Comments
Type ry Type Set Value

Text Unique, Auto-

Patent No. Yes String N/A N/A
Box validates format

Text Must match prior

Patent Title Yes String N/A N/A
Box filed record

Patent Auto-
Text
Obtained/Receipt Yes String N/A N/A incremented
Box
No. optionally

Patent Received Date Current Cannot be

Yes Date N/A
Date Picker Date future-dated

Text Can be same as

Acceptance No. Yes String N/A N/A
Box Receipt No.

Must be on or
Date
Acceptance Date Yes Date N/A N/A after Received
Picker
Date

Acceptance Date +20 Defaulted to 20

Yes Date N/A
Validity Picker years years if blank

Business Rules and Dependencies

Validation/ Business Data
Field Label Error Messages
Rules Dependencies

Must be
Patent No. alphanumeric and "Duplicate Patent No." Patent Filing
unique

Cross-check with "Patent Title not found in

Patent Title Patent Filing
filed records filing stage."

Acceptance >= Received Date "Acceptance Date must Patent

Date not be before Received Received Date
 Date."

Acceptance >= Acceptance "Validity must be after Acceptance

Validity Date Acceptance Date." Date

Buttons, Links, and Icons

Other Visibl Enabled vs
Label OnClick Event Navigate To
Event e Displayed

Save Save data to Enabled

None Yes None
Record database always

Reset Enabled
Clear form None Yes None
Form always

View All Redirect to list Enabled

None Yes /patents/obtained
Patents view always

Export to Export current Enabled if Generate and

None Yes
PDF record record saved download file

Risk Assessment
Risk
Risk Description Mitigation Strategy
ID

R-001 Data loss due to form timeout Auto-save draft every 2 mins

Invalid acceptance dates Date validations and audit logs

R-002
corrupting reports enabled

Automated cross-check with Filing

R-003 Duplication due to manual entry
record
Updated Non-Functional Requirements
 Data must be encrypted at rest and in transit.

 The UI must support both English and Urdu labels.

 Response time for data submission must be under 2 seconds.

 System should support minimum 50 concurrent patent entries.

 SLA for bug fix on this module: Critical - 1 working day, Medium - 3
working days.

Sub Module: The "Patent Files/Obtained Approval Workflow

Overview
The "Patent Files/Obtained Approval Workflow, Alerts and Notifications, and
Automatic KPI Calculation" sub-modules are integral components of the
PCSIR ERP Patent Management System. These features ensure that all
submitted and obtained patents undergo systematic review and approval,
that stakeholders are alerted about important deadlines or actions, and that
KPIs are auto-evaluated to track progress and efficiency. This improves
transparency, accountability, and performance tracking across the
organization.
Software Requirement Analysis
The system must:

 Implement multilevel approval workflows for submitted and obtained

patent files.

 Trigger automated alerts/notifications via email/SMS based on status

changes or pending actions.

 Automatically calculate patent-related KPIs such as Time-to-Approval,

Compliance Timeliness, and Productivity Index.

System Dependencies:

 Notification service (SMS/Email gateway)

 Patent File and Patent Obtained data modules

 User management for role-based access

 KPI repository and configuration rules

High-level Architecture
1. Frontend: Web-based UI for workflow approval, KPI dashboards, and
notification settings.

2. Backend: Business logic layer managing workflows, notification

events, and KPI algorithms.

3. Database: Stores workflow statuses, notifications, and computed KPI

data.

4. Integration Layer: Connects with Patent data modules, HRM, and

reporting engines.

Sub Module Name

1. Patent Files/Obtained Approval Workflow

2. Alerts and Notifications

3. Automatic KPI Calculation and Evaluation

Patent Files/Obtained Approval Workflow

Purpose/Description
This sub-module ensures each patent application or obtained patent record
goes through a formalized review and approval process involving predefined
roles (e.g., Center Head, Legal Cell, Director). It guarantees accountability
and approval traceability.

Use Cases
Use Case ID: PWF-001
Use Case Name: Initiate and Approve Patent Workflow
Primary Actor(s): R&D Officer, Legal Reviewer, Center Head, Director
Pre-conditions: Patent file data must be complete
Post-conditions: Status changed to "Approved", timestamped with
approver info
Main Success Scenario:

1. R&D Officer submits patent record for review.

2. Legal Reviewer verifies IP-related completeness.

3. Center Head reviews technical legitimacy.

4. Director gives final approval. Alternative Path:

 Rejection at any stage sends back to R&D Officer with comments.

Business Rules:

 Only users with specific roles may approve.

 No skip in workflow levels allowed.

Alerts and Notifications

Purpose/Description

This sub-module sends automated alerts and reminders for patent deadlines,
pending approvals, KPI anomalies, and important dates (e.g., renewal due
dates).
Use Cases
Use Case ID: ALERT-001
Use Case Name: Generate Patent Notifications
Primary Actor(s): System
Pre-conditions: Notification rules configured
Post-conditions: User notified via email/SMS
Main Success Scenario:

1. System identifies pending approval exceeding threshold.

2. Notification triggered and delivered to relevant role. Alternative

Path:

 Delivery failure is logged and reattempted. Business Rules:

 Alerts must be sent 3 days before deadlines.

 Escalation alerts after 48 hours of inaction.

Automatic KPI Calculation and Evaluation

Purpose/Description

KPI metrics like "Average Approval Time", "Patent Productivity", "Timely

Renewal Compliance" are auto-calculated based on data and presented in
dashboards.

Use Cases
Use Case ID: KPI-001
Use Case Name: Calculate and Evaluate Patent KPIs
Primary Actor(s): System, Director R&D
Pre-conditions: Patent file workflow logs, obtained patent dates
Post-conditions: Updated KPI metrics available in dashboard
Main Success Scenario:

1. System scans patent records.

2. Applies formulas to compute KPIs.

3. KPIs updated in reports and dashboards. Alternative Path:

 If any critical data is missing, KPI calculation skipped and logged.

Business Rules:

 Metrics refresh every 24 hours.

 Manual override only by Admin role.

Screen/UI Design
(Wireframes to be shared separately. Key screens: Approval Dashboard, Alert
Settings Panel, KPI Dashboard)

Field Level Specifications

Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

[Pending,
Role-
Approval Dropdow Reviewed,
Yes String Pending dependent
Status n Approved,
visibility
Rejected]

Shown on
Approver
Text Area No String — — rejection
Comments
only

Notification Dropdow [Email, SMS, For alerts

Yes String Both
Type n Both] setup

[Avg Approval
Dropdow Time, Used in KPI
KPI Type Yes String —
n Productivity, Dashboard
Compliance]

Business Rules and Dependencies

Validation/Business
Field Label Error Messages Data Dependencies
Rules

Approval "Previous approval Depends on

Cannot skip stages
Status pending" workflow config

Notification "Select notification

Must be selected Alerts config table
Type type"

Must match Calculated from

KPI Type "Invalid KPI type"
predefined list patent data

Buttons, Links, Icons

Other Visibl Enabled vs
Button Label OnClick Event Navigate To
Event e Displayed
Submit for Triggers Approval
— Yes Enabled
Approval workflow List

Sends
Send Alert — Yes Enabled —
notification

Loads KPI
View KPI Report — Yes Enabled
dashboard Dashboard

Risk Assessment
 Incorrect Approval Flow Configuration: May cause missed
validations — mitigated by validation rules.

 Notification Delivery Failures: Redundancy via email/SMS; error

logging included.

 KPI Miscalculation: Handled via automated tests and admin override

access.

Updated Non-Functional Requirements

 System must handle 100+ concurrent KPI evaluations.

 Alert delivery must occur within 60 seconds of trigger.

 Approval UI must render under 2 seconds.

 KPIs refresh every midnight automatically.

Design and Fabrication Management System
Sub Module: Industries Database Management and Measurement
Units Definition:
Overview:
This document provides the functional specifications for two foundational
components of the PCSIR ERP Design and Fabrication Management System:

1. Industries Database Management

2. Measurement Units Definition

These sub-modules serve as the backbone for classification and

standardization of data, enabling all other modules to correctly interpret,
categorize, and interact with domain-specific information.

Software Requirement Analysis:

The software must allow:

 Seamless creation, update, deactivation, and querying of industries in

a master list.

 Standardized unit of measurements to be added with relevant

metadata (abbreviation and remarks).

 Secure access with role-based permission for creation or modification.

 Data integrity with validations and lookups to avoid duplication or

inconsistent entries.

 Integration with dependent modules for real-time data referencing

(such as Product Management, Fabrication, KPI calculation, etc.).

High-Level Architecture:
 Frontend: React.js UI with Tailwind CSS styling

 Backend: Node.js with Express.js API

 Database: PostgreSQL

 Authentication: Integrated with PCSIR LDAP/SSO

 Integration: REST APIs for inter-module communication

Sub-Module: Industries Database:
Purpose/Description:

This sub-module enables administrative users to manage and update the

standardized list of industries across Pakistan. The list helps in classifying the
origin and context of developed products and processes, making analytics
and reporting consistent.

Use Cases:
Use Case ID: IND-01
Use Case Name: Add New Industry
Primary Actor(s): System Administrator, Head of Division
Pre-conditions: User must be authenticated and authorized
Post-conditions: New industry entry becomes available for selection across
dependent modules
Main Success Scenario:

1. User clicks on "Add Industry"

2. Enters industry name

3. System checks for duplicates

4. Industry saved successfully

Alternative Path:

 If duplicate name detected, system prevents submission and alerts

user

Business Rules:

 Industry name must be unique

 Industry name must be more than 3 characters

Screen/UI Design:
To be designed: Basic CRUD grid view with inline form or modal popup for
Add/Edit functionality

Field Level Specifications:

Field Field Mandato Data Value Default
Comments
Label Type ry Type Set Value

Industry
Text Box Yes String N/A N/A Must be unique
Name
 Used to
Dropdow Active,
Status Yes Boolean Active deactivate old
n Inactive
entries

Business Rules and Dependencies:

Validation/Business Data
Field Label Error Messages
Rules Dependencies

Industry Must be unique, min 3 "Industry already

None
Name characters exists"

Buttons, Links, and Icons:

Button OnClick Visibl Enabled vs Navigate
Label Event e Displayed To

Add
Save data Yes Enabled N/A
Industry

Cancel Reset form Yes Enabled N/A

Risk Assessment:
 Risk: Duplicate entries may cause inconsistency
 Mitigation: Unique constraint and duplicate check validations
Sub-Module: Measurement Units Definition:
Purpose/Description:

This sub-module allows users to define units of measurement for scientific

equipment, processes, and product specifications. These units are referenced
across all scientific records, testing parameters, and contract documentation.

Use Cases:
Use Case ID: MU-01
Use Case Name: Add Measurement Unit
Primary Actor(s): Technical Staff, System Administrator
Pre-conditions: Must be authenticated and authorized user
Post-conditions: Unit appears in dropdowns for relevant modules
Main Success Scenario:

1. User clicks "Add Unit"

2. Enters unit name, abbreviation, and remarks

3. System validates and saves the unit

Alternative Path:

 User skips abbreviation; system shows warning

Business Rules:

 Unit name must be unique

 Abbreviation recommended but not mandatory

Screen/UI Design:
To be designed: Standard grid with modal or side-form for input

Field Level Specifications:

Field Field Mandato Data Value Default
Comments
Label Type ry Type Set Value

Text e.g., Kilogram,

Unit Name Yes String N/A N/A
Box Centigrade

Abbreviati Text
No String N/A N/A e.g., Kg, °C
on Box

Text Free text about

Remarks No String N/A N/A
Box context/usage
Business Rules and Dependencies:
Field Validation/Business Error
Data Dependencies
Label Rules Messages

Unit Must be unique and 2+ "Unit already

None
Name chars exists"

Buttons, Links, and Icons:

Button On Click Visibl Enabled vs
Navigate To
Label Event e Displayed

Add Unit Save Unit Yes Enabled N/A

Reset Clear Fields Yes Enabled N/A

Risk Assessment:
 Risk: Inconsistent unit abbreviations causing confusion
 Mitigation: Central list with abbreviation recommendations and
validations

Updated Non-Functional Requirements:

 Performance: Should allow industry and unit lookup in under 1
second.

 Scalability: Support for 1000+ units and 100+ industries without

performance degradation.

 Security: Only authenticated users with proper roles can edit records.

 Usability: Simple interfaces with tooltips and auto-suggestions.

 Availability: 99.9% uptime with auto-recovery mechanisms.

 Audit Logging: All additions and changes to be logged with user IDs
and timestamps.
Design and Fabrication Information Management & Search
Overview
The Design and Fabrication Management sub-module is a key component of
PCSIR’s ERP system that allows for the digital recording, management, and
retrieval of detailed information about equipment and fabrication activities.
This sub-module supports structured entry, updating, and keyword-based
searching of fabrication items, including full technical specifications, inventor
data, and materials lists. It ensures traceability, enables easy retrieval via
wildcard and keyword search, and supports cross-linking with inventors,
departments, centers, and research outcomes.

Software Requirement Analysis

 Users: PCSIR Engineers, Technical Managers, Admin Staff, R&D
Department, Fabrication Unit, Quality Assurance Team

 Functional Requirements:

o Add, edit, and view equipment design and fabrication records

o Maintain inventor data and year of development

o Attach capacity unit, specifications, and material details

o Support keyword tagging and wildcard search functionality

o Link with centers, units, and related R&D records

 Non-Functional Requirements:

o High availability and fast response time

o Audit trail for changes

o Strong access control for different roles

o Data validation and integrity

High-Level Architecture
 Frontend: Angular / React (Web-based interface)

 Backend: Node.js / .NET Core with RESTful APIs

 Database: PostgreSQL / SQL Server

  Security: Role-based access control, JWT Authentication

 Middleware: API Gateway, Caching Layer for Search

 Integration: ERP Core Modules (Inventors DB, R&D Program DB, CRM)

Sub-Module Name: Design and Fabrication Information Management &

Search
Purpose / Description

This sub-module captures the complete lifecycle details of fabricated

equipment and components at PCSIR. It supports the structured
documentation of fabrication metadata such as equipment name, alias,
model, specifications, dimensions, center association, unit, year of
development, inventor details, list of materials used, and technical
specifications. It allows users to perform keyword-based and wildcard search
across all fabrication records.

Use Cases
Use Case 1

 Use Case ID: DF-01

 Use Case Name: Add New Fabrication Record

 Primary Actor(s): Fabrication Engineer, Admin Officer

 Pre-conditions: User is authenticated and has data entry privileges

 Post-conditions: New fabrication record is saved and assigned a

unique identifier

 Main Success Scenario:

1. User opens fabrication entry screen

2. Fills required fields: Name, Alias, Model, Capacity Unit,

Dimensions, Inventors, etc.

3. Uploads document (blueprints/specs if any)

4. Submits the form

5. System validates and saves the record

 Alternative Path:
 o Missing fields → System highlights mandatory errors

o Duplicate name → Prompt user to confirm overwrite or edit

 Business Rules:

o Equipment name must be unique within the same center

o Year must not be in the future

Use Case 2

 Use Case ID: DF-02

 Use Case Name: Search Fabrication Record

 Primary Actor(s): QA Officer, Center Manager, Inventor

 Pre-conditions: User is authenticated

 Post-conditions: List of matched fabrication records retrieved

 Main Success Scenario:

1. User accesses search screen

2. Enters keyword or partial text using wildcard (e.g., Mixer, Pump)

3. Hits Search

4. System performs full-text index search

5. Displays list with filters and match highlighting

 Alternative Path:

o No matches found → Show appropriate message

o Too many matches → Suggest filter options

 Business Rules:

o Minimum 2 characters for search term

o Search across name, alias, keyword, inventor name,

specifications
Screen/UI Design
(Attach wireframes or describe)

1. Fabrication Record Entry Form

2. Search and Results Grid View

3. Detailed Record View with Print Option

Field Level Specifications

Field Mandato Data Value Defaul
Field Label Comments
Type ry Type Set t Value

Dropdow
Unit Name Yes String Units DB — Lookup
n

Dropdow Centers
Center Name Yes String — Lookup
n DB

Equipment Name Text Box Yes String — — Unique

Equipment Alias Text Box No String — — Optional

Equipment Model Text Box Yes String — — —

Dropdow
Capacity Unit No String Units DB — Optional
n

Date Current Validation ≤

Year Developed Yes Year —
Picker Year Current Year

Multi- Inventor
Inventor(s) Yes List — Lookup
select s DB

Searchable
Keywords Text Box No String — —
Tags

Features/ Long
Text Area No Text — —
Specifications Description

Format:
Dimensions Text Box No String — —
LxWxH
 Bullet List
List of Materials Text Area No Text — —
Supported

Business Rules and Dependencies

Data
Field Label Validation/Business Rules Error Messages
Dependencies

Year "Year cannot be

Must be ≤ current year None
Developed in the future"

Equipment Must be unique within the "Duplicate entry

Unit, Center
Name same center and unit exists"

At least one inventor must be "Select at least

Inventor(s) Inventor DB
selected one inventor"

Buttons, Links and Icons

Button Other Visibl Enabled vs
On Click Event Navigate To
Label Event e Displayed

Save Save current Enabled if all Fabrication

— Yes
Record form mandatory filled Details Page

Reset Clear form — Yes Always Enabled —

Initiate search Enter key Enabled with min

Search Yes —
query press 2-char input

View Show detailed Enabled if row Detailed View

Row click Yes
Details record view selected Modal

Export to Download
— Yes Enabled on View —
PDF record as PDF

Risk Assessment
Risk Description Likeliho Impac Mitigation Strategy
 od t

Duplicate data entry due to Uniqueness validation,

Medium High
user error confirmation prompts

Improper search results due to Mediu Enforce proper keyword

Medium
incorrect tagging m standards

Unauthorized access to
Low High Role-based access control
confidential fabrication data

Missing inventor linkage on Mediu

Medium Mandatory inventor field
older records m

Updated Non-Functional Requirements

 Performance: System must return search results under 2 seconds

 Scalability: Should handle up to 1M fabrication records

 Security: Records accessible only to authorized roles

 Audit Trail: Changes logged with user, timestamp, and action

 Backup & Recovery: Daily backup with 7-day retention

 Search: Supports fuzzy, wildcard, and full-text search

Sub Module Name: Equipment Contract Management &
Repair/Maintenance Tracking

Overview
This sub-module of the Design and Fabrication Management System aims to
manage contractual, legal, and operational metadata associated with
fabricated equipment. It allows users to capture and retrieve detailed
information regarding equipment-specific contracts, such as contract types,
value, quality control obligations, and legal rights (e.g., logo rights).
Additionally, it provides a structured mechanism to track in-lab and on-site
repair and maintenance activities, ensuring transparency, accountability, and
lifecycle traceability.

Software Requirement Analysis

 Technology Stack: Angular (Frontend), .NET Core (Backend), MS SQL
Server (Database)

 User Roles: Center Admins, Design Engineers, Maintenance Staff, Legal

Department

 Integration: Asset Registry Module, Financial Management Module

 Security: Role-based access control (RBAC), Audit logging, File

encryption for contract attachments

High-level Architecture
 Frontend: Angular SPA with component-based design for form input
and history logs

 Backend API: .NET Core RESTful APIs

 Database: Relational schema using normalized tables for Contracts,

Repairs, Equipment Info

 Storage: Azure Blob/On-Prem for storing contract documents, repair

logs

 Authentication: OAuth2 integrated with PCSIR IAM system

Purpose/ Description
This sub-module is designed to handle the lifecycle management of design
and fabrication-related contractual engagements and equipment
maintenance. The contract management section ensures all legal, quality,
and ownership parameters are digitally recorded. The repair and
maintenance component allows tracking of incidents, service history,
responsible personnel, and whether the event occurred on-site or in-lab.

Use Cases
Use Case 1

 Use Case ID: DFM-CM-001

 Use Case Name: Record Equipment Contract

 Primary Actor(s): Legal Officer, Design Admin

 Pre-conditions: Equipment must exist in Design Database

 Post-conditions: Contract metadata stored and linked to Equipment

ID

 Main Success Scenario:

1. User logs in

2. Navigates to Equipment Profile

3. Selects "Add Contract"

4. Fills all fields (Contract Type, Dates, Value, QC Clauses, etc.)

5. Uploads relevant document

6. Clicks Submit

7. Contract saved and visible in history

 Alternative Path: Missing mandatory fields — display validation

errors

 Business Rules: Each equipment can have multiple contracts but

only one active

Use Case 2

 Use Case ID: DFM-RM-002

 Use Case Name: Record Equipment Repair

 Primary Actor(s): Maintenance Engineer

 Pre-conditions: Equipment must exist in system

  Post-conditions: Repair record added with classification (in-lab/on-
site)

 Main Success Scenario:

1. User selects equipment

2. Clicks "Add Repair Log"

3. Chooses type (in-lab/on-site), date, notes, personnel

4. Saves the record

 Alternative Path: Invalid date entered — show error

 Business Rules: Cannot add repair for retired equipment

Screen/UI Design
 Form-based input for contract and repair

 Tabbed view for historical entries

 File uploader component for contracts

(Wireframes will be provided in a separate attachment)

Field Level Specifications

Field Field Mandato Defaul
Data Type Value Set Comments
Label Type ry t Value

Auto-filled Lookup from

Equipmen Alphanumer
Text Box Yes from N/A Equipment
t ID ic
selection DB

Lease,
Contract Dropdow Validated
Yes String Ownership, -
Type n list
Licensing

Indicates
Logo Checkbo
No Boolean Yes/No No branding
Rights x
rights

Summary of
Quality
Text Area No String N/A - QC
Control
obligations

Contract Date Yes Date - Current Must be <=

 Effective
Date Picker Date
Date

>=
Effective Date
Yes Date - - Contract
Date Picker
Date

Must be >=
Date
End Date No Date - - Effective
Picker
Date

Positive
Value of
Text Box Yes Decimal - 0.00 numeric
Contract
only

Repair Radio In-Lab, On- Required for

Yes String -
Type Button Site repair log

Repair Date Current Not in

Yes Date -
Date Picker Date future

Technician Person
Text Box Yes String - -
Name responsible

Free text
Notes Text Area No String - -
notes

Business Rules and Dependencies

Validation / Business Data
Field Label Error Message
Rule Dependencies

Contract Must be <= "Contract Date cannot be

Effective Date
Date Effective Date after Effective Date"

Must be >= "End Date must be later

End Date Effective Date
Effective Date than Effective Date"

Equipment Must exist in

"Invalid Equipment ID" Equipment DB
ID Equipment Master

Repair Type Must be selected "Please select repair type" -

Buttons, Links, and Icons
Button Other Visibl Enabled vs
OnClick Event Navigate To
Label Event e Displayed

Add Open contract Enabled if user

- Yes -
Contract input form has role

Enabled if
Add Open repair
- Yes equipment -
Repair Log input form
exists

Validate and Enabled if all

Save - Yes -
persist data fields valid

Cancel Clear form - Yes Always enabled -

View Show past Enabled if Contract/Repair

- Yes
History entries records exist History Tab

Risk Assessment
 Data Integrity Risks: Incorrect contract dates or repair logs

o Mitigation: Strict validation and date pickers

 Access Control Risks: Unauthorized updates

o Mitigation: Role-based permissions

 Document Upload Security: Malware in uploaded contracts

o Mitigation: Antivirus scan and file size/type validation

Updated Non-Functional Requirements

 Performance: Save/load operations within 3 seconds for up to 5000
equipment entries

 Security: Contract documents encrypted at rest

 Availability: 99.5% uptime for legal-critical components

 Audit Logging: Every change to contract and repair log recorded with
user ID
  Scalability: System should support at least 50 concurrent users
entering contracts and repairs

Sub-Module Name: Approval Workflow, Alerts and Notifications,

KPI Evaluation

Overview
This document provides a detailed functional specification for three integral
sub-modules of the PCSIR ERP Design and Fabrication Management System:
Approval Workflow, Alerts and Notifications, and Automatic KPI
Calculation and Evaluation. These sub-modules collectively streamline the
internal review process, enable real-time communication, and automate
performance measurement of design and fabrication activities across various
centers of PCSIR.

Software Requirement Analysis

 Platform: PCSIR ERP Web-based System

 Database: PostgreSQL

 Backend: Node.js with Express.js

 Frontend: React.js with Tailwind CSS

 Role-based Access: Admin, Approver, Reviewer, Technical Committee

Member

 Notification Services: Email, SMS Gateway, Web Socket for in-app

notifications

 KPI Evaluation Engine: Rules Engine + Scheduled Cron Jobs

High-Level Architecture
 Microservices-based modular architecture

 Notification microservice connected via event bus (RabbitMQ)

 Approval engine integrated with BPMN workflow engine (Camunda)

 KPI engine uses business rules stored in the database, triggered via
scheduled tasks

 REST API endpoints for all front-end interactions

Sub-Module Name: Approval Workflow, Alerts and Notifications, KPI
Evaluation
Purpose/Description:

 Approval Workflow: To manage multi-tiered approvals for design

initiation, fabrication, contract finalization, and handover.

 Alerts and Notifications: To keep stakeholders informed through

real-time alerts for action items, approval status, reminders, and
escalations.

 Automatic KPI Calculation and Evaluation: To monitor the

performance of designs, fabrication units, and teams by calculating
KPIs such as turnaround time, material cost variance, rejection rate,
etc.

Use Cases
Use Case 1

 Use Case ID: DFM-AW-UC01

 Use Case Name: Initiate Design Approval Workflow

 Primary Actor(s): Design Engineer, Project Lead

 Pre-conditions: Design request form must be submitted.

 Post-conditions: Approval status set to either Approved or Rejected.

 Main Success Scenario:

1. Engineer submits the design document.

2. System triggers approval workflow.

3. Each approver reviews and takes action.

4. Final approver's decision closes the workflow.

 Alternative Path: Approver rejects, sends back with comments.

 Business Rules: Each approver has max 48 hrs to respond; automatic

escalation after timeout.
Use Case 2

 Use Case ID: DFM-NF-UC02

 Use Case Name: Send Notification

 Primary Actor(s): System

 Pre-conditions: Status update/event occurs.

 Post-conditions: Recipient receives email, SMS, and/or in-app

notification.

 Main Success Scenario:

1. System observes a status change.

2. Trigger message template based on event type.

3. Push message to relevant users.

 Alternative Path: If SMS fails, fallback to email only.

 Business Rules: High-priority alerts are shown as sticky banners.

Use Case 3

 Use Case ID: DFM-KPI-UC03

 Use Case Name: Evaluate Design KPIs

 Primary Actor(s): KPI Engine

 Pre-conditions: All design records must have end dates and status.

 Post-conditions: KPI scores stored and visualized.

 Main Success Scenario:

1. Cron job executes every 1st of the month.

2. Fetch design/fabrication data.

3. Apply business rules and score KPIs.

 Alternative Path: Partial failures logged for re-processing.

 Business Rules: Each KPI has a score formula and threshold.

Screen/UI Design
Wireframes include:
  Approval Workflow Tracker

 Notification Center Dashboard

 KPI Analytics Dashboard (Gauge, Bar, Heatmap visualizations)

Field Level Specifications

Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

Pending, Controlled by
Approval Dropdow
Yes String Approved, Pending workflow
Status n
Rejected engine

Notification Dropdow Email, SMS, Affects delivery

Yes String Email
Type n In-App channels

Computed
KPI Score Text Box No Float Calculated 0
using formula

Used for
Threshold Intege
Text Box Yes 0–100 70 performance
Limit r
evaluation

Business Rules and Dependencies

Validation/Business Error Data
Field Label
Rules Messages Dependencies

Approval Must follow workflow Invalid Depends on user

Status route Approver role

Notification Depends on user

Must be active channel Delivery Failed
Type settings

Calculated from KPI Calculation Requires complete

KPI Score
completed records Failed case data

Buttons, Links and Icons

Label OnClick Other Event Visible Enabled Navigate To
 Event

Submit for Start Approval

N/A Yes Yes
Approval workflow Tracker Page

Send Condition Notification

Notify Retry if failed Yes
notifications al History

Run KPI Execute KPI Scheduled Admin

Yes KPI Dashboard
Engine rules Monthly Only

Risk Assessment
 Risk: Delay in approvals due to manual oversight
Mitigation: Automated reminders and escalation workflows

 Risk: Notification overload and spam filtering

Mitigation: Role-based opt-in notification templates

 Risk: KPI bias due to data incompleteness

Mitigation: Pre-check for required fields before KPI job runs

Updated Non-Functional Requirements

 Performance: KPI engine must process up to 1000 records/min

 Reliability: Workflow must have 99.9% uptime

 Scalability: Notification system to handle 10,000+ daily alerts

 Usability: KPI dashboard to be mobile responsive

 Security: Role-based access control for approvals and KPI visibility

Calibration Management System
Calibration Parameters
Overview
The Calibration Parameters module of the PCSIR ERP is designed to manage
the core reference data related to calibration standards. It enables the
systematic configuration of calibration domains, calibration methods
(accredited/non-accredited), and the measurement units used in these
procedures. This foundational data supports the calibration workflows of
various departments by ensuring traceability, accuracy, and standardization
in calibration operations.

Software Requirement Analysis

 Stakeholders: Calibration Laboratory Staff, QA Officers, ERP System
Administrator

 System Users: Lab Technicians, Metrology Experts, Quality Managers

 Functional Requirements:

o Define Calibration Domains

o Define Domain-wise Calibration Methods

o Maintain list of Measurement Units

o Enforce data validation and traceability

 Non-Functional Requirements:

o System availability: 99.9% uptime

o Responsiveness: <2 seconds per operation

o Auditability: All changes must be logged

o Security: Role-based access to data

o Localization: Support for metric units only

High-Level Architecture
 Frontend: Web-based ERP User Interface (React + TailwindCSS)

 Backend: RESTful APIs (Node.js / Python Flask)

  Database: PostgreSQL (Primary), Redis (for caching)

 Authentication: JWT-based role-driven access control

 Hosting: PCSIR On-premise Cloud Infrastructure

Module Name: Calibration Parameters Management

Sub Module Name:

 Calibration Domain Definition

 Domain-wise Calibration Method Definition

 Measurement Units Definition

Purpose / Description

This sub-module allows the ERP system to maintain core reference

parameters for the calibration domain. It provides a centralized repository for
recording calibration types (e.g., Dimension, Volume, Mass), methods used
(e.g., Accredited, Traceability, Standards used), and corresponding
measurement units (e.g., Kg, Liter, Pascal). These entities ensure uniformity
across all calibration processes and reporting.

Use Cases
Use Case 1

 Use Case ID: CAL-001

 Use Case Name: Define Calibration Domain

 Primary Actor(s): QA Manager, System Admin

 Pre-conditions: User must have Admin privileges

 Post-conditions: New Calibration Domain available in master list

 Main Success Scenario:

1. User navigates to Calibration Domain Management

2. Enters Domain Name and submits

3. System stores and lists new domain

 Alternative Path:

o If domain name exists, system shows error

 Business Rules:
 o Domain name must be unique

o Cannot delete domain if in use

Use Case 2

 Use Case ID: CAL-002

 Use Case Name: Define Calibration Method by Domain

 Primary Actor(s): Lab Technician, QA Manager

 Pre-conditions: Calibration Domain must exist

 Post-conditions: Calibration method stored with traceability

 Main Success Scenario:

1. User selects a Calibration Domain

2. Enters Method details (name, accreditation, equipment)

3. System saves the method and shows in list

 Alternative Path:

o Missing mandatory fields → error displayed

 Business Rules:

o One method per domain can be marked "Accredited"

o All methods must reference a valid equipment entry

Use Case 3

 Use Case ID: CAL-003

 Use Case Name: Define Measurement Unit

 Primary Actor(s): QA Officer, System Admin

 Pre-conditions: User logged in with access rights

 Post-conditions: Unit stored and available for selection

 Main Success Scenario:

1. User adds unit name, abbreviation, and remarks

2. System validates and stores unit

 Alternative Path:
 o Duplicate unit abbreviation → error shown

 Business Rules:

o Abbreviations must be unique

o Remarks optional

Screen / UI Design
(Representative wireframes – actual screen to be developed using UI library)

1. Calibration Domain Master

o [Dropdown: List of Domains]

o [Button: Add New Domain]

o [Table: Existing Domains, Edit, Delete]

2. Calibration Method Definition

o [Dropdown: Select Domain]

o [Text: Method Name]

o [Radio: Accredited/Non-Accredited]

o [Dropdown: Reference Equipment]

o [Textarea: Traceability]

o [Textarea: Remarks]

o [Button: Save]

3. Measurement Unit Definition

o [Text: Unit Name]

o [Text: Abbreviation]

o [Textarea: Remarks]

o [Button: Save]
Field Level Specifications
Field Mandato Data Default
Field Label Value Set Comments
Type ry Type Value

Domain Unique, case-

Text Box Yes String - -
Name insensitive

Method
Text Box Yes String - - Alphanumeric
Name

Accredited, Non- Validates

Accreditatio Radio Boolea
Yes Non- Accredite based on role
n Type Button n
Accredited d access

Populated
Reference Dropdow Foreign Equipment from
Yes -
Equipment n Key Table Equipment
Master

Max 500
Traceability Textarea Yes String - -
chars

Unit Name Text Box Yes String - - e.g., Kilogram

e.g., kg, l,
Abbreviation Text Box Yes String - -
cm³, Pa

Optional note
Remarks Textarea No String - -
field

Business Rules and Dependencies

Validation / Business Data
Field Label Error Messages
Rule Dependencies

"Domain already
Domain Name Must be unique None
exists."

"Method name Domain must

Method Name Cannot be blank
required." exist

"Duplicate unit
Abbreviation Unique across all units None
abbreviation."
 Validation / Business Data
Field Label Error Messages
Rule Dependencies

Must exist in
Reference "Invalid equipment Equipment
Equipment Master
Equipment selected." Table
table

Buttons, Links, and Icons

Other Visibl Enable
Label OnClick Event Navigate To
Event e d

Stay on same
Save Store record in DB Validate Yes Yes
page

Add Open Domain Entry

- Yes Yes Inline UI Update
Domain popup/modal

Discard unsaved Return to

Cancel - Yes Yes
changes master screen

Soft-delete
Delete - Yes Yes Inline update
domain/method/unit

Risk Assessment
Risk Description Mitigation Strategy

Enforce unique constraint and

Duplicate domain or unit entries
validation

Use dropdowns from controlled

Incorrect calibration mapping
vocabularies

Implement frontend and backend

Manual data entry errors
validation

Inconsistent units usage in

Link units via foreign key enforcement
methods

Deletion of referenced
Apply deletion prevention if linked
domain/method
Updated Non-Functional Requirements
NFR
Specification
Category

Usability Responsive UI with consistent layout and auto-suggestions

Performance Record addition < 2 seconds

Availability 24/7 with downtime limited to scheduled maintenance

Security Role-based access; Admin can manage reference data only

All data creation/edit/delete operations logged with timestamp

Audit Trail
and user ID

Measurement units to follow international metric standards (SI

Localization
Units)
Quotation, Invoicing, and Payment
Overview
This module facilitates the automated generation and processing of
quotations, invoices, and payments for calibration services offered by PCSIR.
It supports both on-site and in-lab calibration service quotations, centralized
and future-scalable payment account management, system-generated
covering letters, and online/offline multi-channel payment mechanisms
including PSID generation. It is tightly integrated with the Enquiry
Management System.

Software Requirement Analysis

Requirement
Details
Area

Module Calibration Services

Sub-Modules Quotation Generation, Invoicing, Payment Processing

Actors Customer, ILO-Enquiry Officer, Admin, Finance

Enquiry Management System, Test Method Database,

Integration
Financial System, Bank Payment Gateways

Scalability Multi-account support, Payment integration extensibility

Role-based access control, encrypted payment credentials,

Security
audit logging

Output Quotation PDF, Invoice PDF, PSID, Covering Letter

High-Level Architecture
 Frontend: React.js-based ERP interface with modular UI for
quotations, invoices, and payments

 Backend: RESTful services (Node.js or Django) interfacing with

Oracle/PostgreSQL DB

 Database: Normalized schema for Enquiries, Quotations, Payments,

Test Methods, and Calibration Domains
  External Integrations: Bank API for online payments and PSID
generation

Sub-Module Name: Quotation and Payment Processing

Purpose/Description

This sub-module enables PCSIR to:

 Automatically respond to calibration-related enquiries with valid

quotations or appropriate alternative responses.

 Generate invoices based on the quotation and test methods with linked
calibration details.

 Maintain a list of approved accounts for payment collection.

 Add special statutory or procedural instructions on quotations/invoices.

 Generate PSIDs and support various online and offline payment

channels.

Use Cases
Use Case 1

 Use Case ID: QIP-001

 Use Case Name: Generate Quotation for Calibration Services

 Primary Actor(s): ILO-Enquiry Officer

 Pre-conditions: Valid enquiry exists in the system

 Post-conditions: Quotation is generated, stored, and downloadable

 Main Success Scenario:

1. User opens enquiry record

2. Selects "Generate Quotation"

3. System fetches test methods and rates

4. System adds special instructions, account details

5. Generates quotation with covering letter

 Alternative Path:

o If no calibration service available, system displays unavailability

notice
 o If more info is needed, user is prompted to schedule a meeting

 Business Rules:

o Quotation must include terms, conditions, and selected test

methods

o Quotation status should be traceable from the enquiry panel

Use Case 2

 Use Case ID: QIP-002

 Use Case Name: Generate Invoice for Calibration Services

 Primary Actor(s): ILO-Enquiry Officer

 Pre-conditions: Approved quotation exists

 Post-conditions: Invoice generated and saved

 Main Success Scenario:

1. ILO selects “Generate Invoice”

2. Selects account from the list

3. System merges bank and test rate data

4. Invoice is created and linked to the enquiry

 Alternative Path:

o If account list is empty, system prompts for admin setup

 Business Rules:

o Invoices must be generated from quotations only

o Special instructions auto-included from reference data

Use Case 3

 Use Case ID: QIP-003

 Use Case Name: Accept Multi-Channel Payment

 Primary Actor(s): Customer, Finance Officer

 Pre-conditions: Invoice is generated

  Post-conditions: Payment status updated

 Main Success Scenario:

1. Customer selects preferred payment mode (online, DD, cheque,

swipe)

2. If online, system generates PSID and redirects to bank gateway

3. Upon payment success, status updated and receipt generated

 Alternative Path:

o For offline payments, customer uploads payment proof

 Business Rules:

o PSID validity must be 24 hours unless extended manually

o Each invoice maps to one unique PSID

Screen/UI Design
(To be designed in coordination with UI/UX team, wireframe references will
be added in design phase)

Field Level Specifications

Field Mandato Data Default
Field Label Value Set Comments
Type ry Type Value

Auto-
Enquiry ID Text Box Yes String N/A Linked to EMS
Fetch

Calibration Dropdow [On-site, In- Based on

Yes String None
Type n lab] enquiry type

[Generated,
Quotation Dropdow
Yes String Draft, Draft Editable
Status n
Rejected]

Lookup from
Account Dropdow From Account Central
Yes String Admin
Number n Master Account
Settings

Special
Text Area No String Ref Data None Optional
Instructions
 Field Mandato Data Default
Field Label Value Set Comments
Type ry Type Value

Visible only
Auto-
PSID Text Box Auto String None on online
generated
selection

Payment
Payment Dropdow [Online, DD,
Yes String Online validation
Mode n PO, Cheque]
applies

Business Rules and Dependencies

Field Validation/Business Error Data
Label Rules Messages Dependencies

Account Must exist in Account "Invalid account Depends on Finance

Number Master selected." Setup

Must be generated only "PSID already Online Payment

PSID
once per invoice exists." Option only

"Invalid
Payment Must match payment Triggers PSID or doc
payment
Mode details format upload UI
method."

Buttons, Links, Icons

OnClick Other Enabled vs Navigate
Label Visible
Event Events Displayed To

Calls
Generate Quotation
quotation Auto-fill data Yes Enabled
Quotation Preview
API

Generate Calls Auto-fill

Yes Enabled Invoice Page
Invoice invoice API instructions

Generate Calls PSID Enabled on Payment

None Conditional
PSID API Online Gateway

Upload Opens file None On Offline Enabled Attachment

Payment
 OnClick Other Enabled vs Navigate
Label Visible
Event Events Displayed To

Proof uploader Modes Section

Risk Assessment
Risk Mitigation Strategy

Single account dependency Multi-account master with default fallback

Incorrect PSID generation Validation with timestamp and unique invoice ID

Embedding tax-exemption instructions from ref

Regulatory non-compliance
data

UI Complexity for Payment Conditional visibility of fields and buttons based

Modes on selection

Updated Non-Functional Requirements

NFR
Requirement
Category

Availability 99.9% uptime for payment features

Performance PSID generation within 3 seconds

Security PCI DSS-compliant payment integration

Maintainabili Admin panel for updating account numbers and special

ty instructions

Addition of new banks and payment gateways without

Scalability
code change

Full logs for every invoice and payment step with

Auditability
timestamps
Sub Module Name: Equipment Management
Overview
The Equipment Management sub-module of the PCSIR ERP Calibration
Module is designed to facilitate the seamless intake, verification,
categorization, and tracking of equipment submitted for calibration, either
through in-lab or on-site services. The sub-module ensures operational
transparency, traceability via QR code integration, streamlined data entry,
and compliance with technical procedures including exception handling for
non-functional or small-size equipment.

Software Requirement Analysis

 Support for data entry of equipment attributes

 Equipment inspection workflow with status recording

 QR/Barcode generation per equipment instance

 Conditional logic based on Calibration Type (In-Lab/On-Site)

 Small equipment tagging via reusable zip ties

 Ability to scan and attach supporting documents

 Role-based access for ILO Operators and Equipment Operators

 Seamless handoff between ILOs and Calibration staff

 Storage of calibration denomination and override capabilities

 Integration with payment validation and case initiation

High-Level Architecture
 Frontend: Web-based UI for ILO and Equipment Operators

 Backend: RESTful services for CRUD operations, QR Code generator,

case routing
  Database: Relational DB storing equipment metadata, calibration
status, QR Code mapping

 Integration: Linked with Payment, Case Management, QR Code

Services, and Calibration Tracking

Sub Module: Equipment Management

Purpose / Description

This sub-module manages the intake and verification of equipment under

calibration requests. It allows PCSIR to ensure all devices sent for calibration
are properly documented, tagged, and validated for functionality. It supports
in-lab and on-site workflows, small equipment handling, and traceable QR
code generation.

Use Cases
Use Case ID: EQM-01

Use Case Name: Record Calibration Request Equipment Primary Actor(s):

ILO Operator Pre-conditions: Payment confirmed or gratis case approved
Post-conditions: Case created and forwarded to next ILO or Equipment
Operator Main Success Scenario:

1. ILO logs in and initiates equipment entry

2. Enters calibration type, customer details, and equipment list

3. Sets or overrides calibration denomination

4. Saves and forwards to next ILO

Alternative Path:

 If no payment is made or gratis not approved, system halts entry

Business Rules:

 Default denomination set to "As Above"

 Equipment count validation

Use Case ID: EQM-02

Use Case Name: Equipment Receipt and Inspection Primary Actor(s):
Equipment Operator Pre-conditions: Equipment case received Post-
conditions: Non-functional equipment removed/quantity adjusted Main
Success Scenario:

1. Equipment Operator views equipment list

2. Inspects items and removes or updates quantities

3. Saves accepted equipment records

Alternative Path:

 For on-site calibration, Scientist performs entries

Business Rules:

 Non-functional equipment cannot proceed

 On-site calibration bypasses Equipment Operator

Use Case ID: EQM-03

Use Case Name: QR Code Generation for Equipment Primary Actor(s):

Equipment Operator Pre-conditions: Equipment accepted post-inspection
Post-conditions: QR Codes generated per equipment instance Main
Success Scenario:

1. Operator enters equipment with quantity > 1

2. System generates QR Code per unit

3. QR Codes printed for pasting or hanging

Alternative Path:

 Small items use reusable zip ties

Business Rules:

 Quantity-based QR Code creation logic

 QR Code must be unique per instance

Screen/UI Design
(Include screens separately or upon request. Example layout: Equipment
Entry, Inspection Interface, QR Code Summary)

Field Level Specifications

Field Label Field Mandato Data Value Default Comments
 Type ry Type Set Value

Determines
Calibration Dropdow On-Site,
Yes String - conditional
Type n In-Lab
flows

Calibration Dropdow Domain Lookup

Yes String -
Domain n List required

Equipment
Text Box Yes String - - -
Name

Model Text Box Yes String - - -

Make Text Box Yes String - - -

QR generated
Quantity Number Yes Integer > 0 1
per unit

Good,
Appearing Dropdow Inspection
Yes String Poor, Good
Condition n filter
Broken

Calibration As User can

Text Box Yes String -
Denomination Above override

Date
Date of Receipt Yes Date - Today Auto-default
Picker

Time
Time of Receipt Yes Time - Now Auto-default
Picker

Business Rules and Dependencies

Validation/Business Data
Field Label Error Messages
Rule Dependencies

Please select
Calibration Type Must be selected None
calibration type

Equipment Enter valid Affects QR Code

>0; Integer only
Quantity quantity generation

Calibration Override allowed but Calibration -

 denomination is
Denomination must not be blank
required

Buttons, Links, Icons

Other Visibl Enable
Label OnClick Event Navigate To
Event e d

Save & Save data and Next ILO or

- Yes Yes
Forward forward Equipment OP

Opens document
Scan Docs - Yes Yes Attachments
scanner

Generate Triggers QR
- Yes Yes QR Summary Page
QR generation

Risk Assessment
 Risk of QR Code duplication – mitigated via unique hash

 Entry errors due to bulk data – mitigated through validations and

quantity logic

 Equipment misidentification – mitigated using make, model, and

condition

 Small equipment tagging risk – addressed via reusable hang tags with
printed QR

Updated Non-Functional Requirements

 System shall generate QR Codes dynamically within 3 seconds per unit

 Scanning module must support common file formats (PDF, JPEG)

 System uptime shall be 99.9% for Equipment Management

  System shall be capable of handling 1,000+ concurrent calibration
records

 Accessibility standards must be met (WCAG 2.1 AA)

 QR Code must be scannable with PCSIR mobile app and handheld

readers

 All entries must be stored with a time-stamp and user ID for

traceability

Sub Module Name: Case Management

Overview
The Case Management Sub-Module is a critical part of PCSIR's Calibration
Management System designed to enable the smooth tracking, assignment,
processing, and closure of calibration service requests. It ensures that
calibration cases are efficiently handled from initiation to report delivery
while maintaining traceability, transparency, and timely communication with
clients.

Software Requirement Analysis

 Track and assign calibration cases among ILO Operators, Section In-
Charges, Analysts/Scientists/Engineers, and Heads of Centers.

 Automated job card and data sheet generation.

 Uploading and verification of calibration reports.

 Notification to clients via SMS at different stages.

 Final report scanning and dispatch.

 Search functionality for client identification.

 Daily report generation for ILOs.

 Record overdue and emergency status notifications.

High-level Architecture
 Frontend: Angular / React

 Backend: Node.js / ASP.NET Core

  Database: PostgreSQL / SQL Server

 Notifications: Twilio / Local SMS Gateway

 Document Management: Azure Blob / S3-compatible storage

 Authentication: Role-based access using OAuth 2.0 / JWT

Purpose/Description
The Case Management sub-module is responsible for managing the life cycle
of a calibration service request. It covers everything from the initial
assignment of the case to internal units and personnel, through report
preparation and approval, to final report delivery and client notification.

Use Cases
Use Case 1

 Use Case ID: CM-001

 Use Case Name: Assign Case to Calibration Head

 Primary Actor(s): ILO Operator

 Pre-conditions: Calibration Case is created

 Post-conditions: Case assigned to Head of Center

 Main Success Scenario: ILO Operator assigns case to Head

 Alternative Path: Assignment fails due to system issue or invalid

state

 Business Rules: Only authorized ILO Operators can perform

assignment

Use Case 2

 Use Case ID: CM-002

 Use Case Name: Section Assignment

 Primary Actor(s): Head of Center

 Pre-conditions: Case is assigned to Head of Center

 Post-conditions: Case is assigned to Section In-Charge

 Main Success Scenario: Section assignment completed

 Alternative Path: No available section; fallback to default section

  Business Rules: Section must be valid for the calibration domain

Use Case 3

 Use Case ID: CM-003

 Use Case Name: Analyst/Scientist/Engineer Case Assignment

 Primary Actor(s): Section In-Charge

 Pre-conditions: Case assigned to section

 Post-conditions: Case assigned to analyst/scientist/engineer

 Main Success Scenario: Assignment completed successfully

 Alternative Path: No available resource; notify Head

 Business Rules: Resource must be active and available

Use Case 4

 Use Case ID: CM-004

 Use Case Name: Report Upload and Case Completion

 Primary Actor(s): Analyst/Scientist/Engineer

 Pre-conditions: Calibration job done

 Post-conditions: Report uploaded, marked complete

 Main Success Scenario: Data sheet and report uploaded

 Alternative Path: Missing required data, validation fails

 Business Rules: Data sheet must be attached before marking

complete

Use Case 5

 Use Case ID: CM-005

 Use Case Name: Report Review and Final Approval

 Primary Actor(s): Section In-Charge, Head of Center

 Pre-conditions: Report uploaded

 Post-conditions: Case approved/rejected

 Main Success Scenario: Report approved and sent to print

  Alternative Path: Rejected and returned to scientist for revision

 Business Rules: Only scientist can revise report

Use Case 6

 Use Case ID: CM-006

 Use Case Name: Final Report Printing and Dispatch

 Primary Actor(s): ILO Printing Operator

 Pre-conditions: Case approved

 Post-conditions: Report printed, signed, dispatched

 Main Success Scenario: Report dispatched, SMS sent

 Alternative Path: Delay in dispatch; log issue

 Business Rules: Dispatch method must match client preference

Use Case 7

 Use Case ID: CM-007

 Use Case Name: Daily Summary Report Generation

 Primary Actor(s): ILO Operator

 Pre-conditions: Cases exist for the day

 Post-conditions: Summary report generated

 Main Success Scenario: Report includes totals and balances

 Alternative Path: No cases; generate blank report

 Business Rules: Only accessible by ILO role

Screen/UI Design
(To be provided separately as image prototypes or wireframes.)

Field Level Specifications

Field Mandato Data Value Default
Field Label Comments
Type ry Type Set Value

Text Auto- Unique per

Case No. Yes String N/A
Box generated case

Customer Name Text Yes String N/A Fetched From Enquiry

 Box

Instrument Text From Validation

Yes String N/A
Name Box Equipment required

Text From
Make No String N/A -
Box Equipment

Text From
Model No String N/A -
Box Equipment

Environmental Text Entered by

No String N/A N/A
Conditions Box Analyst

Next Calibration Date

No Date N/A N/A Optional
Date Picker

Courier Tracking Text Required if

No String N/A N/A
No. Box dispatched

Business Rules and Dependencies

Validation/Business Data
Field Label Error Messages
Rules Dependencies

"Duplicate Case Auto-

Case No. Must be unique
Number." generated

"Please enter
Environmental Required for Calibration
Temperature and None
Conditions completion
Humidity."

Next Calibration "Date must be in

Must be future date Case Date
Date future."

Courier Tracking Required if dispatch "Tracking number is Dispatch

No. method is courier required." Method

Buttons, Links, and Icons

Other Visibl
Button Label OnClick Event Enabled Navigate To
Event e
Assign to Assigns case to
- Yes Yes Current page
Section selected section

Opens file dialog,

Upload Report - Yes Yes N/A
saves report

Print Final
Opens print dialog - Yes Yes Print layout
Report

Dispatch Marks case as Condition

- Yes N/A
Report dispatched al

Daily
Generate Generates summary
- Yes Yes Summary
Daily Report report
Report

Risk Assessment
 Incorrect Assignment: Role-based validations must be in place.

 SMS Failure: Backup queue and retry logic required.

 Data Loss: Auto-save during report drafting, document versioning.

 Unauthorized Amendments: Restrict editing access to original

reporter.

Updated Non-Functional Requirements

 Scalability: System must support 10,000+ concurrent cases

 Availability: 99.9% uptime required for business hours

 Security: Role-based access control, encrypted report storage

 Performance: Each screen should load under 2 seconds

 Auditability: Full case workflow must be auditable with logs

 SMS Gateway Integration: Auto-trigger SMS events with failover

support
Sub Module Name: Return of Equipment

Overview
The Return of Equipment sub-module is a critical part of the Calibration
Management System. It ensures that all post-calibration deliverables—
including calibrated instruments, tested/remaining samples—are returned to
the customer in a traceable, auditable, and efficient manner. This includes
automated generation of delivery challans, gate passes, and tracking of On-
Site service activities.

Software Requirement Analysis

This sub-module must support the following requirements:

 Generate delivery challans for all post-calibration returns

(instruments/samples).

 Generate gate passes linked with delivered items.

 Log On-Site calibration/testing activities with details like site address,

visiting staff, time of visit, and duration.

 Integrate with Case Management, Inventory, and SMS Notification

Modules.

 Print, archive, and retrieve past gate passes and delivery challans.

High-level Architecture
 Frontend: Angular/React Web Interface

 Backend: RESTful APIs using .NET Core or Java Spring Boot

 Database: PostgreSQL or MS SQL Server

 Integration: ERP Core Services, SMS Gateway, QR Code Engine, User

Authentication (OIDC/LDAP)
Purpose/Description
The Return of Equipment sub-module aims to streamline the return logistics
process for PCSIR calibration services. It automates the generation of
delivery documentation and records On-Site testing activities, ensuring
traceability and compliance with SOPs.

Use Cases
Use Case 1

 Use Case ID: REQ-001

 Use Case Name: Generate Delivery Challan

 Primary Actor(s): ILO Operator

 Pre-conditions: Calibration/Test case marked complete

 Post-conditions: Delivery challan generated and archived

 Main Success Scenario: ILO Operator opens the completed case and
clicks “Generate Delivery Challan.” The system auto-fills customer and
item info. Challan is saved and printable.

 Alternative Path: Manual entry of missing data; alert user if

instrument/sample ID not linked.

 Business Rules: Only one challan per return allowed. Must be linked
to a completed case.

Use Case 2

 Use Case ID: REQ-002

 Use Case Name: Generate Gate Pass

 Primary Actor(s): Security Operator, ILO Operator

 Pre-conditions: Delivery Challan generated

 Post-conditions: Gate pass is printed with QR code

  Main Success Scenario: After issuing the delivery challan, user clicks
“Generate Gate Pass.” Gate pass with QR and case info is produced.

 Alternative Path: If delivery challan is missing, gate pass cannot be

generated (error shown).

 Business Rules: Gate pass linked one-to-one with delivery challan.

Use Case 3

 Use Case ID: REQ-003

 Use Case Name: Log On-Site Calibration

 Primary Actor(s): Engineer/Scientist, Section In Charge

 Pre-conditions: On-Site calibration request approved

 Post-conditions: Site visit is logged and reportable

 Main Success Scenario: Scientist/Engineer opens “Log On-Site Visit”

form, fills site info, visit date, attendees, and duration.

 Alternative Path: Incomplete form submission triggers validation

errors.

 Business Rules: Multiple visits can be logged per case; each must
include at least location, date, and engineer name.

Screen/UI Design
 Generate Delivery Challan Screen

 Generate Gate Pass Screen

 Log On-Site Visit Screen

(Note: UI Wireframes to be attached separately or rendered using UI

prototype tools)

Field Level Specifications

Field Field Mandato Defaul
Data Type Value Set Comments
Label Type ry t Value
 Lookup from
Case Alphanumer Auto-
Text Box Yes - Case
Number ic generated
System

Customer
Text Box Yes String - - Pre-filled
Name

From
Equipment
Text Area Yes String - - Calibration
Description
Job Card

[Courier,
Delivery Dropdow Required for
Yes String Handed -
Type n dispatch
Over]

Gate Pass Auto Auto-

Yes String - Unique
Number Field generated

Mandatory
On-Site
Text Box Yes String - - for On-Site
Location
logs

Validation:
Date of Date Current
Yes Date - not future
Visit Picker Date
date

Dropdow [Users Logged-

Visited By Yes String -
n List] in User

Number
Duration
Text Box Yes Numeric - - between 0.5
(Hours)
to 24

Business Rules and Dependencies

Data
Field Label Validation/Business Rules Error Messages
Dependencies

Case Must exist and be in "Invalid or Depends on Case

Number Completed state incomplete case." Sub-Module

Gate Pass "Gate Pass already Auto-generated by

Must be unique
Number exists." system
 Must be a decimal "Invalid duration.
Duration None
between 0.5 and 24 hours Must be 0.5–24."

Date of "Future dates are Depends on

Must not be in future
Visit not allowed." system date

Buttons, Links, and Icons

Button/Link/Icon Other Visibl Enabled vs
OnClick Event Navigate To
Label Event e Displayed

Challan
Generate Save & Preview Enabled when
- Yes Preview
Challan Challan PDF case done
Page

Generate Gate Save & Preview Enabled if Gate Pass

- Yes
Pass Gate Pass Challan exists PDF Page

Save site visit

Always
Log Visit record to case - Yes -
enabled
log

Risk Assessment
Impact
Risk Description Mitigation Strategy
Level

Missing or duplicate delivery Validation + auto-

High
records numbering

Unauthorized gate pass Role-based access

Medium
generation control

Failure to log on-site visits Mandatory fields + audit

Medium
correctly logs

Updated Non-Functional Requirements

 Security: All actions secured by Role-Based Access Control (RBAC)

 Availability: 99.5% uptime to support return/delivery processes

  Performance: System must generate challan/gate pass within 3
seconds

 Audit Trail: All logs, returns, visits must be archived with timestamps

 SMS Integration: Notifications on challan issuance and site visit

logging

 Usability: Simple forms with tooltips, mandatory validations, and

auto-fill

Sub Module Name: Special Case Handling and Confidential

Calibration Workflows

Overview
The "Special Cases" sub-module is a critical component of the Calibration
Management System (CMS) under the PCSIR ERP. It is designed to handle
unique calibration scenarios such as internal PCSIR customer cases, overdue
case identification, gratis-based calibration, confidential calibrations, and
calibration of calibration equipment (e.g., by NPSL). This sub-module ensures
comprehensive traceability, transparency, and confidentiality, offering a
highly specialized yet integrable solution within the overall CMS.

Software Requirement Analysis

 The system must differentiate internal PCSIR customers and support
internal billing/logging workflows.

 Case tracking logic to detect and flag overdue calibration jobs with
override capability based on user roles.

 Enable per-case status drill-down of assigned scientists/engineers and

remaining activities.

 System flags and logic to handle gratis-based cases where billing is

bypassed.

 System-level confidentiality tagging must restrict report access and

visibility to predefined roles.
  Management of NPSL-based calibration data for calibration instruments
used by PCSIR.

High-Level Architecture
1. User Interface Layer: Role-based dynamic forms and dashboards.

2. Application Layer: Business rule engine, workflow management

engine, confidentiality flagging.

3. Database Layer: Special case repository, user audit logs, overdue

flags, instrument traceability.

4. Notification Layer: Alerts/SMS/email integrations.

5. Security Layer: Role-based access control, audit trail, encryption of

confidential data.

Purpose/Description
The purpose of this sub-module is to manage calibration workflows that
deviate from regular procedures due to special conditions such as internal
PCSIR transactions, gratis arrangements, confidentiality agreements,
overdue handling, and traceability of in-use calibration instruments. It
strengthens the operational transparency and accountability for special case
management in the Calibration Division.

Use Cases
Use Case ID: SC-001

Use Case Name: Internal Customer Calibration Case

Primary Actor(s): ILO Operator, Head of Lab
Pre-conditions: Internal lab/unit initiates a calibration case
Post-conditions: Case created under internal customer workflow
Main Success Scenario: ILO selects "Internal Customer" from the customer
type dropdown. System adjusts financial workflow and tags case accordingly.
Alternative Path: If external customer is mistakenly selected, validation
triggers correction.
Business Rules: Case must bypass external quotation/invoicing stages.

Use Case ID: SC-002

Use Case Name: Overdue Case Flagging and Tracking

Primary Actor(s): ILO Operator, Section Incharge, Center Head
Pre-conditions: Calibration deadline is defined at case initiation
Post-conditions: Overdue tag is visible with escalation prompts
Main Success Scenario: System calculates calibration time elapsed. When
default or overridden threshold exceeded, an overdue flag appears.
Alternative Path: Deadline override applied by authorized user during case
sheet preparation
Business Rules: Override allowed only to designated roles.

Use Case ID: SC-003

Use Case Name: Gratis Calibration Handling

Primary Actor(s): ILO, Finance Admin
Pre-conditions: Customer type marked as "Gratis Eligible"
Post-conditions: No invoice/quotation generated
Main Success Scenario: System logs zero-value quotation and bypasses
financial module
Alternative Path: If billing attempt is made, error is shown
Business Rules: Only specific customer types (e.g., Courts) can be tagged
as gratis.

Use Case ID: SC-004

Use Case Name: Confidential Case Handling

Primary Actor(s): ILO Operator, Lab Director
Pre-conditions: Case marked as confidential at initiation
Post-conditions: Report visible only to superior roles, restricted printing
access
Main Success Scenario: Confidentiality flag ensures report access/print
only via approved users
Alternative Path: If accessed by unauthorized user, access denied log is
triggered
Business Rules: Confidential flag is immutable after submission.

Use Case ID: SC-005

Use Case Name: Calibration of Calibration Equipment

Primary Actor(s): ILO, NPSL Liaison Officer
Pre-conditions: PCSIR-owned instrument selected for calibration
Post-conditions: Data stored with NPSL references and validity
Main Success Scenario: ILO records equipment, vendor (NPSL), validity
period, and tracking code
Alternative Path: None
Business Rules: Can only be created for internal PCSIR instruments.
Screen/UI Design
(Wireframes to be attached separately or designed via front-end prototyping
tools)

 Internal Customer Form

 Overdue Case Dashboard Widget

 Gratis Flag Toggle and Confirmation Modal

 Confidentiality Checkbox with Access Role Matrix

 Calibration Instrument Validation Tracker

Field-Level Specifications
Field Mandato Data Default
Field Label Value Set Comments
Type ry Type Value

Enables
Customer Dropdow Internal,
Yes String External internal
Type n External
workflow

Controls
Confidential Checkbo TRUE/
No Boolean FALSE access and
Flag x FALSE
print rights

Gratis Dropdow Court, Govt Zero-billing

Yes String NULL
Eligibility n Agency enforcement

Overdue Only editable

TimeSpa
Duration Text Box No - - at case
n
Override initiation

Calibration Auto- For tracking

Reference Text Box Yes String - generate calibration
No d equipment

Required for
NPSL
Date internal
Calibration Yes Date - -
Picker calibration
Date
validation

Business Rules and Dependencies

Field Label Validation/Business Rules Error Messages Data
 Dependencies

Must be Internal to Enquiry,

"Invalid Customer
Customer Type initiate internal customer Financial
Type"
flow Modules

Confidential Cannot be unset once "Confidential status Access Control

Flag marked cannot be revoked" List

Only allowed for

Gratis "Customer not Customer
registered Govt/Court
Eligibility eligible for Gratis" Master Data
entities

Overdue
Only editable at case "Unauthorized
Duration Role Table
creation by roles Override Attempt"
Override

NPSL
Required if equipment is "Calibration Date Equipment
Calibration
internal PCSIR asset Missing" Registry
Date

Buttons, Links and Icons

Other Visibl
Label OnClick Event Enabled Navigate To
Event e

Mark Apply flag, restrict

- Yes Yes -
Confidential visibility

Override Enable Time Entry Condition

- Yes -
Deadline Popup (role-based) al

Submit Gratis Submit case with Billing/Accounting

- Yes Yes
Case billing bypass Module

NPSL
Open calibration Calibration
Calibration - Yes Yes
tracking modal Equipment Tab
Log

Risk Assessment
 Data Breach (High): Confidential cases may be exposed if access
control is not strictly enforced. Ensure audit trails and encryption.
  Incorrect Classification (Medium): Internal or gratis customer
tagging errors may lead to wrong workflows. Add dropdown validations
and mandatory confirmations.

 Overdue Threshold Misuse (Low): Only authorized users should be

allowed to override calibration deadlines.

Updated Non-Functional Requirements

 Access Control: Multi-level role-based access for confidential cases.

 Auditability: Logging of who accessed/attempted to access

confidential or internal data.

 SMS/Email Notification: Configurable alerts for overdue status,

internal case submissions.

 Performance: Overdue tracking and confidential flags should not

delay normal case processing.

 Availability: Sub-module must remain operational during calibration

data integration windows.
Student Supervision and Internship Management System
Student Supervision

Overview
The Student Supervision and Internship Management System (SSIMS)
is a key module within the PCSIR ERP suite designed to digitalize and
streamline the entire lifecycle of supervising students at PCSIR centers. This
system maintains metadata about universities, degrees, disciplines, and
facilitates the end-to-end workflow for recording supervision requests,
verifying approvals at multiple levels (Scientist → Head of Center → Director
P&D → DG Complex), managing student information, monitoring KPIs, and
generating institutional progress reports. Additionally, the module supports
backward data entry for legacy supervised students and includes advanced
wildcard search functionality.

Software Requirement Analysis

Functional Requirements:

 University/Institute Master Registry

 Degree Type Management (Bachelor’s, Master’s, PhD., etc.)

 Research Discipline Registry

 Student Supervision Workflow

 Student Detail Entry and Document Upload

  Multi-tiered Approval Workflow

 KPI Integration

 Consolidated Progress Report Generation

 Legacy Case Entry

 Wildcard Search Feature

Non-Functional Requirements:

 Role-based access control

 Document upload size < 5MB per file

 Data encryption for personal information (e.g., CNIC)

 Scalable database for historical entries

 99.5% uptime availability

High-level Architecture
 Frontend: React.js with Role-based Access Views

 Backend: .NET Core Web API

 Database: SQL Server 2019

 Storage: Azure Blob Storage for document uploads

 Authentication: PCSIR Single Sign-On (SSO)

 Security: TLS 1.3 encryption, CNIC masking

 KPI System Integration: REST-based integration with KPI Module

Sub-Module: University, Degree, and Discipline Master Data

Purpose/Description

This sub-module allows Admin users to create and maintain records of:

 Universities/Institutes: Includes city and remarks.

 Degrees: Bachelor’s, Master’s, PhD., Post Doctorate.

 Disciplines: Fields of research for supervision.

Sub-Module: Student Supervision Management

Purpose/Description
Facilitates PCSIR scientists/engineers in entering, submitting, and tracking
supervision requests. The request undergoes an approval workflow, after
which student details are added and KPI points are updated. The module
enables the generation of supervision progress reports and allows legacy
data entry.

Use Cases
Use Case 1

 Use Case ID: SSIMS-001

 Use Case Name: Initiate Supervision Request

 Primary Actor(s): Scientist/Engineer

 Pre-conditions: University, Degree, and Discipline must be pre-

created

 Post-conditions: Supervision request submitted for HoC approval

 Main Success Scenario:

1. Scientist logs in and opens “Initiate Supervision”

2. Fills supervision form: letter ref, date, university, degree, etc.

3. Uploads scanned letter

4. Clicks “Submit for Approval”

 Alternative Path:

o If incomplete, shows validation errors

 Business Rules:

o Duplicate letter reference not allowed

o Upload only PDF or JPG (max 5MB)

Use Case 2

 Use Case ID: SSIMS-002

  Use Case Name: Approve/Reject Supervision by HoC

 Primary Actor(s): Head of Center

 Pre-conditions: Supervision request submitted by scientist

 Post-conditions: Moves to Director P&D or back to initiator

 Main Success Scenario:

1. HoC logs in and reviews submission

2. Chooses approve, reject, or object

3. If objected, adds comments and sends back

4. If approved and part of lab complex, forwards to Director P&D

 Alternative Path:

o If already rejected, disables further actions

 Business Rules:

o Cannot approve without verifying letter and research topic

Use Case 3

 Use Case ID: SSIMS-003

 Use Case Name: Final Approval by Director P&D

 Primary Actor(s): Director P&D / OIC Training

 Pre-conditions: HoC approval completed

 Post-conditions: Supervision authenticated, KPIs updated

 Main Success Scenario:

1. Director logs in, reviews info and scanned documents

2. Approves the supervision

3. System authenticates and updates KPI dashboard

 Alternative Path:

o If objected, sent to HoC for resolution

 Business Rules:

o Approval date = system timestamp

 o No modification post-approval

Use Case 4

 Use Case ID: SSIMS-004

 Use Case Name: Add Student Details

 Primary Actor(s): Scientist/Engineer

 Pre-conditions: Supervision is finally approved

 Post-conditions: Student record created

 Main Success Scenario:

1. Opens approved supervision record

2. Fills student form (name, CNIC, picture, address)

3. Uploads CNIC or Form-B

4. Clicks “Save Student”

 Alternative Path:

o CNIC validation fails, shows error

 Business Rules:

o CNIC should be unique and masked in display

Use Case 5

 Use Case ID: SSIMS-005

 Use Case Name: Search Supervised Students

 Primary Actor(s): Scientist, Admin, DG Complex

 Pre-conditions: At least one student record available

 Post-conditions: Search results shown

 Main Success Scenario:

1. Opens Search panel

2. Enters wildcard keywords like Ahmed, PhD, etc.

3. Clicks Search

 Business Rules:
 o Wildcard search supports *, % as tokens

o Date range filter must have both start and end dates

Screen/UI Design
(Wireframes can be provided or referenced separately—here are screen
names)

 University/Degree/Discipline Master Setup

 Supervision Request Entry Form

 Student Details Entry Form

 Approval Dashboard (HoC/Director)

 Supervision Search & KPI Report

Field Level Specifications

Field Mandato Data Default
Field Label Value Set Comments
Type ry Type Value

Letter
Unique,
Reference Text Box Yes String N/A N/A
alphanumeric
Number

Date Cannot be in
Letter Date Yes Date N/A Today
Picker future

Lookup from
University Dropdow Pre-loaded
Yes String N/A University
Name n from master
master

Bachelor’s,
Degree Dropdow Lookup from
Yes String Master’s, N/A
Name n Degree master
PhD., etc.

Discipline Dropdow Pre-loaded

Yes String N/A
Name n from master

Supervisor Text Box Yes String N/A N/A Auto-filled if

 Field Mandato Data Default
Field Label Value Set Comments
Type ry Type Value

Name logged-in user

Research Max 500

Text Area Yes String N/A N/A
Topic characters

Co-
Supervisor Text Box No String N/A N/A Optional
Name

Scanned File JPG, PNG,

Yes File N/A Max size 5MB
Letter Upload PDF

Business Rules and Dependencies

Validation/Business Data
Field Label Error Messages
Rule Dependencies

CNIC Must be 13-digit

“Invalid CNIC Format” None
Number numeric only

Cannot be after “Letter date cannot

Letter Date None
current date be in future”

Discipline Must exist in

Must be selected “Discipline required”
Name master

University Must be selected from “Select a valid From University

Name list University” master

Buttons, Links, and Icons

Button/Link Other Enable
OnClick Event Visible Navigate To
Label Events d

Submit for Validate → Save Supervisor

N/A Yes Yes
Approval → Submit Dashboard

Role- Next Approval

Approve Approves record N/A Yes
based Level
Button/Link Other Enable
OnClick Event Visible Navigate To
Label Events d

Moves to rejected Role-

Reject N/A Yes N/A
list based

Add remarks → Role-

Object N/A Yes N/A
Return Back based

Saves student
Save Student N/A Yes Yes Student List
record

Risk Assessment
Impac
Risk Mitigation Strategy
t

Incomplete master Ensure master setup is part of pre-launch

High
data phase

CNIC data privacy High Data masking and encryption protocols

Document upload Mediu Validate format, size, and enforce retry

errors m logic

Mediu
KPI sync failure Async logging with retry policy
m

Updated Non-Functional Requirements

 Scalability: System should support 10,000+ supervision records

 Security: AES-256 encryption for documents and personal data

 Accessibility: WCAG 2.1 Level AA compliance

 Performance: Response time < 3 seconds for 90% of requests

 Audit Trail: Track all approval actions with timestamps

Internship Management – Student Supervision & Internship
Approval Workflow
Overview
The Internship Management System under the PCSIR ERP facilitates
structured management of student internship cases including initiation,
supervision approval, progress tracking, certificate issuance, and KPI
integration. It digitizes the approval workflows between scientists, Heads of
Centers (HoC), and Director P&D/OIC Training, providing real-time visibility,
data archiving, and search/reporting facilities.

Software Requirement Analysis

Requiremen
Description
t

Platform Web-based ERP System

Access Role-based access: OIC Training, HoC, Section In Charge,

Control Director P&D, DG PCSIR

Uploads Image/PDF (Internship Letter, CNIC/Form-B)

Notifications System alerts for deadlines and approvals

Reporting Progress Reports and Auto-generated Internship Certificates

Search
Wildcard Search on Internship Metadata
Features

KPI
Automatic update of supervision and internship KPIs
Integration

High-level Architecture
 Frontend: ReactJS-based web interface

 Backend: Node.js/Express API layer

 Database: PostgreSQL or Oracle DB

 File Storage: Secure Blob storage for scanned documents

 Authentication: Role-based user login with RBAC policies

  KPI Engine: Internal service for real-time KPI updates

 Reporting: Auto-generated PDF reports and certificates

Sub-Module: Internship Management

Purpose/Description:

The Internship Management Sub-Module digitizes the lifecycle of internship

cases — from submission of reference letters to student onboarding, center
assignment, progress monitoring, approval routing, KPI scoring, and
certificate generation. It provides robust support for handling both current
and historical internships with consolidated visibility and analytics for
supervisory authorities.

Use Cases
Use Case 1:

 Use Case ID: INT-01

 Use Case Name: Add Internship Request

 Primary Actor(s): Director P&D / OIC Training

 Pre-conditions: Valid login with appropriate role

 Post-conditions: Internship request saved in pending status

 Main Success Scenario:

1. User logs in

2. Navigates to Internship > New Entry

3. Fills all internship metadata

4. Uploads reference letter

5. Clicks “Submit”

 Alternative Path:

o If any required field is missing, show error

 Business Rules:

o CNIC must be valid format

o Letter date must not be future dated

Use Case 2:

 Use Case ID: INT-02

 Use Case Name: Student Onboarding

 Primary Actor(s): Director P&D / OIC Training

 Pre-conditions: Internship request must be approved

 Post-conditions: Student profile is saved against internship record

 Main Success Scenario:

1. Internship request is approved

2. Student details are filled

3. CNIC or Form-B is uploaded

4. Record is saved

 Alternative Path:

o If CNIC is already present, show duplication warning

 Business Rules:

o Entry date must be equal or greater than approval date

Use Case 3:

 Use Case ID: INT-03

 Use Case Name: Internship Routing to Head of Center

 Primary Actor(s): OIC Training

 Pre-conditions: Student onboarding complete

 Post-conditions: Internship routed to HoC

 Main Success Scenario:

1. OIC clicks “Route to Center”

2. HoC is notified

 Alternative Path:

o If student info incomplete, block routing

  Business Rules:

o Only after student onboarding can routing happen

Use Case 4:

 Use Case ID: INT-04

 Use Case Name: Internship Completion & Certificate Generation

 Primary Actor(s): Section In Charge, HoC, Director P&D

 Pre-conditions: Internship in progress

 Post-conditions: Completion status updated, certificate issued

 Main Success Scenario:

1. Section In Charge enters start/end date

2. Certificate request initiated

3. HoC and P&D approve

4. Certificate is printed and KPIs updated

 Alternative Path:

o Case rejected, moved to rejected list

 Business Rules:

o Internship end date cannot precede start date

o Certificate generated only after final approval

Screen/UI Design
(To be added as wireframe in implementation phase – typically includes:
Internship Form, Student Entry, Approval Dashboard, KPI Panel, Certificate
Generator)

Field Level Specifications

Field Mandato Data Defaul
Field Label Value Set Comments
Type ry Type t Value

Letter Reference Alphanumeri

Textbox Yes String — —
No. c

Letter Date Date Yes Date — Current Not future-

 Field Mandato Data Defaul
Field Label Value Set Comments
Type ry Type t Value

Picker Date dated

Dropdow Predefined
University Name Yes String — Lookup
n List

Bachelors,
Dropdow
Degree Name Yes String Masters, — Lookup
n
etc.

Discipline/ Dropdow Predefined

Yes String — Lookup
Subject n List

Numeric
Semester Textbox Yes String 1–10 —
Mask

Unique
Enrollment No. Textbox Yes String — —
format

Alphabetic
Student Name Textbox Yes String — —
only

CNIC Format
Student CNIC Textbox Yes String — —
Mask

Date
Start Date Yes Date — — —
Picker

Date Must be ≥
End Date Yes Date — —
Picker Start Date

Business Rules and Dependencies

Error Data
Field Label Validation/Business Rule
Message Dependencies

CNIC Must match format 99999-

Invalid CNIC None
Number 9999999-9

Start Date Cannot be later than End Date Date Conflict End Date

Degree Must match list Invalid None

 Error Data
Field Label Validation/Business Rule
Message Dependencies

Name Degree

Invalid
Semester 1 to 10 only None
Semester

Buttons, Links, and Icons

OnClick Other
Label Visible Enabled Navigate To
Event Events

Save request
Submit None Always Enabled —
to DB

Update Notify
Condition
Approve status to next Conditional Dashboard
al
Approved approver

Create
Generate Trigger KPI Post Final Condition /certificate/
internship
Certificate update Approval al preview
certificate

Execute
/internship/
Search wildcard Filter data Always Enabled
search
search

Risk Assessment
Probabili Impac
Risk Mitigation
ty t

Incomplete Approval Workflow validation before

Medium High
Workflows routing

Mediu Use format mask and duplicate

Invalid CNIC Entries Medium
m check

Delayed Certificate
Low High Auto-notifications to approvers
Generation

KPI Misalignment Medium High Sync KPI engine with final

 Probabili Impac
Risk Mitigation
ty t

approval

Updated Non-Functional Requirements

 Performance: KPI calculation and report generation must execute
within 5 seconds

 Security: CNIC data and images must be encrypted during storage

 Usability: Interface must support wildcard searches with partial

entries

 Audit Logging: Every action (submit, approve, generate) is audit-

tracked

 Availability: 99.5% uptime with redundancy for reporting module

 Scalability: Capable of storing >50,000 internship records annually

Training Management System
Sub Module: Training Initiation with Visits/Meetings, Fields of
Studies, Industry Type, and Multi-Channel Payment Methods
Overview
This document defines the functional specifications for two critical sub-
modules of the PCSIR ERP Training Management System: Training Initiation
with Visits/Meetings, Fields of Studies, Industry Type, and Multi-
Channel Payment Methods. These sub-modules support the automation
and digital governance of training requests, engagement workflows, and
payment management, thereby enhancing transparency, traceability, and
operational efficiency.

Software Requirement Analysis

 Stakeholders: PCSIR Training Coordinators, Center Heads, Finance
Department, Trainers, Trainees

 Business Requirements:

o Capture detailed training initiation data.

o Categorize trainings by Field of Study and Industry Type.

o Log pre-training visits/meetings.

o Accept payments via multiple channels.

 Technical Requirements:

o Integration with payment gateways and banks.

o Secure data handling.

o Dynamic dropdowns based on master data tables.

o Multi-tenant architecture for different PCSIR centers.

High-level Architecture
 Frontend: Angular + Tailwind UI

 Backend: ASP.NET Core / Node.js REST APIs

 Database: SQL Server

  Authentication: OAuth2 + PCSIR SSO

 Integration: 1Link (PSID), Online Card Payment API, Swipe Machines,

Payment Reconciliation APIs

Sub Module Name 1: Training Initiation with Visits/Meetings, Fields of Studies,

Industry Type
Purpose / Description

This sub-module allows PCSIR officials to initiate and document training

cases, capture key metadata (industry type, field of study, training type),
and log pre-training site visits or meetings with stakeholders.

Use Cases
Use Case ID: TRN-INIT-01

Use Case Name: Create New Training Request Primary Actor(s): Training
Officer Pre-conditions: User must be authenticated; Master data tables
must be populated. Post-conditions: A new training case is created with
status "Draft" or "Pending Review". Main Success Scenario:

1. User clicks on "New Training Case".

2. Fills training metadata.

3. Logs visits/meetings.

4. Saves the case.

Alternative Path:

 If visit date is not entered, system flags a warning but allows

proceeding.

Business Rules:

 Visit date cannot be in the future.

 Only predefined Fields of Study and Industry Types can be selected.

Sub Module Name 2: Multi-Channel Payment Methods

Purpose / Description

This sub-module manages payment collection and logging from various

channels including online payments (e.g. 1Link PSID), swipe card terminals,
and traditional banking receipts.
Use Case ID: TRN-PAY-01

Use Case Name: Receive Training Payment Primary Actor(s): Accounts

Officer, Customer Pre-conditions: Valid Training Case must exist. Post-
conditions: Payment is logged, receipt is generated. Main Success
Scenario:

1. Customer selects preferred payment method.

2. System redirects to bank/PSID portal.

3. Payment confirmation is logged.

Alternative Path:

 For offline payment, user uploads scanned receipt.

Business Rules:

 PSID must be unique.

 Amount must match system-generated invoice.

Screen/UI Design
(To be provided later – suggest wireframes in Figma/Whimsical)

Field Level Specifications

For Training Initiation:

Field Mandato Data Default

Field Label Value Set Comments
Type ry Type Value

Training Title Text Box Yes String N/A None 255 char max

[Chemistry,
Field of Dropdow Lookup from
Yes String Physics, IT, None
Study n master table
etc.]

Industry Dropdow [Textile, Lookup from

Yes String None
Type n Pharma, etc.] industry DB

Visit/Meeting Date Must be <=

No Date N/A None
Date Picker today
For Payment:

Field Mandator Data Default

Field Label Value Set Comments
Type y Type Value

[Online,
Payment Dropdow Triggers
Yes String Swipe, Bank None
Mode n conditional logic
Receipt]

Payment
Alphanumeric,
Reference Text Box Yes String N/A None
20 char max
No.

Payment Date Current Must be <=

Yes Date N/A
Date Picker Date today

Business Rules and Dependencies

Validation/ Business Data
Field Label Error Messages
Rules Dependencies

Field of Must exist in master "Invalid Field of Dependent on

Study list Study" center

Payment Must match backend "Invalid Payment

Controls UI fields
Mode enum Mode"

Must be unique and Generated by

PSID "Duplicate PSID"
active system

Buttons, Links and Icons

OnClick Other Visibl Enabled vs
Label Navigate To
Event Event e Displayed

Save Saves draft

None Yes Enabled always N/A
Training case

Generate Creates new Enabled if /payments/

None Yes
PSID PSID invoice exists generate

Upload Opens file OnChang Enabled only for /payments/

Yes
Receipt dialog e offline upload
Risk Assessment
 Risk: Payment failures from bank APIs

o Mitigation: Retry logic + payment reconciliation

 Risk: Wrong categorization of training

o Mitigation: Field validations + dropdown dependency rules

 Risk: Duplicate PSID or Payment Ref No.

o Mitigation: Unique constraints and validation rules

Updated Non-Functional Requirements

 Security: PCI DSS compliance for payments

 Scalability: Able to handle 10,000 concurrent payment transactions

 Performance: UI operations must not exceed 2 seconds of load time

 Reliability: Payment log must have 99.9% uptime

 Auditing: All payment actions must be audit logged

 Localization: Support Urdu and English for user entry fields

Sub Module: Case Management, Trainer Information, and Training
Workflows

Overview
This document defines the functional specifications for the Case
Management, Trainer Information, and Training Workflows sub-modules
within the PCSIR ERP Training Management System. These functionalities
support structured assignment of training cases, management of training
logistics, assignment of trainers, monitoring deadlines and overdue statuses,
and implementation of automated workflow processing.

Software Requirement Analysis

The system should support:

 Defining and assigning primary and secondary laboratories for training

cases.

 Setting deadlines, automatic tracking of overdue cases.

 Capturing and managing trainer profiles and credentials.

 Execution of training workflows, including approvals, assignments,

scheduling, and reporting.

 Integration with alerts/notifications and dashboard components.

High-level Architecture
 Frontend: Web-based user interface (Angular/React)

 Backend: RESTful API using Node.js/Java/.NET

 Database: PostgreSQL or Oracle DB

 Authentication: LDAP/SSO integration

 Notification: SMS/Email Gateway integration

Sub Module Name: Case Management, Trainer Information, Training

Workflows
Purpose/Description

This sub-module facilitates the tracking and management of training cases

with support for lab designation (Primary/Secondary), deadlines, overdue
status tracking, and integrated workflows for trainer assignments, approvals,
scheduling, and monitoring.
Use Cases
Use Case ID: TMS-CM-001

Use Case Name: Define Primary and Secondary Labs Primary Actor(s):
Training Coordinator, Lab Manager Pre-conditions: Training case must be
created and approved. Post-conditions: Primary and secondary labs
assigned to the training case. Main Success Scenario: Coordinator selects
labs; the system validates capacity and assigns roles. Alternative Path: If
lab is unavailable or not capable, system prompts error. Business Rules:
Only authorized labs may be selected; labs must be within the same region
unless overridden by admin.

Use Case ID: TMS-CM-002

Use Case Name: Manage Deadlines and Overdue Status Primary Actor(s):
System Scheduler, Training Coordinator Pre-conditions: Case must have
scheduled date and assigned lab. Post-conditions: Deadline monitored;
overdue flag is auto-assigned. Main Success Scenario: System monitors
deadline and updates dashboard flags. Alternative Path: Deadline
manually extended by authorized personnel. Business Rules: Overdue flag
raised 24 hours after missed deadline unless paused.

Use Case ID: TMS-TI-001

Use Case Name: Trainer Information Management Primary Actor(s):

Training Administrator Pre-conditions: Trainer must be registered in ERP.
Post-conditions: Trainer profile created/updated with domain and
availability. Main Success Scenario: Admin inputs data, system validates
and stores. Alternative Path: Invalid credentials trigger an alert. Business
Rules: Trainers must be validated by HR before being assigned.

Use Case ID: TMS-WF-001

Use Case Name: Training Workflow Execution Primary Actor(s):

Coordinator, Trainer, Admin Pre-conditions: Case, labs, and trainers must
be defined. Post-conditions: Training case proceeds through predefined
stages. Main Success Scenario: Training progresses from initiation to
completion as per rules. Alternative Path: Workflow halted if approval or
resource is missing. Business Rules: All stages must be completed in
sequence unless marked parallel.

Screen/UI Design
(Wireframes to be attached in UI mockup tool or provided via prototyping
system)

Field Level Specifications

Field Mandato Data Value Default
Field Label Comments
Type ry Type Set Value

Dropdow [Lab Lookup from

Primary Lab Yes String None
n List] Registered Labs

Secondary Dropdow [Lab

No String None Optional lookup
Lab n List]

Deadline Date Current Must be >=

Yes Date -
Date Picker +7 today

Overdue Calculated by
Label No Boolean Yes/No No
Status system

Trainer Auto-complete
Text Box Yes String - -
Name from database

Trainer Field Dropdow Validated from

Yes String [Fields] -
of Study n study domains

Updated as
Workflow [Stages
Label Yes String Initiated workflow
Stage ]
progresses

Business Rules and Dependencies

Validation / Business Data
Field Label Error Messages
Rules Dependencies
Primary Must be registered and "Primary Lab must be
Training Case
Lab available selected from list."

Deadline "Deadline must be in

Must be future date System Date
Date future."

Overdue Auto-updated 24hrs post-

"Case is overdue." Deadline Date
Status deadline if not completed

"Trainer not
Trainer Must match registered
recognized in Trainer Registry
Name profile
system."

Workflow Depends on prior stage "Previous step not Workflow

Stage completion completed." Configuration

Buttons, Links, and Icons

Other Visibl Enabled vs
Label OnClick Event Navigate To
Event e Displayed

Opens lab Enabled on

Assign
assignment None Yes case LabAssignmentPage
Lab
popup approval

Triggers
Start Enabled if all WorkflowExecutionHan
workflow None Yes
Workflow data present dler
engine

Validates and
Save Enabled TrainerManagementPag
saves trainer None Yes
Trainer always e
profile

Enabled if
View Filters overdue OverdueCaseDashboar
None Yes overdue
Overdue cases d
exists

Risk Assessment
 Data Integrity Risk: Incomplete or incorrect lab or trainer
assignment can disrupt workflows. Implement validations and locking.
  Overdue Tracking: Delays in overdue flag generation due to server
lag. Use CRON-based tracking.

 Workflow Execution Errors: May halt if resources are unavailable.

Use fallback routing and notifications.

Updated Non-Functional Requirements

 Performance: Overdue tracking to run under 1 minute per batch of
500 cases.

 Scalability: Must support up to 50,000 training cases concurrently.

 Security: Role-based access for lab assignment, workflow triggers,

and trainer updates.

 Availability: 99.9% uptime; fallback screens for workflow errors.

 Auditability: Full logs of lab/trainer assignment and overdue status

changes.
Sub Module Name: Training Search, Report Compilation, KPI
Evaluation

Overview
This document outlines the functional specifications for the PCSIR ERP
Training Management System’s sub-modules including Training Search using
keywords and wildcard searches, Report Compilation & Generation, and
Automatic KPI Calculation & Evaluation. The aim is to streamline training-
related data retrieval, automate report generation, and evaluate training
performance metrics effectively.

Software Requirement Analysis

 Platform: Web-based ERP application

 Supported Browsers: Chrome, Firefox, Edge

 Backend: SQL Server or Oracle DB

 Frontend: ReactJS with TailwindCSS

 Integration: KPI Management Module, Notifications, PDF/Excel Export

Modules

 Security: Role-based Access Control (RBAC), Audit Trails

High-level Architecture
1. Frontend Layer: ReactJS-based form inputs for keyword search,
filters, and KPI display.

2. Business Logic Layer: Handles search processing, KPI computation

algorithms, and report formatting.

3. Data Layer: Fetches and stores training data from relational

databases.

Sub Module: Training Search using Keywords and Wildcard Search

Purpose/Description
Enable users to search for training records using keywords or partial string
matches across training titles, trainer names, fields of study, and industry
type.

Use Cases
Use Case ID: TMS-SRCH-001
Use Case Name: Keyword and Wildcard Search
Primary Actor(s): Training Officer, Administrator
Pre-conditions: User must be logged in with appropriate permissions
Post-conditions: Filtered list of training sessions is displayed
Main Success Scenario:

1. User enters keyword or wildcard query

2. System fetches relevant data

3. Results are displayed in a tabular format Alternative Path: No records

found; display message Business Rules:

 Wildcards allowed: %, *

 Search applies to: Title, Trainer, Field of Study, Industry Type

Sub Module: Report Compilation and Generation

Purpose/Description

Facilitates automatic compilation of training reports with filtering options and

export functionality to PDF/Excel.

Use Cases
Use Case ID: TMS-RPT-002
Use Case Name: Generate Training Report
Primary Actor(s): Admin, Training Officer
Pre-conditions: User must be authorized
Post-conditions: Report is generated and ready for download or printing
Main Success Scenario:

1. User selects filters (date range, trainer, type, field)

2. Clicks Generate Report

 3. System compiles and exports report Alternative Path: No data for
selected filters Business Rules:

 Must include summary stats

 Export to PDF/Excel

Sub Module: Automatic KPI Calculation and Evaluation

Purpose/Description

Calculate and present key performance indicators for training activities

based on defined parameters (attendance, feedback score, training
duration).

Use Cases
Use Case ID: TMS-KPI-003
Use Case Name: KPI Auto-Calculation
Primary Actor(s): Administrator, HR Manager
Pre-conditions: KPI parameters must be defined
Post-conditions: KPI dashboard is updated
Main Success Scenario:

1. System reads attendance, feedback scores, trainer quality

2. KPI values are calculated

3. Values displayed and exported Alternative Path: Data inconsistency

triggers error Business Rules:

 KPI formula = (Weighted Attendance * Feedback) / Time Factor

Screen/UI Design
Design to be embedded separately – includes:

 Keyword Search Bar

 Filters Pane (Date, Industry, Field of Study)

 Report Generation Buttons

 KPI Dashboard (with charts, scores)

Field Level Specifications

Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value
Search Wildcard
Text Box No String N/A N/A
Keyword enabled

Date Current
Start Date No Date N/A Date Range filter
Picker Date

Date Current
End Date No Date N/A Date Range filter
Picker Date

All
Industry Dropdow Lookup from
No String Industry N/A
Type n Industry Master
Types

Field of Dropdow Lookup from

No String All Fields N/A
Study n Study Master

Business Rules and Dependencies

Data
Field Label Validation Rules Error Messages
Dependencies

Search Accept wildcards *, %; max "Invalid keyword

None
Keyword length 50 chars format"

"Start date cannot

Start Date Must be before End Date End Date
exceed end"

Cannot exceed current "End date is in the

End Date Start Date
date future"

Buttons, Links and Icons

Other Visibl Enable
Label OnClick Event Navigate To
Event e d

Execute Enter
Search Yes Yes Stay on Search Page
wildcard search key

Generate Compile and /training/report/

None Yes Yes
Report download download
View KPI Navigate to KPI /training/kpi-
None Yes Yes
Dashboard Summary dashboard

Risk Assessment
 Incorrect KPI logic: Ensured through test cases and audits.

 Performance: Wildcard search may slow down large datasets –

optimized using indexed columns.

 Security: Exports and report access restricted by user role.

Updated Non-Functional Requirements

 Performance: Search results under 3 seconds for up to 100k records

 Scalability: Ready for integration with future KPI modules

 Security: Role-based access control, audit logs

 Usability: Intuitive filters and exports for non-technical users

 Compatibility: Desktop and mobile responsive interface

Visits Management System
Sub Module: Industrial Visits Management System – Visit
Information

Overview
The Industrial Visits Management System (IVMS) under PCSIR ERP is
designed to digitally manage and track all industrial visits carried out by
PCSIR scientists/engineers. The Visit Information sub-module is the core
data-capturing component that maintains records of visit details, including
source linkage, participant records, venue, results, and media attachments. It
supports incoming and outgoing visit types, enables proper approval
workflows, and integrates with KPI scoring and reporting features.

Software Requirement Analysis

 Stakeholders: PCSIR Scientists, Engineers, Center Heads (HoC),
Director P&D, Director General PCSIR Complex, MIS Department

 Primary Interfaces: PCSIR HR System, KPI Scoring Engine, Document

Upload Services

 Input Sources: Manual entry from authenticated users

 Output: Approved visit records, progress reports, KPI data points

 Compliance: Government Data Protection and Integrity Standards

High-level Architecture
 Frontend: Angular/React-based UI

 Backend: Node.js or Java Spring Boot APIs

 Database: PostgreSQL / Oracle

 Services:

o HR System Integration (Employee Validation)

o Approval Workflow Engine

 o Media Storage Service (Image/Video Upload)

o KPI Scoring Engine

o Report Generation Service

Sub Module Name: Visit Information

Purpose/ Description

The Visit Information sub-module is responsible for capturing and managing

detailed data related to PCSIR’s industrial visits. It facilitates the entry of visit
metadata, links with source modules (R&D, Testing, Calibration, etc.),
captures industry and study fields, allows for media uploads, and handles
multi-stage approval workflows. This sub-module forms the basis for progress
reporting and KPI evaluation.

Use Cases
Use Case 1

 Use Case ID: IVMS-VISIT-01

 Use Case Name: Add New Visit Information

 Primary Actor(s): PCSIR Scientist/Engineer

 Pre-conditions:

o User must be authenticated through PCSIR ERP.

o Source of visit must be valid.

 Post-conditions:

o Visit record is submitted for initial approval.

 Main Success Scenario:

1. User clicks “Add Visit”.

2. Fills in required visit information.

3. Selects source and links source reference.

4. Adds PCSIR and Industry participants.

5. Uploads media (if available).

6. Submits for approval.

  Alternative Path:

o If source = “Other”, additional fields for manual industry and

field of study input become mandatory.

 Business Rules:

o PCSIR participants must be validated via HR System.

o Source references must exist in the linked modules.

Use Case 2

 Use Case ID: IVMS-VISIT-02

 Use Case Name: View Visit History

 Primary Actor(s): PCSIR Staff

 Pre-conditions: Visit records must exist.

 Post-conditions: User views status, results, approvals.

 Main Success Scenario:

1. User navigates to “My Visits”.

2. Filter/search applied.

3. Results shown with status (Submitted, Approved, Rejected, KPI-

Included).

 Business Rules:

o Access limited to user’s own visits unless role is Center

Head/Director.

Use Case 3

 Use Case ID: IVMS-VISIT-03

 Use Case Name: Approve Visit

 Primary Actor(s): Head of Center / Director P&D

 Pre-conditions: Visit submitted for approval.

 Post-conditions: Visit is approved/rejected/objected.

 Main Success Scenario:

 1. Approver receives visit request.

2. Reviews details and participant list.

3. Makes a decision: Approve/Reject/Object.

 Alternative Path:

o If objection is raised, case goes back to initiator.

 Business Rules:

o Only approved visits are included in KPI calculations.

Screen/UI Design
(Wireframe will be attached in the finalized version — describe below in
detail.)

 Tabs:

o Visit Information

o Participants

o Source Reference

o Media Upload

o Approval Workflow

 Action Buttons:

o Save, Submit, Add Participant, Upload Media, Approve, Reject,

Object

Field Level Specifications

Defau
Field Field Mandato Data
Value Set lt Comments
Label Type ry Type
Value

Determines
Dropdow Incoming,
Visit Type Yes String None direction of
n Outgoing
the visit

Source of Dropdow Yes String Inquiry, R&D None If "Other",

Visit n Program, Testing, enable
Calibration, Industry and
 Defau
Field Field Mandato Data
Value Set lt Comments
Label Type ry Type
Value

Process Lease
Out, Product
Development,
Design and
Fabrication,
Fields input
Technical Report,
Consultancy,
Industrial
Training,
Academic, Other

Required if
Source Condition
Text Box String N/A None source ≠
Reference al
"Other"

List of PCSIR- Lookup from

Multi-
Industry Yes String recognized None Industry
Select
industries Master Table

Mandatory if
Field of Multi- Condition List of PCSIR-
String None Source =
Study Select al defined fields
Other

Description
Visit
Text Box Yes String N/A None of reason for
Purpose
visit

Date Valid calendar Curren No future

Visit Date Yes Date
Picker dates t Date dates allowed

PCSIR Employee ID
Dynamic Objec Lead must be
Participant Yes (Lookup from None
List t marked
s HR) + Name

Industry Optional,
Participant Text Area No String N/A None free-text
s entry

Visit Venue Text Box Yes String N/A None Physical or

 Defau
Field Field Mandato Data
Value Set lt Comments
Label Type ry Type
Value

virtual venue

Visit Outcomes of
Text Area Yes String N/A None
Results the visit

Upload File Images/

No File JPG, PNG, MP4 None
Media Upload videos

Business Rules and Dependencies

Data
Validation/ Business
Field Label Error Messages Dependencie
Rules
s

If “Other”, industry and “Please provide

Source of Source =
field of study fields are industry and field
Visit "Other"
mandatory details.”

Must include at least “At least one Lead

PCSIR Lookup from
one participant and one Participant must be
Participants HR
Lead assigned.”

“Future dates not Current system

Visit Date Cannot be future-dated
allowed.” date

Upload “Unsupported file

File types restricted Upload module
Media format.”

Buttons, Links and Icons

Button Other Visibl Enabled vs
OnClick Event Navigate To
Label Event e Displayed

Enabled for all Stay on same

Save Save draft None Yes
users page

Submit Submit for HoC None Yes Enabled if all -

Button Other Visibl Enabled vs
OnClick Event Navigate To
Label Event e Displayed

mandatory fields
approval
filled

Opens
Add
participant None Yes Always enabled Modal Popup
Participant
modal

Upload Triggers file

None Yes Enabled -
Media selector

Approves visit Only visible to Redirect to

Approve None Yes
(HoC/Director) approvers Dashboard

Only visible to Redirect to

Reject Rejects visit None Yes
approvers Rejected Cases

Redirect to
Sends back for Only visible to
Object None Yes Initiator
correction approvers
Dashboard

Risk Assessment
Risk Impac
Description Mitigation Strategy
ID t

Incomplete participant data from Integration testing with HR

R1 High
HR System system; validation rules

Missing visit media upload due Mediu Enforce media limits and
R2
to file size or type issues m allow alternate uploads

Role-based access control

R3 Unauthorized approvals or edits Critical
and audit trail

Mediu
R4 Data loss during submission Autosave drafts and backups
m
Updated Non-Functional Requirements
Requiremen
Description Target
t ID

System must respond to visit form submission

NFR-01 ≤ 2 seconds
within 2 seconds

Upload media size limit should not exceed 25

NFR-02 ≤ 25 MB
MB

Approval history must be fully traceable and 100%

NFR-03
auditable traceability

System should support wild card and multi-field Advanced

NFR-04
visit search Search

System must handle concurrent entries from ≥ 100

NFR-05
multiple users concurrent
Sub Module: Visit Search Using Keywords and Wildcard Search
and Automatic KPI Calculation and Evaluation
Overview
The Industrial Visits Management System (IVMS) facilitates comprehensive
management and tracking of PCSIR industrial visits. This FSD covers two
critical sub-modules:

1. Visit Search Using Keywords and Wildcard Search: Enables users

to quickly locate visit records by applying keyword filters and flexible
wildcard searches over multiple fields, enhancing data retrieval
efficiency.

2. Automatic KPI Calculation and Evaluation: Automates the

evaluation of Key Performance Indicators (KPIs) based on approved
visit data, ensuring objective and timely performance measurement
aligned with PCSIR’s organizational goals.

Software Requirement Analysis

 Actors: PCSIR Scientists, Center Heads, Directors, MIS Staff

 Data Sources: Industrial Visits Database, User Role Data, KPI Rules
Engine

 Interfaces: ERP Search Engine, KPI Dashboard, Reporting Tools

 Constraints: Search must be performant over large datasets; KPI

calculations must reflect real-time approvals

 Security: Role-based access controls for search and KPI data visibility

High-level Architecture
 Frontend: ReactJS UI components for search and KPI dashboards

 Backend: RESTful APIs handling search queries and KPI computations

 Database: PostgreSQL optimized for full-text and wildcard search

indexes
  Services:

o Search Service with wildcard and keyword parsing

o KPI Calculation Engine integrated with visit approval workflows

o Reporting Module for KPI visualization

Sub Module Name: Visit Search Using Keywords and Wildcard Search
Purpose / Description

This sub-module enables users to perform powerful, flexible searches on

industrial visit records using keyword inputs and wildcard patterns. It
supports filtering by various visit attributes including visit type, source,
participants, industry, field of study, date ranges, and visit results. The
feature enhances usability by reducing time spent locating specific visit
records.

Use Cases
 Use Case ID: IVMS-SEARCH-01

 Use Case Name: Search Visit Records

 Primary Actor(s): PCSIR Scientists, MIS Staff, Center Heads

 Pre-conditions:

o User is authenticated and authorized for visit data access

 Post-conditions:

o Relevant visit records matching criteria are displayed

 Main Success Scenario:

1. User enters keywords or wildcard patterns into search bar.

2. User optionally selects filters (visit type, date range, industry,

etc.).

3. System performs a full-text search with wildcard support.

4. Results matching criteria are displayed in tabular format with

pagination.
  Alternative Path:

o If no results found, user is prompted to modify search criteria.

 Business Rules:

o Search respects user access permissions.

o Wildcard characters supported: * (any characters), ? (single

character).

Screen/UI Design
 Search bar with wildcard-enabled input

 Filters panel: Visit Type, Source, Industry, Field of Study, Date Range

 Results grid with columns: Visit ID, Date, Type, Industry, Participants,
Status

 Pagination controls

 Export button (CSV/PDF)

Field Level Specifications

Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

Search Supports * and

Text Box No String N/A None
Keywords ? wildcards

Filters results
Dropdow Incoming,
Visit Type No String All by visit
n Outgoing
direction

Inquiry, R&D,
Dropdow Testing, Multi-select
Source No String All
n Calibration, enabled
Other

Industry Multi- No String List of PCSIR None Lookup from

Select Industries master
Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

industry list

Lookup from
Field of Multi- List of PCSIR
No String None master field of
Study Select Fields
study list

Date Date From and To

No Date N/A None
Range Picker dates

Business Rules and Dependencies

Validation / Business Error
Field Label Data Dependencies
Rules Messages

“Invalid
Search Supports wildcards * and ?
wildcard N/A
Keywords only
syntax.”

‘From Date’ must be ≤ ‘To “Invalid date Date validation based

Date Range
Date’ range.” on system date

Search results filtered

User “Access User roles linked to
based on user's role
Permissions Denied.” visit record access
permissions

Buttons, Links and Icons

Button Other Visibl Enabled vs Navigate
OnClick Event
Label Event e Displayed To

Executes search Enabled when

Search None Yes Same page
query input is valid

Reset Clears all filters and None Yes Enabled Same page
Button Other Visibl Enabled vs Navigate
OnClick Event
Label Event e Displayed To

keywords

Exports current Enabled if results File

Export None Yes
result set exist download

Risk Assessment
Risk Impac
Description Mitigation Strategy
ID t

Large search datasets cause Index optimization;

R1 High
performance degradation search caching

Incorrect search results due to Mediu Input validation and user

R2
wildcard misuse m help tips

Unauthorized data exposure via Strict role-based access

R3 Critical
search control

Updated Non-Functional Requirements

Requiremen
Description Target
t ID

Search response time should not exceed 3

NFR-01 ≤ 3 seconds
seconds

System supports up to 100 concurrent 100 concurrent

NFR-02
search requests users

NFR-03 Exported files generated within 5 seconds ≤ 5 seconds

Sub Module Name: Automatic KPI Calculation and Evaluation

Purpose / Description

This sub-module automatically calculates and evaluates KPIs related to

industrial visits based on approved visit records. It applies predefined KPI
rules, aggregates data per employee, center, and timeframe, and generates
KPI scores used in performance reviews and reporting. This automation
ensures accuracy, objectivity, and timely updates to performance metrics.

Use Cases
 Use Case ID: IVMS-KPI-01

 Use Case Name: Calculate KPIs for Approved Visits

 Primary Actor(s): KPI Engine, MIS Staff

 Pre-conditions:

o Visit record is approved by all required authorities.

 Post-conditions:

o KPIs are updated and reflected in dashboards and reports.

 Main Success Scenario:

1. Approved visit data triggers KPI calculation batch.

2. System applies KPI formulas based on visit attributes (e.g.,

number of visits, visit results, participant involvement).

3. KPI scores are stored in employee and center records.

4. KPI dashboards are updated in near real-time.

 Alternative Path:

o Visits rejected or objected are excluded from KPI calculation.

 Business Rules:

o KPI rules are configurable and version-controlled.

o Only visits within defined reporting periods are counted.

Screen/UI Design
 KPI Dashboard showing aggregated scores by employee, center, and
time

 Detailed drill-down for individual visit contributions

 Configurable KPI thresholds and weights

 Alert/notification panel for KPI updates or issues

Field Level Specifications
Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

Monthly, Select time

KPI Dropdow
Yes String Quarterly, Monthly period for KPI
Period n
Yearly calc

Employe Lookup from

Text Box Yes String N/A None
e ID HR system

Visit Total approved

Label N/A Integer N/A 0
Count visits

Calculated
KPI Score Label N/A Float 0.0 – 100.0 0.0
score

Calculated,
KPI calculation
Status Label N/A String Pending, Pending
status
Failed

Business Rules and Dependencies

Field Validation / Business Data
Error Messages
Label Rules Dependencies

“Invalid KPI
KPI Period Must be a valid time period Date validation
period.”

Employee “Employee not HR System

Must exist in HR system
ID found.” integration

Calculated based on “KPI calculation Visit approval

KPI Score
approved visits only failed.” status

Updates to reflect calculation Calculation job

Status N/A
result result
Buttons, Links and Icons
Button Other Visibl Enabled vs Navigate
OnClick Event
Label Event e Displayed To

Initiates KPI Enabled if visit Same

Calculate None Yes
calculation batch data available page

Refreshes KPI Same

Refresh None Yes Enabled
dashboard data page

Exports KPI data in Enabled if KPI File

Export KPI None Yes
report format data exists download

Risk Assessment
Risk Impac
Description Mitigation Strategy
ID t

Delays in KPI update due to Mediu Optimize batch processing,

R1
large data volume m incremental calc

Incorrect KPI results from Data validation prior to

R2 High
invalid visit data calculation

Unauthorized access to KPI Role-based KPI data visibility

R3 Critical
data control

Updated Non-Functional Requirements

Requirement
Description Target
ID

KPI calculations must complete within 5

NFR-04 ≤ 5 minutes
minutes

KPI dashboard updates reflect data within ≤ 10 minutes

NFR-05
10 minutes latency

KPI data export supports CSV, Excel, and All common

NFR-06
PDF formats formats
Quality Management System (ISO/IEC 17025)
Document Management System for ISO
Overview
The ISO Document Management System is a centralized digital platform
designed to manage and control the lifecycle of documents related to Quality
Management System (QMS) compliance, specifically for ISO standards. This
system ensures secure versioning, revision history, controlled access, and
traceability for documents such as SOPs, Manuals, Templates, Audit Reports,
Policies, and more. It is essential for maintaining compliance with ISO
standards, enabling transparent audits, and supporting continual
improvement in quality processes.

Software Requirement Analysis

Requirement Description

Functional Ability to upload, edit, approve, version, and archive

Requirements ISO-related documents

Security Role-based access control; audit trail logging for every

Requirements document transaction

ISO 9001:2015, ISO 17025 standards for document

Compliance
control

Integration with User Management Module for Role

Integration
Access Control

System should support high availability and handle

Performance
concurrent users

Automated daily backup with version restoration

Backup & Recovery
capabilities

High-Level Architecture
 Frontend: Web-based UI using React/Angular with Bootstrap/Material
Design
  Backend: Node.js/.NET Core with RESTful API layer

 Database: PostgreSQL/MySQL for metadata and document indexing

 Storage: Encrypted file system or cloud-based blob storage (e.g., AWS

S3)

 Security: OAuth2/JWT authentication, SSL encryption

 Version Control: Custom table-based versioning logic with rollback

and compare features

Module Name: ISO Document Management System

Sub-Module Name:

Controlled Documents Repository and Versioning

Purpose/Description:

This sub-module facilitates the systematic creation, versioning, approval,

access control, and archival of Controlled ISO Documents. It allows
organizations to maintain compliance with QMS and ISO standards by
maintaining historical integrity and access logs for documents such as:

 Quality Manual

 QMS Processes

 SOPs for Equipment

 Forms and Formats

 QMS Templates

 Internal & External Audit Reports

 Objectives

 Policies

 Opportunities

Use Cases
Use Case 1

 Use Case ID: UC_ISO_001

 Use Case Name: Upload New Controlled Document

 Primary Actor(s): Quality Admin, Document Controller

  Pre-conditions: User must be authenticated and authorized

 Post-conditions: Document is saved with metadata and version set

to 1.0

 Main Success Scenario:

1. User selects document type and uploads file

2. Metadata is entered

3. System assigns version 1.0 and stores the document

4. Notification sent to approver

 Alternative Path:

o If metadata is incomplete, show error and do not allow

submission

 Business Rules: Only approved users can upload documents to

specific categories

Use Case 2

 Use Case ID: UC_ISO_002

 Use Case Name: Create New Revision

 Primary Actor(s): Document Editor, Quality Admin

 Pre-conditions: Document already exists in system

 Post-conditions: New version is created with incremented revision

and logs

 Main Success Scenario:

1. User accesses document details

2. Edits and uploads revised version

3. System auto-increments revision and issue numbers

4. Approver validates the revision

 Alternative Path:

o If previous version is still pending approval, restrict new revision

  Business Rules: Only authorized personnel can create document
revisions

Screen/UI Design
(Wireframes and UI design can be inserted as per prototype system;
description provided below)

Key Screens:

 Document Upload Screen

 Document List View with Filters

 Document Detail with Metadata & Version History

 Revision Creation Panel

 Approval Workflow Panel

 Audit Trail Viewer

Field-Level Specifications
Field Field Mandato Default
Data Type Value Set Comments
Label Type ry Value

Unique per
Document
Text Box Yes String N/A N/A document
Title
type

Auto-
Document Alphanumer Must be
Text Box Yes N/A gen or
Number ic unique
Manual

Format X.Y Auto-

Revision
Text Box Yes Decimal (e.g., 1.0, 1.0 incremented
Number
1.1) on revision

Auto-
Issue
Text Box Yes Integer N/A 1 incremented
Number
per version
Field Field Mandato Default
Data Type Value Set Comments
Label Type ry Value

Auto-
Issue Date Current assigned;
Yes Date N/A
Date Picker Date editable by
admin

Quality
Document Dropdow Manual, Predefined
Yes String None
Type n SOP, Form, categories
etc.

Uploaded File .doc, .pdf, . File size <

Yes Binary None
File Upload xls 20MB

Uploaded Logged-in Logged System

Auto Text Yes String
By user User generated

Pending,
Approval Dropdow Controlled by
Yes Enum Approved, Pending
Status n workflow
Rejected

Business Rules and Dependencies

Validation / Data
Field Label Error Messages
Business Rules Dependencies

"Title already exists

Document Must be unique for the Dependent on
under this
Title same Document Type Document Type
category"

Document Alphanumeric; unique "Document number System-wide

Number system-wide already used" uniqueness

Revision Auto-incremented per "Invalid revision Based on previous

Number Document ID number" document revision

Cannot be in the "Future dates not

Issue Date System clock
future allowed"
Buttons, Links and Icons
Other Enabled vs
Label OnClick Event Visible Navigate To
Event Displayed

Opens Upload Enabled if user

Upload None Yes Upload Dialog
Panel has access

Saves metadata Enabled when Document

Save None Yes
and file all fields valid Repository

Opens previous Revision

Create Enabled if doc
doc and sets new None Yes Upload
Revision approved
rev Screen

Hover
View Displays version Always Version
shows Yes
History history enabled History Panel
details

Marks document Role- Enabled for Approval Log

Approve None
as Approved based approver Panel

Risk Assessment
Risk Mitigation Strategy

Unauthorized access to controlled

Implement robust RBAC and audit logs
documents

Daily encrypted backups and revision

Loss of revision data
rollback

Enforce validation, mandatory fields,

Incorrect metadata entry
and review UI

Restrict file types and enforce size

File type or size issues
limits

Workflow bottlenecks Notifications and escalation reminders

Updated Non-Functional Requirements
NFR Category Requirement

System must support 100 concurrent users with <2s

Performance
response time

Availability 99.9% uptime with automated failover

Backup & Daily backups, restore point available per document and
Restore version

Security SSL encryption, JWT-based auth, role-based access

Usability Responsive UI, clean navigation, filter-based search

Logging & Audit Full activity log for uploads, edits, approvals, and access
Trail attempts

Horizontally scalable for future modules and increased

Scalability
document load
Sub Module: The Opportunities and Risk Management System
Overview
The Opportunities and Risk Management System is a key component of the
PCSIR ERP platform, facilitating center-wise monitoring, control, and analysis
of potential opportunities and associated risks. This system is designed to
ensure proactive management by allowing the definition, categorization, and
evaluation of both positive and negative occurrences that may impact
center-level operations. It will support strategic planning by identifying
potential benefits and limitations while mitigating risks through preventive
controls and risk rating mechanisms.

Software Requirement Analysis

The system must provide:

 A user interface for defining and managing center-wise opportunities

and risks.

 Capability to define and describe risk likelihood and severity scales

with values ranging from 0 to 5.

 Automatic risk rating calculation (Severity x Likelihood).

 Data fields and conditional logic for action statuses (Taken/Not Taken).

 Configuration for control plans and further control recommendations.

 Audit trails and search functionalities.

High-level Architecture
 Frontend: Web-based interface developed in Angular/React.

 Backend: RESTful API with Node.js/.NET Core.

 Database: PostgreSQL or MS SQL Server.

 Authentication: Integrated with PCSIR Single Sign-On (SSO).

 Hosting: On-Premise PCSIR Data Center / Cloud Infrastructure.

 Security: RBAC-based permissions, encrypted data storage.

Purpose/Description of Sub-Module
This sub-module allows centers to record and evaluate both opportunities
and risks with detailed attributes such as potential benefits, limitations,
controls, actions taken, and the rationale for inaction. Additionally, it allows
risk severity and likelihood definition and evaluates risks with control
measures and auto-calculated risk ratings. The system ensures
comprehensive documentation and mitigation planning for operational
excellence.

Use Cases
Use Case ID: ORM-001

 Use Case Name: Define Center-wise Opportunity

 Primary Actor(s): Center Administrator

 Pre-conditions: User must have permission to define opportunities

 Post-conditions: Opportunity entry saved and displayed in dashboard

 Main Success Scenario:

1. User logs in and navigates to Opportunities section.

2. Selects center and fills in opportunity form.

3. Submits with appropriate controls, benefits, limitations, and

action status.

4. Data is saved and displayed in opportunities list.

 Alternative Path:

o If 'Action Taken' is No, 'Reason for No Action' must be entered.

 Business Rules: Mandatory field validations and logical dependencies

for action statuses.

Use Case ID: ORM-002

 Use Case Name: Define Risk Likelihood & Severity

 Primary Actor(s): Super Admin / Risk Officer

 Pre-conditions: Likelihood/Severity categories must be editable only

by authorized roles

 Post-conditions: New values saved and available for dropdowns

  Main Success Scenario:

1. Admin defines values and descriptions for each level (0-5).

 Business Rules: Values must be unique and within range 0-5.

Use Case ID: ORM-003

 Use Case Name: Define Center-wise Risk

 Primary Actor(s): Center Risk Manager

 Pre-conditions: Likelihood and severity must be pre-defined

 Post-conditions: Risk record saved with calculated risk rating

 Main Success Scenario:

1. Risk Manager selects activity and enters potential risk.

2. Assigns severity and likelihood.

3. System auto-calculates risk rating.

4. Defines existing and further controls.

 Business Rules: Severity and likelihood must be numeric (0-5)

Screen/UI Design
Screens to be provided separately as wireframes/prototypes:

 Opportunity Form Page

 Risk Likelihood/Severity Setup Page

 Risk Entry Page with Rating Calculation

Field Level Specifications

Field Field Mandator Data Value Default
Comments
Label Type y Type Set Value

Logged-in
Dropdow Cente Lookup from
Center Yes Text User's
n r List Center Master
Center

Potential Text Box Yes String N/A N/A Free text

Opportunit
y

Potential
Text Area Yes String N/A N/A Describe benefit
Benefit

Describe
List of
Text Area No String N/A N/A implemented
Controls
controls

Describe
List of
Text Area No String N/A N/A operational
Limitations
constraints

Boolean Controls
Action Dropdow Yes,
Yes (Yes/No No conditional
Taken n No
) visibility

Details of Conditionall Visible if Action

Text Area String N/A N/A
Action y Yes Taken = Yes

Reason for Conditionall Visible if Action

Text Area String N/A N/A
No Action y Yes Taken = No

Linked to risk
Activities Text Box Yes String N/A N/A
section only

Potential
Text Area Yes String N/A N/A N/A
Risk

Dropdow Based on pre-

Severity Yes Integer 0-5 0
n defined list

Dropdow Based on pre-

Likelihood Yes Integer 0-5 0
n defined list

Controls in Existing
Text Area No String N/A N/A
Plan mitigation plan

Further Recommendation
Controls Text Area No String N/A N/A s for further
Required action
 Auto-
Calculate Severity x
Risk Rating calculate No Integer 0-25
d Likelihood
d

Business Rules and Dependencies

Field Validation/Business Data
Error Messages
Label Rules Dependencies

"Please enter Details of

Action If Yes, Details required; Conditional Field
Action" / "Enter reason
Taken If No, Reason required Visibility
for No Action"

"Severity must be Lookup

Severity Must be in range 0–5
between 0 and 5" dependency

"Likelihood must be Lookup

Likelihood Must be in range 0–5
between 0 and 5" dependency

Depends on
Risk Auto-calculated =
None Severity,
Rating Severity x Likelihood
Likelihood

Buttons, Links, and Icons

Button Other Visibl Enabled vs
OnClick Event Navigate To
Label Event e Displayed

Summary
Save Save form data None Yes Enabled always
List

Current
Reset Clear form None Yes Enabled always
page

Open form in edit

Edit None Yes Conditional Edit Page
mode

View
Show audit trail None Yes Enabled Audit Modal
History
Risk Assessment
The sub-module itself is a tool for risk assessment and control. Key internal
risks include:

 Data Misclassification: Controlled via validations and dropdowns.

 Access Rights Violation: Role-based access control (RBAC).

 Manual Errors: Auto-calculation of risk rating reduces human error.

 Incomplete Entries: Mandatory checks and conditional visibility

ensure completeness.

Updated Non-Functional Requirements

 Performance: System must support concurrent use by at least 100
users.

 Scalability: Must support addition of new centers and risk categories.

 Availability: 99.5% uptime (hosted on PCSIR private cloud).

 Auditability: All changes must be logged with timestamps and user

IDs.

 Security: Role-based authentication, encryption for data-at-rest and

in-transit.

 Searchability: Wildcard and filter search across Opportunity and Risk

logs.

 Interoperability: Integrates with Central ERP Master Modules (e.g.,

Center Master).
Sub Module: The "Committee Management System"
Overview
The "Committee Management System" is a module within the PCSIR ERP
ecosystem that facilitates the formation, operation, and documentation of
various institutional committees, including, but not limited to, the
Management Review Committee, Purchase Committee, Technical Committee,
and Transport Committee. This module ensures structured governance by
automating committee creation, meeting scheduling, agenda preparation,
attendance tracking, documentation handling, and real-time notifications.
The system ensures traceability, accountability, and transparency in all
committee-related activities.

Software Requirement Analysis

This module shall allow authorized users (typically administrative staff or
committee organizers) to:

 Create and categorize committees

 Assign roles within a committee (Chairperson, Secretary, Members)

 Schedule meetings (with date, time, venue)

 Notify committee members automatically

 Manage meeting agendas and flag actionable points

 Record minutes of meetings (MoMs)

 Upload/download related documents

 Maintain attendance with scanned image support

 Generate printable documents (agenda, minutes, notices, etc.)

  Integrate with mobile app for alerts and summary updates

High-level Architecture
Frontend:

 Web UI: Angular/React-based responsive UI

 Mobile App: Flutter/React Native

Backend:

 Node.js/.NET Core for RESTful APIs

 SQL Server or PostgreSQL as DBMS

Security & Access Control:

 Role-Based Access Control (RBAC)

 SSO/LDAP Authentication

Integrations:

 PCSIR Employee Directory

 PCSIR Notifications Engine (SMS/Email/Mobile)

Sub Module Name: Committee Setup and Meeting Lifecycle

Purpose/Description

This sub-module handles the full lifecycle of committees: their creation,

member assignment, role designation, meeting scheduling, and
documentation. It ensures streamlined committee operations and
centralization of associated artifacts such as agenda, MoMs, and decisions.

Use Cases
Use Case ID: COM-01

Use Case Name: Create a New Committee Primary Actor(s):

Admin/Designated Staff Pre-conditions:

 User must have Committee Management privileges Post-conditions:

 New committee is listed and accessible Main Success Scenario:

 Admin selects "Create Committee"

 Enters name, short description, and type

 Saves the committee Alternative Path:

  Error if committee name already exists Business Rules:

 Committee name must be unique

Use Case ID: COM-02

Use Case Name: Assign Members and Roles Primary Actor(s): Admin Pre-
conditions:

 Committee must already be created Post-conditions:

 Committee members are listed with assigned roles Main Success

Scenario:

 Admin selects members from employee list

 One member designated as Chairperson

 One member designated as Secretary Alternative Path:

 Error if no chairperson is assigned Business Rules:

 Chairperson must be selected from member list

Use Case ID: COM-03

Use Case Name: Schedule Committee Meeting Primary Actor(s):

Committee Secretary Pre-conditions:

 Committee must exist Post-conditions:

 Meeting schedule is saved, notifications sent Main Success Scenario:

 Admin selects "Schedule Meeting"

 Enters date, time, venue

 Saves and sends notifications Alternative Path:

 Error if schedule overlaps with existing meeting Business Rules:

 Notification must go to all members immediately

Use Case ID: COM-04

Use Case Name: Record Minutes of Meeting Primary Actor(s): Secretary,

Admin Pre-conditions:

 Agenda must be pre-entered Post-conditions:

 MoM is stored and shared with members Main Success Scenario:

  Secretary opens meeting

 Records decisions per agenda item

 Sets flags per item (Settled, Deferred, etc.)

 Finalizes and publishes Alternative Path:

 MoM draft saved without finalization Business Rules:

 Each agenda must have at least one outcome

Screen/UI Design
(Screens to be added as wireframes/prototypes as per design process.)

 Committee Creation Screen

 Member Assignment Screen

 Meeting Schedule Interface

 Agenda & MoM Entry Interface

 Document Upload and Access Screen

 Attendance Sheet Upload

Field Level Specifications

Defaul
Field Field Mandato Data
Value Set t Comments
Label Type ry Type
Value

Committee
Text Box Yes String N/A None Unique
Name

Short
Text Area No String N/A None -
Description

Purchase,
Management
Committee
Dropdown Yes String Review, - Lookup
Type
Transport,
Technical

Member Multi- Yes String Employees - Lookup

Name select
 Dropdown from PCSIR

Validation to
Chairperso Selected
Dropdown Yes String - ensure
n members only
selection

PCSIR Must be PCSIR

Secretary Dropdown Yes String -
employees staff

Meeting Date
Yes Date - - -
Date Picker

Meeting Time
Yes Time - - -
Time Picker

Venue Text Box Yes String - - -

Agenda
Text Area Yes String - - -
Item

Optional but
Referred,
flagged if
Agenda Deferred,
Dropdown No String - "Time Given"
Flag Settled, Time
then date is
Given
mandatory

Required if
Deadline (if Date
No Date - - "Time Given"
pended) Picker
flag selected

Upload File PDF, DOCX

No File - -
Document Upload allowed

Attendance File Imag

No - - JPG, PNG only
Image Upload e

Business Rules and Dependencies

Data
Field Label Validation/Business Rules Error Messages
Dependencies

Committee "Committee
Must be unique None
Name already exists"
 "Chairperson Depends on
Must be a selected
Chairperson must be a selected
member
member" members

"Invalid selection PCSIR employee

Secretary Must be PCSIR employee
for Secretary" list

If "Time Given" selected, "Please provide

Agenda Flag Flag field
deadline must be entered deadline"

Buttons, Links and Icons

Other Visibl Enabled vs
Button Label OnClick Event Navigate To
Event e Displayed

Save Committee
Save committee data - Yes Enabled
Committee List

Assign selected
Assign
members to - Yes Enabled -
Members
committee

Schedule Save meeting

- Yes Enabled -
Meeting schedule and notify

Upload
Upload selected files - Yes Enabled -
Documents

Generate Generate editable

- Yes Enabled -
MoM minutes template

Publish Finalize and send to

- Yes Enabled -
Minutes all members

Generate printable Print

Print Agenda - Yes Enabled
format Preview

Risk Assessment
Risk Impact Mitigation Strategy

Role misassignment High Enforce validation to restrict

Chairperson/Secretary selection only from
 valid employee pool

Mediu Integrate with fail-safe notification queue

Missed notifications
m system

Data inconsistency in Link each agenda item with corresponding

High
agenda/minutes MoM entry to ensure traceability

Unauthorized access High Implement RBAC and session audits

Updated Non-Functional Requirements

 Performance: Response time < 3 seconds for all committee
operations

 Scalability: Support for 100+ concurrent committee sessions

 Availability: 99.5% system uptime

 Security: RBAC, encrypted transmission (HTTPS), audit logging

 Usability: Mobile-friendly access, intuitive UI

 Maintainability: Modular codebase for easy enhancements

 Compliance: GDPR/Data Protection Compliance for staff data

Sub Module: The Internal and External Audit Management System
Overview
The Internal and External Audit Management System module aims to
digitalize and streamline the audit planning, scheduling, execution, and
reporting processes across all PCSIR centers. This system will ensure robust
quality assurance, real-time visibility, and compliance through seamless
handling of internal and external audits.

Software Requirement Analysis

 A centralized web-based system integrated with PCSIR ERP.

 Role-based access control for Auditors, Auditees, and Admins.

 Scheduling and calendar integration for audit planning.

 Customizable audit templates and logs.

 Capability to attach reports, recommendations, and findings.

 Secure archival and versioning of audit records.

 Automatic generation of log sheets and notifications.

High-Level Architecture
 Frontend: Angular/React web-based interface for Audit Planning and
Reporting.

 Backend: RESTful APIs using Node.js/Django.

 Database: PostgreSQL or MS SQL Server.

 Authentication: OAuth2.0 / PCSIR SSO.

 Integration: HRMS for auditor details, Document Management

System for report attachments.

Sub Module Name: Internal and External Audit Management

Purpose/Description

This sub-module facilitates PCSIR to create, manage, and record both

internal and external audits. It allows for defining audit types, scheduling
audits by center, recording findings, non-conformances, and
recommendations, and automatically generating audit logs.
Use Cases
Use Case ID: AUD-001

Use Case Name: Plan an Audit Primary Actor(s): Quality Manager, Audit
Administrator Pre-conditions: User must be authorized and logged in.
Post-conditions: Audit is scheduled and saved in the system. Main
Success Scenario:

1. User selects "New Audit"

2. Fills audit type, date range, and auditor list

3. Enters schedule by center and time

4. Submits and confirms entry Alternative Path: If mandatory fields are

missing, system prompts error. Business Rules: Dates should not
overlap for same center.

Use Case ID: AUD-002

Use Case Name: Enter Audit Report Primary Actor(s): Auditor, Audit
Admin Pre-conditions: Audit must be scheduled. Post-conditions: Audit
report is saved and available for review. Main Success Scenario:

1. Auditor opens audit record

2. Selects center, enters contact person

3. Fills findings, non-conformances, conclusions

4. Saves report Alternative Path: System prevents submission without

filling all required fields. Business Rules: Data fields are text-rich with
possible attachments.

Use Case ID: AUD-003

Use Case Name: Generate Audit Log Sheet Primary Actor(s): Audit Admin
Pre-conditions: Audit report is completed Post-conditions: Log sheet PDF
is generated Main Success Scenario:

1. Admin clicks on "Generate Log Sheet"

2. System fetches audit data

 3. Log sheet is formatted and exported Alternative Path: No audit found
= No log generation Business Rules: Log sheet includes header,
auditor names, schedules

Screen/UI Design
 Screens to include:

o Audit Planning Form

o Audit Schedule Calendar View

o Audit Report Entry Form

o Audit Log Sheet Generator

Field Level Specifications

Field Mandato Data Value Default
Field Label Comments
Type ry Type Set Value

Dropdow Internal,
Audit Type Yes String None Lookup field
n External

DatePicke
Audit Start Date Yes Date — None —
r

Must be
DatePicke
Audit End Date Yes Date — None after start
r
date

Multi- From Integrated

List of Auditors Yes List —
Select HRMS with HRMS

Center Name Dropdow Center

Yes String None —
(Schedule) n Master

DatePicke
Date Yes Date — None —
r

TimePicke
Start Time Yes Time — None —
r

End Time TimePicke Yes Time — None —

 r

Contact Person Text Box Yes String — — —

Multiple
List of Non-
Text Area No Text — — entries
Conformances
allowed

Multiple
List of Findings Text Area No Text — — entries
allowed

List of Multiple
Recommendation Text Area No Text — — entries
s allowed

Business Rules and Dependencies

Validation / Business Data
Field Label Error Messages
Rules Dependencies

Start < End; End not "Audit End Date must be

Audit Dates —
before Start after Start"

Center One audit per center "Center already

Calendar
Schedule per day scheduled"

Contact Center
Cannot be blank "Enter contact person"
Person selection

Buttons, Links and Icons

Other Visibl Enable
Button Label OnClick Event Navigate To
Event e d

Save Audit Save audit header

— Yes Yes Summary Page
Plan & schedule

Generate Log Create audit log

— Yes Yes Download link
Sheet PDF
Submit Audit Confirmation
Save report data — Yes Yes
Report message popup

Risk Assessment
 Risk: Incomplete or unscheduled audits may lead to compliance
failures.

 Mitigation: Mandatory fields and validations, automated log

generation.

 Likelihood: Medium

 Severity: High

 Controls: Field validation, error alerts, data locking post-submission.

Updated Non-Functional Requirements

 Performance: Each operation (plan, save, generate) must be
completed under 3 seconds.

 Availability: 99.9% uptime expected.

 Security: Role-based access with encryption for reports.

 Scalability: Able to handle audits across all PCSIR centers.

 Audit Logs: All actions logged with user ID and timestamp.

Sub Module: The Corrective Actions Request (CAR) system

Overview
The Corrective Actions Request (CAR) system is a sub-module within the
broader Audit Management System of PCSIR ERP. It is designed to facilitate,
record, and track corrective measures following audits, complaints, feedback,
and other internal non-conformances. The CAR sub-module ensures
transparency, accountability, and structured handling of issues requiring
resolution, through multi-level workflow and real-time tracking.

Software Requirement Analysis

The system must:

 Allow input and classification of corrective actions by various triggering

sources (internal audits, complaints, etc.)

 Enable the QMR to electronically route CAR forms to relevant centers

 Provide a structured form capturing root cause and corrective action

 Support a defined workflow: Issuance > Assignment > Resolution >

Review > Closure

 Allow QMR to generate CAR Logs automatically from the submitted and
processed forms

 Ensure status tracking (Open, In Progress, Rejected, Closed) of each

CAR

High-Level Architecture
 Frontend: Web-based interface (HTML5, JavaScript,
Bootstrap/Vue.js/React)

 Backend: RESTful API services (Node.js/.NET Core/Python Flask)

 Database: Relational (PostgreSQL or MS SQL Server)

 Authentication: PCSIR Single Sign-On (SSO) Integration

  Workflow Engine: Rule-based engine to handle routing and status
update logic

 Document Management: Central repository for all CAR-related

documents

Purpose / Description
The purpose of this sub-module is to automate and track the lifecycle of
Corrective Action Requests initiated from audits, complaints, or risk
assessments. It ensures each request is assigned, addressed, reviewed, and
archived efficiently, providing traceability and reports.

Use Cases
Use Case 1

 Use Case ID: CAR-001

 Use Case Name: Create CAR Form

 Primary Actor(s): Reporting Person (Auditor, QMR)

 Pre-conditions: Login and authorized access

 Post-conditions: CAR saved in draft or submitted status

 Main Success Scenario: The user selects audit type, fills out CAR
form, and submits

 Alternative Path: Form saved as draft for future completion

 Business Rules: Unique CAR No. must be generated, mandatory fields

must be validated

Use Case 2

 Use Case ID: CAR-002

 Use Case Name: Assign CAR to Staff

 Primary Actor(s): Head of Center

 Pre-conditions: CAR must be received by center

 Post-conditions: CAR assigned to a staff member

  Main Success Scenario: Head of Center assigns form and system
captures the date

 Alternative Path: Assignment is rejected and sent back to QMR

 Business Rules: Assignment only allowed to PCSIR staff in a

predefined role list

Use Case 3

 Use Case ID: CAR-003

 Use Case Name: Submit Corrective Action

 Primary Actor(s): Assigned Staff Member

 Pre-conditions: Assigned CAR must be visible

 Post-conditions: Root Cause and Corrective Action submitted

 Main Success Scenario: Assignee submits form for review by Head of

Center

 Alternative Path: Action saved as draft

 Business Rules: Both Root Cause and Action fields must be filled
before submission

Use Case 4

 Use Case ID: CAR-004

 Use Case Name: Review and Close CAR

 Primary Actor(s): QMR, Head of Center

 Pre-conditions: Corrective action submitted

 Post-conditions: CAR marked as closed or returned

 Main Success Scenario: Action accepted and closed by QMR

 Alternative Path: Action rejected and loopback to assignee

 Business Rules: QMR final approval required before closure

Screen/UI Design
(To be attached in prototype - includes CAR Form Entry Screen, Assignment
Panel, Status Dashboard, and CAR Log Generator View)

Field Level Specifications

Field Field Mandato Data Default
Value Set Comments
Label Type ry Type Value

Auto-
Text Box Strin System Unique
CAR No. Yes generate
(Auto) g generated identifier
d

Lookup to
Reporting Dropdow Strin PCSIR Current
Yes employee
Person n g Employees user
directory

Based on
Designatio Strin Auto-
Text Box Yes N/A reporting
n g fetched
person

Date Current
Date Yes Date N/A System date
Picker date

Internal,
External, Risk,
Dropdow Complaint, Must be
Audit Type Yes Enum None
n Internal Non- selected
Compliance,
Other

Validated
Assigned Dropdow Strin
Yes PCSIR Centers None against center
to Center n g
list

Target Date Yes Date N/A None Deadline for

Date Picker closure

Priority Dropdow Normal, Urgent, Risk-based

Yes Enum Normal
Level n Non-Significant evaluation

To be entered
Root Cause Text Area Yes Text N/A None
by assignee

Must be
Corrective validated
Text Area Yes Text N/A None
Action before
submission

Business Rules and Dependencies

Validation /
Field Label Error Messages Data Dependencies
Business Rules

"Duplicate CAR
CAR No. Must be unique Auto-generation logic
Number!"

"Audit Type is
Audit Type Required None
mandatory"

Reporting Must exist in staff "Invalid Reporting Pull designation from

Person list Person" HRMS

"Target Date cannot Related to system

Target Date Must be in future
be in the past" date

Corrective Required if Root "Corrective Action is Dependent on Root

Action Cause entered required" Cause field

Buttons, Links and Icons

Button Enabled vs
OnClick Event Other Event Visible Navigate To
Label Displayed

Saves
Save Enabled
incomplete N/A Yes None
Draft always
form

Submit Sends form to Confirmation Condition Enabled when Dashboard

to Center center Dialog al form complete

Enabled for
Assign Opens staff Auto-fill Condition Assignment
Center Head
CAR list designation al Panel
only

Submit root
Submit Condition Enabled for
cause + N/A Dashboard
Action al assignee
action

Close QMR closes Condition Enabled after CAR Log

N/A
CAR form al acceptance Generator

Risk Assessment
 Data Integrity: Ensuring no overwriting or deletion of submitted
forms.

 Workflow Failure: Failure in email/notification routing to centers or

QMR.

 Auditability: System must maintain version control and timestamps

of each action.

Updated Non-Functional Requirements

 Performance: Response time for CAR submission, routing, and
retrieval must be <2 seconds

 Scalability: Support 500+ simultaneous CAR forms across all PCSIR

centers

 Security: Role-based access control to restrict view/edit permissions

 Usability: Interface designed for clarity and step-wise submission

 Portability: Responsive design compatible with desktop, tablet,

mobile

 Maintainability: Modular structure for easy update of audit types and

center mappings

 Audit Trail: All actions must be timestamped and user-tagged for

traceability