מה זה מסמך אפיון?

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

במילים פשוטות, מסמך אפיון אמור לענות על השאלה:

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

למה בכלל צריך מסמך אפיון?

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

כאשר אין אפיון מסודר, עלולות להיווצר שאלות רבות במהלך הפיתוח:

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

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

מה כולל מסמך אפיון?

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

1. רקע ומטרות הפרויקט

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

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

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

2. הגדרת היקף הפרויקט

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

מה כלול?

• מסכים חדשים.
• שינויים במסכים קיימים.
• תהליכים עסקיים חדשים.
• ממשקים חדשים.
• שינויים בדוחות.
• שינויים בהרשאות.

מה לא כלול?

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

3. מי המשתמשים במערכת?

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

לדוגמה:

4. תיאור התהליך העסקי

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

לדוגמה:

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

5. דרישות פונקציונליות

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

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

הניסוח השני מאפשר למפתח להבין מה נדרש ולאיש QA לבדוק האם הדרישה מתקיימת.

6. דרישות לא פונקציונליות

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

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

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

7. אפיון מסכים

לכל מסך מרכזי כדאי לתאר לפחות:

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

דוגמה לאפיון שדה

8. אפיון ממשקים בין מערכות

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

לדוגמה:

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

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

לנושא הזה אפשר להעמיק גם באמצעות המאמר בדיקות אינטגרציה ב-SAP – איך לבדוק ממשקים.

9. מה קורה במצב של שגיאה?

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

לכל פעולה משמעותית כדאי לשאול:

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

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

10. קריטריוני קבלה

קריטריון קבלה הוא תנאי שמגדיר מתי ניתן לומר שדרישה הושלמה בהצלחה.

קריטריוני קבלה ברורים יוצרים חיבור ישיר בין האפיון לבין תהליך ה-QA.

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

מסמך אפיון ו-QA – הקשר החשוב בין השניים

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

לדוגמה, דרישה שאומרת "המשתמש יוכל להוסיף לקוח" יכולה להוביל למספר רב של בדיקות:

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

לכן אפיון איכותי יכול לשפר גם את איכות הבדיקות ולצמצם אי-הבנות בין הפיתוח ל-QA.

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

מסמך אפיון במערכת SAP

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

לדוגמה, שינוי בתהליך עסקי עשוי להשפיע על מספר שלבים שונים:

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

באתר תוכלו להעמיק בנושא באמצעות המדריך לבדיקות מערכות SAP.

איך כותבים מסמך אפיון בצורה נכונה?

כתיבת מסמך אפיון אינה מתחילה בפתיחת Word והתחלת כתיבת מסכים. מומלץ לעבוד בתהליך מסודר.

שלב 1 – להבין את הצורך העסקי

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

שלב 2 – לזהות את המשתמשים

יש לזהות את סוגי המשתמשים, הצרכים שלהם ורמות ההרשאה שלהם.

שלב 3 – למפות את התהליך

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

שלב 4 – להגדיר דרישות

כל דרישה צריכה להיות ברורה, חד-משמעית וניתנת לבדיקה.

שלב 5 – להגדיר חריגים

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

שלב 6 – להגדיר קריטריוני קבלה

לכל דרישה משמעותית צריך להיות ברור כיצד ניתן לוודא שהיא הושלמה.

שלב 7 – לבצע Review

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

טעויות נפוצות בכתיבת מסמך אפיון

כתיבה כללית מדי

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

התמקדות במסכים בלבד

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

אי-הגדרת מה לא כלול

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

אי התייחסות ל-QA

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

אי-התייחסות לתרחישי קצה

המערכת צריכה להיות מתוכננת גם למצבים שאינם התרחיש הרגיל.

Checklist לפני אישור מסמך אפיון

מסמך אפיון הוא בסיס משותף לכל צוות הפרויקט

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

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

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