כיצד לכתוב מסמך אפיון – לאפליקציה/מערכת וובית חדשה

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

 הנחיות לכתיבת מסמך אפיון – מערכת web

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

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

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

כללים מנחים:

1. אופן הצגת האפיון

  • שרטוט המסכים אשר יהיו גלויים למשתמש + דף הסבר מפורט במילים על כל מסך.
  • קישורים בין מסכים ותוצאות פעולות (לאן מוביל כל מסך, מה קורה כשלוחצים על כל כפתור)  – יכתבו בטבלא נפרדת המוצמדת לכל עמוד.
  • פרוט כתוב ו/או סכמטי של התהליכים הפנימיים העומדים מאחורי תוצאות הפעולה (מנגנוני התאמה, פרמטרים לחיפוש וכד’).
  • שרטוט מסכי ה- Admin  + דפי הסבר מפורטים במילים על כל מסך.

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

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

שלב ראשון – שרטוט המסכים.

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

  • דף הבית  – רצוי להתחיל ממנו, כיוון שהוא מספק מבט כללי על המערכת.  כיום, חשיבות דף הבית הקלאסי במערכות אינטרנט הולכת וקטנה, עקב הגדש המושם על פרסונליזציה ועמודי נחיתה מותאמים אישית. ברשתות חברתיות, לדוגמה, דף הבית הוא דווקא הדף המשמעותי פחות, והמשתמש מבלה את רוב זמנו ב”כרטיס האישי” אשר הופך לדף הבית הפרטי שלו.  חשוב – מהו הדף המשמעותי ביותר במערכת שלך? מהו הדף אשר יהווה “נקודת עוגן” למשתמש ואליו ירגיש בטוח לחזור בכל פעם ש”ילך לאיבוד” באתר? מהו הדף אשר ממנו יגיעו המשתמשים לכמות הגדולה ביותר של דפים אחרים? זהו “דף הבית” של המערכת שלך.
  • דפים פנימיים  עיקריים –  יש להתחיל מהדפים הפנימיים בעלי החשיבות הגדולה ביותר, ולרדת אל הדפים החשובים פחות.  כדי לעשות זאת, מומלץ לדמיין “flow” של המערכת –  תסריט התנהגות דמיוני של המשתמשים מרגע כניסתם לאתר ועד עזיבתם. מכך לא משתמע כי הדפים הראשונים אליהם יכנסו המשתמשים הם החשובים ביותר. לדוגמה, במערכת E-commerce, דווקא דפי הקניה אשר ממוקמים לקראת סוף השימוש הם הדפים עליהם צריך לשים את הדגש הרב ביותר, כיוון שהסטטיסטיקה מראה שרוב הקונים “נוטשים” בקופה.
  • דפים שוליים – הם דפיError  למיניהם, דפי תיקון לפעולות לא תקינות שעשה המשתמש, או דפים אזוטריים שמשתמשים לרוב אינם מגיעים אליהם. אין לזלזל גם בחשיבות שלהם, כיוון שדקדוק בפרטים הקטנים מקנה למשתמש תחושת רצינות. מומלץ לא לזלזל גם בדפי הטקסט המוכרים של אודות, תנאי השימוש ויצירת קשר ולהכניס גם אליהם איזושהי תפנית של חדשנות, שכן למרות הבנאליות שלהם, רוב המבקרים לא פוסחים עליהם בביקור הראשון.
  • תתי דפים
    • פעמים רבות משתנים הדפים משמעותית ללא “מעבר” פורמאלי לדף אחר. לדוגמה, פתיחת חלון Ajax המכיל נתונים שונים, או פתיחה  וסגירה של טבלאות. יש לשרטט דפים אלו בנפרד , כאילו היו דף נפרד, ולמספר אותם באותיות (“דף 23 ג'”).
    • לעומת זאת, פעמים רבות ישנן משבצות גנריות אשר הנתונים בהן משתנים בהתאם לפרמטרים שונים (זמן, נתונים שהקליד המשתמש וכד’) אך אינן משנות את העמוד באופן משמעותי. לדוגמה – משבצת סטטית המציגה נתוני מניות בזמן אמת. עבור משבצות אלו אין צורך לשרטט את העמוד מחדש אלא להשאירן ריקות ולפרט בצידן  (“בלון”) את רשימת סוגי המידע אשר יוצג בהן.
    • אם אותו הדף יכול להיות מוצג באופן שונה בין סוגי משתמשים שונים (לדוגמה: משתמש רשום ומשתמש לא רשום, מנוי רגיל ומנוי פרימיום), רצוי לא להתעצל ולהכין סט חדש של דפים לכל סוג משתמש.
  • אפיונים אשר לא ברור בשלב הראשוני לאיזה מסך שייכים, ניתן להשאיר “בצד” ולהוסיף אל המערכת רק כאשר השבלונות של כל המסכים כבר מוכנות. במצב כזה, כאשר יש תמונה כללית יותר של המערכת, ניתן לראות באופן ברור יותר באיזה מסך ובאיזה מיקום משתלב כל כפתור.

שלב שני –  קישורים בין מסכים.

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

אובייקט לחיץ

קלט תקין

תוצאה

קלט לא תקין

תוצאה

כפתור “upload”

מילוי כל השדות אשר מעליו

מעבר לעמוד מס’ 14ב’

משתמש לא רשום

מעבר לעמוד  מס’ 3 – Login

אי מילוי כל השדות

כוכביות אדומות לצד כל שדות החובה אשר לא מולאו.

קישור “המלצות”

לחיצה

פתיחת חלון Ajaxבו יופיעו המלצות המותאמות נתוני המשתמש כפי שנקלטו בדף 7.

אין

תמונות שהועלו ע”י המשתמש.

Drag and dropאל תוך מאגר התמונות.

אפשרות לסידור התמונות בתוך האלבום האישי.

גרירה אל איזור החורג מהאלבום האישי

התמונה תחזור למקומה המקורי.

שלב שלישי – הגדרת התהליכים הפנימיים:

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

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

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

שלב רביעי – תכנון מסכי ה- Admin :

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

  • באילו טקסטים?
  • באילו לינקים/כפתורים?
  • כיצד יהיה ניתן לשלוט במשתמשים? למחוק יוזר? לשנות סיסמא? לחסום יוזר? לקדם יוזר? (חשוב במיוחד במקרים של נקודות או כסף בקופת המשתמשים).
  • האם אני צריך את האפשרות לצנזר דברים? היכן?
  • אם יש משחקים באתר – האם הייתי רוצה לשנות רמות? להתערב בפרמטרים של המשחק?  לשנות דמויות?
  • האם דרושה יכולת הוספת והחלפת “סקינים”?
  • האם באופן כללי יש צורך בשליטה על עיצוב האתר – הזזת רכיבים ממקום למקום, הורדה, שינוי והוספה ידנית של המוצג בדף?
  • האם דרושים מסכי Admin בנפרד לכל שפה או מסכים “רוחביים” אשר בהם ניתן לשנות, לרכיב מוגדר, את כל השפות בו זמנית?

השאלה הבאה הזקוקה למענה – במה הייתי רוצה אפשרות לצפות ואילו סטטיסטיקות הייתי רוצה לקבל?

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

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

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

  • מיקום לפרסום באתר- היכן? כיצד? האם דרושה התממשקות עם חברת פרסום מסוימת?
  • אם ישנה סליקה באתר – לאיזו חברת סליקה או חיוב יש להתממשק? האם דרושה יכולת חיוב באמצעות SMS?
  • תמיכה בשפות – האם דרוש? בכמה שפות? האם גם מימין לשמאל וגם משמאל לימין?
  • במקרה של אפשרות העלאה קבצים לאתר, ע”י המשתמשים – אילו מגבלות יהיו להעלאה? גודל? משקל? סוגי קבצים?
  • איסוף נתונים על המשתמש – האם נדרש יכולת זיהוי שפת המקור של המשתמש ובדיקת איזור הימצאותו? האם המערכת צריכה “ללמוד” באופן כלשהו את התנהגותו של המשתמש?  לזכור פעולות אחרונות שלו?  האם דרוש לשמור נתונים של המשתמש גם בלי רישום, ובכך לחסוך ממנו תהליך זה?
  • האם “להוציא” את המשתמש מהמערכת אחרי זמן מסוים בו לא השתמש בה?
  • עיצוב – האם להשתמש בשירותי העיצוב של סרגטה או שדרוש תאום  עם מעצב חיצוני?
  • שימוש ב”קוד פתוח” לשם פיתוח האתר – האם ישנה איזושהי עמדה נגד?
  • שפות תכנות, טכנולוגיות וסוג מסד הנתונים – האם ישנן העדפות מיוחדות? מומלץ להיוועץ בנו בנושא.
  • חשוב לזכור, כי ישנם מקומות בהם כדאי לפרט מה *לא* חשוב לכם, על מנת לחסוך בזמן ובעלות הפיתוח.

אנו עומדים לרשותך לכל שאלה.

בהצלחה,

צוות סרגטה.