מחזור פיתוח תוכנה – דרישות ותכנון

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

לדוגמה:

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

  1. הרשמה לאתר.
  2. כניסה/יציאה.
  3. אזור אישי של המשתמש.
  4.  עלות ההחזקה של האתר בחודש לא תהיה יותר מ-1000$.

SDLC:

Requirements & Analysis(SRS doc.) => Design => Coding=> Test => Deployment & Maintenance

STLC:

Requirements & Analysis(STP doc.) => Design (STD doc) => Unit Test by Developers=> Test (STR doc) => Deployment & Maintenance

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

BRS - Business Requirement Specification

למעשה BRS זה:

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

 דוגמה של תרגום דרישות הלקוח למסמך דרישות BRS:

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

  1. הרשמה לאתר (דרישת הלקוח)
    תרגום דרישות הלקוח למסמך דרישות BRS:
    * ניתן יהיה להירשם לאתר מ-mobile וגם ממחשבים נייחים – BR1
    * עלות מנוי לאחר הרשמה ראשונה, תהיה למשך 30 ימים ראשונים חינם – BR2
    * ….
  2. אזור אישי של המשתמש הנרשם (דרישת הלקוח)
    תרגום דרישות הלקוח למסמך דרישות BRS:
    * עמוד ה-WELCOME למשתמש רשום BR3
    * אופציות לשינוי פרטים אישיים BR4
    * הוספת נתונים של ניהול פיננסי BR5
    * שליחת הודעות אישיות למשתמשים אחרים BR6
    * ….

דרישות לא פונקציונליות:
תרגום דרישות הלקוח למסמך דרישות BRS:
* אתר חייב להיות SSL מאובטח BR7
* זמן טעינה של האתר לא יעלה מעבר ל-1.25 מילי שניות BR8
* עלות השרת וכל הוצאות עבור פרסומות/קידום לא יעלו מעבר ל-1K$ בחודש וזמן הפיתוח חייב להיות עד שנה אחת BR9
*…

Hardware Specification
תרגום דרישות הלקוח למסמך דרישות BRS:

* אתר חייב להיות זמין באנדרואיד  מעל גרסה 4 HS1
* אתר אמור לעבוד תקין בכל רזולוציה HS2

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

מחזור פיתוח תוכנה – שלב של ניתוח

Analysis Requirements phase

בשלב הזה של מחזור פיתוח תוכנה מנתח עסקי, מפתחים ומנהל המוצר נפגשים לצורך דיון איזו טכנולוגיות יהיו בשימוש, כלומר מה הדרישות הטכניות (ללא פירוט) נדרשות על מנת לממש את הדרישות עסקיות אשר במסמך BRS, … כך נוצר מסמך: SRS

SRS - Software Requirements Specification

בשלב של ניתוח – Analysis – נוצר מסמך SRS שבו יש דרישות טכניות בהתאם לדרישות עסקיות שבמסמך BRS, אבל ללא פירוט הקוד – אלה רק איזו טכנולוגיות יהיו בשימוש ומה אפשרי ולא אפשרי לממש מנקודת המבט הטכני.

למעשה מסמך SRS זה פירוט יותר עמוק של המסמך BRS.

במסמך SRS יש:

  • תיאור Software פונקציונלי ולא פונקציונלי
  • תיאור Hardware איזו מערכות יהיו בשימוש סביב ה-Software
  • תיאור User Interface תוך שימוש בדיאגרמות כגון:

 מסמך SRS מורכב משני תת מסמכים:

  • FRS – Functional Requirement Specification
    – תיאור פונקציונלי של המערכת שיש לממש.
  • SRS – System Requirement Specification
    – תיאור של Software ו-Hardware של המערכת שיהיו בשימוש.

Planning phase
תכנון בדיקות

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

למעשה בשלב הזה נוצר מסמך תכנון בדיקות STP.

לדוגמה:

דילוג לתוכן