SE 3800, Assignment 3
User Stories

In this assignment, you will get experience writing stories with clear acceptance criteria. This is a group assignment so you have someone to discuss the stories with; review by a partner improves the results dramatically.

For this assignment, you will write stories for a simple game, Word-within-a-word. In this teaching game, the instructor writes a word on the whiteboard and then has students find as many words as they can using the letters of the original word. For example, if the target word is "onomatopoeia" then the students might come up with poem, name, top, pot, ate, etc. This game could have a mode in which students must use each individual letter just once (disallowing 'mam' in the previous word). The winner could be the person or team that finds the most words, or it could be the team that finds a set of words using as many letters as possible from the target word.

You are to write an API and simple program to support this game. It should allow the user to do the following:

• Set the target word.
• Check a list of words to determine that each is a valid match.
• Show what letters are unmatched after entering a list of words.
• Find a word from a dictionary (where the dictionary is a file in your project) that would contain each word in a specified vocabulary. This could be used to generate a target word to be written on the board.
• List all words within the target word, again using the dictionary to find them.

Your API should be delivered in a set of C++ classes that can be used by a GUI program to provide a more interactive game. Note you will not write the GUI version of this game - your program must do all input and output through standard I/O.

For this assignment, write stories capturing how your console I/O system will work. It should cover all of the use cases above. In addition, write a story for entering a candidate word into a GUI, using the GUI to show what target word letters have been matched and circling any letters that do not appear in the target word. This story would be used by a young student to check their answers. Also, write a story that would do the same with a list of words (where the goal is to cover as many target letters as possible).

All stories must have acceptance criteria. Where possible, use the given/when/then format for acceptance criteria as illustrated in the sample Calculator Stories. Be sure your stories cover all of the cases! You may need more than one story for some features. Note that the acceptance criteria in the examples use specific numbers. This is very helpful; it allows the client to see important detail and simplifies writing tests. If relevant, describe ranges of valid inputs. Specific values may be less helpful on some projects, but they are very helpful (and required!) for the types of examples you will write for this assignment. In this course, we will use the term detailed stories to refer to the type of story in which all AC use specific values.

Notes

• For this part of the assignment, you are only writing stories and other planning documentation; you are not implementing anything.
• All input is to be read from standard input (cin) and all output written to standard output (cout). That is, this will be a console application. C++ certainly supports GUI applications, but for this assignment console I/O makes your solution easier to test using an automated setup.
• Warning: having a story that simply specifies input formats fails to provide value; no user gets value from just knowing the date format. Pick a feature and include date information as acceptance criteria for that feature. This information probably does not follow the given/when/then format.
• If your program receives an illegal input, it must re-prompt for the data until it is legal. Be sure to capture this behavior with given/when/then criteria.
• Do not name "user" as the user of your stories. Pick a particular type of user that might use this application such as a student, professor, administrative assistant, registrar, etc. This will allow you to have more meaningful reasons for your stories.

Work in groups of 2 or 3 on this assignment. Your grade for this assignment will have both an individual and a group component, with the bulk of the points being individual. Be sure to review your stories as a group!

• Teams with three members are to write two additional stories. Your instructor can help with suggestions.
• Check that all participating group members are named in the document.
• Document each story with the name of the student who wrote that story. All students must write an approximately equivalent number of stories, and all students must write approximately the same number of acceptance criteria.
• Ensure you have full coverage of all features.
• Ensure each story meets the INVEST criteria, where in this context negotiable generally means you are not giving implementations in the acceptance criteria. Other things to watch for (that you'll learn more about in SE 3821) include ensuring each story has the right scope, is relevant, is complete, and is concise.
• Ensure each story is (uniquely) numbered.
• Ensure each story is grammatical and is free of spelling errors.

Upload your PDF in Canvas for grading as instructed. Note that Canvas is set up for group submissions; any one student in the group can submit, and the others can confirm what was submitted by checking Canvas. As always, you can submit as many times as you like.