דרישות פונקציונליות לעומת דרישות לא פונקציונליות: מה שכל מהנדס צריך לדעת

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

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

מה הן דרישות פונקציונליות?

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

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

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

מאפיינים מרכזיים של דרישות פונקציונליות

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

• (ב) ⁇ :0) ,[דרוש מקור]: הם מתארים התנהגויות מדויקות ותפקודים שהמערכת חייבת לבצע
• (ב) ניתן לאמת את כל דרישותיו באמצעות בדיקות כדי לאשר את יישום
• (FLT:0User-Focusing: 1) הם מתייחסים ישירות לצרכים של משתמשים ולמטרות עסקיות
• (ב) ,0) ,מוכיחים מה המערכת עושה בתגובה לקלטים
• (ב) [ה]הסברים: [ה]] [ה]] [ה]] הם הגדירו תוצאות שניתן למדוד, כגון כניסה מוצלחת עם אישורים תקפים.

דרישות פונקציונליות

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

כללי עסקים ולוגיקה

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

User Authentication and Authorization

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

דרישות ניהול נתונים

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

דרישות User Interface

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

דרישות עסקיות ועיבוד

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

דוגמאות לתפקוד

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

E-Commerce Application דוגמאות

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

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

מערכות בנקאיות ופיננסיות

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

מערכות ניהול בריאות

• המערכת חייבת לאפשר לספקי שירותי בריאות לקבוע פגישות של המטופל
• צוות רפואי חייב להיות מסוגל לגשת ולעדכן רשומות רפואיות של המטופל
• הבקשה חייבת לאפשר ניהול מרשם ובקשות fill
• המערכת חייבת ליצור תזכורות למינוי אוטומטיות באמצעות דואר אלקטרוני ו- SMS
• ספקי שירותי הבריאות חייבים להיות מסוגלים להציג תוצאות בדיקות המטופל ודיווחים אבחון
• המערכת חייבת לתמוך באינטגרציה של בריאות אלקטרונית (EHR) עם מערכות חיצוניות

ניהול תוכן ומדיה חברתית

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

תכנון משאבים ארגוני (ERP) Systems

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

דוגמאות ליישומים ניידים

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

What Areדרישות לא Functional?(IFLT:0) הנדסת מערכות ודרישות הנדסה, דרישה לא פונקציונלית (NFR) היא דרישה כי קריטריונים שניתן להשתמש בהם כדי לשפוט את פעולת המערכת, ולא התנהגויות ספציפיות. הם מנוגדים לדרישות פונקציונליות המגדירות התנהגות או פונקציות ספציפיות.

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

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

הבנת החשיבות של דרישות לא מצחיקות

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

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

סוגים של דרישות לא מצחיקות

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

דרישות ביצועים

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

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

• זמן תגובה: 1 (FLT) הזמן המקסימלי המותר למערכת להגיב לבקשות משתמשים
• (ב) ,0.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10
• (ב) ⁇ :0) מקורות השימוש: 1FLT:1 CPU, זיכרון וצריכת רוחב פס תחת תנאי עומס שונים
• (FLT:0) משתמשים במקביל: מספר המשתמשים בו-זמנית המערכת יכולה לתמוך
• (ב) [15] זמן רב: 1 (ב) כמה מהר דפים, מסכים או עומס נתונים עבור משתמשים

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

דרישות אבטחה

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

דרישות אבטחה כוללות:

• (ב) ◄ [13] ,[[1924]]
• (ב) ⁇ :0) מנגנוני בקרת גישה ומנגנוני בקרה ורמות הרשאה
• (ב) טבלה:0) מוצפנת נתונים: 1FLT: הגנה על נתונים במעבר ומנוחה
• (ב) ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
• [ה] הגנה מפני אלימות: [ה]: [ה] [ה]] [ההגנה] על איומים ביטחוניים משותפים
• (FLT:0) פרטיות נתונים: ההרחבה 1 (FLT:1) , Compliance with Privacyתקנות הפרטיות ותקני הגנת נתונים

דוגמה: יש להזין נתונים גם במעבר באמצעות TLS 1.3 ומנוחה באמצעות תקני הצפנה AES-256.

דרישות שימושיות

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

כתובת דרישות שימושיות:

• (FLT:0) למידה: חיקוי 1 (כמה מהר משתמשים חדשים יכולים להיות פרודוקטיביים עם המערכת
• (ב) [15]: כיצד משתמשים מנוסים יכולים להשיג משימות
• (ב) ⁇ :0) מזכרות: מספר המשתמשים יכולים לחזור למערכת לאחר תקופה של שימוש לא
• (FLT:0) מניעת פלאר: תכונות עיצוב של 1FLT למנוע שגיאות משתמש
• (ב) ⁇ : ⁇ : ⁇ : כמה נעים ומספקים את המערכת
• (FLT:0) גישה: תמיכה עבור משתמשים עם מוגבלויות וצרכים מגוונים

