דרישה (הנדסת תוכנה)

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

מטרת שלב הדרישות

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

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

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

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

נכונות

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

נניח שהבעיה מגדירה שה-ID של כל משתמש במערכת הוא מהתחום [1000-3000] ואילו במסמך הדרישות מופיעה הדרישה המתאימה: לכל משתמש יש מספר ID.

בדידות ומזוהות

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

חד משמעיות

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

שלמות

על הדרישות לכסות בצורה מוגדרת היטב את כל היבטי התוכנה, יש להיזהר מ- (TBD (to be defined.

עקביות

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

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

סתירות לוגיות

למשל במקום אחד בדרישות כתוב כי A גורר את B ובמקום אחר כתוב שהם קורים בו זמנית.

עקבות למקור

יש לזהות את מקורה של כל דרישה: דרישה מפורשת או דרישה נגזרת.

הימנעות מתכן

יש לוודא שאילוצי/הנחיות התכן מהווים צורך אמיתי.

בדיקתיות/מדידות

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

סוגי דרישות

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

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

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

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

אילוצים על המערכת: אמינות, ניידות, בטיחות, ביצועים ועוד:

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

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

מסמך דרישות תוכנה

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

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

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

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

מפרט דרישות תוכנה

ערך מורחב – SRS

מפרט דרישות תוכנה או Software Requirements Specification (בקיצור: SRS) הוא מסמך פורמלי ראשוני שבו מתוארות ומפורטות הדרישות של המערכת המתוכננת, זהו תיאור מלא של ההתנהגות הרצויה המערכת שתפותח.

המסמך כולל מספר תרחישי שימוש (use case) - הגדרות כלליות של המערכת שמתארות את כל פעולות הגומלין של המשתמשים עם התוכנה.

המסמך יכלול הגדרת הדרישות הבאות:

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

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

ראו גם

• אפיון מערכת מידע
• SRS (מפרט דרישות תוכנה)