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

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

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

דוגמה לשימוש במקרה

איך נראה התרחיש, באמצעות דוגמה של הרשאה באתר באמצעות דואר אלקטרוני:

(מערכת) היכנס לאתר כדי לגשת לחשבון האישי שלך. ~~ (גובה פני הים)

הֶקשֵׁר: לקוח לא מורשה מתחבר לאתר כדי שהאתר יזהה אותו ויציג עבורו מידע אישי: היסטוריית גלישה, היסטוריית רכישות, מספר נקודות בונוס עדכני וכדומה, תוך שימוש במייל ככניסה. 
רמה: מטרת המשתמש
דמות ראשית: לקוח (מבקר בחנות המקוונת שלנו)
תְחוּם: אינטראקציה עם הלקוח עם אתר החנות המקוונת
בעלי עניין ואינטרסים:

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

תנאים מוקדמים: אין להרשות למבקר.
מינימום ערבויות: המבקר יידע אם ניסיון ההרשאה הצליח או לא צלח.
הבטחות להצלחה: המבקר מורשה.

תרחיש עיקרי:

1. הלקוח יוזם הרשאה.
2. המערכת מאשרת שהלקוח אינו מורשה ואינו חורג ממספר ניסיונות ההרשאה הלא מוצלחים מסשן נתון (חיפוש סיסמה חלשה למספר חשבונות) לפי "כלל אבטחה מס' 23".
3. המערכת מגדילה את המונה למספר ניסיונות ההרשאה.
4. המערכת מציגה טופס הרשאה ללקוח.
5. הלקוח מזין את המייל והסיסמה שלו.
6. המערכת מאשרת נוכחות של לקוח עם אימייל כזה במערכת וכי הסיסמה תואמת ואין חריגה ממספר ניסיונות הכניסה לחשבון זה על פי "כלל אבטחה מס' 24".
7. המערכת מאשרת את הלקוח, מוסיפה את היסטוריית הגלישה ואת הסל של הפעלה זו עם ההפעלה האחרונה של חשבון לקוח זה.
8. המערכת מציגה הודעת הצלחה של הרשאה ועוברת לשלב הסקריפט שממנו הופסק הלקוח לצורך הרשאה. במקרה זה, הנתונים בדף נטענים מחדש תוך התחשבות בנתוני החשבון האישי.

הרחבות:
2.א. הלקוח כבר מורשה:
 2.א.1. המערכת מודיעה ללקוח על עובדת ההרשאה שבוצעה בעבר ומציעה להפריע לסקריפט או לעבור לשלב 4, ואם שלב 6 הושלם בהצלחה, שלב 7 מבוצע בהבהרה:
 2.א.7. המערכת מבטלת את הלקוח תחת החשבון הישן, מאשרת את הלקוח תחת החשבון החדש, בעוד שהיסטוריית הגלישה והסל של סשן אינטראקציה זה נשארים בחשבון הישן ואינם עוברים לחדש. לאחר מכן, עבור לשלב 8.
2.ב מספר ניסיונות ההרשאה עבר את הסף לפי "כלל אבטחה מס' 23":
 2.ב.1 עבור לשלב 4, קפטצ'ה מוצג בנוסף בטופס ההרשאה
 2.ב.6 המערכת מאשרת הזנת captcha נכונה
    2.b.6.1 Captcha הוזן בצורה שגויה:
      2.ב.6.1.1. המערכת מגדילה את המונה של ניסיונות הרשאה לא מוצלחים גם עבור חשבון זה
      2.ב.6.1.2. המערכת מציגה הודעת כשל וחוזרת לשלב 2
6.א. לא נמצא חשבון עם האימייל הזה:
 6.a.1 המערכת מציגה הודעה על כישלון ומציעה אפשרות לעבור לשלב 2 או לעבור לתרחיש "רישום משתמש" ושמירת האימייל שהוזן,
6.ב. הסיסמה של החשבון עם דוא"ל זה אינה תואמת לסיסמה שהוזנה:
 6.ב.1 המערכת מגדילה את המונה של ניסיונות התחברות לא מוצלחים לחשבון זה.
 6.ב.2 המערכת מציגה הודעה על כשל ומציעה אפשרות לעבור לתרחיש "שחזור סיסמה" או לעבור לשלב 2.
6.ג: מונה ניסיונות הכניסה לחשבון זה חרג מהסף של "כלל אבטחה מס' 24".
 6.ג.1 המערכת מציגה הודעה על חסימת כניסה לחשבון למשך X דקות וממשיכה לשלב 2.

מה נהדר

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

עבודה עם מערכת קופסה שחורה מאפשרת להפריד בין הפיתוח והתיאום עם הלקוח של מה שיהיה אוטומטי משיטות ההטמעה.

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

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

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

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

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

תוספת לשיטה מהתרגול

מקרה השימוש אינו חלק מתועדף עצמאי בהצהרה, בניגוד לסיפור המשתמש.

בתרחיש לעיל, שקול חריג "6.א. לא נמצא חשבון עם האימייל הזה." והשלב הבא "6.a.1 המערכת מציגה הודעת כשל וממשיכה לשלב 2." אילו דברים שליליים נותרו מאחורי הקלעים? מבחינת הלקוח, כל תמורה שקולה לעובדה שכל העבודה שעשה בהזנת נתונים מושלכת למזבלה. (זה פשוט לא נראה בתסריט!) מה אפשר לעשות? בנה מחדש את הסקריפט כדי שזה לא יקרה. האם ניתן לעשות זאת? אתה יכול - כדוגמה, להסתכל על סקריפט ההרשאה של גוגל.

אופטימיזציה לתרחישים

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

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

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

אם פשוט נתאר את תרחיש האינטראקציה בשלב הרישום, נוכל לכתוב "להודיע ​​ללקוח שהמשלוח בלתי אפשרי ולהציע לשנות את העיר או את תכולת העגלה" (ואנליסטים מתחילים רבים עוצרים שם). אבל אם יש הרבה מקרים כאלה, אז אפשר לייעל את התרחיש.

הדבר הראשון שאתה צריך לעשות הוא לתת לך לבחור רק את העיר שבה אנחנו יכולים לספק. מתי לעשות זאת? לפני בחירת מוצר באתר (זיהוי אוטומטי של העיר באמצעות IP עם הבהרה).

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

שני השינויים הללו עושים דרך ארוכה לקראת ביטול חריג זה.

דרישות למדידות ומדדים

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

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

גישה לשימושיות

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

לעיצוב השימושיות, הוספנו קטע קלט - הצגת נתונים.

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

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

בדוגמה עם הרשאת לקוח, אם מפרידים את המידע שהוזן לכניסה וסיסמא, אז כדאי לשנות את סקריפט ההרשאה כדי להדגיש את שלבי הזנת התחברות נפרדת וסיסמה נפרדת (וזה נעשה ב-Yandex, Google, אבל לא נעשה ברוב החנויות המקוונות).

הגעה לטרנספורמציות הנתונים הנדרשות

אתה יכול גם לחלץ דרישות לאלגוריתמים להמרת נתונים מהסקריפט.

דוגמאות:

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

בסך הכל

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

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

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

מקור: www.habr.com