דרישה: תכונה של המוצר/השירות, המהווה תנאי לקבלה ע"י המזמין |
מאמר זה שם דגש על כללי התמציתיות של דרישות.
צורות המקור בעברית הן צורות המתארות פעולות בצורה מופשטת, ללא ציון זמן ולעיתים גם ללא גוף. למשל: "לשדר", "לחשב", "ליירט". צורה זאת מופשטת מדי עבור דרישה ומוסיפה מילים מיותרות.
כלל תמציתיות מס 1: המנע משימוש מיותר בצורת המקור של פעלים. |
דוגמה:
מערכת-הנשק תהיה מסוגלת לאגור את מיקומי כל התחמושות |
נקודה למחשבה: אם נוכיח שהמערכת מסוגלת לאגור את המיקומים פעם אחת אבל נכשלת בכך 99 פעמים – האם עמדנו בדרישה ? ברור שלא: הדרישה איננה על "מסוגלות" המערכת לאגור, אלא על עצם האגירה ! לכן הדרישה צריכה להיות:
מערכת-הנשק תאגור את מיקומי כל התחמושות |
פסוקית היא משפט המשמש כאחד מחלקיו התחביריים של משפט אחר. קיימים מספר סוגי פסוקיות לפי תפקידיהן:
|
|
פסוקית תנאי, למשל, היא פסוקית המתחילה ב: אם…, בתנאי ש…, במקרה ש…, לא… אלא אם כן…
דוגמה:
משואת-הניווט תספק נתונים מורחבים ל-8-20 מטר דיוק לפחות 99.7% הפעמים לכל משתמש-ימי במהלך תמרון נמל |
# | שם הכלל | הסבר |
1 | ללא צורות מקור | המנע משימוש מיותר בצורת המקור של פעלים |
2 | הפרדת פסוקיות | השתמש בפסוקית תנאי נפרדת לכל תנאי |
האם אתם מודעים לכללים אלה לכתיבת דרישות? האם מידע זה תורם לכם? חשוב לכם? שיתופים יתקבלו בברכה, כאן..בתיבה למטה.
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
דרישה: תכונה של המוצר/השירות, המהווה תנאי לקבלה ע"י המזמין |
למוצר או שירות תהיינה הרבה מאד תכונות, אך לא כולן תהיינה תנאי לקבלה ע"י המזמין, ולכן לא כולן תהיינה דרישות. יש להיזהר, במיוחד בעבודה עפ"י חוזה, לא רק לתת מענה לכל הדרישות, אלא גם שלא להתחייב לתכונות שאינן דרישות.
לכן דרישה צריכה להיות אמירה מדויקת, תמציתית, שניסוחה חד וברור. ערפול בניסוח הוא מתכון לצרות: האם הדרישה הובנה ע"י הספק בדיוק כפי שהתכוון המזמין ? אם לא – הוויכוחים יהיו אינסופיים.
איך יוצרים דרישה מדויקת ? כללי העבודה בקטגורית "דיוק (Precision)" יעזרו לנו ליצור דרישות כאלה.
יידוע שמות עצם: השתמש אך ורק בשמות עצם מיוּדעים (מלווים בה"א הידיעה). שימוש במונחים ללא יידוע מוביל לריבוי משמעויות.
דוגמה:
המערכת תספק תצוגת זמן |
מושא הדרישה (תצוגת זמן) צריך להיות מיודע כדי שיהיה חד-משמעי:
המערכת תציג את השעה-הנוכחית |
לשון פעיל: השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה. שימוש בלשון סביל מקשה על אימות הדרישה.
דוגמה:
זהות הלקוח תיבדק |
נטל האימות מונח על כתפי הגורם המבצע. אם המבצע אינו מזוהה במפורש, לא ברור מי צריך לבצע את הפעולה. לכן יש לכתוב:
מערכת-ניהול-החשבונות תוודא את זהות-הלקוח |
הרכב ינגן קבצי שמע מהתקני USB. |
מערכת השמע תנגן קבצי שמע מהתקני USB. |
הכספומט יציג את מצב החשבון. |
הסיכוי לטעות בפרשנות של המונח "מצב החשבון" הוא גבוה. השימוש במילון מאפשר לקורא לדעת בדיוק למה התכוון הכותב כשבחר מלה מסוימת:
הכספומט יציג את מצב-החשבון. |
מצב-החשבון | אוסף נתונים אודות חשבון הבנק של הלקוח, המורכב מהפריטים הבאים:
|
המאזניים הביתיים יציגו את המשקל עד לדיוק של בערך 10 גרם. |
המאזניים הביתיים יציגו את המשקל ± 10 גרם. |
למעגל-המודפס תהיה טמפרטורת אחסנה של לא יותר מ-30 מעלות |
לכל מספר יש לציין במפורש את היחידות בהן הוא נמדד:
למעגל-המודפס תהיה טמפרטורת אחסנה של לא יותר מ-30 מעלות צלזיוס |
מערכת-נתוני-הטיסה תהיה בדרך כלל מקוונת |
תארי פועל מעורפלים עלולים להוביל לדרישות רב משמעיות, שלא ניתן לאמת:
"בדרך כלל", "בערך", "מספיק", "באופן טיפוסי"
למערכת-נתוני-הטיסה תהיה זמינות של לפחות xx% במשך של לפחות yy שעות ברציפות |
מערכת-נתוני-הטיסה תציג את נתוני-המעקב עבור כלי טיס רלבנטיים |
מערכת-נתוני-הטיסה תציג את נתוני-המעקב עבור כל כלי-טיס הנמצא במרחק של 20 ק"מ או פחות מהמנחת |
ה-GPS יציג את מיקום-המשתמש, ככל שירשה המקום |
ה-GPS יציג את מיקום-המשתמש. |
Sוגמה:
הכספומט יציג את מספר חשבון הלקוח, היתרה וכן הלאה |
|
# | שם הכלל | הסבר |
1 | יידוע שמות עצם | השתמש בשמות עצם מיוּדעים (מלווים בה"א הידיעה) |
2 | לשון פעיל | השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה |
3 | נושא הדרישה | הקפד שנושא הדרישה יהיה תואם לרמה המוצר או השירות אליה הדרישה מתייחסת |
4 | מונחים מוגדרים | השתמש אך ורק במונחים המוגדרים במילון (Glossary) |
5 | כַּמָּתים | המנע מכַּמָּתים (Quantifiers) לא מדויקים |
6 | יחידות | השתמש ביחידות מוגדרות ומפורשות לציון כמויות |
7 | תואר הפועל | המנע משימוש בתארי פועל מעורפלים |
8 | תואר השם | המנע משימוש בתארי שם |
9 | פסוקיות לוואי | המנע משימוש בפסוקיות לוואי מעורפלות |
10 | פסוקיות פתוחות | המנע משימוש בפסוקיות פתוחות |
אם כל דרישה באוסף הדרישות מקיימת את כל התכונות המאפיינות דרישה "טובה" – האם זה אומר שאוסף הדרישות כולו הוא "טוב" ? נשמח לתשובה בתיבה למטה
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
תכונה | הדרישה צריכה להיות |
חיונית | הכרחית |
בלתי-תלויה ביישום | מבטאת את הצורך, לא את אופן מתן המענה |
חד-משמעית | בעלת פרשנות אחת בלבד |
שלמה | עומדת בזכות עצמה |
| ייחודית | מבטאת רעיון יחיד וברור |
| ישימה | ברת יישום |
כמו כן אנו מכירים שני כללים חשובים העוזרים בניסוח דרישות "טובות":
| דרישות נכתבות בצרוף מילון מונחים מפורט. במילון מרוכזות במקום אחד, לפי סדר אלפאבתי, ההגדרות של כל המונחים שבשימוש על פני כל הדרישות. |
הקפד שהדרישה תהיה מורכבת ממשפט אחד, הבנוי על פי כללי התחביר: תנאי + נושא + נשוא + מושא [ + סייג] |
בסיום פרק זה נכיר את שלושת המאפיינים האחרונים של דרישה "טובה".
המוצר יתופעל באופן ידידותי למשתמש. |
במקום זאת נציע למזמין ניסוח כדלקמן:
המוצר יאפשר למשתמש שקיבל הדרכה בת חצי יום לבצע בהצלחה כל אחת מיכולות המוצר תוך 30 שניות. |
על ניסוח כזה אפשר להגיע להסכמה ואז גם קל לאמת את הדרישה.
תחנת השאיבה תשמור על זרם מים בעוצמה של 120 ליטר לשנייה למשך 30 דקות. |
תחנת השאיבה תשמור על זרם מים בעוצמה של ±10120 ליטר לשנייה למשך לפחות 30 דקות. |
הלהקה תנגן שירים בלקניים ומזרחיים. |
התזמורת תופיע במהלך כל הערב. |
אנסמבל "עורבא פרח" ינגן שירים בלקניים ומזרחיים. |
התזמורת תופיע במהלך כל הערב. |
התכונה | הדרישה צריכה להיות |
|---|---|
חיונית | הכרחית |
בלתי-תלויה ביישום | מבטאת את הצורך, לא את אופן מתן המענה |
חד-משמעית | בעלת פרשנות אחת בלבד |
שלמה | עומדת בזכות עצמה |
ייחודית | מבטאת רעיון יחיד וברור |
ישימה | ברת יישום |
ברת-אימות | ניתן לאמת אותה |
נכונה | ביטוי נכון ומדויק של צרכי בעלי העניין |
תואמת למוסכמות | מתיישבת עם סטנדרטים ומוסכמות ארגוניים |
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
תכונה | הדרישה צריכה להיות |
חיונית | הכרחית |
בלתי-תלויה ביישום | מבטאת את הצורך, לא את אופן מתן המענה |
חד-משמעית | בעלת פרשנות אחת בלבד |
דרישות נכתבות בצרוף מילון מונחים מפורט. במילון מרוכזות במקום אחד, לפי סדר אלפאבתי, ההגדרות של כל המונחים שבשימוש על פני כל הדרישות. |
בפרק זה נפגוש עוד מספר מאפיינים של דרישה "טובה" ועוד כמה כללי עבודה. שימו לב שחלק מהכללים נוגעים לשפה ולתחביר. עוד על כך – בהמשך.
פעולה | הסבר |
גזירה | החלפה של דרישה בסט דרישות מפורטות וספציפיות יותר, השקולות ביחד לדרישה המקורית. |
הקצאה | שיוך דרישה של מוצר או שירות לאחד או יותר ממרכיביו. |
אימות | פעולה המוכיחה שהדרישה מתקיימת במוצר או בשרות. |
| תיקוף | פעולה המתבצעת בתנאים היעודיים של המוצר או השרות, ומוכיחה שהמוצר או השרות עונה לצרכים. |
עקיבות | קישור של דרישה לפריטי מידע אחרים, כגון: דרישת המקור, פעולת אימות, מטלת מימוש. |
דרישה "טובה" מוגדרת ע"י התכונות הבאות:
פעמון האזעקה יצלצל למשך לא יותר מ-20 דקות |
הדרישה הזאת מסתמכת על הכותרת שמעליה כדי להבין על מה מדובר. זה לא קביל. במקום זאת צריך להיות:
פעמון האזעקה פעמון האזעקה יצלצל למשך לא יותר מ-20 דקות |
מערכת הבקרה תסגור את שסתום כניסת המים עד שהטמפרטורה תרד ל-850 צלזיוס ואז תפתח אותו. |
1. מערכת_הבקרה תסגור את שסתום_כניסת_המים, בתוך פחות מ-3 שניות, כאשר טמפרטורת המים בדוד גבוהה מ-850 צלזיוס. 2. מערכת_הבקרה תפתח את שסתום_כניסת_המים, בתוך פחות מ-3 שניות, כאשר טמפרטורת המים בדוד נמוכה מ-850 צלזיוס. |
למוצר תהיה אמינות של 100%. |
אמינות של 100% כמעט שאיננה ברת-השגה. אם נחשוב קדימה לאימות הדרישות – איך נוכיח אמינות של 100% ? וגם לו יכולנו לבנות מערכת כזאת – האם נוכל להרשות זאת לעצמנו מבחינת העלות ?
השוו לעומת זאת את הדרישה שלהלן:
למוצר תהיה אמינות גדולה או שווה ל-98%. |
הקפד שהדרישה תהיה מורכבת ממשפט אחד, הבנוי על פי כללי התחביר: תנאי + נושא + נשוא + מושא [ + סייג] תנאי – תבנית המציינת באילו תנאים הדרישה צריכה להתקיים, למשל: "כאשר טמפרטורת המים בדוד נמוכה מ-C850" נושא – תבנית המתארת את מבצע הפעולה שבדרישה, למשל: "מערכת הבקרה" נשוא – תבנית המתארת את הפעולה המתבצעת, למשל: "תפתח" מושא – תבנית המתארת את היישות שעליה הפעולה מתבצעת, למשל: "את שסתום כניסת המים" סייג – תבנית אופציונלית המתארת מיגבלה כלשהי על ביצוע הפעולה, למשל: " בתוך פחות מ-3 שניות" |
כאשר טמפרטורת המים בדוד נמוכה מ-C850, מערכת_הבקרה תפתח את שסתום_כניסת_המים בתוך פחות מ-3 שניות. |
בצורה כזאת מתקבלת דרישה שיש בה משפט אחד פשוט, המביע מחשבה אחת.
אוסף התכונות של דרישה "טובה" שבנינו עד עתה הוא:
תכונה | הדרישה צריכה להיות |
חיונית | הכרחית |
בלתי-תלויה ביישום | מבטאת את הצורך, לא את אופן מתן המענה |
חד-משמעית | בעלת פרשנות אחת בלבד |
שלמה | עומדת בזכות עצמה |
| ייחודית | מבטאת רעיון יחיד וברור |
| ישימה | ברת יישום |
צברנו גם שני כללים לכתיבת דרישה "טובה", והם:
דרישות נכתבות בצרוף מילון מונחים מפורט. במילון מרוכזות במקום אחד, לפי סדר אלפאבתי, ההגדרות של כל המונחים שבשימוש על פני כל הדרישות. |
הקפד שהדרישה תהיה מורכבת ממשפט אחד, הבנוי על פי כללי התחביר: תנאי + נושא + נשוא + מושא [ + סייג] |
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
דרישות הן אמצעי תקשורת בין הצד המזמין לבין הצד המספק, באשר לתכולת המוצר או השרות המסופק. דרישות טקסטואליות אינן פורמאליות, ולכן מעצם מהותן הן חשופות לבעיות רבות של הבנה ופרשנות. עם זאת, דרישות טקסטואליות נמצאות בשימוש נרחב מאד במקומותינו.
האיור שלהלן ממחיש השתלשלות עניינים טיפוסית כתוצאה מחוסר הגדרת דרישות מדוייקת למוצר תוכנה. דברים דומים קורים גם במוצרים או שירותים מסוגים אחרים.
בפינה זאת ניגע בכל פעם בחלק מהכללים העוזרים למזער את הבעייתיות הגלומה בדרישות הכתובות בטקסט. בהדרגה, נצבור אוסף כללי עבודה שהשימוש העקבי בו ישיג את המטרות הבאות:
משתמשי כללי "המדרשה לדרישות טובות" חווים:
דרישה "טובה" מוגדרת ע"י התכונות הבאות:
כל דרישה צריכה להיות חיונית.
הרציונאל: דרישה שכוונתה מובעת בדרישות אחרות יוצרת סכנה של סתירה. אין סיבה להביע משהו יותר מפעם אחת. כמו כן, דרישה שמצטטת עובדה מטעה את הקורא לחשוב שהוא אמור לספק משהו. בנוסף:
דוגמא:
| המוצר המסופק יצרוך חשמל בכל מהלך פעולתו |
מה הסיבה לדרישה הזאת ? למי היא נחוצה ? האם קיים בעל עניין למוצר שמאד מעוניין שהוא יצרוך חשמל ? ואם המוצר לא יצרוך חשמל בכל משך פעולתו אלא רק בחלק – האם מישהו יהיה בלתי מרוצה? ואם נסיר את הדרישה הזאת – האם זה ישנה משהו בפתרון ? זאת דוגמא לדרישה מיותרת.
אם נפעיל את כישורי הניחוש שלנו, יתכן שנגיע למסקנה שהדרישה בעצם התכוונה להיות:
| המוצר יפעל על אנרגיה חשמלית |
זוהי דרישה המגבילה את המוצר להשתמש באנרגיה חשמלית (ולא, למשל, באנרגיה סולארית).
דרישה צריכה לבטא את הצורך ולא את אופן מתן המענה. כל פתרון שייבחר צריך לתת מענה לדרישה.
הרציונאל: כאשר בדרישה מובע אופן היישום – הקורא צריך לנחש ממנו את הצורך האמיתי. ואם לא ברור הצורך בנקודה מסוימת, החלחול שלו הלאה למרכיבי הפתרון יהיה לקוי.
דוגמא:
| להכוונת התנועה בצומת יש להשתמש במערכת רמזורים |
במקום לבטא צורך – הדרישה קובעת את הפתרון: רמזורים. אבל מה הצורך כאן ?
צורך הוא משהו מעולם הבעיה. להלן דוגמא של צורך:
| מערכת בקרת התנועה תאפשר לכלי רכב הנוסעים ממזרח למערב לחצות את הצומת עם 2 דקות המתנה לכל היותר. |
זהו צורך אמיתי: שכלי הרכב החוצים את הצומת לא יאולצו להמתין יותר משתי דקות. זה לא מכתיב שום פתרון.
לדרישה צריכה להיות פרשנות אחת בלבד, המשותפת לכל הגורמים הרלבנטיים.
הרציונאל: כאשר הדרישה ניתנת לפרשנות במספר דרכים, היא מפסיקה להיות כלי תקשורת. הסכנה היא שהקורא יבין ויספק כהבנתו בעוד שהכותב התכוון למשהו אחר.
דוגמא:
דוגמא:
| בפאנל הקדמי תהיה תצוגת זמן |
הדרישה היא רב משמעית: האם כל זמן שהוא יהיה קביל ? האם הבהוב רגעי של השעה יהיה מספק ?
רוב הסיכוי שכוונת הכותב הייתה שרוצים תצוגה רציפה של השעה הנוכחית. אם נספק תצוגה רציפה של השעה "10:00AM", נוכל לטעון שעמדנו בדרישה. אבל בפרוש לא נתנו מענה לצורך.
לעומת זאת:
להיות:
| בפאנל הקדמי יוצג באופן רציף הזמן_הנוכחי |
שימו לב שהזמן_הנוכחי הוא מונח שצריך להיות מוגדר במילון המונחים, מכיוון שייתכנו מספר פירושים למונח הכללי "זמן":
מונח | הסבר המונח |
הזמן_הנוכחי | השעה הנוכחית לפי שעון ירושלים, בפורמט "HH:MM 24 שעות" |
זה הזמן לציין כלל חשוב לכתיבת דרישות:
דרישות "טובות" נכתבות בצרוף מילון מונחים מפורט (Glossary). במילון מרוכזות במקום אחד, לפי סדר אלפבתי, ההגדרות של כל המונחים שבשימוש על פני כל הדרישות. |
אי הקפדה על כלל זה תביא לכך שכל מיני קטעי הגדרות, הסברים, ואפילו הגיגי לב שונים של הכותב, יהיו "מרוחים" ללא אבחנה על פני הדרישות ויקשו עד מאד את הבנתן.
עשינו הכרה עם 3 מאפיינים של דרישה "טובה" והם: שהדרישה תהיה חיונית, בלתי תלויה ביישום, וחד משמעית.
כמו כן למדנו כלל חשוב העוזר ביצירת דרישות "טובות": שימוש במונחים סטנדרטיים, המוגדרים במילון מונחים מצורף, והקפדה על כך שהסברים יופיעו בהגדרת המונח ולא בתוך הדרישה.
בפינה הבאה של "המדרשה לדרישות טובות" נכיר מספר מאפיינים נוספים לדרישה טובה ונלמד כמה כללי עבודה חדשים.
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
י יודע מהו הנושא המככב בכל תחקיר על פרויקט שנכשל?……מי שניחש שהנושא קשור לניהול ופיתוח דרישות – צדק! זהו כמובן לא הנושא היחיד, אך בהחלט נושא שחוזר בתדירות גבוהה. מסתבר שלהבין את דרישות הלקוחות, ולנהל אותן במהלך מחזור הפיתוח זהו נושא סבוך וקשה; הסיבות לכך הן רבות. בהיעדר ניהול דרישות שיטתי, ייתכן והמוצר או השירות שתפתחו לא יממש את כל הדרישות שהלקוחות בקשו מכם. בהיעדר תשתית טובה לניהול דרישות, שינויים שקורים במהלך הפרויקט, כולל שינויים בדרישות יכולים להביא להתבדרות של הפרויקט.
מחזור החיים של פיתוח מוצרים ושירותים מתחיל בהגדרת הדרישות. "כמו שנציע את המיטה כך נישן עליה". כלומר, אופן הבנת הדרישות וניהולן משפיע בצורה משמעותית על התוצר הסופי.
מאמר זה מנסה להתמודד עם הנושא באמצעות תהליך שיטתי, בהנחיית מודל ה-CMMI שמטפל בין היתר בנושא הנדסת מערכת.
הטיפול בדרישות, על פי מודל ה-CMMI מכוסה על ידי שני תחומי תהליך:
זהו תהליך ניהולי, המטפל בתהליך הניהול האדמיניסטרטיבי של דרישות המוצר או השירות ורכיביהם. תהליך ניהול הדרישות מתחיל מקבלת דרישות מהלקוח/ות ומכל בעלי העניין שעשויים לתרום הגדרה של צרכים ו/או אילוצים לגבי המוצר. בעלי העניין יכולים להיות גם גופי רגולציה, גופים מוסדיים שונים בארגון ועוד. הלקוחות מגדירים דרישות במונחי מה נדרש לעשות (למשל: ביצועים, תכונות); כמו כן, מטפל התהליך בשינויים בדרישות.
זהו תהליך הנדסי, המתרגם את דרישות הלקוח לדרישות הנדסיות; מחלק את הדרישות לדיסציפלינות (למשל: חומרה/תוכנה) או תתי מערכות. לאחר שחילקנו דרישות לדיסציפלינות, כל דיסציפלינה אחראית על מימוש הדרישות שבאחריותה. לפעמים אותה דרישה תבוצע על ידי כמה דיסציפלינות. תהליך התכן מתחיל מהדרישות ההנדסיות.
מאמר זה דן בנושא ניהול הדרישות בלבד. נושא פיתוח הדרישות יטופל במאמר אחר.
תהליך ניהול דרישות שיטתי דואג שלאורך כל מחזור הפיתוח יהיה אוסף מוגדר ומאושר של דרישות. כמו כן תהיה הלימה בין תוכניות העבודה של הפרויקט ומוצרי הביניים המופקים בתהליך לדרישות המוצר. אין הכוונה שכל הדרישות יהיו מוגדרות בתחילת הדרך. בהחלט אפשרי לפתח במודל איטרטיבי או אג'ילי. במקרים אלה כל שייאמר להלן, ניתן להתאמה כשמדובר באיטרציות, או במנות אג'יליות.
חמש הפרקטיקות בנושא ניהול שיטתי, מוצגות בדיאגרמה שלהלן, ומפורטות בהמשך:
עשה | ואם לא תעשה… | |
הבנת הדרישות | הגדר מראש מיהם ספקי הדרישות המקובלים ואת הקריטריונים לקבלת הדרישות; השג הבנה מספקי הדרישות לגבי המשמעות של הדרישות; נתח את הדרישות וודא עם הלקוח שהבנת אותן. השג אישור מהלקוח לדרישות הבסיס ובכך רתום אותו לפרויקט המתהווה. | בהיעדר הגדרה ברורה ממי מקבלים דרישות, יש חשש מקבלת דרישות שאין צורך לבצען, או שיש סתירה בין ספקי הדרישות. במידה ואין אישור מהלקוח שדרישותיו הובנו, אין ערובה לכך שהמסר עבר במדויק; |
השגת מחויבות לדרישות | השג מחויבות מכל בעלי העניין בארגון לפיתוח המוצר או השירות בהתאם לדרישות. במקרים רבים, האישור יושג לאחר הבנה עמוקה של משמעות יישום כל הדרישות, וקבלת המשאבים הנדרשים. | אי אפשר להצליח ולסיים פיתוח מוצר או שירות שעומד בדרישות הלקוח בהיעדר מחויבות מגוף הפיתוח לפתח את המוצר בהתאם לדרישות. היעדר מחויבות מצד הפיתוח יכול לנבוע מאי הקצאת המשאבים הנדרשים. |
ניהול שינויים לדרישות | הבן את משמעות השינוי וההשפעה שלו על הפרויקט מבחינת משאבים ולו"ז וכן מבחינת ההשפעה שיש לשינוי בדרישות מסוימות, על דרישות אחרות, וקבל החלטה מושכלת אם וכיצד לטפל בשינוי. | קבלה פזיזה של שינויים בדרישות מבלי להבין את משמעותם, תגרום להתבדרות הפרויקט וחוסר שביעות רצון של הלקוחות ושאר בעלי העניין. |
ניהול עקיבות דו-כיוונית | נהל עקיבות דו כיוונית בין הדרישות המקוריות לדרישות ברמות נמוכות יותר, ובין הדרישות למוצרי ביניים של תהליך הפיתוח, עד לבדיקות המאשרות שכל הדרישות מומשו ונבדקו. | בהיעדר ניהול עקיבות קשה לדעת אם אכן כל הדרישות מומשו. כמו כן, במקרה של שינויים בדרישות מסוימות קשה לדעת במדויק על מה ישפיע השינוי. |
הלימה בין הדרישות לתוכנית העבודה | במהלך כל התנהלות הפרויקט, בדוק שתוכניות העבודה אכן ממשות את כל הדרישות, לפי אבני הדרך שבתוכנית. כלומר, שיש הלימה בין אבני הדרך והתכולה שתוכננה להיות מוכנה בכל אבן דרך. במידה ומצאת סטייה, עדכן את התכנית בהתאם (באמצעות ניהול השינוי). | עלולות להיווצר במהלך הפרויקט אי התאמות בין דרישות הלקוח/ות ותוכנית העבודה לחילופין, אי התאמות שנמצאות יכולות להיות מטופלות בצורה שאינה לוקחת בחשבון את השפעות השינוי. כתוצאה מכך, עלולים להיווצר פיגורים בלו"ז, או שיסתבר שהפרויקט לא ממש את התכולה המובטחת. |
בארגונים לא מעטים מצאתי שנושא ניהול ופיתוח הדרישות הוא "תפוח אדמה לוהט", שמעדיפים להעביר אותו מיד ליד ולדחות את הטיפול בו, עד ש…ימוסדו תהליכים אחרים, או יהיה תקציב מיוחד, או שמחכים לשינוי ארגוני שיגדיר פונקציה של הנדסת מערכות, או שיגדירו את האחריות לנושא בתפר שבין מנהל הפרויקט למנהל התוכנית, … ועוד כהנא וכהנא סיבות. ובינתיים – מתחילים לטפל בנושאים אחרים כמו ניהול בדיקות. קשה מאד לטפל בנושאים הקשורים לפיתוח מאמצע או מסוף הדרך. יתרה מזאת, תנאי לניהול בדיקות טוב הוא ניהול דרישות טוב! המלצתי – גשו ישר לעניין ! התחילו מההתחלה. בהצלחה!
==
האם הנושא מטופל בארגונכם?
איזה גוף אחראי לכך?
אשמח לשיתוף כיצד מנוהלות הדרישות בארגונכם; טוב? פחות טוב?
אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן
