กรณีการใช้งานเทียบกับเรื่องราวของผู้ใช้: ความแตกต่างระหว่างกรณีการใช้งานและเรื่องราวของผู้ใช้

ในการพัฒนาซอฟต์แวร์แบบ Agile เรามักจะพบคำศัพท์สองคำ นั่นคือ กรณีการใช้งานและเรื่องราวของผู้ใช้ คำเหล่านี้เป็นคำศัพท์ทั่วไปบางส่วนที่ใช้โดยนักพัฒนาซอฟต์แวร์หรือผู้ที่ไม่ใช่นักพัฒนาตามการใช้งานบ่อยครั้ง ยิ่งไปกว่านั้น สำหรับผู้ที่ไม่มีความรู้พื้นฐานเกี่ยวกับการพัฒนา การใช้คำศัพท์เหล่านี้แทนกันได้ก็เป็นเรื่องปกติเช่นกัน

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

ตรวจสอบหลักสูตรฟรีเพื่อเพิ่มทักษะให้กับตัวเอง

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

กรณีการใช้งานคืออะไร?

กรณีการใช้งานสะท้อนถึงกระบวนการที่เกี่ยวข้องกับการบรรลุเป้าหมายของผลิตภัณฑ์ที่ต้องการ เป็นความต้องการของระบบที่ช่วยให้ได้รับผลิตภัณฑ์ ทำงานเป็นคำอธิบายผลิตภัณฑ์สำหรับนักแสดง (หรือผู้ใช้) ที่จะใช้ ในทางเทคนิคแล้ว มันคือปฏิสัมพันธ์ระหว่างระบบกับตัวแสดงผ่านคำอธิบาย

องค์ประกอบที่สำคัญบางประการของกรณีการใช้งาน:-

• นักแสดง: บุคคลหรือกลุ่มคนที่โต้ตอบกับระบบ
• เป้าหมาย: ผลลัพธ์สุดท้ายที่มีการพัฒนากรณีการใช้งาน
• ระบบ: ทุกขั้นตอนที่เกี่ยวข้องเพื่อให้บรรลุเป้าหมาย

กรณีการใช้งานมีความสัมพันธ์แบบเหตุและผลซึ่งรวมถึงเหตุการณ์บางอย่างที่ผู้ใช้ปลายทางอธิบายฟังก์ชันหรือคุณสมบัติของผลิตภัณฑ์ ให้ความเข้าใจโดยละเอียดเกี่ยวกับพฤติกรรมของผู้ใช้ในขณะที่โต้ตอบกับระบบ

ทีมผลิตภัณฑ์ใช้กรณีการใช้งานในการออกแบบ ทดสอบ และพัฒนาผลิตภัณฑ์ ช่วยให้พวกเขาร่างข้อกำหนดเกี่ยวกับวิธีการออกแบบคู่มือช่วยเหลือผู้ใช้ นอกจากนั้น พวกเขายังสามารถกำจัดข้อผิดพลาดได้อีกด้วย

กรณีการใช้งานคือคำอธิบายโดยละเอียดของผลิตภัณฑ์สำหรับผู้มีส่วนได้ส่วนเสียหรือผู้ใช้ปลายทาง

ตัวอย่างกรณีการใช้งาน

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

คำสั่งซื้อจะถูกจัดเตรียม บรรจุ และจัดส่งไปยังที่อยู่ ในสถานการณ์สมมตินี้ แอปพลิเคชันต้องได้รับคำสั่งซื้อและดำเนินการตัวเลือกการชำระเงินในขณะที่สื่อสารกับทั้งสองฝ่าย (ลูกค้าและผู้ค้าปลีก) ที่นี่:

• ระบบคือ – แอปพลิเคชันอีคอมเมิร์ซ
• นักแสดงหลักคือ – ลูกค้า
• สถานการณ์คือ - เรียกดูผ่านแอปพลิเคชัน

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

• ผู้ใช้เลือกรายการ
• ข้อมูลการชำระเงินและการจัดส่ง
• ยืนยันการสั่งซื้อและชำระเงิน
• เวลานับถอยหลังการสั่งซื้อหรือการติดตาม
• ข้อมูลการเรียกเก็บเงิน

ให้เราไปที่เรื่องราวของผู้ใช้และทำความเข้าใจว่า เรื่องราวของผู้ใช้แตกต่างจากกรณีการใช้งานอย่างไร

เรื่องราวของผู้ใช้คืออะไร?

