Skip to content

Requirements Milestone

Due Date

Due Date: October 13
Grading: Team

Lectures

You must watch the Development Methodologies before starting this Milestone.

Description

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.

You will also mark each feature with one of (emoji not required, just for fun):

  • Required 🌱 Core functionality of the app. Must have these for it to even start working.
  • Desired 🌿 Added functionality, usability features, cosmetic features.
  • Aspirational 🌼 Other cool stuff you would like to add

Roughly the required features are those that need to get done first before anything else can even get started: things like logins, navigation menu, connection to backend, etc. They lay the foundation for building the app. An app that only implements the required features will at most get a passing grade in the class: 70.

The desired features are what make your app worth using. They make the app functional, attractive, and easy to use. Roughly, an app that implements all the desired features gets a 90 in the class.

The aspirational features make your app a professional-quality app. Implementing some of these moves it towards 100.

Example

For example, if you are building an email app, you might have the following requirements. I only have to write "user can" in the first line.

  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. compose emails in RTF 🌿
  9. app looks good on phones 🌿
  10. displays all messages even when offline 🌼
  11. 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 to some of the programming Issue items you will be adding to your GitHub Issues and assigning to team members. For example, item 1 above 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 them 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. They will all probably be required features.

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.

Warning

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, while Issues are specific things that need to get done.

Also remember that the PoC is not a "finished" product, see PoC Milestone.

Deliverables

  1. Make a Requirements wiki page and list your requirements there.
  2. Each item should succinctly explain a feature.
  3. Each one will have a number. You can add sub-numbering, 1.1, 1.2, 1.2.1, etc. if you want.
  4. Each one will be marked as either: Required, Desired, or Aspirational.
  5. 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.

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 or linked to. 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.

Writing

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.

Deliverables

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.