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 (Business Requirement Specification).

BRS - Business Requirement Specification

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

 

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

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

לקוח: אני רוצה שתהיה ההרשמה לאתר (דרישת הלקוח)

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

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

תרגום ל-BRS:

1. ניתן יהיה להירשם לאתר גם באמצעות מכשירים ניידים וגם ממחשבים נייחים – BR1.
2. במהלך ההרשמה, יש לאמת את כתובת הדואר האלקטרוני באמצעות שליחת קישור לאישור – BR2.
3. המערכת תספק אפשרות להירשם באמצעות חשבונות רשתות חברתית כמו Facebook ו-Google. דרישה BR3!

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

• • זמן טעינה לא יעלה על 1.25 שניות – BR4

Hardware Specification:

• • • האתר חייב להיות זמין באנדרואיד גרסה 12 ומעלה – HS1.
    • האתר אמור לעבוד תקין בכל רזולוציה – HS2.

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

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

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

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

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

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

 

לדוגמה: