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

SDLC: יזום והנדסת דרישות

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

תפקידים

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

שלבי פיתוח מערכת

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

יזום פרויקט

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

בדיקת ישימות

• האם יש קשיים / מגבלות בתכנון היישום?
• האם יש טכנולוגיות חדשות?
• האם יש קשיים במימוש המערכת?
• האם יש בעיות היתכנות ברכיבים מסוימים?
• האם קיימים קשיים בהטמעת המערכת?

שיטות לשערוך עלויות

• Analogous Estimating: השוואה לפרוייקטים קודמים דומים.
• Bottom-up Estimating: סכום עלויות של כל רכיבים בנפרד.
• Parametric Estimating: שימוש במודל מתמטי.
• Three-point Estimates: האומדן אופטימלי, ריאליסטי והרעה.

מהנדס מערכת

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

פעולות בשלב הייזום

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

מודל SMART

• Specific: יעדים ממוקדים.
• Measurable : יעדים ניתנים למדידה.
• Attainable : יעדים ריאליים ובר ביצוע.
• Relevant : יעדים תואמים לאסטרטגיה.
• Time-bound: יעדים בתחומי זמן.

פעולות בשלב יזום (המשך)

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

בדיקת ישימות המשך

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

אומדן עלויות

• שיטות אומדן עלויות: Analogous, Bottom-up, Parametric, Three-point estimates.

עקומת Boehm

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

הניסוי של IBM

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

דרישות ובעלי עניין

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

איסוף דרישות

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

שיטות לאיסוף דרישות

• ראיונות ושאלונים.
• סיעור מוחות.
• יצירת демо וכן ניתוח מערכות קיימות.
• ניתוח מסמכים/ממשקים.
• סדנאות לדרישות.
• עבודות עיצוב/פרוטוטיפים.

מדוע מגוון שיטות?

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

עודף דרישות ותעדוף דרישות

• צמצום הדרישות למחויבים.
• כל דרישה עולה כסף וסיכונים.
• מודלים רבים לתעדוף דרישות.

מודל Kano

• שביעות רצון משתמשים vs. עלויות פיתוח.
• סוגים שונים של דרישות (בבסיס/עליהם/לא חיוניים).

MOSCOW

• תוך חלוקה של דרישות (חייבים, רצוי, יכול להיות, לא בשלב זה).

סיווג דרישות - משתמש vs. מערכת

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

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

• Functional Requirements (FR): תיאור מה עושה המערכת מנקודת מבט המשתמש.
• Non-Functional Requirements (NFR): תכונות נוספות של הפיתוח.
• אילוצים כמו: זמני תגובה, נפח/פעילות. אמינות, אבטחת מידע, ממשק משתמש.

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

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

סיווג דרישות תפעוליות vs. מידע

• Operational Requirement (OR) : התנהגות המערכת בהקשר של האינטראקציה שלה עם המשתמש.
• Data Requirement (DR): הדרישות של המערכת בקשר עם המידע.
• דוגמה: כיצד המערכת מטפלת בנתונים - איסוף, אחסון, אחזור.

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

• עמידה בזמני תגובה, נפח פעילות, 
• עמידות בפני עומס, אמינות, אבטחה.
• דוגמה: זמן תגובה של עד 30 שניות להזמנה.

תבניות תיעוד דרישות

• Requirements List: רשימת דרישות.
• Use Cases: דוגמאות לשימושים במערכת.
• Product Requirements Document (PRD): תיאור הפיצ'רים מהצד של המשתמש.
• Functional Requirements Document (FRD): תיאור הפיצ'רים מהצד של המפתח.
• Software Requirements Document / Specification (SRS): תיאור פונקציונלי מלא של המערכת.

איכות דרישות

• Identified : ברור ומייחד.
• Understandable : ברור ומובן.
• Unambiguous : חד משמעי.
• Complete : שלם.
• Necessary : הכרחי.
• Consistent : עקבי.
• Verifiable : ניתן לבדיקה.
• Traceable : ניתן לעקוב.
• Prioritized : ממוינים לפי עדיפות.

Use Case

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