איך כותבים אפיון למפתח בלי רקע טכני: תרחישים, נתונים וקבלת החלטות
חזרה לבלוג
product·6 בספטמבר 2026·4 דק' קריאה·מאת יהונתן סעדיה

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

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

עיקרי הדברים

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

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

איך נראה תרחיש כתוב

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

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

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

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

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

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

דרישה כתובה רע, ואיך כותבים אותה נכון

הדרישה המקורית: "המערכת תשלח תזכורת ללקוחות שלא שילמו."

המשפט הזה נשמע ברור והוא מסתיר לפחות שבע החלטות. הטבלה מפרקת אותו:

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

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

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

אילו החלטות הן שלכם ואילו של המפתח?

זה הגבול שחוסך את רוב הוויכוחים בהמשך:

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

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

מה זה "גמור" ומי קובע?

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

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

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

המסלולים הכושלים שהכי הרבה שוכחים

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

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

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

מקורות

#specification#requirements#scenarios#software development#project management#השוואה

שאלות נפוצות

כמה מפורט אפיון צריך להיות?

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

אפשר לכתוב אפיון בלי לדעת מה אפשרי טכנית?

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

מה עושים כשאין תשובה לכלל מסוים?

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

צריך לצייר מסכים?

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

להמשך קריאה

שירות רלוונטי

פיתוח MVP

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

מידע נוסף →←

על הכותב

יהונתן סעדיה

מפתח פרילנסר לאוטומציה, אתרים ו-MVP

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

בוא נעבוד יחד

יש לך פרויקט דומה?

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