הפקת שלב הדרישות של תהליך פיתוח התוכנה הוא מפרטי דרישות תוכנה (SRS) (נקרא גם א מסמך דרישות ). דוח זה מניח בסיס לפעילויות הנדסת תוכנה והוא נבנה כאשר דרישות שלמות מתקבלות ומנתחות. SRS הוא דוח רשמי, שפועל כייצוג של תוכנה המאפשרת ללקוחות לבדוק האם היא (SRS) בהתאם לדרישותיהם. כמו כן, הוא כולל דרישות משתמש עבור מערכת וכן מפרטים מפורטים של דרישות המערכת.
ה-SRS הוא מפרט עבור מוצר תוכנה, תוכנית או סט של יישומים ספציפיים המבצעים פונקציות מסוימות בסביבה ספציפית. זה משרת כמה מטרות תלוי מי כותב את זה. ראשית, ה-SRS יכול להיכתב על ידי הלקוח של מערכת. שנית, ה-SRS יכול להיכתב על ידי מפתח המערכת. שתי השיטות יוצרות מצבים שונים לחלוטין ומבססות מטרות שונות למסמך לחלוטין. המקרה הראשון, SRS, משמש להגדרת הצרכים והציפיות של המשתמשים. המקרה השני, SRS, נכתב למטרות שונות ומשמש כמסמך חוזה בין לקוח ליזם.
מאפיינים של SRS טוב
להלן התכונות של מסמך SRS טוב:
1. נכונות: סקירת משתמשים משמשת כדי לספק את הדיוק של הדרישות המצוינות ב-SRS. אומרים ש-SRS מושלם אם הוא מכסה את כל הצרכים הצפויים באמת מהמערכת.
2. שלמות: ה-SRS מלא אם ורק אם הוא כולל את האלמנטים הבאים:
(1). כל הדרישות החיוניות, בין אם נוגעות לפונקציונליות, ביצועים, עיצוב, אילוצים, תכונות או ממשקים חיצוניים.
תכונות java8
(2). הגדרת התגובות של התוכנה לכל סוגי נתוני הקלט הניתנים למימוש בכל הקטגוריות הזמינות של המצבים.
הערה: חיוני לציין את התגובות לערכים חוקיים ולא חוקיים כאחד.
(3). תוויות והפניות מלאות לכל האיורים, הטבלאות והדיאגרמות ב-SRS והגדרות של כל המונחים ויחידות המידה.
3. עקביות: ה-SRS עקבי אם, ורק אם, אין תת-קבוצה של דרישות בודדות המתוארות בהתנגשות שלו. ישנם שלושה סוגים של קונפליקט אפשרי ב-SRS:
(1). המאפיינים שצוינו של אובייקטים בעולם האמיתי עלולים להתנגש. לדוגמה,
(א) ניתן לתאר את הפורמט של דוח פלט בדרישה אחת כטבלאית אך באחרת כטקסטואלית.
(ב) תנאי אחד יכול לקבוע שכל האורות יהיו ירוקים ואילו אחר קובע שכל האורות יהיו כחולים.
(2). ייתכן שיש התנגשות סבירה או זמנית בין שתי הפעולות שצוינו. לדוגמה,
(א) דרישה אחת עשויה לקבוע שהתוכנית תוסיף שני תשומות, ואחרת עשויה לקבוע שהתוכנית תכפיל אותם.
(ב) תנאי אחד יכול לקבוע ש-'A' חייב תמיד אחרי 'B', בעוד שתנאי אחר מחייב ש-'A ו-B' מתקיימים במקביל.
(3). שתי דרישות או יותר עשויות להגדיר את אותו אובייקט בעולם האמיתי אך להשתמש במונחים שונים עבור אותו אובייקט. לדוגמה, בקשת תוכנית לקלט משתמש יכולה להיקרא 'הנחיה' בדרישה אחת ו'רמז' באחרת. השימוש בטרמינולוגיה ובתיאורים סטנדרטיים מקדם עקביות.
4. חד משמעיות: SRS הוא חד משמעי כאשר לכל דרישה קבועה יש רק פרשנות אחת. זה מצביע על כך שכל אלמנט מתפרש באופן ייחודי. במקרה שיש שיטה בשימוש עם מספר הגדרות, דוח הדרישות צריך לקבוע את ההשלכות ב-SRS כך שיהיה ברור ופשוט להבנה.
5. דירוג לחשיבות ויציבות: ה-SRS מדורג לפי חשיבות ויציבות אם לכל דרישה בו יש מזהה המציין את המשמעות או היציבות של הדרישה הספציפית הזו.
בדרך כלל, כל הדרישות אינן חשובות באותה מידה. תנאים מוקדמים מסוימים עשויים להיות חיוניים, במיוחד עבור יישומים קריטיים לחיים, בעוד שאחרים עשויים להיות רצויים. יש לזהות כל מרכיב כדי להפוך את ההבדלים הללו לברורים ומפורשים. דרך נוספת לדרג דרישות היא להבחין בין מחלקות של פריטים כחיוניים, מותנים ואופציונליים.
6. אפשרות לשינוי: SRS צריך להיות ניתן לשינוי ככל האפשר וצריך להיות מסוגל להשיג במהירות שינויים במערכת במידה מסוימת. שינויים צריכים להיות מודפסים בצורה מושלמת והצלבה.
7. אימות: SRS נכון כאשר ניתן לאמת את הדרישות שצוינו עם מערכת חסכונית כדי לבדוק אם התוכנה הסופית עומדת בדרישות אלו. הדרישות מאומתות בעזרת ביקורות.
8. עקיבות: ניתן לעקוב אחר ה-SRS אם המקור של כל אחת מהדרישות ברור ואם הוא מקל על ההתייחסות של כל מצב בתיעוד פיתוח או שיפור עתידי.
ישנם שני סוגים של עקיבות:
aws היסט לאדום
1. מעקב אחורה: הדבר תלוי בכך שכל דרישה מפנה במפורש למקור שלה במסמכים קודמים.
2. מעקב קדימה: הדבר תלוי בכך שלכל רכיב ב-SRS יש שם ייחודי או מספר סימוכין.
המעקב קדימה של ה-SRS הוא קריטי במיוחד כאשר מוצר התוכנה נכנס לשלב התפעול והתחזוקה. כאשר הקוד ומסמך העיצוב משתנים, יש צורך להיות מסוגל לוודא את סט הדרישות המלא שעשויות להיות מודאגות משינויים אלה.
9. עצמאות עיצובית: צריכה להיות אפשרות לבחור מבין חלופות עיצוב מרובות עבור המערכת הסופית. ליתר דיוק, ה-SRS לא אמור להכיל כל פרטי יישום.
10. יכולת בדיקה: יש לכתוב SRS בשיטה כזו שפשוט להפיק מקרי בדיקה ותוכניות בדיקה מהדוח.
11. מובן ללקוח: משתמש קצה עשוי להיות מומחה בתחום המפורש שלו, אך ייתכן שאינו מיומן במדעי המחשב. לפיכך, יש להימנע ככל האפשר מהמטרה של סימונים וסמלים פורמליים. יש לשמור על השפה פשוטה וברורה.
12. רמת ההפשטה הנכונה: אם ה-SRS נכתב לשלב הדרישות, יש להסביר את הפרטים במפורש. בעוד שלמחקר היתכנות, ניתן להשתמש בפחות ניתוחים. לפיכך, רמת ההפשטה משתנה בהתאם למטרת ה- SRS.
מאפיינים של מסמך SRS טוב
המאפיינים החיוניים של מסמך SRS טוב הם הבאים:
תַמצִיתִי: דוח ה-SRS צריך להיות תמציתי ובו בזמן, חד משמעי, עקבי ומלא. תיאורים מלאים ולא רלוונטיים מפחיתים את הקריאות וגם מגדילים את אפשרויות השגיאות.
מובנה: זה צריך להיות מובנה היטב. מסמך מובנה היטב הוא פשוט להבנה ולשינוי. בפועל, מסמך SRS עובר מספר תיקונים כדי לעמוד בדרישות המשתמש. לעתים קרובות, דרישות המשתמש מתפתחות לאורך זמן. לכן, כדי להקל על השינויים במסמך ה-SRS, חיוני להפוך את הדוח מובנה היטב.
תכנות struct array c
תצוגת קופסה שחורה: זה צריך רק להגדיר מה המערכת צריכה לעשות ולהימנע מלציין כיצד לעשות זאת. המשמעות היא שמסמך ה-SRS צריך להגדיר את ההתנהגות החיצונית של המערכת ולא לדון בבעיות היישום. דוח ה-SRS צריך לראות את המערכת המפותחת כקופסה שחורה וצריך להגדיר את ההתנהגות הנראית כלפי חוץ של המערכת. מסיבה זו, דוח SRS ידוע גם כמפרט הקופסה השחורה של מערכת.
שלמות קונספטואלית: זה צריך להראות שלמות מושגית כך שהקורא יוכל רק להבין אותה. תגובה לאירועים לא רצויים: עליה לאפיין תגובות מקובלות לאירועים לא רצויים. אלה נקראים תגובת מערכת לתנאים חריגים.
ניתן לאימות: כל דרישות המערכת, כפי שמתועדות במסמך SRS, צריכות להיות נכונות. המשמעות היא שצריך להיות אפשרי להחליט אם התקיימו דרישות ביישום או לא.