ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 วารสาร มฉก.วิชาการ 169

เทคนิคการคนหาและเก็บเกี่ยวความตองการทางดานซอฟทแวร

Software Requirements Eliciting Techniques

บุญประเสริฐ สุรักษรัตนสกุล*

บุญชวย ชาติทอง**

บทคัดย่อ

ในกระบวนการทางวิศวกรรมความต้องการ ขั้นตอนการเก็บเกี่ยวความต้องการเป็นขั้นตอนที่มี

ความสำคัญและเป็นจุดเริ่มของข้อมูลสำคัญที่ใช้ในการพัฒนาระบบ เช่น เป้าหมายการพัฒนาระบบ

การค้นหาปัญหาที่แท้จริง แนวทางการแก้ไขปัญหา และข้อมูลความต้องการทางด้านซอฟท์แวร์ โดย

ขั้นตอนการเก็บเกี่ยวความต้องการทางด้านซอฟท์แวร์ จะเริ่มต้นที่การกำหนดและค้นหาแหล่งที่มาของ

ปัญหา การวางแผนเตรียมพร้อมรับปัญหาที่เกิดขึ้นระหว่างการค้นหาและการเก็บเกี่ยว การระบุหลักการ

และเทคนิคต่างๆที่ใช้ในการเก็บเกี่ยวความต้องการให้ตรงกับกลุ่มเป้าหมายด้วยวิธีการที่เหมาะสม ซึ่ง

เปน็ขัน้ตอนสำคญัในการไดม้าของความตอ้งการทีถ่กูตอ้งและครบถว้น ขัน้ตอนสดุทา้ย คอื การตรวจทาน

ความต้องการที่ได้เก็บเกี่ยวมาโดยผู้ที่มีส่วนเกี่ยวข้อง แล้วทำการระบุเป็นความต้องการที่นำไปพัฒนา

จริงในกระบวนการขั้นตอนทางวิศวกรรมซอฟท์แวร์ต่อไป

คำสำคัญ:ความต้องการทางด้านซอฟท์แวร์ เทคนิคการเก็บเกี่ยวความต้องการ วิศวกรรมความต้องการ

Abstract

On Requirements Engineering process, Requirements Eliciting is an initial step in

software development process. It delivers the critical information such as project goal,

encounter problems, and software requirements, for developing the required system. In

addition, it helps to identify the sources of needs, list of predicted problems, and elicit

techniques, for example, requirements workshop, brainstorming, storyboarding, interview,

* ผู้ช่วยศาสตราจารย์ สถาบันเทคโนโลยีพระจอมเกล้าเจ้าคุณทหารลาดกระบัง

** งานแผนงาน คณะเทคโนโลยีสารสนเทศ สถาบันเทคโนโลยีพระจอมเกล้าเจ้าคุณทหารลาดกระบัง

วารสาร มฉก.วิชาการ ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 170

questionnaire, role playing and prototype. The result of eliciting process will be verified

and validated before to be the software requirements, then delivery to the next process in

software development life cycle.

Keywords:Software requirements, eliciting techniques, requirements engineering

บทนำ

ในกระบวนการพัฒนาระบบซอฟท์แวร์

ความต้องการจากผู้ว่าจ้าง ผู้ใช้งานและผู้ที่มีส่วน

เกีย่วขอ้ง จะเปน็ขอ้มลูเริม่ตน้สำคญัในกระบวนการ

ทางวิศวกรรมซอฟท์แวร์ ความต้องการที่ค้นหา

และเก็บเกี่ยวมานั้นจะถูกนำมาจำแนกกลั่นกรอง

ทำให้มีคุณภาพและจัดเก็บอย่างเป็นระบบตาม

หลักของการจัดการความต้องการ เพื่อให้ความ

ต้องการมีความพร้อมใช้งานในกระบวนการ

ขั้นตอนถัดไป ซึ่งเรียกกระบวนการนี้ว่า วิศวกรรม

ความต้องการทางด้านซอฟท์แวร์ (Kotonya

Kotonya & Sommerville. 1998 : 68) ถา้การไดม้า

ของความต้องการขาดคุณภาพ มีความผิดพลาด

และถูกจัดการอย่างไม่เป็นระบบ จะส่งผลกระทบ

ให้กระบวนการพัฒนาในขั้นตอนถัดไปล้มเหลว

ทำให้โครงการพัฒนาซอฟท์แวร์นั้นไม่ประสบ

ความสำเร็จ เป็นผลให้ผลิตภัณฑ์ซอฟท์แวร์

ที่ได้ ด้อยคุณภาพ ไม่ตรงตามความต้องการของ

ผู้ว่าจ้าง ผู้ใช้งานและผู้ที่มีส่วนเกี่ยวข้องกับระบบ

(Sommerville. 2010 : 128)

ในกระบวนการทางวศิวกรรมความตอ้งการ

ขั้นตอนการเก็บเกี่ยวความต้องการเป็นขั้นตอน

หนึ่งที่มีความสำคัญและเป็นจุดเริ่มของข้อมูล

สำคญัในการพฒันาระบบ ขัน้ตอนในการเกบ็เกีย่ว

ความต้องการจะเริ่มต้นที่การกำหนดและค้นหา

แหล่งที่มาของความต้องการ การระบุปัญหาที่แท้

จริงที่ทำให้เกิดความต้องการระบบใหม่ การเลือก

ใช้เทคนิคในการเก็บเกี่ยวความต้องการ และการ

ตรวจทานความตอ้งการเพือ่ระบเุปน็ความตอ้งการ

ที่จะนำไปใช้ในการพัฒนาระบบ (leffingwell and

widrig. 2004 : 98 ; IBM Rational Requisite

Pro. 2555 : Online)

แหลง่ทีม่าของความตอ้งการเชงิซอฟทแ์วร์

โดยทั่วไปแล้ว ความต้องการทางด้าน

ซอฟท์แวร์มีที่มาจากหลายๆแหล่ง ทั้งมาจาก

องค์กรหรือบุคคลที่เกี่ยวข้อง ซึ่งเป็นหน้าที่ของ

นกัวเิคราะหร์ะบบเปน็ผูร้วบรวมความตอ้งการและ

ค้นหาแหล่งที่คาดว่าจะได้มาของความต้องการ

ซึ่งอาจได้มาจากทั้งภายในและภายนอกองค์กร

ตัวอย่างของแหล่งที่มาของความต้องการ เช่น

ฝ่ายการตลาด ผู้ใช้งานระบบ ลูกค้าองค์กร หรือ

อาจจะเป็นใครก็ตามที่พิจารณาแล้วว่าเป็นผู้ที่มี

ส่วนเกี่ยวข้องในระบบ เป็นต้น แหล่งที่มาของ

ความต้องการ นอกจากจะเป็นตัวบุคคลในองค์กร

แล้ว ยังสามารถอยู่ในรูปของเอกสารต่างๆ ที่

เกี่ยวข้องได้ ตัวอย่างเช่น เอกสารที่เกี่ยวข้องกับ

ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 วารสาร มฉก.วิชาการ 171

กระบวนการปฏิบัติงาน (statement of work)

เอกสารที่เป็นคำร้องขอโดยตรงจากผู้ที่มีส่วนได้

สว่นเสยีกบัระบบ (request for proposal) เอกสาร

กำกับพันธกิจขององค์กร (mission statement)

หรืออาจจะเป็นคำชี้แจงปัญหา (problem state-

ment) ซึ่งผู้ว่าจ้างหรือผู้ใช้งานพบและร้องขอ

การแก้ไขสำหรับการพัฒนาระบบซอฟท์แวร์ใหม่

(Rational Software. 2005 : 256-258)

นอกจากนี้ ยังมีเอกสารอื่นๆ ที่ผู้เก็บเกี่ยว

