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

מהי דרישה ?

מאמר זה שם דגש על כללי התמציתיות של דרישות.

רגע של עברית: מהי צורת המקור של פועל ?

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

מקור הצרות – צורות המקור של פעלים

דוגמה:

נקודה למחשבה: אם נוכיח שהמערכת מסוגלת לאגור את המיקומים פעם אחת אבל נכשלת בכך 99 פעמים – האם עמדנו בדרישה ? ברור שלא: הדרישה איננה על "מסוגלות" המערכת לאגור, אלא על עצם האגירה ! לכן הדרישה צריכה להיות:

עוד רגע של עברית: מהי פסוקית?

פסוקית תנאי, למשל, היא פסוקית המתחילה ב: אם…, בתנאי ש…,  במקרה ש…,  לא… אלא אם כן…

גם בפסוקו של יום מפרידים פסוקיות…

1. תבטא צורך יחיד
2. שכל תנאי או מגבלה בה יופיע כפסוקית נפרדת

מי צריך להגדיר דרישות?

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

רקע לניהול דרישות

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

לכן דרישה צריכה להיות אמירה מדויקת, תמציתית, שניסוחה חד וברור. ערפול בניסוח הוא מתכון לצרות: האם הדרישה הובנה ע"י הספק בדיוק כפי שהתכוון המזמין ? אם לא – הוויכוחים יהיו אינסופיים.

איך יוצרים דרישה מדויקת ? כללי העבודה בקטגורית "דיוק (Precision)" יעזרו לנו ליצור דרישות כאלה.

המסתורין של שמות העצם

יידוע שמות עצם: השתמש אך ורק בשמות עצם מיוּדעים (מלווים בה"א הידיעה). שימוש במונחים ללא יידוע מוביל לריבוי משמעויות.

דוגמה:

לשון פעיל: השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה. שימוש בלשון סביל מקשה על אימות הדרישה.

על המחבר, אלון מודעי

מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.

רקע

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

תכונות של דרישה "טובה" (המשך)

ברת-אימות

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

נכונה

• שהטווח הקביל של הביצועים מבחינת הזרימה הוא 10± ליטר לשנייה
• ש-30 דקות הוא מינימום הביצועים הקביל מבחינת משך הזמן

תואמת למוסכמות

ובפירוט:

מה למדנו ?

מה הלאה ?

רקע

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

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

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

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

משתמשי כללי "המדרשה לדרישות טובות" חווים:

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

תכונות של דרישה "טובה"

דרישה "טובה" מוגדרת ע"י התכונות הבאות:

חיונית (Necessary)

כל דרישה צריכה להיות חיונית.

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

• אם ניתן לפתור את הבעיה / לענות על הצורך ללא הדרישה – הדרישה לא חיונית.
• אם לא ניתן להסביר את הסיבה לדרישה – הדרישה לא חיונית.

דוגמא:

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

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

זוהי דרישה המגבילה את המוצר להשתמש באנרגיה חשמלית (ולא, למשל, באנרגיה סולארית).

בלתי תלויה ביישום (Implementation-Independent)

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

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

דוגמא:

במקום לבטא צורך – הדרישה קובעת את הפתרון: רמזורים. אבל מה הצורך כאן ?

צורך הוא משהו מעולם הבעיה. להלן דוגמא של צורך:

זהו צורך אמיתי: שכלי הרכב החוצים את הצומת לא יאולצו להמתין יותר משתי דקות. זה לא מכתיב שום פתרון.

חד משמעית (Unambiguous)

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

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

דוגמא:

דוגמא:

הדרישה היא רב משמעית: האם כל זמן שהוא יהיה קביל ? האם הבהוב רגעי של השעה יהיה מספק ?

רוב הסיכוי שכוונת הכותב הייתה שרוצים תצוגה רציפה של השעה הנוכחית. אם נספק תצוגה רציפה של השעה "10:00AM", נוכל לטעון שעמדנו בדרישה. אבל בפרוש לא נתנו מענה לצורך.

לעומת זאת:

להיות:

שימו לב שהזמן_הנוכחי הוא מונח שצריך להיות מוגדר במילון המונחים, מכיוון שייתכנו מספר פירושים למונח הכללי "זמן":

כללים לכתיבת דרישה "טובה"

זה הזמן לציין כלל חשוב לכתיבת דרישות:

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

מה למדנו ?

עשינו הכרה עם 3 מאפיינים של דרישה "טובה" והם: שהדרישה תהיה חיונית, בלתי תלויה ביישום, וחד משמעית.

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

מה הלאה ?

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

על המחבר, אלון מודעי

מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.

י יודע מהו הנושא המככב בכל תחקיר על פרויקט שנכשל?……מי שניחש שהנושא קשור לניהול ופיתוח דרישות – צדק! זהו כמובן לא הנושא היחיד, אך בהחלט נושא שחוזר בתדירות גבוהה. מסתבר שלהבין את דרישות הלקוחות, ולנהל אותן במהלך מחזור הפיתוח זהו נושא סבוך וקשה; הסיבות לכך הן רבות. בהיעדר ניהול דרישות שיטתי, ייתכן והמוצר או השירות שתפתחו לא יממש את כל הדרישות שהלקוחות בקשו מכם. בהיעדר תשתית טובה לניהול דרישות, שינויים שקורים במהלך הפרויקט, כולל שינויים בדרישות יכולים להביא להתבדרות של הפרויקט.

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

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

הטיפול בדרישות, על פי מודל ה-CMMI מכוסה על ידי שני תחומי תהליך:

1) ניהול דרישות

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

2) פיתוח דרישות

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

מאמר זה דן בנושא ניהול הדרישות בלבד. נושא פיתוח הדרישות יטופל במאמר אחר.

ניהול דרישות שיטתי על פי מודל ה-CMMI:

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

חמש הפרקטיקות החיוניות לניהול דרישות שיטתי

חמש הפרקטיקות בנושא ניהול שיטתי, מוצגות בדיאגרמה שלהלן, ומפורטות בהמשך:

נושא מאתגר אבל….

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

==

האם הנושא מטופל בארגונכם?
איזה גוף אחראי לכך?
אשמח לשיתוף כיצד מנוהלות הדרישות בארגונכם; טוב? פחות טוב?
אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן