Classwork‎ > ‎Project Milestones‎ > ‎


Your requirements establish a solid definition of what your project is all about.  It is the basis for what your team will build.

Your requirements is a written document contained on your wiki. (Note: You team should have decided on and created a wiki by 10/8.  Hint: github in the repo where you will store your project probably works.)  The first "draft" is due 10/08.  An updated version is due 10/22.  However it is a living document as your project evolves.  You'll update it as the quarter progresses and as you commit to your milestones. There are 5 components to the requirements specification.
  • High level product description
  • Users and use cases
  • Feature specification
  • UI diagrams/UI mockups
  • Product deliverables
On both 10/8 and 10/22, your assignment is to turn in this requirements document.  The difference between what is turned in on these dates is details, clarity, improvements, and completeness.  

High level product specification

This is largely a refinement of your project proposal.  What's the big vision of your product?  Who are the customers?  What problem are you trying to solve?  What alternatives/competitors currently exist?  How is your product different?  What is the "scale" of your product?  How many customers/users are there? What are the major features you want to deliver?  You should have most of this figured out by the 10/8 date.

Users and use cases

Who are the users of your product? How will they use it?  What are the major scenarios?  A scenario shows a sequence of steps that user takes to accomplish task. Text and/or pictures work well to describe users/use cases/scenarios.

By 10/8,  you should describe the users/actors in your system and describe the important use cases, at least at a high level.  Detailed descriptions of users and use cases should follow in the 10/22 delivery.  We'll discuss formats in class that make use cases useful.

Feature specification

What are the features that you will implement?  By 10/8, you should understand the big picture of what the product should do.  You have some details but it may be incomplete.  But 10/22, you have drilled down into specific details of what you will be implementing.  You should have a good idea of the "cost" to implement the features and have refined the feature list so that it is likely implementable by the end of quarter.  Or, you should have some confidence that if things don't go well, what features you will drop and still have a successful project.  

It's possible that you have some high level requirements that you may have thought of and want to implement but don't have time.  Further, you may or may not have done a detailed drill down.  That's okay.  It's good to have a "wish list" of things you want to do in the future, even though you haven't gotten to the details.  Go ahead and list these too.

I've found a detailed text description of all the features to be useful when accompanied by a summary table.  The summary table lists out:
  • feature name
  • description
  • issues
  • priority
  • cost (estimated (person) days to complete)
  • release
  • comment
 Name High Level Description Issues Priority CostRelease  Comment
 FooAllow for visitors to the site to use a flazzle to add content to the content data store.... Flazzle component not completedH 8 days 1 Need to resolve flazzle issue ASAP
 Bar Lorem Ipsum....   - 
 Bazz Blah blah blah.... M  2 

 After 10/22, you may continue to add or drop features as you approach the first, second, and third releases. 

UI Diagrams/User Experience/User Design

What will the UI look like? Submit diagrams containing rough sketches of your product's user interface and user experience.  A "schematic" depicts the basic application flow.  Pictures should should depict what the users will see "on their screen."  Pictures should show the major UI components to be used on screen -- e.g. text boxes, buttons, scroll bars, sliders, etc.  The schematic and pictures are a "prototype" to represent the users, use cases, and functionality. They should reflect forethought about what information needs to be shown and how the user will use the software.

The diagrams can be drawn by hand or computer. It's likely the process to get to a schematic and pictures involves pencil, paper, a white board, and "sticky" notes.  You may have used tools such as Powerpoint or Balsamiq.  If you done things "by hand", photograph or scan them to PDF. Your diagrams do not need to be beautiful but they should be clear and legible. 

You need to decide on your "design assets" -- fonts, styles, colors, iconography, graphics.

Beyond the "low fidelity" mockup of your project, you may choose to do a high fidelity mock up.  This basically shows the prototype dressed up with all the design assets.  If you do a high fidelity mock up, include it.  However, you might decide to by pass the high fidelity mock and go straight to implementation from the low fidelity mockup.  That's okay too.

By 10/8, you should have some basis idea of the user experience/user interface will be.  You've sketched out the basic user flow with paper/pencil and sticky notes.  Perhaps you have some paper design mock ups.  You may or may not have decided on the "design assets" -- the colors, fonts, iconography, styles, etc. that you will use.  That might not come in until 10/22.  By this time, your requirements describes all users, the (major) use cases, and all the major flows (if not all flows) expressed by the feature specification. You have a solid understanding of the application flow at this point.

Product deliverables

What exactly are you delivering as a product?  If you are doing a consumer facing web application, this is pretty easy.  A website.  However, you should describe which browsers, operating systems, and mobile platforms you will support.

If you are doing a software product, there are other issues.  What's the install procedure?  Is there documentation?  Are you doing a source code release?

How to turn in this in:

You should give waynekyamamoto and meganca, tlehmann, and anton-github-username access to your wiki.  You'll submit via Dropbox 1 or more URLS to access your requirements document(s).  I've assumed that you'll be hosting your wiki on github. But if not, figure out how to give us access.

Guidelines for 10/08 Milestone (These are hints about the minimum of what you should produce, use the aforementioned descriptions for more details)

  • High level product description (this should be pretty complete in all details)
  • Users and use cases (you should have a good idea of the users and specify 2-3 major use cases at least at a high level)
  • Feature specification (you should specify 5-6 major requirements in high level detail, and 2 in specific detail)
  • UI diagrams/UI mockups (You should have rough sketches of the UI flow that captures the 1-2 major use cases.  You might have some of the "design elements" worked out.  You may have low fidelity renderings of 1-2 screen mock ups.
  • Product deliverables (This should be reasonably complete.)
Guidelines for 10/22 Milestone (These are hints about the minimum of what you should produce, use the aforementioned descriptions for more details) -- We're still evolving the guidelines; stay tuned

  • High level product description (this should be pretty complete in all details)
  • Users and use cases (4-6 detailed use cases completed)
  • Feature specification (you should specify ~15-30 major requirements in high level detail, and ~10-15  in specific detail) -- You'll continue to add and refine requirements in the remain weeks of class
  • UI diagrams/UI mockups (You should have rough sketches that cover  most of the major use cases.  You've closed on the design elements.   You have low fidelity renderings for all the screens that cover the ~10 use cases.  You may have high fidelity screens that cover important use cases.
  • Product deliverables (This should be reasonably complete.)