--- title: "Systems analysis in IT — ניתוח מערכות בIT" source: "https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT" wiki: "systems-analysis.info/int" article: "Systems_analysis_in_IT_—_ניתוח_מערכות_בIT" language: "he" categories: - "Category:Hebrew" - "Category:Systems analysis" revision_id: 7618 wiki_created_at: 2026-09-07T01:04:29Z wiki_modified_at: 2026-09-07T01:04:29Z downloaded_at: 2026-09-07T23:19:51Z --- # Systems analysis in IT — ניתוח מערכות בIT **ניתוח מערכות בIT** (*Systems Analysis and Design*) — גישה לתכנון ופיתוח מערכות מידע מהרעיון ועד להפעלה, הכוללת זיהוי צרכים, פורמליזציה של דרישות, מידול תחום הבעיה והתהליכים, כמו גם הערכת חלופות וסיכונים. במילים אחרות, ניתוח מערכות בIT הוא שלב הפיתוח שבו מומחים חוקרים את המשימה, קובעים מה המערכת צריכה לעשות ומפתחים פתרונות ליצירתה. **ניתוח מערכות קלאסי** охватывает מגוון רחב של תחומי יישום*,* לא רק פיתוח תוכנה, אלא גם שינויים ארגוניים, אסטרטגיות והיבטים אחרים.[1] [2] ## נושא ומשימות של ניתוח מערכות בIT **נושא** **ניתוח המערכות בIT** הוא מערכת המידע (מוצר תוכנה ו/או שירות) לאורך כל מחזור חייה — מהרעיון וההצדקה ועד למימוש וההפעלה. **משימת ניתוח המערכות** — להמיר צרכים עסקיים לסט מוסכם וניתן לאימות של דרישות והחלטות ארכיטקטוניות: לזהות ולתעד את מטרות ומגבלות בעלי העניין, לפורמל דרישות, למדל את תחום הבעיה והתהליכים, להעריך ישימות וסיכונים של חלופות ולהצדיק את הארכיטקטורה הנבחרת. כתוצאה מכך נוצרים מסמכים מוסכמים ומוקמות קשרי מעקב בין דרישות, החלטות עיצוב ובדיקות. הדבר מבטיח ניהוליות ושליטה בתהליך הפיתוח. משימות ניתוח המערכות כוללות: - **זיהוי צרכים ומטרות של בעלי עניין**. האנליסט אוסף ומדייק ציפיות של לקוחות, משתמשים וצדדים מעוניינים אחרים; נעשה שימוש בראיונות, סקרים, תצפיות וניתוח תהליכים קיימים. התוצר הוא **מפרט דרישות ראשוני** עם חלוקה לפונקציונליות («מה המערכת צריכה לעשות») ולא-פונקציונליות (אמינות, ביצועים, אבטחה וכד').^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-Zowghi-2)} - **פורמליזציה ותיעוד דרישות**. בקשות מומרות לדרישות ניתנות לאימות. דרישה מנוסחת היטב צריכה להיות ברורה וחד-משמעית, מלאה, עקבית, ניתנת לאימות וניתנת למעקב עד למטרות ברמה גבוהה יותר; סט הדרישות — מוסכם ושלם.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA7123-4)} בפרקטיקה נעשה שימוש במסמכים מתוקננים: SRS (*Software Requirements Specification*) לפי ISO/IEC/IEEE 29148, וכן, בענפים מסוימים, URS (*User Requirements Specification*) ומפרטים פונקציונליים.^{[\[5\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-5)[\[6\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-6)[\[7\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-7)} - **ניתוח ומידול המערכת**. להבנת *כיצד* המערכת תפעל ותתקשר עם העולם החיצוני, נבנים מודלים: דיאגרמות Use Case לתרחישי שימוש, DFD לזרימות נתונים ותהליכים עסקיים, דיאגרמות מחלקות/רכיבים ועוד. המודלים משמשים בסיס להשוואת פתרונות וארכיטקטורות חלופיות.^{[\[8\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-8)[\[9\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-9)[\[10\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO42010-10)} - **הערכת ישימות ובחירת פתרון**. מתבצע *feasibility study* (ישימות טכנית, ארגונית, כלכלית, לוחות זמנים) והשוואת חלופות ארכיטקטוניות (*trade-off*). להערכת איכות הארכיטקטורה לפי מאפיינים (למשל ביצועים, סקלביליות, ניתנות לשינוי) משתמשים בשיטות כגון ATAM (*Architecture Tradeoff Analysis Method*).^{[\[11\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-11)[\[12\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ATAM-12)} הבחירה בין, למשל, ארכיטקטורה מונוליתית למיקרו-שירותים [3] נסמכת על פשרות מפורשות (מורכבות תפעולית לעומת סקלביליות עצמאית ומהירות אספקה) בהתאם להמלצות מדריכי התעשייה.^{[\[13\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-13)[\[14\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-14)} - **הכנת ארטיפקטים של פרויקט**. בעקבות הניתוח נוצרים: - מפרט דרישות מאושר (עם ציון חשיבותן), - מודל קונצפטואלי של המערכת (דיאגרמות/תיאורים), - החלטות ארכיטקטוניות ועיצוביות (סכמות נתונים, ממשקים של מערכות חיצוניות), - תוכנית מימוש (שלבים/מודולים). - חיוני להבטיח *מעקביות* (bidirectional traceability) של דרישות לאלמנטים של עיצוב ולבדיקות.^{[\[15\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-15)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA7123-4)} הצלחת פרויקט IT תלויה במידה רבה בבשלות הפרקטיקות של עבודה עם דרישות וארכיטקטורה. מחקר שביצעו McKinsey ו-Oxford הראה שפרויקטי IT גדולים עוברים לעיתים קרובות את גבולות התקציב והלוחות הזמנים. מחקר זה הדגיש גם עד כמה חשוב לנהל נכון את האסטרטגיה, לתקשר עם בעלי עניין ולאסוף דרישות בצורה מושכלת. כל זה יכול להשפיע רבות על הצלחת הפרויקט או כישלונו.^{[\[16\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-16)} ## גישות ומתודולוגיות בניתוח מערכות IT **ניתוח מערכות בIT** נסמך על עקרונות החשיבה המערכתית ועל מתודיקות המותאמות לפיתוח תוכנה. בפרקטיקה משלבים גישות «קשות» ו«רכות», מתודולוגיות מובנות, סימונים מונחה-עצמים, כמו גם שפות מידול של תהליכים ודרישות. - **גישה קשה וגישה רכה**. בפרויקטי IT גישה קשה (hard systems) מניחה מטרות ודרישות הניתנות לפורמליזציה מראש, פירוק והתכנון «מלמעלה למטה». גישה רכה (soft systems) מיושמת כשהמטרות אינן ברורות ויש נקודות מבט מרובות: משתמשים באלמנטים של Soft Systems Methodology (SSM) (למשל, *rich picture*, הגדרות שורש, CATWOE) להסכמת הבנת הבעיה והשינויים הרצויים; לאחר מכן התוצאות מומרות לדרישות פורמליות.^{[\[17\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-17)[\[18\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-18)} - **מתודולוגיית SSM (Soft Systems Methodology)**. שפותחה במקור על ידי *פיטר צ'קלנד* לשינויים ארגוניים, SSM שימושית בשלבים הקדם-פרויקטליים של IT: מחקירת מצב הבעיה וניסוח הגדרות שורש (כולל דרך CATWOE) ועד השוואת מודלים קונצפטואליים עם המציאות והשגת הסכמה בין בעלי העניין.^{[\[19\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-19)[\[20\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-20)} - **מתודולוגיות מובנות: SADT/IDEF0**. SADT מדלה את המערכת כהיררכיה של פונקציות; הסימון הסטנדרטי IDEF0 (IEEE 1320.1) מקבע פונקציות וממשקי I-C-O-M שלהן (Inputs, Controls, Outputs, Mechanisms). השיטה נוחה לפירוק פונקציונלי ולהסכמת גבולות המערכת ללא תלות באלגוריתמים.^{[\[21\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-21)[\[22\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-22)} - **ניתוח מונחה-עצמים:** UML ו-SysML (MBSE). UML הפך לשפת הבסיס לדרישות ועיצוב (דיאגרמות Use Case, מחלקות, רצפים ועוד) ומקל על אימות תרחישים עם משתמשים; SysML מרחיב את UML להנדסת מערכות (דיאגרמות דרישות, דיאגרמות פרמטריות) ונסמך על גישת MBSE, שבה המודל הוא הארטיפקט המרכזי לאורך שלבים מהדרישות ועד הבדיקות.^{[\[23\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-23)[\[24\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-24)[\[25\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-25)} - **מידול תהליכים עסקיים:** BPMN. תקן BPMN משמש לתיאור גרפי של תהליכים (pools, זרימות עבודה, אירועים, שערים), כולל השוואת *as-is/to-be* במפרטי דרישות ואינטגרציה.^{[\[26\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-26)[\[27\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-27)} - **הקשר להנדסת דרישות**. התהליך כולל שלבים של elicitation–analysis–specification–validation–change management; קריטריונים ל«דרישה טובה» ומבנה SRS מוסדרים ב-ISO/IEC/IEEE 29148. לתעדוף משתמשים בטכניקות **MoSCoW** (Must/Should/Could/Won't) ובשיטות בחירה רב-קריטריאלית, למשל AHP. בתהליכים גמישים, פעילות ניתוח המערכות באה לידי ביטוי ב-backlog refinement ובמעקביות דרישות.^{[\[28\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-28)[\[29\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-29)[\[30\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-30)[\[31\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-31)} - **הקשר להנדסת מערכות**. עבור מערכות מורכבות (סייבר-פיזיקליות) משתמשים במודל V: בענף ה«שמאלי» — ניתוח מערכות וארכיטקטורה, בענף ה«ימני» — אינטגרציה, אימות ווולידציה עם קישור לארטיפקטים של הענף השמאלי. שיטות הערכת ארכיטקטורה לפי מאפייני איכות כוללות ATAM (ניתוח trade-off).^{[\[32\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-32)[\[33\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-33)} ניתוח מערכות בIT משלב גישות מוכחות — ממתודיקות רכות של הסכמת חזון ועד לסימונים ותקנים פורמליים. בחירת הכלים נקבעת לפי מידת הוודאות של המשימה: בחוסר ודאות גבוה — גוברת תפקיד SSM והפסיליטציה, בגבולות ברורים — מודלים פורמליים (UML/SysML, IDEF0, BPMN) ותקנות. ## הקשר לארכיטקטורת IT וארכיטקטורת ארגון ניתוח מערכות בפרויקטי IT קשור קשר הדוק לתכנון ארכיטקטוני. תפקידי האנליסט והארכיטקט חופפים: האנליסט מנסח דרישות ומודל לוגי, הארכיטקט קובע את המבנה הרצוי של הפתרון ופשרות טכניות; העבודה מתבצעת במשותף. - **ארכיטקטורת מערכות IT**. במובן הצר, ארכיטקטורת תוכנה היא ארגון הרכיבים, יחסיהם והעקרונות המנחים בעת תכנון הפתרון. לאנליסט חשוב לקחת בחשבון סגנונות ארכיטקטוניים (שכבתית, לקוח-שרת, מיקרו-שירותים, מונחת-אירועים ועוד), מכיוון שדרישות לא-פונקציונליות (אמינות, סקלביליות, ניתנות לשינוי) לעיתים קרובות קובעות את ההחלטות הארכיטקטוניות ופשרותיהן.^{[\[34\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SEI_ATAM-35)} בשלב מוקדם של הניתוח מגבשים **חזון ארכיטקטוני** (high-level vision) ומפתחים קונטור טיוטה של הפתרון לבדיקת ישימות הדרישות (אורך האיטרציות ורמת הפירוט תלויים במתודולוגיה).^{[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-TOGAFIntro-36)} - **תבניות ופתרונות מקדימים**. לעמידה בדרישות לא-פונקציונליות משתמשים בתבניות ארכיטקטוניות (architectural patterns). לדוגמה, לתקשורת אסינכרונית וצימוד רופף — publish–subscribe דרך message broker בארכיטקטורה מונחת-אירועים.^{[\[37\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-AzureEvent-37)} - **TOGAF (The Open Group Architecture Framework)**. אחד מהframeworks הנפוצים ביותר לארכיטקטורת ארגון; כולל שיטת ADM (Architecture Development Method) וארטיפקטים לניהול ארכיטקטורה (מאגר, קטלוגים/מטריצות, עקרונות). ב-TOGAF ניהול דרישות הוא תהליך רוחבי, משולב בכל שלבי ADM.^{[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-TOGAFIntro-36)} לתמיכה בדרישות ומעקביות משתמשים בקטלוגים ובמטריצות (למשל, דרישות ↔ שירותים, פונקציות ↔ רכיבים), וכן מבחינים בין ***Architecture Building Blocks*** ל-***Solution Building Blocks***.^{[\[38\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-38)[\[39\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-39)} עקרונות ותקנים של הארגון מקובעים בקטלוגים המתאימים ומשמשים **דרישות** לא-פונקציונליות חיצוניות לצוותי הפרויקט.^{[\[40\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-40)} התאמת הפתרונות לארכיטקטורה היעד מאושרת בנוהל Architecture Compliance Review.^{[\[41\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-41)} גישת TOGAF מניחה **Architecture Vision** מקדימה ופירוט עוקב (נתונים/יישומים/טכנולוגיות) עם תוכנית מיגרציה וניהול שינויי דרישות.^{[\[42\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-42)[\[43\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-43)} - **Zachman Framework**. אונטולוגיה מוקדמת ומשפיעה של ארטיפקטים של ארכיטקטורת ארגון, המוצגת כמטריצה 6×6 (פרספקטיבות × היבטים «מה/איך/איפה/מי/מתי/למה»). שורת «המעצב» מתאימה לניתוח ועיצוב מערכות; העמודות קובעות שלמות הסתכלות על נתונים, פונקציות/תהליכים, תפקידים, מיקום ומוטיבציה. הframework משמש כסיווג (ולא מתודולוגיה) ועוזר להבטיח שלמות תיאור הפתרון בנוף הארגון.^{[\[44\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-Zachman1987-44)} - **הקשר לארכיטקטורת ארגון (Enterprise Architecture, EA)**. האנליסט עובד בהקשר של EA: דרישות חדשות מקושרות ליכולות עסקיות ולמודל התפעולי; מיושמים תקנים ומגבלות עקרוניות של הארגון (אבטחה, תאימות וכד').^{[\[45\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-45)[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-TOGAFIntro-36)} בשלב היזום מגבשים ***Architecture Vision*** (מטרות/מגבלות, דרישות מצומצמות), לאחר מכן האנליסט מפרט תוך שמירה על מעקביות לחזון ולתקנים הארגוניים; אי-עמידה בתקנים מתגלה בסקירות ארכיטקטורה ועלולה להוביל לעיבוד מחדש של הפתרון.^{[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-46)} לסיכום: ניתוח מערכות ותכנון ארכיטקטוני יוצרים חיבור «דרישות → החלטות ארכיטקטוניות → פשרות לפי מאפייני איכות». בחירת השיטות (סגנונות/תבניות, ארטיפקטים של TOGAF, סיווג Zachman) נקבעת לפי אופי הפרויקט ומסגרת ארכיטקטורת הארגון. ## תהליכים ופרקטיקות ניתוח מערכות משתלב לאורך כל מחזור החיים של פיתוח והפעלת תוכנה, המקשר בין מטרות עסקיות, ארכיטקטורה ואספקה. כולל חקירה קדם-פרויקטלית, בחירת גישה, יצירת ארטיפקטים ניתנים לאימות ודרישות לאמינות, ביצועים, אבטחה ותחזוקה. במודל מפל מים, הניתוח מתבצע לפני התכנון והמימוש; בשיטות גמישות — ברציפות דרך איטרציות, וב-DevOps — עם דגש על מטרות תפעוליות. ללא תלות בגישה, הניתוח מבטיח מעקביות, ניהול שינויים וסיכונים, תיעוד פשרות ארכיטקטוניות ועמידה במגבלות רגולטוריות, מה שהופך את הפיתוח לצפוי וניהיר. - **SDLC קלאסי (Waterfall)**. שלב System Analysis & Requirements Definition קודם לתכנון ולמימוש; הדרישות מקובעות ב-**SRS** מפורטת כבסיס לתכנון וחוזים. יעיל בתחומים יציבים ומוסדרים; סיכוני «הקפאת דרישות» מצטמצמים על ידי SRR/סקירות וניהול שינויים דרך **CCB**.^{[\[47\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA_CCB-49)} - **מתודולוגיות גמישות (Agile)**. הניתוח רציף: במקום SRS סופית מנהלים product backlog של user stories עם קריטריוני קבלה, המדוייקים ב-backlog refinement; משתמשים ב-**BDD** (Given–When–Then); סיכון אובדן ארכיטקטורה שלמה מקוזז על ידי עיבוד ארכיטקטוני מוקדם ומעקביות שקופה של דרישות ↔ מימוש/בדיקות.^{[\[50\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-MS_Trace-52)} - **DevOps ו-SRE**. פרסומים תכופים דורשים דרישות תפעוליות «כברירת מחדל»: אוטומציה, observability, rollback. דרישות לא-פונקציונליות מנוסחות כ-SLO/SLI, מנהלים error budget; לbacklog מוסיפים משימות על logs/metrics/traces/alerts; לפרסום ללא השבתה — תבניות **blue/green** ועוד.^{[\[53\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-AWS_BlueGreen-55)} - **ניהול דרישות וסיכונים**. דרישות ב-ALM כוללות סטטוסים וקשרים עם משימות/גרסאות/פגמים; חובה לבצע version control, change impact analysis ועדיפויות מחדש באופן סדיר.^{[\[56\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-Azure_Backlog-57)} - **הבטחת איכות (QA)**. איכות מוטמעת בשלב הדרישות: סקירות, «Three Amigos», תוכנית *Acceptance Test Plan*, בדיקות אוטומטיות לקריטריוני קבלה (BDD/ATDD).^{[\[58\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-MS_SpecFlow-59)} - **Observability ואמינות**. בדרישות כוללים SLA/SLO, MTTR ו-MTBF עם יעדים מדידים ושיטות בקרה; הפרמטרים מגיעים מהעסק/תפעול ומוטמעים בארכיטקטורה ובבדיקות אמינות.^{[\[60\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-GCloud_Obs-61)} ## מדדים ואיכות ארטיפקטים להערכת עבודת אנליסט המערכות ואיכות תוצריו משתמשים בקריטריונים מקובלים. **דרישות ומודלים איכותיים** — הבסיס לפרויקט מוצלח, ולכן הם מנוהלים לאורך כל מחזור החיים (elicitation → specification → verification/validation → change management). מאפייני האיכות הבסיסיים של דרישות מעוגנים בתקנים ISO/IEC/IEEE 29148 ו-(היסטורית) IEEE 830.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} - **נכונות (Correctness)** — הדרישה משקפת את הצורך האמיתי ומוסכמת עם מומחי תחום הבעיה; מאושרת על ידי validation (סקירה/inspection, אבות-טיפוס, תרחישים).^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA7123-4)} - **שלמות (Completeness)** — נלקחו בחשבון ההיבטים והתנאים המהותיים. - *שלמות דרישה בודדת*: צוינו הפרטים הנדרשים (למשל, «האינדיקטור עובר לסטטוס **אדום בכשל**», ולא פשוט «הופך לאדום»). - *שלמות המפרט*: מכוסים תרחישים/תפקידים, מוגדרים NFR; מושגת באמצעות רשימות תיוג ומעקביות למטרות עסקיות; מועיל ביקורת עצמאית על שלמות (QA/review).^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA_SEH-63)} - **חד-משמעיות (Unambiguity)** — ניסוחים מתפרשים בדרך אחת בלבד; עוזרים גלוסר, תבניות מסוג «המערכת **חייבת לעשות A, כאשר B, אם C**», דוגמאות; דיאגרמות מלוות בלגנדה. אימות — עיקרון **«ארבע עיניים»**.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} - **עקביות (Consistency)** — דרישות אינן סותרות זו את זו ואת המגבלות החיצוניות; משתמשים במבנה, בטבלאות מאפיינים משוכללות, בסקירות צוותיות; בודקים רגולציה/תקנים.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA_SEH-63)} - **ניתנות לאימות/בדיקה (Verifiability)** — השגת הדרישה מאושרת על ידי בדיקה/הדגמה/ניתוח; ניסוחים שאינם ניתנים לאימות מוחלפים בקריטריונים מדידים; עבור NFR מוגדרים מדדים וקריטריוני קבלה נקבעים מראש.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA_SEH-63)} - **ניתנות לשינוי ומעקביות (Modifiability & Traceability)** — מזהים ייחודיים, מבנה הגיוני («רעיון אחד — פסקה אחת»), היעדר כפילויות; נשמרים קשרים «דרישה ↔ מקור/יעד/עיצוב/בדיקה», מנוהלת מטריצת **מעקביות (RTM)**.^{[\[64\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)} - **דירוג ותעדוף** — איכות סט הדרישות; משתמשים בטכניקות **MoSCoW** ו-MCDM (למשל, **AHP**); תעדוף משותף עם העסק משפיע על תכנון וסיכונים.^{[\[65\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-Saaty-66)} **מדדי איכות דרישות** (דוגמאות):^{[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} - צפיפות פגמי דרישות (הערות לכל 100 דרישות); - מספר שינויים לאחר קיבוע הבסיס; - מדדי כיסוי: אחוז דרישות עם בדיקות; אחוז דרישות הניתנות למעקב למטרות עסקיות; - יציבות דרישות (יחס דרישות שנוספו/הוסרו למספר הכולל בתקופה); - גודל/מורכבות מפרט (מספר דרישות ממוצע ב-use case, עומק פירוק); - שביעות רצון בעלי עניין (סקר). בתהליכים בשלים (למשל, **CMMI** רמה 3+) פועלים תקנות איכות דרישות: בדיקות פורמליות, ביקורות עמידה בתבניות, איסוף/ניתוח מדדים.^{[\[67\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SEI_CMMI-67)} בתחומים קריטיים (תעופה, חלל ועוד) משתמשים ב-**שיטות פורמליות** להגברת האמינות.^{[\[68\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA_FM-68)} ## שגיאות אופייניות בפרויקטי IT מתרחשות לעיתים קרובות שגיאות ניתוח מערכות: אי-שלמות וחוסר בהירות של דרישות, סתירות, גבולות מטושטשים, התעלמות מהיבטים לא-פונקציונליים, אינטגרציה שהוחמצה ואבטחה מאוחרת. הדבר מוביל לעיבוד מחדש, עיכובים, עלייה בעלויות ופגמים. בעיות אופייניות, השלכותיהן ודרכי מניעה. - **אי-שלמות ודרישות חסרות**. מוחמצים תפקידים עם הרשאות מיוחדות, מקרי קצה ו-NFR. *השלכות:* עיבוד מחדש של ארכיטקטורה ודחיית ההשקה. כיצד למנוע: רשימות תיוג, סיעורי מוחות «מה אם…», חיבור מוקדם של בודקים, מעקביות למטרות עסקיות.^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SEI_Pitfalls-69)} - **ניסוחים לא ברורים וחד-משמעיים**. *השלכות:* מפתחים ממשים «לא את זה», הלקוח אינו מרוצה. כיצד למנוע: קריטריונים מדידים, גלוסר, תבניות «A, כאשר B, אם C», peer‑review.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SEI_Pitfalls-69)} - **דרישות סותרות**. *השלכות:* עיכובים בבירורים, עיבוד מחדש באינטגרציה. כיצד למנוע: מבנה, בדיקת חוקי עסקים/רגולציה, סשנים לפתרון קונפליקטים, בדיקת עקביות בסקירה.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} - **תסמונת «הציפוי הזהב» (gold‑plating)**. *השלכות:* גידול היקף, סיבוך, נקודות כשל חדשות. כיצד למנוע: קישור כל דרישה למטרה/מדד; ב-Agile — לא לכלול מיותר בbacklog; קיבוע scope; ראה YAGNI. - **פירוט יתר שאינו נחוץ.** כיצד למנוע: להפריד בין *מה/למה* (דרישות) ל*איך* (עיצוב/מימוש); להפעיל *design‑free requirements* היכן שמתאים.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)} - **הפרת ניהוליות דרישות**. *השלכות:* בלבול גרסאות, מימוש «הדבר הלא נכון». כיצד למנוע: מקור אמת יחיד ב-ALM, היסטוריזציה וסטטוסים, RTM וchange impact analysis; ניהול שינויים דרך CCB.^{[\[64\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} - **היעדר השתתפות משתמשים**. כיצד למנוע: ראיונות, תצפית, אבות-טיפוס, הצגות סדירות; validation מפורשת עם בעלי עניין.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} - **«שיתוק ניתוחי» ממושך מדי**. כיצד למנוע: אזור הספיקות, איטרטיביות ו-timeboxing; הפעלת MVP/תוספות ותיקון על פי משוב.^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} - **התעלמות מדרישות לא-פונקציונליות**. כיצד למנוע: לייחד NFR (למשל, FURPS+), להגדיר קריטריונים מדידים, לכלול אותם בתוכנית הבדיקות ובהחלטות הארכיטקטוניות.^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)} - **שגיאות תקשורת ו«גורם אנושי»**. כיצד לפתור: לפתח ראיון ופסיליטציה, לשמור ניטרליות, לקבע החלטות ומקורות דרישות (מעקביות למטרות).^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} רוב הבעיות מתכנסות לאיכות הניסוחים, שלמות הדרישות וניהוליותן; יישום תקני ISO/IEC/IEEE 29148 ופרקטיקות SWEBOK (ניתנות לאימות, מעקביות, איטרטיביות) מפחית משמעותית את הסיכון לחריגה בלוחות זמנים ולעיבוד מחדש.^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-SWEBOK-1)} ## מגבלות למרות יעילותו בהפחתת אי-ודאות, לניתוח מערכות יש מגבלות משלו: - **המציאות משתנה ומורכבת.** אי-אפשר לקחת בחשבון את כל הגורמים, במיוחד בפרויקטים ארוכי-טווח. חלק מהדרישות יתגלו בהכרח לאחר השקת המערכת. חשוב לשאוף למזעור הפתעות, אך יש להיות מוכנים לשינויים. - **דרישות תלויות בבני אדם.** סדרי עדיפויות עסקיים, חוקים ושוק עשויים להשתנות. ניתוח מערכות מקבע את המצב הנוכחי ואינו יכול לחזות את כל השינויים החיצוניים. להסתגלות, יש לעדכן דרישות באופן סדיר ולעבוד באופן איטרטיבי. - **משתמשים לא תמיד יודעים מה הם רוצים עד שהם רואים זאת.** זוהי מגבלה ידועה. אב-טיפוס ומתודולוגיות גמישות כגון Agile עוזרות להתגבר על בעיה זו. ניתוח על הנייר מוגבל, ולקבלת נתונים מדויקים נדרש משוב ממימושים. - **איזון בין זמן לאיכות.** ניתוח מפורט מדי עלול להתיישן. בתחומים חדשניים עדיף ליצור מהיר מינימום מוצר קיים (MVP) ולקבל נתונים אמיתיים. ניתוח מערכות יעיל בתחומים יציבים, אך בפרויקטי מחקר ופיתוח (R&D) תפקידו מוגבל. - **גורם אנושי.** אפילו המתודולוגיות הטובות ביותר אינן מפצות על חוסר כשירות של אנליסט או אי-זמינות הלקוח. חשוב שכל המשתתפים בתהליך יהיו מעורבים ומוטיבציים. ## השפעת הטכנולוגיות המודרניות על ניתוח מערכות בIT ניתוח מערכות בIT מתפתח ללא הרף תחת השפעת חידושים טכנולוגיים. האנליסט של המאה ה-21 עובד בתנאי גידול מהיר בנפחי הנתונים, יישום נרחב של AI, מחזור פיתוח מהיר ותשומת לב מוגברת לאבטחה. פרקטיקה מוצלחת של ניתוח מערכות מחייבת רכישת ידע חדש (Data Science, אבטחת סייבר, טכנולוגיות ענן) וגמישות ביישום שיטות. - **נתונים ו-AI/ML: מה מתווסף לניתוח**. עבור מערכות עם AI כבר בתחילה מקבעים מטרות והקשר יישום, דרישות למקורות ואיכות הנתונים, וכן מדדי אמון בהחלטות המודל (אמינות, אבטחה, ניתנות להסבר, פרטיות, הוגנות). מתכננים בדיקות **TEVV** (testing, evaluation, verification, validation), ניטור בהפעלה וכיבוי/הוצאה בטוחה של המודל. שלבים אלה תואמים את פונקציות **GOVERN–MAP–MEASURE–MANAGE** ממסגרת NIST לניהול סיכוני AI; הם באים לידי ביטוי ב-SRS, בארכיטקטורה ובתוכניות אימות/הפעלה.^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NIST_AI_RMF-70)} - **DevSecOps: אבטחה «משמאל» וכברירת מחדל**. הטמעת אבטחה בכל שלב של **CI/CD** הופכת לנורמה: בדיקות אוטומטיות (SAST/DAST), סריקת תלויות וcontainers, מדיניות פריסה, observability בסיסי. משתמשים במרשמי ארטיפקטים מהימנים ובimages «מוקשחים» מתוקננים; מיושמים עקרונות Zero Trust. בניתוח מערכות מתארים מראש **נקודות בקרת pipeline** (תנאי מעבר שלבים), קשר דרישות לבקרות אבטחה וחוקי מעבר בין סביבות (dev/test/stage/prod).^{[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-DoD_DevSecOps-71)} - **מה משתנה במסמכים (ארטיפקטים)**. איזה חלק מופיע או מדוייק במסמכי מפתח בנוכחות Big Data ו-AI/ML ובעבודה לפי DevSecOps: - **SRS / מפרט דרישות**: מטרות והקשר יישום AI; דרישות לנתונים (מוצא, איכות, מגבלות אתיות וחוקיות); מדדי מודל (דיוק, אמינות, זמן תגובה); תוכנית TEVV (testing, evaluation, verification, validation); דרישות שקיפות/ניתנות להסבר ופרטיות; קריטריונים לכיבוי/הוצאת מודל מהפעלה.^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NIST_AI_RMF-70)} - **ארכיטקטורה והחלטות (Architecture, ADR)**: תוצאות מידול איומים; אמצעי «אבטחה כברירת מחדל» (הצפנה, בקרת גישה, ניהול סודות, עיקרון הרשאות מינימליות); מגבלות שימוש בנתונים/מודלים; רשומות ADR עם הערכת סיכונים ופשרות.^{[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NIST_AI_RMF-70)} - **תוכנית אימות ותיקוף (V&V / TEVV)**: תרחישי בדיקה של מודלים ונתונים; סף קבלה למדדי איכות; ניטור דריפט נתונים/מודל; נהלי הערכה מחודשת סדירה ותיקוף מחדש.^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NIST_AI_RMF-70)} - **מדיניות CI/CD ו«שערי» pipeline**: בדיקות אוטומטיות SAST/DAST, SCA (תלויות), סריקת containers; חתימה ואחסון ארטיפקטים במרשמים מהימנים; חוקי קידום בין סביבות (dev/test/stage/prod) ותנאי חסימת build בכשל בדיקות; דרישות observability כברירת מחדל.^{[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-DoD_DevSecOps-71)} - **תוכנית ניהול נתונים ומודלים**: קטלוג מקורות ו-lineage; קריטריוני איכות וזמינות נתונים; גרסאות datasets/מודלים; לוח זמנים ל(אימון מחדש) ובקרת bias; מדיניות גישה ואחסון; תוכנית כיבוי בטוח של מודל ומחיקת נתונים אם נדרש.^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NIST_AI_RMF-70)} - **הפעלה ו-observability (Ops/Runbook)**: מדדי אמון AI ו-SLO; ביקורת ורישום ביומן; התראות על הידרדרות/חריגות; תוכנית תגובה לאירועים; fallback/kill‑switch לרכיבי AI; דרישות דיווח וניתוח לאחר אירועים.^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-DoD_DevSecOps-71)} - **מעקביות** (end‑to‑end): קשרים מפורשים «**דרישה ↔ בקרה/בדיקה ב-pipeline**» ו«**דרישה ↔ בדיקה/ניטור בהפעלה**», כדי שניתן יהיה לאמת באופן מוכח אבטחה ואיכות לאורך כל מחזור החיים.^{[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NIST_AI_RMF-70)} - **תפקיד אנליסט המערכות**. - מנהל את ההקשר והסיכונים של AI (שחקנים, תרחישי שימוש, הנחות ומגבלות נתונים); - מבטיח מעקביות «**דרישה ↔ בקרת אבטחה ב-pipeline**»; - מנסח דרישות לא-פונקציונליות ניתנות לאימות (אבטחה, שקיפות, observability) לאורך כל מחזור החיים של המערכת.^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-DoD_DevSecOps-71)} ## הבדלים מניתוח המערכות הקלאסי המונח «ניתוח מערכות» היסטורית רחב יותר מפיתוח תוכנה. ניתוח מערכות קלאסי — גישה לפתרון בעיות מורכבות בין-תחומיות (חברתיות, כלכליות, ניהוליות), המבוססת על חשיבה מערכתית ושיטות כמותיות, בדרך כלל לתמיכה בהחלטות ניהוליות. בIT ניתוח מערכות מובן כדיסציפלינה יישומית בתחום הנדסת תוכנה, המוכוונת ליצירת מערכות מידע. להלן — ההבדלים העיקריים. - **מטרות ועצם הניתוח**. הניתוח הקלאסי פותר בעיות לא-מובנות, «מטושטשות» ומשפר מערכות סוציו-טכניות קיימות (רשת תחבורה עירונית, אסטרטגיית חברה, מדיניות סביבתית). העצם — מערכת ממשית; המשימה — לעזור למקבל ההחלטות לבחור מהלך. עבור ניתוח מערכות בIT המטרה — לתכנן וליצור מערכת מידע חדשה או מוצר תוכנה העומדים בדרישות. העצם — המערכת המתוכננת; הפוקוס — ההתנהגות והמאפיינים שנחוצים למשתמשים. - **בסיסים מתודולוגיים**. האסכולות הקלאסיות נסמכות על חשיבה מערכתית ולעיתים קרובות על מתמטיקה. גישה קשה (hard systems) — פורמליזציה של הבעיה, קריטריונים כמותיים, אופטימיזציה (כמו ב-*operations research*). מתודולוגיות רכות (soft systems) מכירות בריבוי נקודות מבט; דוגמה — *Soft Systems Methodology (SSM)*, שבה דרך דיונים ומודלים קונצפטואליים מסכימים על שינויים רצויים. בIT הבסיס — דיסציפלינות הנדסיות: הנדסת דרישות, תכנון תוכנה, frameworkים ארכיטקטוניים. מיושמים תהליכים מתוקננים (ISO/IEC/IEEE 15288, 12207, 29148), סימונים UML/SysML ופרקטיקות ניהול שינויים. - **תפקידים וארטיפקטים**. בניתוח הקלאסי תפקיד «אנליסט המערכות» לעיתים קרובות בלתי-פורמלי; התוצאות — דוח ניתוחי, המלצות, מודלים מתמטיים, תרחישי «מה-אם». בIT תפקיד האנליסט (או אנליסט עסקי) הוא פורמלי; מופקים מפרטי דרישות, מודלים של מערכת (UML, ER), מפרטי ממשקים, user stories ו-backlog — ארטיפקטים בשימוש ישיר של מפתחים ובודקים. - **מחזור חיים ותהליך**. לניתוח הקלאסי אין תבנית אחידה: הצעדים תלויים בבעיה (ב-SSM — מחקירת המצב ועד ליישום שינויים). בIT מקובלים מחזורי SDLC סטנדרטיים: במודל מפל מים יש שלב נפרד של ניתוח דרישות; בגישות איטרטיביות וגמישות הניתוח הוא פעילות קבועה של כל sprint. פרקטיקות מודרניות (DevOps, CI/CD) מרחיבות את מסגרת הניתוח אל ההפעלה: נלקחות בחשבון דרישות לתחזוקה, observability ועדכניות. במילים אחרות, ניתוח מערכות בIT משולב במחזור החיים של הפיתוח, בעוד שהקלאסי מבוצע לרוב כפעילות פרויקטלית/ייעוצית. ## אנליסט מערכות **אנליסט מערכות בIT** — מומחה האחראי על חשיבה מערכתית בתכנון ופיתוח מערכות מידע: גיבוש ואימות דרישות, מידול (UML/BPMN), הסכמת החלטות ארכיטקטוניות והבטחת אינטגרציה. התפקיד ודרישות הכשירות בפדרציה הרוסית מעוגנים בתקן מקצועי ו-FGOS. **המטרה העיקרית של סוג הפעילות המקצועית:** הבטחת התאמת שירות IT, מערכת ממוחשבת, מערכת מידע ממוחשבת, מערכת ניהול ממוחשבת, מוצר תוכנה, מידע או אמצעי (להלן — המערכת) לסביבה, לדרישות ולמגבלות המקוריות, למטרות האוטומציה ולפעילות הממוחשבת, באמצעות פיתוח והעברת החלטות פרויקטליות איכותיות ומשולבות לצדדים המעוניינים בעת הפעלה ותיאום עבודת מבצעים בודדים לאורך כל מחזור החיים של המערכת (*תקן מקצועי «אנליסט מערכות» (צו משרד העבודה של הפדרציה הרוסית מיום 27.04.2023 מס' 367נ*).^{[\[72\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_note-72)} ## גלוסר מונחי מפתח ### מושגים בסיסיים ומשתתפים - ניתוח מערכות בIT — דיסציפלינה שנושאה הוא מערכת המידע לאורך כל מחזור חייה, מהרעיון ועד להפעלה. - בעלי עניין (Stakeholders) — אנשים או קבוצות המעוניינים בפרויקט או שמושפעים ממנו (לקוחות, משתמשים, מנהלים). - ארטיפקטים של פרויקט — מסמכים ותוצאות שנוצרים במהלך הפרויקט, כגון מפרטים, מודלים, תוכניות והחלטות. ### דרישות: סוגים ותיעוד - דרישות פונקציונליות — מתארות מה המערכת צריכה לעשות; את פונקציותיה והתנהגותה. - דרישות לא-פונקציונליות — מתארות מאפייני איכות של המערכת (אמינות, ביצועים, אבטחה, נוחות שימוש, סקלביליות וכד'). - מפרט דרישות (ראשוני) — מסמך המכיל את סט הדרישות הראשוני שנאסף בשלבים הראשוניים של הפרויקט. - SRS (Software Requirements Specification) — מסמך מתוקנן המתאר בפירוט את הדרישות לתוכנה בהתאם לתקנים בינלאומיים (למשל, ISO/IEC/IEEE 29148). - URS (User Requirements Specification) — מסמך המתאר את דרישות המשתמש למערכת מנקודת מבט של תהליכים עסקיים וציפיות המשתמש הסופי. - דרישות משמעותיות ארכיטקטונית (ASR) — דרישות המשפיעות משמעותית על החלטות ארכיטקטוניות ופשרות. - דרישות רוחביות-פונקציונליות (CFR) — מילה נרדפת לדרישות לא-פונקציונליות, המדגישה את אופיין הרוחבי. - קריטריוני קבלה (Acceptance Criteria) — תנאים ניתנים לאימות שבהתקיימם עבודת הדרישה נחשבת מקובלת. - Definition of Ready (DoR) — הסכם לגבי מוכנות פריט backlog לפיתוח (בהירות, הערכה, קריטריונים). - Definition of Done (DoD) — הסכם לגבי «שלמות» העבודה (קוד, בדיקות, תיעוד, פריסה). - מגבלה (Constraint) — תנאי קשיח המגביל פתרונות (לוחות זמנים, פלטפורמות, תקנים, רישיונות). - הנחה (Assumption) — הנחה המתקבלת ללא הוכחה, הדורשת אימות מאוחר יותר. - איכות דרישות — מאפיינים לפי ISO 29148: חד-משמעיות, שלמות, עקביות, ניתנות לאימות, אטומריות. ### פורמליזציה, מעקביות ותעדוף דרישות - פורמליזציה של דרישות — תהליך המרת בקשות לא-פורמליות לדרישות ברורות, ניתנות לאימות וחד-משמעיות. - מעקביות דרישות — יכולת מעקב אחר מחזור חיי דרישה ממקורה ועד למימוש, בדיקות ופריסה. - Bidirectional traceability (מעקביות דו-כיוונית) — יכולת מעקב אחר קשרים בין דרישות, אלמנטי עיצוב ותרחישי בדיקה הן בכיוון קדימה והן בכיוון אחורה. - MoSCoW — טכניקת תעדוף דרישות המסווגת אותן כ-Must-have (חייב להיות), Should-have (ראוי לכלול), Could-have (אפשר לכלול) ו-Won't-have (לא יהיה). - BDD (Behavior-Driven Development) — מתודולוגיית פיתוח שבה הבדיקות כתובות בשפה טבעית המוכוונת להתנהגות המערכת מנקודת מבט המשתמש (פורמט Given–When–Then). ### סימונים ומידול - UML (Unified Modeling Language) — שפת מידול גרפית מתוקננת לספציפיקציה, ויזואליזציה, בנייה ותיעוד רכיבי מערכות תוכנה. - SysML (Systems Modeling Language) — הרחבה של UML להנדסת מערכות, התומכת במידול היבטים שונים של מערכות מורכבות, כולל דרישות, התנהגות, מבנה ופרמטרים. - BPMN (Business Process Model and Notation) — תקן סימון גרפי לתיאור תהליכים עסקיים, המאפשר ויזואליזציה של זרימות עבודה, אירועים, שערים ו-pools. - MBSE (Model-Based Systems Engineering) — גישה להנדסת מערכות שבה המודל הוא הארטיפקט המרכזי בכל שלבי מחזור חיי המערכת, מדרישות ועד בדיקות. - ArchiMate — סימון לארכיטקטורת ארגון (עסקים, יישומים, טכנולוגיות) וקשריהם. - DMN (Decision Model and Notation) — מידול החלטות עסקיות וטבלאות חוקים. - DFD (Data Flow Diagram) — דיאגרמות זרימת נתונים (הקשר, רמות פירוק). - ERD (Entity-Relationship Diagram) — מודל תחום הבעיה עם ישויות, קשרים ומאפיינים. - מטריצת CRUD — התאמת פעולות Create/Read/Update/Delete לישויות ולתפקידים/פונקציות. ### סגנונות ארכיטקטוניים והערכת פתרונות - ארכיטקטורה מונוליתית — גישה ארכיטקטונית שבה כל המערכת מפותחת כמודול אחד, בלתי-ניתן לחלוקה. - ארכיטקטורת מיקרו-שירותים — גישה ארכיטקטונית שבה המערכת בנויה כסט של שירותים קטנים, הניתנים לפריסה ולהתאמה לגודל באופן עצמאי. - Trade-off (פשרה) — בחירה בין מאפיינים או פתרונות בלעדיים או סותרים, שבה שיפור מאפיין אחד מתרחש על חשבון הידרדרות האחר. - ATAM (Architecture Tradeoff Analysis Method) — שיטת הערכת ארכיטקטורת תוכנה, המשמשת לניתוח פשרות בין מאפייני איכות (למשל ביצועים, סקלביליות). ### ארכיטקטורת ארגון ו-frameworks - TOGAF (The Open Group Architecture Framework) — אחד ה-frameworks הנפוצים ביותר לארכיטקטורת ארגון, הכולל שיטת ADM (Architecture Development Method) לפיתוח וניהול ארכיטקטורה. - Zachman Framework — אונטולוגיה של ארטיפקטים של ארכיטקטורת ארגון, המוצגת כמטריצה 6×6, המסווגת היבטים שונים של ארכיטקטורה מפרספקטיבות שונות. ### גישות לניתוח ותהליכי פיתוח - גישה קשה (Hard Systems) — מתודולוגיית ניתוח מערכות המניחה מטרות ודרישות הניתנות לפורמליזציה מראש, פירוק ותכנון «מלמעלה למטה», יעילה למשימות מוגדרות בבירור. - גישה רכה (Soft Systems) — מתודולוגיית ניתוח מערכות המיושמת כשהמטרות אינן ברורות ויש נקודות מבט מרובות של בעלי עניין, המכוונת להסכמת הבנת הבעיה והשינויים הרצויים. - SSM (Soft Systems Methodology) — מתודולוגיית הגישה הרכה הספציפית שפיתח פיטר צ'קלנד, המשתמשת בכלים כגון rich picture, הגדרות שורש ו-CATWOE. - Waterfall (מודל מפל מים) — מתודולוגיית פיתוח תוכנה קלאסית שבה השלבים (ניתוח, תכנון, מימוש, בדיקות, יישום) מבוצעים ברצף, עם השלמה מלאה של השלב הקודם לפני תחילת הבא. - Agile — קבוצת מתודולוגיות פיתוח תוכנה גמישות, המוכוונות לפיתוח איטרטיבי, הסתגלות לשינויים, אינטראקציה עם הלקוח ואספקה רציפה של ערך. ### שיטות בחירה ושגיאות אופייניות - AHP (Analytic Hierarchy Process) — שיטת בחירה רב-קריטריאלית המאפשרת מבנה בעיות מורכבות והערכת חלופות על בסיס היררכיית קריטריונים. - Gold-plating (תסמונת «הציפוי הזהב») — שגיאה בניתוח מערכות המורכבת מהוספת פונקציונליות שאינה נדרשת על ידי בעלי עניין, מה שמוביל לגידול היקף ומורכבות הפרויקט. ## קישורים - ISO/IEC/IEEE 15288:2023 — System life cycle processes - ISO/IEC/IEEE 12207:2017 — Software life cycle processes - ISO/IEC/IEEE 29148:2018 — Requirements engineering - ISO/IEC/IEEE 42010:2022 — Architecture description - ISO/IEC 25010:2023 — Product quality model (SQuaRE) - ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288 - ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation) - ISO/IEC/IEEE 42020:2019 — Architecture processes - ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts - IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation - UML 2.5.1 — OMG Specification - BPMN 2.0.2 — OMG Specification - SysML v1.7 — OMG Specification - TOGAF Standard, 10th Edition — The Open Group - ArchiMate 3.2 — The Open Group - SEI ATAM — Architecture Tradeoff Analysis Method - NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF) - SWEBOK Guide v4.0a — IEEE Computer Society (PDF) - Guide to the Systems Engineering Body of Knowledge (SEBoK) - BABOK Guide v3 — IIBA - Google SRE Books — Official site - Microsoft Azure Well-Architected Framework — Official docs - ניתוח מערכות במילים פשוטות. YouTube - ניתוח מערכות בIT במילים פשוטות. YouTube ## ספרות - ISO/IEC/IEEE (2023). *15288: System Life Cycle Processes*. - INCOSE (2023). *INCOSE Systems Engineering Handbook*, מהד' 5. - ISO/IEC/IEEE (2018). *29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering*. - IIBA (2015). *A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3*. - The Open Group (2022). *The TOGAF® Standard, 10th Edition*. גרסה רשמית חינמית. - OMG (2017). *Unified Modeling Language (UML®) 2.5.1 Specification*. PDF. - OMG (2014). *Business Process Model and Notation (BPMN™) 2.0.2 Specification*. PDF. - OMG (2024). *Systems Modeling Language (SysML®) 1.7 Specification*. PDF. - The Open Group (2022). *ArchiMate® 3.2 Specification*. הורדה רשמית חינמית (ברישיון). - Bass, L.; Clements, P.; Kazman, R. (2021). *Software Architecture in Practice*, מהד' 4. - Wiegers, K.; Beatty, J. (2013). *Software Requirements*, מהד' 3. - Rozanski, N.; Woods, E. (2012). *Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives*, מהד' 2. - Meadows, D. (2008). *Thinking in Systems: A Primer*. - Senge, P. M. (2006). *The Fifth Discipline: The Art & Practice of the Learning Organization* (rev. ed.). - Blanchard, B. S.; Fabrycky, W. J. (2010). *Systems Engineering and Analysis*, מהד' 5. - Robertson, J.; Robertson, S. (2012). *Mastering the Requirements Process: Getting Requirements Right*, מהד' 3. - van Lamsweerde, A. (2009). *Requirements Engineering: From System Goals to UML Models to Software Specifications*. - Hull, E.; Jackson, K.; Dick, J. (2017). *Requirements Engineering*, מהד' 4. - Kendall, K. E.; Kendall, J. E. (2023). *Systems Analysis and Design*, מהד' 11. - Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). *Systems Analysis and Design: An Object-Oriented Approach with UML*, מהד' 8. - Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). *Systems Analysis and Design in a Changing World*, מהד' 7. - Fowler, M. (2003). *UML Distilled: A Brief Guide to the Standard Object Modeling Language*, מהד' 3. - Delligatti, L. (2013). *SysML Distilled: A Brief Guide to the Systems Modeling Language*. - Silver, B. (2011). *BPMN Method and Style*, מהד' 2. - Lankhorst, M. et al. (2017). *Enterprise Architecture at Work: Modelling, Communication and Analysis*, מהד' 4. - Richards, M.; Ford, N. (2020). *Fundamentals of Software Architecture*. - Fairbanks, G. (2010). *Just Enough Software Architecture: A Risk-Driven Approach*. - Keeling, M. (2017). *Design It!: From Programmer to Software Architect*. - Evans, E. (2003). *Domain-Driven Design: Tackling Complexity in the Heart of Software*. - Vernon, V. (2013). *Implementing Domain-Driven Design*. - Brandolini, A. (2018). *Introducing EventStorming: An Act of Deliberate Collective Learning*. - Simsion, G.; Witt, G. (2015). *Data Modeling Essentials*, מהד' 4. - Silverston, L. (2008–2009). *The Data Model Resource Book*, Vols. 1–3 (rev. eds.). - Keeney, R. L.; Raiffa, H. (1993). *Decisions with Multiple Objectives: Preferences and Value Trade-Offs*, מהד' 2. - Saaty, T. L. (1980). *The Analytic Hierarchy Process*; (1990) *Decision Making for Leaders*. ## הערות 1. ↑ ^{[1.00](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-0)} ^{[1.01](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-1)} ^{[1.02](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-2)} ^{[1.03](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-3)} ^{[1.04](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-4)} ^{[1.05](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-5)} ^{[1.06](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-6)} ^{[1.07](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-7)} ^{[1.08](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-8)} ^{[1.09](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-9)} ^{[1.10](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-10)} ^{[1.11](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-11)} ^{[1.12](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SWEBOK_1-12)} IEEE Computer Society (2025). *Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a*. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf 2. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-Zowghi_2-0) Zowghi, D.; Coulin, C. (2005/2014). *Requirements Elicitation: A Survey of Techniques, Approaches, and Tools*. https://eecs481.org/readings/requirements.pdf 3. ↑ ^{[3.00](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-0)} ^{[3.01](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-1)} ^{[3.02](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-2)} ^{[3.03](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-3)} ^{[3.04](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-4)} ^{[3.05](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-5)} ^{[3.06](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-6)} ^{[3.07](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-7)} ^{[3.08](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-8)} ^{[3.09](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-9)} ^{[3.10](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-10)} ^{[3.11](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-11)} ^{[3.12](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO29148_3-12)} ISO/IEC/IEEE 29148 (2011/2018). *Systems and software engineering — Requirements engineering*. *ISO* overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html 4. ↑ ^{[4.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA7123_4-0)} ^{[4.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA7123_4-1)} ^{[4.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA7123_4-2)} NASA (2020). *NPR 7123.1C — Systems Engineering Processes and Requirements*. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all 5. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-5) GMU (George Mason University). *IEEE Software Requirements Specification Template (SRS)*. https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc 6. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-6) Westfall, L. (Cal Poly, .edu). *The What, Why, Who, When and How of Software Requirements* (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf 7. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-7) Stanford University IT (.edu). *Functional Specification Document Template*. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx 8. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-8) Penn State (.edu). *Elements of a Use Case Diagram*. https://www.e-education.psu.edu/geog468/l8_p4.html 9. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-9) UC Irvine (.edu). *Data Flow Diagram*. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/ 10. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ISO42010_10-0) ISO/IEC/IEEE 42010 (2011/2022). *Architecture description* — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/ 11. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-11) Cornell University (.edu). *CS 5150 — Feasibility Studies*. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf 12. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-ATAM_12-0) Carnegie Mellon SEI. *Architecture Tradeoff Analysis Method (ATAM) — overview*. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/ 13. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-13) Microsoft Azure Architecture Center. *Architecture styles: microservices — benefits & complexity*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/ 14. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-14) Google Cloud. *What Is Microservices Architecture? — Monolithic vs. microservices (обзор)*. https://cloud.google.com/learn/what-is-microservices-architecture 15. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-15) NASA (2023). *Requirements Management — Traceability, Bidirectional traceability (definitions)*. https://www.nasa.gov/reference/6-2-requirements-management/ 16. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-16) McKinsey (2012). *Delivering large-scale IT projects on time, on budget, and on value*. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value 17. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-17) University of Cambridge, IfM. *Soft Systems Methodology (SSM) — CATWOE, 3Es*. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/ 18. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-18) Lancaster University (ePrints). *Soft Systems Methodology and root definitions*. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf 19. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-19) University of Cambridge, IfM. *Soft Systems Methodology (SSM)*. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/ 20. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-20) UCL Discovery (.ac.uk). M. Haklay. *Soft System Methodology (SSM)*. https://discovery.ucl.ac.uk/1296/1/paper13.pdf 21. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-21) IEEE Std 1320.1-1998 (R2004). *Functional Modeling Language — Syntax and Semantics for IDEF0*. https://standards.ieee.org/ieee/1320.1/2003/ 22. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-22) ISO/IEC/IEEE 31320-1:2012. *IDEF0: Function Modeling*. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf 23. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-23) University of Washington (.edu). *UML Class Diagrams / UML overview (course material)*. https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf 24. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-24) JHU/APL (.edu). *Modeling with SysML — tutorial*. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf 25. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-25) MIT OCW (.edu). O. de Weck. *Introduction to Systems Modeling Languages (incl. SysML, MBSE)*. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf 26. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-26) IBM. *What is Business Process Modeling and Notation (BPMN)?*. https://www.ibm.com/think/topics/bpmn 27. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-27) IBM Docs. *Business Process Modeling Notation (BPMN) model*. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model 28. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-28) IEEE/ISO/IEC 29148:2018. *Systems and software engineering — Requirements engineering (overview)*. https://standards.ieee.org/ieee/29148/6937/ 29. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-29) King’s College London (.ac.uk). *What is MoSCoW prioritization?*. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/ 30. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-30) T. L. Saaty. *How to Make a Decision: The Analytic Hierarchy Process*. *Interfaces* 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19 31. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-31) Microsoft Learn (Azure Boards). *Best practices for Agile project management — Refine each backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management 32. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-32) MIT OCW (.edu). *V-Model — Fundamentals of Systems Engineering*. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/ 33. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-33) Carnegie Mellon SEI (.edu). *Architecture Tradeoff Analysis Method (ATAM) — overview*. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/ 34. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-AzureStyles_34-0) Microsoft Azure Architecture Center. *Architecture styles*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/ 35. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SEI_ATAM_35-0) Kazman, R.; Klein, M.; Clements, P. *ATAM: Method for Architecture Evaluation*. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf 36. ↑ ^{[36.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-TOGAFIntro_36-0)} ^{[36.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-TOGAFIntro_36-1)} ^{[36.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-TOGAFIntro_36-2)} ^{[36.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-TOGAFIntro_36-3)} The Open Group. *Introduction — The TOGAF® Standard*. https://www.togaf.org/chap01.html 37. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-AzureEvent_37-0) Microsoft Azure Architecture Center. *Event-Driven Architecture style*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven 38. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-38) Jonkers, H. et al. *ArchiMate® and the TOGAF® Framework*. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf 39. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-39) Estrem, W. *Building Blocks Revisited*. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf 40. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-40) The Open Group. *Architecture Principles*. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf 41. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-41) The Open Group. *IT Architecture Compliance*. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm 42. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-42) *The TOGAF® Standard, Version 9.2* (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf 43. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-43) Engelsman, W.; van Sinderen, M. *Supporting Requirements Management in TOGAF and ArchiMate*. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf 44. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-Zachman1987_44-0) Zachman, J. A. *A Framework for Information Systems Architecture*. *IBM Systems Journal*, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276 45. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-45) MIT CISR. *Classic Topics — Enterprise Architecture* (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture 46. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-46) The Open Group. *IT Architecture Compliance*. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm 47. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-Royce_47-0) Royce, W. W. (1970). *Managing the Development of Large Software Systems*. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf 48. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-DAU_SRR_48-0) Defense Acquisition University. *System Requirements Review (SRR) — Acquipedia*. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/ 49. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA_CCB_49-0) NASA (2023). *Requirements Management — baseline, change control (CCB)*. https://www.nasa.gov/reference/6-2-requirements-management/ 50. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-MS_Agile_50-0) Microsoft Learn (Azure Boards). *Best practices for Agile project management — Refine each backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management 51. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-MS_BDD_51-0) MSDN Magazine (Microsoft). *BDD Primer: Behavior‑Driven Development with SpecFlow*. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin 52. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-MS_Trace_52-0) Microsoft Learn. *End‑to‑end traceability in Azure DevOps*. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability 53. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SRE_SLO_53-0) Google SRE. *Service Level Objectives*; *Error Budget Policy*. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/ 54. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-AzureMon_54-0) Microsoft Learn. *Azure Monitor — Overview*. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview 55. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-AWS_BlueGreen_55-0) AWS Whitepaper. *Blue/Green Deployments on AWS*. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html 56. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-Azure_Workflow_56-0) Microsoft Learn. *Manage change — track, triage, and implement change requests*. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change 57. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-Azure_Backlog_57-0) Microsoft Learn (Azure Boards). *Backlogs overview — create and manage your product backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview 58. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-MS_Test_58-0) Microsoft Learn (Azure Test Plans). *What is Azure Test Plans?*. https://learn.microsoft.com/en-us/azure/devops/test/overview 59. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-MS_SpecFlow_59-0) MSDN Magazine. *Behavior‑Driven Design with SpecFlow*. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow 60. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-IBM_MTTR_60-0) IBM. *MTTR vs. MTBF: What’s the difference?*. https://www.ibm.com/think/topics/mttr-vs-mtbf 61. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-GCloud_Obs_61-0) Google Cloud. *Google Cloud Observability*. https://cloud.google.com/products/observability 62. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-IEEE830_62-0) IEEE Std 830‑1998. *IEEE Recommended Practice for Software Requirements Specifications* (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf 63. ↑ ^{[63.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA_SEH_63-0)} ^{[63.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA_SEH_63-1)} ^{[63.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA_SEH_63-2)} ^{[63.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA_SEH_63-3)} NASA. *Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2)*. https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf 64. ↑ ^{[64.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA_RM_64-0)} ^{[64.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA_RM_64-1)} NASA (2023). *Requirements Management — traceability, baseline, CCB*. https://www.nasa.gov/reference/6-2-requirements-management/ 65. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-MoSCoW_65-0) King’s College London (.ac.uk). *What is MoSCoW prioritization?*. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/ 66. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-Saaty_66-0) Saaty, T. L. (1994). *How to Make a Decision: The Analytic Hierarchy Process*. *Interfaces* 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19 67. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SEI_CMMI_67-0) SEI / CMMI Institute. *Capability Maturity Model Integration (CMMI) — Overview*. https://www.sei.cmu.edu/cmmi/ 68. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NASA_FM_68-0) NASA Langley. *What is Formal Methods?*; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf 69. ↑ ^{[69.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SEI_Pitfalls_69-0)} ^{[69.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-SEI_Pitfalls_69-1)} SEI (CMU). *Common Testing Problems: Pitfalls to Prevent and Mitigate* (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/ 70. ↑ ^{[70.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NIST_AI_RMF_70-0)} ^{[70.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NIST_AI_RMF_70-1)} ^{[70.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NIST_AI_RMF_70-2)} ^{[70.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NIST_AI_RMF_70-3)} ^{[70.4](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NIST_AI_RMF_70-4)} ^{[70.5](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NIST_AI_RMF_70-5)} ^{[70.6](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NIST_AI_RMF_70-6)} ^{[70.7](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-NIST_AI_RMF_70-7)} NIST (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf 71. ↑ ^{[71.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-DoD_DevSecOps_71-0)} ^{[71.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-DoD_DevSecOps_71-1)} ^{[71.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-DoD_DevSecOps_71-2)} ^{[71.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-DoD_DevSecOps_71-3)} ^{[71.4](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-DoD_DevSecOps_71-4)} ^{[71.5](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-DoD_DevSecOps_71-5)} U.S. DoD CIO (2021). *DoD Enterprise DevSecOps Reference Design*. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf 72. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D7%A0%D7%99%D7%AA%D7%95%D7%97_%D7%9E%D7%A2%D7%A8%D7%9B%D7%95%D7%AA_%D7%91IT#cite_ref-72) Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).