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 
Replace the PHP/Markdown seeding with a data-driven generator in
scripts/sdlc-seed and regenerate all 59 work products.
This commit is contained in:
Thanakorn
2026-09-09 08:09:54 +07:00
parent 758922f5c4
commit 087e7b3958
209 changed files with 8063 additions and 5762 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sdlc/1-PM Process (10 Work Product)/2.Project Plan/3-Customer Requirement/200-WMS-26-001-00 Customer Requirements 25690112 V1.0 Final.md
-276
View File
@@ -1,276 +0,0 @@
# Customer Requirements
| Document field | Value |
|---|---|
| Document | Customer Requirements |
| Project | BRN WMS |
| Project code | 200-WMS-26-001-00 |
| Title | Document Recording and Summarizing Customer Requirements |
| Project period | 05/01/26–24/08/26 |
| Release | 12/01/26 V1.0 Final |
| Standard | ISO/IEC 29110 Basic Profile |
| Project Manager | Apirach Supattaratpateep |
| System Analyst | Noppong Chareunsook |
| Developer | Thanakorn Sathitwitayakul |
| Project Sponsor / Customer Representative | Seri Viriyasakultorn |
| Status | Final — ready for review and authorized approval |
## 1. Purpose
This document records the customer-level functional and non-functional requirements for BRN WMS. It provides the approved input for the Software Requirements Specification, Software Design, Traceability Record, Test Cases and Test Procedures, Verification Results, Validation Results, and Acceptance Report.
The System Analyst records the technical interpretation, and the Project Sponsor acting as Customer Representative reviews the operational accuracy and authorizes the baseline.
## 2. Business need
B.R.N. Enterprise Co., Ltd. requires a centralized warehouse management system to improve inventory accuracy, transaction control, operational visibility, and auditability. The system must support multiple companies and warehouses while restricting users to authorized data and functions.
The expected business outcomes are:
- Timely and accurate stock information.
- Traceable receipts, issues, transfers, lots, serial numbers, and expiry dates.
- Controlled sales, purchasing, finance, and accounting documents.
- Reduced manual error and duplicate data handling.
- Faster operational and management reporting.
- Stronger access control, company-data isolation, and accountability.
- Maintainable deployment, configuration, backup, and recovery procedures.
## 3. Stakeholders
| Stakeholder | Project role | Responsibility and interest |
|---|---|---|
| Seri Viriyasakultorn | Project Sponsor / Customer Representative / Authorized Approver | Represent customer needs and approve project scope, strategic decisions, requirement baseline, acceptance, and closure. |
| Apirach Supattaratpateep | Project Manager | Plan and coordinate requirement activities, resolve issues, control changes, and maintain the approved baseline. |
| Noppong Chareunsook | System Analyst | Analyze customer needs, specify system behavior, and maintain technical traceability. |
| Thanakorn Sathitwitayakul | Developer | Design and implement the solution. |
| Parin Ngamkham | QA / Tester | Perform test execution, verification, and validation facilitation independent of the Developer. |
| Yaowalak Bangchomphoo | Document Control | Control identifiers, versions, approvals, distribution, repository content, and evidence; same role as the example reference project for the same company. |
| Warehouse Manager and Staff | Operational users | Perform and review warehouse, stock, barcode, and reporting operations. |
| Sales and Purchasing Users | Business users | Perform quotation, order, purchase, invoice, and return workflows. |
| Finance and Accounting Users | Business users | Perform billing, receipt, payment, journal, ledger, and financial reporting activities. |
| System Administrator | Supporting user | Configure the environment, company, users, services, monitoring, backup, and recovery. |
| Management / Auditor | Information consumer | Review controlled records, transaction history, exceptions, and management information. |
## 4. Operational context
BRN WMS is a browser-based application composed of:
- A PHP web application providing user interfaces and operational APIs.
- A MySQL/MariaDB identity and company database.
- A MySQL/MariaDB WMS and accounting database.
- A Node.js/Socket.IO service for real-time notifications.
- A Node.js scheduler for aggregate maintenance and operational alerts.
- A controlled Git repository for source and configuration templates.
Users access the system through current standards-based browsers. The application and scheduled services operate using the Asia/Bangkok time zone.
## 5. Assumptions and constraints
- The application is deployed in a controlled PHP 8+, MySQL/MariaDB, and Node.js environment.
- B.R.N. provides authorized users, representative operational data, and availability for review and validation.
- Required network, server, barcode, printing, and endpoint hardware is available or procured separately.
- Legacy-data migration is excluded unless assessed and approved through change control.
- External ERP, bank, shipping, tax, or other third-party integration is excluded unless formally added.
- Local credentials, passwords, tokens, and secrets are not stored in the source repository.
- “Must” requirements are acceptance-critical. A “Should” requirement may only be deferred through documented disposition.
## 6. Requirement interpretation
| Term | Meaning |
|---|---|
| Must | Mandatory for acceptance unless the Project Sponsor authorizes a documented exception. |
| Should | Expected within the agreed solution; deferral requires documented review and disposition. |
| User | An authenticated person acting in an authorized company and role context. |
| Company | A tenant whose data must be isolated from other companies. |
| Warehouse location | A warehouse, storage area, and/or bin used to identify stock location. |
| Controlled document | A business or project record with identifier, status, history, and applicable authorization. |
## 7. Functional requirements
### 7.1 Identity and access
| ID | Requirement | Priority | Acceptance intent |
|---|---|---|---|
| FR-001 | The system shall support registration and onboarding of a company owner and onboarding of invited users. | Must | An authorized user can complete the applicable onboarding flow and access the assigned company. |
| FR-002 | The system shall authenticate users and enforce the Owner, Admin, Staff, and Viewer roles. | Must | Each role can access only its permitted screens and server-side actions. |
| FR-003 | The system shall support password recovery, session control, and applicable OTP verification. | Must | Recovery and verification operate without exposing credentials; concurrent-session rules are enforced. |
| FR-004 | The system shall allow authorized administrators to manage company profile, SMTP, system settings, users, and application access. | Must | Authorized changes are saved and unauthorized users are rejected. |
### 7.2 Master data
| ID | Requirement | Priority | Acceptance intent |
|---|---|---|---|
| FR-005 | The system shall maintain warehouses, storage areas/bins, product categories, products, contact types, and contacts. | Must | Authorized users can create, view, update, and appropriately deactivate supported records. |
| FR-006 | The system should support both simple and layered warehouse-location models. | Should | A company can use a basic warehouse model or configured warehouse/storage/bin levels. |
### 7.3 Inventory and warehouse operations
| ID | Requirement | Priority | Acceptance intent |
|---|---|---|---|
| FR-007 | The system shall record stock-in using product, quantity, warehouse/location, document, and applicable traceability attributes. | Must | A valid receipt creates the expected movement and balance; invalid input is rejected. |
| FR-008 | The system shall record stock-out with authorization and available-balance validation. | Must | An authorized issue reduces the correct balance and cannot issue an invalid quantity. |
| FR-009 | The system shall transfer stock between authorized warehouse locations. | Must | Source and destination movements remain balanced and traceable as one transfer. |
| FR-010 | The system shall track lot, serial number, and expiry date where applicable. | Must | Relevant stock and reports retain and display the required traceability attributes. |
| FR-011 | The system shall display stock overview, movement history, capacity/occupancy, low-stock, expired-stock, and product-lot information. | Must | Reports reflect authorized operational data and applicable filters. |
| FR-012 | The system should generate SKU and location barcode labels and support scanning workflows. | Should | Labels contain usable identifiers and supported screens accept scanned values. |
### 7.4 Sales and purchasing
| ID | Requirement | Priority | Acceptance intent |
|---|---|---|---|
| FR-013 | The system shall create and manage quotations, sales orders, invoices, returns, and credit notes. | Must | Authorized users can complete valid document lifecycles and related stock/financial effects. |
| FR-014 | The system shall create and manage purchase requests, purchase orders, purchase invoices, and supplier returns. | Must | Authorized users can complete valid purchasing lifecycles and related stock/financial effects. |
### 7.5 Finance and accounting
| ID | Requirement | Priority | Acceptance intent |
|---|---|---|---|
| FR-015 | The system shall create and manage receipt billing, receipts, payment billing, and payments. | Must | Authorized financial transactions retain document linkage, amount, status, and history. |
| FR-016 | The system shall maintain chart of accounts, departments, account formulas, journals, and general-ledger entries. | Must | Authorized users can maintain structures and post balanced, traceable entries. |
| FR-017 | The system shall provide trial balance, profit-and-loss, balance-sheet, VAT, journal, and GL-movement reports. | Must | Reports use authorized data and produce consistent totals for the selected period. |
### 7.6 Documents, reports, and automation
| ID | Requirement | Priority | Acceptance intent |
|---|---|---|---|
| FR-018 | The system shall generate controlled document numbers and manage document lifecycle/status. | Must | Document numbers follow the configured sequence and invalid status transitions are rejected. |
| FR-019 | The system should allow permitted file attachments on supported records. | Should | Allowed files can be uploaded and retrieved only by authorized users. |
| FR-020 | The system shall allow authorized users to filter, view, print, and/or export supported operational and management reports. | Must | Report output matches the selected scope and filters. |
| FR-021 | The system should notify authorized users of relevant status transitions and operational alerts. | Should | Relevant recipients receive only notifications within their authorized context. |
| FR-022 | The system should maintain stock/GL summaries and generate low-stock and overdue-invoice alerts on schedule. | Should | Scheduled jobs complete without duplicate or unauthorized results. |
| FR-023 | The system shall preserve creator, updater, status, and transaction history required for operational review. | Must | A reviewer can identify material record ownership and lifecycle events. |
| FR-024 | The system shall restrict company and warehouse data to the current authorized user context. | Must | Cross-company and unauthorized warehouse access is prevented in UI and server-side actions. |
## 8. Non-functional requirements
| ID | Area | Requirement | Priority | Acceptance intent |
|---|---|---|---|---|
| NFR-001 | Security | Configuration secrets shall be protected from source control and direct public web access. | Must | Repository and deployment review find no committed active secret or publicly exposed protected configuration. |
| NFR-002 | Security | Server-side actions shall validate input and enforce authentication, authorization, and tenant scope. | Must | Negative authorization and invalid-input tests are rejected without unauthorized data change. |
| NFR-003 | Integrity | Related database changes shall be transactional where required and prevent invalid negative or duplicate movements. | Must | Failure/rollback and concurrency-oriented tests preserve consistent balances and records. |
| NFR-004 | Availability | Installation, configuration, backup, and recovery procedures shall be documented. | Must | An authorized administrator can follow the documentation in the supported environment. |
| NFR-005 | Usability | The user interface should be responsive and usable on desktop and warehouse-floor devices. | Should | Representative screens remain usable at the agreed desktop and mobile viewport sizes. |
| NFR-006 | Performance | Daily operations should respond within practical operational time, and aggregates should support dashboards and reports. | Should | Representative operations complete acceptably on the agreed environment and data volume. |
| NFR-007 | Maintainability | The software should use modular managers/APIs, centralized helpers, configuration templates, and version control. | Should | Maintenance review can locate responsibilities and change configuration without modifying unrelated modules. |
| NFR-008 | Compatibility | The system shall run on PHP 8+, MySQL/MariaDB, Node.js where used, and current standards-based browsers. | Must | Installation and representative workflows succeed on the supported platform. |
| NFR-009 | Traceability | Every approved requirement shall link to design, component, and verification evidence. | Must | The Traceability Record has no unexplained gap for an approved Must requirement. |
| NFR-010 | Time | Application and scheduled services shall use Asia/Bangkok consistently. | Must | Stored/displayed operational times and scheduled execution follow the configured time zone. |
## 9. Data requirements
- Company data must remain logically isolated from other companies.
- Warehouse data must remain limited to warehouses authorized for the current user.
- Identifiers and relationships must preserve referential integrity.
- Stock movements must retain sufficient product, quantity, location, status, and traceability information.
- Financial and accounting records must retain document linkage, amount, posting status, period, and audit information.
- Soft deletion or inactive status must not silently destroy required transaction history.
- Demo/test data must be distinguishable from approved production data.
## 10. Interface requirements
### 10.1 User interface
- Browser-based responsive screens.
- Navigation and available actions appropriate to the current role and application access.
- Clear validation, status, success, and error feedback.
- Printable business documents and barcode labels where supported.
### 10.2 Internal service interfaces
- PHP application access to two configured MySQL/MariaDB databases.
- Authenticated or secret-protected event relay to the Node.js notification service.
- Browser Socket.IO connection to the configured public notification endpoint.
- Controlled scheduler invocation of approved PHP maintenance and alert jobs.
### 10.3 File interfaces
- Supported file attachment upload and retrieval.
- Export/print output for supported operational and management reports.
- Configuration templates that do not contain live secrets.
## 11. Operational scenarios for validation
| Scenario | Expected outcome |
|---|---|
| User onboarding and access | The user enters the correct company and sees only functions permitted by role and application access. |
| Warehouse setup | Authorized users configure warehouse/location and product data required for operations. |
| Stock receipt | A valid receipt updates traceable stock at the selected location. |
| Stock issue | A valid issue reduces available stock; an invalid or excessive issue is rejected. |
| Stock transfer | Source and destination movements remain balanced and traceable. |
| Lot/serial/expiry control | Required attributes remain associated with stock and appear in applicable reports. |
| Sales lifecycle | Quotation/order/invoice/return actions follow permitted statuses and create expected related effects. |
| Purchasing lifecycle | Request/order/invoice/return actions follow permitted statuses and create expected related effects. |
| Finance and accounting | Receipt/payment and journal/GL results remain balanced and reportable. |
| Reporting | Authorized filters return consistent operational and financial results. |
| Notification and scheduler | Relevant events and scheduled alerts reach only appropriate recipients without duplication. |
| Tenant isolation | Attempts to access another company or unauthorized warehouse are denied. |
## 12. Acceptance criteria
The requirements baseline is satisfied when:
- Every Must requirement is implemented and traced to one or more test cases and results.
- Representative end-to-end validation scenarios pass in the agreed environment.
- No unresolved critical defect remains in security, tenant isolation, inventory integrity, transaction integrity, or core workflows.
- Any deferred Should requirement has a documented and authorized disposition.
- User, operation, configuration, and maintenance documentation covers the delivered system.
- The Project Sponsor acting as Customer Representative confirms that the requirements reflect intended use.
- The Project Sponsor authorizes the requirement baseline and applicable acceptance result.
## 13. Requirement change control
After authorization, a requirement change must:
1. Receive a unique Change Report reference.
2. Identify the requested change and business reason.
3. Analyze scope, schedule, design, implementation, test, security, and documentation impact.
4. Receive Project Sponsor authorization before baseline modification.
5. Update the SRS, design, traceability, tests, plan, and affected records.
6. Be implemented, verified, validated where applicable, and formally closed.
## 14. Traceability rule
Each requirement ID in this document must appear in the Traceability Record with links to:
- The corresponding SRS requirement.
- One or more Software Design elements.
- Implementing component(s), configuration, or operational control.
- Verification method and Test Case ID(s).
- Test result and defect/correction reference where applicable.
- Validation or acceptance evidence for customer-facing requirements.
## 15. Approval
### Prepared by
Name: Thanakorn Sathitwitayakul
Role: Developer
Signature: ______________________________________________
Date: ___________________________________________________
### Reviewed by
Name: Apirach Supattaratpateep
Role: Project Manager
Signature: ______________________________________________
Date: ___________________________________________________
### Reviewed, confirmed, 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: ___________________________________________________
sdlc/1-PM Process (10 Work Product)/2.Project Plan/3-Customer Requirement/200-WMS-26-001-00 Customer Requirements 25690206 V1.0 NoC.md
+149
View File
@@ -0,0 +1,149 @@
# Customer Requirements
<!-- footer: CR -->
| Document No | Customer Requirements | Release, Version, By: | 25690206 V1.0 NoC |
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
| Project Code | 200-WMS-26-001-00 |
| Title | เอกสารบันทึกและสรุปความต้องการของลูกค้า (Customer Requirements) |
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
## วัตถุประสงค์ (Objective)
เอกสารฉบับนี้จัดทำขึ้นเพื่อบันทึกและสรุปความต้องการของลูกค้า (Customer Requirements) ตามกระบวนการ ISO/IEC 29110 สำหรับใช้เป็นพื้นฐานในการจัดทำ Software Requirements Specification, การออกแบบระบบ, การทดสอบ และการตรวจรับ ของโครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด
## ผู้มีส่วนได้ส่วนเสีย (Stakeholders)
| ลำดับ | ชื่อ | ตำแหน่ง | บทบาท |
| :---: | --- | --- | --- |
| 1 | คุณเสรี วิริยะสกุลธรณ์ | ผู้บริหาร (CEO) | Project Sponsor อนุมัติและตัดสินใจเชิงกลยุทธ์ |
| 2 | คุณอภิรัชช์ สุภัทรประทีป | ผู้จัดการโครงการ | บริหารโครงการและควบคุมการเปลี่ยนแปลง |
| 3 | คุณนพพงษ์ เจริญสุข | นักวิเคราะห์ระบบ | เก็บและวิเคราะห์ความต้องการ จัดทำเอกสาร |
| 4 | หัวหน้าฝ่ายคลังสินค้าและพนักงานคลัง | ผู้ใช้งานหลัก | ให้ข้อมูลกระบวนการรับเข้า จ่ายออก โอนย้าย และตรวจนับ |
| 5 | ฝ่ายขายและฝ่ายจัดซื้อ | ผู้ใช้งาน | ให้ข้อมูลกระบวนการเอกสารขายและจัดซื้อ |
| 6 | ฝ่ายบัญชีและการเงิน | ผู้ใช้งาน | ให้ข้อมูลการวางบิล รับชำระ จ่ายชำระ และการบันทึกบัญชี |
## ความต้องการเชิงหน้าที่และไม่ใช่หน้าที่ (Functional and Non-Functional Requirements)
| ID | Topic | Result* | Remark |
| --- | --- | :---: | --- |
| CR01: Feature & Functional Characteristics | | | |
| CR01:001 | ระบบต้องรองรับการลงทะเบียนเจ้าของบริษัทและการเชิญผู้ใช้งานเข้าร่วมบริษัท (Onboarding) | A | FR-001 |
| CR01:002 | ระบบต้องยืนยันตัวตนผู้ใช้และบังคับสิทธิ์ตามบทบาท Owner, Admin, Staff และ Viewer | A | FR-002 |
| CR01:003 | ระบบต้องรองรับการกู้คืนรหัสผ่าน การควบคุม Session และการยืนยัน OTP ตามที่กำหนด | A | FR-003 |
| CR01:004 | ระบบต้องให้ผู้ดูแลจัดการข้อมูลบริษัท, SMTP, การตั้งค่าระบบ, ผู้ใช้งาน และสิทธิ์การเข้าถึงแอปพลิเคชัน | A | FR-004 |
| CR01:005 | ระบบต้องจัดการข้อมูลคลังสินค้า, พื้นที่/ช่องจัดเก็บ, หมวดสินค้า, สินค้า, ประเภทผู้ติดต่อ และผู้ติดต่อ | A | FR-005 |
| CR01:006 | ระบบต้องรองรับโครงสร้างตำแหน่งจัดเก็บทั้งแบบคลังเดียวและแบบหลายชั้น (คลัง/พื้นที่/ช่อง) | A | FR-006 |
| CR01:007 | ระบบต้องบันทึกการรับสินค้าเข้า (Stock-in) ระบุสินค้า จำนวน ตำแหน่ง เอกสารอ้างอิง และข้อมูลติดตาม | A | FR-007 |
| CR01:008 | ระบบต้องบันทึกการจ่ายสินค้าออก (Stock-out) โดยตรวจสอบสิทธิ์และยอดคงเหลือก่อนจ่าย | A | FR-008 |
| CR01:009 | ระบบต้องโอนย้ายสินค้าระหว่างตำแหน่งจัดเก็บที่ได้รับอนุญาตโดยยอดต้นทาง/ปลายทางสมดุลกัน | A | FR-009 |
| CR01:010 | ระบบต้องติดตาม Lot, Serial Number และวันหมดอายุของสินค้าที่เกี่ยวข้อง | A | FR-010 |
| CR01:011 | ระบบต้องแสดงภาพรวมสต๊อก, ประวัติความเคลื่อนไหว, ความจุ/การใช้พื้นที่, สินค้าใกล้หมด, สินค้าหมดอายุ และข้อมูล Lot | A | FR-011 |
| CR01:012 | ระบบต้องพิมพ์บาร์โค้ดสินค้า (SKU) และตำแหน่งจัดเก็บ และรองรับการสแกนในหน้าจอที่กำหนด | A | FR-012 |
| CR01:013 | ระบบต้องสร้างและจัดการใบเสนอราคา, ใบสั่งขาย, ใบแจ้งหนี้, ใบรับคืน และใบลดหนี้ | A | FR-013 |
| CR01:014 | ระบบต้องสร้างและจัดการใบขอซื้อ, ใบสั่งซื้อ, ใบแจ้งหนี้ซื้อ และใบคืนสินค้าผู้ขาย | A | FR-014 |
| CR01:015 | ระบบต้องสร้างและจัดการใบวางบิลรับ, ใบเสร็จรับเงิน, ใบวางบิลจ่าย และใบสำคัญจ่าย | A | FR-015 |
| CR01:016 | ระบบต้องจัดการผังบัญชี, แผนก, สูตรบัญชี, สมุดรายวัน และบัญชีแยกประเภท | A | FR-016 |
| CR01:017 | ระบบต้องจัดทำรายงานงบทดลอง, งบกำไรขาดทุน, งบดุล, ภาษีมูลค่าเพิ่ม, สมุดรายวัน และความเคลื่อนไหว GL | A | FR-017 |
| CR01:018 | ระบบต้องออกเลขที่เอกสารอัตโนมัติและควบคุมสถานะ/วงจรชีวิตของเอกสาร | A | FR-018 |
| CR01:019 | ระบบต้องรองรับการแนบไฟล์ที่อนุญาตกับรายการที่กำหนด | A | FR-019 |
| CR01:020 | ระบบต้องให้ผู้ใช้กรอง ดู พิมพ์ และส่งออกรายงานปฏิบัติการและรายงานผู้บริหาร | A | FR-020 |
| CR01:021 | ระบบต้องแจ้งเตือนผู้ใช้ที่เกี่ยวข้องเมื่อสถานะเอกสารเปลี่ยนหรือมีเหตุการณ์ปฏิบัติการ | A | FR-021 |
| CR01:022 | ระบบต้องสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมดและใบแจ้งหนี้ค้างชำระตามกำหนดเวลา | A | FR-022 |
| CR01:023 | ระบบต้องเก็บผู้สร้าง ผู้แก้ไข สถานะ และประวัติรายการเพื่อการตรวจสอบ | A | FR-023 |
| CR01:024 | ระบบต้องจำกัดข้อมูลบริษัทและคลังสินค้าให้เฉพาะผู้ใช้ที่ได้รับอนุญาตในบริบทปัจจุบัน | A | FR-024 |
| CR02: Performance Considerations | | | |
| CR02:001 | ระบบต้องตอบสนองงานประจำวัน (เปิดหน้าจอ, ค้นหา, สร้างเอกสาร) ภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | A | NFR-006 |
| CR02:002 | ระบบต้องมีตารางสรุปยอด (Aggregate) เพื่อให้แดชบอร์ดและรายงานแสดงผลได้โดยไม่ต้องคำนวณใหม่ทุกครั้ง | A | NFR-006 |
| CR02:003 | ระบบต้องรองรับปริมาณข้อมูลและผู้ใช้พร้อมกันในระดับที่ตกลงสำหรับสภาพแวดล้อมใช้งานจริง | A | NFR-006 |
| CR03: Interface Considerations | | | |
| CR03:001 | ระบบต้องเชื่อมต่อฐานข้อมูล MySQL/MariaDB 2 ฐาน (wms สำหรับผู้ใช้/บริษัท และ wms2 สำหรับคลัง/บัญชี) | A | Operational context |
| CR03:002 | ระบบต้องใช้งานผ่าน Web Browser มาตรฐาน (Chrome, Edge, Firefox) ได้ | A | NFR-008 |
| CR03:003 | ระบบต้องส่งเหตุการณ์ไปยังบริการ Node.js ผ่าน Endpoint ภายในที่ป้องกันด้วย Secret | A | NFR-002 |
| CR03:004 | Browser ต้องเชื่อมต่อ Socket.IO Endpoint สาธารณะเพื่อรับการแจ้งเตือนแบบ Real-time | A | FR-021 |
| CR03:005 | ระบบต้องส่งอีเมล Onboarding, กู้คืนรหัสผ่าน และแจ้งเตือนผ่าน SMTP ที่ตั้งค่าต่อบริษัท | A | FR-004 |
| CR04: Required System Characteristics | | | |
| CR04:001 | ระบบต้องพัฒนาบนสถาปัตยกรรม Web-based Application | A | Operational context |
| CR04:002 | ระบบต้องเก็บข้อมูลแบบ Relational Database และรักษา Referential Integrity | A | Data requirements |
| CR04:003 | ระบบต้องรองรับการเข้าสู่ระบบด้วย Username/Password และกำหนดบทบาทผู้ใช้ | A | FR-002 |
| CR04:004 | ระบบต้องทำงานบน PHP 8 ขึ้นไป, MySQL/MariaDB และ Node.js | A | NFR-008 |
| CR05: Human Engineering Considerations | | | |
| CR05:001 | UI ต้องเป็น Responsive ใช้งานได้ทั้งบน Desktop และอุปกรณ์หน้าคลังสินค้า (Tablet/Mobile) | A | NFR-005 |
| CR05:002 | เมนูและปุ่มคำสั่งต้องแสดงตามบทบาทและสิทธิ์การเข้าถึงของผู้ใช้ | A | Interface requirements |
| CR05:003 | ระบบต้องแสดงผลการตรวจสอบข้อมูล สถานะ ความสำเร็จ และข้อผิดพลาดอย่างชัดเจน | A | Interface requirements |
| CR05:004 | ระบบต้องมีขั้นตอนยืนยันก่อนลบ ยกเลิก หรือทำรายการที่ย้อนกลับไม่ได้ | A | Usability practice |
| CR05:005 | ระบบต้องพิมพ์เอกสารธุรกิจและฉลากบาร์โค้ดในรูปแบบที่ใช้งานได้ | A | Interface requirements |
| CR06: Security Considerations | | | |
| CR06:001 | การเชื่อมต่อในสภาพแวดล้อมใช้งานจริงต้องเข้ารหัสด้วย HTTPS/TLS | A | NFR-001 |
| CR06:002 | ค่าตั้งค่าและความลับของระบบต้องไม่ถูกเก็บใน Source Control และไม่เข้าถึงได้จากเว็บสาธารณะ | A | NFR-001 |
| CR06:003 | การทำงานฝั่งเซิร์ฟเวอร์ต้องตรวจสอบข้อมูลนำเข้า ยืนยันตัวตน ตรวจสิทธิ์ และจำกัดขอบเขตบริษัท/คลัง | A | NFR-002 |
| CR06:004 | ระบบต้องจำกัดสิทธิ์การเข้าถึงตามบทบาท (Role-based Access Control) ทั้งใน UI และฝั่งเซิร์ฟเวอร์ | A | FR-002 |
| CR06:005 | ระบบต้องป้องกัน SQL Injection และ Cross-Site Scripting | A | NFR-002 |
| CR06:006 | ระบบต้องบล็อกการเข้าสู่ระบบซ้ำซ้อน (Concurrent Login) ของบัญชีเดียวกัน | A | FR-003 |
| CR07: Environmental Considerations | | | |
| CR07:001 | ระบบต้องทำงานบน Linux Server ในรูปแบบติดตั้งเอง (LAMP) หรือ Docker Compose | A | NFR-004 |
| CR07:002 | ระบบต้องใช้เขตเวลา Asia/Bangkok อย่างสม่ำเสมอทั้งแอปพลิเคชันและงานตามกำหนดเวลา | A | NFR-010 |
| CR07:003 | ระบบต้องใช้งานได้บนอุปกรณ์ Desktop และอุปกรณ์พกพาผ่าน Web Browser | A | NFR-005 |
| CR07:004 | ระบบต้องแยกข้อมูลสาธิต/ทดสอบออกจากข้อมูลใช้งานจริงได้ | A | Data requirements |
| CR08: Operational Considerations | | | |
| CR08:001 | ระบบต้องมีการสำรองฐานข้อมูลอัตโนมัติรายวัน | A | NFR-004 |
| CR08:002 | ระบบต้องกู้คืนข้อมูลจากชุดสำรองได้ตามขั้นตอนที่จัดทำเป็นเอกสาร | A | NFR-004 |
| CR08:003 | ระบบต้องมีการเฝ้าระวังสถานะบริการ Web, Database และ Node.js พร้อมแจ้งเตือนเมื่อขัดข้อง | A | NFR-004 |
| CR08:004 | ระบบต้องรองรับหลายบริษัท (Multi-company) และหลายคลังสินค้าภายใต้การแยกข้อมูล | A | FR-024 |
| CR08:005 | งานตามกำหนดเวลาต้องทำงานสำเร็จโดยไม่สร้างผลลัพธ์ซ้ำหรือเกินสิทธิ์ | A | FR-022 |
| CR09: Maintenance Considerations | | | |
| CR09:001 | ซอฟต์แวร์ต้องมีโครงสร้างแบบโมดูล (Manager Classes / API) เพื่อให้แก้ไขได้โดยไม่กระทบส่วนอื่น | A | NFR-007 |
| CR09:002 | ระบบต้องมีแม่แบบค่าตั้งค่า (Configuration Template) และควบคุมเวอร์ชันด้วย Git | A | NFR-007 |
| CR09:003 | ระบบต้องมีเอกสารคู่มือการบำรุงรักษาและประวัติข้อบกพร่องที่แก้ไขแล้ว | A | NFR-004 |
| CR09:004 | การเปลี่ยนแปลงโครงสร้างฐานข้อมูลต้องสะท้อนใน setup.php และตาราง schema_migrations | A | NFR-007 |
| CR10: Installation Considerations | | | |
| CR10:001 | ระบบต้องติดตั้งฐานข้อมูลได้ในขั้นตอนเดียวผ่าน setup.php | A | NFR-004 |
| CR10:002 | ระบบต้องติดตั้งแบบ Container ได้ด้วยคำสั่ง docker compose up -d --build | A | NFR-004 |
| CR10:003 | ระบบต้องมีสคริปต์สร้างไฟล์ .env และค่าความลับอัตโนมัติ (docker/init-env.sh) | A | NFR-001 |
| CR10:004 | ระบบต้องมีเอกสารขั้นตอนการติดตั้งและตั้งค่า | A | NFR-004 |
| CR11: Support Considerations | | | |
| CR11:001 | ต้องมีคู่มือผู้ใช้งาน (Software User Document) | A | Documentation |
| CR11:002 | ต้องมีคู่มือปฏิบัติงานสำหรับผู้ดูแลระบบ (Product Operation Guide) | A | Documentation |
| CR11:003 | ต้องมีการอบรมผู้ใช้งานก่อนเปิดใช้งานจริง | A | Training |
| CR11:004 | ต้องมีช่องทางสนับสนุนและระดับการให้บริการ (SLA) หลังส่งมอบ | A | Maintenance |
| CR12: Design Constraints | | | |
| CR12:001 | ระบบต้องพัฒนาด้วย PHP, MariaDB และ Node.js ตามที่องค์กรอนุมัติ | A | NFR-008 |
| CR12:002 | ระบบต้องควบคุม Source Code ด้วย Git โดยมี main เป็น Baseline หลัก | A | Configuration |
| CR12:003 | รหัสผ่านผู้ใช้ต้องเข้ารหัสด้วย bcrypt และไม่เก็บหรือบันทึกเป็นข้อความธรรมดา | A | NFR-002 |
| CR12:004 | โครงการต้องจัดทำ Work Products ตามมาตรฐาน ISO/IEC 29110 Basic Profile | A | NFR-009 |
| CR13: Safety and Reliability Considerations | | | |
| CR13:001 | การเปลี่ยนแปลงฐานข้อมูลที่เกี่ยวข้องกัน (เอกสาร + สต๊อก + GL) ต้องเป็น Transaction เดียวกัน | A | NFR-003 |
| CR13:002 | ระบบต้องป้องกันยอดสต๊อกติดลบและความเคลื่อนไหวซ้ำซ้อน | A | NFR-003 |
| CR13:003 | ระบบต้องรองรับการสำรองและกู้คืน (Backup & Recovery) ทั้ง Source Code และฐานข้อมูล | A | NFR-004 |
| CR13:004 | ระบบต้องจัดการข้อผิดพลาดโดยแสดงข้อความที่เข้าใจได้แทน Fatal Error | A | NFR-006 |
| CR14: Quality Expectations | | | |
| CR14:001 | ระบบต้องผ่านการทดสอบตาม Test Case ที่กำหนดก่อนส่งมอบ | A | Acceptance |
| CR14:002 | ทุกความต้องการต้องสอบกลับได้ถึงการออกแบบ ส่วนประกอบ และหลักฐานการทดสอบ | A | NFR-009 |
| CR14:003 | ระบบต้องผ่านการทดสอบการยอมรับ (UAT) โดยตัวแทนลูกค้าบนสภาพแวดล้อมใช้งานจริง | A | Acceptance |
| CR14:004 | ต้องไม่มีข้อบกพร่องระดับวิกฤตค้างอยู่ในด้านความปลอดภัย การแยกข้อมูล และความถูกต้องของสต๊อก/บัญชี | A | Acceptance |
## Remark
- \* Result : A = Accepted, U = Unaccepted, N/A = Not Applicable
- เอกสารฉบับนี้รวมความต้องการที่ได้จากการทบทวนขอบเขตงานร่วมกับลูกค้า
- การเปลี่ยนแปลงความต้องการหลังอนุมัติต้องดำเนินการผ่าน Change Report
## ผู้จัดทำเอกสาร (Secretary)
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
## ผู้ตรวจสอบเอกสาร (Reviewer)
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
## ผู้อนุมัติ (Approval)
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
| --- | --- | --- | --- |
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |