C SC 400 Programming Practicum

Winter 2008 Project Deliverables

23 January 2008

The majority of this quarter will be spent in the requirements and analysis workflows. You have just completed C SC 325 and are familiar with workflows and agile development. It is reasonable for you to expect to apply those techniques to your project.

Project Vision and Scope Document

This short document should be structured consistent with the Chapter 5 discussion and p. 82 template in the Wiegers textbook. Adapt as necessary, leaving out any sections or subsections that do not apply and adding any you feel are needed for this project. Either a web page or Word document will be fine.

Requirements and Analysis Specification

The Requirements and Analysis Specification document shall consist of:
  1. Vision and Scope (from above)
  2. Use-case diagrams
  3. Use-case descriptions
  4. User Interface Prototype
  5. Class diagram
  6. Sequence Diagrams
  7. Statecharts
  8. Glossary
  9. credits
To assure uniform formatting, the requirements and analysis document will be a single web page that you produce by editing RAS_template.html. Please save a copy of this file, rename it appropriately and replace template text with your own (look especially for the phrase "goes here"). For best results, edit the HTML code directly rather than through a WYSIWYG editor. The "code view" editor in Dreamweaver MX is a good alternative to Notepad (I'm using it right now).

Textbook Resource: Osbert Oglesby Case Study

The Schach textbook illustrates the development lifecycle through the Osbert Oglesby case study. Oglesby is an art dealer. Chapters 10 and 12, and particularly the sections outlined below address the issues and provide examples of the tables and diagrams that will appear in the Requirements and Analysis Specification.

SectionPageTitle
The Requirements Workflow
10.6278Initial Understanding of the Domain
10.7279Initial Business Model
10.8282Initial Requirements
10.9284Continuing the Requirements Workflow
The Analysis Workflow
12.9363The Initial Functional Model
12.10365The Initial Class Diagram
12.11371The Initial Dynamic Model
12.12373Extracting the Boundary Classes
12.13374Extracting the Control Classes
12.14374Refining the Use Cases
12.15377Use-Case Realization
12.16386Incrementing the Class Diagram

There is no consensus on whether prototyping should be considered an analysis activity, a design activity, or both. I personally feel that prototyping is necessary early in the project. During the interactive hands-on experience of playing with a prototype (or even just viewing it), clients frequently refine and change their ideas, and even come up with new capabilities to be included in the system.

Schedule of Deliverables

Wednesday January 30 Project Vision and Scope document
Monday February 25 First Draft Requirements and Analysis Specification.
Monday March 10 Second Draft Requirements and Analysis Specification.
Monday March 17, 6:00 pm Final Requirements and Analysis Specification, Project Presentation (details later).
[ C SC 400 | Peter Sanderson | Math Sciences server  | Math Sciences home page | Otterbein ]
Last updated:
Peter Sanderson (PSanderson@otterbein.edu)