Functionality กับ Non-Functionality

FunctionNonFunction

 

ประเด็นที่หลายต่อหลายคนมักงงๆ กันว่าfunctional requirement กับ non-functional requirement ต่างกันอย่างไร มีอีกเทคนิคหนึ่งที่จะแนะนำกันคือ ขั้นแรกต้องเข้าใจความหมายของคำว่า ‘functionality’ กับ ‘non-functionality’ เสียก่อน

ผมมีเทคนิคในการจำง่ายๆ ดังนี้

Functionality หมายถึง การทำงานของระบบที่ไคลเอ็นต์ (ผู้ใช้ / อุปกรณ์/ ระบบภายนอก) สามารถมีปฏิสัมพันธ์ด้วย หรือเรียกใช้ได้ตรงๆ เช่น จากรูปข้างบน ผู้ใช้สามารถเรียกใช้ฟังก์ชั่นต่างๆ ได้โดยตรง เช่น Login, Check Out เป็นต้น ส่วนกรณีไคลเอ็นต์เป็นระบบภายนอก สมัยนี้นิยมเรียกว่าเป็นการมาเรียก ‘เซอร์วิส’ เพราะคำว่า ‘ฟังก์ชั่น’ ให้ความรู้สึกว่าเป็นคนมาเรียกใช้งานระบบมากกว่า

Non-Functionality หรือในทางสถาปัตยกรรมเรียกว่า ‘กลไกทางสถาปัตยกรรม’ (architectural mechanism) หมายถึงการทำงานของระบบที่ไคลเอ็นต์ไม่สามารถมีปฏิสัมพันธ์ด้วยโดยตรงได้ หรือเรียกใช้ตรงๆ ไม่ได้นั่นเอง ซึ่งเป็นส่วนการทำงานภายใน จากรูปข้างบน เช่น กลไก Data Access, Encryption, Thread Control เป็นต้น ซึ่งกลไกฯ เหล่านี้สามารถเรียกใช้กันเองได้ และถูกเรียกใช้โดยส่วน functionality ได้ หรือฟังก์ชั่นเรียกใช้กลไกฯ หรือ functionality เรียกใช้ non-functionality นั่นเอง

ดังนั้น functional requirement หรือ use case จึงหมายถึงความต้องการที่เกี่ยวกับฟังก์ชั่นที่จะสนับสนุนผู้ใช้โดยตรงนั่นเอง ส่วน non-functional requirement (NFR) จึงหมายถึงความต้องการที่เกี่ยวกับกลไกการทำงานภายในของระบบเอง จากที่ว่า NFR มีผลต่อคุณภาพของระบบ ก็เพราะถ้าเราอยากให้เจ้าฟังก์ชั่น (functionality) มีคุณภาพที่ดี เราก็ต้องทำให้เจ้ากลไกฯ มีคุณภาพที่ดีเสียก่อน ฟังก์ชั่นเปรียบเหมือนความสามารถของมนุษย์เรา เช่น นั่ง นอน วิ่ง ขับรถ ดำน้ำ เขียนโปรแกรม เล่นกีฬา เป็นต้น ส่วนกลไกฯ เปรียบเหมือนระบบการทำงานภายในร่างกาย เช่น ระบบ (กลไก) หายใจ ระบบ (กลไก) ขับถ่าย ระบบ (กลไก) ควบคุมการทรงตัว เป็นต้น ซึ่งระบบการทำงานภายในร่างกายของเราก็ประกอบด้วยอวัยวะต่างๆ ในทางไอทีก็เหมือนกับโมดูลใหญ่ประกอบด้วยโมดูลเล็กๆ ซึ่งโมดูลเล็กๆ ก็อาจถูกแชร์ถูกเรียกใช้โดยโมดูลอื่นได้อีก

สรุป

การเก็บ วิเคราะห์ และ บริหารความต้องการ ต้องใส่ใจ non-functional requirement ด้วย และทำให้มากๆ เพราะมีผลต่อคุณภาพระบบ และมีผลต่อฟังก์ชั่นมากๆ เช่น เวลาคุยกับผู้ใช้ก็ต้องคุยเรื่องคุณภาพกันด้วย หรือจากนี้ไปเวลากำหนดคุณสมบัติแอพพลิเคชั่นเซิร์ฟเวอร์ก็ควรระบุคุณภาพที่ต้องการ และประเมินกลไกฯ ภายใน อาทิ transaction management, caching, pooling, concurrency control, loggin, locking, data mapping, authenticate, authorize, state management เป็นต้น

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s