(שלב ג' בתהליך הפיתוח)
מטרת המסמך ותוכנו:
- להציג את כל הדרישות הטכניות מהמוצר והגרסה, כולל תוכנה וחומרה.
- הצגת הארכיטקטורה ופירוק לרמות נמוכות.
- אמור לכלול ביצועים, storage, צריכת זכרון, זמני תגובה, ביצועי בסיסי הנתונים ועוד.
אל תקבלו משפט כמו: שיתמוך בכמות סבירה של משתמשים! אחרת הבדיקה שלכם לא תהייה בדיקה אלא benchmark. צריך להחיל מראש לאן שואפים, ואפשר ליצור פשרות אח"כ, אבל מתפקיד כותב המסמך לדעת מה הוא מאפיין! אותו דבר לגבי שאר הנתונים.
- דרישות כלליות של ה-GUI ושל תהליכיפ פנימיים (בדיזיין יהיה פירוט ברור יותר של ה-GUI).
- תרשימי זרימה לאורך כל המערכת.
- דרישות security
- דרישות לגבי התחזוקה
- דרישות לגבי מהימנות המערכת (עליה לעמוד בעומס של X פעולות לאורך Y שעות במשך Z זמן עם A שגיאות מותרות בדרגת חומרה B).
- ממשקים חיצוניים
- ממשקים פנימיים
- קינפוג חומרה ותוכנה
- מגבלות
- תמיכה לאחור (backwards compatibility)
- דרישות התקנה
- קווים מנחים להתקנות ולבדיקות
ביקורת של אפיון טכני
חשוב מאוד להבין שגם כאן אין קיצורי דרך, ואם לא תדרשו לקבל מסמך טוב לפי ההגדרות כאן זה לא רק שלא יחסוך לכם עבודה וזמן אלא יכפיל אותם, ויגרום עגמת נפש ללקוח!
על הדרישות להיות:
עצה אחרת ששמעתי היא לשאול לגבי כל דרישה את השאלות הבאות:
1. מה
2. מתי
3. איך
4. איפה
5. למה
6. מי
למשל הוספת פיצ'ר של שמירה אוטומאטית של מסמך.
1. מה קורה אם זה שומר בזמן שאני כותב / פותח תפריט מסויים וכו'
2. מתי השמירה מתבצעת והאם אפשר לקנפג את זה
3. איך המנגנון פועל מאחורי הקלעים
4. איפה יישמר הקובץ אם המסמך עדיין לא שמור
5. למה יש בכך צורך והאם הדרישה משרתת את הצורך, ואולי אפשר לשלב צרכים אחרים?
6. מי מוודא שזה קורה? האם יש מנגנוני אזהרה?
שאלת שאלות אלו יקלו עליכם בכתיבת המסמכים בייחוד בעניין של expected results.
מטרת המסמך ותוכנו:
- להציג את כל הדרישות הטכניות מהמוצר והגרסה, כולל תוכנה וחומרה.
- הצגת הארכיטקטורה ופירוק לרמות נמוכות.
- אמור לכלול ביצועים, storage, צריכת זכרון, זמני תגובה, ביצועי בסיסי הנתונים ועוד.
אל תקבלו משפט כמו: שיתמוך בכמות סבירה של משתמשים! אחרת הבדיקה שלכם לא תהייה בדיקה אלא benchmark. צריך להחיל מראש לאן שואפים, ואפשר ליצור פשרות אח"כ, אבל מתפקיד כותב המסמך לדעת מה הוא מאפיין! אותו דבר לגבי שאר הנתונים.
- דרישות כלליות של ה-GUI ושל תהליכיפ פנימיים (בדיזיין יהיה פירוט ברור יותר של ה-GUI).
- תרשימי זרימה לאורך כל המערכת.
- דרישות security
- דרישות לגבי התחזוקה
- דרישות לגבי מהימנות המערכת (עליה לעמוד בעומס של X פעולות לאורך Y שעות במשך Z זמן עם A שגיאות מותרות בדרגת חומרה B).
- ממשקים חיצוניים
- ממשקים פנימיים
- קינפוג חומרה ותוכנה
- מגבלות
- תמיכה לאחור (backwards compatibility)
- דרישות התקנה
- קווים מנחים להתקנות ולבדיקות
ביקורת של אפיון טכני
חשוב מאוד להבין שגם כאן אין קיצורי דרך, ואם לא תדרשו לקבל מסמך טוב לפי ההגדרות כאן זה לא רק שלא יחסוך לכם עבודה וזמן אלא יכפיל אותם, ויגרום עגמת נפש ללקוח!
על הדרישות להיות:
- מלאות וברורות מתוך המסמך עצמו (יש אפשרות לקשר למסמכים אחרים בכדי להבין תהליכים קודמים או קישור למסמכים מסוג שונה אבל לא שנצטרך לשאול שאלות לגיטימיות שהתשובות עליהן יפנו אותנו למייל או לאיזו תורה שבעל-פה).
- נכונות.
- חד-משמעיות.
- עקביות עם שאר המסמך ועם המערכת.
- ניתנות ל-traceability, כלומר כל דרישה היא סעיף, כל תת-דרישה היא תת-סעיף).
- ניתנות לווידוא (על ההתנהגות להיות סבירה - לא ניתן לווידוא).
עצה אחרת ששמעתי היא לשאול לגבי כל דרישה את השאלות הבאות:
1. מה
2. מתי
3. איך
4. איפה
5. למה
6. מי
למשל הוספת פיצ'ר של שמירה אוטומאטית של מסמך.
1. מה קורה אם זה שומר בזמן שאני כותב / פותח תפריט מסויים וכו'
2. מתי השמירה מתבצעת והאם אפשר לקנפג את זה
3. איך המנגנון פועל מאחורי הקלעים
4. איפה יישמר הקובץ אם המסמך עדיין לא שמור
5. למה יש בכך צורך והאם הדרישה משרתת את הצורך, ואולי אפשר לשלב צרכים אחרים?
6. מי מוודא שזה קורה? האם יש מנגנוני אזהרה?
שאלת שאלות אלו יקלו עליכם בכתיבת המסמכים בייחוד בעניין של expected results.
אין תגובות:
הוסף רשומת תגובה