Functional Requirement หรือ Use Case

Functional Requirement หรือ ในทางการพัฒนาซอฟต์แวร์แบบ Object-Orientation เรียกว่า Use Case คือ ความต้องการที่เกี่ยวกับการทำงานของระบบ ว่าระบบต้องทำอะไรได้บ้างเพื่อสนับสนุนการใช้งานโดยไคลเอ็นต์ เป็นการทำงานที่ไคลเอ็นต์ใช้ได้โดยตรง  หากไคลเอ็นต์เป็นระบบภายนอกสมัยนี้นิยมเรียกว่า ‘เซอร์วิส’ เป็นการเข้ามาเรียกเซอร์วิส

ทีมพัฒนาระบบส่วนมากมักชอบระบุฟังก์ชั่นกันก่อน แล้วค่อยมาระบุไคลเอ็นต์หรือผู้ใช้ภายหลัง จริงๆ ควรระบุไคลเอ็นต์ก่อน แล้วค่อยระบุฟังก์ชั่นภายหลัง เพราะนักไอทีมีวิธีคิดแบบ ‘ในออกนอก’ (inside-out) แต่งาน requirement ควรคิดแบบ ‘นอกเข้าใน’ (outside-in) เหมือนการทำธุรกิจ ต้องมองตลาดก่อน เข้าใจลูกค้าก่อน แล้วค่อยมาดูว่าออกแบบและพัฒนาผลิตภัณฑ์อะไรไปขายลูกค้า นักไอทีชอบคิดถึงระบบก่อน แล้วก็นั่งเทียนฝันถึงฟังก์ชั่น คิดแต่ว่าระบบต้องมีฟังก์ชั่นอะไรบ้าง

 

*ไม่ใช่ทุกสิ่งที่ระบบทำแล้วเหมารวมเรียกว่า ‘ฟังก์ชั่น’ จำง่ายๆ แบบนี้ละกันครับ ฟังก์ชั่นหรือเซอร์วิส คือ การทำงานที่ไคลเอ็นต์เข้ามาเรียกใช้ได้โดยตรง ส่วนการทำงานภายในระบบที่ไคลเอ็นต์เรียกใช้ไม่ได้ (เช่น transaction management, data access, โมดูลคำนวณภาษี) เรียกว่า ‘กลไกการทำงานภายใน’ ซึ่งไม่ใช่ฟังก์ชั่นหรือเซอร์วิส โดยเจ้ากลไกการทำงานภายในนี้ เรียกอีกอย่างได้ว่า ‘กลไกทางสถาปัตยกรรม’ (architectural mechanism) หรือคือส่วนการทำงานที่เป็น ‘non-function’ นั่นเอง (ดู Functionality & Non-Functionality)

การจัดกลุ่มฟังก์ชั่น

นอกจากนี้ที่หนักกันไปใหญ่ คือ พอระบุฟังก์ชั่นได้เยอะก็มานั่งจัดกลุ่มฟังก์ชั่น หรือจัดกลุ่ม use case ซึ่งทำไม่ได้! จัดกลุ่มไม่ได้เด็ดขาด! ไม่ควรทำ เอาเกณฑ์อะไรมาจัดกลุ่มฟังก์ชั่น? การจัดกลุ่มฟังก์ชั่นที่นิยมทำๆ กันคือใช้เกณฑ์ด้าน business function โดยเห็นว่ามันเกี่ยวข้องกันก็เลยจัดอยู่ในกลุ่มเดียวกัน จัดหัวข้อเสร็จสรรพ แล้วพอจะมาออกแบบละพัฒนาระบบก็ดันเผลอใช้การจัดกลุ่มนั้นเป็นกรอบด้วยเลย กลายเป็นระบบต้องแบ่งฟังก์ชั่นเป็นกลุ่มๆ ตามนั้น ซึ่งจริงๆ แล้วการจัดกลุ่มฟังก์ชั่นในระบบ (ออกเป็นโมดูล หรือ subsystem) มันต้องออกแบบสถาปัตยกรรมระบบก่อน แล้ววางโครงสร้างสถาปัตยกรรม ดังนั้นหมายความว่าการจัดกลุ่มฟังก์ชั่นในระดับ business modeling หรือ requirement กับในระดับสถาปัตยกรรมระบบ ไม่จำเป็นต้องมีกลุ่มเหมือนกัน มีจำนวนเหมือนกัน หรือแม้แต่มีฟังก์ชั่นชื่อเดียวกัน