ความต้องการ อาจต้องทำการศึกษาเพิ่มเติม เพื่อ

ใช้ประกอบการเก็บเกี่ยวและค้นหาความต้องการ

ตวัอยา่งเชน่ เอกสารทีแ่สดงกระบวนการทางธรุกจิ

(business rules) เอกสารที่เป็นกฎระเบียบและ

ข้อบังคับต่างๆ (laws and regulations) เอกสาร

ที่แสดงระบบอื่นที่จะใช้ร่วมกับระบบที่กำลังจะ

พัฒนาขึ้นหรือเอกสารข้อมูลการทำงานของระบบ

เดิม (legacy systems) และรูปแบบเชิงธุรกิจ

(business models) เป็นต้น รูปที่ 1 แสดงแหล่ง

ที่มาของความต้องการทางด้านซอฟท์แวร์ และ

บทบาทของผู้ที่มีส่วนให้ความต้องการ

ñ ñ

ô òนักวิเคราะห์ระบบ / ผู้เก็บเกี่ยวความต้องการ

หุ้นส่วน /

ผู้ที่มีส่วนได้ส่วนเสียทางธุรกิจ

- เงื่อนไขของความต้องการ

- แผนการดำเนินงานทางธุรกิจ

- เป้าหมายส่วนบุคคลในแต่ละบทบาท

- โมเดลเชิงธุรกิจ ผู้ว่าจ้าง

- รายงานข้อผิดพลาดในระบบเดิม

- คำร้องขอการเปลี่ยนแปลง

ผู้ใช้งานระบบ

- ข้อเสนอแนะจากผู้เชี่ยวชาญ

- นักวิเคราะห์ระบบธุรกิจ

- ข้อมูลการแข่งขัน

ขอบเขตของปัญหา

รูปที่1แหล่งที่มาของความต้องการ

วารสาร มฉก.วิชาการ ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 172

ปัญหาในการเก็บเกี่ยวความต้องการ

ปัญหาที่เกิดขึ้นในการเก็บเกี่ยวความ

ต้องการมีที่มาที่หลากหลาย เช่น อาจมาจากผู้ที่มี

ส่วนเกี่ยวข้องหรือผู้ที่มีส่วนได้ส่วนเสียกับระบบ

ยกตัวอย่างเช่น ผู้ที่ให้ข้อมูลความต้องการไม่รู้ว่า

อะไรคือสิ่งที่ตนเองต้องการอย่างแท้จริง หรืออาจ

จะรู้แต่ไม่สามารถกล่าวได้ชัดเจนว่าตนเองนั้น

ต้องการอะไร หรืออธิบายออกมาให้ผู้ที่เก็บเกี่ยว

ความต้องการเข้าใจได้ หรือบางครั้งคิดว่ารู้ในสิ่งที่

ตนเองต้องการ แต่จำหรือนึกถึงไม่ได้เมื่ออยู่ใน

กระบวนการเก็บเกี่ยว ซึ่งต้องอาศัยการกระตุ้นใน

การฟื้นการจดจำ นอกจากนี้ บางปัญหาเกิดจาก

ผู้ที่เก็บเกี่ยวความต้องการหรือนักวิเคราะห์เอง

เช่น ผู้ที่เก็บเกี่ยวความต้องการหรือนักวิเคราะห์

คิดว่าตนเองเข้าใจปัญหาได้ดีกว่าผู้ใช้งานระบบ

(user) ตัวจริง และสุดท้าย เป็นปัญหาที่อาจเกิด

ขึ้นโดยทั่วไป เช่น ผู้ที่ให้ข้อมูลมีความเชื่อลึกๆ ว่า

มแีรงผลกัดนัทางการเมอืงในการปรบัเปลีย่นระบบ

หรือขาดแรงบันดาลใจในการพัฒนาระบบและ

ความอยากได้ระบบใหม่ของผู้ใช้งาน ซึ่งทั้งหมดนี้

คือ ปัญหาในภาพกว้างที่เกิดขึ้นโดยทั่วไป เมื่อมี

กระบวนการเกบ็เกีย่วความตอ้งการทางดา้นซอฟท ์

แวร์ (kotonya and sommerville. 1998 : 312)

รปูแบบการดำเนนิงานเมือ่มกีารเกบ็เกีย่ว

ความต้องการ

รปูแบบการดำเนนิงานเมือ่มกีารเกบ็เกีย่ว

ความต้องการ จะอยู่ในรูปแบบของการส่งมอบ

แล้วตรวจสอบแบบเป็นวงรอบคล้ายก้นหอย

(spiral model) โดยมีจุดมุ่งหมายเพื่อให้เกิดความ

เข้าใจหรือการยอมรับระหว่างกันให้มากที่สุด

โดยจะมีการปรับปรุงข้อมูลความต้องการไปเรื่อยๆ

ซึ่งการปรับปรุงข้อมูลจะเกิดขึ้นจนกระทั่งได้

ข้อตกลงร่วมกันระหว่างผู้ว่าจ้าง ผู้ใช้งานและผู้ที่

มสีว่นเกีย่วขอ้งในโครงการพฒันาระบบซอฟทแ์วร ์

(Borland. 2012 : Online)

ข้อควรตระหนักของผู้ เก็บเกี่ยวความ

ต้องการในการดำเนินการ คือ การที่ผู้เก็บเกี่ยว

ความต้องการต้องยอมรับความล้มเหลวของความ

ต้องการที่ได้เก็บเกี่ยวมาแล้วอย่างถูกวิธี เนื่องจาก

ทุกครั้งที่มีการปฏิเสธจากผู้ที่เกี่ยวข้องหรือผู้ที่

ทำการตรวจทาน ผู้เก็บเกี่ยวความต้องการจะได้

ข้อมูลใหม่ ซึ่งสิ่งนั้นกลับเป็นข้อมูลสำคัญในการ

เก็บเกี่ยวความต้องการต่อไปให้ถูกแนวทาง โดย

กระบวนการการปฏิเสธนี้จะช่วยให้ผู้ที่เก็บเกี่ยว

ความต้องการได้รู้ว่าอะไรเป็นสิ่งที่สำคัญในองค์กร

(บุญประเสริฐ สุรักษ์รัตนสกุล. 2551 : 2)

เทคนิคการเก็บเกี่ยวความต้องการ

เทคนิคการเก็บเกี่ยวความต้องการมี

หลายวิธี ขึ้นอยู่กับนักวิเคราะห์และผู้เก็บเกี่ยว

ความต้องการทำการวางแผนร่วมกัน เพื่อกำหนด

กรอบและคัดเลือกเทคนิคที่ใช้ในการเก็บเกี่ยว

โดยแต่ละเทคนิคนั้น จะมีคุณลักษณะเฉพาะที่

เน้นในการเก็บเกี่ยวความต้องการที่แตกต่างกัน

ทั้งนี้อาจขึ้นอยู่กับระดับความต้องการหรือกลุ่ม

เป้าหมายที่ต้องการเก็บเกี่ยว

ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 วารสาร มฉก.วิชาการ 173

โดยทัว่ไปแลว้ การเกบ็เกีย่วความตอ้งการ

จะดำเนินงานภายใต้กรอบที่ได้มาจากการประชุม

เชงิปฏบิตัเิพือ่การเกบ็เกีย่วความตอ้งการ (require-

ments workshop) ซึ่งในการประชุมเชิงปฏิบัติ

การดังกล่าว จะมีการนำเทคนิคการเก็บเกี่ยว

ความตอ้งการมาบง่ใชใ้หเ้หมาะสมกบักลุม่เปา้หมาย

ภายใต้ระยะเวลา งบประมาณ หรือเงื่อนไข

กำหนด ซึ่งเทคนิคที่บทความนี้นำเสนอ ประกอบ

