גילוי ודרישות

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

תירוצים של לקוחות "למה לא צריך מסמך דרישות"

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

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

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

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

מטרות תהליך הגילוי

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

איך זה מתבצע?

בעיקר באמצעות תקשורת בה מגלים את הדרישות האמיתיות:

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

מה מכיל מסמך הדרישות

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