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

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

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

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

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

มีการใช้คำสำคัญบางคำตลอดกระบวนการกรณีใช้งานทั้งหมด หลักการเหล่านี้เป็นกรอบและแกนหลักของกระบวนการทั้งหมด

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

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

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

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

ตรวจสอบหลักสูตรฟรีของเราที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์

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

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

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

สำรวจหลักสูตรวิศวกรรมซอฟต์แวร์ยอดนิยมของเรา

ทฤษฎีสามซี

องค์ประกอบที่สำคัญสามประการของเรื่องราวของผู้ใช้ที่มีประสิทธิภาพคือ 3C Ron Jeffries ผู้ร่วมคิดค้นแนวปฏิบัติเรื่อง User Story ได้นำเสนอแนวคิดนี้ ทุกวันนี้ เมื่อเราพูดถึงเรื่องราวของผู้ใช้ เรามักจะหมายถึงประเภทของเรื่องราวของผู้ใช้ที่ประกอบด้วยปัจจัยสามประการนี้

การ์ด

การ์ดใช้เขียนเรื่องราวของผู้ใช้ วลีสั้นๆ ที่มีข้อความเพียงพอจะปรากฏบนการ์ด User Story แต่ละใบเพื่อเตือนหัวข้อของเรื่องราว

การสนทนา

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

การยืนยัน

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

สำรวจหลักสูตรฟรีสำหรับการพัฒนาซอฟต์แวร์ของเรา

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

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

โฟกัสทางเทคนิคเทียบกับผู้ใช้

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

พื้นฐานกับเชิงลึก

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

ทักษะการพัฒนาซอฟต์แวร์ตามความต้องการ

บทสรุปกับรายละเอียด

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

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

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

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

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

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

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

คุณควรใช้อันไหน?

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

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

อ่านบทความยอดนิยมของเราเกี่ยวกับการพัฒนาซอฟต์แวร์

บทสรุป

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