T&E

T&E Table
תמצית האירוע תמצית הלקחים סוג פרויקט סוג תקלה חומרת התקלה קובץ לפרטים נוספים
בזמן טיסה יצא מכלל פעולה חלק ממערכת נגד צבירת הקרח באחד ממשטחי ההיגוי. הדבר גרם לשיבוש נחיתה והביא לסכנת קריסת המטוס יחד עם הצוות. בתכן המערכת לא נקבע כי הפסקת פעילות של חלק מהמערכת מהווה CI ולא נקבעו דרישות הולמות למרות קיום ידע מוצק על סכנת צבירת קרח אפילו באחד ממשטחי ההיגוי. ניתן לראות בכך הפרת כללי DT&E וטעות קריטית בהגדרת דרישות. תעופה וחלל חוסר דרישות אירוע בטיחותי מאגראירועים ל T&E 2010\tupolev aircraft Tu-154M 16.9.2010.pdf
חוסר דרישות לבדיקה
המערכת הינה מערכת הגנה לספינות מפני טורנדו. תפקידה לזהות איום, למקמו, להציע תמרון התחמקות ולאתר מקור האיום. התכן הוגדר כבל סיכון נמוך שבל שימוש במערכות זיהוי טורפדו קיימות. אך עם זאת המשימה שהוגדרה למערכות הייתה חדשה ומורכבת.תוכנית הניסויים כללה ניסויי תתי מערכות בנפרד וכן על פלטפורמה קטנה מפרופיל המשימה המקורי. המערכת נבדקה בכללותה על פלטפורמה בקנה מידה מלא רק בשלב הניסויים האחרון האגמי בלבד. הניסויים הראשונים הוכתרו ככישלון חרוץ. א. יש לשמור על קשר בין מערך הניסוי לאופן הפעולה במציאות
ב. יש להשארבגבולות גזרה ניתנים למדידה וניסוי
ג. אין לבצע ניסוי במערכת ישנה עם משימות חדשות
ד. אבטחת מוכנות לניסוי חשובה
ה. אין לבצע ניסוי אגמי מוקדם מידי
ו. להזהר מלבצע ניסוים חוזרים
ז. להזהר מלבצע אנליזה חוזרת
ח. להקפיד על אימות סימולציות
ט. להימנע מניסוי עם מטרות מלכותיות
י. חשוב להבטיח שדה ניסויים זהה זמין
צבאי מרכיבי REUSE שלא נדרש לבדוק מג’ורית- ביצועים בלתי מספקים, כשלון ניסוי אגמי , אי עמידה  בביצועים, עלות ובלוח הזמנים etl20112003\SSTD 15.3.doc
חוסר בדרישות לבדיקת יכולת פעולה הדדית (יפ”ה)
לא בוצעו בדיקות אינטגרציה
אי שילוב בדיקות OT&E בשלבים מוקדמים
סביבת בדיקות לא מתאימה
בשנת 2007 התרחשו מספר ארועים של נעילת דוושת האצה ברכבי טויוטה – בארועים הללו נפגעו מספר אנשים. החשד שעלה הוא כי הגורם לנעילה הוא “גלישת” שטיחון אל מתחת לדוושה. מאוחר יותר בשנים 2007 ו-2008, לאחר שהתרחשו מספר תאונות, חלקן קטלניות, טויטה ביצעה ריקול לעשרות אלפי ממכוניותיה מדגמים שונים. לאחר חקירות רבות, שאותן הובילה הרשות לבטיחות בדרכים של ממשלת ארה”ב, התברר כי בחלק מן המקרים בהם הדוושה נתקעה במקומה, התופעה נגרמה עקב שחיקה במנגנון הדוושה. וזאת ללא קשר לנוכחות שטיחון על רצפת הנהג. התברר כי שורש הבעיה נעוץ בכך שדוושת ההאצה שהמנגנון שלה אלקטרוני בחלקו, תוכננה כך שתיתן “הרגשה” כאילו היא דוושה מבוססת מנגנון מכאני בלבד כפי שהיה נהוג להתקין בדגמי מכוניות בעבר. החלק שאחראי על החזרת הדוושה למקומה וסגירת המצערת הוא קפיץ (במקום בוכנה הידראולית בדוושות מהסוג הישן). לאחר שחיקת חלק מסויים בדוושה החדשה, הקפיץ לא היה מסוגל להתגבר על כוח החיכוך שנוצר. א. בעת פיתוח מנגנון עיקרי חדש ברכב, תכנית הבדיקות צריכה להתמקד ראשית כל בהיבט הבטיחותי, ורק לאחר מכן בהיבט הנוחות למשתמש.
ב. שינוי כלשהו במערכת ההאצה של הרכב דורש תכנית בדיקות קפדנית שתשלול כל אפשרות לסכנת חיים, כתוצאה מטעות אנוש ולא רק כתוצאה מטעות בתכן.
ג. יש לתכנן בדיקות מקפידות לכלל מערכות הרכב,ומרכיביה הפשוטים ביותר כמו למרכיביה המסובכים יותר.
ד. 4. יש להשתמש בתלונות לקוח ככלי לשיפור המוצר ולתכנון בדיקות. אין בשום אופן להתעלם מהתלונות ללא בדיקתן.
תעשיית רכב חוסר דרישות לבדיקה קריטית – כשל משימה, הפסד השוק,
אירוע בטיחותי, איום על קיום הארגון, סטייה משמעותית בביצועים, עלות ובלוח זמנים (מעל 20%).
etl20112003\toyota gas pedal malfunction 1.3.pdf
לא בוצעו בדיקות לאחר שינוי
לא נחקרו דיווחי לקוחות
עבור אישור בטיחותי למשאיות התובלתיות בצה”ל בוצע ניסוי יציבות כמוגדר ב SOW ע”מ לאשרה למהירות 80 קמ”ש (מעבר של מהירות 73 מאפשר לאשר למהירות 80). המשאית עברה את הניסוי במהירות גבולית של 73 קמ”ש, אך בהסתכלות על העבר (10 שנים אחורה!) זה מהווה ירידה בביצועים לעומת המשאיות הקיימות ולכן הוחלט לבצע שיפורים וניסויים נוספים. כלל אספקת המשאיות נעצרה עד למציאת פיתרון טכני לשיפור יציבות המשאית. מתברר שמדד היציבות שהוגדר אינו מדד מספיק לשביעות רצון הלקוח ויש להגדיר מדד שונה. עקב כך תוכנן מדד חדש “מדד בטיחות” המשקלל פרמטרים נוספים: תאוצות צד, שאלון נסיעה התרשמותית ומדדי הנדסת אנוש. א. בפיתוח מוצר שהינו תחליף משופר למוצר קיים, יש לדרוש מדדים המגדירים שיפור ביצועים יחסית למוצר הקיים.
ב. בהגדרת מדדים במפרט, נדרש לשים לב להגדרת מדדים המגלמים בתוכם גם את שביעות רצון הלקוח או התאמה לדרישות הלקוח.
ג. עם תכנון שיטת הבחינה והניסויים נדרש לבצע הערכת סיכונים לכל אחד משלבי הבחינה והשפעתו על המשך התהליך.
ד. על צוות הבחינה להיות מקיף ככל הניתן ולכלול גורמים מכל אורך מחזור החיים של המוצר
ה. יש לבצע את בחינת המוצר בתנאים הקרובים ביותר למתאר הפעילות בפועל של המוצר.
בטחוני / צבאי אחר (אגף הטכנולוגיה והלוגיסטיקה) חוסר דרישות לבדיקה מינורית – אי נוחות, סטייה קלה בביצועים, בעלויות ובלוח הזמנים (עד 5%) etl20112003\transport trucks stability 1.3.pdf
דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
תעשיית רכב אי שילוב בדיקות OT&E בשלבים מוקדמים
ב-1998 בוצע פיתוח קשתות התהפכות לרכב שטח. לאחר בחינת הקשתות הורכבו הקשתות ע”ג מס’ כלים. לאחר מספר שנים אירע אירוע של כשל בקשת התהפכות כתוצאה מהתהפכות. מבדיקת הקשתות נמצא כי ישנו כשל בריתוך הקשתות בתהליך הייצור של הקשתות. הכשל לא זוהה בתהליך הייצור היות ולא בוצעו בדיקות מתאימות לקשתות. 1. בעת ביצוע ריתוכים יש להגדיר בדיקות מלאות לריתוך ולוודא בדיקות כגון רדיוגרפיה או אולטרה סונית לריתוכים. תעשיית רכב דרישות שלא נבדקו. קריטית – כשל משימה, הפסד השוק, אירוע בטיחותי, איום על קיום הארגון, סטייה משמעותית בביצועים, עלות ובלוח זמנים (מעל 20%). etl20112003\supporting arc 1.3.doc
2. בעת שימוש בקבלני משנה נדרש לבצע בדיקות תקופתיות לתהליכי הייצור ולמוצרים עצמם של הקבלן, כולל במקרים בהם נדרשת בדיקה הורסת. בטחוני חוסר בציוד בדיקה מתאים
במסגרת פרויקט שדרוג חבילת התוכנה של Office 2007 בארגון אירעו מספר תקלות בהיבטי T&E. תקלות אלו הובילו לאי-יכולת של משתמשים רבים לתפעל את מערכות התוכנה שלהם במשך מספר ימים, ולעיכוב רב בהשלמת הפרויקט. ניתוח האירוע העלה מספר כשלים:

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

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

ג. העדר בקרה מספקת בשלב הפצת התוכנה.

הלקחים המרכזיים שהופקו מניתוח האירוע הינם:

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

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

ג. ניהול תצורה הדוק בעת עדכון גרסאות התוכנה ו/או סביבת הבדיקה.

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

מערכות תוכנה חוסר בדרישות לבדיקת יכולת פעולה הדדית (יפ”ה), דרישות שאינן כלולות בתוכנית הבדיקה, סביבת בדיקות שאינה מנוהלת תצורה. מג’ורית- סטייה בינונית בביצועים, בעלות ובלוחות הזמנים של הפרויקט (כ-15%). T&E 2010\updating ‘office’ computer progrem 16.9.2010.pdf
התאונה אירעה ב 3 ליוני 1998 בסמוך לעיר Eschede בזמן נסיעה שגרתית של הרכבת.  כדקה לפני התאונה כשל החישוק החיצוני של הגלגל וחדר לתוך קרון הנוסעים. כתוצאה מהכשל ירדה הרכבת מהפסים ובהמשך התנגשה בגשר בטון והתהפכה. כתוצאה מהאירוע נספו 101 אנשים ו 88 נפצעו באורך קשה. הסיבות לאירוע כפי שעלו מחקירה שבוצעה היו:

א) הגלגל לרכבת נבחר בהסתמך על ביצועי גלגל של רכבת עירונית שמשמעותית יותר איטית.

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

ג) לא נלקח בחשבון השינויים בכוחות הדינמיים כתוצאה משחיקה של הגלגל.

ד) בדיקות תחזוקה לא בוצעו ע”י כלים מתאימים ורלונטיים לאיתור הכשל.

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

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

א)  במקרה של חריגה מנתוני המפרט הבסיסיים יש לבצע אוולואציה מלאה ולא להסתמך על אינטרפולציה או על חישובים תיאורטיים.
ב) קיים צורך לביצוע ניסויי מעבדה מקדימים המדמים את מחזור חיי הרכיב במיוחד כאשר נלווה מרכיב שחיקה לתהליך.
ג) קיימת חשיבות של מדידה מקיפה של עומסי השירות הריאליים הפועלים במערכת ולהעמקת הבנת התופעות הדינמיות הנלוות ומשמעותן על אמינות הרכיב.
ד) בהנחה וקיים מרכיב שחיקה בתהליך יש להגדיר מערך בדיקות תחזוקה אשר יוודא בצורה פוזיטיבית את תקינות הרכיב.  במקרה זה חיישן רעידות יכול לשמש לניטור התקלה.
ה)  במקרה ועולות תלונות מצד הלקוח או היצרן יש לבצע מחקר טכני מקיף לאישור תקינות המוצר. כל חריגה מנתוני או דרישות יצרן נדרשת להיות מלווה במחקר המאשר את החריגה.
תעשיית רכב ותחבורה דרישות שלא נבדקו – לא נבדק תפקוד הגלגל במהירות גבוהה לאורך זמן קריטית – כשל משימה, הפסד השוק, אירוע בטיחותי, איום על קיום הארגון, סטייה משמעותית בביצועים, עלות ובלוח זמנים (מעל 20%). etl20112003\eschede train disaster 1.3.pdf
דרישות שלא יודעים איך לבדוק – חוסר תשתית לבדיקת מעטפת ביצועי הגלגל.
 ציוד בדיקה אינו מתאים לשלב מחזור החיים הנדרש – ציוד התחזוקה לא התאים לאיתור התקלה.
התעלמות מנתוני יצרן ומתלונות המשתמש.
לא נחקרו דיווחי לקוחות
לחברה תהליכית בתחום פרמצבטיקה נדרש לייבש חומר גלם לתרופה (API- Active Pharmaceutical Ingredient). בתהליך פיתוח של החומר נמצא כציוד שיתאים למשימה יהיה יבשן מסוג Double Cone. האירוע מנתח את תהליך רכישת ציוד סטנדרטי, אשר התקיים בחברה בהתאם לנוהל פנימי ומציג ליקויים שנתגלו בהתקנת והסמכת הציוד, שהובילו לעיכוב משמעותי בזמן תחילת יצור. אירוע קריטי שגרם להפסדים כבדים לחברה. היצרן של הציוד לא מילאה/ ביצעה אחר כל דרישות המשתמש. במבט לאחור היה ניתן למנוע את כל הליקויים על ידי ישום תהליך T&E קפדני יותר. את מירב הבעיות היה ניתן לגלות בזמן ביקור נציגי החברה אצל היצרן (FAT- Factory AcceptanceTest). תעשייה פרמצבטית דרישות שלא נבדקו. מג’ורית- ביצועים בלתי מספיקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח זמנים. T&E 2010\double cone dryer 16.9.2010.pdf
אטמים לדלת מילוט סימן 4 מגיעים לליין בקושי גבוה ותוקעים את אספקת הדלתות במש”א. בדיקה מעלה כי ייתכן וספק הדלתות עבר יצרן גומי – דבר שגרר שוני בתהליך הייצור ושוני ושוני גדול (בעצם חוסר) בתהליך בדיקת האטמים. 1. במעבר ליצרן גומי חדש לא היה תהליך מסודר של AT&E.
2. אם לא היה מעבר יצרן באטם הרי שיש כאן בעיה של בדיקת ייצור סדרתי של פריטי גומי כאשר מסתמכים על תעודות ואין דרך להצמיד תעודה לסדרה של אטמים – תכנון מוקדם ונכון של T&E היה מביא לתוצאות טובות יותר והייצור היה פחות רגיש למעברי יצרן וכד’.
בטחוני/צבאי חוסר תכנון בדיקות / תקצובן 20.מינורית – אי נוחות, סטייה קלה בביצועים, בעלויות ובלוח הזמנים (עד 5%) etl20112003\merkava rubber 1.3.pdf
לא בוצעו בדיקות לאחר שינוי
לא בוצעו בדיקות אינטגרציה
חברה X פיתחה מוצר חדש לתחום הבדיקות של Y. המוצר נכשל בכל שלבי הפיתוח. כישלון זה נבע ממספר גורמים. תהליך תכנון המוצר היה לוקה לכל אורך הדרך.
השגיאות שנעשו היו מתוצאה של חוסר תכנון של בדיקות וניתוח לא נכון של תוצאות הבדיקות.
מתוך תהליך שגוי זה הושגו מספר מסקנות כגון:
1. הגדרות הבדיקות והסקת המסקנות מהסימולציה תאושר על ידי מנהל על חיצוני שילווה את הפרויקט.
2. כל מהנדסי המערכת בפרוייקט עברו אימון בתחום הPLC.
3. מחלקת השיווק הוחלפה.
בטחוני חוסר התייחסות לתוצאות הבדיקות קריטית T&E 2010\failure in testing system 26.8.2010.pdf
חוסר תכנון בדיקות
בארגון, שבו האתר הראשי של תשתיות המחשוב והמידע של הארגון מסונכרן על בסיס קבוע לאתר משני, היה כשל בתהליך של DRP בו היה מעבר לאתר עבודה מול אתר הגיבוי המשני, בגלל נפילת מערכות האל פסק באתר הראשי. המידע באתר המשני לא היה מסונכרן כלל עם האתר הראשי. הסיבה: רכיב התוכנה בבסיס הנתונים האחראי על הסנכרון בין האתר הראשי למשני לא עבד מספר ימים. במקרה המתואר במהלך תהליך OT&E ועל בסיס קבוע יש להגדיר בדיקה עומס של מערכות האל פסק ובדיקת חיות ותקינות על בסיס קבוע של רכיבי התוכנה האחראים לסנכרון עם האתר החלופי. כמו כן, ביצוע אירוע DRP על בסיס קבוע והסקת מסקנות הקשורות ל: חשיפת תקלות התכנון של התכנית, ליקויים בכ”א, בעיות בזמני תגובה, ליקויי אבטחת מידע, בדיקת מערך הגיבויים והשחזור כל פעם שחזור קבוצה אחרת, בדיקת מנגנון ההתאוששות מכשל חומרה ותוכנה. מערכות תוכנה חוסר דרישות לבדיקה קריטית T&E 2010\disaster recovering process (drp) 16.9.2010.pdf
חוסר בדרישות לבדיקת יכולת פעולה הדדית (יפ”ה)
נגמ”ש בראדלי פותח כחלופה לנכמש ישן M113. בבחינת תהליכי בחינה וניתוח תוצאות התגלו פערים של חוסר הגדרות (בדיקת מיגון עם טילים בעלי ביצועים לא מספקים), הגדרות בדיקה שלא משקפות את המציאות (שימוש בתחמושת דמה בזמן ניסוי שרידות הכלי), הגדרות מוגזמות (בניית תקן להגדרת סוג בעל חיים בבדיקות השפעת האדים שנוצרים עקב חדירה של הטיל). חקר של הדבר גרם לשינויי תכן בשווי של כ~1 מיליארד דולר. א. יש לתכנן את הבדיקות המשקפות את המציות שבה המערכת תעבוד.

