docs(sdlc): reformat work products to audited reference layout
This commit is contained in:
Thanakorn
+81
@@ -0,0 +1,81 @@
|
||||
# Work Schedule
|
||||
|
||||
<!-- footer: WS -->
|
||||
|
||||
| Document No | Work Schedule | Release, Version, By: | 25690213 V1.0 ApS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | แผนการดำเนินงานโครงการ (Work Schedule) |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 | Project Duration | 232 วัน |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## แผนการดำเนินงาน (Work Schedule)
|
||||
|
||||
| No. | Phase | Task | รายละเอียด | ผู้รับผิดชอบ | Start | Finish | วัน | สิ่งส่งมอบ / หลักฐาน | Status | หมายเหตุ |
|
||||
| :---: | --- | --- | --- | :---: | ---: | ---: | ---: | --- | :---: | --- |
|
||||
| 1.1 | Project Initiation | Kick-off Meeting | เปิดโครงการ ชี้แจงขอบเขต เป้าหมาย และทีมงาน | ApS, SeV | 5 ม.ค. 69 | 9 ม.ค. 69 | 5 | Statement of Work | Completed | เปิดโครงการอย่างเป็นทางการ |
|
||||
| 1.2 | Project Initiation | Identify Stakeholders | ระบุผู้มีส่วนได้ส่วนเสียและบทบาทความรับผิดชอบ | ApS, YaB | 12 ม.ค. 69 | 16 ม.ค. 69 | 5 | Stakeholder Register | Completed | จัดทำ Stakeholder Register |
|
||||
| 1.3 | Project Initiation | Define Vision & Objectives | กำหนดวัตถุประสงค์ ขอบเขตระบบ และเกณฑ์ความสำเร็จ | ApS, NoC | 19 ม.ค. 69 | 21 ม.ค. 69 | 3 | Project Charter Report | Completed | อนุมัติวัตถุประสงค์โครงการ |
|
||||
| 1.4 | Project Initiation | Approve Project Charter | ผู้บริหารอนุมัติกฎบัตรโครงการและขอบเขตงาน | SeV, ApS | 22 ม.ค. 69 | 23 ม.ค. 69 | 2 | Approved Project Charter | Completed | อนุมัติโดย Project Sponsor |
|
||||
| 2.1 | Project Planning | Collect Customer Requirements | เก็บและวิเคราะห์ความต้องการลูกค้า จัดหมวด CR01–CR14 | NoC, ApS | 12 ม.ค. 69 | 6 ก.พ. 69 | 26 | Customer Requirements | Completed | ความต้องการ 80 รายการ ผลสรุป A ทั้งหมด |
|
||||
| 2.2 | Project Planning | Develop Software Project Plan | จัดทำแผนโครงการ ทรัพยากร ความเสี่ยง และการควบคุม | ApS, YaB | 26 ม.ค. 69 | 13 ก.พ. 69 | 19 | Software Project Plan | Completed | รวม Work Schedule |
|
||||
| 2.3 | Project Planning | Baseline Requirements & Schedule | ทบทวนและตั้ง Baseline ความต้องการและแผนงาน | ApS, NoC | 16 ก.พ. 69 | 18 ก.พ. 69 | 3 | Baselined Plan | Completed | เริ่มพัฒนา 19 ก.พ. 69 |
|
||||
| 3.1 | Project Execution | Software Requirements & Design | จัดทำ SRS (SR01–SR09) และเอกสารออกแบบระบบ | NoC, ThS | 19 ก.พ. 69 | 25 ก.พ. 69 | 7 | SRS, Software Design | Completed | Git 9a50080–1843308 |
|
||||
| 3.2 | Project Execution | Security & Database Foundation | ป้องกันไฟล์ตั้งค่า แก้ผลตรวจความปลอดภัย และออกแบบฐานข้อมูลสต๊อก | ThS | 9 มี.ค. 69 | 17 มี.ค. 69 | 9 | Database schema, ICS modules | Completed | Git 93d903c–a4f474b |
|
||||
| 3.3 | Project Execution | Inventory & Warehouse Modules | พัฒนาคลังสินค้า ความจุ สินค้า Lot/Serial/Expiry และรายงาน | ThS, NoC | 9 เม.ย. 69 | 29 เม.ย. 69 | 21 | Inventory & report modules | Completed | Git 3b8f94f–db5c47b |
|
||||
| 3.4 | Project Execution | Authentication & Onboarding | พัฒนาเข้าสู่ระบบ ลงทะเบียน Onboarding และสิทธิ์ตามบทบาท | ThS | 28 เม.ย. 69 | 12 พ.ค. 69 | 15 | Authentication modules | Completed | Git d8fd30c–79e66bd |
|
||||
| 3.5 | Project Execution | Order & Barcode Workflows | พัฒนาใบสั่งขาย ใบรับคืน ใบแจ้งหนี้ คลังหลายชั้น และบาร์โค้ด | ThS | 2 พ.ค. 69 | 8 พ.ค. 69 | 7 | Order & barcode modules | Completed | Git a90975d–304848d |
|
||||
| 3.6 | Project Execution | Production Preparation & Setup | เตรียมใช้งานจริง Base URL อัตโนมัติ และสคริปต์ติดตั้งฐานข้อมูล | ThS | 11 พ.ค. 69 | 13 พ.ค. 69 | 3 | setup.php, configuration | Completed | Git d989e59–bf3be28 |
|
||||
| 3.7 | Project Execution | Accounting & Finance Workflows | พัฒนาผังบัญชี GL สมุดรายวัน ใบวางบิล ใบเสร็จ และใบสำคัญจ่าย | ThS | 13 พ.ค. 69 | 23 พ.ค. 69 | 11 | Accounting & finance modules | Completed | Git 04a683b–eddb10a |
|
||||
| 3.8 | Project Execution | Real-time Services & Scheduled Jobs | พัฒนา Socket.IO, ตารางสรุปยอด และงานแจ้งเตือนตามกำหนดเวลา | ThS | 22 พ.ค. 69 | 27 พ.ค. 69 | 6 | Node.js services | Completed | Git 9c275eb–b8798bc |
|
||||
| 3.9 | Project Execution | Security Hardening & Lifecycle Review | ทบทวน Role Guard ขอบเขตบริษัท วงจรเอกสาร และโควตารายการ | ThS, PaNg | 21 พ.ค. 69 | 28 พ.ค. 69 | 8 | Hardening commits | Completed | Git 6eeebfe–ed3dd2f |
|
||||
| 3.10 | Project Execution | Refactor & Development Baseline | ลดความซ้ำซ้อนของคลาสและตั้ง Baseline การพัฒนา | ThS | 29 พ.ค. 69 | 29 พ.ค. 69 | 1 | Development baseline | Completed | Git a0677d6 |
|
||||
| 4.1 | Project Control | Progress & Meeting Records | ติดตามความก้าวหน้า ประเด็นปัญหา มติ และการแก้ไขตลอดโครงการ | ApS, YaB | 5 ม.ค. 69 | 24 ส.ค. 69 | 232 | Progress Status, Meeting Record | Completed | บันทึกรายงวดตลอดโครงการ |
|
||||
| 4.2 | Project Control | Configuration & Repository Control | ควบคุม Source Code, Baseline, เวอร์ชันเอกสาร และการสำรองข้อมูล | ThS, YaB | 19 ก.พ. 69 | 24 ส.ค. 69 | 187 | Software Configuration | Completed | Git origin + backup remote |
|
||||
| 4.3 | Verification | Verify Work Products | ตรวจสอบความต้องการ ออกแบบ ส่วนประกอบ และการสอบกลับ | PaNg, NoC | 30 พ.ค. 69 | 17 ส.ค. 69 | 80 | Verification Results | Completed | ตรวจสอบ 4 รอบ รอบสุดท้าย 17 ส.ค. 69 |
|
||||
| 4.4 | Validation | System Test & UAT | ทดสอบระบบตาม Test Case และทดสอบการยอมรับโดยผู้ใช้ | PaNg, SeV | 10 ส.ค. 69 | 14 ส.ค. 69 | 5 | Test Report, Validation Results | Completed | ทดสอบ 45 Test Case และ 12 สถานการณ์ UAT |
|
||||
| 4.5 | Documentation | Operational Documentation | จัดทำคู่มือผู้ใช้ คู่มือผู้ดูแลระบบ และคู่มือบำรุงรักษา | ThS, YaB | 1 มิ.ย. 69 | 17 ส.ค. 69 | 78 | User / Operation / Maintenance docs | Completed | จัดทำครบ 3 ฉบับ |
|
||||
| 4.6 | Stabilization | Post-baseline Corrections | แก้ไขปัญหาการเข้าสู่ระบบและค่าตั้งค่าหลัง Baseline | ThS | 3 ส.ค. 69 | 3 ส.ค. 69 | 1 | Correction Register | Completed | Git b2c4374 |
|
||||
| 4.7 | Stabilization | Demonstration Data & Delivery Package | เตรียมข้อมูลสาธิต ปรับแบรนด์ และชุดติดตั้ง Docker Compose | ThS | 14 ส.ค. 69 | 17 ส.ค. 69 | 4 | Demo data, Docker stack | Completed | Git dd48a8b–6c39700 |
|
||||
| 5.1 | Project Close | Final Work-product Review | ตรวจสอบความครบถ้วนของ Work Products และหลักฐาน | ApS, YaB | 10 ส.ค. 69 | 17 ส.ค. 69 | 8 | List of Evidence | Completed | ตรวจรอบที่ 4 เมื่อ 17 ส.ค. 69 |
|
||||
| 5.2 | Project Close | Training | อบรมผู้ใช้งานก่อนเปิดใช้งานจริง | ThS, PaNg | 22 ส.ค. 69 | 22 ส.ค. 69 | 1 | Training Report | Completed | ผู้เข้าอบรม 6 คน |
|
||||
| 5.3 | Project Close | Acceptance & Project Closure | ส่งมอบระบบ ตรวจรับ และปิดโครงการ | SeV, ApS | 17 ส.ค. 69 | 24 ส.ค. 69 | 8 | Acceptance Report | Completed | ตรวจรับ 17 ส.ค. 69 ปิดโครงการ 24 ส.ค. 69 |
|
||||
|
||||
## หลักไมล์ของโครงการ (Milestones)
|
||||
|
||||
| หลักไมล์ | วันที่ | เกณฑ์การบรรลุ |
|
||||
| --- | :---: | --- |
|
||||
| เปิดโครงการอย่างเป็นทางการ | 5 มกราคม 2569 | ประชุม Kick-off และชี้แจงขอบเขตงาน |
|
||||
| อนุมัติกฎบัตรโครงการ | 23 มกราคม 2569 | Project Sponsor อนุมัติ Project Charter |
|
||||
| ตั้ง Baseline ความต้องการและแผนงาน | 18 กุมภาพันธ์ 2569 | อนุมัติ Customer Requirements และ Work Schedule |
|
||||
| เริ่มพัฒนาระบบ | 19 กุมภาพันธ์ 2569 | เริ่ม Task 3.1 ตามแผน |
|
||||
| Baseline การพัฒนา | 29 พฤษภาคม 2569 | พัฒนาครบทุกโมดูล (Git a0677d6) |
|
||||
| ทดสอบระบบและ UAT | 10 สิงหาคม 2569 – 14 สิงหาคม 2569 | ทดสอบ 45 Test Case และ 12 สถานการณ์ UAT ผ่านทั้งหมด |
|
||||
| ตรวจรับส่งมอบระบบ | 17 สิงหาคม 2569 | ผลการตรวจรับ Accepted |
|
||||
| อบรมผู้ใช้งาน | 22 สิงหาคม 2569 | อบรมผู้ใช้งาน 6 คน |
|
||||
| ปิดโครงการ | 24 สิงหาคม 2569 | ปิดโครงการอย่างเป็นทางการ |
|
||||
|
||||
## หมายเหตุการติดตามแผนงาน
|
||||
|
||||
- สถานะงานได้รับการปรับปรุงทุกงวดรายงานตาม Progress Status Record
|
||||
- งานที่ไม่แล้วเสร็จตามกำหนดต้องดำเนินการตามแผนสำรองใน Software Project Plan หัวข้อ 10
|
||||
- การเปลี่ยนแปลงแผนงานที่กระทบกำหนดส่งมอบต้องผ่าน Change Report
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณอภิรัชช์ สุภัทรประทีป | Project Manager | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-99
@@ -1,99 +0,0 @@
|
||||
# Work Schedule
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Work Schedule |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Project end date | 24/08/26 |
|
||||
| Release | 17/08/26 V1.0 Final |
|
||||
| Schedule baseline | 05/01/26 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Status | Final — reviewed and authorized |
|
||||
|
||||
## Revision history
|
||||
|
||||
| Version | Date | Change | Prepared by |
|
||||
|---|---|---|---|
|
||||
| V1.0 | 17/08/26 | Initial controlled issue, subsequently updated with closure outcomes through 24/08/26: training, operational controls, delivery packaging, and repository-backup synchronization completed. | Apirach Supattaratpateep |
|
||||
|
||||
The Status, Actual/evidence date and Remarks columns below record outcomes through formal closure on 24/08/26. The Start, Finish and Duration columns retain the 05/01/26 planned baseline; where a task finished after its planned Finish date, the Remarks column states the actual finish.
|
||||
|
||||
## Schedule basis
|
||||
|
||||
| No. | Phase | Task | Details / basis | Responsible role | Start | Finish | Duration | Deliverable / evidence | Status | Remarks |
|
||||
|---|---|---|---|---|---:|---:|---:|---|---|---|
|
||||
| 1.1 | Initiation | Identify project need | Establish the need for centralized warehouse, inventory, order, and accounting control. | Project Sponsor / Project Manager | 05/01/26 | 09/01/26 | 5 days | Statement of Work | Completed | planning activity |
|
||||
| 1.2 | Initiation | Identify stakeholders and objectives | Identify sponsor, operational users, system administrator, development, and approval roles. | Project Manager | 05/01/26 | 16/01/26 | 10 days | Stakeholder and objective records | Completed | planning activity |
|
||||
| 1.3 | Initiation | Approve project scope | Confirm project boundaries, assumptions, deliverables, and acceptance approach. | Project Sponsor | 19/01/26 | 23/01/26 | 5 days | Approved Statement of Work | Completed | Approved scope recorded |
|
||||
| 2.1 | Planning | Collect customer requirements | Document functional, data, security, operational, and quality requirements. | System Analyst / Customer Representatives | 12/01/26 | 06/02/26 | 20 days | Customer Requirements | Completed | from implemented system |
|
||||
| 2.2 | Planning | Prepare Software Project Plan | Define lifecycle, resources, risks, repository, configuration, communication, and controls. | Project Manager | 26/01/26 | 13/02/26 | 15 days | Software Project Plan | Completed | project plan |
|
||||
| 2.3 | Planning | Baseline requirements and schedule | Review initial requirements, priorities, milestones, and work-product responsibilities. | Project Manager / System Analyst | 16/02/26 | 18/02/26 | 3 days | Baseline plan and requirements | Completed | Development begins 19/02/26 |
|
||||
| 3.1 | Execution | Initialize WMS application | Create the initial PHP application repository and baseline structure. | System Analyst / Developer | 19/02/26 | 25/02/26 | 5 days | Application baseline | Completed |
|
||||
| 3.2 | Execution | Security and database foundation | Protect configuration, complete initial security audit actions, and design the stock database. | Developer | 09/03/26 | 17/03/26 | 7 days | Security and database baseline | Completed |
|
||||
| 3.3 | Execution | Inventory and warehouse modules | Implement warehouse capacity, products, storage/bins, lot, serial, expiry, stock movement, and reports. | Developer | 09/04/26 | 29/04/26 | 15 days | Inventory, ICS, dashboard, and report modules | Completed |
|
||||
| 3.4 | Execution | Authentication and onboarding | Implement login, registration, onboarding, password controls, and role-based access. | Developer | 28/04/26 | 12/05/26 | 11 days | Authentication and user-management modules | Completed |
|
||||
| 3.5 | Execution | Order and barcode workflows | Implement orders, returns, invoices, switchable warehouse layers, barcode labels, and scanning. | Developer | 02/05/26 | 08/05/26 | 5 days | Order and barcode modules | Completed |
|
||||
| 3.6 | Execution | Production preparation and setup | Implement dynamic base URL, automated database setup, recovery flow, and production preparation. | Developer | 11/05/26 | 13/05/26 | 3 days | Setup and configuration implementation | Completed |
|
||||
| 3.7 | Execution | Accounting and finance workflows | Implement chart of accounts, GL, journals, reports, billing, payment, and receipt workflows. | Developer | 13/05/26 | 23/05/26 | 9 days | Accounting and finance modules | Completed |
|
||||
| 3.8 | Execution | Real-time services and scheduled jobs | Implement Socket.IO notifications, stock/GL aggregates, and operational alerts. | Developer | 22/05/26 | 27/05/26 | 4 days | Node.js service and scheduled jobs | Completed |
|
||||
| 3.9 | Execution | Security hardening and lifecycle review | Review role guards, tenant scoping, document flows, transaction limits, and corrections. | Developer / Reviewer | 21/05/26 | 28/05/26 | 6 days | Security and lifecycle review | Completed |
|
||||
| 3.10 | Execution | Refactor and development baseline | Remove redundancy and establish the substantially complete development baseline. | Developer | 29/05/26 | 29/05/26 | 1 day | Development baseline | Completed |
|
||||
| 4.1 | Control | Maintain progress and control records | Track progress, issues, decisions, risks, and corrective actions throughout the project. | Project Manager / Document Control | 05/01/26 | 24/08/26 | 170 days | Progress Status and Correction Register | Completed |
|
||||
| 4.2 | Control | Configuration and repository control | Control source, baselines, document versions, configuration, and backups. | Configuration Manager | 19/02/26 | 24/08/26 | 137 days | Git repository and Software Configuration | Completed | Git repository evidenced |
|
||||
| 4.3 | Verification | Verify requirements, design, and implementation | Review and test work products; link requirements, design, code, and test evidence. | Reviewer / Tester | 30/05/26 | 31/07/26 | 45 days | Verification Results and Traceability Record | Completed | Actual finish 17/08/26, after the scheduled finish of 31/07/26. Traceability Record complete (34/34 requirements linked and verified); Round 2 independent verification performed by Yaowalak Bangchomphoo (Document Control) on 17/08/26 |
|
||||
| 4.4 | Validation | Customer-oriented system validation | Validate operational workflows and quality attributes against intended use. | Customer Representatives / Tester | 01/06/26 | 07/08/26 | 50 days | Validation Results and Test Report | Completed | Actual finish 14/08/26, after the scheduled finish of 07/08/26. All 34 test cases and 12 validation scenarios were executed and passed over 10/08/26–14/08/26, confirmed by the project user on 17/08/26; per-case execution dates within that window were not separately recorded |
|
||||
| 4.5 | Documentation | Prepare operational documentation | Prepare user, operation, configuration, deployment, and maintenance guidance. | Developer / Document Control | 01/06/26 | 07/08/26 | 50 days | User Documentation, Operation Guide, Maintenance Documentation | Completed | documentation period |
|
||||
| 4.6 | Stabilization | Configuration and login corrections | Correct login and environment configuration issues identified after baseline. | Developer | 03/08/26 | 03/08/26 | 1 day | Configuration and login correction | Completed |
|
||||
| 4.7 | Stabilization | Prepare demonstration data | Populate controlled demonstration data for validation and handover support. | Developer / Tester | 14/08/26 | 14/08/26 | 1 day | Demonstration data | Completed |
|
||||
| 5.1 | Closure | Final repository and work-product review | Confirm required work products, traceability, configuration items, and unresolved actions. | Project Manager / Document Control | 10/08/26 | 24/08/26 | 15 days | Repository review and List of Evidence | Completed | Round 2 independent verification performed by Document Control on 17/08/26 |
|
||||
| 5.2 | Closure | Acceptance and project closure | Obtain authorized acceptance and record project closure and follow-up actions. | Project Sponsor / Project Manager | 14/08/26 | 24/08/26 | 11 days | Acceptance Report, Training Report, operational-control closure, and repository-backup record | Completed | Product accepted 17/08/26; training completed 22/08/26; operational controls closed 23/08/26; administrative and repository-backup closure completed 24/08/26 |
|
||||
|
||||
## Milestones
|
||||
|
||||
| Milestone | Date | Basis |
|
||||
|---|---:|---|
|
||||
| Formal project start | 05/01/26 | Agreed project boundary |
|
||||
| Requirements and planning baseline | 18/02/26 | Planned pre-development completion |
|
||||
| Development start | 19/02/26 | Application development begins |
|
||||
| Development substantially complete | 29/05/26 | Final main-development refactoring commit |
|
||||
| Post-development correction | 03/08/26 | Login and configuration correction commit |
|
||||
| Demonstration data | 14/08/26 | Final repository commit |
|
||||
| Project end date | 24/08/26 | Formal project completion date |
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
|
||||
Role: Project Manager / Document Creator
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical contributor
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
|
||||
Role: Developer
|
||||
|
||||
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: ___________________________________________________
|
||||
+283
@@ -0,0 +1,283 @@
|
||||
# Software Project Plan
|
||||
|
||||
<!-- footer: PP -->
|
||||
|
||||
| Document No | Software Project Plan | Release, Version, By: | 25690213 V1.0 ApS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | แผนการดำเนินโครงการ |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 | Project Duration | 232 วัน |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## 1 Manufacture
|
||||
|
||||
บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด เป็นบริษัทผู้ประกอบธุรกิจด้านเทคโนโลยีสารสนเทศ ซึ่งมีประสบการณ์ในการส่งมอบผลิตภัณฑ์และบริการด้านเทคโนโลยีให้แก่หน่วยงานภาครัฐและเอกชนอย่างต่อเนื่อง บริษัทประกอบธุรกิจหลัก 3 ด้าน ได้แก่
|
||||
|
||||
- พัฒนาซอฟต์แวร์ตามความต้องการของหน่วยงาน (Software Development)
|
||||
- จำหน่ายผลิตภัณฑ์ซอฟต์แวร์สำเร็จรูป (Software Package) เช่น ระบบบริหารจัดการสินทรัพย์
|
||||
- ให้บริการบำรุงรักษาระบบ (Service Maintenance: MA) ครอบคลุมโครงสร้างพื้นฐาน เครื่องแม่ข่าย และศูนย์ข้อมูล
|
||||
|
||||
## 2 Overview
|
||||
|
||||
เพื่อยกระดับการบริหารจัดการคลังสินค้าของบริษัทให้มีความถูกต้อง รวดเร็ว และตรวจสอบย้อนกลับได้ บริษัทมีความประสงค์จะพัฒนา ระบบบริหารจัดการคลังสินค้า (BRN WMS) ขึ้นใหม่ โดยมีวัตถุประสงค์เพื่อ
|
||||
|
||||
- รวมศูนย์ข้อมูลคลังสินค้า สินค้าคงคลัง และความเคลื่อนไหวของสินค้าไว้ในระบบเดียว
|
||||
- เชื่อมโยงงานขาย งานจัดซื้อ งานการเงิน และการบันทึกบัญชีเข้ากับความเคลื่อนไหวของสินค้า
|
||||
- ควบคุมสิทธิ์การเข้าถึงและแยกข้อมูลระหว่างบริษัทและคลังสินค้าอย่างชัดเจน
|
||||
- ให้ผู้บริหารเห็นภาพรวมสถานะคลังสินค้าและสถานะทางการเงินได้ตามเวลาจริง
|
||||
|
||||
## 3 Goals and Scope
|
||||
|
||||
### 3.1 เป้าหมายของโครงการ
|
||||
|
||||
**เป้าหมายด้านองค์กร**
|
||||
|
||||
- ลดข้อผิดพลาดของยอดสินค้าคงคลังที่เกิดจากการบันทึกด้วยมือ
|
||||
- เพิ่มความสามารถในการตรวจสอบย้อนกลับของสินค้าตาม Lot, Serial Number และวันหมดอายุ
|
||||
- ทำให้ข้อมูลคลังสินค้าและข้อมูลบัญชีสอดคล้องกันโดยไม่ต้องบันทึกซ้ำ
|
||||
|
||||
**เป้าหมายด้านผู้ใช้งาน**
|
||||
|
||||
- ให้พนักงานคลังสินค้าบันทึกรายการรับเข้า จ่ายออก และโอนย้ายได้สะดวกจากอุปกรณ์หน้าคลัง
|
||||
- ให้ฝ่ายขายและฝ่ายจัดซื้อจัดทำเอกสารและติดตามสถานะได้ในระบบเดียว
|
||||
- ให้ฝ่ายบัญชีได้ข้อมูลรายการที่ผ่านการตรวจสอบแล้วโดยอัตโนมัติ
|
||||
|
||||
### 3.2 ขอบเขตของโครงการ (SOW)
|
||||
|
||||
| ลำดับ | ระบบ | ระบบย่อย |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ระบบบริหารจัดการผู้ใช้งานและสิทธิ์ | ลงทะเบียนเจ้าของบริษัทและเชิญผู้ใช้งาน (Onboarding) / เข้าสู่ระบบและควบคุมสิทธิ์ตามบทบาท Owner / Admin / Staff / Viewer / กู้คืนรหัสผ่าน, OTP และควบคุม Session / ตั้งค่าบริษัท, SMTP, ผู้ใช้งาน และสิทธิ์การเข้าถึงแอปพลิเคชัน |
|
||||
| 2 | ระบบข้อมูลหลัก (Master Data) | คลังสินค้า, พื้นที่จัดเก็บ, ช่องจัดเก็บ (Bin) / หมวดสินค้าและสินค้า / ประเภทผู้ติดต่อและผู้ติดต่อ (ลูกค้า/ผู้ขาย) / รองรับโครงสร้างคลังแบบชั้นเดียวและแบบหลายชั้น |
|
||||
| 3 | ระบบควบคุมสินค้าคงคลัง (Inventory Control) | รับสินค้าเข้า (Stock-in) / จ่ายสินค้าออก (Stock-out) พร้อมตรวจสอบยอดคงเหลือ / โอนย้ายสินค้าระหว่างคลัง/ตำแหน่ง / ติดตาม Lot, Serial Number และวันหมดอายุ / พิมพ์บาร์โค้ดสินค้า/ตำแหน่ง และรองรับการสแกน / แนบไฟล์ประกอบรายการ |
|
||||
| 4 | ระบบขาย (Sales) | ใบเสนอราคา (Quotation) / ใบสั่งขาย (Sales Order) / ใบแจ้งหนี้ (Invoice) / ใบรับคืน / ใบลดหนี้ (Return / Credit Note) |
|
||||
| 5 | ระบบจัดซื้อ (Purchasing) | ใบขอซื้อ (Purchase Request) / ใบสั่งซื้อ (Purchase Order) / ใบแจ้งหนี้ซื้อ (Purchase Invoice) / ใบคืนสินค้าผู้ขาย (Supplier Return) |
|
||||
| 6 | ระบบการเงิน (Finance) | ใบวางบิลรับ / ใบเสร็จรับเงิน / ใบวางบิลจ่าย / ใบสำคัญจ่าย |
|
||||
| 7 | ระบบบัญชี (Accounting) | ผังบัญชี, แผนก, สูตรบัญชี / สมุดรายวันและบัญชีแยกประเภท (Journal / GL) / รายงานงบทดลอง, งบกำไรขาดทุน, งบดุล, ภาษีมูลค่าเพิ่ม |
|
||||
| 8 | ระบบรายงานและแดชบอร์ด | แดชบอร์ดคลังสินค้าและบัญชี / รายงานสต๊อก, ความเคลื่อนไหว, ความจุคลัง, สินค้าใกล้หมด, สินค้าหมดอายุ, Lot / กรอง ดู พิมพ์ และส่งออกรายงาน |
|
||||
| 9 | ระบบควบคุมเอกสาร | ออกเลขที่เอกสารอัตโนมัติตามลำดับที่กำหนด / ควบคุมสถานะและวงจรชีวิตของเอกสาร / บันทึกผู้สร้าง/ผู้แก้ไข/ประวัติรายการ |
|
||||
| 10 | ระบบแจ้งเตือนและงานตามกำหนดเวลา | แจ้งเตือนแบบ Real-time ผ่าน Node.js / Socket.IO / งานสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมด, ใบแจ้งหนี้ค้างชำระ ตามกำหนดเวลา |
|
||||
| 11 | ระบบติดตั้งและตั้งค่า | ติดตั้งแบบ Manual ผ่าน setup.php / ติดตั้งแบบ Container ผ่าน Docker Compose (php-apache, mariadb, node/pm2) / สร้างค่าตั้งค่าและความลับของระบบจาก .env โดยไม่เก็บใน Source Control |
|
||||
|
||||
### 3.3 สิ่งส่งมอบ (Work Products)
|
||||
|
||||
| รหัส | สิ่งส่งมอบ (Work Product) | รายละเอียด |
|
||||
| --- | --- | --- |
|
||||
| WP 1.0 | เอกสาร 200-WMS-26-001-00 Software Project Plan (พร้อม Work Schedule) | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 2.0 | เอกสาร 200-WMS-26-001-00 Customer Requirements | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 3.0 | เอกสาร 200-WMS-26-001-00 Software Requirements Specification | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 4.0 | เอกสาร 200-WMS-26-001-00 Software Design | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 5.0 | เอกสาร 200-WMS-26-001-00 Change Report | ส่งเอกสารจำนวน 3 ฉบับ (CH-001–CH-003) |
|
||||
| WP 6.0 | เอกสาร 200-WMS-26-001-00 Test Case and Test Procedures | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 7.0 | เอกสาร 200-WMS-26-001-00 Validation Results | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 8.0 | เอกสาร 200-WMS-26-001-00 Software User Document | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 9.0 | ระบบ BRN WMS ที่ผ่านการทดสอบพร้อมนำไปใช้งานจริง | ส่ง Source Code (Git baseline 6c39700) และติดตั้ง |
|
||||
| WP 10.0 | เอกสาร 200-WMS-26-001-00 Product Operation Guide | ส่งเอกสารจำนวน 1 ชุด |
|
||||
| WP 11.0 | เอกสาร 200-WMS-26-001-00 Maintenance Document | ส่งเอกสารจำนวน 1 ชุด |
|
||||
|
||||
### 3.4 Delivery Instruction
|
||||
|
||||
ในการส่งมอบตามสิ่งส่งมอบ (Work Product) เมื่อแล้วเสร็จและถึงกำหนดเวลา (Due Date) ผู้จัดการโครงการต้องจัดเตรียมเครื่องมือและสถานที่เพื่อให้ลูกค้าทำการทดสอบการยอมรับผู้ใช้ (Validation Result หรือ User Acceptance Test – UAT) โดยทดสอบตามข้อกำหนดในเอกสารความต้องการผู้ใช้ (Customer Requirements) ทีละข้อ และลงนามยืนยันเมื่อผ่านการทดสอบ
|
||||
|
||||
- **กรณีสิ่งส่งมอบไม่แล้วเสร็จตามกำหนด (Delay)** ผู้จัดการโครงการต้องนัดประชุมรายงานความคืบหน้าและอธิบายสาเหตุให้ลูกค้าทราบ พร้อมทั้งตกลงกำหนดวันส่งมอบใหม่อย่างเป็นทางการร่วมกัน
|
||||
- **การปิดโครงการ (Project Closure)** เมื่อสิ่งส่งมอบทั้งหมดผ่านการตรวจรับและได้รับลายเซ็นอนุมัติจากลูกค้าครบทุกชุดแล้ว ผู้จัดการโครงการจัดประชุมปิดโครงการอย่างเป็นทางการ พร้อมจัดทำเอกสารสรุปผลการดำเนินงานเพื่อเก็บเป็นหลักฐาน
|
||||
|
||||
### 3.5 เกณฑ์คุณภาพ (Quality Criteria)
|
||||
|
||||
**ด้านคุณภาพของระบบ**
|
||||
|
||||
| ลำดับ | หัวข้อ | เกณฑ์คุณภาพ | วิธีประเมิน |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1.1 | ความถูกต้องของฟังก์ชัน | ฟังก์ชันทั้งหมดทำงานตรงตาม Customer Requirements ครบ 100% | ทดสอบตาม Test Case และ UAT |
|
||||
| 1.2 | ความถูกต้องของข้อมูลสต๊อกและบัญชี | ไม่พบยอดสต๊อกติดลบหรือรายการ GL ที่ไม่สมดุล | ทดสอบ Transaction และ Rollback (TC-UN08.002) |
|
||||
| 1.3 | ความปลอดภัยของระบบ | ไม่พบข้อบกพร่องระดับวิกฤตด้านสิทธิ์และการแยกข้อมูล | ทดสอบสิทธิ์เชิงลบ (TC-UN12.001, TC-UN12.002) |
|
||||
| 1.4 | ประสิทธิภาพการตอบสนอง | งานประจำวันตอบสนองภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง | ทดสอบตามปริมาณข้อมูลตัวอย่าง (TC-UN09.001) |
|
||||
| 1.5 | ความสามารถในการเข้าถึง | ใช้งานได้บน Desktop, Tablet และ Mobile (Responsive) | ทดสอบข้ามอุปกรณ์ |
|
||||
|
||||
**ด้านการดูแลหลังส่งมอบ**
|
||||
|
||||
| ลำดับ | หัวข้อ | เกณฑ์คุณภาพ | วิธีประเมิน |
|
||||
| :---: | --- | --- | --- |
|
||||
| 2.1 | การตอบสนองเหตุขัดข้อง | ตอบรับภายใน 4 ชั่วโมง และแก้ไขตามระดับความรุนแรงที่กำหนดใน SLA | บันทึกการให้บริการ |
|
||||
| 2.2 | การสำรองข้อมูล | มีระบบสำรองข้อมูลอัตโนมัติรายวันและทดสอบกู้คืนได้จริง | Backup & Restore Test (TC-UN13.004) |
|
||||
| 2.3 | การเฝ้าระวังระบบ | ตรวจสอบสถานะบริการทุก 5 นาที และแจ้งเตือนเมื่อล้มเหลว 2 ครั้งติดกัน | บันทึกการเฝ้าระวัง |
|
||||
|
||||
## 4 Software Development Life Cycle Methodology
|
||||
|
||||
โครงการเลือกใช้แนวทาง Incremental / Evolutionary ภายใต้ขั้นตอนหลักของ Waterfall เนื่องจาก
|
||||
|
||||
- ขอบเขตและสิ่งส่งมอบกำหนดชัดเจนตั้งแต่ต้นโครงการ จึงวางแผนและตรวจรับเป็นงวดได้
|
||||
- ระบบมีหลายโมดูลที่ส่งมอบต่อเนื่องกัน จึงพัฒนาและทดสอบทีละส่วนเพื่อลดความเสี่ยง
|
||||
- เอกสารครบถ้วนตามมาตรฐาน ISO/IEC 29110 ที่เน้น Work Products และ Traceability
|
||||
- ตรวจสอบย้อนกลับ (Audit) และตรวจรับงานได้อย่างเป็นทางการ
|
||||
|
||||
| ขั้นตอน | แนวทางที่ใช้จริงในโครงการ |
|
||||
| --- | --- |
|
||||
| Requirements | เก็บความต้องการและตั้ง Baseline ก่อนเริ่มพัฒนา การเปลี่ยนแปลงภายหลังผ่าน Change Report (CH-001–CH-003) |
|
||||
| Design | ออกแบบสถาปัตยกรรม โครงสร้างฐานข้อมูล และ Software Unit ก่อนพัฒนาแต่ละโมดูล |
|
||||
| Implementation | พัฒนาเป็นโมดูลต่อเนื่องระหว่าง 19 ก.พ. – 29 พ.ค. 69 พร้อมทบทวนและแก้ไขระหว่างทาง |
|
||||
| Verification | ตรวจสอบ Work Products 4 รอบ ควบคู่กับการพัฒนา และรอบสุดท้ายก่อนส่งมอบ |
|
||||
| Validation | ทดสอบระบบและ UAT ระหว่าง 10–14 ส.ค. 69 บนสภาพแวดล้อมที่กำหนด |
|
||||
| Closure | ตรวจรับ อบรม ปิดงานควบคุมปฏิบัติการ และปิดโครงการภายใน 24 ส.ค. 69 |
|
||||
|
||||
## 5 Organization
|
||||
|
||||
### 5.1 Role & Responsibility
|
||||
|
||||
| ลำดับ | บทบาท | ชื่อ-นามสกุล (ชื่อย่อ) | อีเมล | รายละเอียดหน้าที่ |
|
||||
| :---: | --- | --- | --- | --- |
|
||||
| 1 | Project Manager (ApS) | คุณอภิรัชช์ สุภัทรประทีป | apirach.s@brn.co.th | จัดทำ Project Charter และแผนโครงการ / วางแผน Timeline, Resource, Risk, Quality / จัดประชุมและติดตามความคืบหน้า / ควบคุมการเปลี่ยนแปลงและการปิดโครงการ |
|
||||
| 2 | System Analyst (NoC) | คุณนพพงษ์ เจริญสุข | noppong.c@brn.co.th | เก็บและวิเคราะห์ความต้องการ / จัดทำ SRS และเอกสารออกแบบระบบ / ออกแบบฐานข้อมูลและความสัมพันธ์ของโมดูล / ตรวจสอบความสอดคล้องของงานพัฒนากับความต้องการ |
|
||||
| 3 | Developer (ThS) | คุณธนกร สถิตวิทยากุล | thanakorn.s@brn.co.th | พัฒนาโมดูลและ API ตามการออกแบบ / จัดการฐานข้อมูลและประสิทธิภาพ / ดูแลความปลอดภัยและการติดตั้ง / แก้ไขข้อบกพร่องที่พบจากการทดสอบ |
|
||||
| 4 | QA / Tester (PaNg) | คุณปริญ งามขำ | parin.n@brn.co.th | จัดทำ Test Case และ Test Procedures / ทดสอบระบบและบันทึกผล / ติดตามการแก้ไขข้อบกพร่องและทดสอบซ้ำ / สนับสนุนผู้ใช้งานช่วง UAT |
|
||||
| 5 | Document Control (YaB) | คุณเยาวลักษณ์ บางชมภู | yaowalak.b@brn.co.th | ควบคุมรหัสเอกสารและเวอร์ชัน / จัดเก็บและตรวจสอบความครบถ้วนของเอกสาร / ประสานการทบทวนและอนุมัติ / บันทึกประวัติการเปลี่ยนแปลงเอกสาร |
|
||||
| 6 | Project Sponsor (SeV) | คุณเสรี วิริยะสกุลธรณ์ | seri.v@brn.co.th | อนุมัติขอบเขต งบประมาณ และการเปลี่ยนแปลง / ตัดสินใจเชิงกลยุทธ์ / ทดสอบการยอมรับและตรวจรับส่งมอบ / อนุมัติปิดโครงการ |
|
||||
|
||||
## 6 Project Estimate
|
||||
|
||||
### 6.1 Size of the Software Work Products
|
||||
|
||||
| ลำดับ | Work Product | ปริมาณ (ประมาณการ) |
|
||||
| :---: | --- | --- |
|
||||
| 1 | เอกสารบริหารโครงการ (PM Process) | 10 รายการ |
|
||||
| 2 | เอกสารกระบวนการพัฒนา (SI Process) | 12 รายการ |
|
||||
| 3 | ความต้องการลูกค้า (Customer Requirements) | 80 รายการ (CR01–CR14) |
|
||||
| 4 | ความต้องการซอฟต์แวร์ (SRS) | 49 รายการ (SR01–SR09) |
|
||||
| 5 | Software Unit | 45 หน่วย (UN01–UN13) |
|
||||
| 6 | Test Case | 45 รายการ |
|
||||
| 7 | ตารางฐานข้อมูล | ประมาณ 50 ตาราง ใน 2 ฐานข้อมูล |
|
||||
|
||||
### 6.2 Effort Man-Day
|
||||
|
||||
| ลำดับ | ตำแหน่ง | หน้าที่หลัก | ระยะเวลา (Man-Day) |
|
||||
| :---: | --- | --- | ---: |
|
||||
| 1 | Project Manager | ควบคุมงาน ประสานงาน ติดตามแผน | 120 |
|
||||
| 2 | System Analyst | วิเคราะห์ความต้องการ ออกแบบระบบ | 60 |
|
||||
| 3 | Developer | พัฒนาระบบและแก้ไขข้อบกพร่อง | 100 |
|
||||
| 4 | QA / Tester | วางแผนทดสอบ ทดสอบระบบ UAT | 40 |
|
||||
| 5 | Document Control | ควบคุมเอกสารและหลักฐานโครงการ | 60 |
|
||||
|
||||
## 7 Project Resources
|
||||
|
||||
**Human Resource**
|
||||
|
||||
| ลำดับ | Team | จำนวน (คน) |
|
||||
| :---: | --- | ---: |
|
||||
| 1 | Project Management (PM, Document Control) | 2 |
|
||||
| 2 | Software Implementation (SA, Developer, QA) | 3 |
|
||||
| 3 | Project Sponsor / ตัวแทนลูกค้า | 1 |
|
||||
|
||||
**Computer Resource**
|
||||
|
||||
| ลำดับ | รายการ | จำนวน |
|
||||
| :---: | --- | --- |
|
||||
| 1 | Notebook สำหรับทีมพัฒนาและทดสอบ | 5 เครื่อง |
|
||||
| 2 | Git Server (Repository หลัก) | 1 ระบบ |
|
||||
| 3 | Internal Testing Server (PHP 8, MariaDB, Node.js) | 1 เครื่อง |
|
||||
| 4 | Production Server สำหรับใช้งานจริง | 1 เครื่อง |
|
||||
| 5 | เครื่องอ่านบาร์โค้ดสำหรับทดสอบ | 1 เครื่อง |
|
||||
|
||||
## 8 Work Schedule
|
||||
|
||||
แผนการดำเนินงานของโครงการ รวม 232 วัน ตั้งแต่ 5 มกราคม 2569 ถึง 24 สิงหาคม 2569 รายละเอียดกิจกรรม ผู้รับผิดชอบ และสิ่งส่งมอบรายกิจกรรม อยู่ในเอกสาร 200-WMS-26-001-00 Work Schedule ซึ่งเป็นส่วนหนึ่งของ Project Plan
|
||||
|
||||
| Phase | ช่วงเวลา | ผลลัพธ์หลัก |
|
||||
| --- | --- | --- |
|
||||
| Project Initiation | 5 มกราคม 2569 – 23 มกราคม 2569 | Statement of Work, Stakeholder Register, Project Charter |
|
||||
| Project Planning | 12 มกราคม 2569 – 18 กุมภาพันธ์ 2569 | Customer Requirements, Software Project Plan, Work Schedule |
|
||||
| Project Execution | 19 กุมภาพันธ์ 2569 – 29 พฤษภาคม 2569 | SRS, Software Design, ระบบที่พัฒนาแล้ว, Software Components |
|
||||
| Verification & Validation | 30 พฤษภาคม 2569 – 17 สิงหาคม 2569 | Test Case, Test Report, Verification Results, Validation Results |
|
||||
| Project Close | 10 สิงหาคม 2569 – 24 สิงหาคม 2569 | Acceptance Report, Training Report, List of Evidence |
|
||||
|
||||
## 9 Risk Management Plan
|
||||
|
||||
วัตถุประสงค์ของแผนบริหารความเสี่ยง คือระบุแนวทางจัดการความเสี่ยงของโครงการ เพื่อให้โครงการบรรลุเป้าหมายภายในเวลา งบประมาณ และคุณภาพที่กำหนด
|
||||
|
||||
| ลำดับ | หมวด | รายการ | รายละเอียด |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | ขอบเขต | ครอบคลุมทุกกิจกรรมของโครงการ | ตั้งแต่ Initiation, Planning, Execution จนถึง Close |
|
||||
| 2 | บทบาทผู้รับผิดชอบ | Project Manager (Owner), ทีมพัฒนา, Project Sponsor | PM ติดตามและควบคุมความเสี่ยง ทีมพัฒนารายงานความเสี่ยงให้ PM |
|
||||
| 3 | รอบการทบทวน | ทบทวนทุกงวดรายงานความก้าวหน้า | บันทึกความเสี่ยงใหม่และการเปลี่ยนแปลงระดับความเสี่ยงใน Progress Status Record |
|
||||
|
||||
**ตารางระบุความเสี่ยงหลักของโครงการ**
|
||||
|
||||
| ลำดับ | ความเสี่ยง (Risk) | ประเภท | โอกาสเกิด | ผลกระทบ | ระดับความเสี่ยง | แนวทางป้องกัน (Mitigation) | แผนรับมือ (Contingency Plan) | ผู้รับผิดชอบ |
|
||||
| :---: | --- | --- | :---: | :---: | :---: | --- | --- | :---: |
|
||||
| R1 | ความต้องการเปลี่ยนแปลงระหว่างพัฒนา | กระบวนการ | High | High | High | ตั้ง Baseline ความต้องการและทบทวนทุกงวด | จัดทำ Change Report และจัดลำดับความสำคัญใหม่ | ApS / NoC |
|
||||
| R2 | ทีมพัฒนาไม่เพียงพอหรือขาดทักษะเฉพาะทาง | บุคลากร | Middle | High | High | ถ่ายทอดความรู้ภายในทีมและจัดทำเอกสารประกอบ | ขออนุมัติจัดหาผู้เชี่ยวชาญเพิ่มเฉพาะงาน | ApS |
|
||||
| R3 | ยอดสินค้าคงคลังไม่ถูกต้อง | เทคโนโลยี | Middle | High | High | ใช้ Transaction, ตรวจสอบข้อมูลนำเข้า และล็อกรายการ | ตรวจสอบและปรับปรุงยอดพร้อมบันทึก Correction Register | ThS / PaNg |
|
||||
| R4 | ข้อมูลรั่วไหลข้ามบริษัทหรือสิทธิ์ไม่รัดกุม | ความปลอดภัย | Middle | High | High | บังคับ Role Guard และขอบเขตบริษัทฝั่งเซิร์ฟเวอร์ | ปิดช่องโหว่ทันทีและทดสอบสิทธิ์เชิงลบซ้ำ | ThS / PaNg |
|
||||
| R5 | ค่าตั้งค่าหรือความลับรั่วไหล | ความปลอดภัย | Middle | High | High | ยกเว้นไฟล์ตั้งค่าจาก Git และสร้างความลับตอนติดตั้ง | เปลี่ยนค่าความลับและตรวจสอบประวัติการเข้าถึง | ThS |
|
||||
| R6 | ข้อมูลสูญหายระหว่างพัฒนาหรือใช้งาน | เทคโนโลยี | Middle | High | High | สำรอง Git 2 Remote และสำรองฐานข้อมูลรายวัน | กู้คืนจากชุดสำรองตามขั้นตอนในคู่มือ | ThS |
|
||||
| R7 | หลักฐานการทดสอบและตรวจรับไม่ครบถ้วน | กระบวนการ | Middle | High | High | รักษาการสอบกลับสองทิศทางและบันทึกผลทุกครั้ง | ทดสอบซ้ำและบันทึกหลักฐานก่อนตรวจรับ | PaNg / YaB |
|
||||
| R8 | ผู้ใช้ไม่ยอมรับระบบ (UAT ไม่ผ่าน) | ผู้ใช้งาน | Middle | High | High | ให้ผู้ใช้ร่วมทบทวนความต้องการและสาธิตระบบระหว่างพัฒนา | ปรับปรุงตาม Feedback และทดสอบการยอมรับใหม่ | ApS / SeV |
|
||||
|
||||
## 10 Contingency Actions for Non-Completed Tasks
|
||||
|
||||
แผนรองรับสำหรับกรณีงานไม่แล้วเสร็จตามกำหนด (Non-Completed Task)
|
||||
|
||||
| ลำดับ | สถานการณ์ | สาเหตุที่พบบ่อย | ผลกระทบที่อาจเกิด | แผนรองรับเมื่อเกิดเหตุ | ผู้รับผิดชอบ |
|
||||
| :---: | --- | --- | --- | --- | --- |
|
||||
| 1 | งานไม่เสร็จภายในกำหนด (Due Date) | ประเมินเวลาผิดพลาด หรือทรัพยากรไม่เพียงพอ | กระทบ Timeline และกำหนดส่งมอบ | ประชุมด่วนเพื่อประเมินสถานะ จัดลำดับความสำคัญใหม่ ปรับแผน และแจ้งลูกค้าอย่างเป็นทางการ | ApS |
|
||||
| 2 | งานล่าช้าเพราะขาดบุคลากร | ลาป่วย ลาออก หรือไม่พร้อมปฏิบัติงาน | งานค้างสะสมและภาระงานกระจุกตัว | จัดทำเอกสารส่งมอบงาน ถ่ายทอดความรู้ให้ผู้ปฏิบัติแทน และขออนุมัติจัดหาผู้ช่วยเฉพาะงาน | ApS / ฝ่ายบุคคล |
|
||||
| 3 | งานค้างเพราะรอข้อมูลจากผู้ใช้ | ผู้ให้ข้อมูลส่งความต้องการหรือข้อมูลตั้งต้นล่าช้า | ไม่สามารถพัฒนาหรือทดสอบต่อได้ | แจ้งเตือนเป็นลายลักษณ์อักษร แยกงานที่ยังไม่พร้อมออก และนัดยืนยัน Timeline ใหม่ | ApS / SeV |
|
||||
| 4 | งานไม่เสร็จเพราะพบข้อบกพร่องซ้ำซ้อน | ความซับซ้อนสูงหรือขาดการทดสอบระยะแรก | เกิดความล่าช้าในการพัฒนาและทดสอบ | จัดลำดับข้อบกพร่องตามความรุนแรง แยกงานแก้ไขออกจากงานพัฒนาใหม่ และทดสอบซ้ำ | ThS / PaNg |
|
||||
| 5 | งานล่าช้าเพราะต้องแก้ความต้องการ | ขอบเขตเปลี่ยนหลังเริ่มงาน | กระทบแผนงานและสิ่งส่งมอบ | จัดทำ Change Report อย่างเป็นทางการ ประเมินผลกระทบ และขออนุมัติก่อนดำเนินการต่อ | ApS / SeV |
|
||||
|
||||
## 11 Document and Repository
|
||||
|
||||
**รูปแบบไฟล์ (File Format)** การกำหนดชื่อไฟล์ให้ใช้รูปแบบดังนี้
|
||||
|
||||
`[Project code] [Document name] [yyyymmdd] V[version] [editor name].[ext.]`
|
||||
|
||||
| หัวข้อ | รายละเอียด |
|
||||
| --- | --- |
|
||||
| [Project code] | รหัสโครงการตามส่วนงานบัญชี เช่น 200-WMS-26-001-00 |
|
||||
| [Document name] | ชื่อเอกสาร เช่น Progress Status Record |
|
||||
| [yyyymmdd] | วันที่ของเอกสารตามปีพุทธศักราช เช่น 25690817 |
|
||||
| [version] | เวอร์ชันของเอกสาร เช่น 1.0 |
|
||||
| [editor name] | ตัวย่อของชื่อผู้จัดทำ เช่น ApS |
|
||||
| [ext.] | นามสกุลไฟล์ เช่น pdf |
|
||||
|
||||
**การประกาศเวอร์ชัน (Version Declaration)** เก็บเอกสารแต่ละเวอร์ชันแยกไฟล์เพื่อให้ตรวจสอบย้อนหลังได้ โดยใช้รูปแบบ Major.Minor
|
||||
|
||||
| เวอร์ชัน (Version) | รายละเอียด |
|
||||
| --- | --- |
|
||||
| 0.1 (Draft) | ร่างเอกสารฉบับแรก |
|
||||
| 0.2 (Draft) | ปรับปรุงตามผลการทบทวน |
|
||||
| 1.0 (Release) | อนุมัติใช้เป็นเอกสารทางการ |
|
||||
| 1.1 (Revision) | ปรับปรุงเอกสารหลังอนุมัติ |
|
||||
|
||||
**Project Repository** ใช้ Git Server เป็นศูนย์กลางในการจัดเก็บและควบคุมเวอร์ชันของ Source Code และเอกสารทั้งหมดที่เกี่ยวข้องกับโครงการ
|
||||
|
||||
| ลำดับ | หัวข้อ | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ที่เก็บข้อมูล (Repository Location) | ทีมงานเข้าถึง Repository ผ่าน Git Server โดย Repository ของโครงการนี้เก็บทั้ง Source Code และเอกสาร ISO |
|
||||
| 2 | สิทธิ์การเข้าถึง (Access Control) | สมาชิกโครงการได้รับสิทธิ์ตามบทบาท โดย Project Manager และ System Analyst มีสิทธิ์อนุมัติการ Merge |
|
||||
| 3 | การจัดเก็บไฟล์งาน (File Storage Rules) | ไฟล์ที่เกี่ยวข้องกับโครงการต้องจัดเก็บใน Repository และไฟล์ที่สร้างจากเครื่องส่วนบุคคลต้องนำขึ้น Repository ภายในเวลาที่กำหนด |
|
||||
|
||||
**Project Repository Backup** เพื่อป้องกันการสูญหายของข้อมูลใน Git Server
|
||||
|
||||
| ลำดับ | หัวข้อ | รายละเอียด |
|
||||
| :---: | --- | --- |
|
||||
| 1 | ผู้รับผิดชอบ (Responsibility) | มอบหมาย Developer ตรวจสอบความถูกต้องของข้อมูลสำรองอย่างสม่ำเสมอ |
|
||||
| 2 | วิธีการสำรองข้อมูล (Backup Methods) | ซิงก์ Repository ไปยัง Backup Remote และสำรองฐานข้อมูลด้วยการ Export อัตโนมัติ |
|
||||
| 3 | รอบการสำรองข้อมูล (Backup Frequency) | ฐานข้อมูลสำรองทุกวันเวลา 02:00 น. และ Repository ซิงก์ทุกครั้งที่มีการส่งมอบ |
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณอภิรัชช์ สุภัทรประทีป | Project Manager | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเยาวลักษณ์ บางชมภู | Document Control | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-437
@@ -1,437 +0,0 @@
|
||||
# Software Project Plan
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Software Project Plan |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Warehouse Management System Development Project Plan |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 Final |
|
||||
| Planning baseline | 05/01/26 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Project Manager | Apirach Supattaratpateep |
|
||||
| Status | Final — reviewed and authorized |
|
||||
|
||||
## Revision history
|
||||
|
||||
| Version | Date | Change | Prepared by |
|
||||
|---|---|---|---|
|
||||
| V1.0 | 17/08/26 | Initial controlled issue. Consolidates the 05/01/26 planning baseline with lifecycle, quality, equipment-evidence, and configuration outcomes recorded through closure preparation. | Apirach Supattaratpateep |
|
||||
|
||||
Sections 6, 8.5, 12.2 and 16 describe outcomes as at 17/08/26; the remaining sections retain the 05/01/26 planning baseline.
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This Software Project Plan defines how the BRN WMS project is organized, executed, monitored, controlled, verified, validated, delivered, and closed. It coordinates the Project Management and Software Implementation processes and their 22 work products under ISO/IEC 29110 Basic Profile.
|
||||
|
||||
### 1.1 Standards basis and applicability
|
||||
|
||||
BRN WMS applies the ISO/IEC 29110 software engineering Generic Basic Profile for one non-safety-critical software product developed by one project team under a customer project agreement. The standards basis for this project is:
|
||||
|
||||
- **ISO/IEC 29110-4-1:2018** — Software engineering profile specifications for the Generic profile group, including the Basic profile.
|
||||
- **ISO/IEC 29110-5-1-2:2025** — Software engineering management and engineering guidelines for the Generic Basic profile.
|
||||
|
||||
| Applicability item | BRN WMS application |
|
||||
|---|---|
|
||||
| Profile group | Generic profile group |
|
||||
| Profile | Basic profile |
|
||||
| Engineering discipline | Software engineering |
|
||||
| Project organization | One project team with assigned management, analysis, development, testing, document-control, and customer-approval roles |
|
||||
| Product scope | One browser-based warehouse management software product and its supporting deployment/service components |
|
||||
| Agreement | Customer project agreement controlled through the Statement of Work and Customer Requirements |
|
||||
| Safety criticality | Non-safety-critical software |
|
||||
| Management process | Project Management |
|
||||
| Engineering process | Software Implementation |
|
||||
| Lifecycle | Incremental/evolutionary implementation with controlled requirements, configuration baselines, verification, validation, and acceptance |
|
||||
| Tailoring principle | Work-product structure and detail are scaled to BRN WMS size and complexity while retaining controlled content, responsibility, review, and traceability |
|
||||
|
||||
### 1.2 Work-product tailoring
|
||||
|
||||
- Project Plan content is controlled across the Work Schedule, this Software Project Plan, and Customer Requirements.
|
||||
- The Software work product is the Git-controlled application baseline; work product 17 is its controlled identification and repository pointer record.
|
||||
- The Traceability Record (work product 13) is the master requirements matrix. The additional Traceability Record Table is a summary/pointer and does not create a second competing baseline.
|
||||
- Test Cases and Test Procedures defines the tests and records their execution status; the separate Test Report consolidates the results and disclosed evidence limitations.
|
||||
- The Project Charter Report, Stakeholder Register, List of Evidence, Traceability Record Table, and Training Report supplement the Basic-profile work products without replacing them.
|
||||
- Markdown files under `sdlc/` are the controlled editable document sources. PDFs under `sdlc-delivery/` are generated delivery/printing outputs and are not edited independently.
|
||||
- No Project Management or Software Implementation process is declared excluded. Content granularity is scaled where documented, including requirement-level traceability for the 34 controlled requirements.
|
||||
|
||||
## 2. Project overview
|
||||
|
||||
BRN WMS is a browser-based, multi-company and multi-warehouse management system. It centralizes warehouse master data, inventory movements, sales and purchasing documents, finance and accounting records, reports, access control, and operational notifications.
|
||||
|
||||
The project is intended to:
|
||||
|
||||
- Improve the accuracy and timeliness of warehouse operations.
|
||||
- Provide current stock visibility across authorized warehouses and locations.
|
||||
- Preserve lot, serial-number, expiry-date, and movement traceability.
|
||||
- Control sales, purchasing, return, invoice, receipt, payment, and accounting workflows.
|
||||
- Separate company data and restrict functions according to authorized roles.
|
||||
- Provide management reports, operational alerts, and auditable records.
|
||||
|
||||
## 3. Scope
|
||||
|
||||
### 3.1 Included scope
|
||||
|
||||
- Company, user, role, application-access, SMTP, and system configuration.
|
||||
- Contact, product, category, warehouse, storage-area, and bin master data.
|
||||
- Stock-in, stock-out, stock transfer, balance, lot, serial number, and expiry control.
|
||||
- Warehouse capacity, occupancy, movement, expired-stock, and product-lot reporting.
|
||||
- SKU and warehouse-location barcode labels and supported scanning workflows.
|
||||
- Quotations, sales orders, returns, invoices, and credit notes.
|
||||
- Purchase requests, purchase orders, purchase invoices, and supplier returns.
|
||||
- Receipt billing, receipts, payment billing, and payments.
|
||||
- Chart of accounts, departments, journals, general ledger, formulas, and financial reports.
|
||||
- Controlled document numbering and lifecycle/status handling.
|
||||
- Real-time notifications using Node.js and Socket.IO.
|
||||
- Scheduled stock/GL maintenance, low-stock alerts, and overdue-invoice alerts.
|
||||
- Deployment configuration, database setup, operating guidance, and maintenance information.
|
||||
- ISO/IEC 29110 work products and controlled project repository.
|
||||
|
||||
### 3.2 Excluded scope
|
||||
|
||||
- Procurement of servers, networks, barcode scanners, printers, or user devices.
|
||||
- Legacy-data migration unless separately assessed and approved.
|
||||
- Integration with external ERP, banking, shipping, tax, or third-party services unless approved through change control.
|
||||
- Custom functionality outside the baselined requirements.
|
||||
- Production hosting or third-party subscription fees unless separately authorized.
|
||||
|
||||
## 4. Objectives and success criteria
|
||||
|
||||
The project is successful when:
|
||||
|
||||
- All acceptance-critical requirements are implemented and traceable to verification evidence.
|
||||
- Representative warehouse, sales, purchasing, finance, and accounting workflows pass validation.
|
||||
- No unresolved critical defect blocks intended operation or compromises security or data integrity.
|
||||
- Installation, configuration, user, operation, and maintenance documentation is available.
|
||||
- Software and controlled work products are stored in the project repository.
|
||||
- Verification, validation, and acceptance records receive the required review and authorization.
|
||||
|
||||
## 5. Lifecycle and schedule
|
||||
|
||||
| Phase | Period | Main activities | Primary outputs |
|
||||
|---|---:|---|---|
|
||||
| Initiation | 05/01/26–23/01/26 | Establish need, stakeholders, objectives, scope, and authority. | Statement of Work, stakeholder records |
|
||||
| Planning | 12/01/26–18/02/26 | Collect requirements; define schedule, resources, risks, controls, and baselines. | Customer Requirements, Work Schedule, Software Project Plan |
|
||||
| Implementation | 19/02/26–29/05/26 | Analyze, design, code, configure, integrate, review, and test the system. | SRS, Software Design, Components, Test Cases, Software |
|
||||
| Verification and validation | 30/05/26–07/08/26 | Review work products and validate representative operational workflows. | Traceability, Test Report, Verification and Validation Results |
|
||||
| Documentation and stabilization | 01/06/26–24/08/26 | Prepare guides, close corrections, configure deployment, and prepare demonstration data. | User Documentation, Operation Guide, Maintenance Documentation |
|
||||
| Closure | 10/08/26–24/08/26 | Review repository, resolve open actions, obtain acceptance, and close the project. | Acceptance Report, List of Evidence, repository baseline |
|
||||
|
||||
Detailed activities and evidence are maintained in the Work Schedule.
|
||||
|
||||
## 6. Software development lifecycle methodology
|
||||
|
||||
BRN WMS follows an incremental/evolutionary development approach, with features, modules, and security corrections delivered throughout implementation.
|
||||
|
||||
BRN WMS is more accurately described as **incremental/evolutionary**, within the same overall lifecycle stages used for planning and reporting purposes (Section 5):
|
||||
|
||||
| Stage | How it was actually approached |
|
||||
|---|---|
|
||||
| Requirements | Captured once at a level (Customer Requirements), then implicitly refined as implementation proceeded — e.g., the Rack→Bin terminology change (CH-001) and multiple onboarding/security corrections show requirements being clarified during implementation, not frozen beforehand |
|
||||
| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was derived from the as-built architecture, not authored before coding began |
|
||||
| Implementation | Continuous, feature-by-feature, evidenced by 100 commits across the implementation period (19/02/26–29/05/26; 110 in the repository overall) with no clean phase boundary between "build" and "test/fix" |
|
||||
| Verification | Interleaved throughout implementation (ongoing manual exercising and correction, per the Correction Register) rather than concentrated in a single verification phase; formal Round 2A document-control and Round 2B technical work-product verification was completed on 17/08/26 and recorded in work product 21 |
|
||||
| Stabilization/closure | A distinct late-stage effort (03/08/26 onward) closer to a traditional stabilization phase |
|
||||
|
||||
## 7. Organization and responsibilities
|
||||
|
||||
| Role | Assigned person | Responsibilities |
|
||||
|---|---|---|
|
||||
| Project Sponsor / Customer Representative / Authorized Approver | Seri Viriyasakultorn | Represent customer needs; authorize scope, resources, baseline changes, acceptance, and project closure. |
|
||||
| Project Manager | Apirach Supattaratpateep | Plan and monitor work; assign responsibilities; manage risks, issues, communication, changes, and closure. |
|
||||
| System Analyst | Noppong Chareunsook | Analyze customer requirements, specify system behavior, and maintain technical traceability. |
|
||||
| Developer | Thanakorn Sathitwitayakul | Design, implement, configure, correct, and maintain source code, aligned with Git implementation evidence. |
|
||||
| Tester / Reviewer | Parin Ngamkham | Prepare and execute tests, review work products, report defects, and confirm corrections. |
|
||||
| Document Control | Yaowalak Bangchomphoo | Control identifiers, versions, approvals, distribution, repository content, and evidence. |
|
||||
|
||||
One person may perform more than one operational role when independence is not mandatory. Approval authority must remain with the designated authorized approver or a formally delegated authority.
|
||||
|
||||
## 8. Resources and environment
|
||||
|
||||
### 8.1 Schedule summary
|
||||
|
||||
| Phase | Calendar span | Approx. duration |
|
||||
|---|---|---:|
|
||||
| Initiation | 05/01/26–23/01/26 | 19 days |
|
||||
| Planning | 12/01/26–18/02/26 | 38 days |
|
||||
| Implementation | 19/02/26–29/05/26 | 100 days |
|
||||
| Verification and validation | 30/05/26–07/08/26 | 70 days |
|
||||
| Documentation and stabilization | 01/06/26–24/08/26 | 85 days |
|
||||
| Closure | 10/08/26–24/08/26 | 15 days |
|
||||
|
||||
These are calendar spans rather than effort estimates.
|
||||
|
||||
### 8.2 Software and infrastructure
|
||||
|
||||
- PHP 8.0 or later.
|
||||
- MySQL or MariaDB.
|
||||
- Nginx or another compatible PHP web server.
|
||||
- Node.js, npm, Socket.IO, and PM2 for real-time and scheduled services.
|
||||
- Git repository with `main` as the controlled integration baseline.
|
||||
- Current standards-based desktop and mobile browsers.
|
||||
- Asia/Bangkok time zone across application and scheduled-job environments.
|
||||
|
||||
### 8.3 Logical application components
|
||||
|
||||
| Component | Purpose |
|
||||
|---|---|
|
||||
| PHP web application | Main user interface and operational APIs |
|
||||
| Identity/company database | Users, companies, access, SMTP, usage, and related configuration |
|
||||
| WMS/accounting database | Warehouse, inventory, documents, finance, and accounting records |
|
||||
| Node.js notification service | Browser notifications and application event relay |
|
||||
| Node.js scheduler | Aggregate maintenance and scheduled operational alerts |
|
||||
|
||||
### 8.4 Configuration constraints
|
||||
|
||||
- Local configuration and secrets must not be committed to Git.
|
||||
- Production database credentials must use the minimum privileges required after installation.
|
||||
- Application, database, upload, and service configuration must follow the controlled configuration guide.
|
||||
- Public access to source-control metadata, secrets, and internal service endpoints must be restricted.
|
||||
|
||||
### 8.5 Computer and equipment resources
|
||||
|
||||
The example reference package's Section 7 lists specific equipment (notebook count, scanner, Git server, software licenses). No equipment inventory record exists as project evidence for BRN WMS — this is not fabricated here. What is evidenced instead:
|
||||
|
||||
| Item | Evidence |
|
||||
|---|---|
|
||||
| Git hosting | Primary remote `origin` (`188.166.228.62:nok/wms-app.git`) and backup remote `backup` (GitHub) — see Project Repository, work product 9 |
|
||||
| Deployment target | Manual LAMP install or Docker Compose stack (`php-apache`, `mariadb`, `node/pm2`) — see Software Configuration, work product 8, and Product Operation Guide, work product 19 |
|
||||
| Developer workstation(s) | Not recorded — no inventory evidence exists |
|
||||
| Office/licensed software (word processor, spreadsheet, etc.) | Not recorded — no inventory evidence exists |
|
||||
|
||||
## 9. Deliverables and work products
|
||||
|
||||
### 9.1 Project Management work products
|
||||
|
||||
1. Statement of Work
|
||||
2. Project Plan, including Work Schedule, Software Project Plan, and Customer Requirements
|
||||
3. Progress Status Record
|
||||
4. Correction Register
|
||||
5. Acceptance Report
|
||||
6. Change Report
|
||||
7. Meeting Record
|
||||
8. Software Configuration
|
||||
9. Project Repository
|
||||
10. Project Repository Backup
|
||||
|
||||
### 9.2 Software Implementation work products
|
||||
|
||||
11. Software Requirements Specification
|
||||
12. Software Design
|
||||
13. Traceability Record
|
||||
14. Software Components
|
||||
15. Test Cases and Test Procedures
|
||||
16. Test Report
|
||||
17. Software
|
||||
18. Software User Documentation
|
||||
19. Product Operation Guide
|
||||
20. Maintenance Documentation
|
||||
21. Verification Results
|
||||
22. Validation Results
|
||||
|
||||
## 10. Monitoring and communication
|
||||
|
||||
| Record or activity | Frequency or trigger | Owner | Audience |
|
||||
|---|---|---|---|
|
||||
| Work Schedule update | At least weekly during active work | Project Manager | Project team and sponsor |
|
||||
| Progress Status Record | Weekly during active work | Project Manager | Project team and sponsor |
|
||||
| Project meeting | At planned reviews or when decisions are required | Project Manager | Relevant stakeholders |
|
||||
| Meeting Record | For each formal project/review meeting | Recorder | Attendees and affected stakeholders |
|
||||
| Correction Register | When a defect, issue, or nonconformity is identified | Tester / Project Manager | Assigned owner and reviewer |
|
||||
| Change Report | When a baseline change is requested | Project Manager | Sponsor, affected team, customer representative |
|
||||
| Repository review | At each baseline and project closure | Document Control | Project Manager and reviewer |
|
||||
|
||||
Progress status includes completed work, planned work, deviations, risks, issues, required decisions, corrective actions, and schedule impact.
|
||||
|
||||
## 11. Risk management
|
||||
|
||||
| ID | Risk | Impact | Planned response / control | Owner |
|
||||
|---|---|---|---|---|
|
||||
| R-01 | Pre-development planning records were prepared after the fact | Audit evidence may be weaker than the records suggest. | Mark assumptions clearly and obtain review and approval. | Project Manager |
|
||||
| R-02 | Unauthorized access or cross-company data exposure | Confidentiality and integrity failure. | Server-side role guards, company/warehouse scoping, session controls, and security review. | Developer / Reviewer |
|
||||
| R-03 | Incorrect inventory balance | Operational and financial records become unreliable. | Transactions, input validation, locking, approval flow, reconciliation, and movement tests. | Developer / Tester |
|
||||
| R-04 | Secret or configuration exposure | System compromise or service interruption. | Ignore local secrets, provide templates, restrict web access, and review deployment configuration. | Configuration Manager |
|
||||
| R-05 | Incomplete requirement or acceptance evidence | Delivery cannot be objectively demonstrated. | Maintain bidirectional traceability and obtain signatures before baselining. | Project Manager |
|
||||
| R-06 | Uncontrolled scope expansion | Schedule and quality degradation. | Require Change Report, impact analysis, authorization, and re-planning. | Project Manager / Sponsor |
|
||||
| R-07 | Inadequate backup or recovery | Loss of source, documents, or operational data. | Maintain repository backup and documented database/file backup and recovery procedures. | Configuration Manager |
|
||||
| R-08 | Third-party or environment incompatibility | Deployment or notification failure. | Document supported versions and verify the target environment before acceptance. | Developer / System Administrator |
|
||||
|
||||
Risks are reviewed with progress status. New risks and changes to exposure or response are recorded by the Project Manager.
|
||||
|
||||
### 11.1 Contingency actions for non-completed tasks
|
||||
|
||||
Distinct from the risk table above (which addresses project-level threats), this table addresses the specific, recurring situation of an individual task or work product not finishing by its planned date.
|
||||
|
||||
| Situation | Common cause | Likely impact | Contingency action | Owner |
|
||||
|---|---|---|---|---|
|
||||
| Task not finished by its due date | Timeline or resource estimate was too tight | Downstream tasks slip; delivery date at risk | Meet with the team to reassess status and priority; agree and communicate a revised timeline | Project Manager |
|
||||
| Delay due to insufficient staffing (illness, unavailability) | Single-person roles (Section 7) have no backup | Work stalls until the person returns | Document a handover/knowledge-transfer note; consider temporary outside help for the specific gap only with Sponsor authorization | Project Manager |
|
||||
| Delay due to late or incomplete requirement/content input | Upstream dependency (customer input, data) not ready | Downstream development or testing cannot proceed | Escalate to the Sponsor with a clear description of what is blocking; agree a revised input date | Project Manager |
|
||||
| Delay due to unexpected technical complexity | Underestimated integration/defect complexity discovered during work | Task takes materially longer than planned | Prioritize by severity (Critical/High/Low, per Section 12.1); temporarily set aside lower-priority items | Developer |
|
||||
| Delay because scope changed mid-task | Requirement changed after work started | Effort already spent may be partially invalidated | Raise a Change Report; obtain authorization before continuing under the new scope | Project Manager |
|
||||
|
||||
## 12. Quality assurance
|
||||
|
||||
- Assign a unique identifier to each approved requirement.
|
||||
- Review requirements for clarity, completeness, consistency, testability, and scope alignment.
|
||||
- Review design against requirements and operational constraints.
|
||||
- Review implementation for authorization, tenant isolation, data integrity, configuration safety, and error handling.
|
||||
- Trace requirements to design elements, components, test cases, and results.
|
||||
- Record defects and nonconformities in the Correction Register.
|
||||
- Re-test corrected behavior and retain objective evidence.
|
||||
- Validate representative end-to-end scenarios with customer-oriented data.
|
||||
|
||||
### 12.1 Defect disposition
|
||||
|
||||
| Severity | Meaning | Acceptance treatment |
|
||||
|---|---|---|
|
||||
| Critical | Prevents core operation, compromises security, causes cross-company exposure, or corrupts essential data. | Must be corrected and verified before acceptance. |
|
||||
| Major | Material function fails without an acceptable workaround. | Correct before acceptance or obtain explicit authorized disposition. |
|
||||
| Minor | Limited impact with an acceptable workaround. | Record planned correction or authorized acceptance. |
|
||||
| Observation | Improvement or documentation item without functional failure. | Record and prioritize as appropriate. |
|
||||
|
||||
### 12.2 Quality criteria and evaluation methods
|
||||
|
||||
The example reference package states measurable quality thresholds directly in the Software Project Plan (response time, uptime, security scan result, etc.). BRN WMS's measurable criteria are already defined as non-functional requirements in Customer Requirements (Section 8) and restated as technical requirements in the SRS (work product 11); this table cross-references them here rather than duplicating a second copy that could drift out of sync.
|
||||
|
||||
| Quality area | Criterion | Evaluation method | Reference |
|
||||
|---|---|---|---|
|
||||
| Functional correctness | All Must requirements implemented and traceable | Traceability Record review + Test Report execution | NFR-009, work products 13, 16 |
|
||||
| Performance | Practical operational response time; aggregates support dashboards/reports | Representative-operation timing under agreed data volume | NFR-006, SR05:001–003, TC-NFR-006 |
|
||||
| Security | No unresolved critical security defect; server-side auth/tenant scope enforced | Negative-authorization/invalid-input testing | NFR-002, SR07:001–005, TC-NFR-002 |
|
||||
| Reliability/integrity | No invalid negative/duplicate stock or GL movement | Failure/rollback and concurrency test | NFR-003, SR09:003, TC-NFR-003 |
|
||||
| Usability | Responsive UI usable on desktop and warehouse-floor devices | Representative-screen check at agreed viewport sizes | NFR-005, SR02:002, TC-NFR-005 |
|
||||
| Installability | Installation/configuration/backup/recovery repeatable | Follow Product Operation Guide end-to-end | NFR-004, TC-NFR-004 |
|
||||
| Post-delivery support | Backup and restoration | Restoration check performed manually by the Developer | Project Repository (Backup), work product 10 |
|
||||
|
||||
Actual results belong in the Test Report and Verification/Validation Results, which show 34 of 34 passed and 12 of 12 passed, executed 10/08/26–14/08/26 (see the Acceptance Report's current-status note).
|
||||
|
||||
## 13. Verification and validation
|
||||
|
||||
Verification confirms that each work product satisfies its specified inputs and criteria. Validation confirms that the integrated BRN WMS supports its intended operational use.
|
||||
|
||||
Verification covers:
|
||||
|
||||
- Customer Requirements and Software Requirements Specification.
|
||||
- Software Design and database/configuration design.
|
||||
- Software Components and integration behavior.
|
||||
- Test Cases, Test Procedures, Test Report, and traceability.
|
||||
- User, operation, configuration, and maintenance documentation.
|
||||
|
||||
Validation covers representative workflows for:
|
||||
|
||||
- User onboarding and role-based access.
|
||||
- Warehouse and product configuration.
|
||||
- Stock receipt, issue, transfer, balance, lot, serial, and expiry handling.
|
||||
- Sales, purchasing, return, invoice, receipt, and payment workflows.
|
||||
- Accounting postings and management reports.
|
||||
- Notifications, scheduled jobs, and operational recovery.
|
||||
|
||||
## 14. Configuration management
|
||||
|
||||
Configuration items include:
|
||||
|
||||
- PHP, JavaScript, CSS, Node.js, and database/setup source files.
|
||||
- Application and service configuration templates.
|
||||
- Database schema and migration/setup logic.
|
||||
- Controlled requirements, design, test, guide, and management work products.
|
||||
- Approved releases, evidence, and repository backups.
|
||||
|
||||
Controls include:
|
||||
|
||||
- Controlled `main` baseline.
|
||||
- Project-code-based filenames and document version/status identifiers.
|
||||
- Review and authorization before changing an approved baseline.
|
||||
- Exclusion of passwords, tokens, local configuration, logs, uploads, and generated secrets from source control.
|
||||
- Repository and operational-data backup with recoverability checks.
|
||||
|
||||
## 15. Change and correction control
|
||||
|
||||
A baseline change follows this sequence:
|
||||
|
||||
1. Record the requested change and reason.
|
||||
2. Analyze its scope, schedule, technical, quality, security, and documentation impact.
|
||||
3. Obtain authorization from the designated authority.
|
||||
4. Update affected plans, requirements, design, traceability, tests, and configuration records.
|
||||
5. Implement and verify the change.
|
||||
6. Record the result and close the Change Report.
|
||||
|
||||
Defects and nonconformities are recorded in the Correction Register, assigned to an owner, corrected, re-tested, and closed with evidence.
|
||||
|
||||
## 16. Repository and document control
|
||||
|
||||
### 16.1 File naming convention
|
||||
|
||||
BRN WMS's actual naming convention, in force since PM work product 1 and used consistently across all 46 controlled files, differs deliberately from the example reference project's:
|
||||
|
||||
`[Project code] [Document name] [YYYYMMDD Buddhist] V[version]`, for example `200-WMS-26-001-00 Correction Register 25690817 V1.0`.
|
||||
|
||||
| Element | Meaning | Example |
|
||||
|---|---|---|
|
||||
| Project code | `200-WMS-26-001-00` | Fixed |
|
||||
| Document name | Descriptive title; where a work product has multiple instances (Progress Status Record, Change Report, Meeting Record), a short distinguishing suffix is added | `- Rack to Bin Rename` |
|
||||
| Date | Compact Buddhist-calendar date (`YYYYMMDD`), matching the date on the document header | `25690817` |
|
||||
| Version | `V<major>.<minor>`, e.g. `V1.0` | `V1.0` |
|
||||
|
||||
BRN WMS document filenames do not append author initials.
|
||||
|
||||
### 16.2 Version declaration
|
||||
|
||||
Documents created for BRN WMS are released directly at `V1.0` once content is complete, without the example's separate `0.1`/`0.2` Draft stages — BRN WMS work products are not labeled `Draft` unless explicitly requested, per the same recorded decision. "Final" in the document-control Status field means the controlled content is complete; authorization and the project-acceptance decision are recorded in each document's Approval section and the Acceptance Report.
|
||||
|
||||
### 16.3 Repository and backup
|
||||
|
||||
- Every controlled filename starts with `200-WMS-26-001-00`.
|
||||
- Documents identify title, date, version, status, preparer, reviewer, and approver as applicable.
|
||||
- Drafts remain distinguishable from approved baselines.
|
||||
- The Project Repository contains the current controlled work products and supporting evidence (work product 9).
|
||||
- The repository backup is maintained separately and checked during project closure (work product 10); BK-001–BK-004 are closed, including restoration, complete delivery packaging, and synchronization and retrieval verification of the final `sdlc` branch and release tag on 24/08/26.
|
||||
- Superseded records are retained or archived according to organizational control practices.
|
||||
|
||||
## 17. Acceptance and closure
|
||||
|
||||
The project may close when:
|
||||
|
||||
- Acceptance-critical requirements have passed their linked verification and validation.
|
||||
- No unresolved critical defect remains.
|
||||
- Deferred items and accepted exceptions have authorized dispositions.
|
||||
- Required user, operation, configuration, and maintenance documents are available.
|
||||
- Software, source, setup information, evidence, and required work products are in the repository.
|
||||
- The Acceptance Report and closure decision are signed by the authorized approver.
|
||||
|
||||
## 18. Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
|
||||
Role: Project Manager
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Technical contributor
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
|
||||
Role: Developer
|
||||
|
||||
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: ___________________________________________________
|
||||
-276
@@ -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: ___________________________________________________
|
||||
+149
@@ -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 | | |
|
||||
Reference in New Issue
Block a user