הגדרת דרישות וניהולן Requirements Definition and Management מבוא להנדסת תוכנה הגדרת דרישות וניהולן Requirements Definition and Management מקורות: S. R. Schach: Chapter 9 R. S. Pressman: Chapter 11 J. Robertson, S. Robertson, Mastering the Requirements Process מבוא להנדסת תוכנה © 1999-2001, ד"ר עמיר תומר

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

מה עומד על הפרק? היכן נמצאות הדרישות, ומה הקשר לאנליזה? מטרת שלב הדרישות תכונות הדרישות דפוס קבוע לדרישות: Volere טכניקות למיצוי דרישות אב-טיפוס מהיר סיפורי משתמש מדריך למשתמש כמסמך דרישות מבוא להנדסת תוכנה

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

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

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

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

תכונות הדרישות חד-משמעיות (lack of ambiguity) שלמות (completeness) לא סביר שמוצר, אשר הדרישות לגביו ניתנות לפירוש באופנים שונים, עונה על דרישות הלקוח. שלמות (completeness) למרות שאי אפשר לחזות את כל הדרישות העתידיות, יש לפרט לפחות את כל הדרישות הנוכחיות. עקביות (consistency) לא ניתן לממש מוצר בעל דרישות הסותרות זו את זו זיהוי של סתירות מאפשר "משא ומתן" ליישב את הבעיה יש גם "התנגשויות" בדרישות המחייבות העדפה של דרישה א' על פני ב' והחלשה של ב' מבוא להנדסת תוכנה

תכונות הדרישות (המשך) עקבות למקור (traces to origin) וזיהוי ייחודי לדרישה זיהוי מקורה של כל דרישה דרישות מפורשות (explicit) דרישות נגזרות (derived) הימנעות מתכן (avoid design) מפורטות ככל שיהיו, הדרישות הן עדיין רק דרישות. כל קביעה מפורשת של רכיב, אלגוריתם וכו' שייכת לתכן. סבירות לממש: ניתן לבניה במשאבים המוצעים מבוא להנדסת תוכנה

מה מבנה הדרישות ומה הן מכילות? דפוס קבוע של 26 סעיפים ראשיים גישה אפשרית: Volere מה מבנה הדרישות ומה הן מכילות? דפוס קבוע של 26 סעיפים ראשיים מגבלות (constraints) למוצר: עובדות והנחות דרישות פונקציונליות דרישות לא-פונקציונליות (איכויות) שאלות חשובות לפרויקט (issues) מבוא להנדסת תוכנה

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

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

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

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

אינן עובדות, אך אולי יהיו נכונות בעתיד הנחות וסברות אינן עובדות, אך אולי יהיו נכונות בעתיד חשוב לגלות ולרשום הנחות "סמויות" כדי למנוע אי-הבנות בפיתוח סברות על יכולות המשתמשים הנחות על יכולות של תוכנות תומכות עתידות מבוא להנדסת תוכנה

גבולות המוצר: מה בפנים ומה בחוץ תיאור דרישות לכל פעולה של המוצר דרישות פונקציונליות גבולות המוצר: מה בפנים ומה בחוץ כולל רשימת מאורעות שהמוצר מגיב אליהם תיאור דרישות לכל פעולה של המוצר לכל דרישה כזו יש גם fit criterion המאפשר לבדוק אם נעמוד בדרישה, במימוש יעמוד בבדיקות מקיפות ובדיקות beta לכל פעולה מבוא להנדסת תוכנה

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

דרישות לא-פונקציונליות (המשך) דרישות הפעלה תנאים מיוחדים בהפעלה: חוסר אור, יופעל בחוץ יותאם למגבלות והנחות, ולדרישות נוחיות השימוש דרישות על אחזקה וניידות (portability) כל כמה זמן צפויה גירסה חדשה? האם מדובר בקו מוצרים (product line) ? האם צפויה ורזיה ל-Mac ? בטחון ופרטיות למי מותרת גישה לאיזה חלק מהמידע? דרישות לביקורת כספים חיצונית האם יש צורך בהגנה מווירוסים וחדירות? מבוא להנדסת תוכנה

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

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

טכניקות למיצוי דרישות לקוח (requirements elicitation) ראיון עבודה בצוות משותף מיצוי מטקסט כתוב שימוש ב-CASE בניית אבטיפוס מהיר סיפורי משתמש כתיבת "מדריך למשתמש" מבוא להנדסת תוכנה

מיצוי דרישות מתוך טקסט כתוב מסמך בסיס לדוגמה: RFP = Request for Proposal הוצאת משפטי מפתח לתוך רשימה פירוק המשפטים לדרישות בדידות קביעת מאפיינים לדרישות מיון והקצאה מבוא להנדסת תוכנה

CASE לניהול דרישות RequisitePro® (Rational Software Co.) מיצוי דרישות מתוך טקסט בעותק-רך בניית מאגר דרישות טבלת מעקב לדרישות מקור עץ דרישות חיפוש ושליפה לפי שאילתות ניהול ומעקב אחר מילוי הדרישות - עבודת צוות שילוב עם כלי ניתוח ותכן מבוא להנדסת תוכנה

® RequisitePro - סימון ויצירת דרישות 3.1.4. Administrative Functions 3.1.4.1. Banking Information [PR6 The QBS system shall allow updates to customer information only in the Customer Information screen. ] [PR16 All other screens shall have customer information updated from the Customer Information Screen. ] [PR17 All balance information shall be updated systematically ]  3.1.4.2. Reports [PR7 The QBS system shall provide the following reports: ]  Report: Complete customer history per account. Report: Customer demographic report. Report: Customer listing with options to sort by, name, company, interest rate, and origination date. מתוך “The Learning Project” RequisitePro Evaluation Report: Complete customer history per account. מבוא להנדסת תוכנה

® RequisitePro - רישום דרישה פרטים מאפיינים מבוא להנדסת תוכנה

® RequisitePro - הגדרת סוגי דרישות ומאפייניהם מאפייני דרישות קדימות (priority) סטטוס קושי יציבות ... מבוא להנדסת תוכנה

® RequisitePro - מטריצת הדרישות - מאפיינים מבוא להנדסת תוכנה

® RequisitePro - מטריצת הדרישות - עץ מעקב מבוא להנדסת תוכנה

® RequisitePro - מעקב דרישות נגזרות מבוא להנדסת תוכנה

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

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

- עקרונות האבטיפוס המהיר בשפת C (למימוש ב- ++C) או בשפת Java ממשק משתמש אלפאנומרי פשוט התפריטים כוללים את כל הפונקציות לא כל הפונקציות ממומשות אבל התפריט מגיב לכל האופציות! בסיס מידע מתעדכן - ממומש ע"י קבצים בסיס מידע קבוע - בתוך התכנית מבוא להנדסת תוכנה

דרישות דרך סיפורי משתמש סיפור: תרחיש טיפוסי המכיל מספר קטן של פעולות המערכת בפיתוח פעולה מובנת בעזרת סה"כ הסיפורים מתקשר ל-use cases של UML בשימוש נרחב ב-Extreme programming דוגמה: מהלך של הוצאת סכום מזומנים מכספומט אחרי זיהוי ובירור יתרה מבוא להנדסת תוכנה

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

אז מה היה לנו...? היכן נמצאות הדרישות? מטרת שלב הדרישות תכונות הדרישות דפוס לדרישות: Volere טכניקות למיצוי דרישות אב-טיפוס מהיר סיפורי משתמש מדריך למשתמש מבוא להנדסת תוכנה

וכעת נעבור ל... ניתוח OO מבוא להנדסת תוכנה