ด้วย เทคนิคการระดมและปรับรูปแบบความคิด

(brainstorming and idea reduction) การสร้าง

ยูสเคสโมเดล (use case model) เพื่อค้นหา

ความต้องการ (use case workshops) การทำ

ภาพประกอบเรือ่งราว (storyboards) การสมัภาษณ ์

(interviews) การใช้แบบสอบถาม (question-

naires) การสวมบทบาทปฏิบัติ (role playing)

การสร้างแบบจำลองหรือต้นแบบ (prototypes)

และส่วนสุดท้าย คือ การทบทวนการกำหนด

ความตอ้งการจากผูท้ีเ่กีย่วขอ้ง แลว้ทำการระบเุปน็

ความต้องการที่จะนำไปใช้งานจริงในกระบวนการ

ทางวิศวกรรมซอฟท์แวร์ต่อไป ซึ่งความต้องการที่

ได้จากเทคนิคเหล่านี้ อาจเป็นได้ทั้งความต้องการ

ในระดับสูงจากผู้ที่มีส่วนได้ส่วนเสียกับระบบ

(stakeholder needs) ความต้องการที่ เป็น

คุณลักษณะของระบบใหม่ (features) หรือความ

ต้องการเชิงซอฟท์แวร์ (software require-

ments) (Rational Software. 2005 : 288)

การประชุมเชิงปฏิบัติการเพื่อเก็บเกี่ยว

ความต้องการ มีเป้าหมายเพื่อสร้างขอบเขตของ

ความเห็นร่วมกันระหว่างผู้พัฒนาระบบ ผู้ว่าจ้าง

และผู้ที่มีส่วนเกี่ยวข้องกับการพัฒนาระบบ ใน

การประชุมจะมีการพิจารณาความเสี่ยงที่อาจเกิด

ขึ้น รวมถึงการค้นหาคุณลักษณะสำคัญเบื้องต้น

ของระบบซอฟท์แวร์ใหม่ที่กำลังจะพัฒนา มีการ

ทำบทวิเคราะห์ปัญหา โดยใช้เทคนิคการระดม

ความคิดร่วม เพื่อสร้างจุดสัมฤทธิ์ผลขององค์กร

ในอนาคต โดยอาจเริ่มต้นจากการพิจารณาจาก

ปัญหาที่เกิดขึ้น ณ ปัจจุบัน เช่น มีปัญหาใดที่

ทำให้ธุรกิจไม่เติบโตตามเป้าหมาย เป็นต้น อาจมี

การทำบทวิเคราะห์ปัจจัยของความสำเร็จและ

ต่อต้าน (force field analysis) เพื่อพิจารณา

การสง่เสรมิใหธ้รุกจิดำเนนิไปสูเ่ปา้หมายทีต่อ้งการ

อาจมีการวิเคราะห์พลังยั้งหรือพลังต่อต้านการ

เปลี่ยนแปลง (restraining forces) ที่เกิดขึ้น ซึ่ง

ผลผลิตที่ได้ในขั้นตอนสุดท้าย อาจอยู่ในรูปแบบ

ของการชี้แจงปัญหา (problem statement) เพื่อ

กำหนดในเอกสารกำหนดเป้าหมายของโครงการ

(vision document) สำหรับการพัฒนาระบบที่จะ

เกิดขึ้น (Sommerville. 2010 : 335)

ในการประชุมเชิงปฏิบัติการนี้ ต้องมีผู้ที่

ทำหน้าที่เป็นผู้ดำเนินการ (moderator) เพื่อ

ทำการไกล่เกลี่ยหามติข้อสรุปที่ได้จากการประชุม

โดยคุณสมบัติของผู้ดำเนินการ ต้องมีความ

เป็นกลางและงดแสดงความคิดเห็นใดๆ ทั้งสิ้น

กจิกรรมนีอ้าจใชร้ะยะเวลา 3-5 วนั ในการประชมุ

วางแผน ซึ่งสิ่งที่คาดหวังว่าจะได้รับจากการ

ประชุมเชิงปฏิบัติการ คือ บทวิเคราะห์ปัญหา

ข้อมูลความต้องการที่สำคัญที่ได้มาจากการระดม

ความคิด โมเดลเชิงธุรกิจเบื้องต้น และลำดับ

ความเสี่ยงที่อาจเกิดขึ้น

วารสาร มฉก.วิชาการ ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 174

การประชมุเชงิปฏบิตักิารเพือ่การเกบ็เกีย่ว

ความต้องการ เป็นกระบวนการที่อยู่ในรูปแบบ

ของการลงทุนและการใช้เวลาให้คุ้มค่า (cost-

effective and time-efficient) โดยหวังผล

การตอบรบัจากผูเ้ขา้รว่มการประชมุ ภายใตแ้นวคดิ

แบบ JAD (Joint Application Development)

หรือ RAD (Rapid Application Development)

ซึ่งเป็นแนวความคิดที่เน้นผู้ใช้งานขั้นสุดท้ายเป็น

กุญแจในการให้ข้อมูลสำคัญ (บุญประเสริฐ สุรักษ์

รัตนสกุล. 2551 : 2)

ข้อดีของเทคนิคนี้ คือ ในการเก็บเกี่ยว

ความต้องการบ่อยครั้งจะใช้เวลานาน เนื่องจาก

ผู้ที่มีส่วนเกี่ยวข้องแต่ละคน ต่างมีความต้องการ

ทีเ่ปน็ของตนเอง และมคีวามขดัแยง้กบัความตอ้งการ

ของผู้ที่มีส่วนเกี่ยวข้องอื่น การที่รวมทุกคนเพื่อ

ทำการเก็บเกี่ยวความต้องการอย่างพร้อมเพรียง

กนั จะชว่ยเพิม่ความเรว็ในการเกบ็เกีย่วความตอ้งการ

เนื่องจากความขัดแย้งของความต้องการที่ถูกค้น

พบ จะถูกตกลงในที่ประชุมร่วมกันทันทีภายใต้

ความคิดร่วมของทุกฝ่ายที่เกี่ยวข้อง นอกจากนี้

การประชุมแบบรวมกลุ่ม (group-oriented) จะ

ช่วยให้การระดมความคิดร่วมดำเนินไปได้อย่าง

รวดเรว็แลว้ ยงัเปน็จดุเริม่ตน้สำหรบัแนวความคดิ

ในการพัฒนาแผนภาพยูสเคส ซึ่งเป็นแผนภาพ

ที่มีความสำคัญในการพัฒนาระบบขั้นตอนถัดไป

(IBM Rational RequisitePro. 2555 : Online)

ข้อแนะนำสำหรับการจัดการประชุมเพื่อ

การเก็บเกี่ยวความต้องการ (บุญประเสริฐ สุรักษ์

รัตนสกุล, สุรเชษฐ์ สูรย์ส่องธานี และสิสา

สิมะสาธิตกุล. 2552 : 2)

- ควรเตรียมรูปแบบ อุปกรณ์และ

เทคนิคในการเก็บเกี่ยวความต้องการให้พร้อม

เช่น เทคนิคการระดมความคิด และการใช้ภาพ

ประกอบเรื่องราว เป็นต้น

- ควรมีวิธีการเร่งกระบวนการในการ

เก็บเกี่ยว

- ควรมีผู้ที่ทำหน้าที่ดูแลและจัดการ

กำหนดเวลาให้เป็นไปตามแผน

- พยายามให้ผู้ที่มีส่วนเกี่ยวข้องทุกคน

มีส่วนร่วม และควรแสดงผลลัพธ์ที่ได้ให้เห็นคุณ-

ประโยชน์ทันที

รปูที ่2 แสดงตวัอยา่งคำแนะนำการวางแผน