ב. התעלמות מהבדיקות הנדרשות לא תפתור את הבעיה הקיימת.

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

בטחוני דרישות שלא נבדקו קריטית etl20112003\bradleyIFV 1.3.pdf
חוסר דרישות לבדיקה
בדיקות מיותרות ולתכונות NICE TO HAVE
ספינות ליברטי היא סדרת ספינות משא שנבנו בייצור המוני בארצות הברית במהלך מלחמת העולם השנייה. בניית הספינות, שנועדו למלא את מקומן של ספינות משא של בעלות הברית שטובעו על ידי הצוללות הגרמניות, הייתה מהירה וזולה. בתחילה נבנו כמאה ספינות שכאלו עבור בריטניה במסגרת תוכנית החכר והשאל האמריקנית.
ב-1940 הזמינה בריטניה ממספנות בארצות הברית 60 ספינות כדי למלא את אבדותיה בים ולתגבר את צי הסוחר שלה.
ספינות הליברטי הראשונות סבלו מתופעה של היווצרות סדקים בגוף ובסיפון, ואחדות מהן טבעו עקב כך. במהלך המלחמה התרחשו כ-1,500 מקרים של הופעת שברים בספינות עקב פריכות המתכת. שלוש מספינות הליברטי שנבנו נשברו לשניים ללא התרעה.
• יש להגדיר בדיקות OT&E ולשלבן בתכנון כגון סביבת תפעול.
• יש להגדיר את כל הדרישות ולא רק כלליות : מנוע פחם וכד’.
• יש להגדיר מדיניות בדיקוב עבור מוצרי מדף.
• יש להגדיר מדיניות אחריות ותיקונים.
מערכות ים + בטחוני/צבאי חוסר דרישות קריטית etl20112003\liberty ship 1.3.pdf
דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
חוסר דרישות לבדיקה
אסון מעבורת החלל צ’לנג’ר, אירע ב-28 בינואר 1986. במהלך משימה STS-51-L התפוצצה באוויר מעבורת החלל צ’לנג’ר 73 שניות אחרי שהמריאה ממרכז החלל קנדי, פלורידה. האסון הביא למותם של שבעה אסטרונאוטים. א. למרות כשל בבדיקות ראשוניות של האטם, לא הוגדרה הבעיה ברמה קריטית עוד בשלב הDT&E.

ב. למרות שהיה ידוע על בעיות באטם לכל אורך הפרויקט, רק לאחר 8 שנים בוצע ניסיון לתכן מחדש של האטם- מעבר שלבים למרות אי מילוי הדרישות על פי DT&E וAT&E.

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

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

תעופה וחלל דרישות שלא נבדקו- צמיגות האטם אסון T&E 2010\challenger accident 19.8.2010.pdf
לא נחקרו חריגות שנתגלו בבדיקות
חוסר התייחסות לתוצאות הבדיקות
רישות ספינות חה”י תוך כדי קישורן לרשת הנתונים החופית בעת עגינתן ברציף. חזון הפרויקט היה שבעת עגינת הספינה יחוברו מערכות המחשוב בספינה לרשתות הנתונים החופיות וע”י כך מתן יכולת מערכות מחשוב בספינה כפי שיש במשרד. הרעיון היה לרשת את הספינות בסיבים אופטיים וקישור הספינה לחוף באמצעות סיב/כבל טקטי בעמידה בתנאי סביבה ימית. לאחר התקנה באב טיפוס ובכלל הספינות סבלו הרשתות בספינות מחוסר זמינות ותקלות שפתרונן היה ארוך ולא מספק לצורך המבצעי. א. חוסר בדיקתיות ב-DT&E, כשל באימות התכן.

ב. OT&E- חוסר בהתאמה תפעולית/ Operational Suitability.

ג. בדיקות קבלה לא מתאימות- AT&E

בטחוני/ צבאי אחר חוסר בדרישות, , כשל משימה, ירידה באמון הלקוח (ספינות) עד כדי חוסר שימוש במערכת. T&E 2010\communication between pier and ship 16.9.2010.pdf
מערכות ים חוסר דרישות לבדיקה (בעיקר דרישות ל- OT&E)
מערכות תקשורת כשל באימות התכן.
חוסר בדרישות לבדיקת יכולת פעולה הדדית (יפ”ה)
רובוט EYE DRIVE הינו רובוט קל משקל ומיועד להטלה מגובה של עד 2 מטר.מתחילת אבלואציה מבצעית של פלטפורמה רובוטית EYE DRIVE, התגלו מס’ כשלים שחזרו בכל הפלטפורמות: שבירת מנועים ואנטנות. עקב ריבוי תקלות הופסק ניסוי אג”מי. א. בוצע איתור נקודות קריטיות שבהם יש סיכוי רב לכשל ובוצעו אנליזות מתאימות.

ב. אנטנות חיצוניות הוחלפו באנטנות פנימיות.

ג. שונה מבנה של בתי המנועים.

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

ה. בוצע שיפור במרסנים של כרטיסים אלקטרוניים.

צבאי דרישות שלא נבדקו. קריטית – כשל משימה, הפסד שוק, ארוע בטיחותי, איום על קיום הארגון, סטיה משמעותי בביצועים, עלות ובלוח זמנים מעל 20% etl20112003\eye drive 1.3.pdf
אי שילוב בדיקות OT&E בשלבים מוקדמים.
לטורניר החשובביותר בספורט הכדורגל, הגביע העולמי לשנת 2011 בדרא”פ, הוציאו כדור חדשומיוחד שנעשה בעזרת טכנולוגיות חדשות של תכנון, ניסוי וייצור.
הכדור החדש קיבל שם אותנטי – Jabulani, עיצוב מיוחד עם קישוט וכיתוב מיוחד, אבל גם תכונות חדשות. הכדור “עגול” יותר ובעל מרקם מיוחד, שמאפשר לולנוע יותר טוב באוויר.
הנבחרות שעלו לטורניר הגמר התלוננו על הכדור החדש, הטענות המרכזיות היו: מסלולבלתי צפוי באוויר ושליטה טכנית שנפגעה (טענות שעלו בעיקר מצד השוערים).
בתחילה, פטרו פיפ”א ואדידס את הטענות בטענה שהכדור תוכנן ויוצר בשיתוףמכון מחקר אקדמי לספורט (מוסד בבריטניה), שהכדור נמסר לנבחרות המובילות בטורנירלניסיון, ושאלו ביקורות “סטנדרטיות” לפני טורנירים.
בהמשך, בעלי תפקידים בפיפ”א יצאו בהצהרה שהכדור “בעייתי”. אמינותה של פיפ”א, היא הואשמה בחוסר מקצועיות, פגיעה באתיקה ספורטיבית, בכךשהכניסה את הכדור החדש לטורניר החשוב בעולם, ללא שניתן מספיק זמן לאימון, משחקו”הסתגלות” של כל הנבחרות שלקחו חלק בטורניר.
א. פיפ”א הייתה צריכה לתכנן את לוח הזמנים טוב יותר, על מנת לשמור על אתיקה מקצועית, הכדור היה צריך לעבור הסתגלות ארוכה יותר, ואצל כל הנבחרות שעלו לטורניר ולא רק בחלקן. על-מנת לקבוע את הזמן המתאים לכך, פיפ”א הייתה להציף את בעיות ה”הסתגלות” עם כל מאמני הנבחרות והאגודות. טכנולוגיות ספורט חוסר דרישות לבדיקה תקלה קלה – אין נזק משמעותי etl20112003\the Jabulani Ball 1.3.pdf
ב. כדור חדיש ו”מהפכני”, כדברי אדידס, שיכול להכניס מימד חדש למשחק. חייב להיות תחת שימוש בקונצנזוס רחב יותר מזה שאדידס יצרה לקראת טורניר הגביע העולמי 2010 בדרא”פ. דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
ג. אימון והכשרה הוא חלק מבדיקות הטמעה של מערכת חדשה, גם אם מדובר על סביבה בלתי מבוקרת. חוסר תכנון בדיקות
במסגרת פרויקט שדרוג מעבדת פיתוח עבור לקוח זר נדרש הספק להחליף את רכיבי החומרה ולהמיר את תוכנת המערכת לשפת תכנות חדשה תוך שמירה על כלל ביצועי המערכת הקיימת. לאחר השלמת הפיתוח הגיעו הצדדים לשלב ה-ATP ללא מסמך בדיקות מוסכם ומבלי לאמוד בצורה סדורה את ביצועי המערכת הישנה כמקור להשוואה. בנוסף התברר כי תכולות מסוימות להן ציפה הלקוח כלל לא מומשו במערכת החדשה. האירוע מנע באופן מיידי את התחלת שלב ה-ATP והביא לדחייה של כ-3 חודשים בלו”ז התוכנית (כ-20% תוספת). במסגרת זמן זה רכיבי תוכנה מסוימים הוחזרו להשלמת פיתוח ובוצע סט של בדיקות למערכת הישנה לצורך השוואה. הלקחים המרכזיים שהופקו בעקבות תחקיר אירוע זה הינם:

א. מסמך הבדיקות יישלח ללקוח לאישור כ-6 חודשים לפני תחילת ה-ATP. המסמך כולל את התוצאות הרצויות והטולרנסים המקובלים.

ב. על הלקוח להעביר לספק את תרחישי הבדיקה החופשית כ-3 חודשים לפני ה-ATP.

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

בטחוני/צבאי חוסר דרישות לבדיקה, מג’ורית- ביצועים בלתי מספקים וסטייה בעלות ובלוח הזמנים. T&E 2010\laboratory upgrating 16.9.2010.pdf
 דרישות שאינן כלולות בתוכנית הבדיקות
הגדרת דרישות.
בפרויקט של ביצוע ניסוי אג”מי (OT&E) לבחינת התאמת של נגמ”ש לביצוע
משימות סיור וביטחון כחלופה לרכבים ממוגנים. טרם העברתו של הנגמ”ש לניסוי בוצעו בו שינויים והכשרה בהתאם לדרישות שהועלו. לאחר שימוש ראשוני התברר כי הנגמ”ש מתאים לייעודי אך ישנם מספר אי התאמות ( בעיקר – תצורת הישיבה בנגמ”ש אינה תואמת את הנדרש). הניסוי הופסק ורק לאחר ביצוע שינויים והתאמות נוספות הנגמ”ש חזר לגזרה להמשך פעילות.
א. בחינה מחדש של דרישות בהתאמה של קונספט חדש לפתרון קיים.

ב. הבאת משתמשי קצה לתיקוף וגיבוש מפרטים טכניים.

ג. ביצוע של כלל שלבי OT&E בדגש על הערכה ראשונית של ההתאמה התפעולית לפני ביצוע תכן מפורט (EOA).

צבאי חוסר דרישות – אי נוחות, סטייה קלה בביצועים, בעלויות ובלוח הזמנים (עד 5%) etl20112003\armored personnal carrier M113 1.3.pdf
בבתחילת נובמבר 2003 התגלה כי מקרי תחלואה ומוות בתינוקות (3 נפטרו) ברחבי הארץ נובעים מצריכת פורמולה צמחית לתינוקות של רמדיה. התברר כי תכולת ויטמין B1 (תיאמין) נמוכה משמעותית לעומת המוצהר בפירוט מרכיבי הפורמולה ע”ג האריזה. מתברר שהפורמולה המיוצרת ע”י חברת הומנה בגרמניה, הינה פיתוח חדש (לתינוקות מגיל 0 עד שנה) שהתבסס על שתי פורמולות קודמות (גיל 0 – 6 ח’ וגיל 6 ח’-שנה) ובעת פיתוחה הוחלט, עקב פענוח שגוי של המרשמים להפסיק את הוספת התיאמין. בדיקה בקו הייצור לא הושלמה עקב תקלה, ובארץ לא נעשו בדיקות כלל, לא ע”י היבואן ולא ע”י משרד הבריאות, אלא רק הסתמכו על הצהרות היצרן. א. יש לדרוש בדיקות אימות בשלבי הפיתוח. תעשיית מזון חוסר דרישות לבדיקה קריטית – אירוע בטיחותי, איום על הארגון etl20112003\remedia incident 1.3 (1).pdf
דרישות שלא נבדקו
ב. יש להשלים את כל הבדיקות הנדרשות בתהליך. מרכיבי REUSE  שלא נדרש לבדוק
לא הייתה התייחסות ל OT&E בשלבי פיתוח המוצר etl20112003\remedia incident 1.3 (2) (indictment).pdf
ג. מוצרים רגישים במיוחד (לדוגמת מזון תינוקות) נדרש לבדוק גם ע”י היבואן וגם ע”י הרגולטור, ולא להסתפק בהצהרות C.O.C. חוסר תכנון בדיקות ו/או תיקצובן
חוסר התייחסות לתוצאות הבדיקות/ אי יישום לקחי העבר
המערכת סיימה בדיקות AT&E במעבדה. בעת בדיקות AT&E אצל הלקוח בתנאי שדה לאישור גירסת תוכנה חדשה- מוד עבודה מסוים לא תפקד. א. תהליך העבודה לשחרור גירסה ובדיקות קבלה למערכות היה נכון אולם לא מספק.

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

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

