Due Thursday, February 21.

• Wiki organization. Create some top level pages on your project wiki to document project progress. Note that nothing counts as done unless it's visible on the wiki or web page.

  For some ideas about wiki structure, look at the TREAT and KICS wikis (from previous cs410 classes) or at the wikis for the projects in my current cs682 class.

  Use blank pages or skeleton pages as placeholders for content to be filled in as it becomes available.

• Team Organization.

  Your team will need some administrative structure. That's separate from the tasks of writing specifications, coding and testing, which all team members share.

  Here are some possible roles. Consider rotating these jobs from time to time, perhaps combining them.

  • Team lead (general nag - not the boss or the manager)
  • Customer contact person
  • Professor contact person
  • Webmaster
  • Wikimaster
  • Secretary (responsible for posting detailed meeting minutes)
  • Editor (reviews wiki and web page content for consistency and correctness)
  • Schedulemaster (The team is responsible collectively for setting the schedule. The schedulemaster keeps the it up to date, reminds people of deadlines.)
  • Sysadmin (manage svn, server (if required))

  Create a team mailing list and make sure all share it. Do not put me on it!

• Schedule.

  Posted list of dated deliverables, with details about who does what and when.

  Regularly updated with YES when tasks have been completed on time and NO when not. Boolean decision, no faking. ("Start foo" is not a scheduled task. "Short story for scenario foo, edited by at least two people" is.)

• Vision

  Your project needs a classy logo, a clever name and a vision statement. The client will have to sign off on them, but the designs are yours.

  These will appear on the project home page (not the wiki page). The index.html for that page is linked from the course web page. If I have set up permission correctly, you have edit privileges there. Use them.

  For suggestions, look at the home pages (not the wikis) for the SE projects from my other classes: TREAT, KICS and this year's cs682.

• Short Stories. (Functional requirements)

  Start specifying functional requirements by writing short stories based on what you can recall (collectively) from client presentations.

  These must be written in grammatical English, as narratives about how real people will use your software. They are not descriptions of the GUI (no "user clicks on ..."). They are not architecture specifications (the word "database" should never appear).

• Nonfunctional requirements

  Nonfunctional requirements include information like platforms that must be supported, tools required by the client, performance requirements.

  Draft these if you can, with placeholders if necessary. You won't be able to fill in details until you've conferred with your client.

• Communication with client

  Send introductory email. Start planning a first meeting. Set up communication channels (email, wiki).