เรื่องราวของผู้ใช้คือคำอธิบายสั้น ๆ ของผลิตภัณฑ์สำหรับผู้ใช้ที่จะแนะนำพวกเขาตลอดกระบวนการ เรื่องราวของผู้ใช้แต่ละคนเขียนขึ้นจากมุมมองของลูกค้าด้วยภาษาที่เข้าใจง่าย เรื่องราวของผู้ใช้มุ่งเน้นไปที่สิ่งที่ผู้ใช้ต้องการจากแพลตฟอร์มและสิ่งที่ระบบควรนำเสนอ

จากนั้นทีมพัฒนาจะรวมผู้ใช้ของข้อความที่ระบุในซอฟต์แวร์ด้วยการแก้ไขบางอย่าง เรื่องราวของผู้ใช้ประกอบด้วยปฏิสัมพันธ์ที่เกิดขึ้นตลอดกระบวนการผ่านทางซอฟต์แวร์ สามซีมีส่วนร่วมในเรื่องราวของผู้ใช้ ซึ่งเป็นแนวคิดที่รอน เจฟฟรีส์นำเสนอ เหล่านี้คือ-

• การ์ด: เรื่องราวของผู้ใช้ควรเขียนเป็นการ์ด ซึ่งหมายถึงเรื่องราวที่สั้นและชัดเจนพร้อมข้อมูลที่จำเป็นทั้งหมด
• การสนทนา: เรื่องราวของผู้ใช้ควรเป็นการสนทนาระหว่างลูกค้าและนักพัฒนาผ่านทางซอฟต์แวร์
• การยืนยัน: หมายความว่าลูกค้ายืนยันเงื่อนไขบางประการที่ควรดำเนินการก่อนที่ผลลัพธ์จะมาถึงระบบควรจะสามารถดำเนินการได้อย่างถูกต้อง

นอกจากสาม Cs ของเรื่องราวของผู้ใช้แล้ว ยังเน้นไปที่จุดประสงค์ที่สำคัญอีกประการหนึ่ง นั่นคือ การลงทุน ย่อมาจาก

• อิสระ :ของโครงการอื่นๆ
• ต่อรองได้ :พื้นที่สำหรับการพัฒนาต่อไป
• ค่า :คำอธิบายสำหรับผู้ใช้
• Estimable :เรื่องราวของผู้ใช้เพื่อดำเนินการตามแผนที่เหมาะสม
• ขนาดเล็ก :วันทำงาน จบงานภายใน 3-5 วัน
• Testable :กลไกตรวจสอบค่าหรือความถูกต้องของกระบวนการ

ตัวอย่างเรื่องราวของผู้ใช้

เรื่องราวของผู้ใช้แสดงไว้ดังนี้:

“ในฐานะ (ตัวตน) ฉัน (ต้องการ) (อย่างนั้น)”

• ในฐานะ (ตัวตน)– บุคคลที่สร้างแอปพลิเคชันหรือซอฟต์แวร์ให้ ควรเน้นผู้ใช้ปลายทาง
• ฉัน (ต้องการ)– ที่นี่ กำลังอธิบายถึงเจตนา ไม่ใช่คุณลักษณะ ควรอธิบายเป้าหมายของผู้ใช้ ไม่ใช่ส่วนของแอปพลิเคชันหรือ UI
• (ดังนั้น)– สิ่งนี้อธิบายถึงประโยชน์โดยรวมหรือภาพรวมของแอปพลิเคชัน ประโยชน์โดยรวมที่ผู้ใช้จะได้รับคืออะไร?

นี่คือตัวอย่างบางส่วนของเรื่องราวของผู้ใช้

• ในฐานะ Elie ฉันต้องการเชื่อมโยงบัตรเครดิตกับโปรไฟล์ของฉัน เพื่อที่ฉันจะได้จ่ายค่าเช่าได้ง่ายโดยไม่ต้องใช้เงินสด
• ในฐานะผู้จัดการ ฉันต้องการจัดระเบียบงานของฉันเพื่อให้ฉันสามารถควบคุมได้มากขึ้น

โครงสร้างของเรื่องราวของผู้ใช้อาจแตกต่างกัน แต่ความตั้งใจควรเหมือนกัน

ทำไมเราต้องมี Use Case และ User Story?

มีเหตุผลบางประการที่เราต้องการทั้งกรณีการใช้งานและเรื่องราวของผู้ใช้ในระบบของเรา เรามาเจาะลึกถึงจุดประสงค์เบื้องหลังเรื่องราวของผู้ใช้และกรณีการใช้งาน:-

เราต้องการกรณีการใช้งานเพื่อ–

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

เราต้องการเรื่องราวของผู้ใช้เพื่อ -

• สร้างกระบวนการที่คล่องตัว
• สร้างเป้าหมายเล็ก ๆ ที่ทำได้
• ให้ทั้งผู้ใช้ด้านเทคนิคและไม่ใช่ด้านเทคนิคอยู่ในหน้าเดียวกัน
• กำหนดกระบวนการทั้งหมด

