דרישות כמה צריך וכמה כדאי

947 views

Published on

דרישות – כמה צריך, כמה כדאי?
יוסי קודיש - מומחה להנדסת מערכות ממוחשבות והנדסת דרישות ומכותבי הספרSystems Modeling & Requirements Specification Using ECSAM.

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

Published in: Education, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
947
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

דרישות כמה צריך וכמה כדאי

  1. 1. ‫דרישות - כמה צרי , כמה כדאי?‬ ‫י. קודיש‬ ‫הנדסת תוכנה ומערכות‬ ‫‪j.kudish@computer.org‬‬ ‫ספטמבר 9002‬
  2. 2. ‫ראשית הסיפור‬ ‫3-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  3. 3. "‫"לא איטונג - לא קונה‬ A characteristic that a system or CSCI must possess in order to be acceptable by the acquirer [MIL-STD-498] IBMMGWR-2009-4 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  4. 4. ‫... ובמונחי טכניי‬ In system/software engineering a capability needed by a user to solve a problem or achieve an objective a capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document [IEEE Std. 610.91] IBMMGWR-2009-5 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  5. 5. ‫תהיות, תובנות ...‬ ‫הא כל תכונה או יכולת הממומשת‬ ‫במערכת או בתוכנה היא בהכרח דרישה?‬ ‫התשובה לשאלה זו היא "לא"‬ ‫הא אפשר להפו כל תכונה או יכולת של‬ ‫מערכת או תוכנה לדרישה?‬ ‫במקרה זה התשובה היא "כ "‬ ‫6-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  6. 6. ‫... ותהיות נוספות‬ ‫מתי נרצה להגדיר תכונה או יכולת כדרישה?‬ ‫כאשר מסיבה כלשהי הפתרו היחיד הקביל‬ ‫עלינו / על המזמי הינו זה המוגדר בדרישה‬ ‫מתי נהיה חייבי להגדיר תכונה או יכולת‬ ‫כדרישה?‬ ‫כאשר הדבר מתחייב מסיבות טכניות )"אחרת‬ ‫זה לא יעבוד"(‬ ‫כאשר הדבר מתחייב מתוק חוק או תקנות‬ ‫7-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  7. 7. ‫רגע, מה בעצ עושי ע זה ?‬ ‫הדרישות מגלמות הבנה והסכמה בי‬ ‫המזמי למייש לגבי מה נדרש לעשות‬ ‫בפיתוח חדש‬ ‫קיי‬ ‫בשדרוג יישו‬ ‫לשימוש / משתמש חדש‬ ‫בהתאמת יישו‬ ‫בסיטואציה חוזית יש להסכמה זאת‬ ‫משמעויות משפטיות‬ ‫בסיטואציה לא-חוזית ההסכמה חוסכת‬ ‫‪ rework‬ואנרגיה‬ ‫8-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  8. 8. ‫דרישות "רכות" ודרישות "קשיחות"‬ ‫דרישות "רכות"‬ ‫אי-יישומ או יישו חלקי או שונה מ הנדרש לא‬ ‫יפגעו ביכולת המערכת למלא את משימתה‬ ‫למשל, מבנה מסכי או דוחות‬ ‫דרישות "קשיחות"‬ ‫יישומ כרוח וכלשונ הוא תנאי הכרחי‬ ‫להבטחת יכולת המערכת למלא את משימתה‬ ‫למשל:‬ ‫משוואות פיזיקאליות במערכת משובצת‬ ‫צורת חישוב המס בתוכנת עיבוד נתוני‬ ‫9-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  9. 9. ‫אי לעשות מה?‬ ‫לבחו הא כל מה שמוגדר כדרישה שיי‬ ‫לקטגוריה של דרישות "קשיחות"‬ ‫מומל להגדיר דרישות "רכות" כהנחיות‬ ‫)‪ (Guidance‬אשר עשויות להשפיע על‬ ‫דירוג המערכת א לא על קבילותה‬ ‫01-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  10. 10. ‫השלכות‬ ‫הואיל ודרישה היא תנאי לקבלת המוצר ע"י‬ ‫המזמי ...‬ ‫יש להדגי פורמאלית ללקוח שהדרישה מומשה‬ ‫מש ה-‪ FQT‬ועלותו גדלי ע גידול מספר הדרישות‬ ‫שינוי או ביטול דרישה משמע פתיחת ההסכ‬ ‫ע המזמי‬ ‫לשינוי תכונות ויכולות שאינ מוגדרות כדרישות‬ ‫מספיק לכנס ועדת שינויי‬ ‫11-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  11. 11. ‫... ועוד השלכות ...‬ ‫כל דרישה מגבילה אל אופציות המימוש‬ ‫העומדות לרשות המפתח‬ ‫הוספת דרישות שאינ הכרחיות עלולה‬ ‫למנוע מימוש אופטימאלי‬ ‫הגדלת עלויות הפיתוח‬ ‫ביצועי מופחתי‬ ‫סיכוני פיתוח מיותרי‬ ‫פגיעה בתחזוקתיות‬ ‫21-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  12. 12. ‫מסקנות עד כא‬ ‫!!! ‪Small is beautiful‬‬ ‫המעיטו בדרישות ככל שנית ,‬ ‫א לא יותר מכ !‬ ‫31-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  13. 13. Huston, we have a problem … IBMMGWR-2009-14 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  14. 14. ‫מה בעצ אנחנו עושי כא ?‬ ‫תוכנה..."‬ ‫"מה לנו ולמערכות ? אנחנו מפתחי‬ ‫התוכנה "נגמרת" ברמה של חבילת תוכנה / ‪CSCI‬‬ ‫היישו הינו מערכת הבנויה מאבני-בניי הממומשות‬ ‫בתוכנה‬ ‫לפיתוחי קטני ?"‬ ‫"הא זה רלוונטי ג‬ ‫כ , א לא אוהבי את המילה "‪"rework‬‬ ‫51-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  15. 15. ‫"... אבל אי לי לקוח ..."‬ ‫תחושה נפוצה כאשר מבוצע פיתוח "פנימי",‬ ‫או פיתוח בסיטואציה לא-חוזית‬ ‫כאשר מבוצע פיתוח עבור מחלקה שאינה‬ ‫מחלקת ה-‪ IT‬בארגו , איש הקשר של המשתמש‬ ‫העתידי הוא הלקוח‬ ‫כאשר מבוצע פיתוח "למד ", יש לאתר תחלי -‬ ‫לקוח )‪ (surrogate‬המכיר את הבעיות ואת‬ ‫הסביבה בה יופעל היישו‬ ‫למשל, מנהל המוצר או איש שיווק‬ ‫ראיונות ע משתמשי פוטנציאליי עשויי‬ ‫לספק מידע אשר יאפשר ניסוח דרישות‬ ‫61-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  16. 16. ‫"... ואי לי דרישות ..."‬ ‫מתכו מהיר לאיסו דרישות‬ ‫אתר את בעלי העניי הרלוונטיי‬ ‫מזמי )א יש(‬ ‫אנשי שיווק / מכירות‬ ‫משתמשי פוטנציאליי‬ ‫גורמי ביקורת והסמכה‬ ‫מתחרי‬ ‫...‬ ‫71-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  17. 17. ‫"... ואי לי דרישות ..."‬ ‫)המש (‬ ‫מתכו מהיר לאיסו דרישות‬ ‫וודא שכל בעלי העניי הרלוונטיי מביני‬ ‫באותה צורה מהו הצור אותו יש לספק‬ ‫ברר הא קיימות דרישות "קשיחות"‬ ‫ברר מדוע ה "קשיחות"‬ ‫אות , את הרציונאל שלה ואת מי שביקש‬ ‫רשו‬ ‫אות‬ ‫א הדרישות ניתנות למימוש במספר ‪,builds‬‬ ‫הגדר את ה-‪ builds‬וחלק ביניה את‬ ‫הדרישות‬ ‫81-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  18. 18. ‫כמה דרישות לאסו ?‬ ‫מעט מדי‬ ‫אתה עלול לפתח את הפתרו הלא נכו‬ ‫יותר מדי‬ ‫תבזבז זמ יקר על בירור דברי העלולי‬ ‫להתברר כשוליי‬ ‫תצמצ את מרחב התמרו העומד‬ ‫לרשות בבחירת דר הפתרו‬ ‫91-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  19. 19. ‫מתכו להצלחה באיסו דרישות‬ ‫זכור שהמטרה היא הבנת הבעיה אותה יש‬ ‫לפתור‬ ‫לעול אל תניח:‬ ‫שאתה מבי את הבעיה טוב יותר מבעלי העניי‬ ‫של‬ ‫שבעל עניי אחד יכול לייצג את כול‬ ‫א צרי , צור מילו מונחי‬ ‫היה מוכ לשינויי בדרישות; לבעלי עניי‬ ‫זכות מולדת לשנות את דעת ...‬ ‫02-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  20. 20. ‫)המש (‬ ‫מתכו להצלחה באיסו דרישות‬ ‫התמקד בדרישות "קשיחות"‬ ‫דחה את מה שהיה אמור להיות דרישות‬ ‫"רכות" לשלב התכ‬ ‫בבוא השעה קבל את אישור בעלי העניי לתכ‬ ‫"רוח וצלצולי " עולי כס !‬ ‫!‪TOOT‬‬ ‫+‬ ‫=‬ ‫=‬ ‫12-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  21. 21. ! ‫א זה לא כתוב, זו אינה דרישה‬ "Everybody knew 'exactly' what had to be done, until somebody wrote it down" [A. Pressman] IBMMGWR-2009-22 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  22. 22. ‫כל בני אנוש נבראו שווי ;‬ ‫הדרישות - לא‬ ‫32-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  23. 23. ‫תזכורת‬ User Installation Operational requirements & validation system definition Proposed characteristics ‫סוגי הדרישות‬ System Integration requirements definition Architectural design & verification Integrated system ‫דרישות מזמי‬ Allocated Supplied ‫ובעלי-עניי‬ Proposed requirements characteristics subsystems ‫אחרי‬ System Integration requirements definition Architectural design & verification Integrated subsystems ‫דרישות‬ Allocated Supplied ‫מערכת‬ Proposed requirements characteristics subsystems ‫דרישות של‬ System Integration requirements definition Architectural design & verification Integrated subsystems ‫תת-מערכות‬ Allocated requirements Proposed characteristics Delivered components ‫דרישות של‬ Component ‫רכיבי‬ development Components IBMMGWR-2009-24 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  24. 24. ‫"מעגל" דרישות בסיסי‬ User Installation Operational requirements system definition & validation ‫במודל שהוצג‬ Proposed characteristics ‫בשק הקוד‬ System requirements definition Architectural design Integration & verification Integrated system ‫חוזרת תבנית‬ Allocated Supplied ‫של מעגל משוב‬ Proposed requirements characteristics subsystems ‫הכולל זוג של‬ System requirements Architectural Integration & Integrated subsystems ‫רבדי סמוכי‬ ‫של מודל‬ definition design verification Allocated requirements Proposed characteristics Supplied subsystems ‫הפיתוח‬ System requirements definition Architectural design Integration & verification Integrated subsystems ‫בכל רמה‬ Allocated Proposed Delivered ‫הדרישות‬ requirements characteristics components ‫מפורטות‬ Component development Components ‫וספציפיות יותר‬ IBMMGWR-2009-25 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  25. 25. ‫... עוד על מעגלי ומשולשי‬ ‫בכל "מעגל" דרישות‬ ‫הדרישות ברמה הגבוהה יותר ה "דרישות מזמי "‬ ‫הדרישות ברמה הנמוכה יותר ה "דרישות מפתח"‬ ‫וכ ...‬ ‫בכל רמה נוספות החלטות תכ‬ ‫כלפי הרמה הבאה, די החלטות התכ כדי‬ ‫דרישות‬ ‫דרישות המפתח מהוות מענה לדרישות‬ ‫המזמי‬ ‫62-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  26. 26. ‫דרישות, החלטות תכ ומפרטי‬ Stakeholders SRD Stakeholders' System Requirements Requirements SSS System System Requirements Design Decisions (Derived Req's) SSDD System Req's Allocated to Subsystem Subsystem Requirements SSS Sub- SSS SSS SSS systems Subsystem Subsystem Requirements Requirements Design Decisions (Derived Req's) SSDD SSDD SSDD SSDD IBMMGWR-2009-27 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  27. 27. ‫... ובמקרי פשוטי יותר‬ Stakeholders SRD Stakeholders' Software Requirements Requirements SRS Software Software Requirements Design Decisions (Derived Req's) SDD IBMMGWR-2009-28 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  28. 28. ‫צרות באופק ...‬ ‫במקרי רבי ל-"מזמי " ול-"המפתח"‬ ‫במעגל דרישות נתו אי שפה משותפת,‬ ‫למשל:‬ ‫010110‬ ‫001101‬ ‫֠‬ ‫הלקוח והמפתח‬ ‫100010‬ ‫...1101‬ ‫☺‬ ‫...‬ ‫הנדסת מערכת‬ ‫והנדסת התוכנה‬ ‫92-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  29. 29. ‫בעלי עניי‬ ‫בעלי עניי ה כל מי שיושפעו על ידי‬ ‫המערכת או מי שבדר כלשהי אחראי‬ ‫לתוצאות הפיתוח או למערכת‬ ‫המזמי הוא בעל עניי בעל זכויות מיוחדות‬ ‫קבלת המערכת או דחייתה‬ ‫אישור התשלו תמורת המערכת‬ ‫03-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  30. 30. ‫בעל המאה...‬ ‫בכל מקרה של סתירה בי דרישות המזמי‬ ‫לדרישות בעלי עניי אחרי קובעת דעתו‬ ‫של המזמי‬ ‫כלל זה אינו חל במקרי בה דרישות‬ ‫המזמי סותרות את הוראות החוק,‬ ‫תקנות או הוראות של תקני מחייבי‬ ‫13-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  31. 31. ‫חייה הסודיי של הדרישות‬ ‫23-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  32. 32. ‫מדוע ניסוח מדויק של דרישות חשוב ?‬ ‫33-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  33. 33. ‫וכ ...‬ ‫43-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  34. 34. ‫"עובדות החיי "‬ ‫דרישות המזמי עלולות להיות ...‬ ‫מנוסחות בשפה טבעית שאינה חד-משמעית‬ ‫לא-קונסיסטנטיות‬ ‫לא-שלמות )כוללות הנחות סמויות(‬ ‫שגויות‬ ‫בלתי ניתנות לבדיקה‬ ‫בלתי ניתנות למימוש‬ ‫מגדירות תכ‬ ‫53-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  35. 35. ‫"נדיפות" דרישות‬ ‫דרישות עשויות להשתנות במהירות רבה‬ ‫המהל הפרויקט‬ ‫הוספת דרישות‬ ‫ביטול דרישות‬ ‫שינוי דרישות‬ ‫שינוי הקצאת דרישות‬ ‫לרכיבי המערכת‬ ‫63-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  36. 36. ‫)המש (‬ ‫"נדיפות" דרישות‬ ‫בפרויקטי ביטחוניי מוקפדי בארה"ב‬ ‫שיעור השינוי החודשי הממוצע עומד על %1‬ ‫בפרויקטי מסחריי שיעור השינוי החודשי‬ ‫הממוצע עלול להגיע לסביבות %4‬ ‫מציאות זאת מחייבת שימוש בכלי ניהול‬ ‫דרישות בעלי יכולת ‪ ,baselining‬שמירת‬ ‫היסטוריה וכיו"ב‬ ‫73-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  37. 37. ‫מה דרישות "טובות"?‬ ‫דרישות "טובות" ...‬ ‫מגדירות בצורה ברורה וחד-משמעית את הצור‬ ‫עליו נועדה המערכת לענות‬ ‫בעלות ער מוס למשתמש‬ ‫סבירות‬ ‫בעלות עקיבות לצור‬ ‫ניתנות לאימות‬ ‫מנוסחות במונחי של "מה" ולא של "אי "‬ ‫83-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  38. 38. ‫אי להגיע לדרישות "טובות"?‬ ‫ככל שדרישות המערכת "קשיחות" יותר‬ ‫כדאי יותר לפתח את הדרישות על בסיס‬ ‫מודל )‪(model-based req’s development‬‬ ‫להקפיד על ניסוח נכו של הדרישות‬ ‫להשתמש בכלי "תעשייתי" לניהול‬ ‫הדרישות, בפרט לש :‬ ‫ניהול שינויי‬ ‫ניהול עקיבות, כולל ‪impact analysis‬‬ ‫93-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  39. 39. ‫רמת גרנולציה של דרישות‬ ‫הא להגדיר דרישות "אטומיות" או דרישות‬ ‫מורכבות?‬ ‫רמת הגרנולציה של דרישות בכל רמה של‬ ‫ע הפיתוח צריכה להבטיח שנית יהיה‬ ‫להבי נכו כל אחת מ הדרישות ג ללא‬ ‫התייחסות לדרישות אחרות‬ ‫תוצר לואי - הקטנת‬ ‫מספר הדרישות‬ ‫04-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  40. 40. ‫דרישות המנוסחות במונחי פתרו‬ ‫לקוח עשויה לדרוש, למשל,ש- "יש להעתיק‬ ‫לארכיו את תור השאילתות כל 03 שניות"‬ ‫אלו שאלות כגו :‬ ‫במקרי‬ ‫"מדוע ?", "מה התכלית של דרישה זו ?"‬ ‫עשויות לגלות שהדרישה‬ ‫האמיתית היא:‬ ‫"איני יכול לסבול במש יותר‬ ‫מ-03 שניות אבד של‬ ‫פניות המגיעות למערכת "‬ ‫14-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  41. 41. ‫דרישות שאינ ניתנות לבדיקה‬ ‫שאינ‬‫לקוח עלול לנסח דרישה במונחי‬ ‫ניתני לבדיקה, למשל, "המערכת תהיה‬ ‫קלה לתפעול"‬ ‫במקרה זה אפשר להציע לנסח את דר‬ ‫הוכחת הדרישה במונחי המקובלי על‬ ‫הלקוח, אשר ניתני לבדיקה אובייקטיבית,‬ ‫כגו :‬ ‫"הא תסכי שהמערכת קלה לתפעול א‬ ‫%59 )או יותר( ממדג של ‪ X‬משתמשי‬ ‫יסווגו אותה ככזאת לאחר הדרכה של ‪ Y‬דקות ?"‬ ‫24-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  42. 42. ‫עקרונות כלליי של ניסוח דרישות‬ ‫נסח את הדרישות כ שקורא סביר:‬ ‫לא ייאל לתת לה פרשנות‬ ‫לא ייאל לנחש מה היו ההנחות של‬ ‫כתוב תמיד משפטי שלמי‬ ‫השתמש בשפה פשוטה וברורה‬ ‫המנע משימוש במונחי מעורפלי , רבי-‬ ‫משמעות, מונחי שמקור בס ֶנג מקומי,‬ ‫ל‬ ‫מונחי מסחריי‬ ‫34-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  43. 43. ‫)המש (‬ ‫עקרונות ניסוח דרישות‬ ‫מדי ...‬ ‫- א לא קצרי‬ ‫כתוב משפטי קצרי‬ ‫השתמש בסימני פיסוק‬ ‫א סימני הפיסוק רבי מדי, נסח את‬ ‫הדרישה מחדש‬ ‫הבח בי דרישות לבי הנחיות )‪(guidance‬‬ ‫המנע ממילי כגו "כגו ", "למשל",‬ ‫"וכדומה", "וכולי", וכו'‬ ‫44-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  44. 44. ‫)המש (‬ ‫עקרונות ניסוח דרישות‬ ‫המנע ממונחי מעורפלי , כגו :‬ ‫למזער‬ ‫להגדיל ככל האפשר‬ ‫מספק‬ ‫ידידותי למשתמש‬ ‫ממדרגה ראשונה‬ ‫המערכת תתמו ב...‬ ‫... כולל א לא מוגבל ל...‬ ‫54-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  45. 45. ‫)המש (‬ ‫עקרונות ניסוח דרישות‬ ‫נסח את הדרישות כ שנית יהיה לשנות או‬ ‫למחוק חלק מה מבלי שהדבר יחייב עדכו‬ ‫של הדרישות הנותרות‬ ‫שמור רשומת של מקורה של דרישה‬ ‫והרציונאל העומד מאחוריה‬ ‫השתדל לכתוב מה נחו , ולא אי לממש את‬ ‫הפתרו‬ ‫64-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  46. 46. ‫ניסוח דרישות בעברית‬ ‫השתמש בציווי בלשו עתיד, למשל:‬ ‫"רשומות המטופלי תוחזקנה במערכת בצורה‬ ‫מוצפנת."‬ ‫"במקרה ולא נית להשלי את הטרנזקציה‬ ‫התוכנה תחזיר את בסיס הנתוני למצב בו היה‬ ‫בטר החל הטיפול בטרנזקציה ."‬ ‫74-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  47. 47. ‫ניסוח דרישות באנגלית‬ ‫התבנית הכללית תהיה:‬ ‫]>?‪The system shall <action> [<what‬‬ ‫]>?‪[<when/how‬‬ ‫הניסוח יהיה בלשו עתיד, ויכלול:‬ ‫את המילה ‪ shall‬לדרישות‬ ‫את המילה ‪ should‬להנחיות )‪(guidance‬‬ ‫את המילי ‪ will, may‬להצהרת כוונות כללית‬ ‫84-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  48. 48. ( ‫)המש‬ ‫ניסוח דרישות באנגלית‬ The System shall… Action What? When / How? measure the car density in each traffic lane. the remaining display in seconds. recording time trasmit the error messages to central log. the communication command in emergency mode. switch to filter traffic the software from the download following power-up. server when signaled by the perform error recovery xyz. the distance till next based on current fuel compute refueling consumption. adjust the exposure time for every frame. IBMMGWR-2009-49 2009 © ‫י. קודיש – הנדסת תוכנה ומערכות‬
  49. 49. ‫כמה צרי , כמה כדאי‬ ‫05-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  50. 50. ‫‪Money, money, money‬‬ ‫לנכונות הדרישות השפעה חזקה על עלות‬ ‫הפיתוח, ולכ כדאי להשקיע בהגדרת‬ ‫הדרישות‬ ‫תיקו מערכת עקב ליקוי בדרישה / הבנה של‬ ‫דרישה לאחר סיו בדיקות המערכת עשוי‬ ‫להיות יקר פי 001 עד פי 002 ]‪Standish Group‬‬ ‫ואחרי [ מאשר תיקו שהיה נעשה בשלב‬ ‫הגדרת הדרישות‬ ‫15-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  51. 51. ‫עלות שגיאות שמקור בדרישות‬ ‫שגיאות שמקור בדרישות מהוות בי %04‬ ‫ל-%05 מ השגיאות בפרויקטי ]‪[Dion‬‬ ‫תקלות בטיחות שמקור בדרישות מהוות בי‬ ‫%06 ללמעלה מ-%08 מכלל התקלות ]‪[NASA‬‬ ‫עלות ממוצעת של תיקו שגיאות שמקור‬ ‫בדרישות )‪ (rework‬מגיעה ל-%07 עד %58‬ ‫מ העלות המקורית של הפרויקט ]‪[Standish‬‬ ‫עלות ה-‪ rework‬אינה מתוקצבת ולכ זהו‬ ‫הכס היקר ביותר בפרויקט של !‬ ‫25-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  52. 52. ‫דוגמה מספרית‬ ‫נניח כי מדובר ביישו בהיק של 000,05 שורות‬ ‫קוד, המפותח ע"י צוות הכולל 6 מפתחי , ראש‬ ‫צוות, 2 אנשי בדיקות ואיש ‪ QA‬אחד, שעלות‬ ‫החודשית הממוצעת היא ‪ $10K‬לעובד‬ ‫בהנחה שהתפוקה החודשית הממוצעת של איש‬ ‫פיתוח היא 053 שורות קוד "נקיות", העלות הכוללת‬ ‫של הפרויקט מוערכת ב-‪ ,$2.4M‬במהל 42‬ ‫חודשי קלנדריי‬ ‫נניח כי עלות ה-‪ rework‬הכוללת בפרויקט היא‬ ‫%03, סכו השווה ל-000,027$‬ ‫א מתו סכו זה עלות תיקו הבעיות בדרישות‬ ‫היא %07, סכו זה מצטבר ל-000,405$ !‬ ‫35-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬
  53. 53. ‫)המש (‬ ‫דוגמה מספרית‬ ‫נניח כי עלות רכש כלי והכשרת הצוות היא‬ ‫מסדר-גודל של ‪$20K‬‬ ‫ההחזר על טיפול טוב יותר בדרישות ית לנו:‬ ‫מקרה 3‬ ‫מקרה 2‬ ‫מקרה 1‬ ‫%04‬ ‫%02‬ ‫%01‬ ‫שיעור סילוק שגיאות בדרישות‬ ‫006,102$‬ ‫008,001$‬ ‫004,05$‬ ‫חיסכו בפרויקט המוצג‬ ‫5.2‬ ‫7.1‬ ‫0.1‬ ‫קיצור זמ ליציאה לשוק ) ‪] (TTM‬חודשי [‬ ‫4.2‬ ‫7.4‬ ‫5.9‬ ‫החזר זמ על ההשקעה ]חודשי [‬ ‫%319‬ ‫%704‬ ‫%351‬ ‫% החזר על ההשקעה במהל פרויקט ראשו‬ ‫45-9002-‪IBMMGWR‬‬ ‫י. קודיש – הנדסת תוכנה ומערכות © 9002‬

×