Spring 2007, Dr. Joyce
Project Documentation: Each team will create several documents to support their project. This might include a Set of Questions, a Project Plan, Progress Reports, two versions of a Requirements Specification, a User Interface Design (which will probably be folded into the Requirements), an Architectural Design, and a Post Mortem. These documents should be posted on the team's web site, and also printed and placed into an organized team binder. This binder should always contain copies of all project deliverables, including progress reports and a printed version of the web site pages. Organize the binder carefully and keep it up-to-date. Do not clutter it with miscellaneous material. It should always be easy for me to find whatever I'm looking for in the binder. The binder, with all original documents, will be kept by me at the end of the semester.
All major documents (Project Plan, Q and A, Requirements Specifications, User Interface Design, User's Guide, and Post Mortem) should include the following:
Information about common required documents is included below. Details of each one will be discussed further in class during the appropriate phase of development.
Questions: One "set" of questions per team. Typewritten. Polite, well written, clear, unambiguous, and complete. Based on the short project description and the answers to this set of questions you will be expected to create a project requirements specification draft.
The Project Plan: This is an optional short document that includes at least the team's number, name, a list of members and contact information, roles, organization, communication plans, and a schedule. Roles might include titles and preliminary job descriptions for each team member, for example: Leader (co-ordinate all activity, Project Plan), Secretary (minutes, Progress Reports, web page maintenance), GUI Engineer (design and implement a prototype), Requirements Engineer (customer relations, Requirements Specification), Web Master (design and maintain team project page). The Plan can be revised as the semester progresses.
Progress Reports: These consist of a brief overview of the status of the project, the progress made since the previous Progress Report, a description of any problems encountered, a table showing the time spent on the project broken down by team member and activity (for example Planning, Meetings, Gathering Requirements, Writing Documents) both since the previous report and cumulative, and plans for the near future. The progress reports should be available on-line, on a Web page. They should be posted periodically throughout the semester. You must post at least four progress reports, unless you opt for the "ongoing" progress tracking option, i.e. you continually post your hours and progress on your web site in the form of a table and a diary-type log.
Requirements Specification I: Describes what the system does (functional requirements) and any constraints under which it must operate or be developed (non-functional requirements). Functional requirements can (should) be separated into two categories: essential and non-essential. Non-functional requirements include the system and languages required (if any), as well as any time or space constraints on the executing system. The Specification should give a general description of the system and its purpose, and must clearly describe the typical user inputs and system response. In general, it should be possible for an independent test engineer to construct a test plan for the system based on this document. This document will be corrected, returned, and rewritten based on the instructor's comments.
Requirements Specification II: The corrected version of the above. Also includes a robust user interface description, which should probably include several screen shots, and some user "scenarios" or use cases that describe the steps a user would follow to perform some common functions. Towards the end of the document include a Cost Estimate section where you predict the effort/schedule needed to complete the base version of the system by a team of three senior computer science majors. When you submit this document you should also submit the "marked up" original version.
Team Post Mortem: An end of semester report of the team's overall experience with the project, to be handed in with the Final Package. More information as to content will be provided later in the semester.
Other: There will probably be a few other small writing related assignments, for example the critique of a project specification, comments on readings, and a personal post mortem.