ตรวจสอบโปรแกรม US - Data Science ของเรา

ความแตกต่างระหว่างกรณีการใช้งานและเรื่องราวของผู้ใช้

ลองมาดูความ แตกต่างระหว่างกรณีการใช้งานและเรื่องราวของผู้ใช้ เพื่อทำความเข้าใจว่าอะไรที่ทำให้ทั้งสองแตกต่างกัน:-

1. กรณีการใช้งานได้รับการพัฒนาสำหรับทีมผลิตภัณฑ์โดยคำนึงถึงเจตนาของผู้มีส่วนได้ส่วนเสีย สรุปโครงสร้างความสำเร็จสำหรับทีมเพื่อสร้างซอฟต์แวร์ที่ต้องการ กรณีการใช้งานมักมีรายละเอียดมากกว่าเรื่องราวของผู้ใช้
   เรื่องราวของผู้ใช้นั้นเรียบง่ายและเน้นผู้ใช้มากขึ้น โดยเน้นย้ำถึงงานประจำของผู้ใช้ ซึ่งเป็นเหตุผลว่าทำไมภาษาที่ใช้ในเรื่องราวของผู้ใช้จึงเข้าใจได้และมาจากมุมมองของผู้มีส่วนได้ส่วนเสียทั้งหมด
2. ตามที่กล่าวไว้ กรณีการใช้งานนั้นตรงไปตรงมามากกว่าเรื่องราวของผู้ใช้ อย่างไรก็ตาม ทั้งสองวิธีนั้นเรียบง่ายและเข้าใจง่าย
3. เรื่องราวของผู้ใช้จงใจออกจากขอบเขตเพื่อการปรับปรุง ด้วยเหตุนี้จึงต้องมีรายละเอียดเพิ่มเติม
   ในทางตรงกันข้าม กรณีการใช้งานจะตรงประเด็นและเน้นขั้นตอนทั้งหมดที่นักพัฒนาจำเป็นต้องปฏิบัติตาม
4. เรื่องราวของผู้ใช้ได้รับการพัฒนาก่อนกรณีการใช้งานและส่วนใหญ่เกิดจากการโต้ตอบ

อ่านบทความยอดนิยมในสหรัฐอเมริกา - วิทยาศาสตร์ข้อมูล

ควรใช้กรณีการใช้งานและเรื่องราวของผู้ใช้เมื่อใด

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

อย่างไรก็ตาม กรณีการใช้งานใช้เพื่อบันทึกกระบวนการ ประกอบด้วยข้อกำหนดของกระบวนการทั้งหมดเพื่อบรรลุเป้าหมายสุดท้าย กรณีการใช้งานวาดภาพที่ใหญ่ขึ้นของระบบที่มีอยู่ มันเกี่ยวข้องกับประเด็นที่ตรงไปตรงมาสำหรับกระบวนการพัฒนาที่ง่าย

เพิ่มอาชีพของคุณด้วย upGrad

การศึกษาระดับอุดมศึกษาที่เหมาะสมสามารถสร้างความแตกต่างอย่างมีนัยสำคัญสำหรับนักพัฒนาและนักวิทยาศาสตร์ข้อมูลที่ต้องการ หากคุณกำลังมองหาโอกาสในการพัฒนาทักษะและข้อมูลรับรอง โปรแกรม Executive PG ของ upGrad ในสาขาวิทยาศาสตร์ข้อมูล อาจเป็นตัวเลือกที่ยอดเยี่ยม ด้วยหลักสูตรนี้ ผู้เรียนจะได้สัมผัสกับโลกแห่งเทคนิคที่โดดเด่น WES และ Institute of Analytics ตระหนักถึงคุณค่าของหลักสูตรนี้ซึ่งจัดทำขึ้นภายใต้ความเชี่ยวชาญของผู้เชี่ยวชาญในอุตสาหกรรมชั้นนำ

บทสรุป

การพัฒนาซอฟต์แวร์แบบ Agile เกี่ยวข้องกับการพัฒนาซ้ำ วิธีการ และเทคนิคเพื่อรวมมุมมองของผู้ใช้ ด้วยเหตุนี้ความต้องการจึงเพิ่มขึ้นอย่างต่อเนื่อง ทุกอุตสาหกรรมมุ่งเน้นไปที่การพัฒนากรณีการใช้งานและเรื่องราวของผู้ใช้ในระบบของพวกเขา เพื่อให้ผลลัพธ์แต่ละรายการกลายเป็นลูกค้าเป็นศูนย์กลาง ซึ่งจะเป็นการเพิ่มความพึงพอใจของลูกค้า