תבנית רשומת החלטה של arc42

https://arc42.org/overview

1. מבוא ומטרות

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

1.1 סקירת דרישות

תוכן

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

מוטיבציה

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

צורה

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

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

1.2 מטרות איכות

תוכן

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

מוטיבציה

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

צורה

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

1.3 בעלי עניין

תוכן

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

• צריכים להכיר את הארכיטקטורה

• צריך לשכנע אותם בארכיטקטורה

• צריכים לעבוד עם הארכיטקטורה או עם הקוד

• זקוקים לתיעוד הארכיטקטורה לצורך עבודתם

• צריכים לקבל החלטות לגבי המערכת או פיתוחה

מוטיבציה

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

צורה

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

2. אילוצים

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

תוכן

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

מוטיבציה

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

צורה

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

3. הקשר והיקף

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

תוכן

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

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

מוטיבציה

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

צורה

• תרשימי הקשר שונים

• רשימות של שותפי תקשורת והממשקים שלהם.

3.1 הקשר עסקי

תוכן

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

מוטיבציה

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

צורה

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

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

3.2 הקשר טכני

תוכן

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

מוטיבציה

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

צורה

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

4. אסטרטגיית פתרון

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

תוכן

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

• החלטות טכנולוגיה

• החלטות על הפירוק ברמה העליונה של המערכת, למשל שימוש בתבנית ארכיטקטורה או בתבנית עיצוב

• החלטות כיצד להשיג מטרות איכות מרכזיות

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

מוטיבציה

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

צורה

שמרו על הסבר ההחלטות המרכזיות האלה קצר.

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

אפשר להשתמש ברשימה של גישות פתרון או בטבלה.

5. מבט אבני בניין

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

תוכן

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

המבט הזה הוא חובה בכל תיעוד ארכיטקטורה. באנלוגיה לבית, זו תוכנית הקומה.

מוטיבציה

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

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

צורה

מבט אבני הבניין הוא אוסף היררכי של קופסאות שחורות וקופסאות לבנות (ראו האיור להלן) ותיאוריהן.

5.1 קופסה לבנה של המערכת כולה

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

• תרשים סקירה

• מוטיבציה לפירוק

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

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

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

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

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

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

5.2 רמה 2

כאן אפשר לפרט את המבנה הפנימי של (חלק מ)אבני הבניין מרמה 1 כקופסאות לבנות.

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

5.2.1 קופסה לבנה לאבן בניין 1

מפרטת את המבנה הפנימי של אבן בניין 1.

השתמשו בתבנית הקופסה הלבנה (ראו לעיל).

6. מבט זמן ריצה

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

תוכן

מבט זמן הריצה מתאר התנהגות ואינטראקציות קונקרטיות של אבני הבניין של המערכת בצורת תרחישים מהתחומים הבאים:

• מקרי שימוש או יכולות חשובים: איך אבני הבניין מבצעות אותם?

• אינטראקציות בממשקים חיצוניים קריטיים: איך אבני הבניין משתפות פעולה עם משתמשים ועם מערכות שכנות?

• תפעול וניהול: הפעלה, אתחול, עצירה

• תרחישי שגיאה וחריגים

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

מוטיבציה

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

צורה

יש סימונים רבים לתיאור תרחישים, למשל

• רשימה ממוספרת של צעדים (בשפה טבעית)

• תרשימי פעילות או תרשימי זרימה

• תרשימי רצף

• BPMN או EPC (שרשראות תהליכי אירועים)

• מכונות מצבים

• וכן הלאה.

6.n תרחיש זמן ריצה n (1, 2, 3 וכן הלאה)

הוסיפו תרשים זמן ריצה או תיאור טקסטואלי של התרחיש.

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

7. מבט פריסה

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

תוכן

מבט הפריסה מתאר:

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

• את המיפוי של אבני בניין (תוכנה) לרכיבי התשתית האלה.

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

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

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

מוטיבציה

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

צורה

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

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

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

7.1 תשתית רמה 1

תארו (בדרך כלל בשילוב של תרשימים, טבלאות וטקסט):

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

• הצדקה או מוטיבציה חשובה למבנה הפריסה הזה

• תכונות איכות ו/או ביצועים של התשתית

• את המיפוי של תוצרי תוכנה (אבני בניין) לרכיבי התשתית