การประชุมเชิงปฏิบัติการเพื่อการเก็บเกี่ยวความ

ต้องการ ซึ่งผู้ที่เก็บเกี่ยวความต้องการสามารถนำ

ไปประยุกต์ใช้ได้

ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 วารสาร มฉก.วิชาการ 175

การระดมความคิด เป็นเทคนิคหนึ่งที่

ช่วยกระตุ้นให้เกิดแนวความคิดที่หลากหลายได้

อย่างรวดเร็ว และลำดับของแนวความคิดเป็นสิ่ง

สำคัญที่จะพัฒนาแนวคิดให้ดำเนินไปสู่เป้าหมาย

ที่ต้องการได้ โดยการระดมความคิดต้องอยู่บน

“กฎของการระดมความคดิ” ซึง่ผูท้ีท่ำการเกบ็เกีย่ว

ความตอ้งการตอ้งยดึถอืปฏบิตัอิยา่งเครง่ครดั ดงันี้

- การระดมความคิดต้องมีเป้าหมายที่

ชัดเจนแน่นอน

- ผูท้ีเ่สนอความคดิทกุคนมสีทิธเิทา่เทยีม

และมีความเสมอภาคกันในการแสดงความคิด

- การปลดปล่อยความคิดต้องไม่ถูก

ครอบงำหรือมีการควบคุม

- ความคิดที่แสดงออกมาต้องไม่พาดพิง

ถึงบุคคลอื่นและไม่ควรให้เกิดการวิจารณ์กัน

- ต้องมีการปรับและรวบรวมความคิด

ที่ซ้ำซ้อนหรือความคิดที่มีความหมายเดียวกัน

เนื่องจากการระดมความคิด อาจมีความคิด

เดียวกันที่มาในหลายรูปแบบ

ขั้นเตรียมการ

Pre-workshop

- จัดตั้งการประชุม

- จัดทีมงาน

- เตรียมงานสนับสนุน

- เตรียมความพร้อมก่อน

ปฏิบัติ (warm-up)

- เตรียมหัวข้อ

- จัดตั้งการประชุม

ขั้นดำเนินการ

Session

- อำนวยความสะดวก

- รักษาการดำเนินงาน

- จดบันทึก

- ย่อใจความ รวบรัด

- สรุป

- อำนวยความสะดวก

ขั้นสรุปผลิตผล

Production

- สังเคราะห์สิ่งที่ได้

- ดึงสารสนเทศที่สำคัญ

- สังเคราะห์สิ่งที่ได้

ขั้นติดตามผล

Follow-up

- เสนอผู้ว่าจ้าง

- กำหนดขั้นตอนที่จะ

ดำเนินการต่อไป

- เสนอผู้ว่าจ้าง

รูปที่2 ตัวอย่างคำแนะนำการวางแผนการประชุมเชิงปฏิบัติการเพื่อการเก็บเกี่ยวความต้องการ

จุดเด่นของเทคนิคการระดมความคิด

เป็นเทคนิคหนึ่งที่ช่วยในการกำหนดความต้องการ

ที่เป็นคุณลักษณะของซอฟท์แวร์ในระบบใหม่และ

มีที่มาจากผู้ที่มีส่วนเกี่ยวข้องทุกคนอย่างแท้จริง

ขั้นตอนต่อไปนี้ เป็นแนวทางขั้นตอน

การระดมความคิดที่แนะนำให้ผู้เก็บเกี่ยวความ

ต้องการดำเนินการ ซึ่งผู้ที่เก็บเกี่ยวความต้องการ

ไม่ควรข้ามขั้นตอนใดขั้นตอนหนึ่ง

เริ่มต้นจากผู้ที่ทำการเก็บเกี่ยวความ

ต้องการอาจใช้กระดาษที่มีแถบกาวหรือโพสอิท

(post-it) เป็นเครื่องมือในการระดมความคิด โดย

ให้ผู้ที่มีส่วนเกี่ยวข้องทุกคนเขียนคุณลักษณะของ

ระบบใหม่ที่ตนต้องการที่สุดหรือสามลำดับแรก

ที่ต้องการมากที่สุด ทั้งนี้ขึ้นอยู่กับจำนวนผู้ร่วม

กิจกรรมและความเหมาะสม จากนั้น ให้ผู้ที่ทำ

การเขียนเสร็จแล้ว นำไปติดไว้ที่ผนังที่ผู้ที่มีส่วน

เกี่ยวข้องทุกคนไม่สามารถรู้ได้ว่าใครติดกระดาษ

ความคิดของตนไว้ที่ใด และต้องไม่มีการกำหนด

วารสาร มฉก.วิชาการ ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 176

ตำแหน่งการติด โดยการเขียนความคิดของตนเอง

นัน้ ตอ้งปราศจากการลอกเลยีนแบบหรอืการพดูคยุ

เมื่อผู้ที่มีส่วนเกี่ยวข้องทุกคนแสดงความ

คิดของตนเองผ่านกระดาษติดผนังครบถ้วนแล้ว

ขั้นตอนถัดมา คือ แบ่งประเภทของความคิดที่ได้

มา โดยให้เชิญผู้ที่มีส่วนเกี่ยวข้องทุกคนย้ายความ

สนใจมาที่ปัญหาและอธิบายคุณลักษณะที่ต้องการ

จากแผ่นกระดาษที่ผู้ร่วมกิจกรรมเสนอ ซึ่งการ

ดำเนินการต้องปราศจากการพูดคุย เพื่อให้ผู้ที่

เสนอความคิด ยังคงยึดมั่นไม่ไขว้เขวกับสิ่งที่ตน

ได้เสนอความคิดไว้

เมื่อมีการอภิปรายแต่ละแนวคิดให้ผู้เข้า

ร่วมกิจกรรมทราบแล้ว ต้องทำการตั้งชื่อแนวคิด

โดยการกำหนดชื่อต้องมาจากความคิดเห็นของ

ผู้เข้าร่วมกิจกรรมช่วยกันตั้งชื่อ ซึ่งในขั้นตอนนี้

อาจมีการตัดแนวคิดบางอย่างที่ไม่เกี่ยวข้องออก

ซึ่งมีข้อควรระวัง คือ ก่อนที่จะตัดแนวความคิด

บางอยา่งหรอืแนวความคดิทีใ่ชก้ารวจิารณ ์ความคดิ

อาจเริ่มเปลี่ยนแปลงได้เมื่อได้ยินความคิดของ

ผู้อื่น ซึ่งข้อนี้ควรต้องระวัง เพราะความคิดที่ดี

ที่สุด คือ ความคิดที่สร้างขึ้นบนทักษะความรู้และ

ความคิดสร้างสรรค์จากคนหลายๆ คนในกลุ่ม

ขั้นตอนสุดท้าย คือ การจัดลำดับความสำคัญของ

แนวคิดที่มีอยู่ เมื่อกลั่นกรองแล้วว่ามีความคิด

ใดบ้างที่เป็นความต้องการเชิงคุณลักษณะของ

ซอฟท์แวร์ จากนั้น ให้ใช้กระบวนการจัดลำดับ

ความสำคญั เชน่ การโหวตหวัขอ้ (bullet voting)

ในการจัดลำดับ

การนำยสูเคสมาชว่ยค้นหาความต้องการ

ยูสเคสเป็นแผนภาพที่แสดงแนวความคิดสะท้อน

ความสัมพันธ์ระหว่างความต้องการกับผู้ที่มีส่วน

เกี่ยวข้องกับระบบ โดยการเตรียมมุมมองในส่วน

ของผู้กระทำการกับระบบและแสดงแนวความคิด

ของผู้ใช้ ว่าผู้ใช้ต้องกระทำการใดให้สำเร็จ ซึ่งเปน็

