בקצרה: המבנה נשען על המבנה המקובל של מסמכי דרישות (IEEE 830 ו-ISO/IEC/IEEE 29148): מבוא והיקף, תיאור כללי, דרישות מפורטות ואימות. הוספנו לו שלושה דברים שבפרויקטים אמיתיים חסרים הכי הרבה: טבלת תפקידים והרשאות, רשימה של מה לא נכלל, וקריטריוני קבלה לכל דרישה בצורה שאפשר לבדוק. מסמך בלי קריטריוני קבלה הוא תיאור כוונות, לא אפיון.

המבנה

#סעיףמה כותבים בו
1מטרה והיקףהבעיה העסקית במשפט או שניים, מי המשתמשים, מה נכלל בגרסה הזאת ומה לא נכלל
2מונחיםכל מונח עסקי שמופיע במסמך, עם הגדרה אחת ברורה. אם הצוות קורא לאותו דבר בשני שמות, כאן מחליטים על שם אחד.
3משתמשים ותפקידיםטבלה: תפקיד, מה רואה, מה משנה, מה אסור לו
4תהליכיםהתהליכים העסקיים המרכזיים, צעד אחר צעד, כולל מה קורה כשמשהו משתבש
5דרישות פונקציונליותסיפור משתמש לכל יכולת, ולכל סיפור קריטריוני קבלה
6מודל נתוניםישויות, שדות חשובים, קשרים, ומי המקור לכל נתון
7אינטגרציותמערכות חיצוניות, מה עובר, באיזה כיוון, ומה קורה כשהן לא זמינות
8דרישות לא פונקציונליותביצועים, זמינות, אבטחה, פרטיות, נגישות, שפות
9אימותאיך בודקים כל דרישה: תרחישים, נתוני בדיקה, ומי מאשר
10נספחיםמסכים לדוגמה, דוחות קיימים, דוגמאות קבצים

סעיף 1: מה לא נכלל

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

סעיף 3: תפקידים והרשאות

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

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

לכל שורה בעמודת "אסור" כותבים תרחיש בדיקה בסעיף 9. אם אין תרחיש, אין דרך לדעת שהאיסור באמת עובד.

סעיף 5: דרישות שאפשר לבדוק

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

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

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

סעיף 8: מה שוכחים בישראל

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

איך להשתמש בתבנית

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

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

שאלות נפוצות

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

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

מה ההבדל בין מסמך אפיון למסמך דרישות?

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

כמה עמודים צריך להיות מסמך אפיון?

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

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

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

אפשר להשתמש במסמך כזה עם כלי AI לפיתוח?

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

מאיפה להתחיל

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

דברו איתי

קשור: תהליך אפיון מערכות, אפיון לפני פיתוח עם AI, אפיון ופיתוח CRM