تحليل المتطلبات وتصميم البرمجيات

المكاسب:

• القدرة على تحويل طلبات العمل الغامضة إلى متطلبات برمجية واضحة وقابلة للاختبار وقصص مستخدمين بدعم من الذكاء الاصطناعي
• القدرة على مقارنة إيجابيات وسلبيات تصميم النظام ونموذج البيانات والقرارات المعمارية بطريقة منظمة مع الذكاء الاصطناعي
• القدرة على التحقق بشكل نقدي من التصميم المقترح للذكاء الاصطناعي مقابل المتطلبات وقابلية التوسع والقيود

غالبية المشاريع البرمجية تفشل ليس بسبب التعليمات البرمجية السيئة، ولكن بسبب المتطلبات التي يساء فهمها. إن طلبًا من جملة واحدة مثل "السماح للمستخدمين بتنزيل التقارير" يترك وراءه عشرات الأسئلة دون إجابة: بأي شكل؟ من هو المسؤول؟ كم عدد السجلات؟ ماذا لو كان بطيئا؟ تحليل المتطلبات (ترجمة طلب العمل إلى احتياجات فنية واضحة وقابلة للاختبار) وتصميم البرمجيات (إنشاء الهيكل على الورق لتلبية هذه الاحتياجات) هي المرحلة التي يتم فيها منع الأخطاء الأكثر تكلفة قبل كتابة التعليمات البرمجية. في هذه الوحدة، سوف نتعلم استخدام الذكاء الاصطناعي باعتباره "شريكًا فكريًا" في هذه المرحلة: شريك يزيل الغموض عن عدم اليقين، ويصنف الخيارات، لكنه يترك القرار النهائي لك.

ينتج الذكاء الاصطناعي قيمتين كبيرتين هنا. أولاً، يطرح عليك الأسئلة التي تخطيتها؛ إنه يجلب إلى السطح الافتراضات المخفية وحالات الحافة في الطلب. ثانيًا، يقوم بسرعة بتجميع إيجابيات وسلبيات قرار التصميم. ولكن هذا هو الخطر: سيقدم الذكاء الاصطناعي توصيات عامة باعتبارها "أفضل الممارسات" دون معرفة السياق الخاص بك بشكل كامل (الميزانية، الفريق، النظام الحالي، القيد القانوني). إنها وظيفتك أن تقوم بتصفية هذه النصيحة مقارنة بالحقيقة الخاصة بك.

المفاهيم: قصة المستخدم: جملة قصيرة تعبر عن الحاجة على شكل "... كما، أريد أن أكون قادرًا على... لأن...". معايير القبول: الشروط القابلة للاختبار والتي يجب استيفاؤها حتى يتم اعتبار الوظيفة "منجزة". المتطلبات غير الوظيفية: المتطلبات المتعلقة بـ "كيفية التصرف" بدلاً من "ما ستفعله"، مثل السرعة والأمان وقابلية التوسع.

من الطلب الغامض إلى المتطلبات القابلة للاختبار

المتطلب الجيد قابل للقياس والتحقق منه. ليس "دع النظام يكون سريعًا"، ولكن "دع نتائج البحث تعود خلال 500 مللي ثانية". فيما يلي طريقة خطوة بخطوة لاستخدام الذكاء الاصطناعي لتضييق نطاق عدم اليقين:

1. قم بتقديم الطلب كما هو وقم بإنشاء السؤال. اسأل الذكاء الاصطناعي ليس عن الحل، ولكن أولاً "إدراج أي شيء غير واضح في هذا الطلب كسؤال".
2. أنت تعطي الإجابات. أنت فقط تعرف السياق؛ أجب عن أسئلة الذكاء الاصطناعي مع قيود عملك الحقيقية.
3. قم بترجمتها إلى قصص المستخدمين ومعايير القبول. ترجمة الحاجة الموضحة إلى عناصر قابلة للاختبار.
4. أضف حالات الحافة والسيناريوهات السلبية. "نتيجة فارغة"، "مستخدم غير مصرح به"، "ملف كبير جدًا" وما إلى ذلك.

مطالبة استخراج الغموض: "سنقوم بترجمة طلب العمل التالي إلى متطلبات برمجية. لا تقترح حلاً بعد. أولاً، استخرج جميع الغموض والافتراضات المخفية التي لم تتم الإجابة عليها في هذا الطلب كقائمة من الأسئلة. قم بتجميع الأسئلة تحت العناوين التالية: النطاق، المستخدم/السلطة، حجم البيانات، الأداء، ظروف الخطأ، الأمان. الطلب: "السماح للمستخدمين بتنزيل سجل الطلبات كتقرير.""

