CSE 403 Section:SRS and Use Cases

January 14, 2010

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

SRS and UI Prototype

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

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

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

Examples

Recipe Finder: Advanced Search

Main Success Scenario1. User clicks “Advanced Search” tab.2. User puts chicken in the ingredients search,

selects a low price range and selects search3. A page with a list of cheap recipes that include

chicken in the ingredients appears4. User selects a recipe which looks good to them

from the list5. Recipe page appears with all the data

Recipe Finder: Find a Recipe

Main Success Scenario1.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.

Restaurant Reviews: Restaurant owner updates information

Main Success Scenario1. Restaurant owner (RO) selects specific restaurant to

update2. RO navigates to restaurant’s information page3. RO attempts to edit page4. WebApp allows user to continue to the Edit page5. RO corrects outdated information6. RO saves changes, or if RO tries to leave the page without

saving changes, WebApp asks RO for confirmation7. WebApp updates database with new information for

current restaurant8. WebApp logs change as made by this user

Restaurant Reviews: Update Restaurant Information

Main Success Scenario1. 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.

Screencasts: Student views lectureMain Success Scenario1. 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.

Screencasts: View lecture

Main Success Scenario1. 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.

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

Android and Heroku

Android Architecture

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

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

Heroku

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