בטחוני/צבאי דרישות שלא נבדקו+ציוד בדיקה אינו יכול לבדוק את כל הבדיקות קלה, אין נזק משמעותי, הבעיה נפתרה. T&E 2010\communication system program 16.9.2010.pdf
המעילה בבנק למסחר התרחשה בין השנים 1997 ו 2002, ובמסגרתה מעלה עובדת הבנק, אתי אלון, בכספי הבנק בהיקפי ענק של כ 300 מליון ש”ח שהביאו לקריסתו. במסגרת המעילה, פתחה אלון בבנק 206 חשבונות פיקטיביים (לעומת כ-1300 לקוחות הבנק), בהם העמידה הלוואות גב אל גב ואת כספי ההלוואות משכה לרשותה וכן גנבה כספים ישירות מחשבונות הלקוחות תוך שבירת פיקדונות הלקוחות. אלון ביצעה את גנבת הכספים כדי לסייע לאחיה, עופר מקסימוב, בפירעון חובות הימורים שלו לגורמים בשוק האפור. הידוק הפיקוח, מחשוב, שקיפות ללקוח: בעקבות הפרשה הידק בנק ישראל את הפיקוח על בנקים בארץ, חייב את הבנקים בשינוי ועדכון נהלים ו”הוראות ניהול בנקאי תקין” ובעיקר נהלי מחשוב וכללים לגבי מערכת המחשב אשר מצויה בשימוש בנקים, כולל הרשאות וסיסמאות. כמו כן, כדי להגדיל את השקיפות ללקוח, חויבו כל הבנקים בישראל למקם בסניפים עמדות מידע ממוחשבות אשר יאפשרו לכל לקוח לקבל מידע על חשבונו באופן בלתי תלוי ומבלי להזדקק למי מפקידי הבנק. מערכות מסחר בנקאי חוסר דרישות לבדיקה OT&E, דרישות OT&E שלא נבדקו. קריטית- היקפי הענק של המעילה הביאו לקריסת הבנק. T&E 2010\embezzlement in the bank 16.9.2010.pdf
בעקבות מקרה שאובחן כי שיטת ניסוי היציבות אינה מספקת- הדרישות לא נבדקו כהלכה, בוצעה עבודה מחקרית מקיפה שעל בסיסה שונתה שיטת הניסוי בהתאם לתקנים רלבנטיים בעולם. יש לעקוב אחר השתנות תקנים ושיטות ניסוי בעולם ולהקפיד על עדכון שיטת הניסוי ע”פ עדכון התקנים הרלבנטיים בעולם. בטחוני דרישות שלא יודעים איך לבדוק מג’ורית- ביצועים בלתי מספקים. etl20112003\vehicle stability test 8.2.pdf
בסוף שנת 2005 מיקרוסופט השיקה מוצר חדש בסדרת קונסולות משחקים – Xbox 360. (קונסולה זו הינה השניה שיוצרה ע”י מיקרוסופט).מתחרות של Xbox 360, הן הקונסולות playstation3 של sony ו-Wii של נינטנדו.
מייד עם השקת המוצר,נתגלו בעיות רבות  ,והתקלה נקראה בשם Red ring of death
מהות התקלות:
1.כשל בחומרה
2.שריטות דיסק
3.שגיאות תוכנה שגרמו לכשל חומרה .
תקלות אלו הביאו לכך שהמוצר הפך ללא אמין ובעל אחוז גבוה לכשל.
לאחר לחץ על החברה, היא החלה בתהליך שידרוגים ושיפורים של גרסאות הקונסולה.
בפיתוח וייצור המוצר קרו מס’ רב של כשלים
1. כשלים טכנים-תהליכי ייצור לא מתאימים, חוסר התחשבות בתנאי סביבה של מחזור חיים וכו’.2. כשלי T&E-לא בוצעו אנאליזות של מעברי חום,לא בוצעו בדיקות של המערכת לתנאים צפויים,היה כשל בבחינת המוצרים וכו’.3. כשלים מנהלתיים-מיקרוסופט מיהרה להוציא מוצר חדש ובכך ההנהלה גרמה למס’ החלטות שגרמו לכשלים האחרים.
מערכות אלקטרוניות חוסר תכנון בדיקות            חוסר דרישות לבדיקה               לא בוצעו בדיקות אינטגרציה מג’ורית- ביצועים בלתי מספקים,אבדן נתח שוק,סטייה בינונית בביצועים,עלות ועמידה בלו”ז etl20112003\xbox 360 failure 1.03.pdf
פיתוח כרטיס הרשת התבצע בחברת Flextronics עבור חברת התקשורת HAVAYA. בסיום אבן דרך 4, CDR, התגלו מספר בעיות בהרכבת הכרטיס, ובמיוחד באורך רגלי הטרנזיסטורים אשר לא תאמו את שכבת הפאד. תקלה זו נגרמה עקב אי בדיקת אפשריות ספקי טרנזיסטורים אחרים, והתמקדות ברכיבים שגויים. הדבר גרם לעיכוב רב בהסמכת אב הטיפוס, והוצאות כלכליות מיותרות. מסתבר שעובי רגלי הטרנזיסטור היו ארוכים ב30 מ”מ, מה שגרם לקצרים ואף לשריפת הכרטיס. עקב המגבלות הטכניות בעת תכנון מוצרים בתוכנות תיב”ם, לא נלקחים בחשבון אלמנטים שונים ומורכבים, אשר גורמים בסופו של דבר לכשל מערכתי. המקרה הזה, פותחה תוכנה יחודית, אשר אוגרת בתוכה את כל התרחישים הקריטיים לבדיקה בשלב DT&A. התוכנה שומרת אצלה בסיס רכיבים עצום מספקים שונים. פותח אלגוריתם מיוחד אשר מבצע בדיקת התאמה בין דרישות המתכנן לבין תכונות השונות של הרכיבים. הלקח החשוב ביותר הוא לבצע אופטימיזציה של החומרה לקבלת תכנון טוב וחסר תקלות בטרם התחלת הייצור. מערכות תוכנה חוסר בדיקתיות קריטית
מע’ “פ-4” הינה מע’ צבאית המשמשת כמקלט.
המערכת פותחה ע”י גוף הנדסי ולאחר הפיתוח וסיום ייצור מנה ראשונית נופקו מס’ יח’ לכח מסוים המשמש כפיילוט תפעול המערכת.
תיאור האירוע בקצרה:
במהלך השימוש התגלה ש-2 מערכות חדלו מלתפקד.
המערכות הוחזרו לגוף המפתח לצורך תחקיר ושיפור המע’.
מתוכו התגלה שהתקלה נובעת מחומר שחור שהצטבר על מכסה הסוללות וגרם לנתק בין סוללות המערכת וכך לחוסר קבלת מתח.
התגלה שהמשתמש החליף את הסוללות שנופקו ע”י היצרן עם המערכת (סוללות נטענות) בסוללות של יצרן אחר (שאינן נטענות). לאחר שינוע המע’ הסוללות הנ”ל הפרישו את חומר שיצר קצר במערכת.
א. הוספת דרישה מהמפתח לבדיקת המערכת עבור מגוון סוגי סוללות, גם נטענות וגם שאינן נטענות.

ב. דרישה לשילוב המשתמש כחלק מ-OT&E במהלך הפיתוח. יתכן וכך היו מגלים את אופן התפעול הייחודי של המשתמש: שינוע עם סוללות ושימוש בסוללות שונות. וכך מעלים את הצורך בבדיקת ת”ס עבור סוללות שונות.

מערכות אלקטרוניות חוסר בדרישות לבדיקה מינורית – אי-נוחות, סטייה קלה בלוחות הזמנים etl20112003\p-4batteries 1.3.pdf
צבאי דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
אי שילוב OT&E בפיתוח המוצר
לא בוצעו בדיקות לאחר שינוי
בשנת 96 צה”ל הצטייד במערכת המתבססת על פלטפורמה גלגלית המקנה יכולת להעברת חוזי ממקומות מאויימים. בשנת 2004 הוחלט לפתח ע”ב הפלטפורמה הקיימת מערכת לטפול במטענים. בתום הפיתוח התגלתה בעיה בשינוע המערכת, לפי הדרישה המקורית שינוע המערכת ברחבי הארץ יתבצע בעזרת נגרר יעודי הקיים במערך ומשמש להובלת המערכת המקורית (משנת 96) אך לא נלקח בחשבון שהמערכת החדשה שוקלת יותר ולכן השימוש בגרור היעודי אינו מתאים בשל חריגה משקלית. כדי לפתור את הבעיה שונתה שיטת הישנוע והגורורים הישנים עברו הסבה לשימושים אחרים. א. בתכנון מערכת חדשה המתבססת על מוצר קיים יש להגדיר מראש את כל הממשקים ולוודא שישנוי במערכת יגרור שינוי מתאים ברכיבים המתממשקים או יתאים לממשקים הקיימים.

ב. יש לבחון את המערכת להתאמה בשלב ה – DT&E: בחינה של המוצר בשלב התכן היתה מגלה שהתוספת המשקלית ע”ג הפלטפורמה תגרום לבעיה בשימוש בגרור הקיים.

ג. יש לבחון את המוצר להתאמה בשלב ה –  AT&E:
הבחינה העלתה את הבעיה הקיימת טרם המסירה ללקוח מה שמנע מסירה של מערכת “בעיתית”

צבאי חוסר דרישות לבדיקה מג’ורית- ביצועים בלתי מספקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%) etl20112003\unsuitable trailer 1.3.pdf
מרכיבי REUSE  שלא נדרש לבדוק
לא הייתה התייחסות ל OT&E בשלבי פיתוח המוצר
לא בוצעו בדיקות לאחר שינוי
לא בוצעו בדיקות אינטגרציה
במהלך השנים האחרונות קרו מספר תקלות אלקטרוניות בזמן ניסויים. התקלות קרו למרות בחינה מדוקדת של תקינות תיבות האלקטרוניקה טרם השימוש. לאחרונה התגלה כי צב”ד התיבות הוא המקור לפגיעה מכאנית במחברי התיבות שגרמו לתקלה. העדר ניתוח אופני כשל למחברי התיבות בשלבי התחזוקה הוביל לכך שלא תוכננו מתקנים מתאימים. בהעדר המתקנים, התקלה הייתה בלתי נמנעת. צבאי חוסר בציוד בדיקה מתאים קריטית T&E 2010\sim and dmc connect eurs 26.8.2010.pdf
מערכות אלקטרוניות חוסר דרישות לבדיקה
תהליך הפיתוח של מערכת כלי הטיס הבלתי מאויש “פרדטור” היה מזורז, והמערכת הועברה לייצור ונפרשה באזורי לחימה למרות שלא נבדקה בתרחישים אמיתיים שבהם נדרשה לעמוד. בשטח התברר שהמערכת אינה אמינה וביצועיה נמוכים בהרבה מהנדרש. א. יש לבדוק שהמערכת עונה לדרישות ומתאימה לצרכי הלקוח תחת כל התרחישים שהוגדרו לפעולתה לפני שעוברים לייצור ופרישה שלה.

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

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

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

תעופה וחלל דרישות שלא נבדקו קריטית: כשלונות משימה; סטייה משמעותית בביצועים; ארועים בטיחותיים. T&E 2010\predator unmanned 16.9.2010.pdf
צבאי אחר: אי ניצול נסיון תפעולי למיקוד תהליכי הבדיקות, והתעלמות ממסקנות תהליך הבדיקה.
חוסר תכנון בדיקות
סביבת בדיקות לא מתאימה
הארוע מתאר כשל של דליפת הליום ממקרר קריאגני לאפליקצית IR מדגם “561K משופר” של חברת ריקור. במקרר קריאוגני משתמשים בהליום כגז הדחיסה. איטום המקרר לרמת דליפת הליום נמוכה מהווה נטבח תכנוני עיקרי לצורך עבודתו של המקרר בשרות לאורך זמן. הכשל עליו יפורט בדוח זוהה מיד לאחר העברתו של דגם המקרר הנ”ל לייצור סדרתי, לאחר שהושלמו בהצלחה כל בדיקות הפיתוח הנדרשות בהתאם נוהל הפיתוח בחברה. א. היה מקום לבצע בדיקות מחמירות מדרישת המפרט כדי לבדוק את איתנות התכן.

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

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

בטחוני/צבאי דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E) מינורית- אי נוחות סטייה קלה בביצועים, בעלויות ובלוחות הזמנים. T&E 2010\helium leaking from 561K refrigerator 16.9.2010.pdf
תלונות מצד התלמידים המורים על קושי המבחן, הניסוח וחוסר הנתונים. אי אפשר לבצע OT&E מסיבות אובייקטיביות ולכן יש להקפיד על בדיקות מחמירות ב-AT&E. פרויקט חינוכי אי אפשר לבצע בדיקות OT&E. קלה- אין נזק משמעותי, הבעיה נפתרה במקום באמצעות מענה ממוקד התמיכה. etl20112003\bagrut 8.6.doc
ב-13 בספטמבר יצאה טיסה Spantax Flight 995, כאשר המטוס נכנס לתהליך ההמראה הטייס הרגיש ויברציה חזקה – הצוות ביצע ביטול ההמראה לאחר מעבר המהירות הטרמינלית, כתוצאה מכך הצוות איבד שליטה על המטוס ולא הצליח לעצור את המטוס על שדה התעופה, המטוס לבסוף התרסק מחוץ לשדה התעופה וגבה את חייהם של 50 נוסעים ופצע 110 . 1. DT&E  – לא היה קיים מענה לכל התרחישים, הכשל בצמיג לא היה ניתן לניטור ע”י שום מערכת או מעקב ע”י גורמי אנוש.
2. OT&E – חוסר התאמה טכנית של אופן האחזקה של הצמיג, לא זוהתה הידרדרות שיטתית של איכות הצמיג ואחזקתו .
3. אי שילוב OT&E – קורס הטייס העביר נהליי המראה תחת כשלים של המנוע אך לא התמקד בכשלים של הגלגלים – לכן המטוס שלא הכיל אינדיקאטורים לכשלים בצמיגים לא התאים לבסוף למשתמש הסופי שלא הוכשר לזהות בעיות כאלו באופן ידני.
 תעופה וחלל  אי שילוב OT&E
