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

מה זה אפיון מערכת

אפיון מערכת הוא מסמך שמתאר מערכת תוכנה: מערכת ניהול, אזור אישי, אפליקציה, פורטל ספקים או כל כלי שאנשים עובדים בו כל יום. בשפה של הנדסת תוכנה קוראים למסמך כזה SRS (Software Requirements Specification, מפרט דרישות תוכנה).

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

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

במה אפיון מערכת שונה מאפיון אתר

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

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

גוף הידע של הנדסת תוכנה (SWEBOK) של IEEE Computer Society מחלק את הדרישות לשתי קבוצות, ובגרסה 4 שלו יש לכל אחת פרק משלה:

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

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

החלקים של אפיון מערכת

תפקידים והרשאות

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

ישויות ושדות

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

חוקים עסקיים

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

מצבים ומעברים

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

מסכים וזרימות

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

חיבורים, דוחות והגירת נתונים

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

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

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

לכל סיפור מצמידים קריטריוני קבלה: רשימת תוצאות שמגדירה מתי הסיפור גמור. בבלוג הטכנולוגי של ממשלת בריטניה מומלץ לכתוב אותם כתרחישים בתבנית Given, When, Then (בהינתן, כאשר, אז), בשפה פשוטה, ובלי להכתיב את הפתרון הטכני.

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

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

מי כותב אפיון מערכת ומתי

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

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

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