บริบทสำคัญในการวิเคราะห์และออกแบบระบบ

นอกจากนี ้ยงัมสีว่นชว่ยในเรือ่งของการคน้หาสิง่ที ่

ผูท้ีม่สีว่นเกีย่วขอ้งตอ้งการ เชน่ ใครเปน็ผูต้อ้งการ

หรือกระทำการกับระบบ วิธีที่ต้องการใช้ระบบ

และส่วนเชื่อมต่อกับระบบที่อยู่ในรูปแบบอื่นๆ

การนำยูสเคสมาช่วยในการค้นหาความ

ต้องการ ควรใช้ร่วมกับเทคนิคการเก็บเกี่ยววิธีอื่น

ประกอบ เช่น ใช้การประชุมเชิงปฏิบัติการสำหรับ

วเิคราะหข์อบเขตของงาน การกำหนดผูก้ระทำการ

และยูสเคส นอกจากนี้ การรวมกลุ่มยังส่งเสริม

การแสดงความคิดในการตั้งชื่อยูสเคส และการ

สร้างคำศัพท์ที่ใช้ร่วมกันได้ด้วย หรือใช้เทคนิค

ภาพประกอบเรื่องราว สำหรับการค้นหาลำดับ

ของการกระทำ (sequence of actions) ซึ่งเป็น

รายละเอียดบรรยายของยูสเคส และเนื่องจาก

แผนภาพยูสเคสนั้น จะถูกนำมาใช้ในขั้นตอน

การวิเคราะห์และออกแบบ ดังนั้น การจัดทำแผน

ภาพยูสเคสควรต้องมีความละเอียดรอบคอบ ซึ่ง

อาจต้องมีคำถามเพื่อส่งเสริมการอภิปราย เช่น

ทำไมระบบถึงมีความต้องการนี้ ใครหรือสิ่งใดมี

ปฏิสัมพันธ์กับระบบอย่างไร ผู้ใช้ต้องการอะไรจาก

การทำงานของระบบ ระบบควรมีส่วนติดต่อกับ

อะไรบ้าง เป็นต้น (Rumbaugh, Jacobson,

Booch. 1998 : 223-224)

ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 วารสาร มฉก.วิชาการ 177

คำแนะนำในการดำเนินงานเพื่อเขียน

แผนภาพยูสเคส อาจเริ่มต้นจากการจัดการการจัด

ประชุมรวบรวมความคิดเห็น โดยมีการแบ่งกลุ่ม

ออกมาเปน็กลุม่เลก็ๆ ซึง่ไมค่วรมสีมาชกิเกนิ 10 คน

โดยครึ่งหนึ่งเป็นทีมผู้พัฒนาและอีกครึ่งที่เหลือ

เป็นตัวแทนของผู้ใช้งาน การดำเนินงานจัดสร้าง

ยูสเคสช่วงเริ่มต้น ควรต้องดำเนินไปอย่างรวดเร็ว

เนื่องจากแนวคิดที่เกิดขึ้นอย่างรวดเร็วครั้งแรก

เป็นแนวคิดที่มีนัยสำคัญ สำหรับเครื่องมือที่ใช้

ประกอบกิจกรรม อาจมีกระดานแบบมีขาตั้ง

กระดาษปะติด ปากกาหลายๆ สี และกระดาน

ไวท์บอร์ด

ภาพประกอบเรื่องราว เป็นเทคนิคที่เกิด

จากอุตสาหกรรมภาพยนตร์ที่นำมาประยุกต์ใช้

ในการเก็บเกี่ยวความต้องการ โดยเฉพาะการเก็บ

เกี่ยวความต้องการในระดับสูง หรือความต้องการ

ที่มาจากผู้ที่มีส่วนได้ส่วนเสียโดยตรง (needs) ซึ่ง

ภาพประกอบเรื่องราว สามารถอยู่ในรูปแบบของ

ภาพยนตร ์การต์นูอะนเิมชัน่ (animation cartoon)

และภาพเสมือน ซึ่งการทำภาพประกอบเรื่องราว

นี้ เป็นเทคนิคหนึ่งที่ให้ผู้ใช้งานระบบที่กล่าวถึง

ลำดับการกระทำที่มาจากยูสเคสหรือขั้นตอนใน

ยูสเคสได้ง่ายและชัดเจนมากขึ้นโดยการทำภาพ

ประกอบเรื่องราวควรต้องแสดงเรื่องราว 3 สิ่ง

ให้เห็น ประกอบด้วย 1) มีใครบ้าง และใครเป็น

ผู้กระทำการ 2) เกิดอะไรขึ้นกับสิ่งเหล่านั้น และ

3) เกิดขึ้นเมื่อไร ซึ่งประโยชน์ของภาพประกอบ

เรื่องราวมีดังนี้

- ช่วยรวบรวมความคิดและปรับรูปแบบ

ความต้องการของผู้ที่เกี่ยวข้องให้อยู่ในรูปแบบที่

เป็นมิตรและง่ายขึ้น

- สง่เสรมิความคดิสรา้งสรรคแ์ละวธิกีาร

แก้ไขที่แปลกใหม่

- ส่งเสริมการทบทวนให้แก่สมาชิกใน

ทีม ทำให้เกิดจินตนาการจากรูปภาพที่สอดคล้อง

แนวทางเดียวกัน

- ช่วยเพิ่มความมั่นใจว่าคุณลักษณะ

ของระบบที่สร้างเสร็จแล้ว จะสามารถเข้าถึงได้

และมีความถูกต้อง

- ช่วยหลีกเลี่ยงอาการเงียบ (blank-

page syndrome) เมือ่ทำการเกบ็เกีย่วความตอ้งการ

การสัมภาษณ์ เป็นเทคนิคหนึ่งที่ผู้เก็บ

เกี่ยวความต้องการสามารถได้รับความต้องการ

จากผู้ที่มีส่วนเกี่ยวข้องได้โดยตรง เป็นเทคนิค

ที่ง่ายและตรงไปตรงมา เหมาะสำหรับใช้ในการ

วิเคราะห์ปัญหาเพื่อทำการเก็บเกี่ยวความต้องการ

และวิธีการแก้ไขที่อาจเกิดขึ้น โดยพิจารณาจาก

มมุมองตา่งๆ ของผูใ้ชง้าน ผูว้า่จา้ง และผูท้ีม่สีว่นได ้

ส่วนเสียกับระบบ คำถามที่ใช้ในการสัมภาษณ์

ต้องมีความเป็นกลางกับสิ่งที่จะดำเนินการและ

ความรู้ที่ใช้ในการแก้ไขปัญหา การสัมภาษณ์ควร

เริ่มต้นจากคำถามง่ายๆ หรือคำถามเบื้องต้นที่

เกี่ยวกับโครงการ

ข้อแนะนำในการสัมภาษณ์มีดังนี้ ควร

หลีกเลี่ยงคำถามที่ผู้ถูกถามไม่ได้ทำเป็นประจำ

ไม่ควรถามในสิ่งที่ไม่จำเป็นที่ต้องอธิบายหรือ

ไม่สามารถอธิบายได้ และการสัมภาษณ์ควร

วารสาร มฉก.วิชาการ ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 178

หลีกเลี่ยงคำถามรูปแบบ “ทำไม” กับบุคคลที่

ทำการสัมภาษณ์ การตั้งคำถามควรเป็นแบบ

คำถามปลายเปดิ (context-free questions) และ

ควรอดทนกับการรอคำตอบ อย่าคาดหวังคำตอบ

ที่เป็นพื้นฐาน และควรอนุญาตให้ผู้ที่ถูกถามคิด

คำตอบได้โดยไม่มีการตัดบท การถามควรถาม

ตามคำตอบต่อไปเรื่อยๆเพื่อให้เกิดความต่อเนื่อง

