ניתוח דרישות וניתוח צרכי בעלי עניין

רווחים:

• יכולת להבחין בין דרישות פונקציונליות ולא פונקציונליות ולכתוב ביטויי דרישות ברורים ניתנים למדידה בתמיכה של בינה מלאכותית
• יכולת להשתמש בבינה מלאכותית עם הנחיות מובנות כדי לחלץ את סיפור המשתמש, קריטריוני הקבלה ומגבלת ההיקף מהערות הראיונות
• להרגל לבדוק דרישות שנוצרו על ידי בינה מלאכותית לגבי אי בהירות, סתירות וחוקים חסרים ולאשר אותן עם בעלי עניין

ניתוח דרישות הוא המשימה להגדיר בצורה מלאה, ברורה וניתנת לאימות מה מערכת צריכה לעשות. זהו אחד השלבים שבהם מומחה MIS מייצר את הערך הרב ביותר; כי טעות כאן גדלה באופן אקספוננציאלי בסוף הפרויקט. ישנם שני סוגים בסיסיים של ניתוח דרישות. הדרישה התפקודית מתארת ​​את העבודה שהמערכת צריכה לעשות: "המערכת צריכה לשלוח דוא"ל ללקוח כשהיא מאשרת את ההזמנה." דרישה לא פונקציונלית מתארת ​​כיצד המערכת צריכה להיות: איכויות כמו ביצועים, אבטחה, שימושיות ונגישות. "מסך הדיווח אמור להיפתח תוך פחות מ-2 שניות בעומס ממוצע" היא דרישה לא פונקציונלית.

לדרישה טובה יש שלושה מאפיינים: היא ברורה (יש לה פרשנות אחת), היא ניתנת למדידה (יש לה סף ניתן לבדיקה), והיא ניתנת למעקב (ברור מאיזה צורך עסקי היא נובעת). "המערכת חייבת להיות מהירה" לא עונה על אף אחד מאלה; "מהיר" הוא סובייקטיבי, לא ניתן למדוד, לא ניתן לבדיקה. בשלב זה, בינה מלאכותית היא כלי עזר רב עוצמה בניסוח דרישות ותפיסת ניסוחים מעורפלים; אבל רק בעל העניין מחליט איזה כלל עסקי הוא אמיתי.

סיפור משתמש וקריטריוני קבלה

פורמט נפוץ בכתיבת דרישות מודרניות הוא סיפור המשתמש: "בתור [תפקיד], עבור [מטרה], אני רוצה [תכונה]." דוגמה: "כנציג מכירות אני רוצה חישוב הנחה ממסך הנייד כדי שאוכל לבצע הצעות מחיר מהירות בשטח". הסיפור קצר ומכוון לעסקים; זה לא כופה פתרון טכני.

לכל סיפור צריך להיות קריטריוני קבלה: תנאים שניתנים לבדיקה שחייבים להתקיים כדי שהסיפור ייחשב "בסדר". דפוס בשימוש תכוף הוא דפוס "נתון/מתי/אז": "נתון: הלקוח נמצא בקטע VIP. מתי: הזמנות מעל 10,000 TL. לאחר מכן: המערכת מפעילה 5% הנחה". דפוס זה מבטל אי בהירות מכיוון שהוא מקשר בבירור בין המצב לבין התוצאה הצפויה.

טיפ: בעת כתיבת סיפור משתמש לבינה המלאכותית, הקפד לומר "צור לפחות 2 קריטריוני קבלה בפורמט Given/When/ Then עבור כל סיפור". כאשר המודל נאלץ לייצר אמות מידה, פערים נסתרים בדרישה נראים לעין.

שלב אחר שלב: חילוץ דרישות בעזרת AI

שלב 1 - איסוף קלט גולמי. יומני שיחות, מיילים, צילומי מסך קיימים, רשימות תלונות. ככל שתשומה אמיתית יותר, כך פחות ייצור.

שלב 2 - חלץ את קבוצת הסיפורים הראשונה. תן קלט גולמי לבינה מלאכותית ובקש ממנה לייצר טיוטות של סיפור משתמש. שלב זה אינו רשימה מלאה, אלא שלב ראשון.

שלב 3 - הוסף קריטריוני קבלה. צור קריטריונים נתון/מתי/אז עבור כל סיפור. סיפור שלא ניתן לייצר עבורו קריטריונים פירושו למעשה שהוא לא מוגדר מספיק.

שלב 4 - סריקה לאיתור סתירות ופערים. שאל את AI "האם יש סתירות, כפילויות או מצבים לא מוגדרים בין הדרישות הללו?" תשאל ותבדוק. סנן את התוצאה כאדם.