חוסר דרישות לבדיקה
קריטית etl20112003\spantax flight 995 1.3.pdf
בין השנים 1939-1945 נבנו בארה”ב 2,708 ספינות מדגם ליברטי. עד 1 באפריל 1946 דווח על 1,031 מקרים של נזק לגוף הספינה שמקורו בשבר פריך של המתכת ממנה עשוי הגוף. יותר מ-200 ספינות ליברטי טבעו או ניזוקו נזק בלתי הפיך. ניתן היה להקטין משמעותית את הקף התופעה ואף למנוע אותה אילו מנהלי הפרויקט היו מגדירים ועורכים בדיקות התאמה לרכיבי Re-use (פלדה), היו מגדירים את הדרישות לעמידה בתנאי הסביבה והעבודה ואת שיטת בחינתן והיו נערכות בחינות OT&E בידי המשתמשים. מערכות ים חוסר דרישות לבדיקה+ רכיבי Reuse שלא נדרש לבדוק+ דרישות OT&E שאינן כלולות בתכנית הבדיקות מג’ורית T&E 2010\liberty ship 19.8.2010.pdf
חוסר תכנון בדיקות
בתאריך 24.5.2001 סמוך לשעה 22:43 בזמן שבאולמי ורסאי התקיימה חתונתם של הזוג קרן ואסף דרור, קרס חלק גדול מרצפת האולם. כתוצאה מכך נהרגו 23 אנשים ונפצעו כ- 380 אורחים נוספים. לאחר חקירת האירוע  נמצא כי לא בוצעו בחינות ע”י מהנדס בניין בעת בניית התקרות בשיטת הפלקל, כמו כן הוסרו עמודי וקירות תמך בקומה שמתחת לרצפה שקרסה ללא אישור של העירייה או מכון התקנים. בנוסף התברר כי בעבר שקעה הרצפה ובעלי האולם החליטו להוסיף עוד חול ושכבת מרצפות ע”מ להגביהה את הרצפה ששקעה. לסיום האולם היה מיועד לתעשייה ומעולם לא אושר להיות אולם ארועים. א. יש להקפיד על בחינה ומעקב תקינים בעת בנייה בשיטת פל-קל שכן היא מחייבת דיוק רב. בניין דרישות שלא נבדקו. קריטית- אירוע בטיחותי etl20112003\versai disaster 1.3 (1).pdf
ב. יש לבצע בחינה לאחר גמר הבנייה לעמידות בעומסים הנדרשים דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
ג. יש לבחון במהלך ביצוע שינויים במבנה קיים ולבדוק עמידותו בגמר השינויי. לא נחקרו חריגות שנתגלו בבדיקות
לא בוצעו בדיקות לאחר שינוי
סביבת בדיקות לא מתאימה
לקוח שהשתמש במערכות מסוג Z בשתי פלטפורמות מוטסות שונות (X,Y) הבחין בביצועים מופחתים בחלק מיחידות שבשימושו בפלטפורמה Y. לאחר חקר מעמיק וממושך בשיתוף הלקוח ויצרני הרכיבים התברר שהביצועים המופחתים התקבלו כאשר המערכת פעלה בתנאים בהם היה שינוי מהיר בשני פרמטרים במקביל, בטמפ’ ובלחץ, שהובילו להתנתקות רכיבים מהכרטיס. מקרה זה גרם לעיכוב במכירת יחידות נוספות וגרר שינוי תכן והחלפת יחידות המותקנות אצל הלקוח. הסיבות שהובילו לאירוע:             1. מפרט הדרישות שהתקבל מהלקוח כלל דרישה לתחום טמפ’ עבודה ותחום לחצים, אך לא כלל את הקשר בין שני הפרמטרים הללו.                                              2. הבדיקות שבוצעו כללו חלק מאפשרויות שילוב טמפ’-לחץ, אך לא את כולן עקב מגבלות מכשור קיים.                           3.בדיקות OT&E שבוצעו לא כללו בדיקות המייחדות את פלטפורמת Y בעקבות הצהרת הלקוח שהמפרט עבור פלטפורמה Y זהה לפלטפורמה X.                        4. הנתק נגרם בעקבות שימוש בדבק ששימש להידוק רכיבים לכרטיס אשר הוסף לאחר זיהוי תקלה בהרעדה ובחירתו נעשתה ללא ידיעת קצב שינוי הטמפ’ והלחץ המקסימליים, אלא בהתבסס על התחומים המקסימליים של כל פרמטר בנפרד. א. יש לבצע בדיקות עבור כל קומבינציות פרופילי הדרישות (במגבלות המכשור, עלות וכו’). במידה וישנן בדיקות שלא ניתן לבצען במסגרת זו יש לציינן ולדרוש ביצוען במסגרת OT&E.

ב. יש לבצע OT&E מלא אצל הלקוח גם עבור מערכות קיימות המותקנות על פלטפורמה שהדרישות עבורה זהות.

בטחוני/צבאי חוסר דרישות מג’ורית- ביצועים בלתי מספקים, תוספת עלות בדיקות מחודשות, עצירת אספקות ללקוחות נוספים עד לסיום הבדיקה, החלפת יחידות אצל לקוחות. T&E 2010\disconnections during welding process 16.9.2010.pdf
חוסר דרישות לבדיקה.
דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
חוסר בציוד בדיקה מתאים
לא בוצעו בדיקות אינטגרציה
בחיבור בין מערכות תוכנה מורכבות על גבי רשתות שונות, ניתן לבדוק את הממשק בתהליך הפיתוח בצורה מוגבלת אשר אינה משקפת במלואה את המציאות בפועל. כל זאת כאשר חיבור המערכות בזמן הפיתוח אינו אפשרי בשל דרישות גבוהות לבטיחות מערכתית ולבטחון מידע. במקרה זה התגלתה תקלה בתחילת אבלואציה מבצעית אשר גרמה לאי קבלת המערכת ודחייה של מספר שבועות בפרוייקט. במקרה המתואר יש לבצע בדיקות מדוקדקות מן הרגיל על מנת לוודא כי הממשק מתפקד כראוי בקשת התרחישים ומקרי הקצה המוגדרים למערכת. בטחוני/ צבאי- מערכת שליטה ובקרה. ציוד בדיקה אינו יכול לבדוק את כל הבדיקות. מינורית T&E 2010\interface testing failure 16.9.2010.pdf
מערכות תוכנה חוסר בדרישות לבדיקת יכולת פעולה הדדית (יפ”ה)
הורכב בארץ ג’יפ צבאי על בסיס ג’יפ אזרחי. שונו מספר מכלולים עיקריים בינהם מערכת העברת הכוח. לאחר קליטת מאות ג’יפים התגלה כי גלגלי השיניים של הדיפרנציאל האחורי נשברות. כשל הדיפרנציאל פוגם בהעברת הכוח לגלגלים ובכך בייעוד הרכב כרכב שטח. בנוסף, חוסר מתן פיתרון הנדסי הביא לכך שהכשל גרם לכשל בטיחותי קריטי של הינתקות גלגלים. מתברר שלפני ייצור הליין נבחן רק רכב אחד וגם בו הדיפרנציאל היה שונה ממה שהורכב בליין. חקר טכני העלה שהמומנט המועבר לדיפרנציאל גדול מידי. א. יש לבחון מרכיבי REUSE גם אם נדמה כי אינם מהווים בעיה, אלא אם כן נותח שוב באופן הנדסי ונמצאו עומדים בדרישות ובשינויים. רכב מרכיבי REUSE שלא נדרש לבדוק קריטית – כשל משימה, הפסד השוק, אירוע בטיחותי, איום על קיום הארגון, סטייה משמעותית בביצועים, עלות ובלוח הזמנים (מעל 20%). etl20112003\jeep rear diff failure 1.3.pdf
ב. יש לבחון יותר ממוצר אחד לפני אישור ליין ייצור למס’ פריטים גדול, גם אם זה כרוך בעלות נוספת. חוסר תכנון בדיקות
ג. יש לבצע תכנון בדיקות מדויק שיגדיר את כלל תתי מערכות הפרויקט ואופן בדיקתם. חוסר דרישות לבדיקה
ד. בעת פיתוח מוצר, יש לתת דגש, ולשים לב במיוחד לפריטים ולתתי המערכות אשר לא ניתן לבחון אותם באמצעות ציוד בדיקה ייעודי.  ציוד בדיקה אינו יכול לבדוק את כל הבדיקות
ה. יש לקחת בחשבון כל תלונת לקוח ועל אחת כמה וכמה תלונות של עובדי החברה הזוטרים. אי התייחסות ל- OT&E
נבדקה המערכת ה”לא נכונה”, המערכת הנבדקת אינה מייצגת את המערכת הנכונה.
המערכת שונתה אחרי הבדיקות
לא בוצעו בדיקות אינטגרציה
לא נחקרו דיווחי לקוחות
מיד עם השקת מכשיר ה-iPhone4 החדש התגלו בעיות קליטה במכשיר. זמן קצר לאחר מכן התגלה כי התקלה קשורה בעיצוב האנטנה הייחודי של המכשיר (פס מתכת העוטף את גוף המכשיר)- כאשר אוחזים אותו עם כף יד שמאל, כך שהיד מכסה את פינתו השמאלית התחתונה של המכשיר, הקליטה נפגמת עד למצב שהוא מאבד לגמרי את השירות הסלולארי. א. יש לתכנן את שיטת הבדיקות המתאימה כבר בשלבי הפיתוח, תוך הקפדה על ייצוג כלל מאפייני המשתמשים.

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

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

מערכות תקשורת דרישות שלא נבדקו מג’ורית- ביצועים בלתי מספקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%) מ T&E 2010\iPhone-4 signal problems 16.9.2010.pdf
דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
 ציוד בדיקה אינו יכול לבדוק את כל הבדיקות
לא נחקרו דיווחי לקוחות
מדובר במערכת אלקטרונית (תיבות) שעבדה מספר שנים במערכות מוטסות והוחלט לשלב אותה גם במערכות ימיות, בספינה עם ממשקים למערכות נוספות. לאחר כשנה של עבודה ללא תקלות בספינות החלו להופיע לפתע בפרק זמן קצר מאוד תקלות במספר תיבות, ח”ח שנרכשו לא היו מספיקים, עקב כך האפקט המרכזי היה שהמערכת לא היתה זמינה במספר ספינות. לאחר ביצוע בדיקות נוספות, דיונים וסקרים עם מהנדסים מהמפעל, מהנדסי אמינות ועוד המסקנות העיקריות היו:

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

ב. חוסר מספק בבדיקות תוכנה בשלב ה-DT&E.

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

תעופה וחלל, מערכות ים, בטחוני/צבאי, מערכות אלקטרוניות חוסר דרישות לבדיקה (בעיקר דרישות ל- OT&E). כשל משימה, המערכת לא תקפדה לפרק זמן רב עד שתוקנה. T&E 2010\system unfit working environment 16.9.2010.pdf
מרכיבי REUSE שלא נדרש לבדוק
רקע: בשנת 2007 צה”ל רכש מאות משאיות אינטרנשיונל שייעודם הובלת תחמושת וציוד בסדיר ובחירום. ארגזי המשאיות מדוגמים ע”ג שלדות המשאיות בחברה נפרדת לאחר ייצור השלדות. ייצור ודיגום הארגז מבוצע בארה”ב. בינואר 2009 נעשתה פנייה של פקע”ר אל הח”מ בנושא תופעות קורוזיה והתקלפויות צבע בארגזי משאיות האינטרנשיונל. תוצאות: בעקבות הסקר לתופעת הקורוזיה שהוכיח תקלה אפידמית (הכשל התרחש במעל 10% כלים מכלל הצי) ובדיקת טיב הצבע, מימשנו אחריות מול היצרן ובימים אלה מבוצעת צביעה מחדש של כלל ארגזי המשאיות בחברה בארץ במימון היצרן. סיבות להתרחשות האירוע: בדיקת טיב הצבע שבוצעה בארץ ע”י בוחני נס”א, הוכיחה אדהזיה לא תקינה בעקבות חוסר צבע יסוד- תקלה של היצרן. בבדיקת הדגם/הבק”מ בחו”ל לא בוצעה בדיקת אדהזיה. בשלב ה-E&DT היה צורך בהגדרת ביצוע בדיקת אדהזיה לארגז המשאית. בשלב ה-E&AT היה צורך בביצוע בדיקת אדהזיה בשלב בחינת הדגם והבק”מ במפעל בחו”ל (לעצור את “העברת המקל”). צבאי חוסר דרישות לבדיקה מינורית- אי נוחות סטייה קלה בביצועים, בעלויות ובלוחות הזמנים. etl20112003\corrosion in International trucks 8.2.pdf
תעשיית רכב ותחבורה
ב-12 לאוקטובר 2007, במהלך אימון של יחידת חי”ר בצבא דרום אפריקה, נעשה שימוש בעמדות נשק נגד מטוסים. השימוש נעשה בתרחיש לא אופייני- ירי בזוית 0 מעלות (ולא ירי בהגבהה כפי שנדרש מנשק נ”מ). בעקבות אוסף של תקלות, המערכת איבדה שליטה והחלה לירות תוך כדי תנועת סיבוב. באירוע נהרגו 9 חיילים וחיילות, 15 נפצעו. כאשר מסבים שימוש אופייני של מערכת לשימוש אחר, יש לנתח את השינויים המערכתיים הנובעים מהשינוי באופן השימוש. יש להגדיר תרחישי בדיקה נוספים או להתאים תרחישי בדיקה קיימים ולבצע בדיקות OT&E לפני הוספת תרחיש שימוש במערכת. יש לקחת בחשבון את ההשפעה של מערכת אחת על מערכת אחרת (זהה או שונה), בעת שימוש במערכות (“חיים בצוותא”). יש להקפיד על ביצוע בדיקות חוזרות לאחר תיקון תקלה לכל הבדיקות המוגדרות כבדיקות המכסות את ההיבטים הבטיחותיים של מערכות בעלות אופי בטיחותי. בטחוני/ צבאי אחר- מערכות נשק. חוסר דרישות לבדיקה. קריטית T&E 2010\anti-aircraft gun friendly fire 16.9.2010.pdf
חוסר בדרישות לבדיקת יכולת פעולה הדדית (יפ”ה)
לא בוצעו בדיקות לאחר שינוי
סביבת בדיקות לא מתאימה
באירוע נבחנה מערכת נומינלית אשר הותקנה בקו הייצור באתר הלקוח, ובסדרת הבדיקות המדוברת נבחנה תאימות פרוטוקולי תקשורת מסוג SECS/GEM (E39,E40,E87,E90,E94,E116) בין המערכת שלנו לבין המערכת המרכזית המפקחת על קו הייצור של הלקוח. בסדרת הבדיקות נתגלו מספר ליקויים, ברמות חומרה קלות שנפתרו מיידית על ידי שינוי קוד תוך כדי סדרת הבדיקות, עד רמת חומרה מג’ורית שדרשו שינויי תכן מסויימים ונפתרו בגרסאות הבאות. עיקר הליקויים נבעו עקב חוסר הבנה לפרטי פרטים של דרישות הלקוח והכרת סביבתו, טעויות בהבנת והטמעת התקן, ומשימוש במדמה מיושן שאינו תואם את התקן. כמו כן לא נערך תיאום ציפיות בין החברה ללקוח, לגבי אופן ביצוע הבדיקות והדרישות המדויקות. היטק אחר- מערכת AOI (Automatic OpticalInspection) בתחום המוליכים למחצה (Semiconductors). חוסר דרישות, חוסר דרישות לבדיקה, דרישות שלא יודעים איך לבדוק,         30=צבד לא תקין T&E 2010\AT&E in Toshiba 16.9.2010.pdf
לא הוגדר קונספט בחינה והערכה קלה עד מג’ורית
 החלק המרכזי של הכישלון נבע כיוון ששלבי ה E&T לא הוגדרו נכון בכל השלבים השונים ובשלב ייצור האב טיפוס. לאחר מעבר מבחני ה-DT&E, יש לשים דגש גם על ביצועי מבחני ה-OT&E, ולא להניח שמבחני ה-DT&E מכסים את כל הבדיקות הנדרשות להוצאת המוצר לשוק. טעות זו נובעת לרוב, מההנחה שמאפייני המוצר והמהנדסים של החברה, יכולים לעלות על כל תרחישי השימוש ולבנות תוכנית מבחני DT&E שיכסו את כל התרחישים וכל התנאים, ללא העזרות בלקוחות אמיתיים. מערכות ציוד רפואי ביצוע מאוחר מדי של בדיקות OT&E. מינורית- סטייה קלה בעלויות ולו”ז. מ T&E 2010\medingo-insulin inserter 16.9.2010.pdf
