Lesson #2

Reminder of lesson 1
Yigal Cohen
Yigal.Cohen@mail.huji.ac.il
yigalco@edu.hac.ac.il

1
• https://aptude.com/blog/entry/understanding
-software-development-with-vertical-slices-vs-
horizontal-slices/
• Understanding Software Development with
Vertical Slices vs Horizontal Slices

2
 Some questions (Inroduction)
1. What is software engineering
2. ** What are the 6 constraints of a project ?
3. ** How can you overcome these constraints ?
4. ** What are the basic activities that appear in all models
(Waterfall, RUP, Agile)?
5. What is a vertical work ? What’s its advantage ?
6. ** What’s “rolling wave planning” ?
7. ** In waterfall model – Can we change a requirements
after the requirements phase ?
8. X: What will you do in order to succeed in your project?
NEXT
3
 ‫מה זאת הנדסת תוכנה ?‬
‫• הנדסת תוכנה מיישמת גישה שיטתית‪ ,‬מבוקרת ומדידה לפיתוח‪ ,‬תפעול‪ ‬ותחזוקה‬
‫‪ ‬של תוכנה‪.‬‬
‫• הנדסת תוכנה מקיפה את מחזור החיים השלם של תוכנה‪ ,‬וכוללת ידע‪ ,‬שיטות‬
‫וכלים עבור‬
‫‪ ‬דרישות‪ ,‬תכנון‪ ,‬בנייה‪ ,‬בדיקות‪ ,‬אינטגרציה‪ ,‬תחזוקה‪ ,‬ניהול תצורה‪ ,‬איכות ועוד‬
‫• הנדסת תוכנה נועדה להפחית את המורכבות שבפיתוח תוכנה‪ ,‬לשפר את‪ ‬אמינות‬
‫‪ ‬התוכנה המפותחת‪ ,‬ולהקטין את עלויות התפעול והתחזוקה‪.‬‬
‫• הנדסת התוכנה שימושית במיוחד בפיתוח מערכות מורכבות הכוללות‪ ‬חומרה‪ ,‬‬
‫תוכנה‪ ‬ותקשורת‪( .‬מתוך ויקיפדיה)‬

