Skip to content

Requirements Milestone

Due Date

Due Date: October 10
Grading: Team


You must watch the Development Methodologies lecture before starting this Milestone.


This will be the main requirements document for your project. If you were charging a client for your work, this document would form part of that contract, specifying exactly what features your software will implement. The other part of the contract would be the payment details.

The document includes the design you made before (so, embed or add links to those images) but extends on that with detailed descriptions of all the desired features.

Try to list all the features of your app in roughly the order in which you think they need to be implemented.

Your requirements document will usually contain a few items that are beyond the scope of this class. That is, these are features I do not expect you to implement for this class.


For example, if you are building an email app, you might have the following requirements (it is assumed that each requirement is prefaced with the phrase "the user can"):

  1. user can login
  2. download user's email to app
  3. display emails on main screen in list view, see Design Image #1 (you link to it)
  4. compose email (DI #2 link)
  5. send email functionality (talk to SMTP server)
  6. CRUD contacts (DI #3 link)
  7. download contacts from server and show in contacts screen
  8. app looks good on phones
  9. displays all messages even when offline
  10. and so on...

The requirements might evolve slightly as you make decisions as to what works for your app. However, make sure that the requirements documents stays up to date with the current development plan.

The items on this list are also close, but not identical, to the programming Issue items you will be adding to your GitHub Issues, and assigning to team members. For example, item 1 can become its own issue: "Add login screen" along with a "Login user to IMAP server". Item 2 then becomes "Download emails from IMAP server" and "Store emails in local SQLite database".

Every week or so, you will look at the next requirement(s) that need to get done, break them down into programming Issues, create then on GitHub, assign to a team member. Repeat.

Add PoC Issues

After the full list of requirements is done, you will then decide on the set of features you will implement for you Proof of Concept milestone (PoC), due at the end of the semester. You will also create one GitHub Issue, with label:enhancement milestone:proof-of-concept, for each feature you plan to implement by the end of the semester. Since this is a proof-of-concept (we are seeing if we can use the technologies), some of your Issues might describe which technology you will be using, others will be standard issues described from the user's perspective. For example, for the email app above you might have issues such as:

  1. Deploy to Google App Engine. Using their Java framework.
  2. Users can login.
  3. Use the App Engine Mail API to send a message, and to receive a message.
  4. Displays received email to user.
  5. User can enter some text and then send it as an email.
  6. Integrate Bootstrap into login and email pages.
  7. Store message text in google cloud data-store

I might approve your PoC Issues, or might ask you to add/remove/edit some them before approving them. Eventually, I will approve a set of PoC Issues which you will then implement for the PoC Milestone. Your grade for the PoC is based on your implementation of these Issues. We will follow the same process (you post Issues, I approve or ask for more/less) for the Beta and RC1 Milestones in 492.

Simply cut-n-pasting Requirements into Issues is usually a bad idea. Each Requirement is typically much higher-level than Issues. Also, Requirements describe the app as it will be when finished. No features of the PoC will be "finished".


  1. Make a Requirements wiki page and list your requirements there.

  2. Each item should succinctly explain a small feature, or part of it.

  3. Each one will have a number. You can add sub-numbering, 1.1, 1.2, 1.2.1, etc. if you want.

  4. Add all the Proof of Concept Issues to your GitHub Issues with label:enhancement, milestone:Proof Of Concept. These are what you will implement by the end of this semester. I will approve them or ask for more/less. I will do so in your GitHub Issues.


  • Create Requirements page

  • All features are numbered

  • All the major features required by the app are covered in the list.

  • The order roughly matches the order of importance.

  • Features are described in enough detail to be unambiguous.

  • All the Proof of Concept issues have been added to Issues and associated with Proof of Concept milestone.

  • Detailed Design images are linked or embedded in the wiki page, and hosted at GitHub.

  • The wiki page is easy to read.

Do not make any changes to the wiki pages used for this milestone after the deadline. Wait until after you receive the grade for the milestone to make any further changes to these pages.

Grading Rubric

Grade is 100 minus the total points lost, with minimum of 0. See grading scale in Syllabus. Points lost for each area are:

Feature Coverage

Excellent (0-10 points lost): A fully-featured app is described. All teacher requests included. Includes very ambitious features: beyond what might be required for this course.

Good (11-20 points): App has few features. Some teacher requests included.

Bad (21-35 points): App does very little. Some teacher requests included.

Failed (> 35 points): App does almost nothing beyond what the underlying libraries/frameworks/etc already do.

Details Provided

Excellent (0-10 points lost): Every feature explained in great detail with Design images embedded. No ambiguity.

Good (11-20 points): Every feature explained in some detail, with hyperlinks or embedded Design images, little ambiguity in what needs to be implemented.

Bad (21-35 points): Features listed with little detail, few or no Design images, some ambiguity.

Failed (> 35 points): Features listed with minimal detail, no Design images, highly ambiguous.


Excellent (0-10 points lost): Grammatically correct, easy to understand *English.

Good (11-20 points): A few bad or confusing sentences.

Bad (21-35 points): Very hard to understand.

Failed (> 35 points): Nearly Impossible to understand. Many errors.


Excellent (0-10 points lost): All done.

Good (11-20 points): Minor things missing.

Bad (21-35 points): Some things missing.

Failed (> 35 points): Most of them missing.