แต่คราวนี้หากจัดกลุ่มไม่ตรงกันในระดับ requirement กับ สถาปัตยกรรม ก็จะทำให้สับสนอีก อาจทำให้การจัดการเรื่องอื่นๆ เช่น traceability, testing ยุ่งยากก็ได้ ดังนั้น การจัดกลุ่มฟังก์ชั่นใน 2 ระดับนี้ควรตรงกัน หมายความว่าการจัดกลุ่มฟังก์ชั่นในระดับ requirement ควรผ่านการพิจารณาโดย architect ควบคู่กับการออกแบบสถาปัตยกรรม ไม่ใช่นึกอยากจะจัดเองก็จัด ส่วนการจัดกลุ่มฟังก์ชั่นในระดับ business modeling อันนี้จัดอย่างไรก็ได้ ไม่จำเป็นต้องจัดตรงกันกับระดับ requirement และ สถาปัตยกรรม

 

ไคลเอ็นต์, System Actor, User, External System

ไคลเอ็นต์ คือ สิ่งที่เรียกใช้ระบบ เข้ามาเรียกใช้งานระบบ เป็นคนก็ได้ ระบบภายนอกก็ได้

System Actor คือ สิ่งที่ระบบมีปฏิสัมพันธ์ด้วย มี 3 ประเภท ได้แก่ คน อุปกรณ์ ระบบภายนอก เช่น คน (ผู้ใช้) ใช้งานระบบ, เซนเซอร์ประตูส่งสัญญาณมายังระบบเพื่อให้ประมวลผล, ระบบส่งคำสั่ง SQL ไปยัง database, ระบบส่ง SMS ไปให้แอดมิน,

User คือ ผู้ใช้ เป็น ‘คน’

External System คือ ระบบภายนอกที่ระบบเราไปเชื่อมต่อหรือทำงานด้วย เช่น ระบบบัญชี, database, mail server

 

โดยส่วนใหญ่ผมชอบใช้คำว่า ‘ไคลเอ็นต์’ มากที่สุด เพราะกว้างดี พูดกับใครก็เข้าใจง่าย อย่างคำว่า ‘System Actor’ หลายคนที่ไม่คุ้นกับแนวทางพัฒนาระบบแบบ Object-Orientation มักไม่เข้าใจ ซึ่งก็ไม่ผิด แต่ทำให้ผมต้องเสียเวลาอธิบายว่ามันคืออะไร จึงเป็นเหตุผลที่ผมชอบใช้คำว่า ‘ไคลเอ็นต์’ เพราะ…ง่ายดี 🙂

 

การระบุไคลเอ็นต์หรือผู้ใช้ด้วยการวิเคราะห์ business process

สามารถระบุไคลเอ็นต์ก่อนได้ด้วยการวิเคราะห์ business process เช่น ใน process งานพิจารณาสินเชื่อลูกค้า ปัจจุบันเจ้าหน้าที่สินเชื่อต้องใช้โปรแกรมหลายโปรแกรมดึงข้อมูลออกมาเป็น Excel แล้วเอามาวิเคราะห์เองโดยใช้สูตรที่เขียนไว้ใน Excel ช่วยคำนวณ

เมื่อวิเคราะห์ business process แล้วพบว่า เจ้าหน้าที่สินเชื่อ คือ business worker และ การพิจารณาสินเชื่อ คือ business activity จากนั้นพบว่าขั้นตอนนี้เป็นขั้นตอนสำคัญ คุ้มค่าที่ระบบควรสนับสนุนงานขั้นตอนนี้ของเจ้าหน้าที่สินเชื่อ เพราะมีประโยชน์ต่อภาพรวม เมื่อสรุปฟันธงว่าจะให้ระบบที่กำลังจะพัฒนาสนับสนุนงานพิจารณาสินเชื่อ ดังนั้นเราก็จะได้ไคลเอ็นต์ก็คือ เจ้าหน้าที่สินเชื่อ นั่นเอง (การระบุไคลเอ็นต์ควรระบุเป็นชื่อบทบาท ดีกว่าชื่อคนหรือชื่อตำแหน่ง) ส่วนฟังก์ชั่นก็คือ พิจารณาสินเชื่อ นั่นเอง ง่ายไหมครับ?

เทคนิคนี้มีประโยชน์และง่าย ได้ทั้งทำความเข้าใจกระบวนการทำงานของลูกค้าและยังได้วิเคราะห์เพื่อหา functional requirement ไปในตัว นอกจากนี้ชื่อไคลเอ็นต์ก็จะเกาะ (มี coupling) กับบทบาทคนทำงาน และชื่อฟังก์ชั่นก็จะเกาะกับ business activity ไปตลอด ทำให้การบริหาร traceability, impact, risk ง่ายขึ้นมีประสิทธิภาพขึ้น เวลามี change request ก็จะวิเคราะห์ง่าย

ใส่ความเห็น

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