דרישה (הנדסה)

מתוך ויקיפדיה, האנציקלופדיה החופשית
קפיצה אל: ניווט, חיפוש
Gnome-colors-edit-find-replace.svg יש לשכתב ערך זה. הסיבה לכך היא: ערך אנציקלופדי לא יכול להיות כתוב בנקודות. הערך הנוכחי נראה יותר כמו סיכום שיעור שערך סטודנט, מאשר כמו ערך אנציקלופדי.
אתם מוזמנים לסייע ולתקן את הבעיות, אך אנא אל תורידו את ההודעה כל עוד לא תוקן הדף. אם אתם סבורים כי אין בדף בעיה, ניתן לציין זאת בדף השיחה.

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

מטרת שלב הדרישות[עריכת קוד מקור | עריכה]

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

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

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

תכונות נדרשות של דרישות[עריכת קוד מקור | עריכה]

נכונות[עריכת קוד מקור | עריכה]

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

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

בדידות ומזוהות[עריכת קוד מקור | עריכה]

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

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

חד משמעיות[עריכת קוד מקור | עריכה]

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

שלמות[עריכת קוד מקור | עריכה]

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

עקביות[עריכת קוד מקור | עריכה]

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

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

סתירות לוגיות[עריכת קוד מקור | עריכה]

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

עקבות למקור[עריכת קוד מקור | עריכה]

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

הימנעות מתכן[עריכת קוד מקור | עריכה]

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

בדיקתיות/מדידות[עריכת קוד מקור | עריכה]

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


סוגי דרישות[עריכת קוד מקור | עריכה]

דרישות פונקציונאליות[עריכת קוד מקור | עריכה]

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

•מבנה ממשק המשתמש והתנהגותו.

•הקלטים לתוכנית.

•הפלטים שהתוכנית תוציא.

•עיבוד הנתונים: הדיוק הנדרש, התנאים בהם העיבוד יצליח.

•כיצד יש לטפל בתקלות.

•אתחול/כיבוי המערכת.

דרישות לא פונקציונליות[עריכת קוד מקור | עריכה]

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

•הסביבה הפיזית של המערכת.

•אבטחה (מערכת המשתמשים).

•ביצועים.

•עלויות.

•ניידות המערכת ועוד...

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

מסמך דרישות תוכנה[עריכת קוד מקור | עריכה]

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

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

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

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

מפרט דרישות לתוכנה[עריכת קוד מקור | עריכה]

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

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

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

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

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