มีการจำแนกที่ชัดเจน แต่ง่ายและเข้าใจได้ของความแตกต่างระหว่าง "use case", "User Story" และ "ฉากการใช้งาน" หรือไม่?

มีคำอธิบายมากมาย แต่ตอนนี้ฉันไม่เห็นใครอธิบายความแตกต่างในประโยคเดียวหรือสอง ...

(เช่นhttp://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparisonนานและยากที่จะได้รับเต็มไปด้วยการอภิปราย)

เรื่องผู้ใช้เป็นทางการมากขึ้น, รุ่นมิตรและขนาดเล็กของใช้กรณีลบแผนภาพ UML นั้น มันมักจะใช้ในสถานการณ์ซ้ำ

สถานการณ์การใช้งานเป็นกรณีใช้ดึงออกมาเป็นขั้นตอนขั้นตอนโดยขั้นตอนบางครั้งมาพร้อมกับผัง

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

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

อ้างอิงจากสกอตต์ดับเบิลยูแอมโบเลอร์เกี่ยวกับสถานการณ์การใช้งานสิ่งประดิษฐ์เหล่านี้ดูเหมือนโฟลว์ของ Use Case:

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

สุจริตความแตกต่างกับการไหลของกรณีการใช้งานไม่ชัดเจนแม้หลังจากอ่านย่อหน้านี้ (ประโยคสุดท้ายอาจจะสำคัญที่สุด):

อย่างที่คุณสามารถจินตนาการได้มีความแตกต่างระหว่างกรณีการใช้งานและสถานการณ์สมมติต่าง ๆ ขั้นแรกกรณีการใช้งานมักจะอ้างถึงนักแสดงทั่วไปเช่นลูกค้าในขณะที่สถานการณ์มักอ้างอิงถึงตัวอย่างของนักแสดงเช่น John Smith และ Sally Jones ไม่มีอะไรจะหยุดคุณจากการเขียนสถานการณ์ทั่วไป แต่โดยปกติแล้วจะเป็นการดีกว่าที่จะปรับแต่งสถานการณ์เพื่อเพิ่มความเข้าใจ ประการที่สองสถานการณ์จำลองการใช้งานอธิบายถึงเส้นทางของตรรกะเดียวในขณะที่กรณีการใช้งานมักจะอธิบายหลายเส้นทาง (หลักสูตรขั้นพื้นฐานรวมทั้งเส้นทางอื่นที่เหมาะสม) ประการที่สามในกระบวนการที่ใช้ UP จะใช้กรณีและปัญหาเป็นเอกสารประกอบอย่างเป็นทางการในขณะที่สถานการณ์จะถูกยกเลิกหลังจากที่พวกเขาไม่ต้องการอีกต่อไป

ฉันอาจจะผิด แต่ฉากการใช้งานดูเหมือนจะใช้ Case flow แต่เปลี่ยนโฉมใหม่ด้วยการสัมผัสแบบ Agile

ไม่มีคำจำกัดความที่แน่นอนของสิ่งนี้ ทุกอย่างแตกต่างกันเล็กน้อย (หรือมาก) จาก บริษัท ไปยัง บริษัท และจากระบบไปยังระบบ

ทางออกที่ดีที่สุดของคุณคือการหาตัวอย่างที่มีอยู่แล้วสำหรับโครงการปัจจุบันของคุณและทำตาม

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

อย่าวางสายในชื่อ

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

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

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

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

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

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

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

1. ฉันเป็นลูกค้าและฉันต้องการชำระยอดเงินในบัญชีของฉันทางออนไลน์ - เป็นมุมมองระดับสูง
2. ฉันเป็นลูกค้าและฉันต้องการอัปเดตปีที่หมดอายุในข้อมูลเครดิตที่เก็บไว้ของฉัน - มุมมองที่สวยงาม

ในระดับสูงสุดของสิ่งที่เป็นนามธรรมกรณีการใช้งานฟังดูคล้ายกันมาก - ปีหมดอายุของการอัปเดตบัตรลูกค้า - แต่นี่เป็นคำสั่งของฟังก์ชั่นแทนที่จะเป็นเป้าหมาย

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

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

ใช้ Case Scenarios อธิบายทีละขั้นตอนทั้งในข้อความหรือผังกระบวนการ (ไม่จำเป็นต้อง UML หรือ BPM - ฉันใช้แผนภาพการไหลข้ามการทำงานมาตรฐานเพื่อความชัดเจนและความสะดวกในการใช้งานโดยผู้บริโภคที่ไม่ได้รับการฝึกฝนในกรณีการใช้งาน

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

สำหรับการสนทนาเชิงลึกในหัวข้อนี้ฉันขอแนะนำให้อ่านhttp://c2.com/cgi/wiki?UserStoryAndUseCaseComparisonบนเว็บไซต์ของ Alistair Cockburn เนื่องจากเขาเป็นผู้ลงนามใน Manifesto ผู้ประกาศเกียรติคุณเรื่องราวของผู้ใช้และได้รับการพิจารณาให้เป็นผู้เชี่ยวชาญเรื่อง Case Use มาสองสามทศวรรษที่แล้วฉันคิดว่าเขาเป็นแหล่งข้อมูลที่ยอดเยี่ยมสำหรับข้อมูลเพิ่มเติม

_{หมายเหตุชั่วคราวด่วน : โพสต์นี้ต้องการการปรับปรุงเพื่อตอบคำถามได้ดีขึ้นเช่น 1) รายละเอียดเพิ่มเติมควรรวมอยู่ในการอ้างอิง 2) การอ้างอิงบางอย่างอาจ 3) ความถูกต้องโดยรวมของภาษาอังกฤษ 4) คุณภาพโดยรวมของการบรรยาย 5) เป็นต้น กลับไปที่มัน อย่าลังเลที่จะปรับปรุงด้วยตัวคุณเอง}

