การวิเคราะห์ความต้องการและการออกแบบซอฟต์แวร์

กำไร:

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

โครงการซอฟต์แวร์ส่วนใหญ่ล้มเหลวไม่ใช่เพราะโค้ดไม่ดี แต่เป็นเพราะข้อกำหนดที่เข้าใจผิด คำขอเพียงประโยคเดียว เช่น “อนุญาตให้ผู้ใช้ดาวน์โหลดรายงาน” ทิ้งคำถามที่ยังไม่ได้ตอบไว้มากมาย: ในรูปแบบใด ใครเป็นผู้รับผิดชอบ? มีกี่บันทึก? เกิดอะไรขึ้นถ้ามันช้า? การวิเคราะห์ความต้องการ (การแปลคำขอทางธุรกิจให้เป็นความต้องการทางเทคนิคที่ชัดเจนและทดสอบได้) และการออกแบบซอฟต์แวร์ (การสร้างโครงสร้างบนกระดาษเพื่อตอบสนองความต้องการเหล่านี้) เป็นขั้นตอนที่ป้องกันข้อผิดพลาดที่แพงที่สุดก่อนที่จะเขียนโค้ด ในหน่วยนี้ เราจะเรียนรู้การใช้ AI เป็น "คู่คิด" ในขั้นตอนนี้: คู่หูที่ไขปริศนาความไม่แน่นอน แยกแยะทางเลือกต่างๆ แต่ปล่อยให้การตัดสินใจขั้นสุดท้ายขึ้นอยู่กับคุณ

AI สร้างค่านิยมใหญ่สองค่าที่นี่ ขั้นแรก จะถามคำถามที่คุณข้ามไป มันเผยให้เห็นถึงสมมติฐานที่ซ่อนอยู่และกรณีขอบในคำขอ ประการที่สอง จะจัดทำตารางข้อดีและข้อเสียของการตัดสินใจออกแบบอย่างรวดเร็ว แต่นั่นคืออันตราย: AI จะให้คำแนะนำทั่วไปว่าเป็น "แนวปฏิบัติที่ดีที่สุด" โดยไม่ทราบบริบทของคุณอย่างถ่องแท้ (งบประมาณ ทีม ระบบที่มีอยู่ ข้อจำกัดทางกฎหมาย) เป็นหน้าที่ของคุณที่จะต้องกรองคำแนะนำนี้เทียบกับความจริงของคุณเอง

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

จากคำขอที่คลุมเครือไปจนถึงข้อกำหนดที่ทดสอบได้

ข้อกำหนดที่ดีสามารถวัดผลและตรวจสอบได้ ไม่ใช่ "ให้ระบบรวดเร็ว" แต่เป็น "ให้ผลการค้นหากลับมาภายใน 500 ms" ต่อไปนี้เป็นวิธีใช้ AI เพื่อลดความไม่แน่นอนทีละขั้นตอน:

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

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

ข้อความแจ้งเรื่องราวของผู้ใช้ + เกณฑ์การยอมรับ: "แบ่งความต้องการที่ชัดเจนต่อไปนี้ออกเป็นเรื่องราวของผู้ใช้ที่สอดคล้องกับหลักการลงทุน เขียนเกณฑ์การยอมรับที่ทดสอบได้ 3-5 ข้อสำหรับแต่ละเรื่องราว (ในรูปแบบที่ให้ไว้เมื่อไรแล้ว) เพิ่มสถานการณ์เชิงลบอย่างน้อย 2 สถานการณ์ (การเข้าถึงโดยไม่ได้รับอนุญาต ข้อมูลว่างเปล่า) ต้องการ: [เขียนความต้องการชี้แจงที่นี่]"

การเปรียบเทียบการตัดสินใจออกแบบกับ AI

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

พรอมต์การเปรียบเทียบการออกแบบ: "ฉันกำลังออกแบบคุณลักษณะ 'ส่งอีเมลแจ้งเตือนไปยังผู้ใช้' เปรียบเทียบสองวิธี: (A) การจัดส่งแบบซิงโครนัสระหว่างคำขอ HTTP (B) การจัดส่งแบบอะซิงโครนัสในพื้นหลังโดยวางไว้ในคิวข้อความ สร้างตารางตามแกนต่อไปนี้: เวลารอของผู้ใช้, ความทนทานต่อข้อผิดพลาด, ความซับซ้อน, ต้นทุนโครงสร้างพื้นฐาน, ความยากในการดีบัก สรุปใน 2 ประโยคที่ฉันจะเลือกอันสุดท้ายในกรณีใด อย่าตัดสินใจแทนฉัน"

