☐ Set of user stories
☐ Definitions document
☐ Sitemap for your web app
☐ User interface wireframes
☐ Class diagram of your model
☐ Customer sign-off
☐ Teammate evaluations
The main deliverables to come out of this iteration are a collection of artifacts regarding project requirements, planning, and design.
For this milestone, you must submit the requirements and design artifacts specified in the following subsections.
All your artifacts must be of high quality with respect to the various criteria discussed in class. All your designs should follow principles of good design, such as the SRP (Single Responsibility Principle) and DRY (Don’t Repeat Yourself) principles.
You must use consistent names for things across artifacts. That way, for example, we can tell where each UI sketch fits into the sitemap. Make sure that all artifacts have unique IDs, so that they may be easily cross-referenced in your task reports. For example, you should employ IDs like US1, US2, US3, etc. for your user stories and WF1, WF2, WF3, etc. for your wireframes.
Diagrams need not be anal-retentively typeset; however, they must be readable.
Keep in mind that these artifacts will evolve as the project rolls along. Plan for such evolution.
You must submit a set of user stories that covers all the main feature of the system. Your USs must follow the templates/guidelines/principles described in lecture.
Your team will be provided a spreadsheet into which you will enter your USs. Each team should have only one user stories spreadsheet that is shared by all team members. Columns of the spreadsheet must be filled out as follows:
You must submit a definitions document that covers all the key terms, concepts, and business rules referred to in your user stories and other design artifacts. Each team should have only one definitions document that is shared by all team members. The definitions themselves must be clear (however you go about expressing them).
You must submit a sitemap that covers all the main pages of your team’s app. I don’t care about the exact notation you use for this diagram. However, it should be easy to figure out what pages your site will have and how those pages will be interconnected. Furthermore, be sure to cross-reference your UI wireframes (explained next).
You must submit user interface wireframes that cover all of the main user interfaces of your team’s web app. Your UI wireframes should show the basic page elements (fields, buttons, etc.). They may or may not be styled (e.g., with colors/graphics). You must give each wireframe a unique ID of the form WF1, WF2, WF3, etc. to facilitate cross-referencing in other documents. Don’t change a wireframe’s ID once a valid ID has been assigned, and don’t worry about sorting wireframes by ID.
You must submit a UML class diagram of your model. Use proper class diagram notation (as given in lecture). Label all associations, and include all multiplicities. Include attribute types (e.g., “name : string”).
Important! The diagram must be a UML class diagram. For example, entity-relationship diagrams (ERDs) are NOT acceptable.
Before your milestone submission will be considered complete, your customer must sign off on it, as per the form below. (Note that I will contact the customer directly to collect their sign-off, so you need only to get their verbal approval.)
At the end of each iteration, each team member must provide an evaluation of each other team member. Instructions and forms for performing these teammate evaluations will be communicated by email near the end of the iteration.
Customers: Please indicate your approval of the following items—but ONLY if you agree 100% with the statement for the item.
If you have ANY disagreement, do not give your approval. Instead, provide the team with feedback, and have them resolve whatever issue is preventing your approval.
☐ I have reviewed the user stories, and they are consistent with my wishes.
☐ I have reviewed the user-interface designs, and I approve of them.
Below are each of the grading items for this Milestone, along with their point values and weights. If an item is not submitted at all, 0 points will be awarded for that item. The top-level bullets specify grading criteria. The sub-bullets indicate standard deductions for errors in a submitted item. The deduction list below may not be complete because there may be mistakes that we did not expect. The deduction for an unexpected mistake will be assessed at the time it’s discovered and will reflect how severe the instructor thinks the mistake is. If the deductions for a grading item total more than the total points for that item, 0 points will be awarded for the item.
20 points with weight of 30%
20 points with weight of 10%
20 points with weight of 10%
20 points with weight of 25%
20 points with weight of 25%