1 / 18

Project Analysis Course ( 2012-2013)

Project Analysis Course ( 2012-2013). Week 2 A ctivities. Where we are now? . At the end of week 1, w e are familiar with : General description of project area (problem area) Project scope (geographically, technically, borders,..) Selecting Technics Intended users of the system

naomi
Télécharger la présentation

Project Analysis Course ( 2012-2013)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project Analysis Course (2012-2013) Week 2 Activities

  2. Where we are now? • At the end of week 1, we are familiar with : • General description of project area (problem area) • Project scope (geographically, technically, borders,..) • Selecting Technics • Intended users of the system • Project Context

  3. Where we go? • Identify requirements (end user point of view) & analyze (Developer point of view) them • Focus of this week includes: • Identification of functional requirement of the system • Identification of the non functional requirement of the system • Identification of constraints • Prioritize requirements • Validate • use case modelling

  4. Functional Requirement • Study the project case carefully and identify functional requirements • Functional requirements describe the interactions between the system and its environment ( in short: WHAT WILL THE SYSTEM DO) • try to identify all possible FR of the system at this stage. • Stating Functional requirements, examples: • An operator must be able to define a new game. • The system will provide registration of new students • The system shall keep track of library members • Remember FR are phrased as actions “Advertise a new league” “Schedule tournament” “Notify an interest group

  5. Non Functional Requirement • Aspects not directly related to functional behavior, but part of the system • Stating non functional requirements, examples: • The response time of the system must be less than 1 second • The system must recover from failure in less than an hour NFR Categories: - Usability - Reliability Robustness Safety - Performance Response time Scalability Throughput Availability - Supportability Adaptability Maintainability Usability Requirement example: “Viewers must be able to watch a match without prior registration and without prior knowledge of the match.” Performance Requirement example “The system must support 10 parallel tournaments” Supportability Requirement example “The operator must be able to add new games without modifications to the existing system.”

  6. Constrains • Imposed by the client or the environment • Sample constraints requirements: • The system must be implemented in Java • The system should run under windows operating system only

  7. Prioritize Requirements • From all identified FR & NFR, which are the most important one (must develop) • Rewrite FR & NFR omitting the non important requirements e.g.: for student registration system ALL discovered requirements Register students Manage students (add, delete, update) Attend lectures Assign courses ……. • Most important updated are 1, 2, 4 • 3 is not part of the registration hence- not important requirement

  8. Validate Requirements • Activities: • Recall the different roles in the groups ( users, developers, etc) - Ask users/clients if the current requirements conform their defined requirements • Go online check for similar project cases implementation – see the match

  9. use cases • Activities includes: • Identification of main actors/stakeholders of the system • Identifying functions provided by the system to each actor/stakeholder • Draw use case diagrams (Check if there is relationship between use cases, show it) • Provide use case scenarios • Provide full description of use case

  10. use cases……. • Identification of Main actors • Example 1 : For Online examination system, actors include: • Examiner • Examinee (students) • System Administrator

  11. use cases……… Identifying functions provided by the system to each actor • Example 1 : For Online examination system, actors include: • Examiner (prepare exam, mark exam, display results) • Examinee (register for an exam, submit exam, view results) • System administrator (manage users, manage exams)

  12. use cases……… • Draw use case diagrams (Check if there is relationship between use cases, show it)

  13. use cases……… • Provide use case scenarios • For above example lots of scenarios can be generated • Scenarios come from use cases, example • Scenario 1: register for exam • Scenario 2: manage users • Scenario 3: manage exams • Scenario 4: display results • Provide a sequence of steps involved in each scenario

  14. use cases……… • Provide use case scenarios • Example: Scenario 1- register for exam (steps) • Examinee fills registration form • Examinee submits the form • The system verifies payment for exam • The system returns a success registration message • Do the same for all scenarios

  15. use cases……… Provide full description of use case ( e.g. add a record of a TB patient to database • Use Case Name - Add a person record • Purpose:This business use case will allow a user to add a "person record" to the Master Person Index (MPI). • Pre-conditions: (Those conditions that must be present before the use case can start.) • The user must have proper security rights to enter a patient in the system. • System is available and operable • The user is notified that a person requires TB services and the person satisfies jurisdiction criteria for assessment and/or treatment. • The person requires TB assessment and/or treatment needs to be added into the MPI.

  16. Main Flow: • User selects register option • System displays register screen • User enters basic patient information in the register screen. Basic information may include last name, first name, sex, date of birth, address, and if a translator is needed. • User enters the reason for adding the person to the MPI which may have the following values: suspect case, confirmed case, contact investigation, targeted testing, etc. • User selects the save option • System saves registration in the MPI • End Use Case Alternate Flow/ Exception: (An optional situation within the activity flow.) • The system provides a message that a database record arleady exist • System rejects the registration and stops Post-conditions:(Outcome)A person record is created in the MPI.

  17. This week’s presentation Content • Heading: Requirement Elicitation & Analysis (summary report) • Introduction (elicitation & analysis approaches) • Functional Requirements • Non Functional Requirements • 3.1 security • 3.2 performance • 3.3 ………… • Constraints • Use case model • 5.1 Actors • 5.2 Use case diagram • 5.3 use cases specification

  18. This week’s report Content • Heading: Requirement Elicitation & Analysis (detailed report) • Introduction (elicitation & analysis approaches) • Functional Requirements • Non Functional Requirements • 3.1 security • 3.2 performance • 3.3 ………… • Constraints • Use case model • 5.1 Actors • 5.2 Use case diagram • 5.3 use cases specification

More Related