האירוע מתאר ייצור עגלת נשיאה עבור קו הרכבה ברפאל על ידי קבלן משנה. בעגלה שיוצרה התפתחה קורוזיה לאחר זמן מה, שאיימה לפגוע במוצר המורכב, מה שחייב את הפסקת השימוש בה, ובעקבות כך את השבתת קו ההרכבה. מתחקיר האירוע התברר כי הקבלן שייצר את העגלה לא עמד בנהלי רפאל לביצוע ריתוכים. כמו כן התברר כי התופעה אינה חד פעמית במונחים כלל רפאליים, ועל כן הוחלט על ביצוע רביזיה בתהליך ההפצה של נהלים והגדרת בדיקות הקבלה של פרויקטים בחטיבה. בטחוני חוסר דרישות לבדיקה מג’ורית- עיקוב בלוח זמנים ובעלות בעקבות קנסות מצד הלקוח הסופי. T&E 2010\carring cart 16.9.2010.pdf
דרישות שלא נבדקו
הפרויקט הינו פיתוח מיכלי דלק פלב”ם משוככים לתומ”ת כמענה לבעיה חמורה של נזילות מהמיכלים הקיימים עשויים פיברגלס. באופיון טכני נכתבה דרישה לעמידות המיכלים בהלמים ורעידות שנרשמו בניסוי ירי ונסיעה אמיתיים, כמו כן הוגדר באופיון כי הדרישה תיבדק במתקני היצרן למול הגרפי הניסויים (תחום תדרים בגרפים 0-1000 הרץ ותאוצה 0-100G). לאחר קבלת הזמנה ע”י היצרן בוצע דיון התנעה בו נאמר לצה”ל כי לא קיימת שום בעיה לביצוע בדיקות הרעדה והלם. במהלך ייצור הדגם הראשון ולקראת הכנה לביצוע בדיקות הרעדה התברר כי לא קיים בארץ מרעד לביצוע בדיקות הלם ובדיקות הרעדה ניתנים לביצוע רק בתחום 0-30 הרץ (המרעדים הקיימים לא מסוגלים להרעיד משקל 300 ק”ג במימדים של 1.5 מטר על 0.5 מטר). א. הוגדרה בדיקה באופיון מבלי לבדוק האם זה ניתן לביצוע בפועל.
ב. יצרן לא ביצע בדיקה מעמיקה לדרישה  ובכך הטעה לקוח (צה”ל).
צבאי דרישות שלא יודעים איך לבדוק מינורית – אי נוחות, סטיה קלה בעלויות ובלוחות זמנים (עד 5%). etl20112003\stainless steel fuel tank 1.3 (1).pdf
ציוד בדיקה אינו יכול לבדוק את כל הבדיקות
מדובר באירוע כיבוי מערכת CT רפואית בזמן ביצוע בדיקה פולשנית. האירוע קרה לאחר שהותקנה גרסה חדשה של מערכת הCT באתר “בטא טסט”. כתוצאה מהאירוע נגרם נזק (מינורי) לחולה ולמוניטין החברה. א. בהחלפת חומרה של רכיב במערכת יש לצפות לשינוים בתפקוד התוכנה הפועלת על אותה החומרה. חובה להעריך את הצימוד חומרה-תוכנה כסיכון בשלב מוקדם של DT&E  ולתכנן את הבדיקות בהתאם. חובה לבצע בדיקה יסודית של התוכנה וכן של המודולים שמתממשקים איתה.

ב. כדאי להשקיע זמן לסקירת קוד יסודית.

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

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

מערכת ציוד רפואי חוסר דרישות לבדיקה מג’ורית- ביצועים בלתי מספקים. T&E 2010\ct fluoroscopy 26.8.2010.pdf
לא בוצעו בדיקות לאחר שינוי
לא בוצעו בדיקות אינטגרציה
ב 12/8/00הצוללת הרוסית של הצי הרוסי הצפוני, קורסק, במהלך תרגיל ימי רחב היקף מתכוננת לבצע ירי חי של טורפדו עם רש”ק דמה לעבר אוניות הצי הרוסי – המביימות אוייב אמריקאי. הצוללת קורסק הינה צוללת אחת מתוך שש צוללות תקיפה באותו התרגיל. הקורסק ננעלת על מטרתה ומפקד הצוללת מאשר ירי. תא טורפדו מספר 4 מתפוצץ, צוות הקורסק כולל מפקד הצוללת נפגעים אנושות ולא מצליחים לתמרן את הצוללת אל פני המים.
הצוללת טובעה למצולות ואחרי 135 שניות מהפיצוץ הראשון פיצוץ נוסף מבקע את חרטום הצוללת.
א. לבנות תוכנית הכשרה מלאה לכל מפעיל בצוללת בכלל, ובפרט למפקד תא הכורים שעל כתפיו מונחת אורך חייה של הצוללת.

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

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

צבאי – צוללות אי שילוב בדיקות OT&E בשלבים מוקדמים. קריטית – כשל משימה, אירוע בטיחותי חמור, סטייה משמעותית בביצועים. etl20112003\russia’s KURSK 1.3.pdf
חוסר תכנון בדיקות מקיפות
חוסר בדיקתיות
האירוע מתאר כשל תיכון בסורק חדש, הכשל התבטא בתקלות מכאניקה חוזרות ונשנות בזמן טעינת קסטות ובנוסף תקלות תוכנה בעת הפעלת אפליקציות מקבילות על מחשב סורק. כל הכשלים התגלו בשלב מאוחר מאוד בפרויקט, אי גילויים בזמן גרם להוצאות נוספות ולעיכובים בלוחות הזמנים. תוכנית הבדיקות בפרויקט הפיתוח הייתה נרחבת וחסרת תקדים במונחי החברה, למרות זאת תקלות הטעינה ותקלות התוכנה לא התגלו בשלבים המוקדמים של הפרויקט, אלא מאוחר יותר על ידי צוות ילדים שעבדו בחופשת הקיץ, המסקנה העיקרית היא שיש לשלב OT&E בשלבי הפיתוח, יש לשלב צוותי בדיקה לא מיומנים שייצגו לקוחות אמיתיים במיוחד כאשר מדובר בממשקי אדם מכונה (טעינת קסטה למכונה במקרה זה). מערכות ציוד רפואי אי שילוב OT&E בפיתוח מוצר. מינורית- אי נוחות סטייה קלה בביצועים, בעלויות ובלוחות הזמנים. T&E 2010\medical CR system 2.9.2010.pdf
מטרת תקני Mil-Std היא להבטיח שבעת פיתוח מוצר צבאי ילקחו בחשבון כל התנאים להם ייחשף המוצר במהלך חייו.  עם כל עדכון חדש של התקן שמים יותר ויותר דגש על הצורך בביצוע בדיקות, ניסויים והגדרות לסביבת עבודת המוצר. במהלך עבודתי נחשפתי לדרישות מוגזמות לתכן, שפשוט מגדירות כי המוצר יעמוד בתקן בכללי. דבר הגורם לבזבזנות מבחינת תקציבים, לו”ז ותכן עודף. דוגמא לכך ביצוע ניסויים למחשב RPT המיועד להתקנה בנגמ”ש, אשר סדרת הניסויים שהורצה עליו לא תואמת סביבת עבודה (רוב הסיכויים שהמפעיל לא ישרוד), ודוגמא נוספת מספרות היא פיתוח למכונת קפה עבור חיל האוויר האמריקאי שבסופו של דבר עלתה למשלם המיסים 8000$ ליחידה. א. מהנדס המערכת אמור לתת את הדעת לדרישות שהוא מציג לספק. לכל דרישה יש משמעויות תקציביות ולו”ז.

ב. הגדרה כללית לתנאי סביבה בשלבי ה-DT&E  או ה-AT&E עלולה לשנות לגמרי את מהות המוצר.

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

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

בטחוני / צבאי דרישות – דרישות מיותרות, תנאים מעבר לנדרש למחזור חיים של המוצר מג’ורית- ביצועים בלתי מספקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%) etl20112003\mil-std 1.3.pdf
ציוד בדיקה אינו מתאים לשלב מחזור החיים הנדרש
בדיקות מיותרות ולתכונות Nice to have
סביבת בדיקות לא מתאימה
חוסר התייחסות לנתוני בדיקות במאגרים קיימים.
ב-28 בינואר 1986, במהלך משימה STS-51-L התפוצצה מעבורת החלל 73 שניות לאחר ההמראה ממרכז החלל קנדי שבפלורידה, בגובה 16 ק”מ בעקבות אטם בטיל ההאצה, שנפגם כתוצאה מהטמפרטורה הנמוכה ששררה ביום השיגור. כתוצאה מכך, גזים לוהטים נפלטו ממנו וחיממו את מכל הדלק הנוזלי הגדול שבגחון המעבורת, עד שהמכל התפוצץ והמעבורת התרסקה לאוקיינוס האטלנטי. כתוצאה, נהרגו 7 אסטרונאוטים וטיסות המעבורות קורקעו למשך שני וחצי. יישום מסקנות הועדה לחקר אסון מעבורת החלל כגון: החלפת אטם מחבר המנוע הרקטי שכשל, מבנה ארגוני של תוכנית החלל-ארגון מחדש, אי שימוש באסטרונאוטים כמנהלים- יוצר ניגוד אינטרסים ופגיעה באספקטי בטיחות, ביצוע אנליזת גורמי סיכון קריטיים, הקמת אגף בטיחות עצמאי בנאס”א, שיפור התקשורת בין כלל הגורמים בתוכנית החלל, שיפור בטיחות נחיתה, תכנון תא בטוח להגנה על אנשי הצוות בחירום, תכנון מדיניות תקציבית תואמת לעלות הפרויקט למניעת הלחצים הנגרמים בעקבות אי עמידה בלו”ז. תעופה וחלל חוסר דרישות קריטית: כשל משימה, עלות ובלוח הזמנים.
בתאריך 29.1.10 פרסמה TOYOTA  “קריאת שרות” ל2.3 מליון מכוניות בארה”ב כתוצאה מאפשרות של תקלה בדוושת ההאצה בדגמים מסוימים של טויוטה. “קריאת שרות” זו באה כתוצאה ממספר פניות של לקוחות שהתלוננו על דוושה “קשה” או דוושה “דביקה” מה שיכול לגרום ל”תקיעת” המצערת במצב פתוח ולהאצה תמידית.
התחקירים של חברת טויוטה ו NHTSA- National Highway Traffic Safety) Administration ) מצביעים על כך שמנגנון הפעלת המצערת גרם לחיכוך מוגבר בדוושת ההאצה, דבר הנבע משתי סיבות:
1. שחיקה טבעית של המנגנון.
2. השפעת תנאי אקלים קיצוניים.
עיקר הכשלים שהביאו לתקלה ולקריאת השירות הינם כשלים שנכנסים בשלב ה DT&E של פיתוח המוצר.
היה מחדל בבדיקת הדרישות השונות על החומר שממנו עשוי מנגנון החיכוך וניתן היה לפתח בקלות מערכת שיכלה למנוע תאונה גם במקרה של תקלה.
תעשיית הרכב  חוסר בדרישות
דרישות שלא נבדקו
אי שילוב OT&E בפיתוח המוצר
קריטית etl20112003\toyota recall 1.3.pdf
בפרויקט פיתוח סוללה נטענת פותח גם מטען לסוללה. נכתבו דרישות ספורות למטען במסגרת נספח למפרט הסוללה ובין הדרישות לסוללה עצמה. למטען לא הוגדר ממשק משתמש באופן מסודר ולא הוגדרו בדיקות לממשק זה. אנשי הפיתוח והבדיקות אצל היצרן התקשו לעקוב אחר הדרישות למטען, שהיו פזורות על פני מפרט הסוללה וסיכומי דיוני התכן. אנשי המזמין לא ביצעו ביקורות באתר היצרן, אלא הסתמכו על דו”חות שסיפק היצרן. המטען שנשלח אל המזמין הגיעו כשהוא חסר פונקציונאליות מסוימת ובעל ממשק משתמש קשה לתפעול. המטען עבר שני סבבי תיקונים אצל היצרן בטרם הגיע לבשלות. א. יש לכתוב מפרט מסודר ומרוכז במסמך אחד.
ב. יש להגדיר את הדרישות לממשק המשתמש ולהגדיר את הבדיקות לממשק.
ג. בשילוב מוצר קיים במסגרת פרויקט פיתוח יש לבצע הערכת סיכונים לגבי האפשרות שהמוצר לא יתאים בסופו של דבר לצרכי הפרויקט. יש לקבוע אמות מידה לחלופות.
ד. יש להגדיר במפרט דרישות לבדיקות הוכחה למוצר. דרישות אלה יש לעדכן במהלך דיוני התכן, כך שיתאימו למוצר הסופי.
ה. יש להגדיר במפרט דרישות לבדיקות קבלה למוצרים סידרתים בכלל ולסדרה אפס בפרט. דרישות אלה יש לעדכן במהלך דיוני התכן, כך שיתאימו למוצר הסופי.
ו. יש לשלב את אנשי המזמין בבדיקות אצל היצרן משלב מוקדם ככל הניתן.
מערכות אלקטרוניות חוסר דרישות מג’ורית- ביצועים בלתי מספקים, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%) Battery_Charger_Development_04-08-2011.pdf
חוסר דרישות לבדיקה
דרישות שלא נבדקו
דרישות שאינן כלולות בתוכנית הבדיקות
אי שילוב בדיקות OT&E בשלבים מוקדמים
לא הייתה התייחסות ל OT&E בשלבי פיתוח המוצר
לא הוגדר קונספט בחינה והערכה
בפרויקט מסוים המסכים התחילו לחזור מהלקוח “שרופים”. בבדיקה מעמיקה שנעשתה במפעל התברר שהמודול התקול הוא מודול תאורה של המסך. הסיבה לכך שהתקלה לא התגלתה ביצור נבעה מכך שבבדיקות תנאי סביבה (וביניהם בדיקת חום) ביצור, בהירות המסך הייתה בערך ברירת מחדל ולא בערך המקסימאלי – שזה המצב המחמיר מבחינת ההספק והחום שמתפתחים במסך.
כתוצאה מכך, הבדיקה ביצור עברה ואצל הלקוח – שהשתמש במסכים רוב הזמן בעוצמה המקסימאלית, הם “נשרפו”.
א. כבר בשלבי הפיתוח הראשוניים חייבים להשתמש בשיטות לאימות התכן כדי לזהות בעיות.
ב. כל מוצר חייב להיבדק לפי התנאים הקיצוניים המוגדרים במפרט ולא לפי התנאים הטיפוסיים.
ג. במקרה הזה שלב ה- OT&Eהחסר היה קריטי ולכן יש לשקול בכל פרויקט, לפי התקציב הקיים, לשלב בדיקות ה- OT&E
מערכות אלקטרוניות חוסר דרישות לבדיקה מג’ורית- ביצועים בלתי מספקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%) uc_Displays_Failure_04_08_2011.pdf
דרישות שלא נבדקו
 אי שילוב בדיקות OT&E בשלבים מוקדמים
לא הייתה התייחסות ל- OT&E בשלבי פיתוח המוצר
חוסר תכנון בדיקות ו/או תקצובן
במערכת HMD מסוימת, יוצרה מערכת הנדסית להדגמה ללקוח. בשלבי ייצור, הרכבה, ATP תת-מערכת בוצעו בדיקות הנדסיות שכללו בין היתר איכות תמונה, פגמים ולכלוכים שנעשו באמצעות מצלמה. בשלבי אינטגרציית מערכת סופיים, לפני שהמערכת הייתה צריכה לעזוב את שערי המפעל ולטוס להדגמה ללקוח, המערכת נבדקה בשלמותה עם תצוגה אופיינית ע”י משתמש אופייני (טייס). התגלו לכלוכים במודול האופטי והמערכת נמצאה לא קבילה. הדבר גרר דחייה בלו”ז, אי-נעימות מול הלקוח, עלויות לא צפויות והעמדת מערכת חליפית בתנאי לחץ על מנת להביא מערכת ללקוח במינימום איחור. בנוסף, נגרם לחברה נזק תדמיתי. א. בדיקת OT&E – במקרה זה בדיקת מערכת בעין או באמצעי חליפי מתאים ע”י משתמש אופייני או גורם מוסמך לכך – צריכה להיות מתוכננת בתוכנית T&E ולהתבצע בכל שלב קריטי ( לפני איטום, בשלב ATP תת-מערכת, בשלב ATP מערכת).
ב. ציוד בדיקה חייב להיות תואם ומסוגל לגלות את כל התקלות שהוא בא לבדוק
ג. ציוד בדיקה וכל התשתיות הנדרשות צריכות להיות מתוכננות כך שיאפשרו לבדוק את תתי-מכלולים מהיבטים קריטיים – דרישה לבדיקתיות.
ד. תוכנית בדיקות ה- AT&E צריכה להיות מוגדרת, מתואמת עם הייצור ולהיבדק ע”י מבקר מהייצור, ומיושמת גם לבדיקת דגמים הנדסיים.
מערכת אוויונית חוסר דרישות לבדיקה מינורית – אי נוחות, סטייה קלה בביצועים, בעלויות ובלוח זמנים (עד 5%) HMD Image Quality Failure_04.08.pdf
דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
 ציוד בדיקה אינו יכול לבדוק את כל הבדיקות
