1. ניתוח ועיצוב מערכות מידע
, תשע"ג – ב'
מרצה: רמי פוזיס
מתרגלים: משה אונגר
יסמין בוקובזה

2. What is a software system?
Computer programs and associated documentation:
Requirements;
Analysis and Design models;
User manuals;
Software products may be
Generic - developed to be sold to a range of different customers:
PC software such as Excel or Word.
Bespoke (custom) - developed for a single customer according to their specification.
Object-Oriented Analysis and Design
Mira Balaban and Arnon Sturm

3. Keys for Building a Good System
Modularity: a modular system consists of :
encapsulated modules
with
dependencies among them.
Flexibility: a flexible system requires
minimal changes
in order to be adapted for new customers / circumstances
Object-Oriented Analysis and Design
Mira Balaban and Arnon Sturm

4. Object-Oriented Analysis and Design
The Details Matter
Applying changes to a program
Automatic refactoring (rename, extract code, pull down/up etc.)
Search and replace
Validate changes by tracking compile errors and running tests
Applying changes to documentation
Read, search… and replace?
Changing dependency or constraint definition does not propagate throughout the document
No ability to validate changes
Object-Oriented Analysis and Design
Mira Balaban and Arnon Sturm

5. What is a software development process?
An organized set of activities whose goal is the development or evolution of software.
Generic activities in all software development processes are:
Specification - what the system should do and its development constraints.
Development - production of the software system.
Validation - checking that the software is what the customer wants.
Maintenance - changing the software in response to changing demands.
Software development processes yield better software systems.
Object-Oriented Analysis and Design
Mira Balaban and Arnon Sturm

6. Incremental development (1)
Development and delivery is broken into increments:
Delivering part of the required functionality.
User requirements are prioritised and the highest priority requirements are included in early increments.
Object-Oriented Analysis and Design
Mira Balaban and Arnon Sturm

7. Incremental development (2)
Build 1
Analysis
Build 2
Design
Analysis
Implementation & Integration
Design
Build n
Delivery
Implementation& Integration
Analysis
Delivery
Design
Implementation
& Integration
Analysis Group
Design Group
Implementation Group
Delivery
Object-Oriented Analysis and Design
Mira Balaban and Arnon Sturm

8. Incremental development (3)
Advantages
System functionality is available earlier.
Early increments act as a prototype:
Help elicit requirements for later increments.
Lower risk of overall project failure.
Object-Oriented Analysis and Design
Mira Balaban and Arnon Sturm

9. Requirements

10. הנפשות הפועלות לקוח איש מחירות מנתח מערכות מפתח זמן צורך שמיים וארץ
לקוח איש מחירות מנתח מערכות מפתח
זמן
צורך
שמיים וארץ
מקדמה
קדימה לעבודה
אברה-כדברה
מימוש
מערכת עובדת
רב תודות והון תועפות

11. חברת הלקוח יוזם מנתח מערכות משתמש ספק זמן צורך חקר מצב קיים
יוזם מנתח מערכות משתמש ספק
זמן
צורך
חקר מצב קיים
אפיון ראשוני
דרכי פעולה
אפשריות
הערכת
דפ"אות
הכנת RFP
RFP
אפיון, ניתוח
עיצוב ראשוני
תכנון
הצעת פרוייקט
הערכת הצעות
חוזה

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

13. נקודה על המסך מסמך ייזום המזמין הוא אדם פרטי
מפתח
לקוח
מסמך ייזום
המזמין הוא אדם פרטי
למזמין חסרות נקודות על המסך. הוא אוהב לראות נקודות.
תיאור המערכת: תוכנה שתציג נקודה על המסך!
הלקוח הוא גם המשתמש ובעל העניין היחיד במערכת.
אלטרנטיבות:
תוכנת Paint – חוסר: צריך לצייר את הנקודה בעצמך.
Stars screen saver – חוסר: לא ניתן לעבוד על המחשב בעת הצגת הנקודות.

