הרצאה מס' ניהול דרישות

קורס הנדסת מערכות לחברות קטנות ובינוניות הרצאה מס' 2 ניהול דרישות 13.2.2012 עוזי אוריון חבר הנהלת האיגוד הישראלי להנדסת מערכות לשעבר נשיא האיגוד ייזום ופיתוח טכנולוגי בחברת אלביט מערכות אלקטרו-אופטיקה אלאופ 1

תוכן העניינים מבוא איסוף צרכי לקוח תרגום הצרכים לדרישות ניתוח תפקודי ניתוח מבצעי של צרכי המערכת סוגי הדרישות )תפקוד, תכונות, התנהגות( סיווג הדרישות כתיבת הדרישות מסמך דרישות הלקוח סקר SRR מדרישות למפרטים כתיבת המפרטים ניתוח המפרט סקר SDR הקצאת מפרטים ליחידות וסקר PDR תכן מפורט, בקרת תצורה וסקר CDR תיקוף ואימות הדרישות ניהול דרישות בכלים ממוחשבים 2

שיעור ההצלחה בפרוייקטים )תוכנה( Failure: Project canceled Challenge: Restarts Cost Overruns Time Overruns Content Deficiancies Success: Project finished on time, on budget with full funcionality Project Success is Rare 2009 2006 2004 2002 2000 1994 Failed 24% 19% 18% Challenged 46% 44% 51% 2009 Succeeded 32% 35% 29% 15% 51% 34% 2009 23% 49% 28% 16% 53% 31% Source: Extreme Chaos, The Standish Group International, Inc. 1994, 2000, 2002, 2004, 2006, 2009 2009 4

סיבות להצלחה או קשיים בפרוייקטים Project Success Factors 1. User Involvement* 2. Executive Management Support* 3. Clear Business Objectives* 4. Clear Statement of Requirements 5. Agile Process* 6. Realistic Expectations 7. Smaller Project Milestones 8. Skilled Resources* 9. Formal Methodology* 10. Standard Tools & Infrastructure* Project Challenged Factors 1. Lack of User Input* 2. Incomplete Requirements & Specifications* 3. Changing Requirements & Specifications* 4. Lack of Executive Support* 5. Technology Incompetence 6. Lack of Resources* 7. Unrealistic Expectations* 8. Unclear Objectives* 9. Unrealistic Time Frames* 10.New Technology Source: 2004*, 1995 Chaos Report, The Standish Group International, Inc. 5

מה זה מערכת הגדרה: אוסף של מרכיבים הפועלים יחדיו על מנת לבצע משימה מוגדרת. כולל חומרה, תוכנה, קושחה,)firmware( אנשים, מידע, טכניקות, תשתיות, מבנים, ציוד, שרותים ומרכיבים תומכים אחרים על פי INCOSE-Systems Engineering Handbook V.2.0 July 2000 6

מערכת מורכבת אופיינית 7

מערכת של מערכות גבולות המערכת ממשקים תת-מערכת פוד צילום תת-מערכת תחנה קרקעית חשמל איזור פעולה הפעלה BIT ממשק מצלמה אויר- Aero-optics 8

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

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

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

ומה זו דרישה? דרישה היא ביטוי בר בדיקה, המתאר את מה שמשפיע על המוצר, להשגת צרכים של בעלי העניין או עמידה ביעדי חוק, תקנות או נוהלים. אנו מבחינים בין 3 רמות של הגדרת דרישות: צרכי הלקוח )הדרישה המבצעית( - תאור צרכי הלקוח במונחים תפעוליים מבצעיים צרכי לקוח: במכונית הונדה לג'נד, יכולת ראיית אדם בלילה מעורפל במרחקי נהיגה דרישות הלקוח - פירוט הדרישה המבצעית במונחים טכניים, בשפתו, במונחים ברי מדידה דרישת לקוח: הכרת אדם במרחק של 50 מ' לפחות, בעבירות אטמוספרית אטמוספרית של פחות מ- 3%, בתאורת סביבה שקטנה מ- 100 מיקרולוקס מפרטי פיתוח - פירוט, בשפת המפתח, של הדרישות שנגזרות מהאופיון, שמאפשרות הגדרה חד משמעית של תוצרי הפיתוח ובדיקתם מפרט פיתוח: מערכת צילום תהיה בעלת MTF גדול מ- 10% ב- 25 זוגות קווים למילירדיאן בשדה ראיה של 30, ויכולת ההבחנה התרמית תהיה טובה מ-,50m K כאשר הרעידות בנקודת הדפינה יהיו קטנות מ- 1G RMS בתחום תדרים של 0.5 עד 350 הרץ. 12

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

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

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

חדשנות בשוק... 17

נקודות מבט של לקוחות ובעלי עניין "לקוח" )Customer( כל אדם או גוף שיכול לחייב הגדרת דרישות למערכת. "בעל עניין" )Stakeholder( א דם או גוף שיכול להשפיע על או להיות מושפע מתוצר המערכת או הצלחת הפרויקט לכל אחד מבעלי העניין נקודת מבט משלו 18

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

הבנת צרכי הלקוח 20

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

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

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

קבוצות מיקוד לזיהוי צרכי לקוח.2.3.4 שיטה לאיסוף מידע שיווקי ע י תקשורת ישירה, ממוקדת, מרוכזת ומובנית בין הלקוחות הקובעים לבין נציגי הארגון היוזם דוגמה: ביקור של מנהל בכיר ונציגים.1 מחברת Analog Devices בחברתנו הכנות הגדרת הנושא קביעת משתתפים לוגיסטיקה לימוד המתחרים מושב פתיחה התכנסות ומבואות הסקופ מי הלקוח קבלת צרכי הלקוחות בקשות, רצונות תועלות, בעיות, תלונות על ציוד קיים Likes &Dislikes עדיפויות הלקוחות מיון ותיעדוף AD נתנו הצהרה שהם רואים בנו שותף אסטרטגי הצגת ה- Road-map שלהם שאלות על מה הצרכים שלנו ותגובות ל- Road-map דיון בפרטי הצרכים שלנו, כולל תזמון הצורך ותיעדוף שאלות על תחושות ביקורתיות של המשתמשים פתיחת ערוצי תקשורת ופתרון סוגיות מיידיות 24

דוגמה: תיעדוף צורכי הלקוח בעזרת טכניקת NGT # Customer need David Peter John Josef J.R Simon Alex Ron AVG STD DEV Decision Voting Weight 1 1 1 3 3 1 1 2 13 1 Cost 18 18 22 23 16 20 25 15 19 3.3 3 2 Weigh 25 20 15 33 25 20 24 20 24 5 1 3 Interface 8 17 10 5 8 10 5 14 9 3.9 6 4 Fast Location 4 4 5 2 3 5 3 2 3.1 1.1 7 5 User Friendly 22 15 20 15 20 25 30 25 21 4.8 2 6 Day/Night 13 16 23 13 18 10 8 13 15 4.4 4 7 Range 10 10 5 9 10 10 5 11 9.2 2.2 5 Total 100 100 100 100 100 100 100 100 100 NGT=Nominal Group Technique 25

דוגמא: תוצאות קבוצת מיקוד Best In Class LM, Thales Thales LM LM, Thales, BAE BAE LM, BAE Thales LM BAE BAE Thales - LM, BAE BAE Thales צורך הלקוח משקל )3 ק"ג גבול עליון( פעולה תחת לחץ/ידידותי למפעיל מחיר יכולת פעולה יום/לילה טווח התממשקות למערכות קימות איכון מהיר של מטרות ( Target )Locator זמן פעולה עם סוללה בודדת אמינות מבצעית תחזוקתיות יכולת אימון והדרכה כושר שדרוג זמן הגעה לשוק יכולת תצפית למודיעין בטיחות חשיבות 10 9 9 9 8 8 7 7 7 6 6 6 5 4 3.1.2.3.4.5.6.7.8.9.10.11.12.13.14.15 26

