NFR ความต้องการซ่อนแอบ ที่ถ้าไม่บอกก็ไม่เห็น
เวลาพูดถึง Requirement เรามันจะพูดถึงว่า ลูกค้าต้องการอะไร ทำแล้วมันตอบโจทย์อะไรกับ Business แล้วเราจะมี Feature หรือ Function อะไรดีนะ ที่ลูกค้าจะใช้แล้วชอบ ใช้แล้วได้ประโยชน์ ตอบสนองกับ Business ของเรา
ถ้าคุณทำ Agile ใช้ Scrum คุณอาจจะมีการทำ Product Discovery แล้วได้ Product Backlog ของเจ้า Requirement เต็มไปหมดเลย แล้วคุณก็เริ่มให้ทีม Delivery ลงมือทำ พอทีมทำไปได้สักพัก ทีก็มีงานงอกที่เรียนว่า “Tech Task” ขึ้นมาและกระทบกับ Roadmap ของ PO ทันที
เกิดอะไรขึ้นนะ!!!!! ก็เป็นเพราะว่า องค์ประกอบหลัก ของProduct มี 3 ส่วนด้วยกัน
ซึ่งหลายๆ ครั้งที่เราคุยกันแต่ Customer อยากได้อะไร Business จะทำอะไร แต่ลืมคุยในแง่ว่าถ้าจะทำแล้วมีอะไรด้าน Non Function ที่ต้องทำบ้าง
Non Function Requirement เปรียบเสมือนเบื้องหลังที่สำคัญที่จะทำให้ Product อยู่ได้
Requirement
การพัฒนา Product หรือ การพัฒนาซอฟต์แวร์ แบ่งความต้องการเป็นดังนี้
Business requirement หรือ ความต้องการเชิงธุรกิจ
เป็นความต้องการที่กำหนดโดย stakeholder ถือว่าเป็นความต้องการในระดับ ‘problem space’ ประมาณว่า ทำไมต้องทำ ตอบโจทย์ใคร แก้ปัญหาอะไร ทำแล้วลูกค้าได้อะไร บริษัทได้อะไร
ตัวอย่าง เช่น
- พัฒนาเสร็จรวดเร็วเพื่อทันต่อการใช้งานหรือขาย (Time to Market)
- ต้นทุนต่ำ หรือให้อยู่ภายในงบประมาณ (Low Cost)
- ตอบสนองพฤติกรรมของผู้ใช้งานที่หลากหลาย (Support a Variety of Customer Behavior)
- ช่วยเพิ่มกำไรสุทธิได้ 10% (Increase Net Profit)
- มีความสามารถในการแข่งขันกับคู่แข่งได้ (High Competitiveness)
- สร้างการรับรู้และเข้าใจในตัวสินค้า (ซอฟต์แวร์) ได้เร็ว (Build Awareness)
User Requirement อะไรที่ทำแล้วตอบโจทย์ลูกค้า
เป็นมุมมองในแง่ลูกค้า ว่าลูกค้าได้อะไร ทำแล้วมันตอบโจทย์อะไรให้ลูกค้า Value ที่ลูกค้าจะได้รับ มันแก้ Painpoint อะไรให้ลูกค้าไหมนะ
ตัวอย่าง เช่น
- ลูกค้าสามารถกรอกข้อมูลได้เร็วขึ้น
- ลูกค้าทำแค่สามขั้นตอนก็สำเร็จ
System Requirement: Functional Requirement
คือฟังก์ชั่นที่ลูกค้าใช้ มองเห็น สัมผัส มันหนะครับ เป็นตัวที่ทำเพื่อผู้ใช้งานโดยตรง และตอบสนองกับสิ่งที่ Business อยากทำ หลายคนคุ้นเคยกับ Functional Requirement มากกว่าประเภทอื่น เพราะสมมติฐานสำคัญคือ โดยธรรมชาติของคนเราที่คุ้นเคยกับ ‘ฟังก์ชั่น’ หรือการทำงานของสิ่งต่าง ๆ คนเรามักใส่ใจในการทำงานของสิ่งต่าง ๆ ว่าทำอะไรได้บ้าง ทำอะไรไม่ได้บ้าง
System Requirement: Non-Functional Requirement
คือความต้องการที่ไม่ใช่ functional! นั่นคือไม่ได้สนใจว่าระบบฯ ต้องทำอะไรได้บ้าง และมักเป็นการทำงานที่ผู้ใช้ไม่ได้เข้ามาใช้โดยตรง (ก็เลยเรียกว่า non-function)
แต่จะสนใจว่าระบบจะต้องมีคุณภาพด้านใดบ้างและในแต่ละ functional requirements ต้องมีคุณภาพด้านใดบ้าง สังเกตได้ว่ามีคำว่า ‘คุณภาพ’ เข้ามาเกี่ยวข้อง เพราะ NFR ถือเป็น ความต้องการที่ชี้วัดด้านคุณภาพของระบบฯ เลยทีเดียว ดังนั้นระบบฯ จะมีคุณภาพใดบ้าง มากน้อยแค่ไหน จึงจำเป็นต้องมีการระบุและอิมพลีเม้นต์ NFR ให้ถูกต้อง สำหรับ NFR เรียกได้หลายอย่าง บางตำราก็ใช้คำว่า ‘quality attribute’ เนื่องจาก NFR เปรียบเสมือนคุณสมบัติทางคุณภาพของสถาปัตยกรรมและระบบนั่นเอง
ตัวอย่าง Non-Functional Requirements เช่น
- Availability คือ ความพร้อมในการให้บริการ ไม่ล่ม ไม่หยุด
- Reliability คือ ความน่าเชื่อถือ
- Performance คือ ความเร็ว อันเกิดจากประสิทธิภาพในการประมวลผล และการใช้ทรัพยากร
- Scalability คือ ความสามารถด้านการรองรับการประมวลผลที่มากขึ้น รองรับการขยายตัวของระบบได้
- Usability คือ ความสามารถด้านการสร้างคุณค่า คุณประโยชน์ และความง่ายในการใช้งาน
- Testability คือ ความสามารถในการทดสอบ
- Modifiability คือ ความสามารถในการปรับปรุงแก้ไขได้มีความยืดหยุ่น ผลกระทบข้างเคียงน้อย
- Interoperability คือ ความสามารถในการทำงานร่วมกันได้ แม้มีข้อจำกัด เช่น ระบบบัญชีเป็น Java ระบบการเงินเป็น C#.NET
- ♣ Security คือ ความปลอดภัย
ใครกันหละจะเป็นคน Create NFR
NFR มีผลอย่างมากทั้งต่อ software architecture และกับระบบโดยรวม การระบุและวิเคราะห์จำเป็นต้องอาศัยความรู้และประสบการณ์ด้าน software architecture และด้านเทคนิคมาก และอาจจำเป็นต้องมี domain expert เพื่อช่วยในการระบุและวิเคราะห์ เช่น ผู้เชี่ยวชาญในระบบงาน ผู้เชี่ยวชาญด้านฮาร์ดแวร์ ผู้เชี่ยวชาญด้านรักษาความปลอดภัย เป็นต้น
จะเห็นจากตรงนี้เลยว่าจริงๆ แล้ว คำว่า Requiremnt มีหลากหลายประเภท ถ้าเราทำ Agile ใช้ Scrum แล้วมุ่งเนี้ยทำ User Story ที่มองแค่มุมด้าน Business และ ลูกค้าเพียงอย่างเดียว โดยลืมมองไปว่า พื้นฐานที่จะตอบสนอง Requirment พวกนั้นก็คือ Tech Task ต่างๆ
จัดการ NFR ตั้งแต่เริ่มต้นด้วยการ คุยสิ่งนี้ใน Discovery
เพราะฉะนั้น ในแต่ละ Sprint ที่คุณทำอาจจะต้องการทำ Balance ระหว่าง Function Requirment และ Non Function Requirment ไปด้วย
เพื่อที่จะได้ Potentially Shippable Product Increment หรือ ของที่พร้อมให้ลูกค้าใช้แล้วรักมัน จริงๆ