14. נקודה על המסך: הצעת פרוייקט
מפתח
לקוח
דרישות חומרה ותוכנה: מחשב PC רגיל + מסך מחשב
מע' הפעלה: WIN-XP ומעלה.
דרישות פונקציונליות:
התוכנה נפתחת בחלון עם סרגל כלים המכיל בין היתר כפתור עם תווית "צייר".
בעת לחיצה על הכפתור תופיע נקודה
המשתמש יוכל לשלוט בצבע של הנקודה ובמיקום שלה.
דרישות לא פונקציונליות:
נקודה תצויר תוך לכל היותר שנייה אחת מרגע לחיצה על הכפתור
המערכת לא שומרת מידע על דיסק קשיח
מגבלות:
הנקודות שהופיעו קודם לכן לא תמחקנה.
הנקודות שצוירו לא יופיעו בהפעלה חוזרת של התוכנה.
התוכנה לא מספקת אפשרויות של שמירה, טעינה, או ייצוא של נקודות לקובץ.
מסירה :
תוך יומיים באמצעות קובץ התקנה על CD.
עלות:
100$ בעת מסירה

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

16. שאלות מפתח
למה?
צריך את זה
מה?
זה צריך לעשות
איך?
זה יעשה

17. בכל הרמות של פיתוח המערכת!
שאלות מפתח
למה?
ייזום
מה?
דרישות
איך?
עיצוב
בכל הרמות של פיתוח המערכת!

18. The Requirements Process Why Are Requirements Important?
Top factors that caused project to fail (Standish, 1995)
Incomplete requirements (13%)
Lack of user involvement (12%)
Lack of resources (11%)
Unrealistic expectations (10%)
Lack of executive support (9%)
Changing requirements and specifications (9%)
Lack of planning (8%)
System no longer needed (7%)
Some part of the requirements process is involved in almost all of these causes
Requirements error can be expensive if not detected early
Prof. Mark Last

19. Categories of Requirements Example: MRP System / Customer Orders
Requirements that absolutely must be met
The customer name, ordered quantities, and promised due date must be recorded for each order
Requirements that are highly desirable but not necessary
The date of receiving the order should be recorded
Requirements that are possible but could be eliminated
Store the original due date requested by the customer
Prof. Mark Last

20. Requirements Elicitation Stakeholders and their roles
Clients: pay for the software to be developed
Customers: buy the software after it is developed
Users: use the system
Domain experts: familiar with the problem that the software must automate
Market Researchers: conduct surveys to determine future trends and potential customers
Lawyers or auditors: familiar with government, safety, or legal requirements
Software engineers or other technology experts
Prof. Mark Last

21. Requirements Elicitation or what the stakeholders want?
Interviewing stakeholders
Reviewing available documentations
Observing the current system (if one exists)
Apprenticing with users to learn about user's task in more details
Interviewing user or stakeholders in groups
Using domain-specific check lists
Brainstorming with current and potential users
Prof. Mark Last

22. Making Requirements Testable General Guidelines
Specify a quantitative description for each adverb and adjective (nice, fast, large, etc…)
Replace pronouns with names of specific entities
Make sure that each noun is defined in exactly one place
Prof. Mark Last

23. Types of Requirements Two Kinds of Requirements Documents
Requirements definition: a complete listing of everything the customer wants to achieve
Describing the entities in the environment where the system will be installed
Requirements specification: restates the requirements as a specification of how the proposed system shall behave
Prof. Mark Last

24. Characteristics of Requirements
Correct
Consistent
Unambigious
Complete
Feasible
Relevant
Testable
Traceable
Prof. Mark Last

25. Elicitation Methods ARM (Accelerated Requirements Method)
Preparation Phase: goals, objectives, preliminary scope, success measures, participants, preliminary schedule.
Facilitated Session Phase: collect the functional requirements
Deliverable Closure Phase: polish, publish, and disseminate
IBIS (Issue-Based Information Systems)
During design of complex systems stakeholders bring their personal expertise and perspective
Any problem, concern, or question may is an issue that may require discussion and resolution
JAD (Joint Application Development)
Designed for development of large computer systems
Fact finding and information gathering results in security goals and artifacts.
Validate goals and artifacts.
In our case studies, we decided to use JAD, ARM, and IBIS on three different projects. These three methods were subjectively ranked to be the most suitable candidates for the case studies, given the time and effort constraints that we were working with. We considered not just the total score. Implicitly, the learning curve was an important factor, since the students were constrained to complete the work in a single semester. Also, the team attempted to select methods that were not too similar to one another, so as to have some variety.

26. ARM (Accelerated Requirements Method) Hubbard et al. 2000
Elicit, categorize, and prioritize requirements
Preparation
Session
Deliverable

