CS5430 Project: Phase 1 Details

Due Date: 2/8 (Wed) 9am.   No late assignments will be accepted.

Weight: 20%

Deliverable:

The deliverable for this phase is a relatively short document that describes the system your group will build. This document serves two purposes.

1. It allows the course staff to check that what you plan to build is a sensible system and is sufficiently (but not overly) ambitious. Where there are obvious problems, we will ask questions or make suggestions about how to proceed. If there are severe problems then we may invite you to submit a revised document, which we will also review.

2. It defines what you will be building and establishes the baseline against which your implementation will be evaluated. If you don't ultimately deliver a running system with the functionality you propose in this phase then your grade will be lowered. So be realistic.

Note, plans to implement the Extra Credit functionality should not be disclosed in this document. Extra Credit functionality is something to be contemplated only after you have a running project for the baseline functionality.

Format. Your Phase I deliverable should be prepared in Microsoft Word and submitted to CMS as a .doc or .docx. Use 10 point font or larger, "single" line spacing, and at least 1 inch margins. The entire document should be at most 5 pages (single-sided). A document that does not follow these standards will be returned unread to its authors for re-formatting and receive a grade deduction. (Success in life depends, to a surprising degree, on just following instructions.)

Structure your document as follows.

Title: A short descriptive title for your system.

Group: List the group members. Give the full name and netid for each.

System Description: Using a few paragraphs, describe what community your system is designed to serve. Then explain "functionality" your system will implement, justifying choices (where possible) in terms of that intended user community and their presumed needs. "Functionality" here means explaining how your social-networking system resolves the under-specified parts in the project specification (e.g., posting boards, regions, friends) as well as how your social-networking system supports behaviors that are useful but not mentioned at all in the project specification (e.g., how/when a user is notified that "interesting" content has been posted).

Security Functionality: Start by giving the threat model you intend to defend against. Passive wiretappers? Active wiretappers? Arbitrary code co-resident with the Client GUI?

Next, give a bulleted list. Each item in the list should state a security property that will be enforced by your system. For example, in a write-up for a "Networked Banking System" we might find:

• Property: Bank account numbers or information about balances in transit on the network cannot be viewed or changed by wiretappers.
  

• Property: Only the human who has privileges for a bank account can initiate transactions that reveal the balance or cause withdrawals from the bank.
  

We will evaluate your Phase I submission against criteria listed below.

• Whether the document you submit contains the required sections and each section contains the required content.

• Whether the description of functions and features is clear, complete, and is justified for supporting the intended community.

• Whether the security functionality listed is complete and reasonable for the system being built.

Clarity and correct American or British language style and usage is required throughout (because it really does matter in the "real world"). Bad grammar, usage, or style will lead to grade penalties. Groups with all non-native speakers are urged to have somebody (who is not enrolled in this course) critique their prose.