https://www.yisraelpedia.com/index.php?action=history&feed=atom&title=%D7%93%D7%A8%D7%99%D7%A9%D7%94_%28%D7%94%D7%A0%D7%93%D7%A1%D7%AA_%D7%AA%D7%95%D7%9B%D7%A0%D7%94%29דרישה (הנדסת תוכנה) - היסטוריית גרסאות2026-09-15T10:02:22Zהיסטוריית הגרסאות של הדף הזה בוויקיMediaWiki 1.43.8https://www.yisraelpedia.com/index.php?title=%D7%93%D7%A8%D7%99%D7%A9%D7%94_(%D7%94%D7%A0%D7%93%D7%A1%D7%AA_%D7%AA%D7%95%D7%9B%D7%A0%D7%94)&diff=379722&oldid=previmported>לוכסן: מסד נתונים במקום "בסיס נתונים"2026-05-29T14:30:25Z<p><a href="/index.php/%D7%9E%D7%A1%D7%93_%D7%A0%D7%AA%D7%95%D7%A0%D7%99%D7%9D" title="מסד נתונים">מסד נתונים</a> במקום "בסיס נתונים"</p>
<p><b>דף חדש</b></p><div>{{הנדסת תוכנה}}<br />
'''דרישה ''' היא הגדרת מאפיין או אילוץ, מבצעי, פונקציונלי או של התכן והוא חיוני לקבלת המוצר או התהליך. דרישה שאינה כתובה לא מאפשרת בקרה ומעקב, ולכן נדרוש שהדרישות יופיעו כמשפטים שכל אחד מהם מהווה דרישה נפרדת ומוגדרת היטב. <br />
<br />
מאפיין הוא תכונה שהמערכת צריכה לאפשר, או צורת התנהגות של המערכת במצב כלשהו. אילוץ הוא הגבלה כלשהי על המערכת – עקב מצב קיים (למשל קיום [[מסד נתונים]] שעל המערכת להשתמש בו) או דרישה עתידית. דרישה מבצעית משפיעה על אופן פעולת התוכנה. דרישה פונקציונלית משפיעה על יכולות התוכנה ודרישת תכן משפיעה על אופן מימוש התוכנה. <br />
<br />
==מטרת שלב הדרישות==<br />
מטרת שלב הדרישות הוא יצירת תשתית למפרט התוכנה על פי צורכי הלקוח כגון הגדרת צורכי הלקוח והמשתמשים, הגדרת יכולות המוצר והתנאים בהם הוא נדרש לעמוד, הקצאת דרישות המערכת לתוכנה והבנה משותפת בין הלקוח למפתח.<br />
<br />
סט הדרישות מאפשר יצירת בסיס לניהול ולמעקב אחרי הפיתוח (מטריצת מעקב דרישות) ויצירת בסיס לבדיקת המוצר ואיכותו.<br />
<br />
בשלב הדרישות, בניגוד לשלב התכן, אנו אומרים מה התוכנה צריכה לעשות, ולא איך היא תעשה את זה. <br />
<br />
==תכונות נדרשות של דרישות==<br />
'''נכונות''': כל דרישה צריכה לייצג את הפונקציונליות הנדרשת עבור המערכת. <br />
<br />
לדוגמה - דרישה "לכל משתמש יהיה מספר ID ייחודי". במידה ונרצה להגביל את תחום הID הניתן - יש לנסח את הדרישה בצורה מדויקת יותר: "לכל משתמש יהיה מספר ID יחחודי מהתחום [1000-3000]".<br />
<br />
'''בדידות ומזוהות''': צריכה להיות אפשרות לקרוא כל דרישה באופן עצמאי. וכן זיהוי ייחודי וחד-ערכי של כל דרישה. הזיהוי נשמר לאורך כל מחזור החיים, גם אם הדרישה מבוטלת.<br />
<br />
כמו כן על דרישה להיות ניתנת לפירוש בדרך אחת בלבד. כל דרישה צריכה להיות קצרה, מפורשת וברורה. יש להשתמש במילון מלווה כאשר אנו משתמשים בביטוי שיכולים להיות לו מספר משמעויות.<br />
<br />
הדרישות צריכות לכסות בצורה מוגדרת היטב את כל היבטי התוכנה, יש להיזהר מ- (TBD (to be defined.<br />
<br />
יש למנוע מהגדרת דרישות הסותרות זו את זו. ישנם מספר סוגי סתירות נפוצות:<br />
# ביטויים שונים מציינים את אותו האובייקט.<br />
# מאפיינים שונים לאותו אובייקט. למשל פעם אחת מתייחסים לשדה כמכיל [[מספר שלם]] ובמקום אחר כמחרוזת.<br />
כן יש להימנע מסתירות לוגיות. למשל במקום אחד בדרישות כתוב כי A גורר את B ובמקום אחר כתוב שהם קורים בו זמנית.<br />
<br />
'''מלאות''': סט הדרישות צריך להכיל את כל המיקרים האפשריים. לדוגמה, אם ישנה דרישה האומרת: "במקרה והטמפרטורה עולה על ערך המוגדר במבנה הנתונים, יש...", צריכה להיות דרישה המגדירה מה קורה כאשר הטמפרטורה אינה עולה על אותו ערך.<br />
<br />
יש לזהות את מקורה של כל דרישה: דרישה מפורשת או דרישה נגזרת.<br />
<br />
יש לוודא שאילוצי/הנחיות התכן מהווים צורך אמיתי.<br />
<br />
כן נדרשת קביעה מפורשת כיצד יהיה ניתן להוכיח את העמידה בדרישה, בדרך שתיקח זמן סופי ותהיה יעילה מבחינה כספית. על כל הדרישות להיות מובנות הן על ידי הלקוח והן על ידי המפתחים.<br />
<br />
==סוגי דרישות==<br />
<br />
===דרישות פונקציונליות=== <br />
<br />
מתארת פונקציות יסודיות של המערכת ושירותי מערכת שהמשתמש מצפה שיתבצעו על ידי המערכת. <br />
* מבנה מנשק (ממשק) המשתמש והתנהגותו. <br />
* הקלטים לתוכנית. <br />
* הפלטים שהתוכנית תוציא.<br />
* עיבוד הנתונים: הדיוק הנדרש, התנאים בהם העיבוד יצליח.<br />
* כיצד יש לטפל בתקלות.<br />
* אתחול/כיבוי המערכת.<br />
<br />
===דרישות לא פונקציונליות===<br />
<br />
אילוצים על המערכת: אמינות, ניידות, בטיחות, ביצועים ועוד:<br />
<br />
* הסביבה הפיזית של המערכת. <br />
* אבטחה (מערכת המשתמשים). <br />
* ביצועים. <br />
* עלויות. <br />
* ניידות המערכת ועוד. <br />
<br />
לשני מוצרים יכולים להיות בדיוק אותה פונקציונליות אולם המאפיינים של כל אחת יכולים ליצור שני מוצרים שונים לגמרי. דרישות לא פונקציונליות קשות יותר לבדיקה מדרישות פונקציונליות. למשל דרישות לא פונקציונליות ההכרחיות לכל מוצר הן "מהירות", "בטיחות" ו-"ניתן לאחזקה". קשה להגדיר כיצד יש לבדוק האם המוצר עומד בהן.<br />
<br />
==מסמך דרישות תוכנה==<br />
"מסמך דרישות תוכנה" מציג את אוסף הדרישות המוגדרות מהתוכנה לגבי המשימה שעליה לבצע. מוגדרות בו הבעיות שהתוכנה תיתן פתרון עבורן. לאחר כתיבת התוכנה, המסמך יאפשר לבדוק האם התכן הוא טוב. אם התכן ממלא את כל הדרישות אזי הוא פתרון קביל לבעיה. <br />
<br />
מסמך דרישות ניתן לשינוי אם המבנה והסגנון שלו הם כאלו ששינויים יכולים להיעשות בקלות. על המסמך להכיל [[תוכן עניינים]], [[מפתח העניינים|אינדקס]] והתייחסויות בתוך המסמך. על כל דרישה בו להופיע במקום אחד בלבד. <br />
<br />
מסמך דרישות ניתן למעקב אם כל דרישה בו נמצאת בפסקה ממוספרת נפרדת, כך שניתן להתייחס לדרישה זו במסמכים אחרים:<br />
* מעקב לאחור: אנו יודעים מדוע כל דרישה קיימת. כל דרישה מספקת התייחסות למקורה (הנמצא במסמכים או במקורות קודמים). <br />
* מעקב קדימה: כל מסמך בעתיד יוכל להתייחס לכל אחת מהדרישות במסמך.<br />
<br />
===מפרט דרישות תוכנה===<br />
{{הפניה לערך מורחב|SRS}}<br />
מפרט דרישות תוכנה או Software Requirements Specification (בקיצור: SRS) הוא מסמך פורמלי ראשוני שבו מתוארות ומפורטות הדרישות של המערכת המתוכננת, זהו תיאור מלא של ההתנהגות הרצויה המערכת שתפותח.<br />
<br />
המסמך כולל מספר [[תרחיש שימוש|תרחישי שימוש]] (use case) - הגדרות כלליות של המערכת שמתארות את כל פעולות הגומלין של המשתמשים עם התוכנה.<br />
<br />
המסמך יכלול הגדרת הדרישות הבאות: <br />
* ממשקים חיצוניים של המערכת. זיהוי המידע שעתיד לזרום אל המערכת ומתוכה.<br />
* דרישות פונקציונליות ולא פונקציונליות מהמערכת<br />
* אילוצי עיצוב<br />
<br />
לאחר כתיבת מפרט הדרישות לתוכנה, יבוא שלב [[מפרט תיכון תוכנה]].<br />
<br />
==ראו גם==<br />
* [[אפיון מערכת מידע]]<br />
* [[SRS]] (מפרט דרישות תוכנה)<br />
<br />
[[קטגוריה:הנדסת תוכנה]]</div>imported>לוכסן