27. Preparation Phase
Define goals, objectives, and project success criteria (PSC).
Define objectives and preliminary scope of the session.
Establish partitions and identify participants.
Determine environmental and logistical aspects.
Establish expectations for participants.
Communicate with participants.

28. Initial questioner What are the goals of this project? 1
What are the objectives of this project? 2
What are the project success criteria? 3
What is the scope for this project? 4
What are the partitions of this project? 5
Who are the participants? 6
What are the environmental aspects? 7
1. The goal statement usually describes the purpose of the project in one sentence.
2. The objective statement is derived from the goal and can be treated as a goal with a detailed statement. A project can typically have five to seven objectives.
3. PSC are used to describe what factors can help the project become a successful project. PSC can be both business and functional criteria.
4. In-scope items are topics that are suitable to discuss in the Session Phase. Out-of-scope items are topics that are unsuitable to discuss in the Session Phase.
5. According to the goal, objective, PSC, and scope, a partition breaks the project into small pieces that are correlated with one another and highly cohesive.
6. According to the goal, objective, PSC, scope, and partition, the participants are those who are suitable to join the meeting.
7. To have a successful meeting, the team should prepare environmental and logistical arrangements that include room selection, technology arrangements, and refreshments.

29. Session Phase executive sponsor commentary scope closure
brainstorm, organize, and name (BON)
details
prioritization
participant feedback
Supply note cards for participants to write more sentences.
Supply tape to attach cards to the wall.
Provide the following items to aid team members:
detailed individual job assignments
security requirement form: The words written in the cards could have been too small to read, so the team prepared a form that could project the content of the cards on the screen.
grouping form: In the Organize step of the process (Step 3), the team could show the categorized result on the screen immediately.
details form: In the Detail step (Step 4), the team could fill in the outputs from the participants on the form.
Supply package for each participant, including
memorandum
prioritization form
feedback form
Session Phase slides
Preparation Phase slides
scratch paper
note cards (four)

30. BON: Brainstorm, Organize, and Name
Based on their professional experience and security knowledge, the participants were asked to write down seven important security requirements on scratch paper within the time limit of seven minutes.
Write down the top three or four security requirements on cards within three minutes.
The enforcement and usability of an access control system
The preservation of data integrity
Security must be manageable and not hinder business (where possible)
Data integrity
The ability to securely transmit data to remote sources
Information must be kept private from the outside world.
Integrity
Consistent application program interfaces (APIs)
Authentication and access control
Accountability (who did what, when, how...)
There must be a strong, reliable authentication process
Granular access to data for users (operators) and customers
Strong authentication
Indelibility (deletions and retractions are logged)
Executive Sponsor Commentary
Due to time constraints, the team decided to omit this step. Also, the team understood that the participants already possessed the information, which would have been conveyed during the Preparation Phase. However, the team did provide a brief introduction to ARM and the procedures of the Session Phase meeting.
Scope Closure
The team also decided to omit this step because its primary purpose is to prepare the participants for the following steps. However, since the participants worked closely together in the same department, they required little preparation time to familiarize themselves with security issues.
Focus question
An important security requirement of the Beta Application is __
Integrity (assurance in data protection and validity)
Reduce or eliminate risks of inappropriate behavior
Role-based, restricted view, edit, and action access (e.g., summary report information, public for particular people)
Represent and support segmented disclosure.
Confidentiality (encryption, etc.)
Selectively secure communication with outside entities.
Access control
Partitioned data store (public read only and private read/write)
Key action audit (e.g., attribution of who pressed the publish button and from where, and what changes were made)
Available 24/7 via remote authenticated access and secure

31. BON: Brainstorm, Organize, and Name
The enforcement and usability of an access control system
The preservation of data integrity
Security must be manageable and not hinder business (where possible)
Data integrity
The ability to securely transmit data to remote sources
Information must be kept private from the outside world.
Integrity
Consistent application program interfaces (APIs)
Authentication and access control
Accountability (who did what, when, how...)
There must be a strong, reliable authentication process
Granular access to data for users (operators) and customers
Strong authentication
Indelibility (deletions and retractions are logged)
Then the participants thoroughly discussed what they thought were important requirements. This step provided an opportunity for the participants to share their security concerns about the project. 
remove duplicate or inadequate security requirements
Integrity (assurance in data protection and validity)
Reduce or eliminate risks of inappropriate behavior
Role-based, restricted view, edit, and action access (e.g., summary report information, public for particular people)
Represent and support segmented disclosure.
Confidentiality (encryption, etc.)
Selectively secure communication with outside entities.
Access control
Partitioned data store (public read only and private read/write)
Key action audit (e.g., attribution of who pressed the publish button and from where, and what changes were made)
Available 24/7 via remote authenticated access and secure