Benchmarking - השוואת שוק - Benchmarking השוואה שיטתית בין מוצרים שירותים או תהליכים תהליך ה Benchmarking.1.2.3.4.5.6.7.8.9.10.11 תחקור הלקוחות מי נתפס כטוב ביותר בשוק Class(,)Best in לגבי כל צורך בנפרד בחירת המוצרים/החברות המתחרות להשוואה ההחלטות הדרושות: הגדרת מדדים כמותיים להשוואה ערכי היעד במדדים קביעת שיטת איסוף הנתונים הנבחרים ביצוע אסוף הנתונים. קבלת מעמד של מוביל קביעת גודל פער הביצועים הקיים הערכת רמות הביצוע שידרשו בעתיד קבלת הסכמה על ממצאי ה- Benchmarking ע"ע בעלי העניין )החיצוניים והפנימיים( הכנת תכנית פעולה להשגת ערכי היעד יישום תכנית הפעולה ועקוב אחר ההתקדמות בדוק בתכיפות את נקודות המוצא ע. הרי רח כספרי 25 חיפה, 34677 טל: 04-8246977 פקס 04-8246772 27

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

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

אגב חיפוש צרכי לקוח 34

תהליך QFD (Quality Function Deployment) קורס כלי QFD לזיהוי צרכים ופיתוח דרישות צוות רב תחומי זיהוי הצרכים הפיכת הצרכים לדרישות פיתוח הדרישות בחינת אופן המימוש לאורך הפרויקט משתתפים לקוחות מגזרי הלקוח השונים מהנדסי המערכת מנהלי הפרויקטים.1.2.3.4 35

תהליכי QFD קורס לזרוז פיתוח הדרישות (Requirement Elicitation) 36

Reduce energy level to 7.5 ft/lb Maintain current level Reduce force to 9 lb. Reduce energy to 7.5 ft/lb. Maintain current level Maintain current level Energy needed to close door Door seal resistance Check force on level ground Energy needed to open door Accoust. Trans. Window Water resistance Customer Requirements Easy to close Stays open on a hill Easy to open Engineering Characteristics Doesn t leak in rain No road noise Importance weighting Target values 7 5 3 3 2 קורס דוגמה לבית האיכות X X X 10 6 6 9 2 3 X X Correlation: Strong positive X * 6 Positive Negative Strong negative Competitive evaluation X = Us A = Comp. A B = Comp. B 1 2 3 4 5 (5 is best) X AB X AB XAB A X B X A B Relationships: Strong = 9 Medium = 3 Small = 1 Technical evaluation (5 is best) 5 4 3 2 1 B A X BA X B AX B XA BXA BA X 37

תרגילון בנית בית האיכות נבחרת )באופן זמני( להשתתף ב-צוות QFD שתפקידו לפתח מצלמה חדשה. בנה את בית האיכות. 1984-1994 T/Maker Co. 38

תרגילון בנית בית האיכות בחירת תכונות הנדסיות שמספקות את דרישות הלקוח דירוג החשיבות של לקוח אופייני מה שהלקוח רוצה )'קיר'( - + + + + סתירות ותמיכות + Customer Requirements Light weight Easy to use Reliable Target Values Customer Importance 3 2 1 Aluminum Parts Steel Parts 5 2 Auto Focus Auto Exposure 8 7 4 8 5 3 19 14 21 17 הקשרים שבין מאפייני הלקוח לתכונות ההנדסיות )'חדרים'( 1984-1994 T/Maker Co. 39

כללים להגדרת צרכי הלקוח המה ולא האיך... בשפת הלקוח ברורים לכל בעלי העניין. הצהרות חיוביות לעיתים קרובות אין מספרים כמותיים )הלקוחות לא קונים בד"כ פרמטרים או מאפיינים. הם קונים תועלות או פתרונות לבעיות( יש להתייחס לאילוצי תקציב ולו"ז כגון:,TTM תקציבי פיתוח וייצור, מה אפשר באופן ריאלי לפתח בזמן שעומד לרשות הפרוייקט חובה להתייחס להיבטים אסטרטגיים של הפתרון כגון שיתופי פעולה, מגזרי השוק )גיל הקונים, דרכי הקניה, יכולת פיננסית של מגזר השוק, עיתוי הקניה, פתרון אוניברסלי או פניה ל- Low-end או High-end,Key buying factors לא בהכרח טכניים יש לזהות ולהתייחס לפערי ידע וסיכונים: פערים טכניים פערים שיווקיים מתאר השימוש 42