قصة المستخدم + مطالبة معايير القبول: "قسّم الحاجة الموضحة التالية إلى قصص مستخدمين تتوافق مع مبادئ INVEST. اكتب 3-5 معايير قبول قابلة للاختبار لكل قصة (بتنسيق معين-متى-ثم). أضف سيناريوهين سلبيين على الأقل (وصول غير مصرح به، بيانات فارغة). الحاجة: [اكتب الحاجة الموضحة هنا]"

مقارنة قرارات التصميم مع الذكاء الاصطناعي

التصميم عبارة عن مقايضة مستمرة: السرعة مقابل المرونة، والبساطة مقابل قابلية التوسع؟ يضع الذكاء الاصطناعي هذه المقايضات في جدول بيانات سريع. على سبيل المثال، بالنسبة لميزة "إرسال إشعار"، يمكنك مناقشة ما إذا كان سيتم استخدام أسلوب متزامن (إرسال عند الطلب) أو غير متزامن (قائمة الانتظار، الإرسال في الخلفية).

مطالبة مقارنة التصميم: "أقوم بتصميم ميزة 'إرسال إشعار بالبريد الإلكتروني إلى المستخدم'. قارن بين الطريقتين: (أ) التسليم المتزامن أثناء طلب HTTP، (ب) التسليم غير المتزامن في الخلفية عن طريق وضعه في قائمة انتظار الرسائل. أنشئ جدولاً بالمحاور التالية: وقت انتظار المستخدم، والتسامح مع الخطأ، والتعقيد، وتكلفة البنية التحتية، وصعوبة تصحيح الأخطاء. لخص في جملتين أي واحدة سأختارها في النهاية، وفي هذه الحالة. لا تتخذ القرار نيابةً عني."

المحور

انتقال متزامن

غير متزامن (قائمة الانتظار)

وقت انتظار المستخدم

طويل (في انتظار الشحن)

قصير (يعود على الفور)

التسامح مع الخطأ

منخفض (ينفجر الطلب إذا انفجر الإرسال)

عالي (ممكن إعادة المحاولة)

التعقيد

منخفض

متوسطة إلى عالية (البنية التحتية لقائمة الانتظار)

تكلفة البنية التحتية

منخفض

المكونات الإضافية المطلوبة

حيث يناسب

حجم منخفض، تطبيق بسيط

حجم كبير، والتسليم الحرجة

نصيحة: إن إخبار الذكاء الاصطناعي "لا تتخذ القرار نيابةً عني، فقط أرني الخيارات والشروط" يجبرك على التفكير ويقلل من خطر القبول الأعمى للاقتراح. أفضل قرار تصميمي هو القرار الذي يتخذه الشخص الذي يعرف سياقك (أنت).

موجه ضعيف / موجه قوي

ضعيف: "تصميم قاعدة بيانات لنظام الطلبات." (النتيجة: ما هو النطاق، وما هي العلاقات، وما هي القيود غير الواضحة؛ مخطط عام وغير واقعي.) قوي: "اقترح نموذج بيانات مسودة للتجارة الإلكترونية الصغيرة. الكيانات: العميل، الطلب، المنتج، عنصر الطلب. القيود: يمكن أن يكون هناك العديد من المنتجات في الطلب؛ قد يتغير سعر المنتج بمرور الوقت، ولكن يجب الحفاظ على السعر الحالي في الطلب السابق؛ من المتوقع أن يصل عدد الطلبات إلى 500 طلب يوميًا. العلاقات وسبب ذلك "اشرح أنك اتخذت القرار. حدد كيفية حل مشكلة سجل الأسعار. أعطها كقائمة بالكيانات والحقول، وليس رمزًا."

الفرق موجه قوي؛ الحجم (500 طلب يوميًا)، وقاعدة العمل (يجب الحفاظ على السعر السابق) وتنسيق الإخراج المطلوب. جملة واحدة مثل "يجب الحفاظ على السعر السابق" تغير التصميم تمامًا؛ إذا لم تحدد ذلك، فسوف ينتج الذكاء الاصطناعي رسمًا تخطيطيًا غير دقيق ولكنه معقول المظهر.

حالات صغيرة