אי שילוב בדיקות OT&E בשלבים מוקדמים
ה- MARINER היא תוכנית של סוכנות חלל אמריקאית NASA בשנים 1963-1973 למחקר כוכבים:  מאדים, נוגה ומרקורי . Mariner 1 הייתה חללית ראשונה בסדרה ומטרתה הייתה לבצע טיסה על פני נוגה ולהעביר נתונים שונים לגבי- אטמוספרה, שדה מגנטי, מסת החלקיקים וכוי. כעבור 293 שניות משיגור החללית קצין בטיחות הניסוי ביצע השמדת החללית, כאשר זיהה סטייה מהמסלול.  תקינות התקשורת ועוצמת אות שידור יש לבדוק ע”י סימולציות וגם בניסויים פונקציונאליים בשלב DT&E ובהמשך בשלב OT&E.
בעת ביצוע בדיקות תוכנה נדרש לעבור על כל התרחישים האפשריים ולוודא פעולות תקינה של מערכת. יש לבצע הבדיקות תוכנה בכל שלבי T&E.
יש לשלב מערכת יעילה לדיווח וריכוז תקלות הניסוי בכל תוכנית T&E. כמו כן יש לבצע תחקור וניתוח תקלות שעלו בעת ניסויים ולעקוב שנתנו להם פתרונות.
– תעופה וחלל חוסר דרישות לבדיקה. קריטית – כשל משימה Mariner1 01.08.11.pdf
דרישות שלא נבדקו
חוסר תכנון בדיקות או תקצובן
תחקור איורע מהיר ולא מפורט
Mars climate orbiter (MCO)
היא חלק מתוכנית לחקר המאדים של סוכנות החלל האמריקאית NASA בסוף בשנות ה-90, שמטרתה בדיקת אקלים במאדים. שיגור החללית עבר בהצלחה, כל המידע שהתקבל מהחלליתעד לכניסתה למסלול סובב המאדים היה כמצופה. בקרי הטיסה לא הצליחו לגלות אותותכאשר היה צפוי כי החללית תגיע מאחורי הכוכב.
MCO אבדה.
הסיבה העיקרית לאובדן החללית הייתה כישלון של התוכנה בשימוש ביחידות אינצ’יותבמקום ביחידות מטריות.
במהלך המסע של החללית מהשיגור, המערכת ביצעה באופן מחזורי תיקוני דחף בכדילפצות על סטיות ההתמד הזוויתי שהצטברו בגלגל התנופה (חלק ממערכת ההנעה), בשלאסימטריה של מערך תאים סולאריים ביחס לגוף החללית שגרמו לסטיות גדולות יותרמהצפוי.
הצורך בתיקונים גרמו להצטברות טעויות רבות יותר במסלול שהביאו לאובדןהחללית.
א. לוודא שימוש אחיד באותן יחידות בכל ערוצי המערכת, לבצע בדיקתיות לתוכנה בשלב היחידה ולבצע בדיקות תיקוף ובדיקות מערכת.
ב. לבצע בדיקת התאמה בין ממשקי התוכנה של הצוותים השונים, כלומר לבצע בדיקות שילובים.
ג. לבצע סקרי תיכון בלתי תלויים על כל האירועים הקריטיים הצפויים במשימה, לבצע DT&E להערכת התקדמות האבולוציונית של הפיתוח.
ד. לבצע עץ תקלות אפשריות למשימות השונות.
ה. להשוות את הצפי של מסלול מערכת הניווט לשיטות ניווט אחרות על מנת לוודא שהתוצאות נכונות, לבצע תהליך V&V.
ו. לערב את צוות התפעול (הביצוע) בשלב מוקדם בפרויקט, עדיף כבר בשלב של הכנת תוכנית הפרויקט, Early OT&E.
ז. תהליכי V&V לא טופלו באופן מספק בתוכנית התפעול שהייתה בבקרה הקרקעית.
תעופה וחלל חוסר דרישות לבדיקה קריטית – כשל משימה Mars Climate Orbiter 4.8.pdf
חוסר בדיקתיות
לא בוצעו בדיקות אינטגרציה
לא הייתה התייחסות ל- OT&E בשלבי פיתוח המוצר
בשנת 2005 נחתם חוזה לאספקת מערכת מל”טים בין תעשייה ישראלית למדינה זרה. בחוזה הוגדר כי אספקת המטע”דים האלקטרואופטיים בפרויקט תיעשה ע”י קב”מ מארץ הלקוח. הקב”מ, בעל ניסיון בייצור מערכות א”א, אך עם ניסיון דל בפיתוחו וידע מועט במל”טים, ביצע פיתוח של מטע”ד אשר עמד בלו”ז, בעלות ובמפרט הנדרש, אך אינו נותן מענה לדרישות וצרכי הלקוח בשילוב על מל”ט ובבחינה בסביבה הריאליסטית.
במרכז האירוע התעלמות והזנחת OT&E בשלבי הפיתוח המוקדמים, אשר הובילו לגילוי התוצאה בשלב מאוחר לאחר השלמת תהליך הפיתוח.
א. יש לשלב תהליכי OT&E כמה שיותר מוקדם בתהליך הפיתוח, בדגש על EOA ו-OA אשר יעריכו את המועילות וההתאמה המבצעית של המערכת בטחוני/ צבאי
תעופה וחלל
דרישות שאינן כלולות בתוכנית הבדיקות מג’ורית – ביצועים בלתי מספקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%)  UAS_inappropriate_payload_4.8.pdf
ב. יש לשלב את גורמי התפעול המבצעיים של המערכת (מצד התעשייה ו/או מצד הלקוח הסופי) בשלבי הפיתוח המוקדמים אי שילוב בדיקות OT&E בשלבים מוקדמים
ג. יש לבצע ניסויי טיסה בסביבה ריאליסטית כמה שניתן, תוך התחשבות בתרחישי העבודה של המערכת  לא הייתה התייחסות ל-OT&E בשלבי פיתוח המוצר
ד. ביצוע תהליכיAT&E  באוריינטציה של DT&E בתנאי מעבדה מעכבת עוד יותר את קבלת התמונה האמיתית על מועילות המערכת. יש לשאוף לבצע את בדיקות הקבלה של המערכת על המערכת מלאה סביבת בדיקות לא מתאימה
במערכת תצפית ימית אשר משתמשת בטכנולוגיה ייחודית של הארת המטרה בלייזר Class 4, נשכחה דרישה חשובה של בדיקת יציאת הלייזר בזמן אמת מהמערכת. כתוצאה מכך לא ניתן היה לבקר בטיחותית ומבצעית את עוצמת הלייזר היוצאת ולא ניתן היה למנוע תקלות בטיחות של המערכת. כמו כן לא ניתן היה לדעת באם המערכת מבצעת את ייעודה.
הדרישה שנשכחה התגלתה לבסוף לאחר ייצור אב טיפוס ראשוני ותוקנה ע”י הוספת חומרה ייעודית (לא מתוכננת ולכן גם לא כחלק אינטגראלי מהמערכת).
1. יש לשלב את שלב ה OT&E כבר בשלב
התכן המקדים (EOA) על מנת לראות מבעוד מועד את כל הבדיקות אותן יש לבצע על מנת לעלות על כל הכשלים.
מערכות ים חוסר דרישות מינורית – המערכת שונתה כבר בשלב האב טיפוס והסטייה בלוחות הזמנים הייתה קטנה מאוד.  lack of Laser output check 04.08.pdf
2. יש להגדיר היטב את מפרט דרישות
המערכת על פי תרחישי הייחוס העיקריים והמשניים של המערכת.
חוסר דרישות לבדיקה
3. יש להבין את הבעיות המרכזיות של
המערכת גם מהיבטי הבטיחות ולא רק מהיבטי המבצעיות.
אי שילוב בדיקות OT&E בשלבים מוקדמים
לא הייתה התייחסות
ל OT&E בשלבי פיתוח המוצר
חסר תכנון בדיקות
מדובר בפרויקט מורכב לפיתוח מערכת אוויונית במסגרת הפרויקט פותחו מחשבי טיסה, צגים חכמים וחיישנים שונים. פיתוח הפרויקט נמשך יותר מחמש שנים והוא כלל מרכיבי חומרה ותוכנה שסופקו מיצרנים שונים כולל מודולי תוכנה שפותחו ע”י הלקוח. עקב מורכבות והיקף המערכת, הפיתוח והאינטגרציה נעשו בשלבים. בכל שלב שולבו מרכיבים נוספים או פונקציות נוספות.
באחד השדרוגים המתוכננים של המערכת, התגלתה תקלה בצגים,  שגרמה לחוסר תפקוד של אחד מהמחשבים בצגים והשבתת הפונקציות הקשורות בו, בעת התקנת הצגים המשודרגים על הפלטפורמה לצורך טיסות ניסוי.
א. יש לבצע בדיקות רגרסיה למערכת, לאחר שדרוג החומרה והתוכנה,  ע”י צוות הנדסת מערכת, או נציג הלקוח, כאשר מוודאים שמחברים שאינם קיימים על המערכת המבצעית מנותקים.
ב. יש להוסיף לרשימת דרישות הרגרסיה, דרישה שתוודא היעדר פונקציות התלויות במחבר המבדק שאינו קיים במערכת המבצעית.
ג. יש להוסיף בדיקות למבדקי החומרה האוטומטיים, שבודקים תפקודים בסיסיים של החומרה, ללא הפעלת הסיגנלים ממחבר המבדק שאינו קיים במערכת המבצעית.
תעופה וחלל חוסר דרישות לבדיקה מינורית – אי נוחות, התקלה תוקנה אם כי נוצר חשש וחוסר אמון של הלקוח. LRU upgrade failure on operational platform 04 08 2011.pdf
דרישות שאינן כלולות בתוכנית הבדיקות, בעיקר OT&E.
 לא בוצעו בדיקות רגרסיה
בין יוני 1985 לינואר 1987 מאיץ לינארי רפואי, Therac-25, הקרין הקרנת-יתר בצורה קטלנית על 6 מטופלים. בכל המקרים המטופלים דיווחו שחשו תחושה של “בערה”.
כל המטופלים פיתחו סימפטומים של קרינת יתר : אדמומיות בעור, תחושה של שיתוק, כאבים עזים ועוויתות.
2 מקרים הסתיימו במוות כתוצאה מקרינת יתר. 4 מקרים הסתיימו בפגיעה באיבר שעבר הקרנה.
בכל המקרים המטופלים קיבלו טיפול בקרינה ברמות של 13,000-25,000 rad (טיפול רגיל אמור להיות באזור 200 rad, הקרנה של 500 rad  לכל הגוף תגרום למוות ב-50% מהמקרים)
במערכות בהן מרכיב התוכנה משמעותי יש לכלול את רכיבי התוכנה בכל בדיקות המערכת ובפרט בבדיקות הבטיחות.
לא מספיק לבצע בדיקה של רכיבי התוכנה כחלק מהמערכת, אלא חשוב לבדוק כל רכיב בפני עצמו.
יש לבצע בדיקות שימוש על ידי סוגים שונים של משתמשים חדשים ומנוסים, שעשויים לייצג תרחישי הפעלה שונים.
יש לבדוק קוד קיים המשולב במערכת ואת מידת התאמתו למערכת החדשה.
יש לתכנן את תוכנת המערכת כך שתהיה ברת בדיקה, ולשלב עין חיצונית המבצעת בקרה לקוד המערכת שנכתב – בנוסף לבדיקות על רכיבי התוכנה.
לאחר תיקון תקלה יש לבצע בדיקת רגרסיה למערכת ובדיקת כלל תרחישי השימוש ולא של התרחיש שהוביל לתקלה בלבד.
מערכות ציוד רפואי מרכיביREUSEשלא נדרש לבדוק קריטית – כשל משימה, הפסד השוק, אירוע בטיחותי, איום על קיום הארגון, סטייה משמעותית בביצועים, עלות ובלוח זמנים (מעל 20%). Therac25_04-08-2011.pdf
חוסר בדיקתיות
לא בוצעו בדיקות רגרסיה
לא הייתה התייחסות לבדיקות OT&E בשלבי פיתוח המוצר
בדיקות בטיחות חסרות
מערכת צבאית המציגה וידאו על גבי המסך נשלחה ללקוח .
המערכת עברה בהצלחה גם ניסויים הנדסיים וגם תהליכי  ESS ,הרעדה ,ATP עם צב”ד יעודי יצורי.
באינטגרציה של מערכת בכלי יעודי נצפו הפרעות בוידאו על גבי המסך של היחידה.
התקלה גרמה לשליחת צוות טכני ללקוח .הצוות גילה שפורמט הוידאו בכניסה למערכת אינו תואם תקן
סטנדרטי כמו שהוגדר בדרישות מערכת. התקלה טופלה במקום ע”י עדכון גרסת תוכנה .
תקלה גרמה נזק מינורי .
א. יש לבצע אינטגציה בשלבים מוקדמים של הפרויקט ,DT&E.
ב. יש להיזהר בהגדרת הדרישות למוצר חדש על סמך ניסיון העבר.(תקלת REUSE)
ג. תוכנית בדיקות ה- DT&E  ,POD צריכה לבדוק רובוסטיות של תכנון.
מערכת צבאית חוסר דרישות לבדיקה מינורית VIDEO Distortion 04.07
חוסר דרישות
חוסר בציוד בדיקה מתאים
לא בוצעו בדיקות אינטגרציה
בספטמבר 2010 נערכו בדיקות GAT של מל”ט מסוג “הרמס 450” מקרון שליטה באתר ניסויים.במהלך הבדיקות לא צלח ניסיון יצירת קשר P2P (Point to point) עם המל”ט. לאחר בדיקה של כמה שעות התגלה כי המרכיב התוכנתי שאחראי על שליחת תדרי תקשורת למקטע תקשורת קרקעי אינו שלח כראוי את התדרים החדשים באתר הניסויים.עקב כך הופסקו בדיקות ה GAT ונדחו בכחודש, עד לפיתרון הבעיה ושריון מועד חדש. א. יש לדרוש בצורה יותר ברורה וממוקדת את ספקטרום התדרים שמולם יעבוד מכשיר התקשורת אל מול הנתונים הטכניים של מכשיר התקשורת   ב. יש לבדוק בשלבים ראשוניים את מכשיר התקשורת אל מול ספקטרום התדרים (DT&E)     ג. יש להוסיף תרחישים מבצעיים לבדיקות, כולל נתונים אמיתיים על פי נתוני הלקוחות, אתרי ניסויים וכו… (OT&E)  ד. על אנשי התפעול והתפעול לעבור על בדיקות התכן לאשרן בשלב מוקדם תעופה וחלל חוסר דרישות מינורית- אי נוחות, סטייה קלה בביצועים, בעלויות ובלוח זמנים uav failure 3.8.pdf
חוסר דרישות לבדיקה
אי שילוב בדיקות OT&E בשלבים מוקדמים
בתאריך ה-15.01.90 בשעה 14:25 מנהלי רשת של AT&T במרכז המבצעים של הרשת שמו לב לנקודות התרעה אדומות על המסכים ממספר מרכזים בעולם. תוך שניות כל מסכי הרשת התכסו בנקודות אדומות. כ-50% מהשיחות שנכנסו לרשת לא הצליחו להגיע ליעדן.כעבור 9 שעות הצליחו לייצב את הרשת, בשלב הזה הפסידה AT&T $60 מיליון בשיחות שלא הצליחו להתחבר. הגורם לבעיה הייתה שורת קוד בתוכנה. בתחילת דצמבר הגיעו טכנאים לשדרג סוגים מסוימים של הודעות. למרות שהשדרוג נבדק שורת קוד אחת נוספה בשוגג ל-114 המתגים ברשת. מתג אחד הגיע לקיבולתו המרבית הוא אתחל את עצמו. נשלחה הודעה לשכניו שיש בו בעיה כאשר המתג חזר לתפקד הוא שלח לשכניו את ההודעות שנצברו בתוכו ובמתגים השכנים  שורת הקוד הבעייתית גרמה לדריסת מידע תקשורת חשוב שגרם לאתחול בתוכם גם כן וכך זה התגלגל לרשת כולה. א.  שימוש במהדר (compiler) בשפת C אינו מספיק יש לעבור לשפת תכנות מובנה שבהן יש מהדרים קפדנים יותר שמעלים את אחוז גילוי השגיאות המוקדמות בתוכנה.

