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

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

‫‪ :SDLC‬יזום והנדסת‬ ‫דרישות‬  ‫בעלי עניין‬ ‫מעורב בצורה אקטיבית בפרויקט (בצורה גלויה או מאחורי הקלעים)‬ ‫ ‬ ‫בעל אינטרס חיובי‪ /‬שלילי שיכול להשפיע על ביצועי הפרויקט והשלמתו‪.‬‬ ‫ ‬ ‫מושפע מהפרויקט או בעל יכולת השפעה על הפרויקט‪ ,‬תוצריו או על‬ ‫ ‬ ‫מעורבים אחרים‪.‬‬ ‫לדוגמא‪:‬‬ ‫ ‬ ‫לקוח‬ ‫–‬ ‫משתמש‬ ‫–‬ ‫משקיע‬ ‫–‬ ‫ספק‬ ‫–‬ ‫רגולטור‬ ‫–‬ ‫גורם ניהולי בכיר‬ ‫–‬ ‫בעלי תפקידים‬ ‫מנתח מערכות‬ ‫ ‬ ‫מנהל פרויקט‬ ‫ ‬ ‫מנהל מוצר‬ ‫ ‬ ‫מהנדס מערכת‬ ‫ ‬ ‫ארכיטקט תוכנה‬ ‫ ‬ ‫ראש צוות‬ ‫ ‬ ‫תוכניתן (מהנדס תוכנה)‬ ‫ ‬ ‫בודק (מהנדס בדיקות)‬ ‫ ‬ ‫מטמיע (מהנדס שטח)‬ ‫ ‬ ‫*לאו דווקא אנשים שונים‬ ‫ייזום פרויקט‬  ‫שלבים בפיתוח מערכת‬ ‫ייזום ‪ -‬זיהוי בעיות והזדמנויות‬ ‫ ‬ ‫הגדרת דרישות ‪ -‬תיאור מדויק של הנדרש‬ ‫ ‬ ‫ניתוח ‪ -‬כיצד ניתן לפתור את הבעיות‬ ‫ ‬ ‫עיצוב ‪ -‬בחירה ותכנון הפתרון המתאים‬ ‫ ‬ ‫מימוש ‪ -‬תרגום התוכניות למציאות‬ ‫ ‬ ‫בדיקות ‪ -‬בחינת התוצאות מול התכנון‬ ‫ ‬ ‫הטמעה ‪ -‬התקנת המערכת והטמעה אצל המשתמשים‬ ‫ ‬ ‫תחזוקה ‪ -‬תהליך מתמשך של ניפוי שגיאות והרחבות‬ ‫ ‬ ‫וגם ‪ :‬דיונים‪ ,‬הערכת סיכונים‪ ,‬תיעוד‪ ,‬תיעדוף‪ ,‬ארכיטקטורה‪....‬‬ ‫ ‬  ‫מתחילים‬ ‫ "מישהו" יוזם פיתוח מוצר‬ ‫– בארגון– מנהל מחלקה‪ ,‬מנהל חטיבה‪ ,‬סמנכ"ל‪ ,‬מנכ"ל‪...‬‬ ‫– בשוק חופשי ‪ -‬יזם בעל רעיון העונה לצורך‬ ‫ בארגונים נדרש מסמך ייזום‬ ‫– אסמכתא מגורם ניהולי להתחיל בתהליך והגדרת אחריות לביצוע‬ ‫ בשוק חופשי נדרש מסמך חזון (‪)Vision‬‬ ‫– אמצעי תקשורת עם גורמים אותם עשוי לעניין המיזם‬ ‫ מי אחראי על הייזום?‬  ‫מנהל מוצר‬ ‫נדבר עליו גם בהמשך‬  ‫מנתח מערכת‬ ‫מנתח מצב קיים ובעיות הדורשות מחשוב‬ ‫ ‬ ‫מגדיר איפיון למרחב הבעיה וקווי מתאר לפתרון‬ ‫ ‬ ‫תוחם ומחדד מטרות מערכת‬ ‫ ‬ ‫אוסף ומסווג דרישות מלקוחות ומשתמשים‬ ‫ ‬ ‫תוצרים פורמליים‪:‬‬ ‫ ‬ ‫ מסמך ייזום‬ ‫ ניתוח מצב קיים‬ ‫ הגדרת דרישות‬ ‫ איפיון פתרון‬ ‫ דיאגרמות ופורמטים סטנדרטיים‬  ‫פעולות בשלב הייזום‬ ‫ הגדרת הלקוח‪/‬ות‬ ‫– בתוך האירגון‬ ‫– מחוץ לאירגון (הלקוח הפוטנציאלי)‬ ‫ מציאת מנהל מוצר‬ ‫ ניתוח מצב קיים‪ ,‬בדיקת מערכות דומות קיימות‬ ‫ הגדרת מטרות (כלליות) ויעדים (ספציפיים)‬ ‫– מטרה הופכת לרשימת יעדים‬ ‫– מודל ‪SMART‬‬  ‫מודל ‪SMART‬‬ ‫ ‪ -Specific‬יעדים ממוקדים ככל הניתן‪ ,‬ולא כלליים מידי‪.‬‬ ‫ ‪ -Measurable‬יעדים הניתנים למדידה‬ ‫ ‪ -Attainable‬יעדים ברי השגה‪ -‬ריאליים והגיוניים‪.‬‬ ‫ ‪ -Relevant‬יעדים המשרתים את הייעוד והאסטרטגיה‬ ‫הארגונית‪.‬‬ ‫ ‪ -Time-bound‬יעדים התחומים בזמן‪.‬‬ ‫פעולות בשלב הייזום ‪ -‬המשך‬ ‫ הגדרת אילוצים וסיכונים‬ ‫– אילוצים ומגבלות טכנולוגיים‪ /‬ארגוניים‬ ‫– אילוצי זמן‪ /‬משאבים‪ /‬תקציב‬ ‫ הגדרת תועלות וחסכונות‬ ‫– תועלות מוחשיות‪ /‬לא מוחשיות‬ ‫– חיסכון בכ"א‪ /‬ייעול תהליכים‬ ‫ בדיקת ישימות ובדיקת עלות‪ /‬תועלת‬  ‫בדיקת ישימות‬ ‫נשאל ונבדוק‪:‬‬ ‫ האם צפויים קשיים‪/‬מגבלות בתחום הגדרת היישום?‬ ‫ האם מדובר בטכנולוגיה חדשה ובלתי מוכרת?‬ ‫ האם צפויים קשיים‪/‬מגבלות במימוש המערכת?‬ ‫ האם יש בעיות היתכנות ברכיבים מסוימים‪ ,‬למשל‪,‬‬ ‫ברכיב אבטחת מידע‪.‬‬ ‫ האם צפויים קשיים בתחום הטמעת המערכת?‬ ‫בדיקות עלות‪ /‬תועלת‬  ‫למה לבצע בדיקת עלויות‬ ‫‪Money makes the world go round‬‬ ‫ ‬ ‫עוזר בהשגת תמיכת ההנהלה וקבלת תקציב‬ ‫ ‬ ‫הגדרת היקף ההשקעה הכדאי במערכת‬ ‫ ‬ ‫כלי לבחינת האלטרנטיבות‬ ‫ ‬ ‫ניסיון להפוך הנחות סובייקטיביות‪ ,‬השערות ותקוות‬ ‫ ‬ ‫לעובדות ומדדים (או להפריך את ההשערות)‬ ‫שיטות לשערוך עלויות‬  Parametric estimate -‫תבנית ל‬ https://www.smartsheet.com/ultimate-guide-project-cost-estimating  ‫פעולות בשלב הייזום ‪ -‬המשך‬ ‫ גיבוש ועדת היגוי )‪(committee steering‬‬ ‫– נציגים מתחומי ידע שונים (מיחשוב‪ ,‬תשתיות‪ ,‬כספים‪ ,‬משתמשים‪)...‬‬ ‫– ממשיכה לתפקד עד אחרי העלאת המערכת‬ ‫ יעדי ועדת ההיגוי‪:‬‬ ‫קביעת מדיניות פיתוח‬ ‫–‬ ‫מעקב ובקרה אחרי הלו"ז והעלויות של המערכת‬ ‫–‬ ‫פתרון בעיות במהלך הפיתוח‬ ‫–‬ ‫שינויים בשלב הפיתוח‬ ‫–‬ ‫קבלת החלטות בשלבים השונים של פיתוח המערכת‬ ‫–‬ ‫יצירת מעורבות ומחויבות אצל הלקוחות ואנשי הפיתוח‬ ‫–‬  ‫פעולות בשלב הייזום ‪ -‬המשך‬ ‫ קביעת לו"ז ומשאבים‬ ‫– לו"ז‪:‬‬ ‫סיום אפיון‬ ‫ ‬ ‫סיום פיתוח‬ ‫ ‬ ‫סיום בדיקות‬ ‫ ‬ ‫מועד עלייה לאוויר‬ ‫ ‬ ‫– משאבים‪:‬‬ ‫ משאבי חומרה ותוכנה‬ ‫ משאבים אנושיים‪ -‬לאפיון‪ ,‬לפיתוח‪ ,‬לבדיקות‪ ,‬להרצה ולתחזוקה‬ ‫ כתיבת מסמך הייזום‬  ‫רציונל ותוכן מסמך יזום‬ ‫יצירת מסגרת קונספטואלית וראיה משותפת לכלל המעורבים‬ ‫ ‬ ‫אינו מסמך טכני‬ ‫ ‬ ‫מתאר מצב קיים והבעייתיות‬ ‫ ‬ ‫למי נדרש הפתרון‬ ‫ ‬ ‫ישמש כקלט לתהליך האיפיון ולהחלטת ‪Make or Buy‬‬ ‫ ‬ ‫ייזום מערכת‪ /‬פרויקט‪ -‬לפי נוהל מפת"ח‬ ‫מרכיבי מסמך ייזום‬ ‫מטרה והצדקה לעריכת הפרויקט‬ ‫ ‬ ‫יעדים ומדדים להשגתם‬ ‫ ‬ ‫דרישות מרכזיות‬ ‫ ‬ ‫תאור כללי ותכולה עיקרית‬ ‫ ‬ ‫אילוצים‪ ,‬סיכונים והנחות‬ ‫ ‬ ‫הערכת לו"ז ואבני דרך‬ ‫ ‬ ‫הערכות תקציב‬ ‫ ‬ ‫רשימת בעלי עניין‬ ‫ ‬ ‫הגדרת נקודת סיום‬ ‫ ‬ ‫תבנית מסמך ייזום – רשות התקשוב הממשלתי‬ ‫הנדסת הדרישות‬ ‫מנתח מערכת‬  ‫מהן דרישות‬ ‫ החל מהגדרה עילית או הצהרה מופשטת לשירות או לאילוץ‬ ‫שיש להתחשב בו וכלה בהגדרה מתמטית מפורטת‬ ‫ דרישות עשויות לשמש בשני אופנים‪:‬‬ ‫– בסיס לבקשת הצעות ולכן עליהן להיות אבסטרקטיות ופתוחות‬ ‫לפרשנות‬ ‫– בסיס לחוזה ולכן עליהן להיות מוגדרות היטב וסגורות לפרשנות‬ ‫רמת האבסטרקציה היא נגזרת המטרה והשלב עליו עובדים‬  ‫הנדסת דרישות (‪)RE‬‬ ‫ יצירת תשתית למפרט התוכנה על פי צורכי הלקוח‬ ‫– הגדרת צורכי הלקוח‬ ‫– הגדרת יכולות המוצר‬ ‫– התנאים בהם המוצר נדרש לעמוד‬ ‫ הבסיס להבנה משותפת‬ ‫בין הלקוח למפתח‪.‬‬ ‫ מתאר את 'מה' המערכת אמורה לעשות ולא את 'איך ולמה'‬ ‫‪Requirements Engineering‬‬ ‫ איסוף‬ ‫ ניתוח‬ ‫ פירוט \ תיעוד‬ ‫ אימות‬  )‫חשיבות הגדרת דרישות (עקומת בוהם‬ “bugs are always more expensive to fix later on in the process” Boehm, Barry W., John R. Brown, and Mlity Lipow. "Quantitative evaluation of software quality." Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976. https://www.google.co.il/search?q=boehm%27s+curve&tbm=isch&tbo=u&source=univ&sa=X&ved=2ahUKEwiqyfv_ n6LeAhVCZVAKHXkAAwYQsAR6BAgGEAE&biw=1707&bih=782#imgrc=sgEr-YDioTa5LM:  IBM ‫הניסוי של‬ Briski, K. A., et al. "Minimizing code defects to improve software quality and lower development costs." Development Solutions. IBM. Crawford, B., Soto, R., de la Barra, CL (2008).  ‫דרישות ובעלי עניין‬ ‫כל בעל עניין "רואה" את המערכת אחרת בעיני רוחו ולכן‬ ‫חשוב להגדיר מסמך דרישות ברור!‬  ‫איסוף הדרישות‪ :‬מה הבעיה?‬ ‫המשתמשים חושבים‬ ‫המפתחים חושבים‬ ‫המנתחים מניחים מה‬ ‫שהם יודעים מה הם‬ ‫שהם יודעים מה‬ ‫המשתמשים רוצים‬ ‫רוצים‪ ,‬עד שהם רואים‬ ‫המשתמשים רוצים‬ ‫את התוצאה בעיניים‬ ‫המשתמשים לא‬ ‫אין אמון בין בעלי‬ ‫יודעים להסביר מה‬ ‫העניין‬ ‫הם רוצים ‪IKIWISI -‬‬ ‫כיצד מאתרים את הדרישות‬ ‫ראיונות ושאלונים למשתמשים השונים‬ ‫ ‬ ‫סיעור מוחות‬ ‫ ‬ ‫יצירת ‪demo‬‬ ‫ ‬ ‫בחינת מערכת קיימת ‪ /‬למידה ממצב קיים‬ ‫ ‬ ‫ניתוח מסמכים\ממשקים‬ ‫ ‬  ?‫מדוע מגוון שיטות‬ http://dilbert.com/search_results?page=3&sort=date_asc&year=2006  ‫עודף דרישות ותיעדוף דרישות‬ ‫ נגדיר רק את מה שצריך ‪ -‬כל דרישה משמעה עלויות‬ ‫כספיות‪ ,‬סיבוכיות למערכת וניהול של הבאגים‪.‬‬ ‫ קיימים מודלים רבים לתיעדוף‬  ‫מודלים לתעדוף דרישות‬ ‫ שביעות רצון מול עלויות‬:Kano ‫ מודל‬ “Customer Delight vs. Implementation – Investment”  ‫מודל ‪Kano‬‬ ‫ציר ‪– X‬השקעה ; ציר ‪ -Y‬שביעות רצון‬ ‫ציפיות בסיסיות‬ ‫השתלמות הביצוע‬ ‫‪http://uxtasy.com/blog/2011/01/kano-mode/‬‬  ‫מודל ‪Kano‬‬ ‫ציר ‪– X‬השקעה ; ציר ‪ -Y‬שביעות רצון‬ ‫מייצרי הנאה‬ ‫‪http://uxtasy.com/blog/2011/01/kano-mode/‬‬  MoSCoW :‫תעדוף דרישות‬ M – Must have S – Should have C – Could have W – Won't have (this time)  ‫סיווג דרישות‪ -‬משתמש ‪ vs‬מערכת‬ ‫ דרישות משתמש‬ ‫– משפטים בשפה טבעית המלווים בדיאגרמות השירותים שהמערכת תספק‬ ‫ומסגרת האילוצים – התיאור הוא עבור משתמשים‬ ‫ דרישות מערכת‬ ‫– מסמך מובנה הפורס תיאור מפורט של פונקציות המערכת ‪,‬‬ ‫שירותיה ואילוצי התפעול ‪ ,‬מתאר מה יש לממש באופן המאפשר‬ ‫להשתמש בו כבסיס לחוזה \ פיתוח \ בקרה \ בדיקות‬ ‫סיווג דרישות – פונקציונליות ולא פונקציונליות‬ ‫פונקציונליות (עסקיות)‪Functional Requirements (FR) :‬‬ ‫ ‬ ‫מה המערכת אמורה לעשות‪/‬להגיב מנקודת המבט של המשתמש‬ ‫לא פונקציונליות (טכניות‪ /‬איכות הפתרון)‪Non-Functional -‬‬ ‫ ‬ ‫)‪Requirements (NFR‬‬ ‫דרישות המגדירות תכונות נוספות של הפתרון שצריכות להתמלא תוך כדי מילוי הדרישות‬ ‫הפונקציונליות או‪ -‬דרישות ותנאים המגבילים את חופש בחירת כיווני הפתרון‬ ‫לדוגמא‪:‬‬ ‫זמני תגובה‪/‬ביצוע‬ ‫–‬ ‫נפחי פעילות‬ ‫–‬ ‫אמינות‬ ‫–‬ ‫אבטחת מידע‬ ‫–‬ ‫אופני מימוש‬ ‫–‬ ‫תדירות ביצוע‬ ‫–‬ ‫עמידה בעומסים‬ ‫–‬ ‫שימושיות‬ ‫–‬  ‫סיווג דרישות‪ -‬דרישות פונקציונליות‬ ‫ דרישות פונקציונאליות‬ ‫– משפטים אודות השירותים שהמערכת תספק‪ ,‬כיצד המערכת תגיב‬ ‫לסוגי קלטים ולמצבים נתונים ‪ ,‬ומהם הפלטים‬  ‫דוגמא לדרישות פונקציונליות‬ ‫– המערכת תאפשר להזין הזמנות מלקוח למוצרים שבמלאי‪.‬‬ ‫המערכת תייצר מספר הזמנה חד ערכי בעת שמירת‬ ‫ההזמנה‪.‬‬ ‫– כל הזמנה תאפשר לציין למוצר יחידת מידה וכמות‪.‬כל שינוי‬ ‫ביחידת מידה מחייב רישום כפריט נפרד בהזמנה‪.‬‬ ‫– לכל פריט בהזמנה יש לרשום יחידת מידה‪ ,‬כמות ומחיר‬ ‫ליחידת מידה‪.‬‬ ‫– ניתן להזמין מוצרים הן דרך מרכז ההזמנות והן בצורה ישירה‬ ‫באינטרנט‬ ‫– עבור כל פריט שיוצג יש להציג את שמו‪ ,‬הברקוד שלו וצבעו‪.‬‬  ‫סיווג דרישות פונקציונליות‪-‬‬ ‫תפעולית ‪ vs‬מידע‬ ‫ דרישה תפעולית ( ‪)OR = Operational Requirement‬‬ ‫– תפעול‪ ,‬לאינטראקציה או להתנהגות של המוצר‬ ‫ דרישת מידע (‪)DR = Data Requirement‬‬ ‫– ישויות המידע ולנתונים בהן נדרשת התוכנה לטפל )לקלוט‪,‬‬ ‫לאחסן‪ ,‬לאחזר‪ ,‬לעבד‪ ,‬להפיק כפלט(‬ ‫– לדוגמא‪ :‬נתונים ומבני נתונים‪ ,‬מאגרי מידע‪ /‬בסיסי נתונים‪,‬‬ ‫דרישות קלט‪/‬פלט‬  ‫דרישות לא פונקציונליות‬ ‫– אילוצים על השירותים או הפונקציות שהמערכת מספקת‬ ‫כגון חלונות זמן לתגובה‪ ,‬נפחים מקסימליים‪ ,‬מספר‬ ‫משתמשים בו זמני‬  ‫מטריקות להגדרה דרישות לא‬ ?‫ דוגמאות‬: ‫פונקציונליות‬ Speed Size Ease of use Reliability Robustness Portability  ‫דוגמא לדרישות לא פונקציונליות‬ ‫אילוץ‬ ‫חומרה‬ ‫מאפייני‬ ‫איכות‬ ‫המערכת תתבסס על מחשב מסוג ‪.....‬‬ ‫ ‬ ‫אילוץ‬ ‫ניהולי‬ ‫המערכת תהיה זמינה ** שעות ביממה‬ ‫ ‬ ‫אילוץ‬ ‫עלויות הפיתוח לא יהיו גבוהות מ‪20M$ -‬‬ ‫ ‬ ‫ניהולי‬ ‫תאריך היעד של המערכת הוא ‪01/01/2023‬‬ ‫ ‬ ‫אילוץ‬ ‫מימוש‬ ‫יש להשתמש בחישוב הפרמיה החודשית כפי‬ ‫ ‬ ‫שמחושב במערכת הקיימת‬ ‫יש להחזיר תשובה לחיפוש תוך ‪ 2‬שניות לכל היותר‬ ‫ ‬ ‫דרישות‬ ‫ביצועים‬ ‫תיעוד דרישות‬  ‫גישות לתיעוד דרישות‬ ‫ ‪Requirements List‬‬ ‫– במסגרת תבניות סטנדרטיות כדוגמת ‪ ,SRS‬ע"י תאור יכולות המערכת‬ ‫(‪ )Features‬ורשימת דרישות מכל ‪.Feature‬‬ ‫ ‪Use Cases‬‬ ‫– במסגרת מסמך ‪ SRS‬כאלטרנטיבה לתאור יכולות ורשימת דרישות ו\או כבסיס‬ ‫לדיאגרמות סטנדרטיות בתקן ‪(Unified Modeling Language) UML‬‬ ‫‪https://qracorp.com/guides_checklists/most-common-requirements/‬‬ ‫סוגי תבניות לייצוג דרישות‬  ‫סוגי תבניות לייצוג דרישות‬ Product Requirements Document (PRD) PRD Describes what a new feature or enhancement should look like and do from the end user’s point-of-view.. This document should focus on the “what” and not the “how.” The PRD should be implementation neutral. Implementation details are provided later on in the process.  ‫מסמך דרישות מוצר (‪)PRD‬‬ ‫מי כותב? ‪PM‬‬ ‫ ‬ ‫מטרות המוצר‪ ,‬מי ישתמש במוצר ואיך המוצר מתכתב‬ ‫ ‬ ‫עם חזון החברה‪.‬‬ ‫פיצ'רים במוצר‬ ‫ ‬ ‫אבני דרך‬ ‫ ‬ ‫קריטריונים להצלחה‬ ‫ ‬ ‫פונקציונליות‬ ‫–‬ ‫שימושיות‬ ‫–‬ ‫אמינות‬ ‫–‬ ‫ביצועים‬ ‫–‬ ‫‪How to Write an Effective Product Requirements Documents‬‬ ‫תמיכה‬ ‫–‬  ‫סוגי תבניות לייצוג דרישות‬ Functional Requirements Document (FRD) FRD is to define the requirements that are to be implemented as part of the engineering solution. The FRD acts as the technical response to PRD or other business request document. business meets technology. first point of translation for technical members of the team (design and test engineers, as well as support personnel). what should be done from a systems perspective. However, an FRD does not include how the system functions will be implemented. ‫מסמך דרישות פונקציונליות (‪)FRD‬‬ ‫מי כותב? ‪SA‬‬ ‫ ‬ ‫מידע כללי‪ -‬תיאור הפרויקט‪ ,‬אנשי קשר ועוד‬ ‫ ‬ ‫דרישות פונקציונליות‬ ‫ ‬ ‫דרישות לא פונקציונליות‬ ‫ ‬ ‫זמני תגובה‪/‬ביצוע‬ ‫–‬ ‫נפחי פעילות‬ ‫–‬ ‫אמינות‬ ‫–‬ ‫אבטחת מידע‬ ‫–‬ ‫אופני מימוש‬ ‫–‬ ‫תדירות ביצוע‬ ‫–‬ ‫עמידה בעומסים‬ ‫–‬ ‫שימושיות‬ ‫–‬ ‫‪How to Write an Effective Product Requirements Documents‬‬  Software Requirements Specification (SRS) * Software development team’s blueprint for defining and managing the scope of the project from a systems perspective. * It accomplishes that end by outlining the features and intended behavior of the various software applications. * Also demonstrates that the development team understands what the stakeholders want and that they have a plan for how to implement the ask via a software solution.  ‫מסמך דרישות )‪(SRS‬‬ ‫ המסמך באופן כולל מהווה את האיפיון המפורט‪ ,‬והוא‬ ‫ילווה בדיאגרמות ומודלים ויזואלים המונעים אי בהירות‬ ‫וכפל משמעות הנובעים לעיתים מתיאור מילולי‬ ‫ על המסמך לכלול‪:‬‬ ‫– מטרות המוצר‬ ‫– תיאור כללי אודות מה יפותח‬ ‫– פירוט הדרישות‬ ‫ על המסמך להיות‪:‬‬ ‫– חד משמעי‬ ‫– ברור‬ ‫– מלא‬  SRS - ‫סעיפים מרכזיים‬ Functional Performance Levels Data Safety Capabilities Structures/Elements Reliability Security/Privacy Quality Constraints and Limitations ‫למי מיועד ה ‪SRS -‬‬  ‫איכות הדרישה‬ ‫‪ - Identified‬בדידה ‪ ,‬מזוהה חד ערכית ‪ ,‬שייכות ברורה‬ ‫ ‬ ‫‪ – Understandable‬מובנת (ברורה‪ ,‬מדויקת)‪ -‬מנוסחת בשפת הלקוח‬ ‫ ‬ ‫‪ - Unambiguous‬לא עמומה (חד משמעית)‬ ‫ ‬ ‫‪ – Complete‬שלמה‬ ‫ ‬ ‫‪ - Necessary‬הכרחית‪ -‬בעלת תרומה משמעותית לשיפור תהליכי העבודה‬ ‫ ‬ ‫‪ – Consistent‬עקבית (לא סותרת דרישות אחרות)‬ ‫ ‬ ‫‪ - Verifiable‬ניתנת לבדיקה באמצעות מבחני קבלה‬ ‫ ‬ ‫‪ - Traceable‬עקיבה (גם לדרישות ברמה גבוהה יותר וגם בהמשך האפיון)‬ ‫ ‬ ‫‪ - Prioritized‬מתועדפת‬ ‫ ‬  ‫איכותית או לא?‬ ‫חיפוש מתקדם שבו ניתן יהיה לסנן גם לפי טקסט חופשי‬ ‫ ‬ ‫זמן חיפוש סביר‬ ‫ ‬ ‫המערכת תפחית את כמות הניירת בעלות שנתית של כ ‪₪20,000‬‬ ‫ ‬ ‫למנהל האתר תהיה האופציה להוציא דוחות לפי חתכים שונים‬ ‫ ‬ ‫במקרה שהמעלית נתקעה במהלך נסיעה מזעיק הנוסע חילוץ באמצעות כפתור‬ ‫ ‬ ‫החילוץ‬ ‫המערכת תאפשר חלוקת עבודה מאוזנת והוגנת בין העובדים‬ ‫ ‬ ‫סטטיסטיקות‬ ‫ ‬ ‫צמצום הוצאות החברה ב ‪ 27‬מיליון ש"ח עד מחצית הראשונה לשנת ‪2018‬‬ ‫ ‬ ‫‪ - Identified‬בדידה ‪ ,‬מזוהה חד ערכית ‪ ,‬שייכות ברורה‬ ‫הצגת היסטוריה של תלמיד בכניסה לאתר‬ ‫ ‬ ‫‪ – Understandable‬מובנת (ברורה‪ ,‬מדויקת)‪ -‬מנוסחת בשפת הלקוח‬ ‫‪ - Necessary‬הכרחית‪ -‬בעלת תרומה משמעותית לשיפור תהליכי‬ ‫ידידותי למשתמש‬ ‫ ‬ ‫העבודה‬ ‫‪ - Complete‬שלמה‬ ‫‪ – Consistent‬עקבית (לא סותרת דרישות אחרות)‬ ‫‪ - Unambiguous‬לא עמומה (חד משמעית)‬ ‫‪ - Verifiable‬ניתנת לבדיקה באמצעות מבחני קבלה‬ ‫‪ - Traceable‬עקיבה (גם לדרישות ברמה גבוהה יותר וגם בהמשך‬ ‫האפיון)‬ ‫‪ - Prioritized‬מתועדפת‬  ‫‪Use Case‬‬ ‫ דרך מקבילה לייצוג דרישות פונקציונאליות על בסיס התנהגות‬ ‫המערכת כתגובה לבקשות המגיעות מהסביבה‬ ‫ תאור כל המקרים )תרחישים( בהם נעשה שימוש בדרישות‬ ‫הפונקציונאליות מהמערכת‬ ‫ ‪ UC‬אינם מתמפים "אחד לאחד" לדרישות ‪:‬‬ ‫– ‪ UC‬אמנם מתבססים על זיהוי דרישות פונקציונאליות אך אינם תרגום אחד‬ ‫לאחד לדרישות ‪.‬על דרישה להכלל לפחות ב ‪ UC‬אחד ‪ ,‬ואילו ‪ UC‬כולל‬ ‫דרישות רבות‬