Transcript הרצאה 1-2
ניתוח מערכות מידע א'
הרצאה 1
נעים להכיר...
ניתוח מערכות
שלבי תהליך הפיתוח
ניתוח דרישות
מחזור החיים
1
ניתוח מערכות מידע א'
מרצים
מכון לב -דוד קאופמן
מכון טל – ד"ר אריאלה ריכרדסון
שעות קבלה:
בתאום מראש בדוא"ל
אתר הקורס
http://www.jct.ac.il/~richards/Nituach-1.htm
2
עדכונים
מצגות
דוגמאות וחומר לחזרה
סילבוס
נושאים שילמדו בקורס
מבוא
הגדרת דרישות
מידול
תרשימי UML
C#
3
הערכה
הציון מורכב מ:
תרגילים ()10%
מבחן סופי ()90%
אסור לעבוד בזוגות בכל חלק (גם בתרגילים וגם במבחן)
נוכחות אינה חובה (אבל מומלצת)
מועד ב' – מורשה לתלמיד(ה) בעל(ת) לפחות %70נוכחות.
הערה :חובה לעבור את המבחן הסופי בציון של 55לפחות.
תרגילים:
חובה להגיש תרגילי בית בזמן.
הגשה ב MOODLE
ספרים
“Requirements Analysis and System Design” 3rd
edition, (Leszek A. Maciaszek(
"Object-Oriented Systems Analysis and Design
Using UML” 3rd edition, Simon Bennett, Steve
Mcrobb, Ray Farmer
5
ניתוח מערכות
מה זה?
6
מהי מערכת מידע?
7
ניתוח מערכות
מהו ניתוח מערכות?
גישה מובנה לזיהוי הזדמנויות ,מטרות ובעיות
ניתוח זרימת המידע בארגונים
תיכנון של מערכות מידע ממוחשבות לפתרון בעיה
למה ניתוח מערכות?
8
מורכבות המערכת
שגיאות נפוצות
ייעול העבודה
...
מושגים בניתוח המערכות
" בעלי העניין" הם אלו שיש להם עניין במערכת
מפתחים
לקוחות
תהליך הפיתוח
מתאר את תהליך פיתוח התוכנה בחברה
מגדיר את שלבי הפיתוח ,לוחות זמנים ,סדר הפעילות וכדו'
לא ניתן לקבוע תהליך סטנדרטי ,יש להתאים לחברה
מידול
9
שפה לתיאור המערכת ()UML,DFD
כלים לבנית מודל המערכת ()CASE
שלבי תהליך הפיתוח
במערכת מידע
מחזור החיים
מדרישת הלקוח ועד שאין יותר שימוש בתוכנה
10
11
שלבי הפיתוח
אין יותר שימוש בתוכנה: סיום, דרישת לקוח: התחלה
שלבים בחייה של מערכת
Initiation, concept development, planning –שלב הייזום
Requirement phase - שלב הדרישות
Analysis phase - שלב הניתוח
Design phase - שלב התכן
Development phase - שלב המימוש
Integration and Test phase - שלב השילוב
Operations & Maintenance phase – שלב התפעול והאחזקה
Retirement\Disposition – פרישה
12
ייזום
– Initiation אתחול
זיהוי צורך או הזדמנות ,הגדרה ראשונית של הצעה למערכת
– System Concept Development
מתאר את גבולות ההצעה ,ניתוח עלויות ,סיכונים ,בדיקת היתכנות
Planning
13
פיתוח תוכנית לתכנון המערכת ,בסיס לתכנון המשאבים הנדרשים
למערכת
שלב הדרישות Requirement phase -
הבנה והגדרה של דרישות הלקוח
כולל ניתוח בעיות ,ניתוח הזדמנויות שיווקיות וכדו'
מורכב משני היבטים:
Business modeling
הכרת הסביבה העסקית שבה תפעל התוכנה
System modeling
הגדרה של מה התוכנה תעשה\לא תעשה
נגדיר שני סוגי דרישות
שירות – service -פעולות שהמערכת צריכה לבצע
אילוץ – constraint -הגבלות על פעילות המערכת
התוצר – מסמך מילולי (בלתי פורמלי) המתאר את הדרישות
14
שלב הניתוח Analysis phase -
זיהוי הישויות הפועלות במערכת
הכרת התכונות של הישויות הנ"ל
הכרת הקשרים בין הישויות
שלב זה נקרא לפעמיםrequirements specification :
התוצר משלב זה (נלמד בהמשך):
15
בשלב זה מתחילים להשתמש בכלי מידול ()CASE
ובוחרים שפת מידול ()UML
בסוף הניתוח יתקבלו התרשימים הבאים:
class diagrams, use case diagrams
שלב התכן Design phase -
תכנון פתרון הבעיה
כולל גם תכנון התוכנה וגם תכנון מרכיבים נוספים במערכת
מבוסס על הגדרות שלב הניתוח.
תכנון ארכיטקטוני (חומרה)
מחשבים ,שרת/לקוח ,מסד נתונים ,תקשורת ,וכו'
תכנון מפורט (תוכנה)
16
אלגוריתמים ,מבני נתונים ,ממשק למשתמש ,וכו'
תיאור ההתנהגות הצפויה מרכיבי התוכנה
שלב המימוש Implementation phase -
פיתוח התוכנה
התקנה של סביבת פיתוח התוכנה
תיכנון התוכנה על סמך השלבים הקודמים
קידוד התוכנה
תיעוד התוכנה ()help, web sites with FAQ
בדיקות תוכנה
17
בדיקה של יחידות התוכנה השונות
בדיקת התוכנה של המערכת כולה
תיקונים והרחבות
שלב השילוב (הטמעה)Integration phase -
יש לתכנן את השילוב בתחלית מחזור החיים
הרכבת חלקי המערכת ()integration
יש לבצע באופן הדרגתי
פריסה ()deploymentהתקנת המערכת כולה
הדרכת משתמשים ,הסבת נתונים ושיטות עבודה.
בעיות נפוצות
קשיים בשילוב בין הרכבים עקב תלות מעגלית
רכיב אחד מוכן לפני/אחרי האחרים
18
טוב שתהיה מערכת גיבוי לעבודה לתקופת השילוב
שלב האחזקה Maintenance phase -
לאחר המסירה ללקוח יש להמשיך לתחזק את המערכת
האחזקה היא חלק חשוב של הפרויקט ומהווה אחוז ניכר
של פעילות אנשי מערכות המידע
אחזקה מורכבת מ:
Housekeeping
Adaptive maintenance
ניתור ,כיול ,הוספת משתמשים וכדו'
Perfective maintenence
19
ביצוע פעולות אחזקה סדירות לאפשור נגישות למערכת
תכנון מחודש של תתי מערכות
פרישה Retirement -
בסוף המערכת יוצאת משימוש
סיבות אפשריות
20
שינויים מעבר למסגרת אחזקה
המערכת יוצאת משליטה ואין אשפרות לנבא כיצד תפעל
מחסור בתיעוד המאפשר שינויים
שינויים בחומרה או תוכנה שאינה מאפשרת את העברת
המערכת
המתודה ותהליך הפיתוח
תכנון ()planning
הגדרת תוצרים
לוחות זמנים
משאבים דרושים (כוח אדם ,תקציבים ,ציוד ,כלי פיתוח וכו')
הערכת סיכונים
בדיקות ()testing
תיכנון הבדיקות החל מתחילת התהליך
בדיקת הקוד ()walkthrough
בדיקות של כל יחידה ,בדיקות של המערכת
לפעמים מוגדרים כשלבים נפרדים ,אבל בעצם מדובר בפעילויות
המבוצעות לאורך כל מחזור החיים
21
פירוט שלב הגדרת מטרות
ויעדים
22
הגדרת מטרות ויעדים
המטרות מוגדרות בספרות כ"תוצאות רצויות" ,מה
החברה רוצה להשיג ,או מהו המצב הרצוי.
מטרות הן משהו יותר מעורפל ואילו היעדים הם כימות
של המטרות.
היעדים להבדיל מהמטרות מוגדרות היטב ,ומטווחים
בזמן.
לכל מערכת מידע יש מטרות ויעדים
מטרות מגדירות לשם מה הוקמה מערכת מידע
יעדים (דרישות) מגדירים את הפעולות שיש לבצע כדי
להשיג את המטרות
יעדים צריכות להיות מנוסחים ע"פ
עקרון SMART:
:Specific יעדים ממוקדים ככל הניתן ,ולא כלליים מדי" .הגדלת רווחים",
"שיפור שביעות רצון"" ,שיפור יעילות" – הן יעדים כלליים מדי .אינפורמציה
חסרה :של מי? בכמה? באיזה תחום ספציפי?
:Measurable יעדים הניתנים למדידה ,אחרת לא נוכל לדעת האם היעדים
הושגו או לא .קיימות מגוון דרכים למדוד יעדים ,גם אם במחשבה ראשונה
נדמה שהן אינן מדידות.
:Attainable יעדים ברי השגה .יעדים ריאליים והגיוניים.
:Relevant יעדים המשרתים את הייעוד והאסטרטגיה
הארגונית .יעדים משמעותיים לארגון.
:Time-bound יעדים התחומים בזמן .כך אנחנו מוודאים
שיש מסגרת זמנים שמאפשרת לנו מעקב קבוע.
דוגמה :מערכת "חברה קדישא"
מטרות ויעדי המערכת
התייעלות תהליכי העבודה השוטפת( .מטרה)
קיצור קבורה ממוצעת ועבודתם של צוות החופרים מ 40-דקות בממוצע ל 25-דקות כיוון שיגיעו
עם טאבלט שיכוון אותם באופן ויזואלי למיקום המדויק שנועד לחפירה( .יעד)
חסכון בעלויות( .מטרה)
חיסכון בהעסקת עובדי משרד לצורך דיווח לגורמי הפיקוח כיוון שהמערכת תעשה זאת באופן
אוטומטי כיוון שגם הגורמים המפקחים יוכלו להיכנס אליה מרחוק (חסכון במשכורת של פקידה
בסך ( ).₪ 6,000יעד)
סנכרון מהיר יותר בין המערכת של חב"ק למערכת של מל"ל כך שבמקום שהמערכות ידברו
פעם ברבעון המערכת החדשה תסנכרן עם המערכת של מל"ל פעם ביום והתשלומים השוטפים
יועברו באופן מיידי( .יעד)
שירות לקוחות טוב יותר( .מטרה)
חסכון בזמן של המבקרים בבי"ע שיוכלו לחפש את קבר יקיריהם בזמן מועט יותר .אם כיום
המבקר הממוצע מחפש כ 20-דקות את מבוקשו ,בעזרת המערכת החדשה יוכל למצוא את
מבוקשו תוך דקה( .יעד)
הגברת מספר המכירות בחיים מ 350-בממוצע לשנה ל .800-מהסיבות הבאות( :יעד)
איש המכירות לא יצטרך לרדת לשטח עם כל לקוח ובכך יוכל להיפגש עם 8לקוחות ביום במקום 3כיום.
הלקוחות ידעו באפן מדויק איזה חלקה הם רוכשים והיכן היא ממוקמת ופחות יחששו מהרכישה( .יעד)
הפחתת מס' התביעות המשפטיות כנגד חב"ק ממוצע של 4בשנה ל – ,1כיוון שהרוכשים ידעו
בוודאות מה הם רוכשים( .יעד)
ניתוח דרישות
+פרויקט דוגמא
27
פרויקט לדוגמא:
פניני להט
מנחה:
אריאלה ריכרדסון
מציגות:
הדס טייב
הדס אביטל
ענף התכשיטים
זהב ,יהלומים ואבני חן
חומרי גלם – ייצור – מכירה
ניהול הנתונים באופן ידני
מפעל התכשיטים
בעבר -חנות לממכר תיקים ותכשיטי כסף
היה תלוי בספקים חיצוניים
כיום -עברו להתמקד בענף התכשיטים
עברו לייצר עצמי של התכשיטים
30
מיוצרים מזהב ,יהלומים ופנינים
לפי הזמנת לקוח או ייצור עונתי בעיצוב מנהל המפעל
המפעל מספק הזמנות לחנויות או לבודדים
קניית חומרי הגלם וקבלת הסחורה מתבצעת ע"י מנהל
המפעל בלבד
הטמעת מערכת מידע במפעל התכשיטים
תיאור המצב הקיים
ניהול לא ממוחשב
המפעל מתנהל באופן מבולגן
אין מעקב מסודר אחר הפעילות במפעל
ריכוזיות יתר
31
תיעוד הזמנות ,תשלומים וכדו' מבוצע באופן ידני בניירות
בעל המפעל מרכז את כל התהליכים המסחריים וכן את
תהליכי היצור
הבעיות הקיימות במפעל התכשיטים
התנהלות לא מאורגנת
התנהלות לא יעילה
העדר יכולת לשלוף מידע ונתונים כגון:
32
מכירות ,תהליכים ,חומרי גלם
אובדן של חומרי גלם
בזבוז שעות עבודה
בעיות ביכולת לספק תוצרים בזמן
פגיעה ברווחיות המפעל
הפתרון המוצע עבור מפעל התכשיטים
מציאת פתרון בעל התכונות הבאות:
ייעל את המפעל
יאפשר מעקב ובקרה על הנעשה במפעל
מתוך כך יביא לייעול המפעל ומקסום רווחיו
33
שלב הדרישות:
ניתוח דרישות מפורט והגדרת תכולת הפרויקט
34
דרישות ואילוצים
- service statements דרישות פונקציונליות
מה המערכת "צריכה לעשות"
הגדרה ברורה של התפקידים של המערכת
אילו תפקידים ימומשו ע"י מערכת המידע ואילו דורשים
התערבות ידנית
באיזה מידע המערכת תטפל
– constraint statements אילוצי המערכת
35
מה הן המגבלות שלנו בפיתוח המערכת
דרישות פונקציונליות
דרישה תפעולית ()OR-Operational Requirement
מתייחסת לתפעול ,לאינטראקציה או להתנהגות המוצר
פעולות ,תרחישים ,תגובות לאירועים וכו'
פונקציות ,שירותים
דרישת מידע ))DR - Data Requirement
– דרישה המתייחסת לישויות המידע ולנתונים בהן
המערכת מטפלת (קלט ,אחסון ,אחזור ,עיבד ,פלט)
36
נתונים ומבני נתונים
מאגרי מידע ,בסיסי נתונים
דרישות קלט/פלט
אילוצי המערכת
קלות השימוש
שימוש חוזר של יחידות תוכנה
זמן תגובה של המערכת ,מספר משתמשים
יעילות
37
טיפול בכשלים של המערכת ,שיקום מהיר ויעיל
ביצועים
מחלקות ,חבילות ,ממשקים...
אמינות
נוחות ממשקים ,טיפול בבעיות ,התאמה למשתמשים שונים
עלות מול תועלת של כוח אדם תוכנה וציוד
דרישות פונקציונליות -מפעל התכשיטים
המערכת צריכה לטפל בתהליך הרכישה של חומרי
הגלם
המערכת תומכת בתהליך הייצור ע"י מעקב אחר
העבודה ,עלות וזמן הייצור ,וכמות הזהב בתהליך
המערכת לא מבצעת את הייצור ,אלא מספקת תמיכה
המערכת תספק גם תמיכה לבחירת ספקים (ע"י יכולת
דירוג של ספקים שונים לפי פרמטרים של מחיר ,תנאי
תשלום וכו')
38
המערכת לא בוחרת את הספק ,את זה יעשה המנהל
אילוצים -מפעל התכשיטים
קלות השימוש -המשתמשים אינם מורגלים בעבודה מול מחשב,
על הממשק להיות ברור ביותר וקל לתפעול
שימוש חוזר של יחידות תוכנה -כדאי להשתמש בכמה שיותר
חבילות קיימות
אמינות -חשוב שיהיה קל לשקם את המערכת ממצב של נפילה,
אבל לא חייבים שיתבצע מאד מהר
ביצועים -המערכת חייבת להיות נוחה אבל לא מוכרח שתהיה
מאד מהירה .יהיו עד 10משתמשים במערכת ,כלומר מספר
משתמשים קטן.
יעילות – על המערכת להיות זולה ,לא משתלם לחברה להשקיע
כסף רב בשיפור שתביא התוכנה
* 39במסמך המלווה את הקורס ניתן לראות עוד דוגמאות
הפקת דרישות – מקורות מידע
מידע להגדרת הדרישות נאסוף ממומחים ומלקוחות
שיטות מסורתיות
ראיונות ,שימוש בשאלונים ,תצפיות ,ניתוח מסמכים
ומערכות תוכנה...
שיטות מודרניות
פרוטוטיפים ,סיעור מוחיןJAD, RAD ,
השיטות המודרניות נחשבות טובות יותר אבל יקרות
יותר מהמסורתיות
40
שיטות איסוף מסורתיות – ראיונות ושאלונים
ראיונות
תשאול מומחים בתחום ואת הלקוחות
יש לשים לב שללקוחות יש הרבה פעמים תמונה חלקית
ראיון יכול להיות מובנה (שאלות מוגדרות מראש) או חופשי
(לתת למרואיין לדבר על מה שיבחר)
יתרונות – גמישות ,הבנה מעמיקה
חסרונות – גוזל זמן רב ,מאפשר אי הבנות וסתירות
שאלונים ("אמריקאי" ,דירוג )
מאפשר איסוף מידע ממספר רב של לקוחות
משמש בדרך כלל כתוספת לראיון ולא תחליף
41
יתרונות – תשאול של הרבה אנשים על פני מרחק גדול
חסרונות – קשה לכתיבה ולפעמים גם לניתוח
שיטות איסוף מסורתיות – תצפיות וניתוח
מסמכים
תצפיות
תצפית פסיבית – צפייה בתהליך ללא התערבות
תצפית אקטיבית – הצופה נוטל חלק בפעילות
תצפית מסבירה – הצופה מקבל הסבר בזמן הביצוע
יתרונות -וידוא אמיתות הראיונות ,מאפשר מדידת זמנים
חסרונות -צפייה גורמת לעיוות הפעילות ,לעיתים יש בעיות
אתיות ומשפטיות בתהליך צפייה חיצוני
מסמכים
42
ניתוח דוחות ,מסמכים ומערכות תוכנה קיימות
למידה על התחום ממאמרים וספרים
שיטות איסוף מודרניות-אב טיפוס ()Prototype
()Kotonya and Somerville 1998
אב טיפוס הוא דגם ראשוני של המוצר
מורכב ממשק למשתמש (בד"כ חלקי)
הפונקציונליות אינה ממומשת באופן מלא
המטרה היא לתת תחושה של המערכת הסופית
אב טיפוס "לזריקה" ( )throw-awayמשמש רק להדגמה
אב טיפוס "מתפתח" ( )evolutionaryמורחב אח"כ
למערכת האמתית
43
לפעמים בנויה על מצב היפותטי של המערכת
יתרונות – מקל על הגדרת דרישות ,ומציאת סתירות
חסרונות – זמן הפיתוח
שיטות איסוף מודרניות -סיעור מוחין
()Brainstorming
ועידה בה מעלים רעיונות לפתרון בעיה
נועד להעלות רעיונות חדשים ולקבל עליהם חיווי
אדם אחד אחראי על ניהול הפגישה ,ומציג שאלות
להכוונה (מתאים ל 10-20איש)
למשל -אילו פעילויות יבוצעו במערכת ,מה הקלט
ופלט ,מהם הסיכונים וכו'
יש לרשום את הרעיונות והמגבלות ולדרג אותם
44
יתרונות – מעלה הביטים שלא תמיד עולים בשיטות אחרות
חסרונות – עלול להתבדר
שיטות איסוף מודרניות – JAD
Joint Application Development
פיתוח יישום שיתופי
דומה לסיעור מוחין ,אך מובנה יותר
משתתפים:
45
מנהל ) –(leaderחיצוני ,אינו ממתכנני המערכת וגם לא לקוח
רשם ) – (scribeרושם את כל מה שמתנהל
לקוחות ) – (customersהגורם הכי פעיל ,מגדירים את
הדרישות וכו'
מפתחים ) – (developersאנשי צוות הפיתוח בעיקר
מקשיבים...
שיטות איסוף מודרניות – RAD
Rapid Application Development
פיתוח יישום מהיר
שילוב של מספר שיטות
בניית אב טיפוס מהיר
שימוש בכלי CASE
פגישת JAD
קביעת מגבלות זמן
46
יתרונות – מתאים לפרויקטים קטנים או "פחות חשובים"
חסרונות – נוטה לסבול מסתירות פנימיות ,חוסר שימוש
חוזר ,העדר מסמכים מלווים וקשוי בתחזוקה
שיטות איסוף -מפעל התכשיטים
בפרויקט בוצע שימוש בשיטות הבאות:
ראיונות
צפייה
47
בעל המפעל מאד דומיננטי במפעל ולכן ראיונות איתו הניבו
הרבה מידע
בתהליכי העבודה
בציוד ובחומרי בגלם הקיימים במפעל
לא היה כדאי כאן לבצע אב טיפוס משיקולי זמן
משא ומתן ואימות דרישות
בתשאול הלקוחות יתכנו חפיפות סתירות בדרישות
יש ליישב סתירות וחפיפות אלו
מתבצע גם במקביל לאיסוף הדרישות וגם בסוף
איך מתבצע?
.1
.2
.3
48
הגדרת דרישות שהם מחוץ לתחום המערכת
מילוי מטריצת תלויות
ניתוח סיכונים וסדר עדיפות
הגדרת דרישות שהם מחוץ לתחום
תחילה יש להגדיר את טווח המערכת
דרישות מחוץ לטווח ההגדרה לא יכנסו לתכנון
יש לבדוק אלו מהדרישות אינן חיוניות למערכת
אולי נרצה להוריד אותם
דרישות "יקרות" שלא ניתנות למימוש יש להוריד
יש דרישות שימולאו ע"י גורם חיצוני והן מחוץ לטווח
למשל במפעל התכשיטים – המערכת אינה בוחרת
ספקים וסחורה אלא מספקת תמיכה לקבלת החלטה
49
מילוי מטריצת תלויות
.1מעקב אחר
הזמנות מספקים
דרישה
.2ניהול רשימת
הזמנות
.3ניהול רשימת
לקוחות
.4רשימת כל
ההזמנות
.1מעקב אחר
הזמנות מספקים
.2ניהול רשימת
הזמנות
.3ניהול רשימת
לקוחות
חפיפה
.4רשימת כל
ההזמנות
יש לרשום אם יש חפיפה או סתירה בין שתי דרישות
50
מצ"ב טבלה חלקית למפעל התכשיטים
ניתוח סיכונים וסדר עדיפות
יש לנתח סיכונים לכל דרישה
מתבצע לאחר פתירת החפיפות והסתירות
סיכון טכני – קשה לבצע
סיכון ביצועי – יכול לפגוע בביצועי מערכת
סיכון אבטחה – פוגע באבטחת המערכת
סיכון אמינות מידע – פגיעה במידע במסד הנתונים
סיכון פיתוח – חסרה יכולת של המפתחים
במפעל התכשיטים יש לשים לב בכל הדרישות הנוגות לשכר ומחירי חומרי גלם
במפעל התכשיטים צוות הפיתוח מצומצם ויש להתחשב בכך
סיכון פוליטי או חוקי
יש לקבוע סדר עדיפות לדרישות
51
נקבע לרוב לפי רצונות הלקוח (מספיק לדרג גבוה ,בינוני ונמוך)
ניהול דרישות -זיהוי וסיווג דרישות
הדרישות נכתבות בשפה רגילה ,למשל:
"יש לפרט את כל חומרי הגלם המפעל"
"יש לעקוב אחר הזמנות מספקים"
יהיו המוני דרישות ויש לעקוב ע"י מספור מסודר
שיטות מספור מקובלות:
מספר זיהוי ייחודי
מספר זיהוי התלוי במבנה מסמך הדרישות
מספר זיהוי התלוי בדרג הדרישות
52
2.6.1נמצא בפרק ,2סעיף 6חלק 1
2.6.1הוא חלק מדרישה , 2תת דרישה 6וכו'
ניהול דרישות -היררכית דרישות ,ומעקב
אחר שינויים
לדרישות יש בדרך כלל מבנה היררכי
זיהוי המבנה מסייע בניתוח ובפיתוח
למשל:
נדרשת שליטה מלאה על הייצור ומצב הזמנות
יש לעקוב אחר הזמנות
יש לעקוב אחר הזמנות לקוחות פרטיים
יש לעקוב אחר הזמנות לקוחות סיטונאים
ניהול ומעקב אחר שינויים בדרישות
53
דרישות משתנות במהלך התכנון והפיתוח יש לעקוב
אחר שינויים אלו
מסמך דרישות (מסמך ייזום)
כל הדרישות שראינו צריכים להיכתב במסמך דרישות
לא קיים פורמט אחיד למסמך כזה
יש תבניות מקובלות באינטרנט ,בספרים ובחברות יעוץ
חברות בד"כ מפתחות תבנית קבועה משלהם
בקורס נשתמש בתבנית (תרגום של )...מתוך הספר:
Requirements Analysis and System Design
)(Leszek A. Maciaszek
54
מבנה מסמך דרישות (מלא)
.1הקדמה
1.1מטרת הפרויקט
1.2סביבה עסקית
1.3השותפים בפרויקט
1.4הצעות לפתרון
1.5תיאור המסמך
.2שירותי המערכת
2.1תחום הגדרה (טווח)
2.2דרישות פונקציונליות
2.3דרישות מידע
55
מבנה מסמך דרישות (המשך)
.3אילוצי מערכת
3.1דרישות ממשק
3.2דרישות ביצועים
3.3דרישות אבטחה
3.4אחר
.4נושאי פרויקט
4.1נושאים פתוחים
4.2לוח זמנים ראשוני
4.3תקציב ראשוני
נספחים (מילון ,ביבליוגרפיה ,מסמכים נלווים)
56
דוגמא – מסמך דרישות
מסמך דרישות של מפעל התכשיטים ישמש דוגמא למסמך
שעליכם להגיש.
57
המסמך נמצא באתר.