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

SDLC docs

Browse Source
This commit is contained in:
Thanakorn
2026-08-17 17:09:27 +07:00
parent 3045c4a8ef
commit 39201df36e
49 changed files with 4763 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sdlc/1-PM Process (10 Work Product)/2.Project Plan/1-Work Schedule/200-WMS-26-001-00 Work Schedule 25690105 V1.0 Final.md
+92
View File
@@ -0,0 +1,92 @@
# 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 |
| Revised closure target | 24/08/26 — approved through CH-004; original period retained as baseline |
| Release | 05/01/26 V1.0 Final |
| Standard | ISO/IEC 29110 Basic Profile |
| Status | Final — ready for authorized approval |
## Schedule basis
The original formal project period is 05/01/26–14/08/26. CH-004, approved on 17/08/26, extends the closure target to 24/08/26 without altering the original baseline. Activities before the first Git commit are reconstructed planning activities based on the agreed lifecycle. Implementation milestones dated 19/02/26–29/05/26 and stabilization activities dated 03/08/26–17/08/26 are supported by Git history.
| 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 | Reconstructed 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 | Reconstructed 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 | Pending signature | Authority signature required |
| 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 | Reconstructed 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 | Reconstructed 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 | Git commits `9a50080`–`1843308` | Completed | Git evidenced |
| 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 | Git commits `93d903c`–`a4f474b` | Completed | Git evidenced |
| 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 | Git evidenced |
| 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 | Git evidenced |
| 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 | Git evidenced |
| 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 | Git evidenced |
| 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 | Git evidenced |
| 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 | Git evidenced |
| 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 commits | Completed | Git evidenced |
| 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 | Git commit `a0677d6` | Completed | Development substantially complete |
| 4.1 | Control | Maintain progress and meeting records | Track progress, issues, decisions, risks, and corrective actions throughout the project. | Project Manager / Document Control | 05/01/26 | 14/08/26 | 160 days | Progress Status, Meeting Records, Correction Register | Completed | Records require evidence review |
| 4.2 | Control | Configuration and repository control | Control source, baselines, document versions, configuration, and backups. | Configuration Manager | 19/02/26 | 14/08/26 | 127 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 | Overdue / not completed — scheduled period elapsed | Traceability Record complete (34/34 requirements linked); Verification Results is a Round 1 self-review by the document preparer only — independent verification not yet performed |
| 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 — retrospective user-confirmed execution | All 34 test cases and 12 validation scenarios were retrospectively confirmed as executed and passed on 17/08/26; actual execution dates, environment, and attendees 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 | Reconstructed 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 | Git commit `b2c4374` | Completed | Git evidenced |
| 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 | Git commit `dd48a8b` | Completed | Git evidenced |
| 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 ahead of revised target | Independent verification and review completion confirmed retrospectively by the project user 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 and closure record | Completed ahead of revised target | Project Sponsor authorization confirmed retrospectively by the project user on 17/08/26; signature capture remains administrative follow-up |
## Milestones
| Milestone | Date | Basis |
|---|---:|---|
| Formal project start | 05/01/26 | Agreed reconstructed project boundary |
| Requirements and planning baseline | 18/02/26 | Planned pre-development completion |
| Development start | 19/02/26 | First Git commit: `init wms` |
| Development substantially complete | 29/05/26 | Final main-development refactoring commit |
| Post-development correction | 03/08/26 | Login and configuration correction commit |
| Demonstration data and original completion boundary | 14/08/26 | Final repository commit within original baseline |
| Revised closure target | 24/08/26 | Approved schedule extension through CH-004 |
## Approval
### Prepared by
Name: คุณอภิรัชต์ สุภัทรประทีป
Role: Project Manager / Document Creator
Signature: ______________________________________________
Date: ___________________________________________________
### Technical contributor
Name: ธนกร สถิตวิทยากุล
Role: Developer / System Analyst
Signature: ______________________________________________
Date: ___________________________________________________
### Reviewed and authorized by
Name: คุณเสรี วิริยะสกุลธรณ์
Project roles: Project Sponsor / Customer Representative / Authorized Approver
Position: กรรมการผู้จัดการ
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
Signature: ______________________________________________
Date: ___________________________________________________
sdlc/1-PM Process (10 Work Product)/2.Project Plan/2-Software Project Plan/200-WMS-26-001-00 Software Project Plan 25690105 V1.0 Final.md
+414
View File
@@ -0,0 +1,414 @@
# Software Project Plan
| Document field | Value |
|---|---|
| Document | Software Project Plan |
| Project | BRN WMS |
| Project code | 200-WMS-26-001-00 |
| Title | แผนการดำเนินโครงการพัฒนาระบบบริหารจัดการคลังสินค้า |
| Project period | 05/01/26–24/08/26 |
| Release | 05/01/26 V1.0 Final |
| Standard | ISO/IEC 29110 Basic Profile |
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
| Status | Final — ready for review and authorized approval |
## 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.
Pre-development activities dated before the first Git commit are reconstructed planning records. Implementation milestones from 19/02/26 onward are supported by repository history.
## 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–14/08/26 | Prepare guides, close corrections, configure deployment, and prepare demonstration data. | User Documentation, Operation Guide, Maintenance Documentation |
| Closure | 10/08/26–14/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
The example reference package states a Waterfall model. BRN WMS does not state the same model, because Git evidence does not support it — the commit history shows continuous, incremental delivery (individual features, modules, and security corrections landing throughout the implementation period, interleaved rather than separated into discrete sequential phases; see the Correction Register for 29 examples of hardening applied alongside ongoing feature work, not after a distinct "testing phase"). Restating "Waterfall" here would misrepresent the actual evidence.
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 reconstructed 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 reconstructed from the as-built architecture, not authored before coding began |
| Implementation | Continuous, feature-by-feature, evidenced by 105 commits across the implementation period 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 independent verification remains a separate, not-yet-executed activity (work product 21) |
| Stabilization/closure | A distinct late-stage effort (03/08/26 onward) closer to a traditional stabilization phase |
This is disclosed as a characterization of *how the work actually happened*, reconstructed from Git evidence — not a methodology that was chosen and documented in advance, since no contemporaneous methodology decision record exists.
## 7. Organization and responsibilities
| Role | Assigned person | Responsibilities |
|---|---|---|
| Project Sponsor / Customer Representative / Authorized Approver | คุณเสรี วิริยะสกุลธรณ์ | Represent customer needs; authorize scope, resources, baseline changes, acceptance, and project closure. |
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป | Plan and monitor work; assign responsibilities; manage risks, issues, communication, changes, and closure. |
| Developer / System Analyst | ธนกร สถิตวิทยากุล | Analyze requirements; design, implement, configure, correct, and maintain technical records and source code, aligned with Git implementation evidence. |
| Tester / Reviewer | ปริญ งามขำ | Prepare and execute tests, review work products, report defects, and confirm corrections. |
| Document Control | คุณเยาวลักษณ์ บางชมภู | 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 Human resources and effort estimate
The example reference package's Software Project Plan includes a "Project Estimate" section with work-product size and a Effort Man-Day table per role. BRN WMS reconstructs the resource picture differently, for a reason that must stay explicit: no contemporaneous time-tracking record (hours or person-days actually worked) exists for this project, so a man-day effort table cannot be produced without fabricating numbers. What follows is limited to what is actually evidenced.
**Headcount** (matches the Organization and responsibilities table in Section 6 — one person per role, not a multi-person team per role as in the example):
| Role | Headcount |
|---|---:|
| Project Sponsor | 1 |
| Project Manager | 1 |
| Developer / System Analyst | 1 |
| Tester / Reviewer | 1 |
| Document Control | 1 |
**Calendar duration by phase** (reconstructed from Git evidence and the agreed lifecycle; phases overlap toward the end of the project rather than running strictly sequentially — see Section 5 for the phase table and the Work Schedule for per-task duration):
| 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–14/08/26 | 75 days |
| Closure | 10/08/26–14/08/26 | 5 days |
These are calendar spans, not effort (person-days actually worked) — the two are not the same thing, and only the former is evidenced (by the agreed lifecycle and Git commit dates). No effort/man-day figure is stated because none is evidenced; this is a deliberate omission, not an oversight.
### 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 records are reconstructed | Audit evidence may be weaker than contemporaneous records. | Mark assumptions clearly and obtain retrospective 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 (currently open — BK-002) | Project Repository (Backup), work product 10 |
None of these are marked as passed in this Software Project Plan — actual results belong in the Test Report and Verification/Validation Results, which currently show 34 of 34 passed (user-confirmed) and 12 of 12 passed (user-confirmed) (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:
- Git history and the 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 42 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` |
**Deviation from the example, stated explicitly:** the example appends the author's initials to the filename (e.g., `...V1.0 ApS.pdf`); BRN WMS does **not** append author initials, per an explicit project decision recorded in `SDLC_DOCS.md`.
### 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 content is complete and ready for review, not that an authority has signed it — see each document's own Approval section and the Acceptance Report's current-status note for actual signature status.
### 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); as of this Software Project Plan's last refresh, that check remains open (BK-001, BK-002).
- 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: คุณอภิรัชต์ สุภัทรประทีป
Role: Project Manager
Signature: ______________________________________________
Date: ___________________________________________________
### Technical contributor
Name: ธนกร สถิตวิทยากุล
Role: Developer / System Analyst
Signature: ______________________________________________
Date: ___________________________________________________
### Reviewed and authorized by
Name: คุณเสรี วิริยะสกุลธรณ์
Project roles: Project Sponsor / Customer Representative / Authorized Approver
Position: กรรมการผู้จัดการ
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
Signature: ______________________________________________
Date: ___________________________________________________
sdlc/1-PM Process (10 Work Product)/2.Project Plan/3-Customer Requirement/200-WMS-26-001-00 Customer Requirements 25690112 V1.0 Final.md
+274
View File
@@ -0,0 +1,274 @@
# Customer Requirements
| Document field | Value |
|---|---|
| Document | Customer Requirements |
| Project | BRN WMS |
| Project code | 200-WMS-26-001-00 |
| Title | เอกสารบันทึกและสรุปความต้องการของลูกค้า |
| Project period | 05/01/26–24/08/26 |
| Release | 12/01/26 V1.0 Final |
| Standard | ISO/IEC 29110 Basic Profile |
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
| Project Sponsor / Customer Representative | คุณเสรี วิริยะสกุลธรณ์ |
| 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 requirements were reconstructed from the agreed project scope, implemented source code, database structure, configuration, and Git history. The Developer/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 |
|---|---|---|
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor / Customer Representative / Authorized Approver | Represent customer needs and approve project scope, strategic decisions, requirement baseline, acceptance, and closure. |
| คุณอภิรัชต์ สุภัทรประทีป | Project Manager | Plan and coordinate requirement activities, resolve issues, control changes, and maintain the approved baseline. |
| ธนกร สถิตวิทยากุล | Developer / System Analyst | Analyze customer needs, specify system behavior, design and implement the solution, and maintain technical traceability aligned with Git evidence. |
| ปริญ งามขำ | QA / Tester | Perform test execution, verification, and validation facilitation independent of the Developer; added to the project 17/08/26. |
| คุณเยาวลักษณ์ บางชมภู | Document Control | Control identifiers, versions, approvals, distribution, repository content, and evidence; added to the project 17/08/26, 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: ธนกร สถิตวิทยากุล
Role: Developer / System Analyst
Signature: ______________________________________________
Date: ___________________________________________________
### Reviewed by
Name: คุณอภิรัชต์ สุภัทรประทีป
Role: Project Manager
Signature: ______________________________________________
Date: ___________________________________________________
### Reviewed, confirmed, and authorized by
Name: คุณเสรี วิริยะสกุลธรณ์
Project roles: Project Sponsor / Customer Representative / Authorized Approver
Position: กรรมการผู้จัดการ
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
Signature: ______________________________________________
Date: ___________________________________________________