View
222
Download
0
Category
Preview:
Citation preview
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!!!
Recommended