איתגור אילוצים פרוייקטאליים שלא הושגו סיכום הגדרת צרכי הלקוח תקשורת עם בעלי העניין )המידע הנכון והלקוחות הנכונים( הסכמת בעלי העניין ובסיס הדרישות תקשורת עם בעלי העניין חבירה עם הלקוח )כולל סביבת התמיכה( הבנת הרמה הבאה של דרישות בעלי העניין אימות ההנחות טכנולוגיות סרט שרות לקוח חיזוי מדוייק של יכולות התהליך תכנון וניהול טכנולוגיה הבנת פרטי סביבת המוצר )לא רק המפרט( הבנת בעלי העניין הבנת המשימה/ הסביבה הבנה מלאה של שיקולי המשימה זיהוי צרכים, דרישות ויעדים שדובר ושלא דובר עליהם זיהוי דרישות ואילוצים סמויים Source: Kurt Himmelriech: Application of SE Process on High Risk Programs 43

תוכן העניינים מבוא איסוף צרכי לקוח תרגום הצרכים לדרישות ניתוח תפקודי ניתוח מבצעי של צרכי המערכת סוגי הדרישות )תפקוד, תכונות, התנהגות( סיווג הדרישות כתיבת הדרישות מסמך דרישות הלקוח סקר SRR מדרישות למפרטים כתיבת המפרטים ניתוח המפרט סקר SDR הקצאת מפרטים ליחידות וסקר PDR תכן מפורט, בקרת תצורה וסקר CDR תיקוף ואימות הדרישות ניהול דרישות בכלים ממוחשבים כאשר אתה מודד ומבטא זאת במספרים, אתה יודע משהו על זה; כאשר אתה לא יכול, הידע שלך זעום ובלתי מספק לורד קלווין, 1891 44

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

מהי דרישה? Would you tell me, please, which way I ought to go from here?' That depends a good deal on where you want to get to, said the Cat. Then it doesn't matter which way you go, said the Cat. I don't much care where said Alice. so long as I get somewhere,' Alice added as an explanation. Alice's Adventures in Wonderland by Lewis Carroll CHAPTER VI - PIG AND PEPPER Image: Sir John Tenniel - 1865 Oh, you're sure to do that,' said the Cat, `if you only walk long enough.' 46

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

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

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

ניהול דרישות הגדרת דרישות לקוח בסיס נתונים ממוחשב לדרישות הכנסת הדרישות וסיווגן עדכון דרישות לקוח SRR SDR PDR עקיבות גזירת מפרט מערכתי גזירת מפרטים למרכיבי המערכת תרגום הדרישות למונחי פיתוח פירוט הדרישות לדיסציפלינות תכנון בדיקות אימות ותיקוף תכנון השילובים, אימות ותיקוף, ניסויים, סימולציות CDR בדיקות פונקציונאלית לא מתוכננות היטב 50

I don t have time to write requirements! Can t you see that I m busy debugging? Requirements? מתוך הרצאתו של Az.): Terry Bahill (Univ. of Discovering System Requirements 2003 51

פירוק תפקודי Functional Decomposition העברה מהירה בטוחה ואמינה מנקודה א' ל-ב' הנעה עצירה הובלת אנשים הובלת מטען אספקת מומנט אספקת אנרגיה יכולת היגוי שליטה בהספק שליטה במומנט להיכן לשייך: דרישות נוחיות ישיבה? דרישות מרחב? דרישות בטיחות? דרישות מבנה? עיצוב הרכב 53

מהו פירוק תפקודי? פירוק המערכת לרכיבים המתאימים לתפעול המערכת ותת המערכת. (IEEE 610.12-1990) חלוקת כל פונקציה )תפקוד( למרכיביה: ABCD מתפרק ל- AB.CD-וAB ממשיכה להתפרק ל- B ו- A ו- CD מתפרקת ל- D ו- C ABCD AB CD A B C D 54

פירוק תפקודי יחסי אב-בן כל התיפקודים )הפונקציות( והתהליכים מקושרים ל תיפקוד או לתהליך אחד לפחות. לכל אב יש לפחות שני ילדים. ABCD לכל ילד יש רק אב אחד AB CD A B C D תויות הן ת יא ור י ות )descriptive( )משמעותיות( לקישורים אין שם )משמעותם רק "מורכב מ..."( 55

למה פירוק תפקודי? לפירוט דרישות כלליות. לקבץ דרישות בקבוצות תפקודיות. כמו דרישות ניווט, סביבה וכו'. לקבוע דרישות לתת המערכות Target Info Deliver Munition Munition Delivery Detect Recognize Locate Ready Aim Fire Munition Delivery 56

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

שיטות לפירוק תפקודי פירוק תפקודי יכול להיות מוצג כהיררכית המערכת, סכמת בלוקים תפקודית, סכמת זרימה תפקודית,,time lines דיאגרמת זרימת נתונים/בקרה, דפי הקצאת דרישות, או בצורת QFD Requirements State Machine Language RSML תכנון מבוסס מצבים מאוגד למצבי על בעזרת דמיון במעברים. במצב זה מספר מצבי המערכת יורד משמעותית. פירוק תפקודי ברשת על )SuperState( איגוד תתי רשתות לרשת כוללת. Clique-decomposition איחוד תכונות תיכון ליצירת קליקות. מאפשר למצוא שיטתית, אופטימלית בתיכון. קליקות מוגדרות גם כתת גרפים של גרף מסוים. פירוק תפקודי היררכי במקרה של תיכון סימטרי שניתן לתאר אותו בעזרת עץ. קבוצת קליקות 60

שימוש בטכניקת FAST )Functional Analysis System Technique( ארגן את התפקודים כתפקודים בסיסיים ותפקודים תומכים: תפקודים בסיסיים )ראשיים( חייבים להתממש תפקודים תומכים )משניים( תפקודים אחרים. יכולים לתמוך בתפקודים הבסיסיים ארגן על פי יחסי "איך", "למה", "מתי" במיון של דרישות לקוח יש להוסיף גם דרישות תומכות בחיוניות לאישור המערכת על ידי הלקוח. אין לערבב תפקודים המבוצעים ע"י המשתמש, המתכנן או היצרן 61

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

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

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

צרכים ממזגן אוויר-דוגמה צרכים יסודיים מקרר בקיץ ומחמם בחורף נוח ויעיל לשימוש בטיחותי דקורטיבי צרכים "מפורשים" חוזק מיזוג רב לא קופא בחורף משפיע מיד על טמפ' החדר לא מיבש את האויר לא מרעיש קל לשלוט בבקרים קל לתפעול ואחזקה קל לכוון את זרם האוויר לא מתקלקל בהפסקות חשמל לא מאפשר להכניס אצבעות לא מקצר את הרשת הביתית התקנה יציבה קומפקטי צורה וצבע מתאימים לריהוט לא מחליד צרכים "מתורגמים" )דרישות( לפחות BTU 24,000 בקירור לפחות BTU 22,000 בחימום מנגנון Anti-freeze למדחס ספיקת אוויר של לפחות 0.5 מ 3 /דקה מיכל נוזל במעבה להגדלת לחות בחימום הנחתת רעש המדחס ב- 14dBלפחות בקר פשוט, כולל מנגנון ממוחשב החלפת וניקוי קל של הפילטרים כיוון זרימה אוטומטי מנגנון השהיית הדלקה של 5 דקות שימוש ברשת בצפיפות של 5 מ"מ מנגנון השהיית הדלקה של 5 דקות איבזור המעבה לתליה יציבה קופסת מעבה של 10x30x150 ס"מ צבע בז' 2352 עם פינות מעוגלות חלקים חיצוניים מפלב"מ 13/70 65

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

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

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

אולם... תכן...Object Oriented תכן פונקציונאלי 69

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

הכנת תרחישי ייחוס הכנת תרחישי דוגמה תרחיש אופייני תרחיש לחוץ Activity Diagram Use Case Diagram תרחיש שכולל יבילות ותמיכה לוגיסטית מאפשר למפתחים לתרגם דרישות מצעיות לדרישות טכניות להגדיר את מעטפת הביצועים שנדרשת על פי התרחישים הללו 72

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

ניתוח מבצעי זיהוי גבולות המערכת והסביבה זיהוי מערכות ידועות שפועלות יחד מתן תשובות לשאלות המבצעיות כמה גדול? כמה מהר? מתן תשובות לשאלות הטכניות ביצועים? מגבלות? גבולות המערכת ממשקים תת-מערכת פוד צילום תת-מערכת תחנה קרקעית חשמל איזור פעולה הפעלה BIT ממשק מצלמה אויר- Aero-optics 74

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

ניתוח סביבתי ניתוח התנאים הסביבתיים בהם המערכת נדרשת לתפקד יש להתייחס לתקנים הרלוונטיים שמכסים נושא זה )כמו,DO-160 )MIL-STD-810,ASTM D5746 לבחון את הנושאים הרלוונטיים והטווחים הדרושים מתוך אותם תקנים טמפרטורת סביבה תנאים אטמוספריים רעידות והלמים לחות נקודת טל Point( )Dew פטריות )Fongus( ברקים הקרחה, שלג, ברד חול ואבק רוחות בקרקע ובגובה אוזון קרינה סולארית ואקום חללי חגורת ואן אלן אטמוספרה קורוסיבית שדות מגנטיים כח הכובד טמפרטורה מושרית תנאים אקוסטיים עומסים סיסמיים קרינה מיננת )בחלל( קרינה לא מיננת )לייזר( 76

תוכן העניינים מבוא איסוף צרכי לקוח תרגום הצרכים לדרישות ניתוח תפקודי ניתוח מבצעי של צרכי המערכת סוגי הדרישות סיווג הדרישות כתיבת הדרישות מסמך דרישות הלקוח סקר SRR מדרישות למפרטים כתיבת המפרטים ניתוח המפרט סקר SDR הקצאת מפרטים ליחידות וסקר PDR תכן מפורט, בקרת תצורה וסקר CDR תיקוף ואימות הדרישות ניהול דרישות בכלים ממוחשבים )תפקוד, תכונות, התנהגות( 77

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

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

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

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

דרישות לא תפקודיות מתוך IEEE-STD-830 83

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

דרישות ממשקים 85

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

דרישות תפעול אופיין תפעול ממשקי אדם מכונה הנדסת אנוש 87

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

סיווג הדרישות ע) לפי: חשיבות הדרישה בטיחות מאפיין מפתח מתחייב )mandatory( אפשרי )optional( רצוי )desirable( אחרת לא דרישה תתי מערכות ספק כח יחידה אלקטרונית פנל הפעלה תחומים מקצועיים: מערכת אלקטרוניקה מכניקה אופטיקה פיזיקה בקרה עיבוד אות עיבוד תמונה מס' 3.13.54 3.35 תחומים מקצועיים )המשך(: תוכנת זמ"א תאלמ"ג תוכנת ניהול חומרים אחרים איכות דרישה מתח הכניסה יהיה 12±1V מידות ומשקלות )שם פרק( עדיפות בטיחות מנדטורי לא דרישה תחום אלקטר' תאלמ"ג - 3.35.1 3.44.2 משקל כולל של היחידות במטוס לא יעלה על 15 ק"ג החיבור עם ספק כח יהיה עם כבל יחיד בעל 4 גידים מאפיין מפתח מנדטורי רצוי מכניקה זיווד עיבוד אות חומרים מכניקה אלקטר' זיווד תאלמ"ג יחידה כח ספק כל היח' "פ תקציב( כח ספק ממשק למטוס 90

חשיבות הניסוח ע"י שינוי מיקום המילה "רק" ניתן לקבל 5 משמעויות שונות: רק אני לקחתי אותה אתמול לגן אני רק לקחתי אותה אתמול לגן אני לקחתי רק אותה אתמול לגן אני לקחתי אותה רק אתמול לגן אני לקחתי אותה אתמול רק לגן 92

The importance of Attitude קורס An English professor wrote on the chalkboard the words: A woman without her man is nothing and asked his students to punctuate it correctly. All of the males in the class wrote: A woman, without her man, is nothing. All the females in the class wrote: A woman: without her, man is nothing. 93

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

כתיבה נכונה של דרישה/מפרט התמקדות במטרות התכנית אין להרחיב, אלא אם ההרחבה היא יעד של הפרוייקט " עודף" דרישות גרוע כמו חוסר. יש דרישות שעדיף להציג בעזרת איורים. בסיסי נתונים יעילים עקב שלמות המידע הכלול בהם, חשיפת מידע זהה לכלל המשתמשים, יכולת הקישור בין הפריטים, וכן יכולת מיון וסינון הפריטים מצד שני, בסיסי נתונים עלולים להיות מסוכנים בכך שהם יכולים לזמן יותר מידע ממה שבאמת נחוץ. "Between thought and expression there lies a lifetime Bob Dylan 95

)לא( כתיבה נכונה של דרישה/מפרט דוגמאות לדרישות שגויות "מה"( ולא )"איך" Titanium case Titanium or Kevlar (red or black) strap Liquid-crystal display Lithium battery Source: Discovering System Requirements, Terry Bahill, University of Arizona 96

שימוש מיוחד במונחים אין להשתמש בראשי תיבות אלא אם הם מוכרים בוודאות לכל המשתמשים בדרישות למילים may, Should,Shall ו- can, יש מובן יעודי בהגדרת הדרישות: המילה shall משמשת לציון דרישות מחייבות, )לפעול בדיוק על פיהן ושסטייה מהן אינה מותרת. Shall( שוה ערך ל- required,is כלומר "נדרש"( המילה should משמשת לציון שמתוך כמה אפשרויות, אחת מומלצת יותר, מבלי להזכיר או לשלול אחרות, או דרך פעולה מסויימת שעדיפה אך לא מחייבת, או )על דרך השלילה( שדרך מסויימת מועדפת פחות, אך אינה אסורה. should( שווה ערך ל- that,is reccomended כלומר "מומלץ"( המילה may משמשת לציון דרך פעולה שהיה מותרת בגבולות המפרט may( שווה ערך ל- to,is premitted כלומר "רשאי") המילה can משמשת באמירות העוסקות באפשרות ויכולת, בין אם הן חומריות, פיזיות, או סיבתיות. can( שווה ערך ל- to,is able כלומר "מסוגל"( אין להשתמש במושגים מופשטים. לדוגמה: and/or, suitable, adequate, first rate, best possible, and others, the like להמנע משימוש במושגים מופשטים. e.g., etc., and i.e. לדוגמה: 98

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

תכולת מפרט על פי MIL-STD-961 100

בעיות נפוצות בהגדרת דרישות בנויות על הנחות שגויות כתיבת פתרונות )איך( במקום דרישות )מה( תיאור פעולות במקום דרישות שימוש במונחים לא נכונים שימוש במבנה משפט לא נכון או דקדוק גרוע דרישות חסרות דרישות יתר )Over-specifying( ע"פ איבי הוקס 101

תבנית נכונה לכתיבת דרישה Requirement ID: Requirement Content Requirement V & V method: Requirement Priority: Requirement Users: Requirement Application: Requirement V & V stage: Requirement Source: Requirement Dependencies: Requirement Conflicts: Comments: Unique identifier A measurable statement of the requirement, written following the writing rules. Analysis, Inspection, System Test, Component Test Safety, Key, Mandatory, Optional, Desirable A list of disciplines that are influenced by the requirement A list of system s units that are influenced by the requirement According to the project life cycle Stakeholder s Name, End user, Derived from doc ID, Standard With other requirement that have an impact on this requirement With other requirement that have an impact on this requirement 102

זיהוי הדרישה )ID( הזיהוי צריך להיות חד חד ערכי, מאפשר מעקב לאורך הפיתוח לא תלוי בסיעוף הדרישה. עדיפות לשימוש במיספור אוטומטי במעבד תמלילים,,excel או מתוך כלי ניהול הדרישות. Word ID1234 3.4.1.1 Stabilization ID1234 3.4.1.1 Stabilization Excel DOORS 103

תוכן הדרישה תאור מדיד ומדויק של הדרישה: The LOS shall remain stabilized during operation with a stabilization error of less than 20 μrad )1s) RMS. System weight shall not exceed 40 kg. 104

שיטת אימות ותיקוף ( Validation & Verification matrix ) שיטת אימות ומימוש הדרישה ניתן לציין מספר שיטות )Enumeration( דוגמאות לשיטות אימות ותיקוף אנליזה Analysis( A( = חיזוי טכני המבוסס על התיכון. בחינה Inspection( I( = השוואה כנגד התיכון. הדגמה Demonstration( D( = ת פעול תחת תנאים רגילים להראות ביצועים מתאימים. בדיקה ( Test T( = פ עילות בתנאים מבוקרים תוך מדידת התוצאות דמיון )Similarity( פעילות דומה לפעילות בפיתוח קודם. יש גם להעריך את דרגת הדמיון. סימולציה )Simulation( הדמייה אשור מסמכים Records( )Validation of סקירת מפרטים ודוחות. סקר תכן Review( )Design 105

עדיפות הדרישה )Priority( מהי העדיפות, בהתאם לחשיבות הדרישה, הן ללקוח והן למערכת. ניתן לציין מספר עדיפויות )Enumeration( דוגמאות לעדיפות הדרישה בטיחות )מחייב מימוש( - Safety מאפיין מפתח )מחייב מימוש( Characteristic Key מתחייב )mandatory( אפשרי )optional( רצוי )desirable( 106

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

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

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

מסמך דרישות לקוח לדוגמה Identifier Contents V&V method Requiremnt D02344 3. Non Functional Requirements No D02345 3.1 Supply Voltage No D02346 3.1.1Nominal supply voltageshoul be 28 4 V Test Mandatory D02348 3.1.2 Supply voltage ripple should be smaller or equal to 0.5 V RMS Demo Mandatory D02678 3.1.3 Supply voltage spikes should be less than 300V and their period should be less than 5 micro-second Test Safety D02679 3.1.4 Supply voltage intrreuption shoud be less than 2 second every 1 per hour or less Test Mandatory 115

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

סקר הדרישות SRR - System Requirements Review ניתוח המאפיינים: מי הם המאפיינים העיקריים המגדירים את המוצר )טכניים, כספיים, לוגיסטיים, איכותיים( האם בוצעה הצלבה בין המאפיינים לצרכים - הצג הצג כיצד ערכי היעד שנבחרו למאפיינים אלה עונים על צורכי הלקוחות מה סדר העדיפויות בין המאפיינים מבחינת המענה לצורכי הלקוח מה מידת הקושי )טכני, לו ז, עלות( בהשגת יעדים אלה.4 :Tradeoffs האם זוהו הזיקות ההדדיות בין המאפיינים לבין עצמם. הצג את הבולטים שבהם.5 מתחרים: הגדר את המתחרים העיקריים הלקוחות( )הנחשבים לטובים בעיני.6 האם המאפיינים שגיבשת במפרט נבחרו בהשוואה למתחרים הנחשבים לטובים ביותר על ידי הלקוח ולמצב הבשלות הטכנולוגית בשוק..7 118

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

סקר הדרישות SRR - System Requirements Review 12. האם הוגדרו יעדי עלות כוללת למוצר האם נלקחו בחשבון דרישות התיישנות,אורך חיים, לתקופה שעבורה הוא תוכנן? רלוונטיות המוצר.13 האם הוגדרו יעדי איכות, אמינות, זמינות, בטיחות, ותחזוקתיות?.14 120

תבנית לסקר דרישות מערכתיות SRR Agenda Management (responsibility of program manager) Program Overview Program Plan Main Deliverables Major Mile Stones IPT Personnel Target Costs (DTC) Intellectual Property Survey Sales, Profit, Cash flow Contractual Requirements & Issues Major Program Risks & Mngmnt Plan Special Infrastructure Required Internal Contracts Status Systems Engineering System Overview General Description Intended use of the system General System Block Diagram Operational Concepts SEMP Presentation Main Customer Requirements Functional Requirements Primary functions Secondary functions Main Customer Requirements )Cont d( Non-Functional Requirements System Requirements Safety Requirements Performance Requirements Security Requirements Packaging Requirements Interoperability Requirements Scalability Requirements Interface Requirements Electrical Interface Software Interfaces Mechanical, Opto- mechanical & Electro- mechanical interfaces Optical Interfaces Stabilization and enslavement HMI & Human Factor Requirements Other Requirements COTS System Solutions Reused Components Constraints, Dependencies, Conflicts Infrastructure Issues Reuse, Generic Design Compliance Matrix CDRL Status Issues 121

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

מהו מפרט? Identifier D02344 D02345 D02346 D02348 D02678 מפרט המוצר הוא תיאור מדויק של מה המוצר אמור לעשות Contents 3. Non Functional Requirements 3.1 Supply Voltage 3.1.1Nominal supply voltageshoul be 28 4 V 3.1.2 Supply voltage ripple should be smaller or equal to 0.5 V RMS 3.1.3 Supply voltage spikes should be less than 300V and their period should be less than 5 micro-second רשימה של דרישות טכניות )להבדיל מדרישות לקוח( מפרט טכני מורכב מלפחות: תכונה ערך תהליך בדיקה עדיפות לאילו מכללים רלוונטי לאילו דיסציפלינות רלוונטי דוגמא: V&V method Test Demo Test Requiremnt No No Mandatory Mandatory Safety Discipline Power Electronics Power Electronics Power Electronics Units PSU PSU PSU, LGU תכן הנדסי SCE תשע"א 125

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

דוגמה לעץ מפרטים מסמך דרישות לקוח System Spec. Operational Spec. Functional Spec. EU S/W requierments Spec. DU S/W requierments Spec. EU Power Supply Spec. EU Spec. GU Spec. DU Spec EU Logic CCU Spec. 127

תבנית לכתיבת מפרט פיתוח Requirement ID: Requirement Content Requirement V & V method: Requirement Priority: Requirement Users: Requirement Application: Requirement V & V stage: Requirement Source: Requirement Dependencies: Requirement Conflicts: Comments: Unique identifier A measurable statement of the requirement, written following the writing rules. Analysis, Inspection, System Test, Component Test Safety, Key, Mandatory, Optional, Desirable A list of disciplines that are influenced by the requirement A list of system s units that are influenced by the requirement According to the project life cycle Stakeholder s Name, End user, Derived from doc ID, Standard With other requirement that have an impact on this requirement With other requirement that have an impact on this requirement 128

תהליך קביעת מפרט הפיתוח מפרט פיתוח לדוגמה D02345 D02346 D02348 D02678 D02679 3.1. מתח אספקה: 3.1.1 המתח שיוזן למערכת הוא 28 4 וולט 3.2.1 אדוות מתח הכניסה )Ripple( לא תהיה גדולה מ- 0.5 וולט.RMS 3.1.3 מתח הדורבנים )Spikes( באספקת המתח לא יעלו על 300Vואורכם לא יעלה על 5 מיקרושניות 3.1.4 הפסקת מתחים: המתח יוזן ברציפות, למעט הפסקות שאורכן לא יעלה על 2 שניות וקצב ההפסקות לא יעלה על 1 בשעה 129

תהליך קביעת מפרט הפיתוח מפרט פיתוח לדוגמה Identifier Contents V&V method Requirement D02344 3. Non Functional Requirements No D02345 3.1 Supply Voltage No D02346 3.1.1Nominal supply voltageshoul be 28 4 V Test Mandatory D02348 3.1.2 Supply voltage ripple should be smaller or equal to 0.5 V RMS Demostration Mandatory D02678 3.1.3 Supply voltage spikes should be less than 300V and their period should be less than 5 micro-second Test Safety D02679 3.1.4 Supply voltage intrreuption shoud be less than 2 second every 1 per hour or less Test Mandatory 130

תהליך קביעת מפרט הפיתוח מפרט פיתוח לדוגמה Identifier Contents V&V method Requiremnt Discipline Units D02344 3. Non Functional Requirements No D02345 3.1 Supply Voltage No D02346 3.1.1Nominal supply voltageshoul be 28 4 V Test Mandatory Power Electronics PSU D02348 3.1.2 Supply voltage ripple should be smaller or equal to 0.5 V RMS Demo Mandatory Power Electronics PSU D02678 3.1.3 Supply voltage spikes should be less than 300V and their period should be less than 5 micro-second Test Safety Power Electronics PSU D02679 3.1.4 Supply voltage intrreuption shoud be less than 2 second every 1 per hour or less Test Mandatory Power Electronics PSU, LGU 131

מטריצת אימות המפרטים מפרט פיתוח לדוגמה Identifier Contents V&V method Requiremnt Comply Notes D02344 3. Non Functional Requirements No D02345 3.1 Supply Voltage No D02346 3.1.1Nominal supply voltageshoul be 28 4 V Test Mandatory Yes D02348 3.1.2 Supply voltage ripple should be smaller or equal to 0.5 V RMS Demo Mandatory Yes D02678 3.1.3 Supply voltage spikes should be less than 300V and their period should be less than 5 micro-second Test Safety Partially Depends in volume restrictions D02679 3.1.4 Supply voltage intrreuption shoud be less than 2 second every 1 per hour or less Test Mandatory Yes 132

ניהול מאפייני מפתח )Key Chracteristics( מפרט פיתוח לדוגמה Comments Comply Risky Risky Risky Subsystem Pod A Kit Discipline Aerodynamics Mechanics System Req KC KC KC תוספת גרר המערכת לא תעלה במטוס בואינג 747-800,על 0.3% סכום משקל המערכת ומשקל ממשקיה לפלטפורמה, לא יעלה על 250 ק"ג TBR( עד )PDR נדרש להחליק את פני השטח לטיב של טפ"ש 11 או להוריד את פרופיל המערכת ב- 3 ס"מ )מגדיל משקל( 285 ק"ג-אפשרי ללא שינוי תכן ALL Aerodynamics System Elect. Mechanics System זמן ממוצע בין תקלות, החזוי בתנאי הפעולה הנגזרים מפרופיל מחזור החיים של המערכת, ובמעטפת הטיסה של המטוס יהיה 9000 טיסות נדרש לפתח טכנולוגיה להכפלת אמינות ממסרי K4-K15 All Active Aerodynamics Electronics Mechanics System ID 87 334 360 133

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

כתיבה נכונה של מפרט מבנה המשפטים קצר ופשוט התייחס למערכת, לא למפעיל השתמש בזמני פו ע ל כלהלן: "shall" מציין מפרט מחייב המנע )is required( will" מ" סמן את כוונת הכותב should" מ" ציין עדיפות, כהמלצה, על כמה אפשרויות אחרות )is reccomended that( "Can" משמעותו "יכול" או "מסוגל" to( )is able "may" - רשאי בגבולות המפרט )is premitted to( "must" מעורפל עם מס' מובנים )"John must love Mary"( "משינויים אלגנטיים" בניסוח השתמש תמיד באותה צורת ניסוח המנע מייחוס למסמכים חיצוניים, אלא אם חובה לעשות זאת - ובדוק אותם... אין להשתמש בראשי תיבות, אלא אם הם מוכרים בודאות לכל בעלי העניין e.g., etc., and i.e. המנע מהכללת יתר "Always, Every, all, Never, None אין להשתמש במושגים מופשטים,"adequate","suitable","and/or" and ","best possible","first rate" "the like","others מנע צירופים כפולים "הדבק והצמד או סמרר.." 137

חוסר בהירות שאינו מתקבל השמטת מילים "הגנרטור יספק למעבד 10.5 אמפר ולסוללות 8.5 אמפר" מילים לא ברורות )יסודות וגם בסיס( foundations "The second floor shall have חוסר בהירות תחבירית "Flying aircraft may be hazardous הבנת משפט שתלויה בנקודת המבט The chicken is ready to eat )מה מסוכן-ההטסה או המטוס?( 138

התפתחות הדרישות במודל V לפיתוח User Needs User Requirements Requirements Verification System Specifications & Design מפרט מערכת Spec. Verification Subsystem Specifications & Design Detailed Design תהליכי תיקוף תהליכי אימות Needs Validation Requirements Validation Performance Validation Performance Validation Performance Unit Validation Integration & Testing Prototypes Development & Configuration control User Acceptance Testing System Integration & Testing Subsystem Integration &Testing System Validation in its Environment התאמה לצרכי הלקוח התאמה לדרישות הלקוח התאמה למפרט מערכת התאמה למפרטי המכללים צרכי לקוח דרישות לקוח מפרט מכללים 169

שלבי הכנת מפרט הפיתוח )1( הכנת מפרט פיתוח תרגום דרישות הלקוח למפרטים המבוטאים בשפת המפתח, ומאפשרים פיתוח מוצלח ובדיקות המוצר וקישור דרישות אלו עם דרישות הלקוח תיקוף המפרטים Verification( )Requirements כתיבת מפרטים ותהליכי בדיקה כדי לוודא שהמערכת תוכננה נכון ועושה מה שהיא אמורה לעשות, כלומר מתאימה לדרישות המשתמש. )Bahill( וידוא כי מפרטים: נחוצים ברי בדיקה ברי השגה אינם משתמע לשני פנים מבטאים תכונה יחידה ייחודיים שלמים עקביים לא כוללים דרך מימוש ניתנים להקצאה מתומצתים כתובים בשפה סטנדרטית 170

קביעת קונספט המערכת, תיכון מערכתי והכנה ל- SDR יש לבצע את הפעילויות הבאות: ניתוח תפקודי Analysis(,)Functional ניתוח סיכונים והגדרה ראשונית של המערכת. בחינת חלופות מערכתיות ובחירת הפתרון המתאים ביותר בדיקת התאמת התיכון המערכתי לצרכי הלקוח, לסביבה המערכתית וליעדי התוכנית. בדיקת אפשרויות Reuse ו/או תכן גנרי ביצוע מטלות בטיחות תכנון ראשוני של מהלך האינטגרציה לעדכן את מסמך בקרת הממשקים )ICD( המערכתי )החיצוני( לעדכן את מפרטי הפיתוח להקצות ראשונית מפרטי פיתוח למכללים 171

)1/2( SDR Agenda Management (responsibility of program manager) System Overview General Description System s purpose Customers System s operational environment SRR Action Items Status Organizational Structure Personnel Schedule Milestones Planned & Status Internal Contracts Status DTC Estimate of development and production cost Estimate of goals achieved System Analysis Main Development requirements Functional Analysis Performance Analysis Trade-offs Analysis קורס תבנית לדוגמה לסקר תיכון מערכתי System Engineering Concept Evaluation Basic problems of the system is to be solved Possible solution to the basic problems Alternative selection criteria Morphological map for alternative generation System alternatives ranking System s Alternatives Description Description & block diagram Concept Reuse Development and Production Cost & Schedule Reliability, Maintainability, Safety Weight Power consumption Risks Main advantages Main disadvantages Winning Alternative Elaboration Development Spec. Issues System Design ICD Key Characteristics Error Budgets Allocation Operational Flow Diagram 172

)2/2( System Engineering (cont.) Activity Modes (State Diagram) Sub-Systems & Assemblies Reuse Generic Design Decisions Safety Requirements and Status Preliminary Integration Plan Main integration steps Needed resources Models & Experiment Plan Preliminary V & V Plan Technical Risk Analysis & Status Intellectual Property Survey Compliance Matrix CDRL Status Issues קורס תבנית לדוגמה לסקר תיכון מערכתי 173

תוכן העניינים מבוא איסוף צרכי לקוח תרגום הצרכים לדרישות ניתוח תפקודי ניתוח מבצעי של צרכי המערכת סוגי הדרישות )תפקוד, תכונות, התנהגות( סיווג הדרישות כתיבת הדרישות מסמך דרישות הלקוח סקר SRR מדרישות למפרטים כתיבת המפרטים ניתוח המפרט סקר SDR הקצאת מפרטים ליחידות וסקר PDR תכן מפורט, בקרת תצורה וסקר CDR תיקוף ואימות הדרישות ניהול דרישות בכלים ממוחשבים ואני רק רציתי לעבור את הנהר... 174

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

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

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

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

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

שיטות הקצאה הקצאה ישירה הדרישות משורשרות ישירות לרמות הנמוכות יותר הניסוח מועבר כפי שהוא ברמה הנמוכה יותר הקצעה מספרית חלוקה של הדרישה המספרית בין המרכיבים ברמה הנמוכה יותר השהיה מערכתית 2 שניות גזירת המפרט ממשקים 0.4 שניות אלקטרוניקה 0.3 רזרבה שניות 0.2 שניות תוכנה 1.1 שניות הקצאה לאחר איסוף הדרישות מהרמות הנמוכות המקור יכול להיות נסתר, אך בר זיהוי 180

הקצאה ישירה לדוגמה: אספקת החשמל המערכתית תתבסס על מתח רשת של 230VAC 15% הכניסה לספק הכח תתקבל ממתח רשת של 230VAC 15% שנאי הכניסה יוזן ממתח רשת של 230VAC 15% המערכת תפעל באופן אוטומטי ללא מעורבות אדם תוכנת הבקרה תפעל באופן אוטומטי ללא מעורבות אדם בקר הטמפרטורה יפעל באופן אוטומטי ללא מעורבות אדם המערכת תכיל מגבילי בטיחות שיאפשרו פעולה אוטומטית ללא מעורבות אדם ראשוני 181

הקצאה מספרית דוגמה: המערכת תיתן אתראה קולית בעוצה של 70 ד"ב לפחות, מרגע שינוי הטמפרטורה בתוך פחות מ- 2 שניות בקר הטמפרטורה יתריע על שיוני הטמפרטורה בתוך פחות מ- 0.3 שניות כרטיס הבקרה יוציא אות אתראה לאחר לא יותר מ- 0.5 שניה מרגע קבלת הודעת שינוי הטמפרטורה מערכת האזעקה תאמת שאות האתראה שהתקבל נגרם עקב שינוי בטמפרטורה ותפעיל את מערכת האזעקה בתוך 1.2 שניות לכל היותר. האזעקה תפיק צליל בעוצה של 70 ד"ב לפחות 182

גזירת המפרט דוגמאות: שמירת דיוק קו הראיה בין מערכת התצפית למרכז המכני של הטלסקופ תהיה טובה מ- 2 מילירדיאן למשך זמן של חודשיים המרכז האופטי בטלסקופ לא יסטה במשך חודשיים ביותר מ- 0.3 מילירדיאן מישוריות ההתקנה של מערכת התצפית לא תזוז ביותר מ- 0.5 מילרדיאן במשך חודשיים מרכז שדה הראיה של מערכת התצפית לא יזוז ממישור ההתקנה ביותר מ- 1 מילירדיאן במשך חודשיים המזגן יוכל להיות מותקן לפחות ב- 80% מבתי האב ללא שינוי גודל המזגן לא יעלה על 150x300x1000 מ"מ המזגן יכלול מערכת הפעלה שתוכל להפעילו ממרחק של 4 מ' לפחות צבע המזגן יהיה לבן מסוג 101 פינות המזגן יעוצבו בקווים מעוגלים ברדיוס של 60-40 מ"מ 183

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

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

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

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

שלב התכן הראשוני )3( לקראת סקר תיכון ראשוני, יוכנו המסמכים הבאים, בסיוע התחומים המקצועיים הרלוונטיים: מסמך תוכנית בטיחות ראשוני, שכולל: System Functional Hazard Assessment Preliminary Hazard List הקצאת סכנות לדיסציפלינות וממשקים מסמך PDR יעודכנו המסמכים הבאים: מסמך תצורת המערכת )איכות( מפרט פיתוח מערכת מפרט תפקודי )אם נדרש( מפרט תפעול )אם נדרש( מסמך בקרת ממשקים, ICD מערכתי )חיצוני( מסמך דרישות הלקוח מהנדס המערכת מסייע לאנשי אפ"א ולמנהל הפרוייקט בעדכון תוכנית ניהול סיכונים. בתום השלב, מתקיים סקר תיכון ראשוני )PDR( להכין תוכנית אבטחת איכות 189

)1/2( קורס תבנית לסקר תכן ראשוני PDR Agenda Management (responsibility of program manager) System Overview General Description System s purpose Customers System s operational environment Main requirements SDR Action Items Status Personnel Organizational Structure Milestones Planned & Status Critical Items (i.e. LLI, Single Source, Export License) Internal Contracts Status DTC Estimate of development & production cost Estimate of goals achieved Management (cont,) Systems Engineering Error Budget Analysis & Allocation System Design System Interfaces Description Performance Analysis Tradeoffs Considerations Requirements Allocation to Disciplines & System Components System Component Alternatives Description System Component main requirements Subsystem Interfaces Description Safety Safety Requirements & Status System Functional Hazard Assessment Preliminary Hazard List Safety Allocation 190

)2/2( קורס תבנית מסמך סקר תכן ראשוני System Engineering (cont.) Key Characteristics Installation & Modeling Models & Experiment Plan Status V & V Plan System Configuration (tree) Discipline Concepts Physics, Optics, Material Eng Mechanics, Opto-mechanics Electronics, Embedded Software, Navigation & Servo, Power, EMC MFG., QA, RAMS, Test Equipment, ILS & Customer Support Master Integration Plan Integration Process General System Integration Plan Subsystem Integration Process Integration Schedule Resources Summary System Integration Resources System integration documents Compliance Matrix Technical Risk Analysis & Status Intellectual Property Survey CDRL Status Issues 191

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

תיכון מפורט )2( עדכון המסמכים הבאים: מפרטי פיתוח המערכת, מפרט תפקודי )אם נדרש(, מפרט תפעול )אם נדרש(, ומפרטי הדרישות של מרכיבי המערכת מסמך בקרת ממשקים, ICD פנימי מפרטי פיתוח המכלולים תוכנית אינטגרציה- MIP )+סטטוס סימולטורים ותשתיות( סיוע למנהל האיכות בעדכון מסמך תצורה סיוע למנהל הבטיחות לתוכנית לעדכן את מסמכי הבטיחות בתום השלב יועברו מסמכי התיכון לרמה המתאימה בהתאם לתהליך ניהול תצורה, יעודכן דוח סטטוס בקרת התצורה ויתקיים סקר תיכון קריטי )CDR( 194

)1/2( )לקראת )CDR CDR Agenda Management System Overview General Description System s operational environment Main requirements PDR Action Items Status Personnel Organizational Structure Milestones Planned & Status Critical Items (LLI) Status DTC Intellectual Properties Protection Plan Internal Contracts Status System Engineering System Major Requirements Lesson learned from similar projects Error Budgets Analyses Subsystems Major Requirements קורס תבנית סקר תכן קריטי System Engineering (cont.) Major Detailed System & Sub System Design External & Internal ICD Subsystem and LRUs main requirements Integration Plan Status Infrastructure and resources Simulators and analyses issues Safety Safety Plan Status Hazard Analyses Safety Analysis Configuration Control Status RAMS Analysis Proof of Design Plan ILS Plan Status Test Equipment Status 195

)לקראת )CDR )2/2( System Engineering (cont.) Assimilation Plan Key Characteristics Status Models & Experiments Status Drawings Freeze Status (in PDM) Integration and V & V Plans Production Flow Diagram Production Issues Acceptance Procedures (ATP), Qualification Procedures (QTP) &First Article Inspection (FAI)- (prepared by QA System Compliance Matrix Discipline Designs Main requirements Design status Design considerations Producibility Considerations, Calibration, TE, Setups Performance analyses & simulations קורס תבנית סקר תכן קריטי Discipline Designs (Contd.) Error Budgets analyses Drawings freeze status V & V plan Discipline Compliance Matrix Issues Intellectual Property Survey Technical Risk Analysis & Status CDRL Status Issues 196

שיטת אימות ותיקוף )Validation & Verification matrix( שיטת אימות ומימוש הדרישה ניתן לציין מספר שיטות )Enumeration( דוגמאות לשיטות אימות ותיקוף אנליזה Analysis( A( = חיזוי טכני המבוסס על התיכון בחינה Inspection( I( = השוואה כנגד התיכון, מתבצע על על היחידות או באופן מדגמי הדגמה Demonstration( D( = ה פעלה בתנאי פעולה רגילים להדגמת הביצועים בדיקה ( Test T( = פעילות בתנאים מבוקרים תוך מדידת התוצאות דמיון similarity( S( = By פ עילות דומה לפעילות בפיתוח קודם. יש גם להעריך את דרגת הדמיון אשור מסמכים Records( )Validation of סקירת מפרטים ודוחות. סימולציה )Simulation( הדמייה בדיקה ואישור בסקר תיכון Review( )Design 198

אימות ותיקוף השלב בתהליך הפיתוח בו מבוצעים שלבי האימות ומימוש הדרישה, בהתאם למחזור החיים של התכנית ניתן לציין מספר שלבים בהם נבדק המוצר או חלק מהמוצר )Enumeration( בעת התיכון )Design( בעת אימות התיכון )Qualification( בעת הכניסה לייצור Article( )First בעת הייצור )Production( 199

תיקוף דרישות הערך כל דרישה קבע את השיטה הסבירה ביותר לאימות מבחינת יחס עלות-תועלת קבע מתי התיקוף נדרש קבע את תהליך התיקוף 200

מסגרות זמן התיקוף אנליזות דמיון סימולציות הגדרת דרישות תיכון מערכתי תיכון ראשוני תיכון מפורט ייצור דגם, בדיקות הצגות בחינות קידוד, בדיקות אינטגרציה QUAL FQR TRR CDR PDR SDR SRR 201

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

למה לנהל עקיבות? Satisfies Satisfies Satisfies Satisfies שינוי בדרישת לקוח Customer Reqs System Reqs H/W Reqs או שינוי בהקצאה דיסציפלינארית Customer Reqs System Reqs H/W Reqs 204

כמה דרישות יש בפרוייקט אופייני? גודל הפרויקט מס' מהנדסים חודשי עבודה מספר מודי פעולה מספר דרישות דוגמאות קטנטן 3 4 3 150 )כרטיס אלקטרוני, קופסת אלקטרוניקה( קטן 15 8 30 1,000 מוצר קטן )מקלט טלויזיה, מכשיר טלפון( בינוני 75 36 100 2,500 מוצר מערכתי )מרכזית טלפונים( גדול מאד גדול 1,000 400 30 48 1,000 500 50,000 10,000 מערכת מורכבת מערך )SOS( )מע' תקשורת למפעל( )מטוס, שדה תעופה( Factors Influencing Requirement Management Toolset Selection By the INCOSE Requirements Working Group (1995) 205

למה צריך כלים ממוחשבים פעילות ניהול הדרישות בפרויקט היא פעילות הכוללת את היכולת: להתייחס לכמויות של מסמכים שונים לראות בצורה תמציתית את הקשר בין המסמכים לדלות מידע מתוך המסמכים ליצור VIEWS מיוחדים ע"י סינון וסידור לשלוט בשינויים בסט של מסמכים בצורה עקבית לטפל בדרישות שונות למבנה וסוגי מסמכים פרויקט טיפוסי בגודל בינוני מכיל כ- 2500 דרישות שונות Source: The Future of Requirements Management Tools by Anthony Finkelstein & Wolfgang Emmerich 206

איזה מידע צריך לנהל? צרכי לקוח דרישות לקוח מפרט מערכת מפרט מכלול Satisfies Satisfies Satisfies Tests Tests Tests Tests תקנים ונוהלים בדיקות קבלה בדיקות מערכת אינטגרצית מערכת בדיקות יחידה 207

איזה מידע מנהלים באיזה שלב SRR SDR Qual Site IRR אינטגרציה מערכתית אינטגרציה של מרכיבי המערכת בדיקות יחידה ייצור ובדיקת הדגם מפרט פיתוח דיסציפלינרי תוצרי התכן צרכי לקוח דרישות לקוח מפרט פיתוח המערכת PDR CDR סקר הצעה TRR FQR 208

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

בחירת הכלי הכלים הממוחשבים לניהול דרישות נבדלים בארכיטקטורה: מבוסס מסמך - הדרישות נשמרות במלל של המסמכים. הכלי מאפשר חיפוש, מיון וסינון במסמכים )כמו.)Requisite Pro מבוסס בסיס נתונים - הכלי מאפשר להפיק מפרטים מתוך הדרישות. כלים אלה מחולקים לשלוש רמות : בסיסית, מורחבת )כמו,)DOORS אנליטית )כמו )CORE דרישות מהכלי: יכולת איסוף דרישות, איחסונן, סיווגן ומיונן זיהוי Identification.Unique זיהוי הדרישה בצורה חד חד ערכית. הקצאה.Alocation מאפשר לזהות את ההקצאה של כל דרישה לאנליזה, דיסציפלינה, או בדיקה ניהול שינויים. ניהול השפעת שינויים - הצבעה על כל הגורמים הקשורים לכל שינוי ממשקים. לכלי יש ממשקים המאפשרים לייבא ולייצא מידע, למשל לכלי ניהול ניסויים ותקלות. בדיקת סטטוס מימוש הדרישות בדיקת סטטוס בדיקות הדרישות ניהול תצורת המפרטים-הקפאת גירסאות בסקרים וקביעת Baselines 210

כלי ניהול דרישות בשוק 212

DOORS 215

הכנסת דרישות הלקוח ל- DOORS 216

מבנה הדרישות ב DOORS 217

Attributes DOORS 218

קישורים וסינון DOORS קישורים 219

הדפסה לקובץ 220

הפקת מסמך מ- DOORS ל- WORD ניתן להגדיר תבנית עבודה, פונטים, עמודות ועוד. 221

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

מאפשר לראות בצורה גרפית, את כל הקישורים הנכנסים אל המודול והיוצאים ממנו. לחיצה על הפלוס, מראה מידע על האובייקט בצד השני של הקישור. נתוני עקיבות ב DOORS - Show Object מאפשר לפתוח את האובייקט המקושר 225

קשר חשוד Link Suspect שינוי ב PS8 קישור חשוד ב PS4 0 בדיקת הקישור החשוד עשיתי רק כמה שינויים קטנים... 226

Traceability Columns 227

דוגמא לדו"ח עקיבות DOORS 228

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

תודה על ההאזנה 230