1. CSE 403 Section: SRS and Use Cases January 14, 2010

2. Problems/Tools Version Control: git, subversion, mercurial Bug Tracking: Google docs/Code, Bugzilla Testing: project dependent Databases: mySql, PostgreSql, sqlite3, PigLatin Hosting: Heroku, AppEngine, EC2 Code Quality: code reviews, style guides User Authentication: Google/Facebook OAuth

3. SRS and UI Prototype

4. Requirements Outline Mostly straightforward, but answer questions thoroughly Write in complete sentences and paragraphs (no outlines) Explain your choices, describe your product as if we have not seen your presentation In your schedule/timeline, show plan to accomplish project phases as well as features – Your schedule should be congruent with the project turn-in dates

5. Review Use Cases use case: a written description of the user's interaction with the software product to accomplish a goal They are part of your requirements: should accurately describe what the system must do. This is documentation of functionality Examples: – Book a flight – Enroll in course – Deposit check

6. A Few Use Case Clarifications… Primary Actor – user, the person interacting in the use case Level – granularity, big picture vs. small feature Minimal/Success “Guarantee” – Guarantee == Post-condition – Minimal/Success == worst case/best case Main Success Scenario – Steps to describe how user uses system to successfully complete a task Extensions – Alternate paths in success scenario (usually failure cases); should maintain minimal guarantee

8. EXAMPLES

9. Recipe Finder: Advanced Search Main Success Scenario 1.User clicks “Advanced Search” tab. 2.User puts chicken in the ingredients search, selects a low price range and selects search 3.A page with a list of cheap recipes that include chicken in the ingredients appears 4.User selects a recipe which looks good to them from the list 5.Recipe page appears with all the data

10. Recipe Finder: Find a Recipe Main Success Scenario 1.User enters recipe criteria. 2.System retrieves and presents matching recipes from Recipe Database. 3.User selects appropriate recipe. 4.System displays recipe information to user.

11. Restaurant Reviews: Restaurant owner updates information Main Success Scenario 1.Restaurant owner (RO) selects specific restaurant to update 2.RO navigates to restaurant’s information page 3.RO attempts to edit page 4.WebApp allows user to continue to the Edit page 5.RO corrects outdated information 6.RO saves changes, or if RO tries to leave the page without saving changes, WebApp asks RO for confirmation 7.WebApp updates database with new information for current restaurant 8.WebApp logs change as made by this user

12. Restaurant Reviews: Update Restaurant Information Main Success Scenario 1.Restaurant owner (RO) requests to edit restaurant’s information. 2.System verifies that RO has permission to modify restaurant information. 3.System presents current restaurant information. 4.RO modifies information as desired. 5.RO indicates modifications are complete. 6.System verifies all required information is present and of legal format. 7.System saves new restaurant information and displays updated restaurant page.

13. Screencasts: Student views lecture Main Success Scenario 1.Student logs into system with his/her account name and password. 2.The home screen is presented with a list of classes the student is attending. The classes are ordered by time, where the classes whose start time is closest to the current time shows up first on the page. 3.Student clicks on the available lecture he/she wants to attend. 4.The page loads the lecture screen with a video feed, question box, and whiteboard. 5.Student waits for the lecture to begin. 6.Instructor delivers the lecture, student optionally asks questions via the question box. 7.Instructor finishes delivering the lecture. 8.Student clicks “Leave Lecture” and logs off system.

14. Screencasts: View lecture Main Success Scenario 1.Student requests to view a lecture. 2.System retrieves lectures from Lecture Database and displays lectures that are visible to the user. 3.Student selects to view desired lecture. 4.System verifies that student is allowed to view the lecture and plays lecture screencast. 5.Student interacts with lecture. 6.When the lecture completes, System displays options to replay recently viewed lectures.

15. Main Success Scenario Summary Approx. 3-9 steps, easy to read Capture actor’s intention, not business logic, GUI, data formats, etc. Steps usually in one of the following forms: – Actor achieves a result – Actor passes information to another actor – Actor validates/verifies a condition – Actor updates state * Reminder: “actor" could be user or system

16. Android and Heroku

17. Android Architecture

18. Android Apps don’t actually stop running unless you explicitly make them stop – New process, with a new dedicated linux user There are 4 kinds of Components – Activity – Service – Content Provider – Broadcast Receiver Android documentation is excellent and development uses familiar tools like eclipse

19. Android tools/technologies Eclipse Plugin: for rapid development and debugging Phone emulator: for testing Layout xml: great to seperating visual UI from from functional UI AsyncTasks: simplified interface for threading Sensors API: easy access to gps, accelerometer, etc… Much more

20. Heroku Version Control with Git Testing environment with multiple apps Hosting for many types of projects Easy integration and establishment of DB FREE!!!