Design
Create a Context Diagram for the system
Brainstorm and list 10 user stories (title only) You may have fewer than 10 user stories if you can cover the entire system in fewer.
Each person on the team pick 1 user story and fully elaborate it (this is an individual grade, so you do not have to cover for a team mate). Recall from class that an elaborated user story is performed at the start of the sprint/iteration when this story moves into the current sprint and is no longer just in the backlog. The data for an elaborated user story includes:
Detailed work tasks to accomplish the story. These should be at a level that allows the developer to check off their progress so team members have an idea how the implementation is going.
Acceptance Scenarios: In the format: GIVEN: some initial condition relevant to this story, WHEN: the user takes some action or some system event happens , THEN: The system's response to that action. These scenarios should cover both success and failure conditions (what should system do with bad data or other things that can go wrong).
Done Done criteria: What does it take for the story to be marked done? This can be a standard team criteria shared by all stories (be sure and mark this for TA), or custom for each individual story.
Note: In Resources section there is a reference card (storycard.pdf) that may be useful in writing good stories.
Implementation
Create your team's Android Project and Import into Git
Create an opening or welcome screen which has options for Login and Registration. You may have some other method of differentiating login and registration, if you do not want an opening screen.
If someone selects Login, then you should display a way to enter the user name and password.
If someone requests login, you should check for the correct user name and password. For this first milestone, you may have a hard coded user with name "user" and password "pass" to check against.
If the login matches user name / password then go to your application. Otherwise, notify of the bad login attempt.
Canceling the login (press Cancel or going back a screen for example) will close out the login attempt , but no information is recorded and the application does not start up. Note here you are not explicitly required to have a cancel button, just a way to back out of the login.
Once in the application, there should be a way to logout. After logging out, the application should return to the welcome / opening page.
NOTE: Security logging, password encryption, or account lockout is not required and would be extra credit for later in M13.
Grading Criteria
Team Points ....... 55
Context diagram covers all actors (5)
10 user stories (or fewer, see above) are listed. They are appropriate and phrased correctly (As a _ I want ) ..... (10)
Android project is created and launches .... (5)
Welcome screen displays (or alternative).... (5)
Welcome screen (or alternative) has controls for login or registration .... (5)
Selecting login brings up screen to enter information .... (5)
Screen displays fields for inputting user name and password .... (5)
Login/Cancel(abort login) has appropriate action (10)
Logout functions correctly (5)
Individual Points ..... 45
User story is in correct format (As a __, I want to , so that I can ) (5 points)
User story complies with INVEST criteria (10 points)
User story acceptance scenarios are in correct format (Given , When , Then ____) (5 points)
User story acceptance scenarios are complete and cover both success and failure cases (20 points)
User story done done criteria is logical (either a single set shared by the team, or custom one per story) (5 points)
Submissions
Electronic submissions should be submitted in .PDF format.
You can combine and submit your team's User stories together in one file and have one person submit it on T-square. In fact, it is recommended.
Design Create a Context Diagram for the system Brainstorm and list 10 user stories (title only) You may have fewer than 10 user stories if you can cover the entire system in fewer. Each person on the team pick 1 user story and fully elaborate it (this is an individual grade, so you do not have to cover for a team mate). Recall from class that an elaborated user story is performed at the start of the sprint/iteration when this story moves into the current sprint and is no longer just in the backlog. The data for an elaborated user story includes: Detailed work tasks to accomplish the story. These should be at a level that allows the developer to check off their progress so team members have an idea how the implementation is going. Acceptance Scenarios: In the format: GIVEN: some initial condition relevant to this story, WHEN: the user takes some action or some system event happens , THEN: The system's response to that action. These scenarios should cover both success and failure conditions (what should system do with bad data or other things that can go wrong). Done Done criteria: What does it take for the story to be marked done? This can be a standard team criteria shared by all stories (be sure and mark this for TA), or custom for each individual story. Note: In Resources section there is a reference card (storycard.pdf) that may be useful in writing good stories.
Implementation Create your team's Android Project and Import into Git Create an opening or welcome screen which has options for Login and Registration. You may have some other method of differentiating login and registration, if you do not want an opening screen. If someone selects Login, then you should display a way to enter the user name and password. If someone requests login, you should check for the correct user name and password. For this first milestone, you may have a hard coded user with name "user" and password "pass" to check against. If the login matches user name / password then go to your application. Otherwise, notify of the bad login attempt. Canceling the login (press Cancel or going back a screen for example) will close out the login attempt , but no information is recorded and the application does not start up. Note here you are not explicitly required to have a cancel button, just a way to back out of the login. Once in the application, there should be a way to logout. After logging out, the application should return to the welcome / opening page. NOTE: Security logging, password encryption, or account lockout is not required and would be extra credit for later in M13.
Grading Criteria Team Points ....... 55 Context diagram covers all actors (5) 10 user stories (or fewer, see above) are listed. They are appropriate and phrased correctly (As a _ I want ) ..... (10) Android project is created and launches .... (5) Welcome screen displays (or alternative).... (5) Welcome screen (or alternative) has controls for login or registration .... (5) Selecting login brings up screen to enter information .... (5) Screen displays fields for inputting user name and password .... (5) Login/Cancel(abort login) has appropriate action (10) Logout functions correctly (5) Individual Points ..... 45 User story is in correct format (As a __, I want to , so that I can ) (5 points) User story complies with INVEST criteria (10 points) User story acceptance scenarios are in correct format (Given , When , Then ____) (5 points) User story acceptance scenarios are complete and cover both success and failure cases (20 points) User story done done criteria is logical (either a single set shared by the team, or custom one per story) (5 points) Submissions Electronic submissions should be submitted in .PDF format. You can combine and submit your team's User stories together in one file and have one person submit it on T-square. In fact, it is recommended.