และเกิดการจัดลำดับความคิด และที่สำคัญควร

ปฏิบัติตนเป็นผู้ฟังที่ดี

ลักษณะของคำถามปลายเปิด จะเป็น

คำถามในระดับสูง หรืออาจเป็นคำถามเชิงนาม-

ธรรม ซึ่งช่วยให้ได้รับข้อมูลในภาพกว้างและ

แนวทางการแก้ไข เป็นคำถามที่ช่วยให้ได้รับ

ข้อมูลที่ เข้าใจปัญหาที่แท้จริง การตั้งคำถาม

ปลายเปิดในการสัมภาษณ์ อาจมุ่งประเด็นสนใจ

ไปที่ 4 ประเด็น ดังนี้ 1) ประเด็นผู้ใช้งานระบบ

2 ) ประเด็นกระบวนการทำงานของระบบ

(process) 3) ประเด็นของระบบที่กำลังจะพัฒนา

หรอืผลลพัธท์ีต่อ้งการไดจ้ากระบบ (product) และ

4) คำถามเพื่อกำกับการถาม (meta-questions)

ตัวอย่างของคำถามปลายเปิดในแต่ละ

ประเด็น

1. คำถามในส่วนของผู้ใช้ เช่น “ใคร

คือ ผู้ใช้งานระบบ” “หน้าที่รับผิดชอบหลักของ

ผู้ใช้งานแต่ละคน คืออะไร” “ผู้ใช้งานในส่วนตรง

นี้ ควรต้องมีความรู้พื้นฐานอะไรบ้าง” เป็นต้น

2. คำถามที่เกี่ยวกับกระบวนการทำงาน

ของระบบ เช่น “คุณคิดว่าปัญหาที่เกิดขึ้นตอนนี้

คือ อะไร” “ในเวลานี้ มีแนวทางการแก้ไขปัญหา

ที่เกิดขึ้นอย่างไรบ้าง” “อยากให้มีการแก้ไขปัญหา

อย่างไร” “เราสามารถหาวิธีการแก้ไขปัญหาได้

จากที่ใดได้บ้าง” เป็นต้น

3. คำถามที่ เกี่ยวกับระบบที่กำลังจะ

พัฒนา เช่น “ผลกระทบที่อาจเกิดขึ้นกับระบบมี

อะไรบ้าง” “ระบบนี้สามารถตอบสนองแผนหรือ

ปัญหาธุรกิจอะไร” “ผู้ใช้คาดหวังเกี่ยวกับการใช้

งาน และความน่าเชื่อถือของระบบที่จะเกิดขึ้น

อย่างไรบ้าง” เป็นต้น

4. คำถามเพื่ อกำกับการถาม เช่น

“คำถามที่ถามเข้าประเด็นที่ต้องการหรือไม่” “คุณ

เป็นคนที่ตอบคำถามนี้ ได้หรือไม่” “คำตอบที่ได้

ช่วยเสนอความต้องการหรือไม่” “มีประเด็นอื่นอีก

หรือไม่ ที่ควรถามแต่ยังไม่ได้ถาม” เป็นต้น

ตัวอย่างคำถามที่ไม่ใช่คำถามปลายเปิด

(non-context-free) ที่ผู้เก็บเกี่ยวความต้องการ

ควรหลีกเลี่ยง เมื่อใช้เทคนิคการสัมภาษณ์

- คำถามชี้นำ เช่น “คุณต้องการจอ

คอมพิวเตอร์ที่ใหญ่กว่านี้ใช่ไหม”

- คำถามที่มีคำตอบในตัวตัวคำถาม เช่น

“สิ่งที่ต้องแสดงต้องมี 50 รายการ ใช่หรือไม่”

- คำถามเชิงควบคุม เช่น “ถ้าผมย้อน

กลับไปคำถามที่ ถามก่อนหน้านี้ อาจมีการ

เปลี่ยนแปลงใช่ไหม”

- คำถามที่ยาวเกินไป และซับซ้อน เช่น

“คำถามที่จะถามนี้มีทั้งหมด 3 ส่วน ดังนี้ …”

สิ่งสุดท้ายที่ผู้เก็บเกี่ยวความต้องการควร

ระลึกถึง เมื่อมีการสัมภาษณ์ คือ “การสัมภาษณ์

เป็นเรื่องที่ง่าย แต่ข้อมูลที่ได้อาจไม่เป็นประโยชน์

ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 วารสาร มฉก.วิชาการ 179

ถ้าคำถามปลายเปิดนั้นเป็นคำถามที่ไม่สามารถ

ชักนำคำตอบมาใช้งานได้”

การใช้แบบสอบถาม เป็นเทคนิคที่เอื้อ

ประโยชน์ในการเก็บเกี่ยวข้อมูลความต้องการ

ที่มาของแบบสอบถามส่วนใหญ่มีที่มาจากการ

เขียนโดยการสัมภาษณ์เพื่อกำหนดคำถามที่จะใช้

ในแบบสอบถาม ซึ่งการกำหนดผู้ที่จะทำการ

สัมภาษณ์หรือจำนวนผู้ที่จะถูกสัมภาษณ์เพื่อนำ

คำถามมาใช้ในแบบสอบถามนั้น ต้องเลือกผู้ที่มี

ความเข้าใจลึกซึ้งในระบบเป็นอย่างดี เพื่อให้ได้

แบบสอบถามที่สามารถเก็บข้อมูลที่เป็นประโยชน์

โดยมากการสัมภาษณ์เพื่อให้ได้คำถามในแบบ

สอบถาม จะใช้คำถามปลายเปิด เพื่อให้เกิดการ

แสดงความคิดเห็นใหม่ คุณสมบัติของเทคนิค

แบบสอบถาม มีดังนี้

- เปน็การเขา้ถงึกลุม่เปา้หมายทีค่อ่นขา้ง

กว้างและจำนวนมาก

- มี ส่ ว น ที่ ต้ อ ง ใ ช้ ห ลั ก ก า ร ท า ง

คณิตศาสตร์ เนื่องจากต้องมีการวิเคราะห์ข้อมูล

ทางสถิติ

- ต้องมีการประยุกต์คำถามให้เหมาะสม

กับกลุ่มคน และสถานที่ที่แจกแบบสอบถาม

- ห้ามนำแบบสอบถามมาใช้สำหรับการ

สัมภาษณ์

- การวางคำถามในแบบสอบถาม ต้อง

เป็นคำถามที่ สามารถนำไปสู่การตัดสินใจใน

อนาคตได้ และถ้อยคำในคำถามต้องแสดงเจตนา

ที่ถามให้ผู้อ่านรับรู้ได้

แบบสอบถามอาจทำได้ยาก เพราะต้อง

ใช้เวลามากในการออกแบบและทดสอบแบบ

สอบถามก่อนนำไปใช้ในการเก็บเกี่ยว ซึ่งถ้าขาด

การทดสอบหรือขาดการตรวจสอบอย่างละเอียด

แล้ว อาจทำให้ได้คำตอบที่ไม่คุ้มค่ากับการลงมือ

ทำกิจกรรม หรืออาจจะไม่ได้คำตอบที่ช่วยให้

สามารถแก้ปัญหาได้

สิ่ งสำคัญอี กสิ่ งหนึ่ งสำหรับการทำ

แบบสอบถาม คือ การวิเคราะห์ทางสถิติเชิง

วิทยาศาสตร์เพื่อให้ได้ผลลัพธ์ที่แท้จริง อย่างไร

ก็ตาม แบบสอบถามต้องหลีกเลี่ยงการลำเอียง

ผลลัพธ์ และต้องตั้งถามคำถามที่ไม่ลำเอียงกับ

คำตอบ

การสวมบทบาทปฏิบัติ ปัญหาหนึ่งที่พบ

