search

UTD-CRSS / project.exploreapollo.org

Project planning for exploreapollo.org
http://project.exploreapollo.org
1 stars 1 forks source link

Basic Use Case Design Needed #13

Open VictorK1902 opened 8 years ago

VictorK1902 commented 8 years ago

As discussed, I think it's best if we id a set of basic use cases so that everyone has something tangible enough to start our implementation. Feel free to add/edit as you want. More details to how each module implements the same use case (as respect to only that module) should be handled separately within each module repo (create an issue that is, within the corresponding repo so that its easier to keep track)

I think the goal for now is implementing the very basic and must-have feature: streaming a Moment. I think it can be broken down to several use cases, I list a couple below

I. Streaming A Moment Feature

  1. User is directed to Dashboard (?? - need details of dashboard design)
  2. User selects a Mission from a given list of Missions (?? - need details of dashboard design)
  3. User is directed to Mission Overview (?!?!? - WE'RE MISSING THIS TRANSITION IN REQUIREMENT)
  4. User select a Story from a given list of pre-defined Stories
  5. User is directed to Story Overview
  6. User select a Moment (any) from the given list of Moments
  7. User is directed to the Moment Viewer
  8. User clicks the PLAY! button
  9. User listen to the audio file
  10. Upon reaching the point 1-2 minutes before the ending of Moment, display the next available Moments

For now, lets focus on these 10 use cases. ALL modules except for the Audio Server module would most likely have to implement all 10 use cases listed above. Each use case I think should be elaborated more in each individual module repo

austinpray commented 8 years ago

So if I had to break this up:

Critical Path

This app is open to the public for viewing so the critical path skips the user authentication

  1. User is navigates to Dashboard (?? - need details of dashboard design)
  2. User selects a Mission from a given list of Missions (?? - need details of dashboard design)
  3. User is directed to Mission Overview (?!?!? - WE'RE MISSING THIS TRANSITION IN REQUIREMENT)
  4. User selects a Story from a given list of pre-defined Stories
  5. User is directed to Story Overview
  6. User select a Moment (any) from the given list of Moments
  7. User is directed to the Moment Viewer
  8. User clicks the PLAY! button
  9. User listen to the audio file
  10. Upon reaching the point 1-2 minutes before the ending of Moment, display the next available Moments

Authentication branch

  1. user signs up
  2. user logs in
  3. user goes to dashboard and is now privileged
  4. user clicks a "create story" button
  5. ...

But we should focus on the critical path first

VictorK1902 commented 8 years ago

Yeah. I was also reading up on the user account management. We could cut and move the log in use case to authentication branch as you said. So is user account management under the scope of this project, if we have the page available to public?

austinpray commented 8 years ago

A user would have to be authenticated to create a story or a moment. If story and moment creation are in-scope then user authentication is in-scope.

austinpray commented 8 years ago

Made a quick video to whiteboard the critical path: http://youtu.be/wGOiMgkvMco