המדרשה לדרישות "טובות" – מאמר ראשון בסדרה

רקע

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

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

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

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

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

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

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

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

חיונית (Necessary)

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

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

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

דוגמא:

המוצר המסופק יצרוך חשמל בכל מהלך פעולתו

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

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

המוצר יפעל על אנרגיה חשמלית

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

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

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

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

דוגמא:

להכוונת התנועה בצומת יש להשתמש במערכת רמזורים

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

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

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

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

חד משמעית (Unambiguous)

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

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

דוגמא:

דוגמא:

בפאנל הקדמי תהיה תצוגת זמן

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

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

לעומת זאת:

להיות:

בפאנל הקדמי יוצג באופן רציף הזמן_הנוכחי

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

מונח	הסבר המונח
הזמן_הנוכחי	השעה הנוכחית לפי שעון ירושלים, בפורמט "HH:MM 24 שעות"

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

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

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

מה למדנו ?

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

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

מה הלאה ?

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

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

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