ב. שימוש בחומרה ובתוכנה “סובלנית” יותר יכול לטפל בתקלות מינוריות ללא אתחול המערכת

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

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

ה.  בעת שדרוג עתידי יש לבצע שדרוג הדרגתי בשטח כדי לוודא שההטמעה עברה בהצלחה

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

מערכות תקשורת חוסר דרישות קריטית – כשל משימה, הפסד השוק, אירוע בטיחותי, איום על קיום הארגון, סטייה משמעותית בביצועים, עלות ובלוח זמנים (מעל 20%).  The 1990 AT&T Long Distance Network Collapse 04.08.pdf
מערכות תוכנה חוסר דרישות לבדיקה
חוסר בדיקיתיות
לא בוצעו בדיקות רגרסיה כמו שצריך
הגורם האנושי- לחצי החגים גרמו לחוסר תשומת לב בעת ביצוע הבדיקות
בצגים מבוססי LCD נעשה שימוש במוליכי אור (Lightguide – LG) הצרובים במערך ייחודי דמוי רשת, כחלק מתאורה אחורית. קבלן משנה שצרב את חומר הגלם (Acrylic) בעזרת ציוד חדש מבוסס לייזר וסיפק כבר מספר מנות בהצלחה, לא הצליח לייצר מנות נוספות שיעמדו במפרט האופטי כנדרש (הבדיקות בוצעו ע”י המזמין ובמעבדתו). בדיקה העלתה שבעקבות ירידה בעוצמת הלייזר לאורך זמן, עומק ההדפס בחומר הגלם נמוך משמעותית מהנדרש.
הגדרת עוצמת הלייזר כ-CI, פעילות DT&E של היצרן כמו גם הגדרת סט בדיקות ישימות, ATP, יחד עם הקמת מערך בדיקה פותרים היטב את הבעיה.
1. יש להגדיר רק דרישות שיש אפשרות לבדוק (ואין להגדיר דרישה ללא אפשרות לבדוק אותה).
2. יש להגדיר היטב ומראש את אופן ודרך הבדיקה לרבות תחום לתוצאות הנדרשות.
3. יש להכין מערך בדיקה, זול, עמיד ופשוט להפעלה ככל שניתן, שישמש את היצרן באתר הייצור.
4. יש להגדיר מראש כמות החלקים הנבדקים לפי הצורך.
5. יש להגדיר היטב את נהלי העבודה עם המכונה ובכללם:
• פרקי הזמן בין בדיקות עוצמת הלייזר
• הגדרת תחומים לעוצמת הלייזר
• הגדרת קצבי הצריבה התואמים לתחומי עוצמת הלייזר השונים
• הגדרת מינימום לעוצמת הלייזר המתקבלת (ירידה מערך זה מחייבת החלפת מודול הלייזר)
תעופה וחלל חוסר דרישות מינורית – אי נוחות, סטייה קלה בביצועים, בעלויות ובלוח הזמנים (עד 5%)  Laser Engraving – 04 08 2011.pdf
חוסר דרישות לבדיקה
דרישות שלא נבדקו, ,
דרישות שלא יודעים איך לבדוק
חוסר בציוד בדיקה מתאים
לא הוגדר קונספט בחינה והערכה
בשנת 2007, התמוטט גשר בין ארצי אל תוך נהר המיסיסיפי במדינת מינסוטה שבארה”ב.
פלטות טריז המקשרות את קורות הפלדה בכל צומת במבנה הגשר כשלו ונשברו תחת עומס משולב של:
תנועת מכוניות ערה, ריכוז של ציוד בניה על הגשר, שיפוצים משמעותיים שנעשו בגשר במהלך השנים שהעלו את משקלו העצמי ביחס למשקלו המקורי.
מתוך 190 אנשים שהיו על הגשר ובסביבתו, נהרגו 13 ונפצעו 145.
לאחר בחינה התברר שמספר גורמים הובילו לכשל של הפלטות החלשות. הפלטה המקורית שתוכננה, תוכננה לא נכון. הפקחים שבדקו את הגשר אחת לשנה לא היו ערים לטעות שבתכנון וכל עומסי-היתר ביום האסון חשפו את חולשתו הגשר.
ü יש לאמוד ולהעריך השפעה שלילית על גשרים בעת החלפת רכיבים או הסרה של חלקים  שנכללו בתכן המקורי.יש לוודא שהשינויים לא פוגעים בבטיחות, ביעילות הגשר, ומחזור החיים שלו.
ü יש להוכיח כי המערכת בטוחה, בכל שלב במחזור החיים של המערכת. ביצועי המערכת בפועל אדישים להנחות האנושיות שנלקחו.
ü הפעל את בקרת האיכות בתהליך התיכון של הגשרים ועל המוצר שתוכנן והתקבל.
ü יש לדאוג שכל תכנון עתידי של גשרים והקמתם ילוו ויבחנו ע”י גורם בלתי תלוי.
ü ספק מספיק משאבים(מימון,חינוך, מומחיות) לבדיקת תכן נאותה.
מבנים הנדסיים חוסר דרישות לבדיקה קריטית – כשל משימה,אירוע בטיחותי  Minneapolis Bridge Collapse 04.08
תוצאות בדיקות שלא דווחו
המערכת שונתה אחרי הבדיקות
לא נחקרו חריגות שנתגלו בבדיקות
לא בוצעו בדיקות רגרסיה
חוסר תכנון בדיקות ו/או תיקצובן
חוסר התייחסות לתוצאות הבדיקה
ביצועי הייצוב של כוונת שהותקנה בפלטפורמה מסוג Z לא תאמו את הדיוקים הנדרשים בתרחישי קיצון.
לאחר חקר מעמיק וממושך בשיתוף הלקוח, התברר שהביצועים המופחתים התקבלו כתוצאה מחוסר התאמת המערכת לPSD בפועל. הPSD שהתקבל מהלקוח לא נמדד במקום ההתקנה המתוכנן של הכוונת. בפועל, בנוסף לתדרי ההפרעה הצפויים, התקבלה אנרגיה בתדר גבוה שלא ניתן היה להנחיתה ע”י חוג הבקרה שתוכנן. מקרה זה היה בעיתי וגרר ניסיונות לשינויי תכן, עיכובים בפיתוח וחריגות בתקציב כתוצאה מניסויי שטח רבים מעבר למתוכנן.
ניסויי שטח בפרויקט מסוג זה יקרים ודורשים ארגון והכנות מקדימות הכוללים תאומים עם גורמים שונים תוך התחשבות בתנאי מזג אויר, זמינות שטחי הניסויים ואישור ועדות בטיחות.
1. בחירת מיקום התקנת הכוונת על פלטפורמה יעשה בשיתוף פעולה מלא עם צוות הפיתוח לפני הגדרת המפרט ביטחוני/צבאי דרישות שלא נבדקו, , מג’ורית- ביצועים בלתי מספקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%)  stabilization_LOS_err_according_platform_vibraions 04.08.11
2. על הלקוח לאפשר מדידות על הפלטפורמה במקום המיועד של הכוונת דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
3. במערך המדידה יותקן על מדמה מסה התואם לכוונת האמיתית מבחינת מסה, אינרציה ותדרים עצמיים.  ציוד בדיקה אינו יכול לבדוק את כל הבדיקות
4. תכנון  מערך בדיקה המדמה את סביבת המערכת האופיינית ומאפשר לבצע את כל שלבי הבדיקות במעבדה. חוסר בציוד בדיקה מתאים
5. בדיקות ה- OT&E בשלבי התאמות הפיתוח מחייבות מעקב מדויק על מנת להבטיח כיסוי של כל התרחישים בהם המערכת צריכה לתמוך. לא בוצעו בדיקות רגרסיה
6. יש לבחון שנית את נושא היתירות הנדרשת למנועים, מדידים, זרמים בהתאם לרמות אי הודאות. אי שלוב OT&E  בשלבים מוקדמים
7. בכדי להבטיח ששינויים בפלטפורמה לאורך הפרויקט לא גוררים נסיגה בתכולות שנבדקו בעבר, יש לבצע בדיקות רגרסיה בסימולציה ובמעבדה כחלק מהוכחה ואישור הקונספט. סביבת בדיקות לא מתאימה
סימולאטור לטיסה המכיל רכיב אמיתי לדימוי ברמה גבוהה. הרכיב האמיתי שודרג ליכולות חדשות-הצריך שדרוג של הסימולאטור לתמיכה ביכולות הללו תוך שמירה על היכולות הקיימות. א. באתר פיתוח התוכנה, יש לדאוג לסביבת פיתוח דומה ככל שניתן לסביבה המבצעית. מערכות תקשורת מרכיבי REUSE שלא נדרש לבדוק מג’ורית- ביצועים בלתי מספקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%) Simulator Software Upgrade_04.08.pdf
השדרוג בסימולאטור בוצע ללא שינוי ממשקים. היכולות החדשות נבדקו ונמצאו תקינות. היכולות הישנות לא נבדקו מתוך הנחה כי אין צורך והסיכוי לתקלה אפסי. ב. יש לבצע בדיקות OT&E בשלב פיתוח תוכנה למודול חדש ולכלל המודולים הקיימים גם אם אין שינוי במודולים קיימים ואין שינוי בממשקים. נבדקה המערכת ה”לא נכונה”-המערכת הנבדקת אינה מייצגת את המערכת הנכונה
בפועל התגלה כי היכולות הישנות לא עובדות באופן תקין והדבר התגלה בבדיקות ATP פורמאליות מול הלקוח שביקש לבדוק את היכולות הללו. ג. יש להשלים את כל הבדיקות הנדרשות לאחר החלפת רכיב תוכנה במערכת. לא בוצעו בדיקות רגרסיה
אי שילוב בדיקות OT&E בשלבים מוקדמים
החללית MARS PATHFINDER שוגרה אל כוכב המאדים במטרה לאסוף ולהעביר למדענים של NASA מידע מגוון אודות הכוכב. במהלך שהותה על המאדים, אספה החללית והעבירה למרכז הפיקוד נתונים אודות האקלים על הכוכב, מידע ויזואלי על אזור נחיתתה ונתוני הרכבים כימיים של הכוכב. מספר ימים לאחר תחילת פעולתה, החללית החלה “לסבול” מבעיית איפוסים של כלל מערכותיה. הבעיה נבעה מניהול לקוי של עדיפויות והתנגשויות בהעברת המידע. הדבר גרם לעצירת פעולת המערכת ולאחר חלוף זמן מוגדר המערכת ביצעה איפוס עצמי תוך איבודי מידע. א. אין להתעלם מתופעות לא צפויות גם אם קשה לשחזרן.
ב. יש לבצע את כל הבדיקות הנדרשות בתנאים התואמים את התנאים האמתיים.
תעופה וחלל דרישות שלא יודעים איך לבדוק מינורית – אי נוחות, סטייה קלה בביצועים, בעלויות ובלוח הזמנים (עד 5%)  PathFinder_04.08.pdf
דרישות שלא כלולות בתוכנית הבדיקה
תוצאות בדיקות שלא דווחו
בתחילת נובמבר 2005 במהלך פיתוח המערכת שליטה במיני מל”ט וכחלק מתהליך השיווק שלה נלקחה המערכת בפעם הראשונה להדגמה בארה”ב. בשלב ההכנות אפליקציית המערכת קרסה כבר בהפעלה ראשונה שלה באזור ההדגמה.  קריסה זו שמה בסימן שאלה את ההדגמה כולה, מאחר ולא ניתן היה לתפעל את המערכת.
בבדיקת סיבות הקריסה (באתר ההדגמה) התגלה באג בתוכנה של חוסר התחשבות בסימן של קואורדינאטה (בארה”ב אחת מקואורדינאטות היא שלילית) וזה השפיע על חישובים שונים וגרם לקריסת האפליקציה. בוצע תיקון נקודתי (PATCH ) של הבאג בשטח כדי לאפשר את קיום ההדגמה.
יש להגדיר סט בדיקת מערכת לעבודה בכל רבעוני העולם ובמעברים בינם תעופה משולב מערכות תוכנה חוסר דרישות לבדיקה מג’ורית- ביצועים בלתי מספקים, אבדן נתח שוק, סטייה בינונית בביצועים, עלות ובלוח הזמנים (עד 20%) CoordinatesCheckFailure04082011.pdf
יש לכלול את סט הבדיקות החדש (סעיף א’) בתהליך בדיקות ה ATP של המערכת. דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
“הזיכרון הקולקטיבי” וניסיון העבר יכולים להיות גורמים מפריעים בתכנון המערכת ותכנוןהבדיקות. בהכנת ה Test Program של מערכת חדשה יש לקחת בחשבון שנדרש לבדוק כלהתהליכים והפונקציונאליות, גם אלו שנראים שגרתיים (עונים על ההגדרה “עשינואת זה כבר מלא במערכות קודמות”). . לא הייתה התייחסות ל OT&E בשלבי פיתוח המוצר
צוות הבדיקות הסתמך על ניסיון קודם
בתאריך 4/07/1996 שוגר לראשונה משגר הלוויינים ARIANE 5 . השיגור הסתיים בהפעלת מנגנון ההשמדה העצמית של המשגר. כ 40 שניות מתחילת השיגור, בגובה של 3700 מטר, סטה המשגר ממסלולו, התפרק והתפוצץ.  שרשרת הכשל החלה בתקלת תוכנה (הודעת exception ) במחשב מערכת הניווט ,SRI – Inertial Reference System, והסתיימה בהפעלת מנגנון ההשמדה העצמי של המשגר כתוצאה מהתפרקות המשגר באוויר עקב כוחות אווירודינאמיים גדולים מהמתוכנן.
בעקבות כישלון השיגור הוקמה וועדת החקירה לחקר סיבת הכישלון . יעדיי וועדת החקירה היו:
1. לקבוע את סיבת הכישלון.
2. לחקור את  תהליכי ה T&E ולבדוק האם התהליכים מתאימים  לגילוי סיבת הכישלון.
3. המלצות לפעולות עתידיות שמטרתן לתקן את  הסיבה לכישלון.
 1. הסימולציות המערכתיות (סימולציות היברידיות המשלבות רכיבי חומרה, תוכנה ומכניקה) המתבצעות כחלק מתהליכיי ה T&E צריכות להכיל כמה שיותר ממרכיבי המערכת עצמה ולא רכיב המדמה את הרכיב האמתי לרבות רכיבי REUSE. כלומר יש להשתמש ב SRI. עצמו ולא במדמה SRI.