ได้บ่อยในการจัดสร้างยูสเคส คือ การไม่สามารถ

อธิบายกิจกรรมที่ซับซ้อนที่เกิดขึ้นในงานที่กระทำ

อยู่ได้ ซึ่งเทคนิคหนึ่งสำหรับการเรียนรู้เกี่ยวกับ

สิ่งที่ผู้ใช้ระบบต้องกระทำหรือการทำงานของ

ระบบ คือ การทำในสิ่งที่ผู้ใช้ระบบนั้นทำ โดยอาจ

ให้ทำงานข้างๆ ผู้ใช้ระบบจนกระทั่งรู้ปัญหาที่ผู้ใช้

ระบบนั้นพบ

ผู้ เก็บเกี่ยวความต้องการอาจนำการ

วิเคราะห์แบบ walkthrough ในเทคนิคการสวม

บทบาทได้ นอกจากนี้เทคนิคการสวมบทบาท

ยังเป็นแนวทางหนึ่งที่ใช้ตรวจสอบยูสเคส เพื่อ

สังเกตขั้นตอนในการทำงาน (scenario) ซึ่งเป็น

พื้นฐานสำหรับการพัฒนาแผนภาพยูสเคส (use

case diagram) จุดเด่นของเทคนิคนี้ คือ ได้รู้

วารสาร มฉก.วิชาการ ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 180

ปัญหาที่แท้จริ งในบริบทของการเกิดปัญหา

(problem domain) และสามารถพบปัญหา

เฉพาะหน้าที่ผู้ใช้ระบบนั้นพบได้

การพัฒนาต้นแบบ เป็นเทคนิคที่ช่วยใน

การเก็บเกี่ยวความต้องการในส่วนของการติดต่อ

กับผู้ใช้ (user - interface) รวมถึงความสามารถ

ในการใช้งานของผู้ใช้กับระบบ (usability) ซึ่งการ

สร้างต้นแบบจำลองการติดต่อระหว่างผู้ใช้งานกับ

ระบบ มีที่มาจากการรวบรวมข้อมูลความต้องการ

ของผู้ที่มีส่วนเกี่ยวข้องกับส่วนที่ติดต่อกับผู้ใช้ของ

ระบบในบทบาทต่างๆ ซึ่งจุดเด่นของการพัฒนา

ต้นแบบมีไว้ช่วยแสดงความเข้าใจในปัญหาที่พบ

ช่วยค้นพบความต้องการที่ยังไม่ทราบ ช่วยแสดง

ให้เห็นถึงพฤติกรรมบางส่วนหรืออาจทั้งหมดของ

ระบบอย่างคร่าวๆ และเพื่อประโยชน์ในการ

ทบทวนและการทดสอบ ทั้งนี้การพัฒนาต้นแบบ

ยังสามารถติดตามผลตอบรับ (feedback) จาก

ผูใ้ชง้านระบบสำหรบัการเขยีนโปรแกรมขัน้สดุทา้ย

ของส่วนติดต่อกับผู้ใช้ได้และแนวทางการแก้ไข

ปัญหาที่ยกขึ้นมาได้

บทบาทของผู้ที่มีส่วนเกี่ยวข้องกับการ

พัฒนาต้นแบบการติดต่อใช้งาน (user-interface

prototype)

- ผู้เขียนยูสเคส เพื่อให้เข้าใจส่วนติดต่อ

กับผู้กระทำการกับยูสเคส

- นักวิเคราะห์ระบบ เพื่อให้เข้าใจว่า

ส่วนติดต่อกับผู้ใช้นั้น ส่งผลต่อการวิเคราะห์ระบบ

อย่างไร

- นักออกแบบระบบ เพื่อให้เข้าใจว่า

ส่วนติดต่อกับผู้ใช้นั้นส่งผลต่อระบบอย่างไร และ

ส่วนติดต่อนั้นต้องแสดงข้อมูลอะไรจากสิ่งที่อยู่

ภายในระบบให้กับผู้ใช้งาน

- ผู้ ที่ ทำหน้าที่ ในการทดสอบคลาส

(class) เพื่อการออกแบบกิจกรรมการทดสอบ

หรือกรณีทดสอบผ่านส่วนการติดต่อกับผู้ใช้นั้นๆ

ประโยชน์ที่ได้จากการพัฒนาต้นแบบ คือ

ช่วยเก็บเกี่ยวและเข้าใจความต้องการ ช่วยพิสูจน์

และเข้าใจทางเทคโนโลยี ช่วยลดความเสี่ยง

เพิ่มโอกาสและแสดงความเข้าใจ ช่วยเพิ่ม

ประสิทธิภาพในปรับปรุงให้ดีขึ้นทางด้านประเมิน

งบประมาณและเวลา และช่วยนิยามคุณลักษณะ

ของระบบ การพัฒนาต้นแบบนั้น สามารถพัฒนา

ได้ตั้งแต่ในชั้นต้นๆ หลังจากที่มีการเก็บข้อมูล

ความต้องการมาได้ระดับหนึ่ง หรืออาจจะเริ่ม

พัฒนาในระยะต้นของการวิเคราะห์และออกแบบ

ระบบ โดยจุดประสงค์ของการสร้างต้นแบบ

เพื่อให้สามารถเปิดเผยและทดสอบทั้งฟังก์ชัน

(function) และความสามารถในการใช้ประโยชน์

ของระบบก่อนที่จะลงมือพัฒนาจริง โดยการ

เริ่มต้นการพัฒนาวิธีนี้สามารถสร้างความมั่นใจ

ได้ว่า สร้างระบบที่ถูกต้องก่อนที่จะเสียเวลาและ

ทรัพยากรในการพัฒนา

การพัฒนาต้นแบบ มีอยู่ 2 ลักษณะ

ลักษณะแรก คือ การสร้างต้นแบบเพื่อใช้งานตาม

วัตถุประสงค์ เมื่อต้นแบบที่สร้างสามารถตอบ

สนองความต้องการได้ตามวัตถุประสงค์แล้ว

จึงหยุดทำการพัฒนา ส่วนอีกลักษณะ จะเป็น

ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 วารสาร มฉก.วิชาการ 181

การพัฒนาต้นแบบต่อไปเรื่อยๆ จนกระทั่งต้นแบบ

ที่สร้างนั้นเป็นระบบจริงที่ใช้ในการส่งมอบงาน

ซึ่งลักษณะหลังจะเป็นการลงทุนที่คุ้มค่ามากกว่า

แต่อย่างไรก็ตาม การเลือกลักษณะการพัฒนา

ต้นแบบ อาจขึ้นอยู่กับบริบทของสภาพแวดล้อม

ในการพัฒนาด้วย

ตรวจสอบความต้องการที่ได้มาจากผู้ที่

มีส่วนเกี่ยวข้อง เมื่อผู้เก็บเกี่ยวความต้องการได้

ความต้องการมาเป็นที่เรียบร้อยแล้ว ขั้นตอน

สุดท้ายก่อนที่จะระบุเป็นความต้องการในการ

พัฒนาระบบ คือ การทำความเข้าใจกับความ

ต้องการนั้นอย่างถ่องแท้และจัดจำแนกประเภท

โดยการจำแนกอาจพิจารณาได้ 3 ด้าน ได้แก่

ด้านพฤติกรรมการใช้ ด้านคุณลักษณะพฤติกรรม

และดา้นประเดน็และสมมตฐิาน ขัน้ตอนถดัมา คอื

เขียนความต้องการนั้นอยู่ในรูปแบบลายลักษณ์

อักษร เพื่อใช้ในการตรวจทาน ซึ่งผู้ที่ตรวจทานได้

ดีที่สุด คือ ผู้ที่ให้ความต้องการนั้นเอง โดยการ

