ידוע שניהול דרישות (Requirements) הוא חלק חשוב מכל פרוייקט תוכנה.

טעויות בניהול הדרישות עלולות להתבטא בעלויות תיקון גבוהות או אף "להרוג" את הפרוייקט.

 

איך מנוהלות הדרישות בפרוייקט שלכם?

האם יש מסמכי דרישות, וכיצד הם מנוהלים?

האם יש שיטות או כלים שימושיים ש"עושים את העבודה" בשבילכם?

 

אשמח לשמוע כמה עצות פרקטיות.

 

452 חברים בקהילה ואף אחד לא מנהל דרישות?

אנסח את השאלה אחרת: מה אתם עושים כשמישהו בא אליכם ומבקש שתשנו / תוסיפו משהו ב-feature?

 

במסמכים ולא בכלי יעודי לדרישות. המסמכים נמצאים תחת מערכת ניהול גרסאות.

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

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

תודה לכל המגיבים.

 

הבעיה עם שיטת המסמכים היא שקשה לעדכן אותם.

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

 

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

 

גנאדי, תוכל אולי לפרט קצת יותר על הנסיון שלכם עם ניהול דרישות ב- excel?

 

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

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

 

האם אתה חושב שכל התוכן של מסמכי הדרישות חשוב באמת או שיש כמות של פרטים שהם כבר בגדר פירוט ואפיון או דברים "גנריים"?

 

(נקודה טכנית - ב-excel שמנו בנוסף לכותרות של הדרישות, פירוט הסיכונים וכד', גם עותקים של כל המסמכים של הפרויקט.)

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

>> יותר פשוט לממש את ה-feature.

 

לא תמיד קל יותר לממש.

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

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

 

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

 

נראה שאתה צודק.

 

>> האם אתה חושב שכל התוכן של מסמכי הדרישות חשוב באמת או שיש כמות של פרטים

>> שהם כבר בגדר פירוט ואפיון או דברים "גנריים"?

 

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

הרבה פעמים חוזרים למסמך הדרישות כאשר מפתחים מתחלפים ורוצים ללמוד את ה-feature , למה הוא עשוי כך ולא אחרת, ואז הפירוט יכול לעזור.

 

>> (נקודה טכנית - ב-excel שמנו בנוסף לכותרות של הדרישות, פירוט הסיכונים וכד', גם

>> עותקים של כל המסמכים של הפרויקט.)

 

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

 

 

אנחנו מנהלים את הדרישות באמצעות MS Project.

למרות שאני לא מחובבי הכלי, נוח לנהל את תוכנית העבודה, תוצרים, סיכונים,הדרישות וכו' במקום אחד.

 

צטט: עדי אל 2008-02-27 22:46:42

אנחנו מנהלים את הדרישות באמצעות MS Project.

למרות שאני לא מחובבי הכלי, נוח לנהל את תוכנית העבודה, תוצרים, סיכונים,הדרישות וכו' במקום אחד.

תודה עדי.

MS Project הוא כלי מצויין לניהול לו"ז, אבל איך אפשר לנהל בו דרישות וסיכונים? 

 

 

 

שלום,

 

אנחנו מנהלים את הדרישות בכלי שאותו אנחנו מפתחים - Test Directory for Quality Center

 

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

 

היתרון עבורנו בעבודה עם הכלי (חוץ מהעובדה שכך אנחנו מראים שהכלי שימושי) הוא שהוא מספק קישור מאוד חזק בין הדרישות לבדיקות שלהן.

 

כך אפשר לבדוק את מצב האיכות של המוצר.

 

בנוסף, יש אצלנו מנהל פרוייקט שמאוד מקפיד כל איטרציה לוודא שכל הדרישות רשימות ומעודכנות (אנחנו עובדים בשיטת AGILE)

 

מקווה שעזרתי,

זיו בירר

על אף הכח הגדול שלו QC מאד מוגבל.

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

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

הקישוריות לבדיקות  ולבאגים (שחכת לציין, או של HP אין באגים ?) מאד נחמדה אלא שלחברות embedded למשל השימוש בהרצות אוטומטיות מאד לא שימושי, ולמנהל הבאגים יש תחליפים חינמיים טובים יותר.

 ובטח שכחתי עוד מגבלות.

QC הוא כלי נהדר אבל לא מתאים לכל אחד. 

הכל שאלה של תקציב - ישנם כלים ממשפחת PLM שייעודם ניהול דרישות לאורך כל חיי הפרוייקט. בתכלס מה שצריך זה שהדרישות ימוספרו, והמיספור לא ישתנה לאורך כל חיי הפרוייקט. כל מסמך דרישות צריך להכיל מטריצת כיסוי. למשל אם מפתח כתב מסמך DETAILED DESIGN, שניגזר ממסמך דרישות של מנהל מוצר, רצוי שיפרט בטבלה איך הוא מכסה כל דרישה של מנהל המוצר. אנשי הבדיקות ישתמשו בטבלה דומה לוודא שלכל דרישה יש כיסוי של TEST CASE.

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

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

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

עד עכשיו ה SVN לא אכזב אותנו בניהול גרסאות, גם במסמכים מורכבים.