כיום יש כלים טובים (למשל ב-Quality Center) למעקב אחרי דרישות. אני אתייחס לצדדים החשובים, תהא ההטמעה אשר תהא.
אביא כאן את העיקר:
אביא כאן את העיקר:
- כל הדרישות חייבות לבוא משלב ה-MRD עם סעיפים, סעיף פר דרישה, ת-סעיף לתת-דרישה, וכל סעיף צריך להיות עם סמן ייחודי (נניח MRD-403-24-001, MRD זה המסמך, 403 זו הגרסה, 24 הסעיף ו-01 הוא תת-הסעיף). מומלץ לקפוץ בין מספרים בהפרש מסויים, למשל מ-01 ל-05, למקרה שמשהו ישכח.
- יש למפות כל דרישת השיווק (MRD) לדרישה של מהנדס המערכת (SysRD). לכן דרישות המערעת אמורות להיות:
SysRD-403-24-01 בהתאמה. אם יש יותר סעיפים כאן אפשר להוסיף בסוף a, b וכד'. - יש למפות כל דרישת מהנדס מערכת לדרישה של הפיתוח. שוב - אותו פורמט של מספרים.
- יש למפות כל דרישת מהנדס מערכת לדרישה של בדיקות. שוב - אותו פורמט של מספרים.
- מסמך הבדיקות יכלול קישור גם למהנדס המערכת וגם למסמכי הפיתוח.
- יש למפות את הבאגים למסמך הבדיקות.
- שום דרישה לאורך התהליך אינה הולכת לאיבוד.
- יש סטטוס עדכני לכל דרישה (בעיקר אם יש כלים שמגבים את זה): כמה באגים פתוחים, מה החומרה שלהם וכד'.
- אפשר לראות פר דרישה כמה באגים היו בה, האם זמני הבדיקות היו כפי שציפינו.
- יהיה אפשר לדעת בעתיד מה מצב כל דרישה (למסמך סיכום הבדיקות, או חקירה מהשטח).
אין תגובות:
הוסף רשומת תגובה