الحالة 1 - الافتراض الخفي. يقوم الفريق مباشرة بترميز طلب "يمكن للمستخدم تحميل صورة الملف الشخصي". سأل فريق آخر الذكاء الاصطناعي عن عدم اليقين: "الحجم الأقصى؟ التنسيقات المسموح بها؟ التحكم غير المناسب في المحتوى؟ حذف الصورة القديمة؟" وتنتج 8 أسئلة مثل. يتعرف الفريق الأول على مشكلة الإنتاج عندما تملأ ملفات بحجم 20 ميجابايت الخادم؛ الفريق الثاني يحلها في التصميم.

الحالة 2 - افتراض المقياس غير الصحيح. يقترح الذكاء الاصطناعي طبقة تخزين مؤقت معقدة لميزة إعداد التقارير. وعندما يشير المهندس إلى أن البيانات الحقيقية هي 30 تقريرًا فقط يوميًا، فإن الذكاء الاصطناعي يبسط الاقتراح. إن عدم تحديد المقياس يؤدي إلى تكلفة التعقيد غير الضروري؛ التحديد يوفر أسبوعين من العمل غير الضروري.

الحالة 3 - فجوة معايير القبول. "ماذا يحدث إذا فشل الدفع؟" نظرًا لعدم طرح السؤال مطلقًا، سيظل نظام الطلب يضع علامة على الطلب على أنه "مؤكد" في حالة عدم نجاح الدفع. قائمة السيناريوهات السلبية الناتجة عن الذكاء الاصطناعي تلتقط هذه الفجوة؛ معايير قبول السطر الواحد تمنع خسارة الأموال الحقيقية.

الأخطاء الشائعة

• تمرير الطلب مباشرة إلى الكود. الكود المكتوب قبل حل الغموض يحل المشكلة الخاطئة بسرعة.
• الأخذ بشكل أعمى بـ "أفضل الممارسات" العامة للذكاء الاصطناعي. إذا لم تحدد السياق الخاص بك (النطاق، الميزانية، الفريق) فلن تناسبك التوصية.
• تخطي المتطلبات غير الوظيفية. إذا لم يتم تحديد السرعة والأمان والحجم، فسيكون التصميم غير مكتمل.
• مجرد التفكير في السيناريو السعيد. يجب تضمين السيناريوهات السلبية مثل البيانات الفارغة والمستخدم غير المصرح به وحالة الخطأ في التصميم.
• تفويض القرار إلى منظمة العفو الدولية. الذكاء الاصطناعي يولد الخيارات؛ عليك أن تقرر أي مقايضة تناسب عملك.

في ملخص

تحليل المتطلبات وتصميمها هي المرحلة التي يتم فيها اكتشاف الأخطاء الأقل تكلفة. هنا، يقوم الذكاء الاصطناعي بإنشاء أسئلة تكشف عن عدم اليقين، ويصوغ قصص المستخدمين ومعايير القبول، ويجري مقايضات في تصميم الرسوم البيانية. لكنك وحدك تعرف السياق؛ إن مهمتك هي تصفية توصيات الذكاء الاصطناعي بناءً على نطاقك وميزانيتك وفريقك والقيود القانونية واتخاذ القرار النهائي. إن الانضباط "لا تتخذ القرار نيابةً عني، أرني الخيارات" يؤدي إلى تصميم أفضل وتعلم أعمق.

مهمة التطبيق

اختر طلب وظيفة من جملة واحدة من السياق الخاص بك. أولاً، قم بتطبيق موجه الغموض على الذكاء الاصطناعي وأجب عن الأسئلة بقيودك الحقيقية. ثم قم بترجمة الحاجة الموضحة إلى قصتين مستخدمتين على الأقل و3 معايير قبول لكل منهما؛ قم بتضمين سيناريو سلبي واحد على الأقل. أخيرًا، قم بإنشاء جدول مقارنة لقرار التصميم (متزامن/غير متزامن، بنية الجدول، وما إلى ذلك) واكتب قرارك الخاص في جملتين.

قائمة مرجعية

• [ ] قمت بإزالة الغموض كأسئلة قبل تمرير الطلب إلى الكود.
• [ ] أعطيت السياق (النطاق، السلطة، الأداء، القيد القانوني) للذكاء الاصطناعي.
• [ ] لقد قمت بتقسيم قصص المستخدم إلى معايير قبول قابلة للاختبار.
• [ ] لقد قمت بإضافة سيناريو واحد على الأقل للجانب السلبي/الحافة.
• [ ] قمت بتقييم قرار التصميم باستخدام جدول المقايضة.
• [ ] لقد اتخذت القرار النهائي بناءً على السياق الخاص بي، ولم أترك الأمر للذكاء الاصطناعي.