Non-Functional Requirements (NFR)

Non-Functional Requirements หรือ NFR คือข้อกำหนดที่ไม่ได้บอกว่า “ระบบต้องทำอะไร” แต่บอกว่า “ระบบต้องทำงานได้ดีแค่ไหน” เช่น ต้องเร็ว ปลอดภัย ใช้งานง่าย และพร้อมใช้งานได้ต่อเนื่อง
ถ้า Functional Requirements เน้นเรื่องฟังก์ชัน เช่น เพิ่มข้อมูล ค้นหา หรือออกรายงาน NFR จะเน้นเรื่องคุณภาพของระบบโดยรวม ซึ่งมีผลโดยตรงต่อประสบการณ์ผู้ใช้และความน่าเชื่อถือของระบบ
พูดง่าย ๆ คือ ระบบอาจ “ทำงานได้” ตามฟังก์ชัน แต่ถ้าช้า ล่มบ่อย หรือใช้งานยาก ผู้ใช้ก็อาจไม่อยากใช้ระบบนั้นต่อ
ทำไม NFR จึงสำคัญ
NFR ช่วยกำหนดมาตรฐานของระบบตั้งแต่ก่อนเริ่มพัฒนา ทำให้ทีมเห็นตรงกันว่าระบบที่ดีควรมีคุณภาพในระดับใด
หากไม่มีการระบุ NFR อย่างชัดเจน นักพัฒนาอาจสร้างระบบที่มีฟังก์ชันครบ แต่ไม่ตอบโจทย์การใช้งานจริง เช่น หน้าเว็บโหลดช้าเกินไป หรือรองรับผู้ใช้พร้อมกันไม่ได้
ในงานจริง NFR ยังช่วยเรื่องการทดสอบและประเมินผล เพราะสามารถใช้เป็นเกณฑ์วัดได้ว่าระบบผ่านมาตรฐานหรือยัง เช่น โหลดหน้าแรกไม่เกิน 3 วินาที หรือมี uptime 99.9%
ความแตกต่างจาก Functional Requirements
Functional Requirements อธิบาย “งานที่ระบบต้องทำ” เช่น สมัครสมาชิก บันทึกข้อมูลพนักงาน ค้นหาสินค้า หรือพิมพ์รายงาน
Non-Functional Requirements อธิบาย “คุณภาพหรือเงื่อนไขของการทำงาน” เช่น ต้องตอบสนองภายใน 2 วินาที ข้อมูลต้องถูกเข้ารหัส หรือระบบต้องใช้งานได้บนมือถือ
ตัวอย่างการแยกให้เห็นภาพชัด:
Functional: ระบบต้องให้พนักงานลงเวลาเข้าออกงานได้
Non-Functional: ระบบต้องรองรับพนักงานลงเวลาพร้อมกัน 1,000 คนโดยไม่ล่ม
ประเภทของ NFR
NFR มักแบ่งออกเป็นหลายด้าน แต่กลุ่มที่พบได้บ่อยและเข้าใจง่ายมี 4 หมวดหลัก ได้แก่ ประสิทธิภาพ ความปลอดภัย การใช้งานง่าย และความน่าเชื่อถือหรือความพร้อมใช้งาน
1. ประสิทธิภาพ (Performance)
หมวดนี้เกี่ยวกับความเร็ว การตอบสนองของระบบ และความสามารถในการรองรับปริมาณงาน
ตัวอย่าง:
ระบบต้องโหลดหน้าหลักเสร็จภายในไม่เกิน 3 วินาที
ระบบต้องตอบสนองต่อคำสั่งผู้ใช้ภายใน 2 วินาทีในการใช้งานทั่วไป
ระบบต้องรองรับผู้ใช้พร้อมกัน 1,000 คนโดยไม่เกิดการล่ม
ตัวอย่างในชีวิตจริง เช่น ระบบลงเวลาพนักงาน ถ้าช่วง 8 โมงเช้ามีพนักงานกดลงเวลาพร้อมกันจำนวนมาก ระบบต้องยังตอบสนองได้ทัน ไม่ค้าง และไม่หลุด
2. ความปลอดภัย (Security)
หมวดนี้เกี่ยวข้องกับการปกป้องข้อมูล การควบคุมสิทธิ์ และการป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต
ตัวอย่าง:
รหัสผ่านของผู้ใช้ต้องถูกเข้ารหัสก่อนบันทึกลงฐานข้อมูล
ข้อมูลสำคัญต้องเปิดดูได้เฉพาะผู้ที่ได้รับสิทธิ์เท่านั้น
ระบบต้องมีการตรวจสอบสิทธิ์ก่อนเข้าถึงข้อมูลส่วนบุคคล
ยกตัวอย่างเช่น ในระบบลงเวลางาน ข้อมูลตำแหน่งที่ตั้งและภาพถ่ายของพนักงานไม่ควรให้ทุกคนในองค์กรเปิดดูได้ แต่ควรจำกัดเฉพาะหัวหน้างานหรือฝ่าย HR ตามบทบาทหน้าที่
3. การใช้งานง่าย (Usability)
หมวดนี้เน้นประสบการณ์ของผู้ใช้ ว่าระบบเรียนรู้ง่าย ใช้งานสะดวก และลดความสับสนได้มากแค่ไหน
ตัวอย่าง:
ระบบต้องรองรับการแสดงผลบนสมาร์ตโฟน แท็บเล็ต และคอมพิวเตอร์อย่างเหมาะสม
ผู้ใช้ใหม่ต้องสามารถเรียนรู้และทำงานพื้นฐานได้ภายในเวลาที่กำหนด เช่น 30 นาที
ผู้ใช้ควรทำงานสำคัญได้ภายในไม่กี่ขั้นตอน เช่น ลงเวลาได้ภายใน 3 คลิก
ตัวอย่างที่เห็นภาพคือ หากหน้าลงเวลาออกแบบปุ่มใหญ่ มองเห็นชัด และใช้งานบนมือถือได้ดี ผู้ใช้ก็จะทำงานได้เร็วและผิดพลาดน้อยลง
4. ความน่าเชื่อถือและความพร้อมใช้งาน (Reliability / Availability)
หมวดนี้พูดถึงความเสถียรของระบบ การทำงานต่อเนื่อง และการลดโอกาสที่ระบบจะหยุดให้บริการ
ตัวอย่าง:
ระบบต้องพร้อมใช้งานไม่น้อยกว่า 99.9%
ค่า uptime 99.9% หมายถึงยอมให้ระบบหยุดได้ประมาณ 43.2 นาทีต่อเดือน หรือประมาณ 8.76 ชั่วโมงต่อปี
หากระบบหรือเครือข่ายมีปัญหา ต้องแจ้งผู้ใช้อย่างชัดเจน ไม่ปล่อยให้ผู้ใช้เข้าใจว่าเครื่องค้าง
ตัวอย่างเช่น ถ้าอินเทอร์เน็ตของสาขามีปัญหา ระบบควรแสดงข้อความแจ้งเตือนว่าไม่สามารถเชื่อมต่อได้ แทนที่จะปล่อยให้หน้าจอหมุนโหลดค้างโดยไม่มีคำอธิบาย
ลักษณะของ NFR ที่ดี
NFR ที่ดีไม่ควรเขียนกว้างเกินไป เช่น “ระบบต้องเร็ว” หรือ “ระบบต้องปลอดภัย” เพราะคำเหล่านี้ตีความได้หลายแบบ
ควรเขียนให้วัดผลได้ชัดเจน เช่น “ระบบต้องโหลดหน้าหลักภายใน 3 วินาที” หรือ “ระบบต้องรองรับผู้ใช้พร้อมกัน 1,000 คน” เพราะสามารถนำไปทดสอบได้จริง
แนวคิดสำคัญคือ NFR ที่ดีควรชัดเจน วัดได้ และเชื่อมโยงกับสถานการณ์ใช้งานจริงของระบบ
จุดสังเกตง่าย ๆ
Functional Requirements มักเป็นคำที่สื่อถึงการกระทำของระบบ เช่น เพิ่ม ลบ แก้ไข ค้นหา บันทึก หรือออกรายงาน
Non-Functional Requirements มักเป็นคำที่ขยายคุณภาพของการทำงาน เช่น เร็ว ปลอดภัย ง่าย เสถียร รองรับได้มาก หรือภายในกี่วินาที
ลองสังเกตแบบง่าย:
“ระบบต้องบันทึกข้อมูลนักศึกษาได้” คือ Functional Requirement
“ระบบต้องบันทึกข้อมูลนักศึกษาเสร็จภายใน 2 วินาที” คือ Non-Functional Requirement
ตัวอย่างเปรียบเทียบให้เห็นภาพ
Functional Requirement: ระบบต้องให้ผู้ใช้สมัครสมาชิกได้
Non-Functional Requirement: ระบบต้องส่งผลการสมัครสมาชิกกลับภายใน 2 วินาที
Functional Requirement: ระบบต้องค้นหาข้อมูลพนักงานได้
Non-Functional Requirement: ระบบต้องค้นหาข้อมูลได้แม้มีผู้ใช้พร้อมกันจำนวนมาก
Functional Requirement: ระบบต้องให้ HR ดูประวัติการลงเวลาได้
Non-Functional Requirement ระบบต้องจำกัดสิทธิ์การดูข้อมูลเฉพาะผู้มีอำนาจ
ตัวอย่างการนำไปใช้กับระบบจริง
สมมติว่ากำลังพัฒนาระบบลงเวลางานพนักงาน ฟังก์ชันหลักอาจมีการลงเวลา ดูประวัติ และออกรายงาน
แต่ NFR ที่ควรกำหนดร่วมด้วย เช่น:
ระบบต้องรองรับการใช้งานผ่านมือถือได้ดี
พนักงานต้องลงเวลาได้ภายใน 3 คลิก
ระบบต้องตอบสนองภายใน 2 วินาที
ข้อมูลตำแหน่งและภาพถ่ายต้องถูกจำกัดสิทธิ์การเข้าถึง
ระบบต้องพร้อมใช้งานไม่น้อยกว่า 99.9%
เมื่อเขียนครบทั้ง Functional และ Non-Functional Requirements จะช่วยให้ระบบไม่ใช่แค่ “ทำงานได้” แต่ “ใช้งานได้ดีจริง” ในสภาพแวดล้อมขององค์กร
แนวทางจำแบบสั้น
จำง่าย ๆ ว่า Functional คือ “ระบบทำอะไร” ส่วน Non-Functional คือ “ระบบทำได้ดีแค่ไหน”
ถ้าเห็นข้อความที่พูดถึงความเร็ว ความปลอดภัย ความง่ายในการใช้งาน หรือความเสถียรของระบบ ข้อความนั้นมักเป็น NFR