דוגמה: משתמשים חדשים חייבים להיות מסוגלים להשלים את העסקה הראשונה שלהם בתוך 5 דקות מבלי לדרוש עזרה חיצונית או תיעוד.

דרישות אמינות וזמינות

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

שיקולים מרכזיים כוללים:

• (ב) ,0) , Uptime:BuildFLT:1 ,% מהזמן המערכת היא מבצעית וגישה
• (הופנה מהדף 0) זמן בין כשלים (MTBF): זמן ממוצע בין כשלי מערכת
• (FLT:0) מעת לעת לתיקון (MTTR): זמן ממוצע נדרש לשחזר פונקציונליות מערכת
• (הופנה מהדף 1) יכולתו של מערכת 1:1 להמשיך לפעול למרות כשלים של רכיב
• (ב) ◄ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇

דוגמה: המערכת חייבת להיות זמינה 99.9% מהזמן, למעט חלונות תחזוקה מתוכננים, המתורגמים לא יותר מ-8.76 שעות של שעות השבתה בשנה.

דרישות סקלאה

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

• (ב) ⁇ (ב"ה) ,0) ,"הההבאה" (ב) "הספקות להוסיף שרתים או צמתים נוספים להפצת עומס"
• (ב) ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
• (ב) ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
• (ב) ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇

דוגמה: המערכת צריכה להיות מסוגלת להתמודד עם 20 מיליון משתמשים ללא הידרדרות בביצועים.

דרישות שמירה

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

שמירה כוללת:

• איכות קוד:0 (ראו:0) תקנים לקראת קוד, תיעוד ומבנה
• (ב) ⁇ :0) , ⁇ : ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
• (ב) ⁇ :0) , ⁇ (ה) , ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
• (ב) ⁇ :0) יכולת שינוי התנהגות מערכת ללא שינוי קוד
• (ב) ,0) ,הסבר: 1 (ה) , 1) , ←

דרישות סודיות ותקנות התפטרות

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

דרישות תאימות משתנות על ידי התעשייה ותחומי השיפוט, אך לרוב כוללות:

• שער עיבוד התשלום חייב להיות PCI DSS תואם
• התוכנה הקלינית חייבת לציית לחוק ה-HIPAA (ביטוח הבריאות וחשבונאות) ול-GDPR (תקנה כללית להגנה על נתונים)
• מרכזי נתונים בענן חייבים לציית להסמכת אבטחה ISO 27001
• מערכות צריכות לעמוד בסטנדרטים ספציפיים בתעשייה כגון SOC 2, FISMA, או תקנות ה- FDA
• יכולות כניסה ודיווח של ביקורת לציות רגולטוריות

דרישות תאימות והתאמה

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

• (FLT:0)Platform Compatibility: מערכות הפעלה ומכשירים שהמערכת חייבת לתמוך
• (ב) ,0) ,Browser Compatibility: FLT:1 דפדפנים וגרסאות שיש לתמוך בהם
• (ב) ◄ סטנדרטים ופרוטוקולים לשילוב מערכת
• (FLT:0) Data Format Compatibility: תמיכה בתבניות נתונים שונות וסטנדרטים
• אינטגרציית מערכת:0Legacy System: FLT:1ua to work with הקיים Systems

דוגמה: תוכנית הפעלה ב- Windows 10 חייבת להיות מסוגלת לפעול על Windows 11 ללא שינוי בהתנהגותו וביצועיו.

דרישות יכולות

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

• (ב) קיבולת:0) כמות המידע שהמערכת חייבת לאחסן
• (FLT:0User Capacity: FigFLT:1) מספר מקסימלי של משתמשים רשומים ונוכחיים
• (ב) כרך ה-FLT:0) מספר עסקאות מעובדות לתקופה
• (ב) ,0) ,Bandwidth: FLT:1roved Data transfer דרישות

דוגמה: דפי האתר צריכים לטעון בשלוש שניות עם המספר הכולל של משתמשים בו זמנית ונעליים; 5 אלף.

השוואה מפורטת: פונקציונליות לעומת דרישות לא מצחיקות

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

הגדרה והתמקדות

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

סגנון מסמכים

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

בדיקה > Access

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

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

השפעה על הצלחה בפרויקט

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

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

אתגרים עדיפויות

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

מדוע שתי הדרישות הן קריטיות להצלחה של הפרויקט

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

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

המונחים: Clarity and Direction

Having clearly defined functional requirements reduces the risk of miscommunication between stakeholders and your development team. This w