מסמך דרישות למערכת: איך מחליפים ניסוח כללי בתוצאה שניתן לבדוק
מאת איתי דילן זריהן זיונץ· הבעלים של POCAST
דרישה צריכה לתאר פעולה או תוצאה שהצוות יכול לבחון. ״מערכת נוחה ומהירה״ אינו תנאי קבלה מספיק.
התשובה בקצרה
דרישה צריכה לתאר פעולה או תוצאה שהצוות יכול לבחון. ״מערכת נוחה ומהירה״ אינו תנאי קבלה מספיק. כתבו מי פועל, באיזה מצב ומה ייחשב תוצאה מתאימה, בלי להסתיר החלטה חשובה מאחורי מילה כללית.
החלטות ותהליך עבודה
לכל דרישה הוסיפו דוגמה, תלות וגבול תכולה. הבחינו בין יכולת נדרשת, העדפה ושאלה שטרם הוכרעה. אם נדרש מדד זמן או היקף, הגדירו את תנאי הבדיקה לפני קביעת ערך, ולא מספר שנבחר בלי בסיס. רשמו מסלול כשל והרשאות לפי הצורך. כשמשתנה ניסוח, בדקו אילו מסכים ותהליכים מושפעים ועדכנו גרסה מאושרת אחת.
תרחיש להמחשה
במפרט לדוגמה כתוב ״אפשר לייצא מידע״. הבירור מגדיר מי רשאי לייצא, אילו שדות ומה קורה ברשימה ריקה. עכשיו ניתן לבצע בדיקת קבלה ולא רק להציג כפתור ייצוא.
רשימת בדיקה
- הדרישה כוללת תפקיד ומצב.
- תוצאה צפויה כתובה.
- העדפות ושאלות מובחנות מחובה.
- תנאי מדידה הוגדרו לפני מספרים.
- שינוי דרישה מתועד בגרסה.
בדיקת החלטה לפני שממשיכים
החליפו במפרט ״נוח ומהיר״ בתרחיש שניתן לבצע ולבדוק. תנאי שאי אפשר להכריע אם התקיים נשאר שאלה לאפיון ולא דרישת קבלה סגורה.
שאלה שכדאי להכניס לבריף
באיזו פעולה ובאיזה מצב ייבדק שהדרישה התקיימה?
המוצר והתכולה לבירור
מסמך דרישות למערכת — דרישות וגבולות לגרסה ראשונה. השירות כפוף להצעת מחיר מותאמת לאחר בירור החומרים, ההיקף ונקודות האישור.
לעריכת בריף ולפנייה בנושא המוצר.
לכל המוצרים בתחום פיתוח תוכנה ומוצרים דיגיטליים.
הכנת בריף
כלי לתכנון הפרויקט — אפשר להכין סיכום ולערוך אותו לפני פנייה.