M0 Initial Planning and Design

---

Milestone M0 Checklist

☐ 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.

1. Requirements and Design Artifacts

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.

1.1. User Stories

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:

• Category: The category column may contain labels of your choosing that help you group and organize your USs.
• ID: The ID must be of the form US1, US2, US3, etc., and each user story must have a unique ID. Don’t change a US’s ID once a valid ID has been assigned, and don’t worry about sorting user stories by ID.
• Title: The title must follow the verb/noun template discussed in class.
• Description: The description must follow the who/what/why template discussed in class.
• Estimate: The estimate must be one of the following values in days of work:
  • 0.5 days (3–4 hours of work)
  • 1 day (6–8 hours)
  • 1.5 days (around 12 hours)
  • 2 days (around 16 hours)
  • 3 days (around 24 hours)
  • 5 days (around 40 hours)
• Priority: The priority must be a number from 10 to 100, with lower numbers representing higher priority.
• Status: The status must be one of the following:
  • Not started
  • In progress
  • Completed-intermediate
  • Completed-final

1.2. Definitions

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).

1.3. Sitemap

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).

1.4. UI Wireframes

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.

1.5. Model Design Diagram

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”).

2. Customer Sign-Off

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.)

3. Teammate Evaluations

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.

---

Milestone M0 Customer Sign-Off Form

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.

---

Grading Rubric

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.

User Stories

20 points with weight of 30%

• Followed title and description templates
  • -1 for each violation up to a max of -5
• Not too big
  • -1 for each violation up to a max of -5
• Complete set
  • -1 to -10, depending on how incomplete
• Functional user requirements only
  • -1 for each violation up to -3
• Customer-oriented
  • -1 for each violation up to -5
• No design, just requirements
  • -1 for each violation up to -3
• Has status tracking
  • -1 per missing/incorrect status up to -4

Definitions Document

20 points with weight of 10%

• All key terms/concepts defined
  • -1 to -20 per undefined term/concept (that arguably should have been defined) depending on relative size of the concept

Sitemap

20 points with weight of 10%

• Shows pages and how they’re interconnected
  • -15 if the figure doesn’t convey this
  • -1 for each missing page up to -15
  • -1 for each missing connection up to -5
• Clear and understandable
  • -1 to -20 depending how unclear or difficult to understand

User Interface Wireframes

20 points with weight of 25%

• Clear and well detailed
  • -1 to -15 depending on how unclear or how many details are missing
• Shows the basic page elements
  • -1 to -15 depending on how many page elements are not accounted for
• Complete set
  • -1 to -15 depending on how many interfaces are not accounted for

Class Diagram of Model

20 points with weight of 25%

• Clear and detailed
  • -1 to -15 depending on how unclear or how many missing details
• Complete
  • -1 to -15 depending on how incomplete
• Uses proper class diagram notation
  • -1 for each departure from class diagram notation up to -5
• All associations and multiplicities labeled
  • -1 for each missing association or multiplicity label up to -4
• Follows good design principles
  • -1 to -5 depending on the number and severity of design issues