2. יש להריץ את הסימולציות המערכתיות על פי מתאר הטיסה של המערכת. כלומר להריץ סימולציה היברידית עם רכיב ה SRI בהתאם למתאר הטיסה של ה ARIANE 5 .
3. עבור כל רכיב במערכת המכיל מודול תוכנה יש לבצע סקר תיכון ייעודי ויש להגדיר תהליך בדיקות מתאים.
4. תהליך בדיקות התוכנה חייב להתחשב בנקודות הבאות :
. יש לזהות את כל הפרמטרים המשמשים כקלט למודול התוכנה ולוודא שתחום הערכים האפשריים של הפרמטרים הנ”ל ידוע.
. יש לבדוק את תחום הערכים האפשריים של כל משתנה פנימי בתוכנה.
. כאשר קיימת יתירות של תתי מערכות יש לשים דגש על המקרים בהם מתבצע בין תתי המערכת בדגש על מעבר בין מעבדים (On Board Computer
תעופה וחלל דחוסר דרישות קריטית – כשל משימה  Ariane 5 failure  7_8_2011
חוסר דרישות לבדיקה
 דרישות שאינן כלולות בתכנית
מרכיבי שלא נדרש לבדוק
בדיקות אינטגרציה לא כללו מרכיבי REUSE
בפלטפורמת רדיו חדשה בוצע שילוב כניסת מחבר USB לטובת העברת מידע ממחשבים של הלקוח, אל הפלטפורמות, בממשק טורי.
יוצרו פלטפורמות וכבלים תואמים (צד אחד USB תקני, צד שני כניסה למחבר הייעודי בפלטפורמה).
עם הגעת הפלטפורמות והכבלים אל הלקוח עלו בעיות של אי זיהוי אפליקציית הלקוח ב-USB, וניתוקים מיד עם הזיהוי.
תופעה זו גרמה לכיבוי והדלקה מחדש בתדירות גבוהה של המערכות, ולפגיעה ביכולת המבצעית.
בניתוח התקלה עלה כי בתקן USB 2 פיני המתח ארוכים יותר מ-2 פיני ה-Data,ע”מ להבטיח קבלת מתח לפני תחילת העברת ה-Data.
עקרון זה לא נלקח בחשבון בפלטפורמה ובכבל התואם, כך שה-DATA  והמתח נתקבלו בצורה אסינכרונית ביחד.
1. יש לשלב את שלב ה OT&E כבר בשלב
התכן המקדים (EOA) על מנת לראות מבעוד מועד את כל הבדיקות אותן יש לבצע על מנת לעלות על כל הכשלים.
רדיו טקטי חוסר דרישות מז’ורית – ביצועים בלתי מספקים, סטייה בינונית בביצועים, עלות ובלוח זמנים. USB_Connector_04_08_2011.pdf
2. יש להגדיר היטב את מפרט דרישות
המערכת על פי תרחישי הייחוס העיקריים והמשניים של המערכת.
חוסר דרישות לבדיקה
3. אין למסור מוצר ללקוח לפני שכל האספקטים שלו נבדקו בתנאים מבצעיים ריאליים. חוסר בדיקתיות
אי שילוב בדיקות OT&E בשלבים מוקדמים
בשנות ה50 וה60 ברית המועצות וארצות הברית היו במהחך מירוץ חימוש, כחלק מאותו מירוץ, מנהיגי ברית המועצות מינו את מרשל מירופן נידלין לעמוד בראש פרויקט פיתוח לטיל באליטסטי בין יבשתי חדיש, R16, האסון שגנרם במהלך אותו פיתוח מהווה את האסון הגדול ביותר בהיסטוריית בנית טילים, לו”ז קצר, לחצים פוליטים ועוד גרמו לאובדן חיים רבים. 1. בניית תהליכי בדיקות מסודרים ללא קיצורי דרך – באסון נידלין ניכר לחץ הלו”ז שכנראה גרר איתו עיגול פינות והאצת תהליך הבדיקות פגיעה בעקרנות DT&A (Test – Fix – Test) בטחוני, הנדסת טילים   חוסר דרישות לבדיקה. קריטית – אסון אמיתי, מעל 74 הרוגים באירוע עצמו ועוד כ50 מפצעים לאחר מכן.
נזק חמור ביותר לפרויקט
 NedelinCatastrophe_04_08_2011.pdf
2. שילוב בדיקות ברמות מערכתיות שונות על מנת להימנע מגרירת תקלות, שילוב Test Plan & Testability  לא נחקרו חריגות שנתגלו בבדיקה
3. ביצוע תכן רובסטי ככל האפשר לטובת הקטנת סיכונים.  כפי הנראה לא בוצעו בדיקות רגרסיה על מנת לבדוק מה נפגע במהלך התיקונים
4. הקפדה על תיעוד ושיתוף בין חברי הפרויקט.  סביבת בדיקות לא מתאימה
5. הגדרת תקני בטיחות ואכיפתם.  חוסר תכנון בדיקות ו/או תיקצובן.
בעקבות תקלה הנדסית, מומש ממשק חשמלי על ידי חוט שמורכב על ידי איש ייצור לאחר הרכבת הכרטיס במכונה. באחת המערכות החוט הורכב על ידי המרכיב בצורה לא תקינה, דבר שגרר לתקלה מול הממשק אצל הלקוח. התקלה התבטאה בדיווח נתוני טמפרטורה גבוהים משמעותית מהערכים בפועל. בבדיקת ATP במעבדה התקלה לא זוהתה.רק בהתערבות הנדסית זוהתה התקלה. זוהה כי הגדרת הבדיקה של הצב”ד לא היתה תקינה. במהלך חיי הפרויקט הוגדרו בדיקות הקבלה בשלב החוזה וכתיבת הדרישות.
כמו כן, בוצע ניתוח כשלים אפשריים בשלב ה- Design.
בשלב ה- DT&E בעת הגדרת דרישות הבדיקה הפרטניות לא זוהה אופן הכשל הרלוונטי והבדיקה לא תאמה את אופציית הכשל הזו.
פתרון גלובלי-
1. הוחלט שבשלב ה- DT&E תבוצע אנליזה נוספת למעגלים בהם מעורבת יד אדם בייצור. בכל מקום בו קיימת “תפירה”, תוחמר ותתוגבר הבדיקתיות של הצב”ד.
2. בתהליך ה- AT&E הוגדר שתקלה לא מאומתת תיבדק על ידי כלי בדיקה נוסף (במקרה זה בחינת ICT היתה מזהה את התקלה)
תעופה וחלל צב”ד קלה  – אין נזק משמעותי, הבעיה נפתרה  temperature_interface_failure_04.08.11.pdf
דרישות שאינן כלולות בתכנית הבדיקות (במיוחד דרישות ל-OT&E)
לא בוצע שימוש בכלי הבדיקה הקיימים לשלב הפרויקט
ב- 20 באפריל 2010, אירע פיצוץ עז ועקבותיו שריפה באסדת הנפט Deepwater Horizon  השייכת לחברת  Transocean , כאשר קדחה באר נפט עבור חברת British Petroleum במפרץ מקסיקו מול חופי מיסיסיפי ואלבמה.
כתוצאה מהתאונה,11 אנשים נהרגו, והחלה נזילת נפט אדירה אל הים עליה לא הצליחו להשתלט במשך חודשים וגרמה לנזק סביבתי עצום. אירוע זה נחשב לאחד האסונות האקולוגיים הגדולים ביותר בהיסטוריה של ארה”ב.
• שיפור הממשק בין שלב הדרישות לשלב תוכנית העבודה למימוש. יש לוודא בעזרת טבלת דרישות ש DT&E יכללו לפי הצורך, יפורטו לסוגים OT&E, AT&E, ויבואו לידי ביטוי בתוכנית העבודה.
• יש לוודא עקיבות מלאה בין DT&E שבתוכנית העבודה, לדרישה אשר ממנה נבעה הפעילות. ומכאן כל שינוי בתוכנית העבודה מחייב בדיקה לגבי השפעתו על הדרישה הרלוונטית.
• ביצוע תוכנית לניהול סיכונים בתחומי התכן והתהליך שתכלול DT&E (כגון אי וודאות לגבי תנאי הסביבה, מורכבות תוכנית המלט והסיכונים שבה מבחינת היבט ייצוריות ובעיות WORKMANSHIP). יש לבצע מעקב על הטיפול בסיכונים ורישום תוצאות מסקנות ה DT&E שבוצעו.
מערכת נפיצית דרישות לא נבדקו לאחר ביצוע שינוי תהליך הקידוח והמלט. קריטית – כשל משימ, אירוע בטיחותי, סטיה משמעותית בביצועים, BP_Macondo_Well_Incident_04.08.11.pdf
הגדרות לתנאי הבדיקות לא הועברו במלואם למעבדה הדבר גרם לביצוע הבדיקה לא נכונות
לא עודכן קונספט בחינה והערכה לאחר שינוי תהליך העבודה והרכב המלט.
עבור הבדיקות אשר כן בוצעו לאחר השינויים הייתה חוסר התיחסות לחלק מתוצאות הבדיקות
לא הוגדר קונספט בחינה והערכה
במסגרת פיתוח ואספקת פרויקט לניהול ידע עבור לקוח זר, לאחר ביצוע ATP, הלקוח שלח כ-20 משתמשי קצה לקורס על המערכת. בעת התרגול המערכת קרסה באופן שלא ניתן להשתמש בה. הלקוח הביע את חוסר שביעות רצונו ואספקת הפרויקט נדחתה בחודש.
הסיבות שהובילו לאירוע:
1. ה-ATP התבצע בשפה האנגלית מול לקוח מתווך ולא מול הלקוח הזר. בכיתת ההדרכה המערכת הופעלה לראשונה בשפת הלקוח באופן מלא. בפועל, מספר מודולים הורצו בשפת הלקוח בפעם הראשונה וכשלים הנובעים מהשוואות טקסט גרמו להפסקת תהליכי הריצה של חלקם.
2. לא בוצע תכנון ובדיקות של תרחישי הדרכה. בפועל בוצעו תרחישים “זדוניים” על ידי המשתמשים מצד הלקוח. התרחישים לא היו צפויים ולא נבדקו על ידי גוף הבדיקות.
3. מהנדס המערכת התפטר כחודש לפני סוף הפיתוח. סמכויותיו פוזרו בין מספר אנשים. עקב כך לא היה פיקוח ראוי על תהליכי הבדיקות.
1. פעילויות ה – T&E של מערכת חייבות להיות מלוות על ידי מהנדס מערכת בכל שלבי האפיון והפיתוח.
2. יש לאפיין ולבדוק תרחישים קיצוניים ולא צפויים בשלב הפיתוח (DT&E).
3. בשלב התכן יש לתכנן ולהיערך לתרחישי הדרכה ובשלבי הפיתוח המתקדמים יש לבצע תהליכי בדיקה ריאליסטים בתצורה אופיינית (OT&E).
4. AT&E צריך להתבצע על מערכת המוגדרת באופן זהה למערכת המסופקת ללקוח (הגדרות שפה, מספרים וכו’).
5. AT&E  צריך להתבצע על ידי לקוח הקצה או בפיקוחו המלא.
מערכות תוכנה חוסר דרישות לבדיקה. .מינורית – אי נוחות, סטייה קלה בביצועים, בעלויות ובלוח הזמנים (עד 5%)  KnowledgeManagementSystem_4_8_2011.pdf
דרישות שלא נבדקו.
המערכת שונתה אחרי הבדיקות.
אי שילוב בדיקות OT&E בשלבי פיתוח המוצר.
 לא הייתה התייחסות ל- OT&E בשלבי פיתוח המוצר.
 חוסר תכנון בדיקות ו/או תיקצובן
כחלק מפיתוח של מערכת מולטידיסיפלינארית הוכנסה המערכת לתא קור לצורך בדיקות ביצועים בטמפרטורה של -32 מעלות סלזציוס.
הוקם תא מיוחד לקליטת המערכת.
הבודק, ביצע הפסקות תכופות של הניסוי כל 5 דקות לערך, ויצא אל מחוץ לתא כדיי “להפשיר”.
לאחר מספר הפסקות, הובחן ששכבה של קרח מתגבשת על גביי הרצפה, המערכת ועדשות המצלמות כתוצאה מכניסת לחות לתא.
הקרח שהתגבש גרם לבודק להחליק בתוך התא, הפריע לתנועת מכלולים עדינים וכיסה חלק מעדשות המצלמות.
בנוסף, לא ניתן היה לתצפת למרחק ולבחון את ביצועיי המצלמות מכיוון שלא הוגדר בקיר התא חלון לצורך הפעילות.
הניסוי הופסק והחלה בחינה של המצב, הגורמים לו והפקת לקחים.
1. עבודה בתוך תא הקור תהיה תמיד בזוגות. – בטיחות.
2. בכתיבת מסמך בדיקות המערכת יש לכלול את ההגדרות המדויקות של התנאים והאמצעים הנדרשים לצורך ביצוע הניסוי.
האמצעים ירוכזו בפרק נפרד אשר יתאר כל שלב בפעילות והאמצעים הדרושים לביצועו.
3. יוגדר תהליך הכנה לניסוי בסדר גודל כזה, אשר כולל דיון TRR, אישור מסמך הבדיקות ע”י מספר גורמים מקצועיים. מסמך בדיקות המערכת ייכתב מבעוד מועד ואישורו של המסמך יכלול פונקציות מתאימות מחוץ לפרוייקט (הנדסת סביבה, הנדסת מערכת, מכאניקה וכו’).
מערכת מולטידיסיפלינארית הכוללת הנע, מכאניקה, בקרה ותוכנה.  ציוד בדיקה אינו יכול לבדוק את כל הבדיקות קריטית – כשל משימה, הפסד השוק, אירוע בטיחותי, איום על קיום הארגון, סטייה משמעותית בביצועים, עלות ובלוח זמנים (מעל 20%). Extreme cold condition 4_8_2011.pdf
סביבת בדיקות לא מתאימה
התפרקות מעבורת החלל קולומביה מעל טקסס ב-1 בפברואר 2003 בעת חזרתה לכדור הארץ ממשימתה
באסון זה נספו שבעת אנשי צוות המעבורת
הגורם שהביא להתפרקות המעבורת הינו מתחום ה OT&E והוא הנזק שנגרם כתוצאה מהפרדות של קצף בידוד שפגע בשפת הכנף של המעבורת.
הוועדה מצאה שאף שהפגיעה בכנף הייתה ידועה לצוות ניהול המשימה, לא ננקטו הצעדים הדרושים כדי לקבל תמונה מלאה של המצב, וממילא לא ננקטו צעדים כדי להתמודד עמו.
מייד לאחר האירוע בוצע תחקיר והופקו לקחים בהיבטי הקף הבדיקות בזמן השיגור.
• תיעוד המעבורת בזמן השיגור אינו מספיק כדי להפיק לקחים בזמן אמת
• הדבקת הקצף לא בוצעה טוב וטיב ההדבקה לא נבדק כראוי
• אירועים דומים בעבר לא גרמו לנזק ולכן לא נלקחו בחשבון
• לא היה לצוות הבדיקות מספיק מיידע כדי לקבוע את חומרת הפגיעה
• הערכות לא מדויקות בגלל נתונים דלים (מסה, צורת בקצף, מיקום וזוית הפגיע של הקצף בכנף
• כשלים באופן התקשורת בין צוותי הבדיקות גרמו לכך שבקשות לצפייה בתצלומי לווין שתיעדו את המעבורת בזמן הפגיעה, לא יצאה לפועל
• מידע על תמונות מכ”מ של ח”א האמריקני על חלקים מהמעבורת הועברו ל NASA רק לאחר האסון
• על נאס”א להתחיל בתוכנית אגרסיבית למניעת נפילת קצף בידוד.
• על נאס”א להכין תוכנית בדיקות מקיפה לחוזק המבני של לוחות הפחמן.
• יש לשפר את היכולת של מגיני החום לספוג פגיעות.
• יש לשפר את יכולת הצילום של המעבורת בזמן השיגור, כדי לספק מידע טוב יותר על פגיעות בגוף המעבורת.
• יש לאפשר שידור אל הקרקע של צילומים של תחתית המעבורת ושל שפת הכנף.
• יש לשפר את מערכת הקלטת המידע מן החיישנים כך שתקליט מידע הנדסי, ומידע על מצב המעבורת.
תעופה וחלל חוסר דרישות לבדיקה קריטית – כשל משימ, אירוע בטיחותי, סטיה משמעותית בביצועים, columbia_disaster_04_08_2011.pdf
תוצאות בדיקה שלא דווחו
ציוד בדיקה אינו יכול לבדוק את כול הבדיקות
לא נחקרו חריגות שנתגלו בבדיקות
חוסר התייחסות לתוצאות הבדיקות