32. BON: Brainstorm, Organize, and Name
A: Confidentiality
B: Access Control
The enforcement and usability of an access control system
C: Data Integrity
Role-based, restricted view, edit, and action access (e.g., summary report information, public for particular people)
Information must be kept private from the outside world.
Indelibility (deletions and retractions are logged)
Granular access to data for users (operators) and customers
Selectively secure communication with outside entities.
Partitioned data store (public read only and private read/write)
Represent and support segmented disclosure.
D: Manageability
E: Usability
Security must be manageable and not hinder business (where possible)
Available 24/7 via remote authenticated access and secure
Accountability (who did what, when, how...)
Then the participants thoroughly discussed what they thought were important requirements. This step provided an opportunity for the participants to share their security concerns about the project. 
remove duplicate or inadequate security requirements
Key action audit (e.g., attribution of who pressed the publish button and from where, and what changes were made)
Reduce or eliminate risks of inappropriate behavior
Consistent application program interfaces (APIs)
Auditing capabilities
(derived requirement)
F: Authentication
Strong authentication

33. Details: Benefits, Proof, Assumptions, Issues, and Action Items
Is the candidate requirement a fragment or duplicate of anything that has already been discussed?
According to the contributor and the group, is the candidate requirement fragment in scope?
Would you like to change the title?
If you had this capability, how would it help the business?
What will you consider acceptable evidence that the envisioned capability has been successfully delivered to the business?
Are there any special constraints on the requirement?
Are there any assumptions made regarding the requirement?
What are the remaining issues and actions items for the requirement?
Are there any related notes or comments?
Is there anything that needs to be clarified by the supplier of the requirement?

34. Details: Benefits, Proof, Assumptions, Issues, and Action Items
Is the candidate requirement a fragment or duplicate of anything that has already been discussed?
According to the contributor and the group, is the candidate requirement fragment in scope?
Would you like to change the title?
If you had this capability, how would it help the business?
What will you consider acceptable evidence that the envisioned capability has been successfully delivered to the business?
Are there any special constraints on the requirement?
Are there any assumptions made regarding the requirement?
What are the remaining issues and actions items for the requirement?
Are there any related notes or comments?
Is there anything that needs to be clarified by the supplier of the requirement?
the participants found it difficult to ask the questions of each requirement in turn,
because it was tedious
because some of the requirements were interrelated.
Instead, the participants reviewed all the security requirements together, not individually.
Each question prompted a series of discussions and generated significant feedback from the participants
the participants reviewed, reworded, and redefined those incomplete, incorrect, or ambiguous security requirements.
true security requirements, not just recommendations

35. Prioritization Label each requirement A, B, or C
Prioritize each requirement based on
Professional knowledge
Importance of the requirement to the project
Replace labels with 9, 3, and 1
10 minutes
all participants agreed that strong authentication, was a high priority
and that consistent APIs, was a low priority.
Moreover, the participants thought the requirements in Group A, Confidentiality, and Group F, Authentication, were the most important ones

36. Final Requirements
The system shall utilize cryptographically strong authentication.
The information in the system must be kept private from unauthorized users.
The system shall implement selectively secure communication with outside entities.
The system shall utilize and enforce an access control system.
The system will attempt to reduce or eliminate risks of inadvertent behavior.
The system shall provide granular access to data for users (operators) and customers.
The system shall provide role-based, restricted view, edit, and action access (e.g., summary report information, public information for particular people). (tied with) The system shall represent and support segmented disclosure.
The system shall implement auditing capabilities.
The system shall provide accountability of users' actions. (tied with) The system will be available 24/7 via remote authenticated access.
The system shall maintain a partitioned data store, public read only and private read/write. (tied with) The system shall implement a key action audit (e.g., attribution of who pressed the publish button and from where, and what changes were made).
The system shall implement indelibility. (tied with) Where possible, the system's security features must be manageable and not hinder business.
The system shall expose consistent APIs to developers.
Based on the result of the prioritization, the participants could then plan to implement their security requirements. Therefore, they could use their limited resources effectively and maximize their satisfaction of the security of the application within application development time and budget constraints.