เขียนความต้องการ ผู้ที่เขียนควรเข้าใจในสภาพ

แวดล้อมและมุมมองของผู้ให้ความต้องการ ซึ่ง

สิ่งนี้จะช่วยให้การระบุความต้องการเป็นไปอย่าง

รวดเร็วและชัดเจนยิ่งขึ้น

ร ะดั บประสบการณ์ ขอ งผู้ ที่ มี ส่ วน

เกี่ยวข้องหรือผู้ตรวจทาน และระดับประสบการณ์

ของสมาชิกทีมพัฒนา เป็นปัจจัยที่สำคัญในการ

กำหนดเทคนิคสำหรับกำหนดความต้องการได้

อย่างถูกต้องและเหมาะสม เช่น

- ห า ก ผู้ ที่ ใ ห้ ค ว า ม ต้ อ ง ก า ร มี

ประสบการณ์ในการใช้งานระบบมาก และผู้เก็บ

เกี่ยวและวิเคราะห์ความต้องการมีประสบการณ์

สูงเช่นกัน ลักษณะของความต้องการจะอยู่ใน

รูปแบบของ “เกิดการพัฒนา (mature)”

- ห า ก ผู้ ที่ ใ ห้ ค ว า ม ต้ อ ง ก า ร มี

ประสบการณ์ในการใช้งานระบบมาก แต่ผู้เก็บ

เกี่ยวและวิเคราะห์ความต้องการมีประสบการณ์

น้อย ลักษณะของความต้องการจะอยู่ในรูปแบบ

ของ “การจับประเด็น (catch up)”

- ห า ก ผู้ ที่ ใ ห้ ค ว า ม ต้ อ ง ก า ร มี

ประสบการณ์ในการใช้งานระบบน้อย แต่ผู้เก็บ

เกี่ยวและวิเคราะห์ความต้องการมีประสบการณ์

สูง ลักษณะของความต้องการจะอยู่ในรูปแบบ

ของ “การนำเสนอหรือแนะนำ (sel l ing /

teaching)”

- ห า ก ผู้ ที่ ใ ห้ ค ว า ม ต้ อ ง ก า ร มี

ประสบการณ์ในการใช้งานระบบน้อย และผู้เก็บ

เกี่ยวและวิเคราะห์ความต้องการมีประสบการณ์

น้อยเช่นกัน ลักษณะของความต้องการจะอยู่

ในรูปแบบของ “ปัญหาที่ยังคลุมเครือ (fuzzy

problem)”

รปูที ่ 3 เปน็แผนภาพทีแ่สดงความสมัพนัธ ์

ระหว่างประสบการณ์ของผู้ เก็บเกี่ยวและผู้ที่

ให้ความต้องการกับรูปแบบของผลลัพธ์ที่ ได้

ประสบการณ์ของผู้ใช้งานระบบ

วารสาร มฉก.วิชาการ ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 182

บทสรุป

ในกระบวนการทางวศิวกรรมความตอ้งการ

ขั้นตอนการเก็บเกี่ยวความต้องการเป็นขั้นตอน

ที่มีความสำคัญและเป็นจุดเริ่มของข้อมูลสำคัญ

ในการพัฒนาระบบ โดยขั้นตอนในการเก็บเกี่ยว

ความต้องการ จะเริ่มต้นที่การกำหนดและค้นหา

แหล่งที่มาของความต้องการ มีการตระหนักถึง

ปญัหาทีเ่กดิขึน้ระหวา่งการคน้หาและการเกบ็เกีย่ว

มีการระบุหลักการและเทคนิคต่างๆ ที่ใช้ในการ

เก็บเกี่ยวความต้องการให้ตรงกับกลุ่มเป้าหมาย

อย่างเหมาะสม ซึ่ งส่วนนี้ อาจขึ้นอยู่สภาพ

ประส

บการ

ณ์ขอ

งผู้พัฒ

นาระ

บบ

สูง

ต่ำ สูง ประสบการณ์ของผู้พัฒนาระบบ

“จับประเด็น”

(catch up)

“ปัญหาคลุมเครือ”

(fuzzy problem)

“เกิดการพัฒนา”

(mature)

“นำเสนอหรือแนะนำ”

(selling / teaching)

ที่มา: Rational Software, 2005.

รูปที่3ความสัมพันธ์ระหว่างประสบการณ์กับรูปแบบของผลลัพธ์ที่ได้จากกระบวนการเก็บเกี่ยว

แวดล้อมและประสบการณ์ของทีมผู้พัฒนาระบบ

ในการเลือกใช้เทคนิคต่างๆ และสุดท้าย คือ

การตรวจทานความต้องการที่ ได้เก็บเกี่ยวมา

โดยผู้ที่มีส่วนเกี่ยวข้อง แล้วทำการระบุเป็นความ

ต้องการที่จะนำไปพัฒนาจริงในกระบวนการ

ขั้นตอนทางวิศวกรรมซอฟท์แวร์ต่อไป แต่อย่างไร

ก็ตาม คำตอบของการเก็บเกี่ยวการความต้องการ

ให้ประสบความสำเร็จนั้น มีปัจจัยหลายด้านเป็น

องค์ประกอบ ซึ่งประสบการณ์จริงและการฝึกฝน

อย่างสม่ำเสมอเป็นสิ่ งสำคัญที่จะผลักดันให้

ประสบความสำเร็จ

\[

ปีที่ 16 ฉบับที่ 32 มกราคม - มิถุนายน 2556 วารสาร มฉก.วิชาการ 183

เอกสารอ้างอิง

บุญประเสริฐ สุรักษ์รัตนสกุล. (2551) “สถาปัตยกรรมเครื่องมือจัดการความต้องการโดยใช้แนวคิดเชิง

บริการ” ในการประชุมวิชาการ ม.อ.ภูเก็ตวิจัย ครั้งที่ 1 สหวิทยาการเพื่อการพัฒนาอย่าง

ยั่งยืน. ภูเก็ต : มหาวิทยาลัยสงขลานครินทร์ วิทยาเขตภูเก็ต.

บุญประเสริฐ สุรักษ์รัตนสกุล สุรเชษฐ์ สูรย์ส่องธานี ลิสา และสิมะสาธิตกุล. (2552) “ระบบบริหาร

จัดการความต้องการทางซอฟต์แวร์แบบเว็บเซอร์วิส” ในการประชุมวิชาการและนำเสนอ

ผลงานวิจัยนานาชาติ ครั้งที่ 2 ความร่วมมือเพื่อการพัฒนาบนเส้นทางระเบียงเศรษฐกิจ

ตะวันออก-ตะวันตก. สกลนคร : มหาวิทยาลัยราชภัฏสกลนคร.

Booch, G, Rumbaugh, J and Jacobson, I. (1998) TheUnifiedModelingLanguageUser

Guide. Reading, Massachusetts : Addison-Wesley.

Borland. CaliberRM Enterprise Software Requirements Management System. (2012)

[Online] Available : http://www.borland.com/us/products/caliber/index.html. (15

October 2012)

IBM. Rational RequisitePro: A Requirements Management tool. (2008) [Online]

Available : http://www-01.ibm.com/software/awdtools/reqpro/ (25 September

2012)

Kotonya G. and Sommerville I. (1998) Requirements Engineering Processes and

Techniques. Chichester : John Wiley & Sons.

Leffingwell Dean, and Widrig Don. (2004) Managing Software Requirements: A Use

Case Approach. 2nd Edition. Reading, Massachusetts : Addison-Wesley

Professional.

Rational Software. (2005) Requirements Management with Use Case. Boston,

Massachusetts : Addison-Wesley.

Sommerville, lan. (2010) Software Engineering. 9th Edition. Boston, Massachusetts :

Addison-Wesley.

184