คุณสมบัติเชิงเทคนิค (NFR) Non-Functional

ความต้องการแบบ cross-cutting ของลูกค้าว่าทั้งสองแอปพลิเคชันต้องรองรับ แพลตฟอร์ม อุปกรณ์ browser ภาษา และ visual identity ใดบ้าง ความต้องการเหล่านี้ปรากฏใน 3 แห่ง — รายการ Technical/Non-Functional Requirement (NFR) "Solution", รายการ generic UX ของ Online Check-In และรายการ generic ของ Advanced Slot Booking — ซึ่งสอดคล้องกัน

การรองรับแพลตฟอร์มและอุปกรณ์

โซลูชันต้องครอบคลุม Web portal, iOS และ Android — สำหรับโทรศัพท์ทุกรุ่น (RFP p33, NFR #2) ฟีเจอร์ Online Check-In ที่ใช้งานโดยคนขับต้อง เข้ากันได้กับทั้ง Android และ iOS รองรับอุปกรณ์ mobile ทุกชนิด (RFP p21, Online Check-In generic row 1) แพลตฟอร์ม Advanced Slot Booking ต้องใช้งานได้ อย่าง seamless บน computer, smartphone และ tablet (RFP p26, Advanced Slot Booking generic row 1)

Responsiveness, browser และ performance

แอปพลิเคชันต้องสามารถ เข้าถึงในรูปแบบ responsive web application และบนอุปกรณ์ mobile (RFP p34, NFR #11) และต้อง mobile compatible เต็มรูปแบบ ทำงานบนแพลตฟอร์มทั่วไปอย่าง web-browser และ mobile tablet / smartphone (ทำงานเร็ว) (RFP p34, NFR #12) สำหรับ booking platform โดยเฉพาะ ต้อง ออกแบบและพัฒนาให้ responsive บน Computer, mobile และ tablet มอบ user experience ที่ดีที่สุดบนอุปกรณ์และขนาดหน้าจอที่แตกต่างกัน (RFP p26, Advanced Slot Booking generic row 4) โปรดสังเกตว่า "Secured Web responsive" ยังถูกระบุเป็นความต้องการด้านความปลอดภัยด้วย — ดู Application security (encryption, VA/PT, VAPT, SSL, IMC04) (RFP p37, NFR #31)

การรองรับภาษา

ต้องรองรับ ภาษาไทย (THAI language) ในทั้งสองแอป โดยมี รูปแบบ font ที่ชัดเจนและขนาดใหญ่ กำหนดค่าได้ตาม corporate identity ของ SCCC (RFP p22, Online Check-In generic row 18; RFP p26, Advanced Slot Booking generic row 6) นอกเหนือจากภาษาไทย User Interface ต้องสามารถรองรับภาษาอังกฤษหรือภาษาอื่น ๆ ตาม regional company ของ SCCC (RFP p34, NFR #13) — สะท้อนขอบเขตแบบ multi-country/regional-company (เทียบ multi-company access management ใน การจัดการสิทธิ์ผู้ใช้ RBAC และ SSO และเอกสารฝึกอบรมภาษาอังกฤษและไทยใน Implementation, testing, migration, cut-over และ training)

Layout และ branding (Company Identity)

layout และหน้าจอของแอปพลิเคชันต้องปรับอัตโนมัติให้รองรับขนาด font ที่หลากหลาย (RFP p22, Online Check-In generic row 19) — กล่าวคือการขยายขนาด font (เพื่อให้คนขับอ่านง่าย) ต้องไม่ทำให้ layout เสีย User Interface ต้องกำหนดค่าได้เพื่อรองรับ Company Identity / Branding (RFP p35, NFR #14) และกำหนดค่าได้ตาม รูปแบบที่ corporate identity ของ SCCC กำหนด (RFP p22 row 18 / RFP p26 row 6) [INFERRED] "configurable to corporate identity / branding" สื่อว่าลูกค้าคาดหวังให้ look-and-feel (สี, logo, font) กำหนดได้ผ่าน configuration แทนการ hard-code — สอดคล้องกับ mandate ที่ให้ปรับผ่าน config เท่านั้นในภาพรวมตาม Source code, IP ownership, GitHub และ no-code config

หมายเหตุ

• record นี้ครอบคลุมเฉพาะเลเยอร์ generic UX/platform เท่านั้น พฤติกรรม UX เชิง functional (navigation ในแอป, color code, pop-up, alert, การย้อน step) ถูกบันทึกไว้ใน Online Check-In — ข้อกำหนด generic / UX (matrix rows 1-19); UX เฉพาะของ booking platform อยู่ใน FR2 — Advanced Slot Booking สำหรับลูกค้า / ผู้ขนส่ง
• ช่อง NFR/compliance ทั้งหมดในต้นทางเว้นว่างไว้โดยเจตนา (ผู้ขายกรอก compliance F/P/N/NA + remarks); ความต้องการเหล่านี้เป็นสิ่งที่ลูกค้าระบุ ยังไม่ได้ยืนยันข้ามแหล่งที่อื่น — จึงมีสถานะ stated

ความต้องการของลูกค้าเกี่ยวกับ สถาปัตยกรรมโซลูชันโดยรวม, deployment landscape (environments), และสถานที่ที่อนุญาตให้ host แอปพลิเคชัน

เอกสารสถาปัตยกรรมและ landscape

ผู้ขายต้องสามารถจัดทำ Solution Architecture (Web, App และ DB) ที่สมบูรณ์ และ Application Landscape (DEV, QA/UAT และ PRD) รวมถึง network, hardware, operating system และซอฟต์แวร์อื่น ๆ ที่ต้องติดตั้ง ให้เข้ากันได้กับโซลูชันที่นำเสนอ (Web portal, iOS และ Android สำหรับโทรศัพท์ทุกรุ่น) (RFP p33, NFR #2)

รูปแบบสถาปัตยกรรมที่แนะนำ

ตาม NFR #18 (RFP p35) application landscape ต้องสอดคล้องกับ "INSEE Digital Project Infrastructure and Security Guideline" (แนวทางด้าน IT compliance — ดู IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management) และ:

• แนะนำสถาปัตยกรรมแบบ 3-tier: WEB – APP – DATABASE
• การวางแผน capacity และ hardware sizing ต้องรองรับการเติบโตของธุรกิจอย่างน้อย 3 ปี
• ต้องมี system landscape อย่างน้อย 2 ชุด: (1) development/testing และ (2) production

ผู้ขายยังต้องจัดทำ hardware specification และความต้องการด้าน internet-bandwidth ที่สอดคล้องกับ Capacity planning ที่อ้างถึงข้างต้น (RFP p35, NFR #19)

ตัวเลือกการ hosting (มีข้อจำกัด)

การ hosting ถูกจำกัด: แอปพลิเคชัน ต้อง host ใน INDG Regional Data Center หรือบน secure hosting cloud platform — เช่น Azure หรือ AWS เท่านั้น (RFP p35, NFR #16) หากการ hosting ที่เสนอเป็น public cloud จะต้องรวม end-to-end hosting service management ไว้ในค่า MA (RFP p35, NFR #17) — กล่าวคือค่า Maintenance Agreement (เทียบ ขอบเขต Application Maintenance, SLA & กฎ change request และกฎเรื่องค่าใช้จ่าย 3rd-party ใน Source code, IP ownership, GitHub และ no-code config)

ข้อขัดแย้งที่ตั้งข้อสังเกต (จำนวน environment: 3 vs 2)

มีความไม่สอดคล้องภายในเรื่องจำนวน environment:

• RFP p33 NFR #2 ระบุ landscape สาม ชุด: DEV, QA/UAT และ PRD
• RFP p35 NFR #18 ระบุ landscape อย่างน้อยสอง ชุด: development/testing + production

นี่เป็นข้อขัดแย้งด้านคุณภาพเอกสารจริง ("อย่างน้อยสอง" อาจตอบโจทย์หรือไม่ตอบโจทย์ของ "สาม" ที่ระบุชื่อไว้) ถือเป็น open item — ดู ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน เพื่อยืนยัน [INFERRED] เจตนาที่น่าจะเป็นคือ environment เชิงตรรกะ 3 ชุด (DEV, QA/UAT, PRD) โดย "อย่างน้อยสอง" เป็นเพดานขั้นต่ำ; รอลูกค้ายืนยัน

หมายเหตุ

• ความรับผิดชอบเรื่อง backup/restoration และ OS-patching ที่ผูกกับตัวเลือก hosting (Regional Data Center vs on-prem vs IaaS/cloud) ระบุไว้ภายใต้ controls "Data backup and restoration" ของ IMC และ Maintenance SOW — บันทึกไว้ใน IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management / ขอบเขต Application Maintenance, SLA & กฎ change request ไม่ใช่ที่นี่
• สถานะ stated (เอกสารเดียว, ช่อง compliance ว่าง; ไม่มีการยืนยันข้ามแหล่ง)

ความต้องการของลูกค้าที่ระบุว่าโซลูชันต้อง scale และขยายได้เกินกว่าขอบเขต check-in ขาออกที่ Saraburi (SRB) ตั้งต้น และต้องมี high availability

การขยายไปยัง business unit / regional company อื่น

แอปพลิเคชันต้อง scale up หรือขยายไปยัง business unit อื่นที่ไม่ได้อยู่ในขอบเขตปัจจุบันได้ง่าย และสามารถ รองรับผู้ใช้ได้ถึง 4,000 users หรือมากกว่า (การขยายระดับ regional company ของ SCCC) (RFP p35, NFR #20) จุดนี้วางกรอบเส้นทางการเติบโตแบบ multi-business-unit / multi-country (สอดคล้องกับ multi-country access management ใน การจัดการสิทธิ์ผู้ใช้ RBAC และ SSO และ multi-language UI ใน ความเข้ากันได้ของแพลตฟอร์ม responsiveness ภาษา และ branding) ทั้งนี้ขอบเขตการขยายไปยัง plant/BU ที่แน่นอนยังเป็น open item — ดู ขอบเขตโรงงาน — เฉพาะ SRB หรือรวม Rayong และการขยายในอนาคต และ ขอบเขตและขอบเขตงาน — อะไรอยู่ใน / นอก scope

Scale up/down และ high availability

แอปพลิเคชันและส่วนประกอบต้องรองรับ standard best practice ด้าน scale up และ down ตามจำนวนผู้ใช้ จำนวน transaction ฯลฯ รวมถึง high availability (RFP p35, NFR #21) การวางแผน capacity/hardware sizing ที่รองรับการเติบโตอย่างน้อย 3 ปี ครอบคลุมอยู่ภายใต้ architecture — ดู สถาปัตยกรรมโซลูชัน การ hosting และ landscape (RFP p35, NFR #18)

มิติเชิง functional ของ scalability (ภาพรวม)

Business Requirements Overview (RFP p11) วางกรอบให้โซลูชัน รองรับ logistics service type หลากหลายที่ SCCC ให้บริการแก่ลูกค้า, จัดการ material group หลายกลุ่ม, รองรับ queuing type ที่แตกต่างกัน และเปิดความเป็นไปได้ในการขยายขอบเขตตลอด user journey เกินกว่าแค่ขั้น check-in อีกทั้งต้องสามารถ รับและส่งข้อมูลแบบ real time กับแพลตฟอร์มปัจจุบันของ SCCC (เทียบ ความต้องการด้านเทคโนโลยีการ integration (API, monitoring)) [INFERRED] นี่คือ "functional scalability" (service type / material group / queue type / journey step ที่มากขึ้น) ซึ่งต่างจากการ scale เชิง infrastructure ของ NFR #20–21 แต่ทั้งสองสะท้อนเจตนาเดียวกันของลูกค้า: ออกแบบเผื่อการเติบโต ไม่ใช่แค่ SRB outbound MVP

หมายเหตุ

• ตัวเลข "4,000 users หรือมากกว่า" เป็นเป้าหมายเชิง capacity เชิงปริมาณเพียงตัวเดียวที่ระบุไว้; กรอบการวางแผน capacity 3 ปี (NFR #18) รองรับตัวเลขนี้ ไม่มีการระบุตัวเลข transaction-per-second หรือ concurrency
• สถานะ stated (เอกสารเดียว, ช่อง compliance ว่าง)

ความต้องการด้าน application security ของลูกค้า ความต้องการเหล่านี้มีสถานะ confirmed เนื่องจาก control ชุดเดียวกันถูกระบุไว้สองครั้งใน RFP: ครั้งแรกเป็นรายการ Non-Functional Requirements "Application Security" (RFP p36-37, NFR #26–32) และอีกครั้งแทบจะคำต่อคำในรูปของ checklist "IT Security" ของ INSEE Minimum Control (IMC) (RFP p45-46) — โดยอย่างหลังคือ IMC ที่มีผลผูกพันซึ่งอย่างแรกอ้างถึง

แนวทางกำกับดูแล (IMC04)

Application Security ต้อง เป็นไปตาม "INSEE Digital Project Infrastructure and Security Guideline" ที่อ้างถึงในส่วน IT Compliance Guideline Requirements (RFP p36, NFR #26; ส่วน compliance ฉบับเต็ม RFP p40 — ผูกพันทั้ง Group ผู้ขายต้องยื่นจดหมายรับรองการปฏิบัติตามอย่างเป็นทางการ ดู IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management) แอปพลิเคชันต้อง ได้รับการแก้ไขและคงความปลอดภัยตาม INSEE Minimum Control IMC04 (RFP p36, NFR #27)

ระบบการทดสอบ VA / PT (IMC04)

กำหนดรอบการทดสอบไว้ดังนี้ (RFP p36 NFR #27, ทวนซ้ำ RFP p45 rows 2–4):

• Vulnerability Assessment (VA): ดำเนินการกับแต่ละแอปพลิเคชันอย่างน้อยเดือนละครั้ง (ทุกเดือน); vulnerability ที่พบทั้งหมดต้อง mitigate โดยเร็วที่สุด
• Penetration Test (PT): ดำเนินการกับแต่ละแอปพลิเคชันอย่างน้อยปีละสองครั้ง (ทุก 6 เดือน); risk ที่พบทั้งหมดต้อง mitigate โดยเร็วที่สุด
• ในการ deploy/project ของแต่ละแอปพลิเคชัน ต้องมีการทำ VA และ PT แบบบังคับ เพื่อให้แน่ใจว่าแอปพลิเคชันได้รับการ "harden" อย่างเหมาะสม และ vulnerability กับ risk ทั้งหมดที่พบถูก mitigate ก่อน Go Live

นอกจากนี้ แอปพลิเคชัน ต้องแสดงผลการทดสอบ VAPT และ gap ที่ได้ remediate / รับรองโดย 3rd party ที่มีคุณสมบัติก่อน go-live (RFP p37, NFR #30)

baseline การ harden แพลตฟอร์ม

• Database ที่ใช้ต้องเป็นเวอร์ชันที่ OEM รองรับ (RFP p36 NFR #27 / p45 row 5)
• Operating System ได้รับการ patch เป็นประจำตาม patch-management process (RFP p36 NFR #27 / p45 row 6, ต่อ p46)
• ติดตั้งและตั้งค่า Antivirus software ให้ auto-update เว้นแต่ OEM แนะนำเป็นอย่างอื่น (RFP p36 NFR #27 / p46 row 7)
• Security configuration setting ของแอปพลิเคชัน (เช่น password setting, log-in/out duration time) ต้องได้รับการ review ครอบคลุม Applications, Operating Systems และ Database เพื่อยืนยันว่าการตั้งค่าเหมาะสมและถูกบังคับใช้; transaction ผิดปกติใด ๆ ต้องได้รับการ investigate และจัดทำเอกสาร (RFP p45, IT Security row 1)

Encryption และ transport security

• ข้อมูล business-critical และ confidential ทั้งหมด — เช่น ข้อมูลพนักงาน ฯลฯ — ต้องจัดเก็บในรูปแบบ encrypted ในระบบ (RFP p36, NFR #29)
• แอปพลิเคชันและส่วนประกอบต้องออกแบบให้รองรับ standard best practice ด้านความปลอดภัย (RFP p36, NFR #28)
• โซลูชันต้องจัดทำในรูปแบบ Secured Web responsive (RFP p37, NFR #31)
• ต้องมี SSL Certification (RFP p37, NFR #32)

Cross-links

• Access-control / RBAC / SSO / การ logging การเข้าถึงของผู้ใช้ เป็นกลุ่ม NFR แยกต่างหาก — ดู การจัดการสิทธิ์ผู้ใช้ RBAC และ SSO (RFP p37 NFR #33–42; IMC Access Control p42)
• การ scan ความปลอดภัยของ source code (GitHub Advanced Security; remediate ระดับ Moderate/High/Critical ก่อนขึ้น QA & Production) ถูกบันทึกไว้ใน Source code, IP ownership, GitHub และ no-code config (RFP p34, NFR #9)
• "No automatic release upgrade" (RFP p36, NFR #25) — ฟังก์ชันใน release ใหม่ต้องสื่อสารให้ SCCC ตัดสินใจรับมาใช้/ไม่รับมาใช้ — เป็น control ด้าน release-management บันทึกไว้ใน การ upgrade แอปพลิเคชันและ release management; เกี่ยวข้องที่นี่เพราะเป็นตัวกำหนดกรอบเวลาที่ security patch/เวอร์ชันจะถูก apply

หมายเหตุ

• "VAPT" = Vulnerability Assessment + Penetration Test "IMC" = INSEE Minimum Control; IMC04 = ชุด control ด้าน IT-Security; IMC01 = การทดสอบ (ดู Implementation, testing, migration, cut-over และ training)
• control ด้าน backup/restoration (daily backup, retention, annual restoration test) อยู่ภายใต้ checklist "Data backup and restoration" ของ IMC (RFP p43-44) — บันทึกไว้ใน IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management / ขอบเขต Application Maintenance, SLA & กฎ change request ไม่ทำซ้ำที่นี่

ความต้องการของลูกค้าเกี่ยวกับ วิธีสร้าง ยืนยันตัวตน กำหนดสิทธิ์ บันทึก log และ provision ผู้ใช้ ทั้งสองแอปพลิเคชัน ระบุไว้ในรายการ NFR "User Access Management" (RFP p37, NFR #33–42) และขยายความเพิ่มเติมด้วย checklist "Access control to IT systems" ของ IMC (RFP p42)

แนวทางกำกับดูแล

การจัดการสิทธิ์ผู้ใช้ต้อง เป็นไปตาม "INSEE Digital Project Infrastructure and Security Guideline" (RFP p37, NFR #33; เทียบ IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management)

โมเดล multi-country / multi-company

ระบบต้องสามารถ จัดการสิทธิ์ผู้ใช้แยกตามประเทศ / บริษัท ได้ (RFP p37, NFR #34) — เป็นโมเดลองค์กรแบบ multi-country, multi-company ที่สอดคล้องกับการขยายระดับ regional company ใน Scalability การขยายระบบ และ high availability

วงจรชีวิตผู้ใช้ บทบาท และ matrix

• กำหนดค่าการสร้างผู้ใช้ สิทธิ์การเข้าถึง การยืนยันตัวตน รวมถึงการจัดการ profile, role และ user matrix (RFP p37, NFR #35)
• ตั้งค่าและกำหนดระดับการอนุมัติสิทธิ์ที่แตกต่างกัน / จัดการการเข้าถึงและระดับความปลอดภัย (RFP p37, NFR #38)
• ต้องมี กระบวนการจัดการสิทธิ์ผู้ใช้ฝั่ง business (เพิ่ม เปลี่ยน ลบ) พร้อม approval flow ที่เหมาะสม (RFP p42, Access Control row 1)

เส้นทางการยืนยันตัวตนและ provisioning

• ผู้ใช้ภายนอก: สร้างผู้ใช้ผ่าน Name / User ID ที่ไม่ซ้ำกัน โดยใช้ email หรือ username (RFP p37, NFR #36)
• ผู้ใช้ภายในของ SCCC: สร้างผู้ใช้โดย sync กับ MS Active Directory (AD) — ID และสิทธิ์การเข้าถึงถูก provision อัตโนมัติผ่าน MS AD (RFP p37, NFR #37; RFP p42, Access Control rows 1[dup]/3) ดู AD ในฐานะ source system ใน ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD
• IMC ระบุแนวทาง provisioning ไว้ 3 แบบ ได้แก่ Manual (สำหรับแอปที่ไม่สามารถ integrate กับ AD/SAP GRC แบบรวมศูนย์ได้ — ต้องกำหนดกระบวนการขอสิทธิ์และ provision ผู้ใช้), ผ่าน Microsoft AD (provision อัตโนมัติ) หรือ ผ่าน SAP GRC (สำหรับระบบ SAP ที่อยู่บน stack ABAP) (RFP p42, Access Control rows 2–3)
• Single Sign-On (SSO): แอปพลิเคชันต้องเข้าใช้งานผ่าน SSO ได้ (RFP p37, NFR #42; ต้นฉบับสะกด "Sigle Sign On" sic)

การกำหนดขอบเขตสิทธิ์ (ระดับข้อมูล)

คนขับควรเห็นและจัดการได้เฉพาะ shipment / task ภายใต้ลูกค้าของตนเองเท่านั้น (RFP p37, NFR #39) — กล่าวคือเป็นการกำหนดสิทธิ์ระดับแถว / scope ตามลูกค้า (multi-tenant data isolation) ซึ่งเชื่อมโยงกับการมองเห็น shipment แยกตามลูกค้าใน Online Check-In — การกรอกและตรวจสอบข้อมูล (shipment / truck / identity) และการ scope quota ตามลูกค้าใน Advanced Slot Booking — booking confirmation, user profile และ customer quota

นโยบายรหัสผ่าน

นโยบายรหัสผ่านที่กำหนดค่าได้: ความซับซ้อน (complexity), ประวัติ (history), วันหมดอายุ (expiration date) (RFP p37, NFR #40)

User access log / audit

ระบบต้องมี user access log ครอบคลุมอย่างน้อย (RFP p37, NFR #41; RFP p42 Access Control row 4):

• Username
• Date / Time
• Change by
• User status
• Activities เช่น creation / modification / deletion / role change / password change (IMC ระบุเฉพาะ: User Creation, User Deletion, User Change Roles)

Privileged access

ต้องกำหนด system log และกระบวนการจัดการ privilege access — โดย role ที่มีสิทธิ์พิเศษ (business admin, technical admin, emergency role) จำกัดเฉพาะผู้ที่ได้รับอนุญาตเท่านั้นในสภาพแวดล้อม production (RFP p42, Access Control row 5)

หมายเหตุ

• การลงทะเบียนบัญชีแบบ self-service, login, reset รหัสผ่าน และ "remember password" ของทั้งสองแอป (รวมถึงการยืนยันตัวตนผ่าน DID/INSEE+ และเงื่อนไข 1 account = 1 driver ID) เป็นเรื่อง functional ที่ถูกบันทึกไว้ใน User account, registration & login (ทั้งสอง app); record นี้ครอบคลุมเฉพาะเลเยอร์ NFR ด้าน governance / RBAC / provisioning
• คอลัมน์ "No." ของ IMC ในหน้า p42 มีความผิดปกติของลำดับเลข (1,1,2,3,4,5) — เป็นข้อบกพร่องของเอกสารต้นทาง ดู ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน
• สถานะ stated (แต่ละ fact มาจากแหล่งเดียว; ช่อง compliance ว่าง)

ความต้องการของลูกค้าเกี่ยวกับ การกำกับดูแลงาน custom development: ใครเป็นเจ้าของ code และ IP, code อยู่ที่ไหน, scan ความปลอดภัยอย่างไร และ mandate ที่ว่าระบบที่ทำงานอยู่ต้องกำหนดค่าได้โดยไม่ต้องเขียน code ทั้งหมดระบุภายใต้หมวด NFR "Solution" (RFP p33-34, NFR #1, #3–10, #15)

แนวทางการพัฒนา

การพัฒนาโซลูชันต้อง เป็นไปตาม "INSEE Digital Project Application Development Guideline" ที่อ้างถึงในส่วน IT Compliance Guideline Requirements (RFP p33, NFR #1; ส่วนฉบับเต็ม RFP p40 — ดู IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management) สำหรับงาน custom development โซลูชันต้อง ออกแบบโดยใช้ technology stack ที่เป็นปัจจุบัน (software architecture, programming language, service component อื่น ๆ) (RFP p33-34, NFR #3)

IP และ ownership ของ source code (เงื่อนไขสำคัญ)

• หากโซลูชันที่เสนอเป็นแอปพลิเคชันแบบ custom-development แล้ว Source Code และ IP ต้องเป็นของ INDG (INSEE Digital) (RFP p34, NFR #7) นี่เป็นเงื่อนไขเชิงพาณิชย์/กฎหมายที่ตายตัว — cross-link เงื่อนไขเชิงพาณิชย์ — การชำระเงิน, ค่าปรับ, IP, เกณฑ์การตั้งราคา
• Source code ต้องจัดเก็บ พัฒนา และบริหารจัดการภายใต้ INDG GitHub Code Repository ในช่วง Project Execution Phase (RFP p34, NFR #8) ผู้ขายต้อง ระบุใน proposal ว่ามี developer จำนวนเท่าใดที่ต้องเข้าถึง GitHub

ด่าน code-quality และ security scanning

แอปพลิเคชันต้อง แสดงผล Code quality และ Security Scan โดยใช้ GitHub Advanced Security Features; alert ด้าน code-quality และ security ระดับ Moderate, High และ Critical ต้องได้รับการ remediate / resolve ก่อน deploy ขึ้น QA และ Production (RFP p34, NFR #9) นี่คือส่วนเสริมฝั่ง source ที่ต่อเนื่องกับระบบ VA/PT ตอน runtime ใน Application security (encryption, VA/PT, VAPT, SSL, IMC04)

Software component, license และค่าใช้จ่าย 3rd-party

• จัดทำ รายการ software component และ license ที่ครอบคลุม รวมถึงค่าใช้จ่าย เพื่อพัฒนาแอปพลิเคชัน (RFP p34, NFR #4)
• service หรือ subscription จาก 3rd-party ใด ๆ ที่ใช้ในการพัฒนา พร้อมค่าใช้จ่าย ต้องนำเสนอให้ INSEE Digital อนุมัติ (RFP p34, NFR #5)
• ค่าใช้จ่าย subscription และ service จาก 3rd-party จะเป็นส่วนหนึ่งของ MA Cost (RFP p34, NFR #6) — เทียบ ขอบเขต Application Maintenance, SLA & กฎ change request และ public-cloud hosting ใน สถาปัตยกรรมโซลูชัน การ hosting และ landscape

Mandate กำหนดค่าได้อย่างเดียว (no-code สำหรับการเปลี่ยนแปลงเชิง business)

Master และ Business Process ทั้งหมดต้องเปลี่ยนแปลงได้ง่ายด้วย configuration โดย Admin เท่านั้น — ไม่ต้องเขียน code และไม่ต้อง build สำหรับการเปลี่ยนแปลงเหล่านั้น (RFP p34, NFR #10) นี่เป็นความคาดหวังที่หนักแน่นของลูกค้าว่าพารามิเตอร์ business ในงานประจำวัน (geofence radius, tolerance/window times, booking policy, slot duration, quota, master data, รายการ field ที่แก้ไขได้, branding) ต้องกำหนดค่าได้โดย admin แทนการ deploy โดย dev ซึ่งเป็นรากฐานของความต้องการแบบ "configurable / able to adjust" จำนวนมากในหลาย ๆ functional record (เช่น รัศมี Geofence สำหรับ off-site check-in, Threshold เวลา tolerance / window / overdue, พารามิเตอร์ของ Booking policy (advance window, slot period, การยืนยัน, การยกเลิก))

Event logging

ระบบต้อง เก็บ event เช่น Log-in log, Interface log, Job Schedule log ฯลฯ (RFP p35, NFR #15) — เป็น operational/event logging ซึ่งต่างจาก security user-access log ใน การจัดการสิทธิ์ผู้ใช้ RBAC และ SSO

เหตุผลของสถานะ

สถานะ confirmed: ห่วงโซ่ IP-to-INDG + GitHub + GitHub-Advanced-Security ได้รับการเสริมด้วย "INSEE Digital Project Application Development Guideline" ที่มีผลผูกพัน (RFP p40) และเงื่อนไข IP เชิงพาณิชย์ กล่าวคือความต้องการนี้ถูกระบุและยืนยันสอดคล้องกันผ่านส่วน compliance ของ development-guideline ไม่ใช่แถวเดี่ยว ๆ ที่โดดเดี่ยว

หมายเหตุ

• "INDG" = INSEE Digital (entity ผู้ออกเอกสาร) คงคำสะกดผิดจากต้นทางไว้ตามเดิมในข้อความที่ยกมา ("If it the proposed solution", "must be store, develop and manage")

ความต้องการของลูกค้า ในระดับเทคโนโลยีว่าระบบใหม่ integrate อย่างไร กับ DAS, ระบบของ SCCC และระบบภายนอก (เป็นเรื่องของ วิธี integrate; ส่วน สิ่งที่ integrate — feed เฉพาะแต่ละรายการ — อยู่ใน record ฝั่ง integration)

แนวทางการ integration

• ง่ายต่อการ integrate โดยรองรับ standard API และ integration tool (RFP p38, NFR #43)
• การ integrate กับระบบของ SCCC หรือระบบภายนอกต้องปลอดภัย ยืดหยุ่น และ seamless (RFP p38, NFR #44)

การ monitor / observability ของ interface

ผู้ขายต้อง จัดหา interface monitoring tool (หรือเทียบเท่า) ให้ผู้ใช้หรือทีม support ทราบถึงปัญหาที่เกิดขึ้นกับการ integrate ข้อมูลระหว่างทั้งสองระบบ (RFP p38, NFR #45) [INFERRED] สื่อความว่าต้องมี visibility/alerting เชิง operational ต่อความล้มเหลวของ interface (failed messages, lag) เพื่อให้ทีม support ตรวจจับการ integrate ที่ขาดช่วงระหว่าง Mobile App ↔ DAS ↔ booking Platform ได้ ไม่ใช่ปล่อยให้คนขับติดค้างอยู่ที่ gate

Automation

ควร automate ให้มากที่สุดเท่าที่ทำได้และมีประสิทธิภาพผ่าน online approvals (RFP p38, NFR #46) — เช่น flow การ confirm booking และการอนุมัติของ admin แบบอัตโนมัติ ลดการจัดการที่ counter ด้วยมือ

ลักษณะ real-time ของการ integration

integration matrix (RFP p33) กำหนดความคาดหวังด้าน latency ที่เทคโนโลยีต้องทำได้: การ integrate ส่วนใหญ่เป็นแบบ Real-time — Shipment data create/update/delete (DAS → Mobile App), Data validation (Mobile App → DAS), Check-In 1 & 2 update (Mobile App → DAS), Cancel event (Mobile App → DAS) และ Booking confirmation (Platform → DAS) — ในขณะที่ Queue status update (DAS → Mobile App) เป็นแบบ Every 30 sec (RFP p33, integration #4) แคตตาล็อก feed-by-feed โดยละเอียดอยู่ใน DAS — ระบบ queue management เดิม (ศูนย์กลางของการ integration) (และแหล่งต้นทาง upstream ใน ระบบต้นทาง/upstream — TMS, INSEE+, INPLANT, OTM, DID, MS AD); การประมวลผลฝั่ง DAS ที่ระบบใหม่ขับเคลื่อนอยู่ใน Logic ฝั่ง DAS ที่ระบบใหม่ต้องขับเคลื่อน (Online CI + Advanced Booking)

หมายเหตุ

• "API + integration tool" และ "interface monitoring tool หรือเทียบเท่า" ใน RFP จงใจไม่ผูกกับเทคโนโลยีใดเทคโนโลยีหนึ่ง — ลูกค้าระบุ capability ไม่ใช่ตัวผลิตภัณฑ์ อย่า infer middleware เฉพาะเจาะจงที่นี่
• สถานะ stated (เอกสารเดียว, ช่อง compliance ว่าง) ตัวเลข real-time/30-sec ได้รับการยืนยันเทียบกับ integration matrix บน RFP หน้าเดียวกัน (p33)

ความต้องการของลูกค้าเกี่ยวกับ วิธีทดสอบ migrate cut over และ rollout โซลูชัน — กลุ่ม NFR "Solution implementation" (RFP p38-39, NFR #47–54) ซึ่งกำกับด้วย INSEE Minimum Control IMC01

แนวทางการทดสอบ (NFR #47)

ผู้ขายรับผิดชอบจัดทำแนวทางการทดสอบและดำเนินการ:

• Unit test, functional test
• System Integration test (SIT)
• Stress test / Load test

FAT/SIT ตาม IMC01 (NFR #48)

• ดำเนินการ Unit Tests และ System Integration Tests (SIT) ก่อน release เข้าสู่ User Acceptance Tests (UAT)
• Unit Tests ดำเนินการโดย Programmers (Developers); SIT ดำเนินการโดย Functional Team
• หลักฐาน — ผลของ test-script, ผู้ดำเนินการทดสอบ และเวลาที่ทดสอบ — ถูก บันทึกและเก็บไว้ใน project folders
• ผลการทดสอบต้องผ่านการ sign off โดย supervisor หรือ tester ก่อนเริ่ม UAT ใด ๆ; การ sign-off นี้ถูกบันทึกและเก็บไว้ใน project folders

UAT ตาม IMC01 (NFR #49)

• UAT ดำเนินการโดย Users (Business Users)
• scenario การทดสอบ, ผลลัพธ์ และการ confirm (business sign-offs) ถูกบันทึกและเก็บไว้ใน project folders
• UAT ต้องผ่านการ sign off โดยผู้มีอำนาจก่อน deploy ขึ้น production environment
• ต้องจัดทำ Release note ที่ระบุขั้นตอนโดยละเอียด, rollback plan ฯลฯ ก่อน deploy ขึ้น production (เทียบ release management ใน การ upgrade แอปพลิเคชันและ release management)

ความรับผิดชอบในการ implement (NFR #50–54)

• รับผิดชอบสนับสนุน User Acceptance Test (UAT) (#50)
• กลยุทธ์และการดำเนินการ Data Migration จากระบบเดิมเข้าสู่ระบบใหม่ หากจำเป็น (#51)
• กลยุทธ์ cut-over รวมถึงกิจกรรมและการดำเนินการ cut-over จากระบบเดิมเข้าสู่ระบบใหม่ (#52)
• แนวทางการ training + train-the-trainer + การสนับสนุนการฝึกอบรม end-user (#53)
• เอกสารการฝึกอบรมจัดทำเป็นภาษาอังกฤษและภาษาไทย หรือภาษาอื่น ๆ ตาม regional company ของ SCCC (#54) — เทียบ multi-language UI ใน ความเข้ากันได้ของแพลตฟอร์ม responsiveness ภาษา และ branding

บริบทของ environment

ขั้นตอนการทดสอบเหล่านี้ map เข้ากับ application landscape DEV, QA/UAT และ PRD (RFP p33, NFR #2) — ดู สถาปัตยกรรมโซลูชัน การ hosting และ landscape; โปรดสังเกตความกำกวมเรื่องจำนวน environment 3-vs-2 ที่ตั้งข้อสังเกตไว้ที่นั่น

หมายเหตุ

• "IMC01" = INSEE Minimum Control สำหรับการทดสอบ (FAT/SIT, UAT) FAT = Factory Acceptance Test, SIT = System Integration Test, UAT = User Acceptance Test [INFERRED expansions]
• deliverables ของ proposal / ความต้องการด้าน project-management ที่ครอบคลุมกิจกรรมเหล่านี้อยู่ใน โครงสร้างข้อเสนอที่คาดหวัง & deliverables ที่ต้องส่งมอบ และ IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management
• สถานะ stated (เอกสารเดียว; ช่อง compliance ว่าง)

ความต้องการของลูกค้าเกี่ยวกับ วิธี upgrade เวอร์ชันแอปพลิเคชันและการกำกับดูแล release — รายการ NFR "Application Upgrade" (#23) และ "Application Release Management" (#24–25) (RFP p36)

การ upgrade แอปพลิเคชัน

แอปพลิเคชันต้อง upgrade เวอร์ชันได้ง่ายเมื่อมี standard ใหม่ในตลาด (RFP p36, NFR #23) — กล่าวคือ upgrade เวอร์ชันได้โดยมี friction ต่ำเพื่อให้ทันสมัยอยู่เสมอ

Release management

• ผู้ขายต้องสามารถ จัดทำ software release plan ที่หนักแน่น (RFP p36, NFR #24)
• ฟังก์ชันใน release ใหม่ต้องสื่อสารให้ SCCC ทราบล่วงหน้า โดย SCCC เป็นผู้ตัดสินใจว่าจะรับมาใช้หรือไม่ — ไม่มีการ upgrade release อัตโนมัติ (RFP p36, NFR #25)

กฎ "ไม่มี upgrade อัตโนมัติ / ลูกค้าเป็นผู้ตัดสินใจรับมาใช้" นี้คือ control สำคัญของลูกค้า: SCCC คงสิทธิ์ควบคุมว่าสิ่งใดจะขึ้นสู่ production environment ของตน กฎนี้เสริม (และจำกัด) flow การ patch ความปลอดภัยและการ deploy ใน Application security (encryption, VA/PT, VAPT, SSL, IMC04) (เช่น patch/เวอร์ชันยังต้องผ่านการตัดสินใจรับมาใช้ของ SCCC) และวินัยเรื่อง release-note + rollback-plan ก่อนขึ้น production ใน Implementation, testing, migration, cut-over และ training (RFP p39, NFR #49)

เชื่อมโยงกับ maintenance

ภาระต่อเนื่องในการ upgrade เวอร์ชัน — รักษาให้ application environment, database, software library และ HW firmware อยู่ใน เวอร์ชันที่เป็นปัจจุบัน และดูแล application roadmap ที่ระบุการ upgrade เวอร์ชันที่วางแผน/ดำเนินการแล้ว — อยู่ใน Application Maintenance Scope of Work (RFP p47-48) ดู ขอบเขต Application Maintenance, SLA & กฎ change request ทั้งหมดนี้ผูก release plan เข้ากับสัญญา maintenance หลัง go-live

หมายเหตุ

• คงคำสะกดผิดจากต้นทาง: NFR #24 "Able to provide the solid of software release plan"
• สถานะ stated (เอกสารเดียว, ช่อง compliance ว่าง)