แกน

การส่งข้อมูลแบบซิงโครนัส

อะซิงโครนัส (คิว)

ระยะเวลารอคอยของผู้ใช้

ยาว(รอจัดส่ง)

สั้น (คืนทันที)

ความอดทนต่อความผิดพลาด

ต่ำ (คำขอจะระเบิดหากการส่งระเบิด)

สูง (ลองอีกครั้งได้)

ความซับซ้อน

ต่ำ

ปานกลาง-สูง (โครงสร้างพื้นฐานของคิว)

ต้นทุนโครงสร้างพื้นฐาน

ต่ำ

จำเป็นต้องมีส่วนประกอบเพิ่มเติม

มันเข้ากันตรงไหน.

ปริมาณน้อย แอปพลิเคชั่นที่เรียบง่าย

ปริมาณมาก การส่งมอบที่สำคัญ

เคล็ดลับ: การบอก AI “อย่าตัดสินใจแทนฉัน แค่แสดงตัวเลือกและเงื่อนไขให้ฉันดู” จะบังคับให้คุณคิดและลดความเสี่ยงในการยอมรับข้อเสนอแนะโดยไม่ตั้งใจ การตัดสินใจออกแบบที่ดีที่สุดคือการตัดสินใจโดยบุคคลที่รู้บริบทของคุณ (คุณ)

พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง

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

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

เคสมินิ

กรณีที่ 1 — สมมติฐานที่ซ่อนอยู่ ทีมงานเขียนโค้ดคำขอ "ผู้ใช้สามารถอัปโหลดรูปโปรไฟล์" ได้โดยตรง อีกทีมถาม AI เกี่ยวกับความไม่แน่นอน: "ขนาดสูงสุด รูปแบบที่อนุญาต การควบคุมเนื้อหาไม่เหมาะสม ลบภาพเก่า" มันสร้างคำถาม 8 ข้อเช่น ทีมแรกได้เรียนรู้ถึงปัญหาในการใช้งานจริงเมื่อไฟล์ขนาด 20 MB เต็มเซิร์ฟเวอร์ ทีมที่สองแก้ไขในการออกแบบ

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

กรณีที่ 3 — ช่องว่างเกณฑ์การยอมรับ “จะเกิดอะไรขึ้นหากการชำระเงินล้มเหลว” เนื่องจากไม่เคยถามคำถามเลย ระบบคำสั่งซื้อจะยังคงทำเครื่องหมายคำสั่งซื้อว่า "ยืนยันแล้ว" ในกรณีที่ชำระเงินไม่สำเร็จ รายการสถานการณ์เชิงลบที่สร้างโดย AI รวบรวมช่องว่างนี้ เกณฑ์การยอมรับ 1 บรรทัดป้องกันการสูญเสียเงินจริง

ข้อผิดพลาดทั่วไป

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

โดยสรุป

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

งานสมัคร

เลือกคำของานที่มีประโยคเดียวจากบริบทของคุณ ขั้นแรก ใช้ข้อความแจ้งความคลุมเครือกับ AI และตอบคำถามด้วยข้อจำกัดที่แท้จริงของคุณ จากนั้นแปลความต้องการที่ชัดเจนเป็นเรื่องราวของผู้ใช้อย่างน้อย 2 เรื่องและเกณฑ์การยอมรับ 3 รายการสำหรับแต่ละเรื่อง รวมสถานการณ์เชิงลบอย่างน้อย 1 รายการ สุดท้าย สร้างตารางเปรียบเทียบสำหรับการตัดสินใจในการออกแบบ (ซิงโครนัส/อะซิงโครนัส โครงสร้างตาราง ฯลฯ) และเขียนการตัดสินใจของคุณเองใน 2 ประโยค

รายการตรวจสอบ

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