nok/wms-app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(sdlc): reformat work products to audited reference layout

Browse Source
This commit is contained in:
Thanakorn
2026-09-09 08:09:54 +07:00
parent f2da2f51b5
commit 9553d94ec6
209 changed files with 8063 additions and 5762 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sdlc/2-SI Process (12 Work Product)/11.Software Requirements specification (SRS)/200-WMS-26-001-00 Software Requirements 25690225 V1.0 NoC.md
+112
View File
@@ -0,0 +1,112 @@
# Software Requirements
<!-- footer: SRS -->
| Document No | Software Requirements | Release, Version, By: | 25690225 V1.0 NoC |
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
| Project Code | 200-WMS-26-001-00 |
| Title | เอกสารบันทึกและสรุปความต้องการซอฟต์แวร์ (Software Requirements Specification) |
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
## วัตถุประสงค์ (Objectives)
เพื่อแปลงความต้องการของลูกค้าที่ได้รับอนุมัติแล้วให้เป็นความต้องการเชิงเทคนิคของซอฟต์แวร์ ครอบคลุมมาตรฐาน โครงสร้าง ส่วนประกอบ ความสัมพันธ์ ประสิทธิภาพ ส่วนเชื่อมต่อ ความปลอดภัย ฐานข้อมูล และการจัดการข้อผิดพลาด เพื่อใช้เป็นเอกสารอ้างอิงหลักในการออกแบบระบบ พัฒนา และทดสอบ
## ผู้มีส่วนได้ส่วนเสีย (Stakeholders)
| ลำดับ | ชื่อ | หน่วยงาน/ตำแหน่ง | บทบาท |
| :---: | --- | --- | --- |
| 1 | คุณเสรี วิริยะสกุลธรณ์ | ผู้บริหาร (CEO) | Project Sponsor อนุมัติความต้องการ |
| 2 | คุณอภิรัชช์ สุภัทรประทีป | ผู้จัดการโครงการ | บริหารจัดการโครงการ |
| 3 | คุณนพพงษ์ เจริญสุข | นักวิเคราะห์ระบบ | จัดทำและควบคุมความต้องการซอฟต์แวร์ |
| 4 | คุณธนกร สถิตวิทยากุล | นักพัฒนาระบบ | พัฒนาระบบตามความต้องการ |
| 5 | คุณปริญ งามขำ | ผู้ทดสอบระบบ | จัดทำ Test Case จากความต้องการ |
## ความต้องการซอฟต์แวร์ (Software Requirements)
| ID | Topic | Result* | Remark |
| --- | --- | :---: | --- |
| SR01: Standards of Software | | | |
| SR01:001 | ระบบต้องพัฒนาและจัดทำเอกสารให้สอดคล้องกับมาตรฐาน ISO/IEC 29110 Basic Profile และแนวปฏิบัติ Secure Coding | A | CR12:004, CR14:001–CR14:003, CR09:003, CR10:004, CR11:001–CR11:004 |
| SR01:002 | ระบบต้องใช้เทคโนโลยี PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js (Socket.IO, pm2) | A | CR04:004, CR12:001 |
| SR01:003 | ระบบต้องติดตั้งบน Linux Server ได้ทั้งแบบ Manual (setup.php) และ Docker Compose (php-apache, mariadb, node/pm2) | A | CR07:001, CR10:001, CR10:002, CR08:001, CR08:002, CR13:003 |
| SR01:004 | รหัสผ่านผู้ใช้ต้องเข้ารหัสด้วย bcrypt (PASSWORD_BCRYPT) และไม่เก็บหรือบันทึกเป็นข้อความธรรมดา | A | CR12:003 |
| SR01:005 | ค่าตั้งค่าและความลับ (app/config.php, .env) ต้องถูกยกเว้นจาก Source Control และสร้างขึ้นตอนติดตั้ง | A | CR06:002, CR09:002, CR10:003 |
| SR01:006 | แอปพลิเคชันและงานตามกำหนดเวลาต้องใช้เขตเวลา Asia/Bangkok | A | CR07:002 |
| SR02: Software Structure Considerations | | | |
| SR02:001 | ระบบต้องเป็น Web-based Application แบบหลายหน้า (Multi-page PHP) | A | CR04:001 |
| SR02:002 | ส่วนติดต่อผู้ใช้ต้องเป็น Responsive Design รองรับ Desktop / Tablet / Mobile | A | CR05:001, CR07:003 |
| SR02:003 | ตรรกะทางธุรกิจต้องจัดเป็น Manager/Service Classes ที่เรียกใช้จาก Page Controller แยกจากส่วนแสดงผล | A | CR09:001 |
| SR02:004 | การเข้าถึงข้อมูลต้องผ่าน Manager Classes ไม่กระจาย SQL ในหน้าเพจ | A | CR09:001 |
| SR02:005 | ระบบต้องติดตั้งเป็น Container Stack ผ่าน Docker Compose ได้ นอกเหนือจากการติดตั้งแบบ Manual | A | CR10:002 |
| SR03: Software Elements | | | |
| SR03:001 | โมดูลผู้ใช้งานและสิทธิ์: ลงทะเบียน, Onboarding, เข้าสู่ระบบ, บทบาท Owner/Admin/Staff/Viewer, สิทธิ์แอปพลิเคชัน (app/login/, UserManager, PasswordManager, PasswordResetManager) | A | CR01:001–CR01:004 |
| SR03:002 | โมดูลตั้งค่าบริษัท: ข้อมูลบริษัท, SMTP, การตั้งค่าระบบ (app/setting/, CompanyProfileManager, CompanySettingManager, SmtpManager) | A | CR01:004, CR03:005 |
| SR03:003 | โมดูลข้อมูลหลัก: คลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ผู้ติดต่อ (app/inventory/, app/contact/, WarehouseManager, ProductManager, ContactManager) | A | CR01:005, CR01:006 |
| SR03:004 | โมดูลควบคุมสินค้าคงคลัง: รับเข้า, จ่ายออก, โอนย้าย, Lot/Serial/Expiry, บาร์โค้ด, แนบไฟล์ (app/ics/, StockManager, StockSourceManager, BarcodeManager, FileUploader) | A | CR01:007–CR01:012, CR01:019, CR05:005 |
| SR03:005 | โมดูลขาย: ใบเสนอราคา, ใบสั่งขาย, ใบแจ้งหนี้, ใบรับคืน/ใบลดหนี้ (app/order/, app/revenue/, QuotationManager, OrderManager, InvoiceManager, ReturnManager) | A | CR01:013 |
| SR03:006 | โมดูลจัดซื้อ: ใบขอซื้อ, ใบสั่งซื้อ, ใบแจ้งหนี้ซื้อ, ใบคืนสินค้าผู้ขาย (app/po/, PurchaseRequestManager, PurchaseOrderManager, SupplierReturnManager) | A | CR01:014 |
| SR03:007 | โมดูลการเงิน: ใบวางบิลรับ, ใบเสร็จ, ใบวางบิลจ่าย, ใบสำคัญจ่าย (app/finance/, ReceiptBillingManager, ReceiptManager, PaymentBillingManager, PaymentManager) | A | CR01:015 |
| SR03:008 | โมดูลบัญชี: ผังบัญชี, แผนก, สูตรบัญชี, สมุดรายวัน, บัญชีแยกประเภท (app/accounting/, app/journal/, PostingManager) | A | CR01:016 |
| SR03:009 | โมดูลรายงานและแดชบอร์ด: รายงานสต๊อก, รายงานการเงิน, แดชบอร์ด (app/reports/, app/dashboard/, app/ac_dashboard/, ReportManager, EtlStockManager) | A | CR01:011, CR01:017, CR01:020 |
| SR03:010 | โมดูลควบคุมเอกสาร: ออกเลขที่เอกสาร, วงจรชีวิต/สถานะ, ประวัติรายการ (DocumentNumberManager, BatchActionManager) | A | CR01:018, CR01:023 |
| SR03:011 | บริการแจ้งเตือนและงานตามกำหนดเวลา: Socket.IO และ Scheduler (nodejs/server.js, nodejs/scheduler.js, app/cron/) | A | CR01:021, CR01:022 |
| SR04: Software Elements Relationship | | | |
| SR04:001 | ทุกโมดูลปฏิบัติการต้องเข้าถึงได้ผ่านการยืนยันตัวตนและการตรวจสิทธิ์ของโมดูลผู้ใช้งานเท่านั้น | A | CR01:002, CR01:024, CR04:003, CR05:002 |
| SR04:002 | โมดูลขาย จัดซื้อ และการเงิน ต้องบันทึกผลกระทบต่อสต๊อกและ GL ผ่านโมดูลคลังสินค้าและบัญชี ไม่ทำซ้ำตรรกะ | A | CR01:013–CR01:016 |
| SR04:003 | โมดูลรายงานต้องอ่านข้อมูลภายใต้ขอบเขตบริษัท/คลังที่โมดูลข้อมูลหลักและคลังสินค้าบังคับใช้ | A | CR01:024, CR08:004 |
| SR04:004 | บริการ Node.js ต้องรับเหตุการณ์จากแอปพลิเคชัน PHP ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret เท่านั้น | A | CR01:021, CR03:003 |
| SR04:005 | ทุกโมดูลที่สร้างเอกสารธุรกิจต้องเรียกใช้โมดูลควบคุมเอกสารเพื่อออกเลขที่เอกสาร | A | CR01:018 |
| SR05: Performance Characteristics | | | |
| SR05:001 | งานประจำวัน (เปิดหน้าจอ, ค้นหา, สร้างเอกสาร) ต้องเสร็จภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | A | CR02:001 |
| SR05:002 | ยอดสรุปสต๊อก/GL/แดชบอร์ดต้องคำนวณล่วงหน้าตามกำหนดเวลา (etl_stock_summary, etl_gl_summary) | A | CR02:002, CR01:022, CR08:005 |
| SR05:003 | ระบบต้องรองรับปริมาณข้อมูลและผู้ใช้พร้อมกันตามที่ตกลงสำหรับสภาพแวดล้อมใช้งานจริง | A | CR02:003 |
| SR05:004 | ระบบต้องมี Health Check ทุก 5 นาที และแจ้งเตือนผู้ดูแลเมื่อล้มเหลวติดต่อกัน 2 ครั้ง | A | CR08:003 |
| SR06: Software Interfaces | | | |
| SR06:001 | แอปพลิเคชัน PHP ต้องเชื่อมต่อฐานข้อมูล MariaDB 2 ฐาน: wms (ผู้ใช้/บริษัท) และ wms2 (คลัง/บัญชี) | A | CR03:001 |
| SR06:002 | ระบบต้องใช้งานได้บน Chrome, Edge และ Firefox รุ่นปัจจุบัน | A | CR03:002 |
| SR06:003 | ระบบต้องรองรับ Mobile/Tablet Browser ผ่าน Responsive UI | A | CR07:003 |
| SR06:004 | แอปพลิเคชัน PHP ต้องส่งเหตุการณ์ไป Node.js ผ่าน HTTP Endpoint ภายใน (NODE_EMIT_URL + NODE_EMIT_SECRET) และส่งอีเมลผ่าน SMTP ต่อบริษัท | A | CR03:003, CR03:005 |
| SR06:005 | Browser ต้องเชื่อมต่อ Socket.IO Endpoint (NODE_PUBLIC_URL) เพื่อรับการแจ้งเตือน | A | CR03:004 |
| SR07: Security Characteristics | | | |
| SR07:001 | การเชื่อมต่อในสภาพแวดล้อมใช้งานจริงต้องผ่าน HTTPS/TLS | A | CR06:001 |
| SR07:002 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | A | CR06:003, CR14:004 |
| SR07:003 | ระบบต้องอนุญาต Session ที่ใช้งานอยู่เพียงหนึ่งต่อบัญชี (บล็อก Concurrent Login) | A | CR06:006 |
| SR07:004 | ระบบต้องป้องกัน SQL Injection และ Cross-Site Scripting ทั้งด้านรับข้อมูลและแสดงผล | A | CR06:005 |
| SR07:005 | RBAC (Owner/Admin/Staff/Viewer) ต้องบังคับใช้ที่ฝั่งเซิร์ฟเวอร์ ไม่ใช่เพียงการซ่อนเมนู | A | CR06:004 |
| SR08: Database Design Requirements | | | |
| SR08:001 | ฐานข้อมูล wms: user, company_list, company_map_user, company_setting, company_smtp, company_usage, whitelist | A | CR01:001–CR01:004, CR04:002 |
| SR08:002 | ตารางข้อมูลหลัก (wms2): md_warehouse, md_storage, md_bin, md_product, md_product_category, md_contact, md_contact_type, md_account, md_account_formula, md_account_formula_item, md_department, md_barcode, md_sku_barcode_label, md_lot, md_lock_operation | A | CR01:005, CR01:010, CR01:016 |
| SR08:003 | ตารางรายการ (td_*): td_stock, td_order/_item, td_quotation/_item, td_invoice/_item, td_return/_item, td_purchase_request/_item, td_purchase_order/_item, td_supplier_return/_item, td_receipt/_item, td_receipt_billing/_item, td_payment/_item, td_payment_billing/_item, td_gl/td_gl_item, td_batch_action, td_bin_log | A | CR01:007–CR01:018 |
| SR08:004 | ตารางสรุปยอดและควบคุมเอกสาร: etl_stock_summary, etl_gl_summary, document_number_sequences, document_types, schema_migrations | A | CR01:018, CR01:022, CR09:004 |
| SR08:005 | ตารางทั้งหมดต้องสร้างซ้ำได้ในสภาพแวดล้อมใหม่ผ่าน setup.php โดยไม่ต้องแก้ Schema ด้วยมือ | A | CR10:001, CR09:004 |
| SR09: Error Handling and Recovery Attributes | | | |
| SR09:001 | การลบ ยกเลิก หรือ Void เอกสารควบคุมต้องมี Confirm Dialog | A | CR05:004, CR01:023 |
| SR09:002 | ข้อผิดพลาดต้องแสดงข้อความที่ผู้ใช้เข้าใจได้แทน Fatal Error | A | CR05:003, CR13:004 |
| SR09:003 | การเปลี่ยนแปลงที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction และป้องกันยอดติดลบ/ซ้ำ | A | CR13:001, CR13:002, CR01:008 |
## Remark
- \* Result : A = Accepted, U = Unaccepted, N/A = Not Applicable
- ช่อง Remark แสดงรหัสความต้องการของลูกค้า (Customer Requirements) ที่เป็นที่มาของความต้องการซอฟต์แวร์แต่ละรายการ
- ความต้องการซอฟต์แวร์ที่ไม่มีที่มาจากความต้องการของลูกค้าต้องผ่าน Change Report ก่อนถือเป็นข้อผูกพัน
## ผู้จัดทำเอกสาร (Secretary)
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
## ผู้ตรวจสอบเอกสาร (Reviewer)
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
## ผู้อนุมัติ (Approval)
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
sdlc/2-SI Process (12 Work Product)/11.Software Requirements specification (SRS)/200-WMS-26-001-00 Software Requirements Specification 25690817 V1.0.md
-144
View File
@@ -1,144 +0,0 @@
# Software Requirements Specification (SRS)
| Document field | Value |
|---|---|
| Document | Software Requirements Specification |
| Project | BRN WMS |
| Project code | 200-WMS-26-001-00 |
| Title | Software Requirements Recording and Summary Document (Software Requirements Specification) |
| Project period | 05/01/26–24/08/26 |
| Release | 17/08/26 V1.0 |
| Standard | ISO/IEC 29110 Basic Profile |
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
| Recorder | Thanakorn Sathitwitayakul — Developer |
| Status | Final — reformulates the approved Customer Requirements into technical software requirements |
## Objective
To restate the approved Customer Requirements as technical software requirements — standards, structure, elements, relationships, performance, interfaces, security, database, and error handling — so they can drive Software Design, Software Components, Test Cases, and Traceability.
## Basis and scaling note
The example reference package (`200-TAS-25-001-00`) enumerates one SR row per screen/CRUD action because that project is a small brochure site with ~6 modules. BRN WMS is a multi-domain warehouse/ERP system with 31 backend manager/service classes plus one shared trait (32 files) and 17 top-level application areas (Section 3 below). Reproducing CRUD-button-level granularity would create hundreds of near-duplicate rows without adding traceability value. This SRS therefore keeps the same category structure (SR01–SR09) as the example but sets granularity at the same level already approved in the Customer Requirements (FR-001–FR-024, NFR-001–NFR-010), one SR row per requirement or tight requirement group. Every SR row's Remark links back to its Customer Requirements ID.
## SR01: Standards of Software
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR01:001 | The system shall be developed in alignment with ISO/IEC 29110 Basic Profile documentation and traceability practice. | A | NFR-009 |
| SR01:002 | The system shall use PHP 8+ for the application layer, MySQL/MariaDB for data storage, and Node.js for real-time/scheduled services. | A | NFR-008 |
| SR01:003 | The system shall be deployable on a Linux server, either via manual LAMP-style installation (`setup.php`) or the provided Docker Compose stack (php-apache, mariadb, node/pm2). | A | NFR-004 |
| SR01:004 | User passwords shall be hashed with `PASSWORD_BCRYPT` (PHP default cost factor); plaintext passwords shall never be stored or logged. | A | NFR-002 |
| SR01:005 | Configuration secrets (`app/config.php`, `.env`) shall be excluded from source control and generated at deployment time. | A | NFR-001 |
## SR02: Software Structure Considerations
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR02:001 | The system shall be a browser-based, multi-page PHP web application (not a single native client). | A | FR-002, operational context |
| SR02:002 | The user interface shall be responsive across desktop and warehouse-floor (tablet/mobile) viewports. | A | NFR-005 |
| SR02:003 | Application logic shall be organized as PHP manager/service classes invoked by page controllers, separated from page presentation. | A | NFR-007 |
| SR02:004 | Data access shall be encapsulated through manager classes rather than inline SQL scattered across pages, where practical. | A | NFR-007 |
| SR02:005 | The system shall be deployable as a container stack (Docker Compose: php-apache, mariadb, node/pm2) in addition to manual installation. | A | NFR-004 |
## SR03: Software Elements (Modules)
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR03:001 | Identity/access module: registration, onboarding, authentication, role (Owner/Admin/Staff/Viewer) and application-access management (`app/login/`, `UserManager`, `PasswordManager`, `PasswordResetManager`). | A | FR-001–FR-004 |
| SR03:002 | Company/system configuration module: company profile, SMTP, system settings (`app/setting/`, `CompanyProfileManager`, `CompanySettingManager`, `SmtpManager`). | A | FR-004 |
| SR03:003 | Master data module: warehouses, storage/bins, product categories, products, contacts (`app/inventory/`, `app/contact/`, `WarehouseManager`, `ProductManager`, `ContactManager`). | A | FR-005, FR-006 |
| SR03:004 | Inventory/warehouse operations module: stock-in, stock-out, transfer, lot/serial/expiry, barcode labels (`app/ics/`, `StockManager`, `StockSourceManager`, `BarcodeManager`). | A | FR-007–FR-012 |
| SR03:005 | Sales module: quotation, order, invoice, return, credit note (`app/order/`, `app/revenue/`, `QuotationManager`, `OrderManager`, `InvoiceManager`, `ReturnManager`). | A | FR-013 |
| SR03:006 | Purchasing module: purchase request, purchase order, purchase invoice, supplier return (`app/po/`, `PurchaseRequestManager`, `PurchaseOrderManager`, `SupplierReturnManager`). | A | FR-014 |
| SR03:007 | Finance module: receipt billing, receipts, payment billing, payments (`app/finance/`, `ReceiptBillingManager`, `ReceiptManager`, `PaymentBillingManager`, `PaymentManager`). | A | FR-015 |
| SR03:008 | Accounting module: chart of accounts, departments, account formulas, journals, general ledger (`app/accounting/`, `app/journal/`, `PostingManager`). | A | FR-016 |
| SR03:009 | Reporting/dashboard module: stock, financial, and operational reports and dashboards (`app/reports/`, `app/dashboard/`, `app/ac_dashboard/`, `app/revenue/`, `app/expense/`, `ReportManager`). | A | FR-011, FR-017, FR-020 |
| SR03:010 | Document-control module: controlled document numbering and lifecycle/status (`DocumentNumberManager`). | A | FR-018 |
| SR03:011 | Notification/scheduler services: Socket.IO notifications and scheduled aggregate/alert jobs (`nodejs/server.js`, `nodejs/scheduler.js`, `app/cron/`, `EtlStockManager`). | A | FR-021, FR-022 |
## SR04: Software Elements Relationship
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR04:001 | Every operational module shall be reachable only through the identity/access module's authentication and role/application-access checks. | A | FR-002, FR-024 |
| SR04:002 | Sales, purchasing, and finance modules shall post related stock and general-ledger effects through the inventory and accounting modules rather than duplicating their logic. | A | FR-013–FR-016 |
| SR04:003 | The reporting module shall read from, and never bypass, the authorization scope enforced by the master-data and inventory modules (company/warehouse isolation). | A | FR-024 |
| SR04:004 | The notification/scheduler services shall relay events from the PHP application through a secret-protected internal endpoint, not directly from the browser to internal services. | A | NFR-002 |
| SR04:005 | Document-control numbering shall be invoked by every module that creates a controlled business document (order, invoice, receipt, payment, journal, etc.). | A | FR-018 |
## SR05: Performance Characteristics
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR05:001 | Representative daily operations (screen loads, list/search, document creation) shall complete within practical operational time on the agreed environment. | A | NFR-006 |
| SR05:002 | Stock, GL, and dashboard aggregates shall be maintained on a schedule (ETL/summary tables) so dashboard and report queries do not require full recomputation on each request. | A | NFR-006, FR-022 |
| SR05:003 | The system shall support the representative concurrent-user and data-volume levels agreed for the production environment. | A | NFR-006 |
## SR06: Software Interfaces
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR06:001 | The PHP application shall connect to two MariaDB databases: `wms` (identity/company) and `wms2` (WMS/accounting). | A | Operational context, SR08 |
| SR06:002 | The application shall be usable on current standards-based browsers (Chrome, Edge, Firefox). | A | NFR-008 |
| SR06:003 | The application shall support mobile/tablet browser access through the responsive UI. | A | NFR-005 |
| SR06:004 | The PHP application shall relay events to the Node.js service over an internal, secret-protected HTTP endpoint (`NODE_EMIT_URL`, `NODE_EMIT_SECRET`). | A | NFR-002 |
| SR06:005 | The browser shall connect to the Node.js Socket.IO endpoint (`NODE_PUBLIC_URL`) for real-time notification delivery. | A | FR-021 |
## SR07: Security Characteristics
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR07:001 | Production deployment shall terminate the client connection over HTTPS/TLS. | A | NFR-001 |
| SR07:002 | Server-side actions shall validate input and enforce authentication, authorization, and tenant (company/warehouse) scope. | A | NFR-002 |
| SR07:003 | The system shall enforce single active-session (block concurrent login) behavior per the implemented login policy. | A | NFR-002 |
| SR07:004 | The system shall protect against SQL injection and cross-site scripting in server-side input handling and output rendering. | A | NFR-002 |
| SR07:005 | Role-based access control (Owner/Admin/Staff/Viewer) shall restrict server-side actions, not only UI visibility. | A | FR-002, NFR-002 |
## SR08: Database Design Requirements
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR08:001 | Identity/company database (`wms`): `user`, `company_list`, `company_map_user`, `company_setting`, `company_smtp`, `company_usage`, `whitelist`. | A | FR-001–FR-004 |
| SR08:002 | Master-data tables in the WMS database (`wms2`): `md_warehouse`, `md_storage`, `md_bin`, `md_product`, `md_product_category`, `md_contact`, `md_contact_type`, `md_account`, `md_account_formula`, `md_account_formula_item`, `md_department`, `md_barcode`, `md_sku_barcode_label`, `md_lot`, `md_lock_operation`. | A | FR-005, FR-006, FR-010, FR-012, FR-016 |
| SR08:003 | Transaction-data tables (`td_*`): `td_stock`, `td_order`/`td_order_item`, `td_quotation`/`_item`, `td_invoice`/`_item`, `td_return`/`_item`, `td_purchase_request`/`_item`, `td_purchase_order`/`_item`, `td_supplier_return`/`_item`, `td_receipt`/`_item`, `td_receipt_billing`/`_item`, `td_payment`/`_item`, `td_payment_billing`/`_item`, `td_gl`/`td_gl_item`, `td_batch_action`, `td_bin_log`. | A | FR-007–FR-018 |
| SR08:004 | Aggregate/document-control tables: `etl_stock_summary`, `etl_gl_summary`, `document_number_sequences`, `document_types`, `schema_migrations`. | A | FR-018, FR-022 |
| SR08:005 | All tables created by the delivered `setup.php` shall be reproducible in a fresh environment without manual schema editing. | A | NFR-004 |
## SR09: Error Handling and Recovery Attributes
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR09:001 | Destructive actions (delete, void, cancel of a controlled record) shall require an explicit confirmation step. | A | Usability practice; not a numbered CR/FR but implemented consistently across modules |
| SR09:002 | Errors shall present a usable message to the user rather than an unhandled fatal error, for the primary operational workflows. | A | NFR-006 |
| SR09:003 | Related database changes (e.g., document + stock + GL postings) shall be transactional where required to avoid partial/inconsistent updates. | A | NFR-003 |
Remark:
- \* Result: A = Accepted (implemented and evidenced in the current codebase), U = Unaccepted, N/A = Not Applicable. No SR row in this document is marked A without an identifiable implementing module, class, or table.
- This SRS restates already-approved Customer Requirements; it does not introduce new scope. Any SR row without a direct FR/NFR precedent must be raised through the Change Report before being treated as binding.
## Approval
### Prepared by
Name: Thanakorn Sathitwitayakul
Role: Developer
Signature: ______________________________________________
Date: ___________________________________________________
### Reviewed by
Name: Apirach Supattaratpateep
Role: Project Manager
Signature: ______________________________________________
Date: ___________________________________________________
### Reviewed and authorized by
Name: Seri Viriyasakultorn
Project roles: Project Sponsor / Customer Representative / Authorized Approver
Position: Managing Director
Company: B.R.N. Enterprise Co., Ltd.
Signature: ______________________________________________
Date: ___________________________________________________