การดูเทมเพลตสามารถให้ข้อมูลเชิงลึกเกี่ยวกับความแตกต่างระหว่างข้อกำหนดเหล่านี้

ใช้กรณี

มีแม่แบบหลายแบบสำหรับกรณีการใช้งาน ผมพบว่า 3 หลังจากการค้นหาอย่างรวดเร็ว: 1 , 2 , 3 บางจุดที่พวกเขา (บางครั้งราง) มีเหมือนกันคือ:

1. ชื่อของกรณีการใช้งาน / ชื่อเรื่อง
2. คำอธิบาย - ข้อความสั้น ๆ ที่อธิบายถึงขอบเขต
3. นักแสดง / นักแสดงหลัก - คนที่มีปฏิสัมพันธ์กับกรณีการใช้งานเฉพาะนี้
4. Precondition - ทุกสิ่งที่กรณีการใช้งานนี้สามารถถือว่าเป็นจริงก่อนที่จะเริ่มเป็นวงจรชีวิต
5. สถานการณ์สมมติความสำเร็จ - ลำดับขั้นตอนที่อธิบายลำดับเหตุการณ์ที่เกิดขึ้นอย่างถูกต้อง

6. ส่วนขยาย - โฟลว์ของแอปพลิเคชันเมื่อมันเบี่ยงเบนจากโฟลว์สถานการณ์ความสำเร็จ:

   1. กระแสทางเลือก - ตัวเลือกอื่น ๆ ของการไหลที่ถูกต้อง
   2. ข้อยกเว้นการไหล - การไหลของเหตุการณ์เมื่อสิ่งผิดปกติ

7. รับประกันความสำเร็จ (เงื่อนไขการโพสต์) - สถานะของการใช้งานหลังจากทุกอย่างเสร็จสิ้น

บางจุดเพิ่มเติมที่สามารถรวมเป็นระดับ , การค้ำประกัน Minimal , ทริกเกอร์ฯลฯ

ข้างต้นเป็นสิ่งที่เรียกว่ากรณีที่ใช้สวมใส่ได้อย่างเต็มที่ คุณสามารถทำให้การสร้างเคสใช้ง่ายขึ้นโดยใช้เคสการใช้งานทั่วไปโดยใช้เฉพาะจุดที่สำคัญที่สุดตัวอย่างเช่น:

1. หัวข้อ
2. นักแสดง (s)
3. ลำดับเหตุการณ์

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

เรื่องราวของผู้ใช้ _{(ฟีเจอร์ aka)}

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

ในฐานะที่เป็น ประเภทเฉพาะของผู้ใช้
ที่ฉันต้องการ ที่จะทำบางสิ่งบางอย่าง
เพื่อให้ ด้วยเหตุผลบางอย่าง

นอกจากนี้เรื่องราวของผู้ใช้สามารถมีเกณฑ์การยอมรับได้

อย่างที่คุณเห็นเทมเพลตนี้มีขนาดเล็กกว่าเคสที่ใช้งานมาก เรื่องราวของผู้ใช้มักเกี่ยวข้องกับภูมิภาค scrum / agile / xp ของการพัฒนาซอฟต์แวร์ พวกเขาตั้งใจจะเขียนบนพื้นผิวเล็ก ๆ เช่นโพสต์ - มันโน้ตและ / หรือบนกระดานต่อสู้ ที่นั่นพวกเขามี (ปกติ) ได้รับค่าจุดซึ่งประมาณว่าความต้องการใช้ความพยายามมากที่จะลงทุนในเรื่องการใช้โทษ

Bill Wake พัฒนาโปรแกรมช่วยจำ INVESTเพื่ออธิบายคุณสมบัติที่ผู้ใช้ควรมีและฉันจะยืมบทสรุปสั้น ๆ ของ Martin Fowler จากเว็บไซต์ของเขา :

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

สถานการณ์การใช้งาน

