ניהול דרישות

מבוא

ניהול דרישות – Requirements  Management הוא מהיסודות החשובים של ניהול תוכנה ומערכות IT. אין כמעט פרויקט או תהליך פיתוח של מוצר שלא מתחיל (צריך להתחיל!) בהגדרה ברורה של הדרישות מהמערכת.

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

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

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

יש להבחין בין שלושה סוגים שונים (לפחות) של "ניהול דרישות":

1.       דרישות-על ברמת תכנית עבודה שנתית (תע"ש), שמטרתן לסייע בתכנון שנתי כולל ותקציב יחידת IT. המונח באנגלית הוא – Demands. דרישות אלה מתמקדות בתכנון השנתי ובתקציב. למידע נוסף על ניהול דרישות תע"ש, ראה קיט תוכנית עבודה שנתית בכרך ניהול/ניהול המחשב וגם במודול תע"ש במערכת לניהול IT (My_IT) המתלווה למפת"ח מהדורה 8 ומעלה.

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

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

 

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

אין אלה עולמות נפרדים וברור שיש קשר הדוק בין השלושה. למשל, דרישות תע"ש (מס' 1) מתפרקות, בין השאר, לדרישות לפיתוח ושכתוב מערכת (מס' 3) ולדרישות תחזוקה שוטפות (מס' 2). או כדוגמא נוספת, דרישות שוטפות (מס' 2) מנותבות, בחלקן, לדרישות מערכת (מס' 3) ו"נספרות" בתוך דרישת-על מסוימת כמסגרת תקציבית בתכנית העבודה השנתית (מס' 1).

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

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

משולש ניהול הדרישות

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

 

איור 1: "משולש הדרישות"

 

סוגי דרישות

דרישות-על (תע"ש)

האיור הבא ממחיש את הסוג הראשון של דרישות - תכנית עבודה שנתית (תע"ש).

 

איור 2: ריכוז דרישות-על בתכנית עבודה שנתית

 

ליד כל מערכת או פרויקט המתוכננים לביצוע במהלך שנת העבודה (התקציב) הבאה, רושמים 2-3 דרישות-על שמבוקש שתתבצענה בשנה זו, כגון:

 ·         הסבת בסיס הנתונים של המערכת (הגירת המערכת לבסיס נתונים חדש), כולל טיוב נתונים

 ·         הוספת מחולל דו"חות ושיפור הדו"חות הקיימים

 ·         שיפור הממשקים עם מערכות: X, Y, Z

 ·         הוספת קבוצות משתמשים חדשות (תמיכה ביחידה ארגונית נוספת)

 ·         שדרוג אבטחת המערכת לעמידה בתקן אבטחה XXX

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

 ·         תחזוקה שוטפת.

 

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

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

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

דרישות שוטפות

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

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

 ·         קלט ממערכות ממוחשבות, בראשן מערכות CRM וניהול תקלות,

 ·         שינויי חוק ורגולציה, כולל נורמות סקטוריאליות וחוקת הארגון,

 ·         שינויי תשתית המחייבים שינויים במערכת המידע (הסבות),

 ·         הצעות ורעיונות לשיפור, ייעול ו"טיפול מונע" של יחידת IT עצמה (מתחזקי המערכת),

 ·         יוזמות של משתמשים מובילים ומנהלים עסקיים בארגון,

 

לדרישות אלה ניתן גם לקרוא בקשות לשינויים ושיפורים - שו"ש (Change Requests). דרישות אלה הן, מטבען, בלתי ממוינות ויש להשקיע מאמץ לא מבוטל במיונן וסידורן לפי מאפיינים שונים, כגון:

 ·         המערכת הרלוונטית – The Destination System

 ·         בעל התפקיד ו/או המחלקה הרלוונטית ב- IT אליהם יש להפנות את הדרישה

 ·         רמת העדיפות העסקית או הדחיפות – הלו"ז הנדרש

 ·         היקף ההשקעה הנדרשת

 ·         רמת הסיכון, רגישות והשלכות – Impact Analysis

 ·         עלות / תועלת. הערכה כוללת של התועלת מול ההוצאה.

 

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

תחזוקה שוטפת

בתת-קבוצה זו כלולות כל הדרישות/בקשות לשינויים שאינן סובלות דיחוי ויש לבצען בהקדם. חיוני שיהיה בארגון נוהל הכנסת שינויים ברור ומחייב, כולל יכולת חזרה (Rollback / Fallback) והפרדה ברורה בין פיתוח לייצור. רישום כרונולוגי מסודר של כל השינויים, תוך שימוש בגלופת טופס שינויים מובנית, הוא דרישה בסיסית שאין לוותר עליה. צעד נוסף, הוא שילוב של כלי ממוחשב לניהול השינויים ומעקב (Log)שינויים היסטורי. צעד נוסף הוא שמירה על תיעוד עדכני של המערכת, היינו רישום כל השינויים שמוכנסים למערכת במבנה של עץ דרישות שאיננו שונה מהותית מעץ הדרישות של הפיתוח. ראה פירוט נושא זה בקיט ניהול שינויים כרך נושאים תומכים, וקיט תחזוקה בכרך יסודות/מחזור חיים.

עדכונים רבעוניים – גרסאות

בקבוצה זו כלולות כל הדרישות/בקשות לשינויים שסובלות דיחוי ושניתן לבצען במסגרת של עדכון תקופתי (רבעוני) של המערכת בהליך מתוכנן ומסודר. עדכונים אלה יוצרים גרסת מערכת חדשה וזיהויים הוא ע"י קידום של ספרה "מימין לנקודה", כגון: 2.1, 2.2, 2.01, 2.02 וכו'. זאת, בניגוד למהדורות שבהן העדכון הוא "משמאל לנקודה": 1.0, 2.0, 3.0 וכו' ושאינם מתבצעים בעדכון רבעוני, אלא בהליך פיתוח מוסדר כמתואר בפסקה הדנה בדרישות מערכת לעיל.

העברה לצוות הפיתוח – מהדורות חדשות

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

איור מס' 3 מציג את ניהול הדרישות השוטפות בשיטה הריכוזית. המשתמשים וכן מערכות CRM וניהול תקלות מנתבים את כל הדרישות והדיווחים (והבקשות) לכתובת מרכזית אחת SPOC (Single Point of Contact). פונקציה זו, בהתייעצות עם מנהלת השינויים CCB (Change Control Board) מנהלת מעקב אחרי כל הפניות, מתעדפת אותן ומפנה אותן לגורם המטפל.

 

איור 3 : ניהול דרישות שוטפות וניתובן בשיטת הריכוזית SPOC/CCB

 

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

 

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

 

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

דרישות מערכת

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

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

ניהול דרישות בפרויקט סדרתי

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

 

איור 5: ניהול דרישות לאורך מחזור חיי המערכת (פיתוח סדרתי).

 

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

ייזום (קונספט)

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

אפיון

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

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

בקשה להצעות

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

עיצוב ובנייה (פיתוח המערכת)

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

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

בדיקות

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

תפעול ותחזוקה

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

דרישות בפיתוח זריז (Agile)

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

 

איור 6: ניהול דרישות בפיתוח בסבבים

 

שיטות פיתוח זריזות ומודרניות, כגון: פיתוח בסבבים, Agile וכו', מציבות אתגרים לנושא ניהול דרישות מערכת, משום שהפעילות המחזורית (האיטרטיבית) שהוזכרה לעיל בתוך שלב האפיון, משתרעת כעת על פני מחזור החיים כולו! הפתרון הוא ניהול דרישות משולב עם ניהול מהדורות וסבבי פיתוח מהירים. בכל סבב פיתוח מטפלים בדרישות מסוימות ומיישמים אותן. בין סבב לסבב, חוזרים ובוחנים את מאגר הדרישות המצטבר (Backlog) ומחליטים מה עובר לסבב הפיתוח (הספרינט) הבא. נושא ניהול דרישות הקלאסי לא נעלם בעולם ה- Agile, רק משתנה ומחליף צורה. אי אפשר לוותר על ייזום ואפיון-על המגדירים את דרישות המערכת ותיחומה "בגדול". אבל ניהול הדרישות הפרטני והמעקב אחר מימושן, יבוצע כחלק מהסבבים והספרינטים בשיטת Scrum למשל, וניהול שוטף של ה- Backlog. אחת לתקופה, ייערך סבב (ספרינט) שיוקדש להערכת המימוש עד כה, לסקירת דרישות שמומשו מול אלה שטרם מומשו, ואפילו לביצוע הגדרת דרישות "בדיעבד". ראה פירוט של שיטות פיתוח אלה בקיט פיתוח זריז Agileבכרך ניהול/ניהול פרויקט.

נושאים נוספים

מהי דרישה טובה?

דרישה טובה, חייבת לעמוד בכמה קריטריונים:

 ·         ברורה ופשוטה להבנה

 ·         ברת בחינה (Testability) – ניתנת לאימות ותיקוף בבדיקה, בהדגמה, באנליזה או בבחינה שהיישום אכן עונה על הדרישה. 

 ·         חד משמעית – הדרישה אינה ניתנת לפרשנויות שונות.

 ·         מלאה - הדרישה כוללת את כל הפרטים.

 ·         עקבית – הדרישה אינה סותרת דרישות אחרות ואינה חוזרת על דרישה אחרת.

 ·         חד ערכית- כל דרישה עוסקת ביכולת אחת של המערכת.

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

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

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

סוגי דרישות

למערכת יש דרישות מסוגים שונים:

 ·         דרישות פונקציונליות

 ·         דרישות ביצועים

 ·         דרישות אבטחת מידע

 ·         דרישות טכנולוגיות

 

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

 ·         ברכיב 2.5 תהליכים - יפורטו כל הדרישות הפונקציונאליות הקשורות לתהליכי המערכת

 ·         ברכיב 2.19 אבטחת מידע - יפורטו הדרישות בנושא אבטחת המידע (במ"מ).

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

 ·         ברכיב 2.22 ממשקים וקישורים - יפורטו דרישות הקישוריות של המערכת עם מערכות אחרות.

 ·         ברכיב 2.23 דרישות מיוחדות – יפורטו דרישות אורתוגונליות הכוללות: גמישות, יבילות ושפות.

 ·         ברכיב 3.9 תשתית סביבתית – יפורטו תנאי סביבה בהם תופעל המערכת (מבנה ו/או פעילות בשטח, פריסה גיאוגרפית, תנאי מזג אויר, ניידות, דרישות פיזיות כגון גודל ומשקל של רכיבי חומרה, דרישות בטיחות, דרישות להזנת מתח, תאימות אלקטרו מגנטית וכדו'.

 

תהליך ניהול דרישות

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

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

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

 ·         מורכבות –פרויקטים גדולים, מורכבים ומסובכים.

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

 ·         תחרות – הלחץ לספק תוצרים בלוח זמנים קצר ובעלויות נמוכות יותר.

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

היתרונות בניהול דרישות

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

 ·         ניהול ובקרה של הדרישות ממקדים את תהליכי האפיון והפיתוח של דרישות הלקוח.

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

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

 ·         שיפור היכולת לבצע בקרה על התקדמות הפרויקט.

 ·         שיפור היכולת לביצוע אמידת עלויות ע"י ניתוח של עלות תועלת עבור כל דרישה בנפרד או עבור מכלול דרישות.

שלבי ניהול דרישות

ניהול דרישות כולל מספר שלבים:

 ·         איסוף ניתוח ותיעוד דרישות

 ·         סקר דרישות (SRR)

 ·         ניהול עקיבות

 ·         טיפול בשינויים בדרישות

איסוף ניתוח ותיעוד דרישות

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

סקר דרישות (SRR)

סקר דרישות (System Requirements Review) הנו אבן דרך במחזור החיים של הפרויקט המציין את סיום שלב הגדרת דרישות המערכת/ המוצר. ל- SRR חשיבות רבה בתאום ציפיות ויצירת שפה משותפת בין המזמין (לקוח) לבין הגורם המפתח (הספק או גוף הפיתוח הפנימי) ויתר הגורמים המעורבים בפרויקט. הסקר הינו כלי לבחינת בשלות והיתכנות מימוש הפרויקט.

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

מטרות סקר SRR

מטרותיו העיקריות של הלקוח ב- SRR הן:

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

 ·         לוודא שהגורם המפתח או הספק במקרה של Outsourcing, מבין היטב את הדרישות, את סדרי העדיפויות והמגבלות הקיימות והוא מתחייב לממש את הדרישות במהלך הפרויקט.

עיתוי

סקר הדרישות  (SRR) יבוצע עם השלמת ניתוח הדרישות ולפני הכנת אפיונים / מפרטים מפורטים. הסקר יבוצע במקרים הבאים:

פרויקט בפיתוח עצמי

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

פרויקט בפיתוח ע"י ספק חיצוני (Outsourcing)

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

ניהול עקיבות

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

עקיבות הדרישות (Requirements Traceability), הוא מדד מרכזי בניהול דרישות מערכת ומשלים את "הצד השני של המטבע" – את המשכיות הדרישות (Requirements Continuity). לצדם, קיימים מדדים חשובים אחרים של גמישות והיענות לצרכי השוק וכן איתור פערים בדרישות. שם המשחק הוא איזון; והאמנות היא איך לשלב את כל הגורמים הבאים במהלך פיתוח מערכת IT:

 ·         הגדרת דרישות בסיסית – Minimal Requirements. חשוב לקבלת החלטות Go/No go בשלבים הראשונים של הפרויקט,

 ·         המשכיות הדרישות (Requirements Continuity) במעבר משלב לשלב בפרויקט,

 ·         העצמה וגמישות הדרישות לשינויים והתאמות – Requirements Augmentation & Flexibility

 ·         מעקב דרישות ופערים - Requirements Gaps & Traceability

 

וכל זה, תוך שימוש ביכולות של פירוק וחיבור דרישות Requirements Composition / Decomposition.

טיפול בשינויים בדרישות

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

כלים לניהול דרישות

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

הכלים הנפוצים לניהול דרישות הם (רשימה לא מלאה):

 ·         Borland Caliber RM

 ·         HP Software Quality Center

 ·         IBM Rational Requisite Pro

 ·         IBM Telelogic DOORS

 ·         Mercury Test Director

 ·         RequsitePro Rational

 ·         כלי MS Office

 

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

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

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

תוצרים

הגשת דרישה

טופס ראשוני הממולא ע"י הדורש/המשתמש.

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

ניתוח דרישה

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

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

אישור תקציבי לדרישה

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

טופס בקשה לשינוי (ראה קיט ניהול שינויים)

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

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

תבנית ניהול שינויים (ראה קיט ניהול שינויים)

רשימה מרכזת של השינויים בפרויקט/מערכת. לרשימה מועברים פרטים עיקריים של השינוי כגון:

 ·         מהות השינוי

 ·         משמעות מבחינת כוח אדם, תקציב ולוחות זמנים

 ·         עדיפות הביצוע

 ·         סטאטוס השינוי

 ·         מהדורה למימוש