שלב 5 - תעדוף ואשר. תעדוף סיפורים עם מחזיקי עניין בהתבסס על ערך עסקי ודחיפות. החלטת העדיפות שייכת ליחידה העסקית, לא ל-AI.

אל תשכח דרישות לא פונקציונליות

לרוב הפרויקטים יש קשיים בתחום מכיוון שהם שוכחים את הלא פונקציונליים תוך כדי כתיבת הדרישות התפקודיות. דוח עשוי לעבוד "נכון", אבל אם ייפתחו 45 שניות, אף אחד לא ישתמש בו. הטבלה הבאה מציגה סוגי דרישות שאינן פונקציונליות שמשתמשים בהן בדרך כלל ודוגמאות כתיבה ניתנות למדידה.

ז'אנר

ביטוי רע

ביטוי מדיד

ביצועים

"חייב להיות מהיר"

"תגובת שאילתה < 2 שניות בעומס ממוצע"

נגישות

"כולם צריכים להיות מסוגלים להשתמש בזה"

"תואם WCAG 2.1 AA; ניווט מלא במקלדת"

אבטחה

"זה צריך להיות בטוח"

"נתונים אישיים מוצפנים בזמן מנוחה; הגישה מבוססת תפקידים"

זמינות

"צריך להיות קל"

"משתמש חדש משלים את ההזמנה ב-3 שלבים ללא הכשרה"

זמינות/המשכיות

"לא צריך לקרוס"

"זמן פעילות חודשי ≥ 99.5%"

שלושה מיני מארזים: לפי המספרים

מקרה 1 - המחיר של צורך בלתי ניתן למדידה. המסך, שפותח בבנק עם הדרישה ש"מסך הדיווח צריך להיפתח במהירות", נפתח תוך 22 שניות בעומס שטח. היזם חשב שהוא מספק את המילה "מהיר" בסביבתו (2 שניות). אם הדרישה הייתה כתובה כ"< 3 שניות בשעת שיא, תפוקה בפועל", הבעיה הייתה נתפסת בבדיקה. השיפוץ עלה 3 שבועות ובעלות נוספת הניתנת למדידה.

מקרה 2 - פער שנלכד על ידי קריטריוני קבלה. בעת כתיבת קריטריוני הקבלה לסיפור "המערכת מפעילה הנחה" בפרויקט מסחר אלקטרוני, בעל העניין שם לב שמה יקרה אם ההנחה תתנגש עם הקופון והנחת VIP לא נדון כלל. שאלה בודדת נתון/מתי/אז מנעה את שגיאת ההנחה הכפולה לפני היציאה לאוויר; טעות זו גרמה לאובדן הכנסות חמור בפרויקטים דומים.

מקרה 3 - כלל תוצרת בינה מלאכותית. בפרויקט משאבי אנוש, AI הוסיפה את המשפט "בקשת עזיבה מאושרת אוטומטית תוך 24 שעות" לטיוטת הדרישות. אישור אוטומטי כזה לא נדון בפגישה; המודל הרכיב כלל שנראה "סביר". ליד כל דרישה כותב המומחה "מקור: איזה ראיון/מסמך?" על ידי הוספת הטור, הוא הסיר 4 משפטים ללא מקור.

הנחיה חלשה / הנחיה חזקה

הנחיה חלשה:

כתוב סיפורי משתמשים עבור הפרויקט הזה.

הנחיה עוצמתית:

התפקיד שלך: אתה אנליסט עסקי של MIS. חלץ סיפורי משתמשים מהערת הראיון למטה. כללים:- פורמט: "בתור [תפקיד], עבור [מטרה], אני רוצה [תכונה]."- כתוב לפחות 2 קריטריוני קבלה לכל סיפור בפורמט Given/When/Then.- הוסף עמודה "מקור" ליד כל סיפור: מאיזה משפט בא כל [UNCERTAIN] הכלל לא ברור? התאמה.- כתוב דרישות לא פונקציונליות מדידות (ביצועים, אבטחה, נגישות) בחלק נפרד. הערת ראיון:[טקסט]

הנחיה עוצמתית אוכפת בבת אחת את פורמט הסיפור, קריטריוני הקבלה, מעקב אחר מקור ודרישות לא פונקציונליות; זה מקל על השליטה בפלט.

ארבע תבניות הניתנות להעתקה

1) הבהרת דרישות:

סקור את הדרישה למטה. סמן כל אמירה מעורפלת, שאינה ניתנת להתאמה או פתוחה ליותר מפרשנות אחת וכתוב שאלת הבהרה לכל אחת מהן. אל תמציא את התשובה. דרישה: [טקסט]

2) סריקת סתירות:

ברשימת הדרישות למטה, מצא פריטים הסותרים זה את זה, שחוזרים על עצמם או משאירים פערים הגיוניים. דווח על כל ממצא עם מספרי פריט והצדקה של משפט אחד. רשימה: [טקסט]

3) יצירת קריטריוני קבלה:

כתוב לפחות 4 קריטריוני קבלה לסיפור המשתמש הבא בפורמט נתון/מתי/אז, כולל מקרי הגבלה וחריגים. רשום גם את כל הנקודות שנותרו לא ברורות. סיפור: [טקסט]

4) מתווה היקף:

נסח את הפריטים "בהיקף" ו"מחוץ לטווח" כטבלה בת שתי עמודות בהתאם לדרישות הבאות. תווית [אישור נדרש] עבור כל פריט שאינך בטוח בו. דרישות: [טקסט]

טעויות נפוצות

• לחשוב שהפתרון הוא צורך. "הוסף תפריט נפתח" הוא פתרון, לא דרישה. הדרישה אומרת "המשתמש חייב להיות מסוגל לבחור את המדינה מהרשימה המוגדרת"; צוות ה-IT מעצב את הפתרון.
• דילוג על אלה שאינם פונקציונליים. פשוט לרשום "מה לעשות" ולשכוח "איך להיות" (מהירות, אבטחה, נגישות) היא הפרצה הנפוצה והיקרה ביותר.
• שימוש בשמות תואר בלתי ניתנים למדידה. מילים כמו "מהיר, קל, בטוח, ידידותי למשתמש" אינן חוקיות ללא סף.
• לא שם לב לכלל שה-AI המציא. המודל עשוי להוסיף כללים "סבירים" אך לא מדוברים בפועל; בקשו משאבים לכל צורך.
• משאירים את סדר העדיפויות ל-AI. מה לעשות קודם הוא החלטה על ערך עסקי; היחידה העסקית נותנת זאת.

זהירות: המשפט המסוכן ביותר בניתוח דרישות הוא "כולם כבר יודעים את זה". הנחות שלא נאמרו אינן נכנסות לתיעוד, לעולם אינן נכנסות לקוד, ומופיעות בשטח. שאל AI "מה ההנחה אבל לא כתוב בדרישה זו?" הופך את ההנחות הנסתרות הללו לגלויות.

לסיכום

ניתוח דרישות מגדיר מה המערכת צריכה לעשות בצורה ברורה, מדידה וניתנת למעקב. דרישות פונקציונליות מתארות את התפקיד, דרישות לא פונקציונליות מתארות את האיכויות, והאחרון נשכח לרוב. סיפור משתמש וקריטריוני קבלה נתון/מתי/אז הם כלים רבי עוצמה שמבטלים אי ודאות. בינה מלאכותית מאיצה משמעותית את ייצור לוחות התכנון, קריטריוני קבלה, זיהוי קונפליקטים ושאלות הבהרה; עם זאת, נכונות הכלל העסקי, היקפו והחלטת העדיפות והמקור לכל משפט הם באחריות האדם. אין להשלים כל דרישה שאינה מקורה ובלתי ניתנת למדידה.

משימת יישום

כתוב בקשה עסקית של פסקה אחת ל"מערכת מקוונת לתורים" דמיונית (למשל, "לקוחות צריכים להיות מסוגלים לקבוע פגישות באינטרנט, הצוות צריך להיות מסוגל לראות לוחות שנה"). (1) צור לפחות 5 סיפורי משתמשים ו-2 קריטריוני קבלה לכל אחד עם הנחיה חזקה מהבקשה הזו. (2) מצא לפחות 2 פערים נסתרים בקריטריונים שמייצר המודל (למשל מינוי כפול בו זמנית, כלל ביטול). (3) כלול לפחות 3 דרישות שאינן פונקציונליות בצורה ניתנת למדידה. (4) זהה לפחות 3 פריטים כ"מחוץ לתחום". (5) סמן כלל שאולי הדגם המציא וכתוב כיצד היית מאשר אותו.

רשימת בדיקה

• [ ] כתבתי דרישות פונקציונליות ולא פונקציונליות בנפרד.
• [ ] כל דרישה ברורה, מדידה וניתנת לבדיקה.
• [ ] לכל סיפור יש קריטריוני קבלה נתון/מתי/אז.
• [ ] אני יכול להתחקות אחר המקור (שיחה/מסמך) של כל דרישה.
• [ ] סימנתי את הכללים האפשריים שה-AI הכינה והשארתי אותם לאישור.
• [ ] עשיתי את סדר העדיפויות יחד עם היחידה העסקית.