สถานการณ์การใช้งานเป็นไปตามรูปแบบ GWT ซึ่งย่อมาจาก Given-When-Then เช่น:

สถานการณ์สมมติ : ชื่อที่
ให้ไว้ : ข้อเท็จจริงเฉพาะ
และ : อีกข้อเท็จจริงเฉพาะ (อาจเป็นตัวเลือก)
เมื่อ : เหตุการณ์บางอย่างเกิดขึ้น
แล้ว : เหตุการณ์อื่น ๆ เกิดขึ้น

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

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

สถานการณ์การใช้งานสามารถใช้สำหรับการเขียนการทดสอบสำหรับแอปพลิเคชันของคุณ หากต้องการอ้างอิงย่อหน้าสุดท้ายของโพสต์ของ Martin:

แม้ว่าสไตล์ที่ได้รับเมื่อ - จากนั้นเป็นอาการของ BDD แต่แนวคิดพื้นฐานนั้นค่อนข้างธรรมดาเมื่อเขียนการทดสอบหรือสเปคตามตัวอย่าง Meszaros อธิบายรูปแบบการทดสอบสี่เฟส สี่ขั้นตอนของเขาคือการตั้งค่า (ให้ไว้), การออกกำลังกาย (เมื่อ), ตรวจสอบ (แล้ว) และ Teardown Bill Wake เกิดขึ้นพร้อมกับการกำหนดเป็น Arrange, Act, Assert

การอ้างอิงสำหรับการศึกษาต่อไป:

หน้าวิกิพีเดียสำหรับกรณีการใช้งาน , เรื่องของผู้ใช้ , สถานการณ์การใช้งาน
บล็อกฟาวเลอร์มาร์ตินในกรณีการใช้งาน , เรื่องของผู้ใช้ , สถานการณ์การใช้งาน

ฉันไม่คุ้นเคยกับเรื่องราวของผู้ใช้ แต่เมื่อฉันดูเรื่องนี้เมื่อหลายปีก่อน:

Use Case เป็นภารกิจที่สำคัญ
สถานการณ์จำลองผู้ใช้เป็นวิธีการต่างๆที่สามารถเล่นได้ ดังนั้นทุกกรณีการใช้งานมีหนึ่งสถานการณ์ขึ้นไป กรณีการใช้งานเป็นนามธรรมผู้ใช้สถานการณ์เป็นแคตตาล็อกของอินสแตนซ์ที่เป็นไปได้ทั้งหมดของงานที่เป็นนามธรรม

ดังนั้น:
ใช้กรณี A: ผู้ใช้รับรองความถูกต้องด้วยรหัสและรหัสผ่าน

สถานการณ์จำลอง:
1. รู้จัก ID, รหัสผ่านถูกต้อง (สถานการณ์สมมติ "วันแดด")
2. รู้จัก ID รหัสผ่านไม่ถูกต้อง
3. รู้จักรหัสผ่านรหัสผ่านไม่ถูกต้องเป็นครั้งที่สาม
4. ไม่รู้จัก ID

ฉันคิดเสมอว่ากรณีการใช้งานเป็นวิธีการกำหนดข้อกำหนดในลักษณะการเล่าเรื่องสำหรับลูกค้าในแง่ของพวกเขา w / r / t ข้างต้นถ้าลูกค้าบอกว่า "แต่ถ้าพวกเขาพยายามเข้าสู่ระบบระหว่างเที่ยงคืนและอีกครั้งเมื่อระบบล่ม?" เราได้ค้นพบอีกสถานการณ์หนึ่งสำหรับงานรับรองความถูกต้องและข้อกำหนดเพิ่มเติมบางอย่าง

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

กรณีใช้งานจากมุมมองของผู้พัฒนา มันถูกต้องและครบถ้วน ควรตอบสนองความต้องการทั้งหมดจากลูกค้า

"ใช้กรณี" และ "เรื่องราวของผู้ใช้" เหมือนกันในแง่ที่ว่าพวกเขาเป็นตัวแทน "ข้อกำหนด" ของลูกค้า

Use case เป็นวิธีที่ระบบใช้ในแต่ละกรณีซึ่งโดยปกติจะแสดงเป็นปฏิสัมพันธ์ระหว่างนักแสดงและระบบหรือระหว่างระบบ

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

จากมุมมองของเครื่องทดสอบ QA พวกเขาไม่ได้ทดสอบ "เรื่องราวของผู้ใช้" แต่ "ใช้เคส" ซึ่งหมายถึงพวกเขากำลังทดสอบฟังก์ชันการทำงานของซอฟต์แวร์

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

... กรณีการใช้งานยังมีคำสั่งเกี่ยวกับสิ่งที่ระบบจะทำในขณะที่สถานการณ์การใช้งานจะหลีกเลี่ยงการสนทนานี้

คุณยังไม่ได้กำหนดว่าจะนำไปใช้อย่างไร

จากผลิตภัณฑ์ศิลปะเว็บไซต์