1. Lecture 03: How to Gather the requirements?
1.1. Gathering requirements techniques:
1.1.1. Interview
1.1.1.1. Open interviews
1.1.1.2. Closed interviews
1.1.1.3. Semi-closed interviews
1.1.2. users groups
1.1.3. survey
1.1.3.1. questionnaire
1.1.3.2. random sample
1.1.3.3. direct random sample
1.1.3.4. direct sample
1.1.3.5. used closed questions
1.1.4. observation
1.1.4.1. Physical
1.1.4.2. Automated
1.1.5. Shadow
1.1.5.1. No interactions should be made
1.1.6. User structure
1.2. Personal Skills
1.2.1. Analyst
1.2.1.1. Enough experience
1.2.1.2. Work for a solution
1.2.1.3. How to deal with people
1.2.2. Types of people in the interview
1.2.2.1. ++ Excellent: Concentrate & Cooperative
1.2.2.2. X+ Normal: "Not" Concentrate & Cooperative
1.2.2.3. +X Very Bad: Concentrate & "Not" Cooperative
1.2.2.4. XX Bad: "Not" Concentrate & "Not" Cooperative
1.3. Lecture notes:
1.3.1. Not Concentrate interviewee: Gets out of the scope
1.3.2. The Analyst must meet the customers, while the Developer should not always meet the customer.
2. Lecture 04: How to Analyse the requirements?
2.1. Using a Use-Case Diagram
2.1.1. Scope: inside System-boundary (always imperative verbs)
2.1.1.1. Any thing outside the System-boundary will not be our job
2.1.2. Actors: Main beneficiary of the System (always nouns)
2.1.3. Use-Cases: Actors' actions on the System
2.1.4. Relations between Use-Cases
2.1.5. Relations between Actors and Use-Cases
2.1.5.1. Many Actors can use the same Use-Case
3. Lecture 01: SDLC Systems development life-cycle
3.1. SDLC Phases
3.1.1. Planning :Gathering the Requirements
3.1.2. System analysis :Analyse the Requirements
3.1.3. Design
3.1.4. Development
3.1.5. Testing
3.1.6. Operations and maintenance
3.2. Software development models
3.2.1. Waterfall
3.2.1.1. Advantages
3.2.1.1.1. record keeping
3.2.1.1.2. client knows what to expect
3.2.1.1.3. In the case of employee turnover, waterfall’s strong documentation allows for minimal project impact.
3.2.1.2. Disadvantages
3.2.1.2.1. developers can’t go back
3.2.1.2.2. relies heavily on initial requirements
3.2.1.2.3. change needs to be made, the project has to start from the beginning
3.2.1.2.4. The whole product is only tested at the end
3.2.1.2.5. doesn’t take into account a client’s evolving needs
3.2.2. Agile
3.2.2.1. Advantages
3.2.2.1.1. allows for changes to be made after the initial planning
3.2.2.1.2. up to date with the latest developments
3.2.2.1.3. allows clients to add their feedback
3.2.2.1.4. testing at the end of each sprint ensures that the bugs are caught
3.2.2.2. Disadvantages
3.2.2.2.1. With a less successful project manager, the project can become a series of code sprints
3.2.2.2.2. the final product can be grossly different than what was initially intended
3.3. S.M.A.R.T. Goals
3.3.1. Specific :What do I want to do?
3.3.2. Measurable :How much?
3.3.3. Attainable / Achievable :How can the goal be accomplished?
3.3.4. Relevant / Reasonable :Does this seem worthwhile?
3.3.5. Time-bound :When?
3.4. Lecture notes
3.4.1. One of the differences between agile and waterfall is that testing of the software is conducted at different stages
4. Lecture 02: Scope
4.1. Contracting Phases
4.1.1. Vision Statment
4.1.2. Scope :Should we do it or not?
4.1.3. Preliminary feasibility study :Should we Go or Not?
4.1.4. Feasibility study
4.1.4.1. time schedule
4.1.4.2. budgeting
4.2. Lecture notes
4.2.1. Zero value change scope request. Is a change in the scope but without any addition cost.
5. Course notes
5.1. Scope change request may change the timing and the budget
5.2. RFP: Requests for proposal
5.3. IDSC: The Information and Decision Support Center: Acting as the Egyptian Cabinet Think Tank
6. Lecture 06: UML 1.5 :Unified Modeling Language
6.1. UML Diagrams :OOP Technic
6.1.1. Structured Diagrams
6.1.1.1. Class Diag.
6.1.1.1.1. Consists of
6.1.1.1.2. Diag. Relations
6.1.1.2. UseCase Diag. :show which actors participate in each use case
6.1.1.3. Physical view
6.1.1.3.1. Component Diag.
6.1.1.3.2. Deployment Diag.
6.1.2. Dynamic Diagrams
6.1.2.1. State Diag.
6.1.2.2. Activity Diag. :sequential and concurrent groups of activities
6.1.2.3. Interaction View
6.1.2.3.1. Sequence Diag. :Shows the behavior sequence of use case.
6.1.2.3.2. Collaboration Diag. :shows the relationship among roles
6.2. Model Management
6.2.1. Package :A set of packages that hold model elements, such as classes, state machines, and use cases.
6.2.2. Extensibility constructs
6.2.2.1. Constraint (XOR)
6.2.2.2. StereoType & Icon (DB Icon)
6.2.2.3. Tagged Values (Name=Ahmed)
7. Lecture 05: Use Case :Requirement specification
7.1. Use-Case Diageam consists of:
7.1.1. Actors: Who are the System-Users
7.1.1.1. Role
7.1.1.1.1. Employee
7.1.1.1.2. Customer
7.1.1.1.3. Guest
7.1.1.2. Organization
7.1.1.3. Device
7.1.1.4. System
7.1.2. Scope: System border
7.1.3. Use-Cases: What they will do with the system
7.1.4. Relations between Actors & Use-Cases
7.1.4.1. Association
7.1.4.2. Multiplicity
7.1.4.3. Generalization (Inheritance) :similar objects are combined in a Superclass
7.1.4.4. Specialization (Realization) :subclasses are created from an existing Superclass
7.1.5. Relation between Use-Cases
7.1.5.1. Extend :conditionally adds steps
7.1.5.2. Include :is used to extract use case
7.2. Specifying System Behavior Problems
7.2.1. The implicit scope
7.2.2. Too little (or too much) definition
7.2.3. Ambiguities and contradictions
7.2.4. Over or missing specification
7.2.5. Focus on the wrong aspects: internals, user interface, design constraints
7.3. Purpose of Use Cases
7.3.1. Define the scope
7.3.2. structure to the requirements
7.3.3. unambiguous statement
7.3.4. capture vocabulary
7.3.5. example interactions
7.3.6. guide the design phase
7.3.7. validate the class model
7.3.8. precise system requirements
7.3.9. all stakeholders can comprehend
7.3.10. basis of the user manuals and test cases for the system
7.4. Lecture Notes
7.4.1. Martin Fowler a software engineer, specializing in object-oriented analysis and design, UML, agile software development methodologies, extreme programming.
7.4.2. A Use Case System Diagram may consist of 12 Cases only.
7.4.3. Authentication: Who is the user? Authorization: What you can do?
7.4.4. Stereo-Type :Classifier for a classifier
7.4.5. Name use cases with verb phrases