หนังสือเล่มนี้อธิบายวิธีการหนึ่งสำหรับการเขียนส่วนหนึ่งของคำชี้แจงปัญหา นั่นคือวิธีกรณีการใช้งาน
มันคืออะไร? นี่คือคำอธิบายสถานการณ์จำลองการโต้ตอบของผู้ใช้กับระบบ (หรือกับธุรกิจ) ในกรณีนี้ ระบบจะทำหน้าที่เป็นกล่องดำ (และทำให้สามารถแบ่งงานออกแบบที่ซับซ้อนออกเป็นการออกแบบการโต้ตอบและรับรองการโต้ตอบนี้ได้) ในเวลาเดียวกัน มีการนำมาตรฐานสัญกรณ์มาใช้ ซึ่งช่วยให้อ่านได้ง่าย รวมถึงสำหรับผู้ที่ไม่ได้เข้าร่วม และช่วยให้สามารถตรวจสอบความสมบูรณ์และการปฏิบัติตามเป้าหมายของผู้มีส่วนได้ส่วนเสียได้
ใช้กรณีตัวอย่าง
สถานการณ์จะเป็นอย่างไร โดยใช้ตัวอย่างการอนุญาตบนเว็บไซต์ทางอีเมล:
(ระบบ) เข้าสู่เว็บไซต์เพื่อเข้าถึงบัญชีส่วนตัวของคุณ ~~ (ระดับน้ำทะเล)
บริบท: ลูกค้าที่ไม่ได้รับอนุญาตเข้าสู่ระบบไซต์เพื่อให้ไซต์จดจำเขาและแสดงข้อมูลส่วนบุคคลสำหรับเขา: ประวัติการเรียกดู ประวัติการซื้อ จำนวนคะแนนโบนัสปัจจุบัน ฯลฯ โดยใช้อีเมลเป็นข้อมูลเข้าสู่ระบบ
ระดับ: เป้าหมายผู้ใช้
ตัวละครหลัก: ลูกค้า (ผู้เยี่ยมชมร้านค้าออนไลน์ของเรา)
ขอบเขต: การโต้ตอบของลูกค้ากับเว็บไซต์ร้านค้าออนไลน์
ผู้มีส่วนได้เสียและผลประโยชน์:
- นักการตลาดต้องการให้ระบุจำนวนผู้เยี่ยมชมไซต์สูงสุดเพื่อให้การส่งจดหมายส่วนตัวครอบคลุมมากขึ้น
- ผู้เชี่ยวชาญด้านความปลอดภัยต้องการให้แน่ใจว่าไม่มีกรณีการเข้าถึงข้อมูลส่วนบุคคลของผู้เยี่ยมชมโดยไม่ได้รับอนุญาต รวมถึงการพยายามเดารหัสผ่านสำหรับบัญชีหนึ่งหรือค้นหาบัญชีที่มีรหัสผ่านที่ไม่รัดกุม
- ผู้โจมตีต้องการเข้าถึงโบนัสของเหยื่อ
- คู่แข่งต้องการแสดงความคิดเห็นเชิงลบเกี่ยวกับผลิตภัณฑ์
- บอตเน็ตต้องการรับฐานลูกค้าของร้านค้าและใช้การโจมตีเพื่อทำให้ไซต์ใช้งานไม่ได้
เงื่อนไขเบื้องต้น: ผู้เข้าชมจะต้องไม่ได้รับอนุญาต
การรับประกันขั้นต่ำ: ผู้เยี่ยมชมจะทราบว่าการพยายามอนุญาตสำเร็จหรือไม่สำเร็จ
รับประกันความสำเร็จ: ผู้เยี่ยมชมได้รับอนุญาต
สถานการณ์หลัก:
- ลูกค้าเริ่มต้นการอนุญาต
- ระบบยืนยันว่าลูกค้าไม่ได้รับอนุญาตและไม่เกินจำนวนครั้งในการพยายามอนุญาตที่ไม่สำเร็จจากเซสชันที่กำหนด (ค้นหารหัสผ่านที่อ่อนแอสำหรับหลายบัญชี) ตามกฎความปลอดภัยหมายเลข 23
- ระบบจะเพิ่มตัวนับจำนวนครั้งในการอนุญาต
- ระบบแสดงแบบฟอร์มการอนุญาตให้กับลูกค้า
- ลูกค้ากรอกอีเมลและรหัสผ่านของเขา
- ระบบจะยืนยันการมีอยู่ของลูกค้าด้วยอีเมลดังกล่าวในระบบและรหัสผ่านตรงกันและจำนวนครั้งในการพยายามเข้าสู่ระบบบัญชีนี้จะต้องไม่เกินตามกฎความปลอดภัยหมายเลข 24
- ระบบให้สิทธิ์แก่ลูกค้า เพิ่มประวัติการเรียกดูและตะกร้าของเซสชันนี้พร้อมกับเซสชันสุดท้ายของบัญชีลูกค้านี้
- ระบบจะแสดงข้อความแจ้งความสำเร็จในการอนุญาต และย้ายไปยังขั้นตอนสคริปต์ที่ไคลเอ็นต์ถูกขัดจังหวะในการอนุญาต ในกรณีนี้ ข้อมูลบนเพจจะถูกโหลดซ้ำโดยคำนึงถึงข้อมูลบัญชีส่วนบุคคล
ส่วนขยาย:
2.ก. ลูกค้าได้รับอนุญาตแล้ว:
2.ก.1. ระบบจะแจ้งให้ลูกค้าทราบถึงข้อเท็จจริงของการอนุญาตที่ดำเนินการก่อนหน้านี้และเสนอให้ขัดจังหวะสคริปต์หรือไปที่ขั้นตอนที่ 4 และหากขั้นตอนที่ 6 เสร็จสมบูรณ์ ขั้นตอนที่ 7 จะดำเนินการพร้อมคำอธิบาย:
2.a.7. ระบบจะยกเลิกการใช้งานไคลเอนต์ภายใต้บัญชีเก่า อนุญาตลูกค้าภายใต้บัญชีใหม่ ในขณะที่ประวัติการเรียกดูและตะกร้าสินค้าของเซสชันการโต้ตอบนี้จะยังคงอยู่ในบัญชีเก่าและจะไม่โอนไปยังบัญชีใหม่ จากนั้นไปที่ขั้นตอนที่ 8
2.b จำนวนความพยายามในการอนุญาตเกินเกณฑ์ตาม "กฎความปลอดภัยหมายเลข 23":
2.b.1 ไปยังขั้นตอนที่ 4 แคปต์ชาจะปรากฏเพิ่มเติมในแบบฟอร์มการอนุญาต
2.b.6 ระบบยืนยันรายการ captcha ที่ถูกต้อง
2.b.6.1 Captcha ป้อนไม่ถูกต้อง:
2.b.6.1.1. ระบบจะเพิ่มตัวนับการพยายามอนุญาตที่ไม่สำเร็จสำหรับบัญชีนี้เช่นกัน
2.b.6.1.2. ระบบแสดงข้อความแสดงข้อผิดพลาดและกลับสู่ขั้นตอนที่ 2
6.ก. ไม่พบบัญชีที่ใช้อีเมลนี้:
6.a.1 ระบบแสดงข้อความเกี่ยวกับความล้มเหลวและเสนอทางเลือกว่าจะไปที่ขั้นตอนที่ 2 หรือไปที่สถานการณ์ "การลงทะเบียนผู้ใช้" และบันทึกอีเมลที่ป้อน
6.ข. รหัสผ่านสำหรับบัญชีที่มีอีเมลนี้ไม่ตรงกับรหัสผ่านที่ป้อน:
6.b.1 ระบบจะเพิ่มตัวนับการพยายามเข้าสู่ระบบที่ไม่สำเร็จในบัญชีนี้
6.b.2 ระบบแสดงข้อความเกี่ยวกับความล้มเหลวและเสนอทางเลือกว่าจะไปที่สถานการณ์ "การกู้คืนรหัสผ่าน" หรือไปที่ขั้นตอนที่ 2
6.c: ตัวนับความพยายามในการเข้าสู่ระบบสำหรับบัญชีนี้เกินเกณฑ์สำหรับ “กฎความปลอดภัยหมายเลข 24”
6.c.1 ระบบแสดงข้อความเกี่ยวกับการบล็อกการเข้าสู่ระบบบัญชีเป็นเวลา X นาที และดำเนินการไปยังขั้นตอนที่ 2
มีอะไรที่ยอดเยี่ยม
ตรวจสอบความสมบูรณ์และการปฏิบัติตามเป้าหมาย กล่าวคือ คุณสามารถส่งข้อกำหนดให้กับนักวิเคราะห์รายอื่นเพื่อตรวจสอบได้ ทำให้เกิดข้อผิดพลาดน้อยลงในขั้นตอนการกำหนดปัญหา
การทำงานกับระบบกล่องดำทำให้คุณสามารถแยกการพัฒนาและการประสานงานกับลูกค้าว่าอะไรจะเป็นอัตโนมัติจากวิธีการนำไปใช้งาน
มันเป็นส่วนหนึ่งของเส้นทางของนักวิเคราะห์ซึ่งเป็นหนึ่งในส่วนหลักของการใช้งาน สถานการณ์ของผู้ใช้กำหนดเส้นทางหลักในการเคลื่อนไหวของเขา ซึ่งจะลดอิสระในการเลือกสำหรับนักออกแบบและลูกค้าอย่างมาก และช่วยเพิ่มความเร็วในการพัฒนาการออกแบบ
ฉันพอใจมากกับสถานที่ในคำอธิบายที่ระบุข้อยกเว้นของการโต้ตอบแต่ละขั้นตอนการโต้ตอบ ระบบไอทีที่สมบูรณ์จะต้องมีการจัดการข้อยกเว้นบางประเภท บ้างก็ด้วยตนเอง บ้างโดยอัตโนมัติ (ดังตัวอย่างด้านบน)
ประสบการณ์แสดงให้เห็นว่าการจัดการข้อยกเว้นที่คิดไม่ดีสามารถเปลี่ยนระบบให้เป็นระบบที่ไม่สะดวกอย่างยิ่งได้อย่างง่ายดาย ฉันจำเรื่องราวในสมัยโซเวียตได้ คุณต้องได้รับการอนุมัติหลายครั้งจากบริการต่างๆ เพื่อที่จะตัดสินใจได้ และจะเจ็บปวดเพียงใดเมื่อบริการสุดท้ายแจ้ง - แต่ใบสมัครของคุณใช้ชื่อผิดหรือมีข้อผิดพลาดอื่น ๆ เครื่องหมายวรรคตอน ทำซ้ำทุกอย่าง และประสานงานทุกอย่างใหม่
ฉันมักจะเจอสถานการณ์ที่ตรรกะการทำงานของระบบที่ไม่ได้คำนึงถึงข้อยกเว้นนั้นจำเป็นต้องมีการปรับปรุงระบบใหม่อย่างมีนัยสำคัญ ด้วยเหตุนี้ ส่วนแบ่งงานของนักวิเคราะห์จึงถูกใช้ไปกับการจัดการข้อยกเว้น
สัญลักษณ์ข้อความตรงข้ามกับไดอะแกรม ช่วยให้สามารถระบุและครอบคลุมข้อยกเว้นได้มากขึ้น
นอกเหนือจากวิธีการปฏิบัติแล้ว
กรณีการใช้งานไม่ใช่ส่วนที่จัดลำดับความสำคัญอย่างอิสระของข้อความ ซึ่งแตกต่างจากเรื่องราวของผู้ใช้
ในสถานการณ์ข้างต้น ให้พิจารณาข้อยกเว้น “6.a. ไม่พบบัญชีที่มีอีเมลนี้” และขั้นตอนถัดไป “6.a.1 ระบบแสดงข้อความแจ้งข้อผิดพลาดและดำเนินการขั้นตอนที่ 2” มีเรื่องลบอะไรทิ้งไว้เบื้องหลังบ้าง? สำหรับลูกค้า การส่งคืนใดๆ เท่ากับการที่งานทั้งหมดที่เขาป้อนข้อมูลจะถูกโยนลงหลุมฝังกลบ (แค่ไม่เห็นในสคริปต์!) ทำอะไรได้บ้าง? สร้างสคริปต์ใหม่เพื่อไม่ให้สิ่งนี้เกิดขึ้น เป็นไปได้ไหมที่จะทำเช่นนี้? คุณสามารถดูสคริปต์การให้สิทธิ์ของ Google เป็นตัวอย่างได้
การเพิ่มประสิทธิภาพสถานการณ์
หนังสือเล่มนี้พูดถึงการทำให้เป็นทางการ แต่พูดถึงวิธีการปรับสถานการณ์ดังกล่าวให้เหมาะสมเพียงเล็กน้อย
แต่เป็นไปได้ที่จะเสริมความแข็งแกร่งของวิธีการด้วยการปรับสถานการณ์ให้เหมาะสม และวิธีการปรับใช้กรณีการใช้งานอย่างเป็นทางการก็ช่วยให้สิ่งนี้สำเร็จได้ โดยเฉพาะอย่างยิ่ง คุณต้องคำนึงถึงข้อยกเว้นแต่ละรายการที่เกิดขึ้น ระบุสาเหตุ และสร้างสคริปต์ใหม่เพื่อกำจัดข้อยกเว้นหรือลดการเดินทางของลูกค้าให้เหลือน้อยที่สุด
เมื่อทำการสั่งซื้อจากร้านค้าออนไลน์ คุณต้องระบุเมืองที่จัดส่ง อาจปรากฎว่าร้านค้าไม่สามารถส่งสินค้าไปยังเมืองที่ลูกค้าเลือกได้ เนื่องจากไม่ได้จัดส่งที่นั่น เนื่องจากข้อจำกัดด้านขนาด หรือเนื่องจากการไม่มีสินค้าในคลังสินค้าที่เกี่ยวข้อง
หากเราเพียงอธิบายสถานการณ์ของการโต้ตอบในขั้นตอนการลงทะเบียน เราก็สามารถเขียนว่า "แจ้งให้ลูกค้าทราบว่าการจัดส่งเป็นไปไม่ได้และเสนอให้เปลี่ยนเมืองหรือสิ่งของในรถเข็น" (และนักวิเคราะห์มือใหม่จำนวนมากก็หยุดอยู่แค่นั้น) แต่หากมีกรณีดังกล่าวจำนวนมาก สถานการณ์ก็สามารถปรับให้เหมาะสมได้
สิ่งแรกที่คุณต้องทำคือให้คุณเลือกเฉพาะเมืองที่เราสามารถจัดส่งได้ เมื่อใดจึงจะทำเช่นนี้? ก่อนที่จะเลือกผลิตภัณฑ์บนเว็บไซต์ (การตรวจจับเมืองอัตโนมัติผ่าน IP พร้อมคำชี้แจง)
ประการที่สอง เราต้องให้ทางเลือกเฉพาะสินค้าที่เราสามารถจัดส่งให้กับลูกค้าได้ เมื่อใดจึงจะทำเช่นนี้? ในขณะที่เลือก - บนไทล์ผลิตภัณฑ์และการ์ดผลิตภัณฑ์
การเปลี่ยนแปลงทั้งสองนี้ช่วยขจัดข้อยกเว้นนี้ได้อย่างมาก
ข้อกำหนดสำหรับการวัดและหน่วยเมตริก
เมื่อพิจารณางานในการลดการจัดการข้อยกเว้นให้เหลือน้อยที่สุด คุณสามารถตั้งค่างานการรายงานได้ (ไม่ได้อธิบายกรณีการใช้งาน) มีข้อยกเว้นจำนวนเท่าใด ในกรณีใดที่เกิดขึ้น รวมถึงจำนวนสถานการณ์ขาเข้าที่ผ่านสำเร็จ
แต่อนิจจา ประสบการณ์แสดงให้เห็นว่าข้อกำหนดการรายงานสำหรับสถานการณ์จำลองในแบบฟอร์มนี้ไม่เพียงพอ จำเป็นต้องพิจารณาข้อกำหนดการรายงานสำหรับกระบวนการที่อธิบายไว้โดยส่วนใหญ่ไม่อยู่ในรูปแบบของกรณีการใช้งาน
การเข้าถึงการใช้งาน
ในทางปฏิบัติของเรา เราได้ขยายแบบฟอร์มคำอธิบายกรณีการใช้งานพร้อมคำอธิบายคุณลักษณะเฉพาะของเอนทิตีและข้อมูลเพื่อให้ลูกค้าตัดสินใจ ซึ่งจะช่วยเพิ่มความสามารถในการใช้งานในภายหลัง
สำหรับการออกแบบการใช้งาน เราได้เพิ่มส่วนอินพุต - แสดงข้อมูล
ในสถานการณ์ที่มีการอนุญาต นี่คือความจริงที่ว่าไคลเอนต์ได้รับอนุญาตในระบบ หากไคลเอนต์ได้รับการอนุมัติล่วงหน้า แสดงคำเตือนเกี่ยวกับการเปลี่ยนประวัติการนำทางและรถเข็นไปยังบัญชีใหม่หลังจากการอนุญาตสำเร็จ
โดยทั่วไป นี่คือการแสดงข้อมูลที่จำเป็นสำหรับลูกค้า เพื่อที่เขาจะได้ตัดสินใจเกี่ยวกับการดำเนินการต่อไปของเขาตามสถานการณ์ (คุณสามารถสอบถามได้ว่าข้อมูลนี้เพียงพอสำหรับลูกค้าหรือไม่ มีอะไรอีกที่จำเป็น ข้อมูลอะไรบ้าง ลูกค้าต้องตัดสินใจ)
นอกจากนี้ยังควรแบ่งข้อมูลที่ป้อนลงในช่องป้อนข้อมูลหากประมวลผลแยกกันและมีข้อยกเว้นที่แตกต่างกัน
ในตัวอย่างที่มีการอนุญาตไคลเอ็นต์หากคุณแยกข้อมูลที่ป้อนออกเป็นข้อมูลเข้าสู่ระบบและรหัสผ่านก็คุ้มค่าที่จะเปลี่ยนสคริปต์การอนุญาตเพื่อเน้นขั้นตอนการเข้าสู่ระบบแยกต่างหากและรหัสผ่านแยกต่างหาก (ซึ่งทำได้ใน Yandex, Google แต่ ไม่ได้ทำในร้านค้าออนไลน์ส่วนใหญ่)
บรรลุการเปลี่ยนแปลงข้อมูลที่จำเป็น
คุณยังสามารถแยกข้อกำหนดสำหรับอัลกอริธึมการแปลงข้อมูลจากสคริปต์ได้อีกด้วย
Примеры:
- ในการตัดสินใจซื้อผลิตภัณฑ์ในร้านค้าออนไลน์ ลูกค้าจำเป็นต้องทราบความเป็นไปได้ ต้นทุน เวลาจัดส่งไปยังเมืองของผลิตภัณฑ์นี้ในบัตรผลิตภัณฑ์ (ซึ่งคำนวณโดยอัลกอริทึมตามความพร้อมของผลิตภัณฑ์ใน คลังสินค้าและพารามิเตอร์ห่วงโซ่อุปทาน)
- เมื่อป้อนวลีลงในบรรทัดค้นหา ลูกค้าจะเห็นคำแนะนำการค้นหาตามอัลกอริทึม (ซึ่งสร้างโดยอัลกอริทึม...)
เบ็ดเสร็จ
โดยทั่วไป หลังจากอ่านหนังสือแล้ว น่าเสียดายที่ยังไม่ชัดเจนว่าจะต้องทำอย่างไรตั้งแต่นักวิเคราะห์ไปจนถึงปัญหาทางธุรกิจไปจนถึงข้อกำหนดทางเทคนิคที่เป็นทางการสำหรับนักพัฒนา หนังสือเล่มนี้บอกเพียงส่วนหนึ่งของกระบวนการ โดยขั้นตอนการป้อนข้อมูลไม่ชัดเจน และขั้นตอนถัดไปไม่ชัดเจน กรณีการใช้งานนั้นมักจะไม่ใช่คำชี้แจงที่สมบูรณ์สำหรับนักพัฒนา
อย่างไรก็ตาม นี่เป็นวิธีที่ดีมากในการจัดรูปแบบและประมวลผลสถานการณ์ของการโต้ตอบระหว่างวัตถุและหัวเรื่อง เมื่อการโต้ตอบทำให้เกิดการเปลี่ยนแปลงในบางสิ่งในหัวเรื่อง เป็นหนึ่งในวิธีการเขียนไม่กี่วิธีที่อนุญาตให้มีข้อกำหนดที่ตรวจสอบได้พร้อมจุดค้นหาข้อยกเว้นที่ชัดเจน
หนังสือเล่มนี้เป็นสิ่งที่นักวิเคราะห์ต้องอ่านเพื่อเริ่มเขียนบทละครที่สามารถทดสอบได้
ที่มา: will.com