‫• הנדסת תוכנה מציעה ומתעדפת אסטרטגיות שונות (איטרציות‪waterfall ,‬‬

‫(‪ …/Continuous testing/integration/Delivery‬לפיתוח התוכנה‪.‬‬
‫‪4‬‬
 Balancing Project Constraints -2

Scope

Resour Risks
ces

Project

Money Time

Quality

5
 ?? Can we enlarge the cake -3
• Scope Scope
– Prioritization: Start with the important and risky things!
– Pareto (20:80)
• Money
– Cost management;
– Reuse! Money
• Quality
– Manage a process, manage continuous testing, continuous integration, continuous
delivery, analyze feedback, automation, defect management, Root cause analysis
• Resources management
– Find the right people, training, mentoring, guidance, challenging; team work, spirit Quality
of excellence, roles & responsibilities
• Time management
– Manage a schedule, Find and manage critical paths, continuous development,
testing & integration
Resour
• Risk management ces
– Assessment and mitigation continuously
Time
Risks
6
 ?? Can we enlarge the cake -3
• Methodologies
• Communication
• Knowledge
• Understanding
• Delegation
• Professionalism
• Team work
• Communication, Communication, Communication

7
 Elementary activities -4
Formal name ?‫מה התכלית‬
• Initiating • Why ?
• Planning • What? when? who?
• Requirements • What?
• Design • How?
• Coding & building • Doing
• Testing • Validating
• Integration • Building
• Maintenance &support • Long term warranty

8
 Vertical Work - 5
• Run a full cycle of development, develop
feature by feature, either sequentially or
concurrently. Use continuous testing and
integration.
• Advantages:
– Avoidance of the big-bang integration and testing
– Having visible and testable results along the
development process
– Having feedback
9
 progressive elaboration
‫ תכנון בגלים‬- rolling wave planning

10
 Can we change the requirements in - 7
?waterfall model
• Yes!
• Use change request process

11
 ?? What to do (1) - 8
1. Plan & work with progressive elaboration (rolling wave
planning) ((‫תכנון בגלים‬
2. Build the global plans in advance without too many details
and update them frequently
3. Work in phases, each phase with visible, beneficial and
measurable results
4. Develop feature by feature and continuously accumulate
them and deliver pieces of the project till you have a
working system
5. Plan, define, design, code, test and integrate in every phase
6. Use methodologies

12
 ?? What to do (2) - 8
7. Encourage Concurrency
8. Fast ramp-up
9. Document !!
10.Use the models with flexibility
11.Enable visibility and transparency
12.Encourage feedback, learning and evolution
13.Use continuous testing, continuous integration
and continuous delivery
14.Develop tools and infrastructures
13
 Lesson #2

2.1 - Requirements Management

14
 ‫למה צריך דרישות כתובות?‬
‫• כדי שכולם ידעו מה צריך לעשות!‬
‫• מי זה כולם?‬
‫• הארכיטקט‪ ,‬המתכנן‪ ,‬המתכנת‪ ,‬הבודק‪ ,‬האינטגרטור‪ ,‬המתחזק‪,‬‬
‫אנשי הצד העסקי‪ .‬כל צוות הפרויקט!‬

‫‪15‬‬
 Requirement – Definition(1)
• A condition or a capability needed by a user or
a client to solve a problem or achieve an
objective
• A condition or a capability that must be met or
processed by a system or a system component
to satisfy a contract, standard, specification or
other formally imposed document (IEEE)

16
 ‫דוגמאות לדרישות לסופרמרקט מקוון‬
‫מערכת "סופרמרקט מקוון" תאפשר לצרכן להזמין דרך‬ ‫•‬
‫האינטרנט מצרכים מתוך רשימה של מוצרים שיש בסופרמרקט‬
‫המערכת תאפשר ניהול מלאי של כל פריט ופריט דרך פעולות‬ ‫•‬
‫הקופות‪ ,‬המחסן‪ ,‬ומסדר המדפים‬
‫המערכת תדווח למערכת הכספים על כל מכירה‪.‬‬ ‫•‬
‫‪.....‬‬ ‫•‬
‫‪.....‬‬ ‫•‬

‫‪17‬‬
 Requirements – Definition (2)
• Anything that drives design choices

18
 ‫)‪Requirements – Definition (3‬‬
‫• מצב או יכולת שיש לעמוד בהם‪ ,‬או שצריכים להיות בידי‬
‫מערכת‪ ,‬מוצר‪ ,‬שירות‪ ,‬תוצאה או מרכיב כדי לענות על‬
‫חוזה‪ ,‬תקן‪ ,‬מפרט או מסמך אחר שמוכתב רשמית‪.‬‬
‫• דרישות כוללות את‪ :‬הצרכים‪ ,‬הרצונות והציפיות של נותן‬
‫החסות‪ ,‬הלקוח‪ ,‬ובעלי עניין אחרים‪ ,‬כשהם מכומתים‬
‫ומתועדים (‪)PMI‬‬

‫‪19‬‬
 ‫‪User Class‬‬
‫• מחלקה של משתמשים באותה מערכת בעלי אותם תכונות‬
‫(‪ )Attributes‬התנהגות (‪ ,)Behavior‬דרישות וצרכים‪.‬‬

‫‪20‬‬
 ‫סופר מרקט אינטרנטי – ‪User Classes‬‬
‫‪ .1‬צרכן ‪ -‬קונה באינטרנט‬
‫‪ .2‬מנהל הנתונים (מזין מוצרים‪ ,‬מחירים‪,‬ועוד) באינטרנט‬
‫‪ .1‬מקדם מכירות (מבצעים)‬
‫ממלא סלים (מלקט)‬ ‫‪.3‬‬
‫קופאי‬ ‫‪.4‬‬
‫מנהל מלאי ‪ /‬מנהל המחסן ‪ /‬מסדר מדפים ‪ /‬קניין‬ ‫‪.5‬‬
‫מנהל החשבונות ‪ /‬כספים‬ ‫‪.6‬‬
‫מנהל משלוחים‬ ‫‪.7‬‬
‫* נתוני מכירות‬ ‫‪.8‬‬
‫* נתוני עבר‬ ‫‪.9‬‬
‫‪21‬‬
‫דוגמא‪ :‬מחלקות משתמשים של סופרמרקט אינטרנטי‬
‫נתוני‬
‫מכירות‪/‬‬
‫‪/‬כספים‬
‫מנהל‬ ‫נתוני עבר‬
‫מלאי‬ ‫צרכן‬

‫מנהל‬ ‫‪ /‬מנהל נתונים‬

‫משלוחים‬ ‫מערכת‬
‫מקדם מכירות‬

‫מנהל‬ ‫ממלא‬
‫חשבונות‬ ‫קופאי‬ ‫סלים‬

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

‫מנהל‬ ‫‪ /‬מנהל נתונים‬

‫משלוחים‬ ‫מערכת‬
‫מקדם מכירות‬

‫מנהל‬
‫חשבונות‬ ‫ממלא‬
‫קופאי‬ ‫סלים‬
‫חברות‬
‫אשראי‬
‫‪23‬‬
 ‫מה זאת "מערכת ידידותית"?‬

‫‪24‬‬
 ‫"מערכת ידידותית"‬
‫‪ .1‬המערכת‪/‬ממשק הלקוח תציע ללקוח את האינפורמציה (כל המוצרים המוצעים‬
‫למכירה) בצורה "נוחה" ו"ידידותית"‪ .‬כלומר‬
‫‪ .1‬תצוגה ברורה ויזואלית ומילולית‬
‫‪ .2‬נגישה לפי החוק‬
‫(ללקויי ראיה‪ :‬מסבירה תמונות ומאפשרת הגדלת טקסט‪ ,‬ללקויי שמיעה‪ :‬כותבת את הנאמר ‪.‬‬ ‫‪.1‬‬
‫ועוד)‬
‫תגובה "מהירה" לכל הקשה (גם הקשה שגויה!)‬ ‫‪.3‬‬
‫אינפורמציה חשובה "למעלה" עם פחות הקשות‬ ‫‪.4‬‬
‫אפשרות למחיקה‪ ,‬להחזרת המחיקה‪ ,‬לעדכון‪ ,‬לעבודה בחלקים‪.‬‬ ‫‪.5‬‬
‫אפשרות למיון לפי קטגוריות‬ ‫‪.6‬‬
‫תתי קטגוריות‬ ‫‪.1‬‬
‫סוגים שונים של קטגוריות‬ ‫‪.2‬‬
‫‪ .2‬תאפשר קיצורי דרך למשתמש ( למשל‪ :‬להיעזר ברשימות לקוח שבנויות סביב קניות‬
‫קודמות‪ ,‬עוד רעיונות??)‬
‫‪ .3‬יציבה‪ ,‬אמינה‪ ,‬לא מאבדת נתונים בזמן נפילה‬
‫‪25‬‬
 ‫סוגי דרישות – היררכיה של דרישות‬

‫‪26‬‬
 ‫עץ דרישות‬
‫דרישות עסקיות‬

‫דרישות פרויקטליות‬

‫דרישות תוכנה‬

‫מנהל‬
‫דרישות‬ ‫לקוח‬
‫‪....‬‬ ‫‪....‬‬ ‫אתר‬
‫קופה‬ ‫בבית‬
‫מכירות‬
‫‪27‬‬
 ‫עץ דרישות‬
‫דרישות עסקיות‬

‫דרישות פרויקטליות‬
‫‪ -‬דרישות לקוח‬ ‫‪ -‬כללים עסקיים‬
‫‪ -‬דרישות איכות‬
‫‪ -‬דרישות מערכת‬
‫‪ -‬ממשקים חיצוניים‬
‫‪ -‬אילוצים‬
‫‪ -‬דרישות פונקציונליות‬ ‫‪ -‬דרישות לא פונקציונליות‬

‫דרישות תוכנה‬

‫דרישות‬ ‫דרישות‬ ‫דרישות‬

‫‪....‬‬ ‫‪....‬‬
‫רכיב ‪3‬‬ ‫רכיב ‪2‬‬ ‫רכיב ‪1‬‬

‫‪28‬‬
 ‫עץ דרישות‬
‫דרישות עסקיות‬

‫דרישות פרויקטליות‬
‫‪ -‬דרישות לקוח‬ ‫‪ -‬כללים עסקיים‬
‫‪ -‬דרישות איכות‬
‫‪ -‬דרישות מערכת‬
‫‪ -‬ממשקים חיצוניים‬
‫‪ -‬אילוצים‬
‫‪ -‬דרישות פונקציונליות‬ ‫‪ -‬דרישות לא פונקציונליות‬

‫דרישות תוכנה‬

‫מנהל‬
‫דרישות‬ ‫לקוח‬
‫‪....‬‬ ‫‪....‬‬ ‫אתר‬
‫קופה‬ ‫בבית‬
‫מכירות‬
‫‪29‬‬
 ‫באמת? צריך דרישות ותכנון?‬
‫מי זה ??‬

‫‪30‬‬
 ‫מבנה מערכת של סופרמרקט אינטרנטי‬
‫עם מכשירים הקפיים‬
‫נתוני‬
‫מכירות‬
‫מנהל‬ ‫נתוני‬ ‫צרכן‬
‫מלאי‬ ‫עבר‬

‫מהל‬ ‫‪ /‬מנהל נתונים‬

‫משלוחים‬ ‫מערכת‬ ‫מקדם מכירות‬

‫מנהל‬ ‫ברקוד‬
‫חשבונות‬ ‫ממלא‬
‫סלים‬
‫קופאי‬ ‫משקל‬
‫אלקטרוני‬
‫חברת‬ ‫קורא‬
‫אשראי‬ ‫כרטיסי‬ ‫משקל‬
‫ברקוד‬ ‫אלקטרוני‬
‫אשראי‬ ‫‪31‬‬
 ‫שאלה קצרה‬
‫• תן דוגמה לדרישה עבור מערכת "סופרמרקט באינטרנט"‬
‫שמקורה איננו בלקוח אלא בגוף חיצוני‪.‬‬

‫‪32‬‬
Levels of Requirements
Relationships of basic types of requirements
 Functional Non Functional
Business
requirements

Vision and scope document

User Business
Requirements rules
Quality
Attributes
Use case document
External
System Functional Interfaces
requirements Requirements
Constraints

Software Requirements Spec

33
 Functional Non Functional
Business
requirements

Vision and scope document

User Business
Requirements rules
Quality
Attributes

External
System Functional Interfaces
requirements Requirements
Constraints

Software Requirements Spec

34
 Levels of requirements
• Business requirements –
– High level objectives of the organization or customer who
requests the system.
– Vision and scope Document=Biz requirements =Marketing
Requirements=Project charter
– Examples: (1) To enable the user to purchase a ringtone; (2)
To encourage the user to purchase as many ringtones as
possible

– What are the business requirements of the ‘Supermarket’?

35
‫(חלקי)‬ ‫דרישות עסקיות ‪ -‬סופרמרקט אינטרנטי‬
‫‪ .1‬המערכת תאפשר ניהול סופרמרקט שחלקו מקוון (דרך האינטרנט) וחלקו חנות‬
‫פיזית‬
‫‪ .2‬המערכת תחבר בין הלקוח בבית‪ ,‬מנהל הנתונים‪ ,‬הקופאי‪ ,‬ממלאת הסלים‬
‫(מלקטת)‪ ,‬מנהל המלאי‪ ,‬מנהלי הכספים‪ ,‬מנהל המשלוחים ופעולות של האחד‬
‫ישמשו לפעילות של כל אחד אחר‪.‬‬
‫‪ .3‬המערכת תעזור לשמר לקוחות‬
‫‪ .4‬מערכת תהיה בעלת ממשקי משתמש טובים מהמתחרות‬
‫‪ .5‬המערכת תנהל מלאי קיים בחנות‪ ,‬נתוני מכירות וכספים‪ ,‬ותשמור נתוני עבר‬
‫‪ .6‬המערכת תוכל להתחבר עם מערכות קיימות לניהול מחסן ו‪/‬או כספים וחברות‬
‫אשראי‪.‬‬
‫‪ .7‬המערכת תנתן להתאמה בקלות לכל סופרמרקט שכונתי או מעל גודל מסוים‬
‫‪36‬‬ ‫‪ .8‬המערכת תפיק דוחות לפי החוק ובפרט דוחות מע"מ‪.‬‬
 ‫שאלה קצרה‬
‫• מהן הדרישות העסקיות של ארגון "יד שרה"?‬

‫‪37‬‬
 Functional Non Functional
Business
requirements

User Business
rules
Requirements Quality
Attributes

Use case document

System External
Functional Interfaces
requiremen
ts Requirements
Constraints

Software Requirements Spec

38
 Levels of requirements
• User requirements
– What the user will do with the product ? User
experience, user goal, actor goals
– Examples :use-case – “Purchase a ringtone”
– Pay attention that possibly there are several user-
classes

39
 ‫דוגמאות לדרישות משתמשים בסופרמרקט‬
‫• צרכן‬
‫– ממשק "מהיר"‪ ,‬ממשק עם תמונות‪ ,‬אפשרות להסתמך ולהשתמש‬
‫ברשימות קודמות‪ .‬קבלת מידע ברור על מבצעים‪.‬‬
‫• קופאי‬
‫– אפשרות להקליד מוצרים‪ ,‬מחירים‪ ,‬כמויות‪.‬‬
‫– אפשרות לקריאת ברקוד ממוצרים‪ ,‬וקבלת המחיר אוטומטית‪ ,‬אפשרות‬
‫לשקילה ודיווח אוטומטי לרשימה‪ ,‬אפשרות לסיכום אוטומטי לכל לקוח‬
‫• מנהל מחסן‬
‫– דיווח על כל מכירה‪ ,‬ועל הוספת מוצרים לסופרמרקט‪ ,‬אפשרות לראות‬
‫את מצב המלאי בתוך החנות‬

‫‪40‬‬
 ‫דוגמא לדרישות משתמשים (חלקי)‬
‫סופרמרקט אינטרנטי‬
‫‪ .1.1‬המערכת תאפשר ניהול סופרמרקט אינטרנטי ורגיל במקביל‪.‬‬
‫‪ 1.2‬המערכת תספק לצרכן ממשק לקוח דרכו יוכל לקנות מצרכים‪.‬‬
‫‪ 1.3‬המערכת תנהל בסיס נתונים ובו רשימה של כל מוצרי הסופרמרקט ותספק ממשק למנהל הנתונים דרכו‬
‫יוכל ל הוסיף ולגרוע מוצרים‪ ,‬לשנות‪ ,‬לראות את המצב הנכון (כולל מלאי) בכל רגע נתון‪ .‬ולבצע כל מה‬
‫שצרכן יכול לבצע‪.‬‬
‫‪ 1.4‬המערכת תעביר לממשק לממלא הסלים את בקשת הלקוח לקניה‪.‬‬
‫‪ 1.5‬המערכת תקרא את פעולות הקופאי (בהזמנות אינטרנטיות זה ממלא הסלים) בזמן דכירת החשבון כדי‬
‫להפיק חשבון ללקוח וכדי לעדכן את מצב המלאי בבסיס הנתונים‬
‫‪ 1.6‬המערכת תקרא את מצב המלאי ותעדכן את ממלא המדפים ואת המחסנאי‬
‫‪ 1.7‬המערכת תאפשר למנהל החשבונות לראות את מצב המכירות ובבסיס הנתונים‬
‫לקבל סיכומים‬
‫‪ 1.8‬המערכת תשמור נתונים בבסיס הנתונים כדי לאפשר מבצעים לאורך זמן‬
‫‪ 1.9‬המערכת תשמור על פרטיות הלקוח (לא פונקציונלי)‬
‫‪ 1.10‬המערכת תשמור על בטיחות הנתונים (לא פונקציונלי)‬
‫‪41‬‬
‫‪ 1.11‬המערכת‪/‬ממשק הלקוח יציע ללקוח את כל המוצרים המוצעים למכירה בצורה "נוחה" ו"ידידותית"‪.‬‬
 Functional Non Functional
Business
requirements

User Business
Requirements rules
Quality
Attributes

System External
Interfaces
requirem Functional
Requirements
ents Constraints

Software Requirements Spec

42
 Levels of requirements
• System requirements
– The top-level requirements that contain multiple
subsystems
– Example: The system shall be able to store
ringtones, to enable the user to purchase them
from his cellular phone, and let him associate
different ringtones with different groups of people

43
 ‫דוגמאות לדרישות מערכת בסופרמרקט‬
‫• המערכת תוכל להתקשר דרך האינטרנט עם הצרכנים‪.‬‬
‫• המערכת תוכל להתחבר עם מערכות לניהול כספים ומחסן‬
‫• המערכת תוכל להתקשר עם "כל" חברות האשראי‬
‫(רשימה)‬

‫‪44‬‬
 Functional Non Functional
Business
requirements

User Business
Requirements rules
Quality
Attributes

System External
Functional Interfaces
requireme Requiremen
nts ts Constraints

Software Requirements Spec

45
 Levels of requirements
• Functional Requirements
– The functionality that the developer must build
into product.
– Uses the traditional "shall statements"
– Separate to user classes and include all of them
– Example: The system shall enable the user to
dialogue with the central station when he
purchases a ringtone; (2) a friendly website will
enable the user to purchase a ringtone via his PC.

46
 ‫דוגמא לאיפיון דרישות ‪ -‬ניהול קופה בסופרמרקט‬
‫גרסה ‪1‬‬

‫פרק ‪ - 2‬ניהול קופה‬

‫‪ 2.1‬תשתיות הקופה‬
‫‪ - 2.1.1‬הקופה תוכל להתממשק עם האתר‬
‫‪ – 2.1.2‬הקופה תוכל להתממשק ישירות עם קורא ברקוד‬
‫‪ – 2.1.3‬הקופה תוכל להתממשק ישירות עם משקל אלקטרוני‬
‫‪ – 2.1.4‬הקופה תוכל להתממשק ישירות עם מקלדת‬
‫‪ – 2.1.5‬הקופה תוכל להתממשק ישירות עם מסך‬
‫‪ – 2.1.6‬הקופה תוכל להתממשק ישירות עם קורא כרטיסי אשראי‬
‫‪ – 2.1.7‬הקופה תוכל להתממשק עם חברת האשראי דרך המערכת‬

‫‪48‬‬ ‫מה חסר?‬

 ‫מבנה של מערכת קופה‬
‫עם מכשירים הקפיים‬

‫מערכת‬
‫חברת‬
‫אשראי‬

‫מקלדת‬ ‫קופה‬ ‫מסך‬

‫קורא‬
‫כרטיסי‬ ‫משקל‬
‫אשראי‬ ‫קורא‬ ‫אלקטרוני‬
‫ברקוד‬
‫‪49‬‬
 ‫דוגמא לאיפיון דרישות ‪ -‬ניהול קופה בסופרמרקט‬
‫גרסה ‪2‬‬
‫פרק ‪ - 2‬ניהול קופה‬
‫‪ 2.1‬תשתיות הקופה‬
‫‪ - 2.1.1‬הקופה תוכל להתממשק עם האתר ולקרוא ממנו את מחירי המוצרים‬
‫‪ – 2.1.2‬הקופה תוכל להתממשק ישירות עם קורא ברקוד ולזהות את המוצר‬
‫‪ – 2.1.3‬הקופה תוכל להתממשק ישירות עם משקל אלקטרוני ולקרוא ממנו אוטומטית את המשקל ולהכפיל‬
‫את המשקל במחיר‬
‫‪ – 2.1.4‬הקופה תוכל להתממשק ישירות עם מקלדת ולקרוא ממנה את שם המוצר‪ ,‬המחיר‪ ,‬המשקל והכמות‬
‫‪ – 2.1.5‬הקופה תוכל להתממשק ישירות עם מסך שיציג את פרטי המוצר הנוכחי ואת רשימת הקניות‬
‫המתהווה‬
‫‪ – 2.1.6‬הקופה תוכל להתממשק ישירות עם קורא כרטיסי אשראי להעביר אליו את המחיר ולקבל ממנו את‬
‫פרטי האשראי‬
‫‪ – 2.1.7‬הקופה תוכל להתממשק עם חברת האשראי דרך המערכת להעביר אליה את פרטי האשראי ולקבל‬
‫ממנו אישור (או דחיה) של התשלום‬

‫מה חסר?‬

‫‪50‬‬
 ‫דוגמא לאיפיון דרישות ‪ -‬ניהול קופה בסופרמרקט‬
‫גרסה ‪3‬‬
‫‪ 2.2‬פונקציונליות של הקופה‬
‫‪ – 2.2.1‬הקופה תוכל לנהל חשבון לכל לקוח‪.‬‬
‫‪ – 2.2.2‬הקופאי יוכל לפתוח חשבון ללקוח‪ .‬בעת פתיחת חשבון ללקוח יהיה סך החיוב אפס‪.‬‬
‫‪ – 2.2.3‬כל מוצר שיעבור מול הברקוד ויהיה עם "תוית ברקוד"‪ ,‬יכנס ויתווסף לרשימה‬
‫‪ – 2.2.4‬כל מוצר שישקל על המשקל לאחר קריאת קוד הברקוד או הקלדת הקוד או המחיר יתווסף לרשימה‬
‫‪ - 2.2.5‬לכל מוצר שיתווסף לרשימה תהיה רשומה עם‪ :‬שם‪ ,‬מספר ברקוד‪ ,‬משקל המוצר (אם יש) ‪,‬מחיר התחלתי‪,‬‬
‫אחוז הנחה ומחיר סופי‪.‬‬
‫‪ -2.2.6‬הקופה תקרא את המחיר ‪ ,‬אחוז המע"מ וואחוז ההנחה מהאתר **‬
‫‪ – 2.2.7‬הקופאי יוכל לסיים את הקניה ואת הזנת המוצרים לחשבון הלקוח‬
‫‪ – 2.2.8‬בסוף הקניה תקרא הקופה את שורת המבצעים ותפעיל אותם על המוצרים שנקנו‪ ,‬תסכם את המוצרים‬
‫שבחשבון‪ ,‬ותדפיס את החשבון‪.‬‬
‫‪ – 2.2.9‬הקופה תוכל לנהל מספר חשבונות בו זמנית‬
‫‪ – 2.2.10‬הקופה תציג את החשבון על המסך במקביל לצבירת החשבון‬
‫‪ – 2.2.11‬הקופאי יוכל להקליד את מספר ההזמנה‪ ,‬והתוכנה תעביר את תוכן החשבון לאתר לחיוב עבור הלקוח‪**.‬‬
‫‪ – 2.2.12‬הקופה תמתין לאישור החיוב מהאתר ואז תדפיס את החשבון ותסגור את הקניה‪.‬‬
‫‪ ( – 2.2.13‬הקופה תחייב תשלום בכרטיס אשראי לפי מספר הזמנה)‬

‫‪51‬‬
 ‫דוגמא לאיפיון דרישות ‪ -‬ניהול אתר‬
‫פרק ‪ - 3‬ניהול האתר‬
‫‪ 3.1‬מנהל האתר יוכל לשלוט באתר דרך ממשק ייעודי‬
‫‪ 3.2‬מנהל האתר יוכל לראות את כל המוצרים המוצעים למכירה‬
‫‪ 3.3‬מנהל האתר יוכל לראות סוגי מוצרים לפי סוגים‬
‫‪ 1.4‬כל סוג מוצר יהיה‪ :‬שם‪ ,‬מספר‪ ,.......‬השלם את הרשימה‬
‫‪ 1.5‬מנהל האתר יוכל להוסיף‪/‬להוריד מוצרים‬
‫‪ 1.6‬מנהל האתר יוכל לשנות מחירים‬
‫‪ 3.7‬מנהל האתר יוכל לקבוע מבצעים‬

‫מה חסר ? מה מוסתר ?‬

‫‪52‬‬
 Functional Non Functional
Business
requirements

User Business
Requirements rules
Quality
Attributes

System External
Interfaces
requireme Functional
Requirements
nts Constraints

Software Requirements Spec

53
 Levels of requirements
• Business rules
– Corporate policies, government regulations,
industry standards, computational algorithms.
– Exist outside of the project boundaries but impact
the project
– Example: (1) the ringtone purchase will comply
with communication office guidance XYZ (2) the
ringtone dialogue will use only the relevant section
(a,b,c) of standards X,Y,Z.

54
 ‫דוגמה לכללים עסקיים ‪ -‬סופרמרקט‬
‫המערכת תחייב במע"מ לפי חוק ותעביר את החיובים‬ ‫•‬
‫למערכת הכספים‬
‫המערכת תשתמש בממשקים אינטרנטיים הרגילים‬ ‫•‬
‫המערכת תשתמש בכלים למניעת פריצה [שם מוצר]‪,‬‬ ‫•‬
‫לשמירה על פרטיות [שם מוצר] ‪,‬ולמעקב אחרי נפילות‬
‫[שם מוצר]‬
‫המערכת תתממשק עם כל חברת אשראי לפי הכללים של‬ ‫•‬
‫חברת האשראי‬

‫‪55‬‬
 Functional Non Functional
Business
requirements

User Business
Requirements rules
Quality
Attributes

System External
Interfaces
requireme Functional
Requirements
nts Constraints

Software Requirements Spec

56
 Levels of requirements
• Quality attributes
– Availability, Eefficiency, flexibility, integrity,
interoperability, reliability, robustness,
performance, usability
– Maintainability, Portability, Reusability, Testability
– Example: (1) The ringtone will not use more
bandwidth than a regular conversation (2) The
ringtone DB will have a GUI to manage it

57
 Quality attributes
Important to the user Important to the Developer
 Availability  Maintainability
 Efficiency  Portability

 Flexibility  Reusability
 Integrity  Testability
 Interoperability

 Reliability

 Robustness

 Usability

 Performance

58
 User Quality attributes (1)
• Availability
– The up-front time of the system (see: MTBF, MTTR,
load balancing)
• Efficiency
– Using of system resources (CPU, Disk space, etc.)
• Flexibility
– Expandability – the easiness of appending features to
the system
• Integrity
– Safety, security, privacy, keeping data, manage access
privileges
59
 ‫דוגמא‪ :‬דרישות לתכונות איכות‬
‫• זמינות (‪)availability‬‬
‫– המערכת תהיה זמינה ‪99.999‬‬
‫• יעילות (‪)Efficiency‬‬
‫– המערכת תרוץ על מחשב [דגם] והלקוח יכול לרוץ על מחשב [דגם ‪]2‬‬
‫• גמישות ((‪Flexibility‬‬
‫• בטיחות נתונים‬
‫• הנתונים יגובו באופן מיידי בבסיס נתונים נוסף‬
‫• פרטיות‬
‫• נתוני המכירות ישארו חסויים‬
‫• שמירת נתונים‬
‫• ניהול הרשאות‬
‫• רק משתמשים רשומים יוכלו להזמין מוצרים‬
‫• לכל ממשק אחר יצטרכו הרשאה מפורשת עם ססמא‬
‫‪61‬‬
 User Quality attributes (2)
• Interoperability
– Easiness of interfacing with other systems
• Reliability
– The probability of SW executing without a failure
• Robustness
– Fault tolerance – Continue to work when error or a
failure occur
• Usability
– Human Engineering
• Performance
– Throughput & latency
62
 Developer Quality attributes
• Maintainability
– How easy is to correct defect, to install a new software, to make
periodical maintenance
• Portability
– The effort required to migrate a piece of SW to another
environment (e.g. Win to Linux)
• Reusability
– The effort required to migrate a piece of SW to another
application
• Testability
– The required effort to test the system (debuggers, loggers, tools)

63
 ‫שאלה קצרה‬
‫ שלושת דרישות האיכות החשובות ביותר של‬,‫– מהן לדעתך‬
?‫הסופרמרקט המקוון‬

– What are the quality attributes of an online

Supermarket?
• What is ”Reliability” for the customer? For the
Supermarket ?
• Customers‘ Privacy
• Security

64
 Functional Non Functional
Business
requirements

User Business
Requirements rules
Quality
Attributes

System External
requireme Functional Interfaces
Requirements
nts Constraints

Software Requirements Spec

65
 Levels of requirements
• External interfaces
– The boundaries of the system
– Example: The ringtone dialogue will be able to
work with any cellular phone that complies with
the rules of the Communication Office

66
 ‫‪External Interfaces‬‬

‫?ש‪ .‬אילו ממשקים חיצוניים יש בסופרמרקט המקוון‬

‫‪.‬ת‬
‫– חברות אשראי‬
‫– מערכת מע"מ (ממשק לא מקוון)‬
‫– מערכת הכספים (?)‬
‫– מערכת המלאי והמחסנים (?)‬

‫‪67‬‬
 Functional Non Functional
Business
requirements

User Business
Requirements rules
Quality
Attributes

System External
Interfaces
requireme Functional
Requirements
nts Constraints

Software Requirements Spec

68
 Levels of requirements
• Constraints
– Restriction to the choices available to the
developer for design the system
– Example: The ringtone subsystem shall be a part of
the cellular system X, and will comply with all its
rules (Programming language, complier, builder,
database, development procedures)

69
 ‫דוגמא‪ :‬מגבלות ‪ -‬סופרמרקט‬
‫• המערכת תיכתב בשפת [שם שפה]‬
‫• בסיס נתונים יהיה [שם בסיס נתונים]‬
‫• המערכת תשתמש בכלים‬
‫– למניעת פריצה [שם מוצר[‬
‫– לשמירה על פרטיות [שם מוצר]‬
‫– ולמעקב אחרי נפילות [שם מוצר]‬

‫‪70‬‬
Levels of Requirements
Relationships of basic types of requirements
 Functional Non Functional
Business
requirements

Vision and scope document

User Business
Requirements rules
Quality
Attributes
Use case document
External
System Functional Interfaces
requirements Requirements
Constraints

Software Requirements Spec

71
Software Requirements Specification (SRS)

– System Description and diagram

– Relevant Business rules
• Industrial standards, Governments rules
– Constraints
– External interfaces
– Functional requirements
• Use cases and “Shall sentences”
– Relevant quality attributes
• Performance, scalability, etc…

72
 ‫סקר דרישות תוכנה –‬
‫‪Software Requirements Review‬‬
‫האם הדרישות העסקיות מכוסות?‬ ‫•‬
‫האם דרישות המערכת מכוסות?‬ ‫•‬
‫האם ה‪ Business Rules-‬מכוסות?‬ ‫•‬
‫האם הדרישות הלא פונקצוינליות מוגדרות‪ ,‬ברורות‬ ‫•‬
‫ומתאימות לפרויקט?‬
‫האם הממשקים החיצוניים מוגדרים?‬ ‫•‬
 – ‫סקר דרישות‬
Software Requirements Review

Each Requirement The entire SRS

SMART is acronym of  Complete
 Specific,  Consistent
 Manageable,  Manageable
 Assignable,  Traceable
 Realistic, Readable  Hierarchical
 Testable, Traceable, Time-  Modifiable
related
 ‫הנדסת דרישות‬

‫‪79‬‬
 Requirements Engineering
Requirements
engineering

Requirements Requirements
Development Management

Elicitation Analysis Specification Verification

80
 – Requirements Development
( Elicitation‫ הפקה‬,‫(שליפה‬
• Identifying the product’s expected user class
• Eliciting needs from individuals who
represent each user class (‫)מאד חשוב אבל לא נתרגל‬
• Understanding user tasks and goals and
business objectives with which those tasks
align

81
 ‫שאלה קצרה‬
‫• עם מי היית מדבר לצורך הכנת דרישות לסופרמרקט מקוון?‬

‫‪82‬‬
 Requirements Development - Analysis
• Analyzing the information received from users to
distinguish their tasks and goals from functional
requirements, nonfunctional requirements, business
rules, suggested solutions, and extraneous information
• Allocating portions of the top-level requirements to
software components defined in system architecture
• Understanding the relative importance of quality
attributes
• Negotiating implementation priorities
83
Requirements Development - Specification

• Translating the collected user needs into

written requirements specification and modes

84
 Requirements Development - Validation

• Reviewing the documented requirements to

ensure a common understanding the users’
stated requirements and to correct any
problems before development group accepts
them
Validate: Correctness, Completeness,
Consistency

85
 ‫ מרכזיה‬An Example of Requirements Development
Private switchboard (1) – - ‫פרטית‬

• User classes:
– Owners, users, customers with special needs, neighbor switchboards
• Eliciting needs:
– Functionality, Privacy, overruling, Multi-site organization, growing
organization, security
• Business objectives:
– Hierarchical organization, mobile users
• Analyzing:
– Functional: Overruling conversation, Virtual phone number, decryption
– Nonfunctional: Capacity, redundancy, scalability
– Business rules: The Communication Office

86
 Requirements Engineering
RE-Evaluate

Elicitation Analysis Specification Verification

Clarify Rewrite

Correct & close gaps

89
 Levels of requirements Documents
• Requirements development is telescopic
process and requirements documents should
be hierarchical

90
Requirement management – Change Request

• Change request is a process that

– Starts with proposal for a change
– Details the steps that were actually done
– Analyze the impact on the other steps
– Reviewed
– and approved by the CCB (Change Control Board).

91
• Thank you!

92
 Product Manager job description
• We are looking for a Product Manager to join our growing product
team
• In your role, you will be part of the product team responsible on
identifying and capturing key requirements and business needs,
define market use cases and translate them into clear product vision
with a proper roadmap strategy. (it’s probably easier said than done)
• We define the user story (and that is a big story, believe us) and build
our product backlog in partnership with the engineering team to
ensure quality on-time release delivery. (Quality. On-time. It’s not a
fairy tale)
• We collaborate with variety groups in our company such as sales,
marketing, engineering and operations in a pursue to create a great
partnership, build a better product and make our customers happy.

93