עבור מספר סביבות או פריסות חלופיות, העתיקו את החלק הזה של arc42 לכל הסביבות הרלוונטיות. **

7.2 תשתית רמה 2

כאן אפשר לכלול את המבנה הפנימי של (חלק מ)רכיבי התשתית מתשתית רמה 1.

אנא העתיקו את המבנה מרמה 1 לכל רכיב שנבחר.

8. מושגים חוצי-מערכת

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

תוכן

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

מוטיבציה

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

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

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

צורה

הצורה יכולה להשתנות:

• מסמכי מושגים בכל מבנה

• מימושי דוגמה, במיוחד למושגים טכניים

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

מבנה הסעיף הזה

בחרו רק את הנושאים הדרושים ביותר למערכת שלכם והקצו לכל אחד כותרת ברמה 2 בסעיף הזה (למשל 8.1, 8.2 וכן הלאה).

• אל תנסו לכסות את כל הנושאים שבתרשים שהוזכר לעיל.

רקע

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

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

9. החלטות ארכיטקטוניות

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

תוכן

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

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

מוטיבציה

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

צורה

• ADR (רשומת החלטה ארכיטקטונית) לכל החלטה חשובה

• רשימה או טבלה, מסודרות לפי חשיבות והשלכות, או

• בפירוט רב יותר בצורת סעיפים נפרדים לכל החלטה

רקע (על ADR)

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

• יודעים על ההחלטה, כי היא גלויה למשל בקוד המקור, אבל

• חסרה להם המוטיבציה שמאחורי ההחלטה הזו (ראו Nygard 2011)

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

ההצעה שלנו בנוגע להחלטות

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

10. דרישות איכות

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

תוכן

הסעיף הזה מכיל את כל דרישות האיכות הרלוונטיות.

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

מוטיבציה

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

מידע נוסף

ראו את מודל האיכות הנרחב Q42 ב-https://quality.arc42.org.

10.1 סקירת דרישות איכות

תוכן

סקירה או סיכום של דרישות איכות.

מוטיבציה

לעיתים קרובות אנו נתקלים בעשרות (ואפילו מאות) דרישות איכות מפורטות. בסעיף הסקירה הזה כדאי לנסות לסכם, למשל על ידי תיאור קטגוריות או נושאים (כפי שמציעים ISO 25010:2023 או Q42

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

צורה

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

בספרות תואר גם הרעיון של עץ תכונות איכות, שמציב את המונח הכללי "איכות" כשורש ומשתמש בחידוד דמוי עץ של המונח "איכות". [Bass+21] הציגו לשם כך את המונח "עץ תועלת של תכונות איכות".

10.2 תרחישי איכות

תוכן

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

שני סוגי תרחישים שימושיים במיוחד:

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

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

צורה

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

בצורה קצרה (המועדפת במודל Q42):

• הקשר/רקע: איזה סוג מערכת או רכיב, מהי הסביבה או המצב?

• מקור/גירוי: מי או מה יוזם או מפעיל התנהגות, תגובה או פעולה.

• מדד/קריטריון קבלה: תגובה הכוללת מידה או מדד

הצורה הארוכה של תרחישים (המועדפת על ה-SEI ועל [Bass+21]) מפורטת יותר וכוללת את המידע הבא:

• מזהה תרחיש: מזהה ייחודי לתרחיש.

• שם תרחיש: שם קצר ותיאורי לתרחיש.

• מקור: הישות (משתמש, מערכת או אירוע) שיוזמת את התרחיש.

• גירוי: האירוע או התנאי המפעיל שהמערכת צריכה לטפל בו.

• סביבה: ההקשר או התנאי התפעולי שבו המערכת חווה את הגירוי.

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

• תגובה: התוצאה או ההתנהגות שהמערכת מציגה בתגובה לגירוי.

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

ראו גם

מאז ינואר 2023, arc42 מספקת מודל איכות פרגמטי, שמציע לתייג דרישות איכות בהאשטגים או בתוויות כמו #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable.

11. סיכונים וחוב טכני

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

תוכן

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

מוטיבציה

"ניהול סיכונים הוא ניהול פרויקטים למבוגרים" (Tim Lister, Atlantic Systems Guild.)

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

צורה

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