CSC 4150 / CPE 4150
Team Project Handbook




Autumn 2007
Prof. Elaine Weltz
Table of Contents
General Project Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
Team and Personal Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Basic Requirements for All Written Documentation. . . . . . . . . . . . . . . . . . . . . .
5
System Requirements Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Implementation Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User's Startup Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
Appendices
Appendix A – Sample Team Documentation . . . . . . . . . . . . . . . . . . . .
Appendix B – Sample Use Case Template . . . . . . . . . . . . . . . . . . . . .
Appendix C – Sample Data Dictionary: Class and Attributes. . . . . . . . . .
Appendix D – Sample Data Dictionary: Operations . . . . . . . . . . . . . . . .
12
13
14
15
1
General Project Information
DESCRIPTION
Using software engineering disciplines learned in CSC 3150 and programming techniques from courses
such as CSC 1230, 2430, 2431, 3220, 3221 and 4410, develop and deliver a tested and documented
software system.
TEAMS
A team of 3 or 4 persons will develop each project. Students will form their own teams and select or define their
own project. All students must participate in a team. The instructor reserves the right to redistribute people or
modify a project proposal if she feels it is necessary.
You will not have time in a single quarter to learn new languages or development environments AND create a
complete system. Therefore, the following conditions apply to teams and project types:
 If a team wishes to build a database application, at least ½ of the team must have applicable experience
in database design (for example, CSC 4410).
 If a team wishes to use a language other than C++ or Visual Basic (for example, C# or Java) or a
programming environment other than Visual Studio, prior completion by at least ½ of the team of a
course in the language of choice or experience in writing applications using the language is required.
 If a team wishes to build a Web-based system, at least ½ of the team must have applicable Web
application experience (for example, CSC 3221).
A word of caution to students planning to create a network plus a networked system or custom hardware plus
software: plan your time very carefully. Historically, students wishing to create a network or hardware and an
application using it have run out of time, succeeding at only one or the other, but not both.
PROJECT CHARACTERISTICS
Each team will define their own project. While having a non-team-member as customer will provide a more
realistic development experience, it is not required. The instructor will provide examples of previous projects to
assist in the definition process.
ALL projects will:
1) Be a Windows-based personal computer application, an interactive console application that can be run
within a Window, or a Web-based application. Access to cs.spu.edu is an option for database and webaccessible database systems. The system may involved HW creation or modification (especially for CPE
majors) but is not required to do so.
2) Be user-oriented; be appropriate for the intended user and accessible for instructor grading.
3) Be accompanied by appropriate user documentation.
4) Include complete input checking (i.e., be "bullet proof").
5) Be executable using OMH computer lab OS and software versions. cs.spu.edu current versions are the
target for database and web-accessible database systems. The instructor will not be able to install a
special environment in order to test the application. Open source tools / environment may be used. In
this case, any platform installation required to run the application must be a part of your system install.
(With a well-written web app, this will not be an issue.)
6) If a project requires additional or specialized hardware for execution, it is the team’s responsibility to
make this available to the instructor for grading, and to provide all necessary documentation for its
installation and use.
2
PROJECT MILESTONES
Except for the two demonstration days and Requirements Review, the milestone dates for deliverables are "not
later than" dates. In the past, students have tended to become pushed by time pressures near the end of the
quarter. If you wish to give yourselves more time for coding and testing, you may turn in requirements or design
specifications any time prior to their due dates. A two-working-day grading turnaround is promised for all
submitted documents. With that in mind, the following should be noted about the end of the week:
 I will be leaving campus immediately after class on Fridays. If you wish to submit a deliverable on Friday,
please bring it to class.
PROJECT TIMETABLE
DATE
September 28 @ noon
October 12 and 15
October 19
October 22
November 9
December 3
December 7 @ noon
DELIVERABLE
Project and Team Proposal (may be submitted electronically)
Requirements Review deadlines (material exchange and review meeting)
System Requirements Document
User-Interface Prototype Demonstration
System Design
System Presentation and Demonstration
Implemented and Tested System with User Documentation
Team Reflection and Peer Evaluations
GRADING
1. Requirements and Design documents are graded on the following:
 Completeness and continuity of the document.
 Adherence to written document standards (see page 5).
 Neatness and polish
 Correct application of the "technical rules" of the analysis and design methodology used. Variations
introduced, or methodologies used other than those introduced in CSC 3150, 4150, or 4410 must be
documented (and your documentation adhered to).
 (Requirements) All listed functional requirements must be documented via use cases; all use cases must
be traceable back to given functional requirements.
 (Design) Comparability and traceability to System Requirements. Major changes must be documented;
minor refinements need not be. Your System Requirements document will be included as an appendix to
the Design document so that comparability and traceability can be judged.
2. The finished system will be graded on the following:
 Completeness of the system (any missing features must be documented as such).
 Documentation neatness and polish; adherence to written document standards (see page 5).
 Ease and convenience of operation.
 Correctness – does it work?
 Effectiveness – does it do what it advertises?
 Aesthetics – is it user friendly; is the UI consistent, logical, and pleasing to the eye?
3. Percentage of quarter grade associated with each project deliverable:
 System Requirements Document
10%
(page 6)
 User-Interface Prototype
10%
(to be described in class)
 Design
10%
(page 8)
 Presentations (2)
10%
(to be described in class)
 Implementation w/ Documentation
15%
(pages 10 and 11)
3
Team and Personal Documentation
Members are expected to be equal contributors to their team (though contributions within a specific
phase or on a specific activity may vary). Since the instructor cannot "police" each team, four
instruments will be used to monitor team activity and individual contribution.
Team Documentation

Team Log. Each team will keep an ongoing report of status throughout the quarter. This will consist of a
weekly emailed Meeting Log, including “minutes” for each team meeting. All teams will meet at least once
per week; if there are more meetings, include notes for each. Email this to all team members and to the
instructor (eweltz@spu.edu). The email MUST have as its Subject: 4150 Log. Each week’s log must be
received by the instructor by noon each Tuesday. A sample outline is included in Appendix A. The exact
style can be tailored to the needs of your team.

Team Reflection and Evaluation (Project Post-Mortem). Each team will submit an evaluation of
their project experience. This will take the form of answering several open-ended questions. The exact
questions will be distributed near the end of the quarter; the evaluation is due December 7 with system
deliverables.
Personal Documentation

Personal Time-Sheets. Each team member will keep a detailed accounting of time spent on project
activities. This will be submitted for review via email to eweltz@spu.edu. Include time spent on each
activity (to the nearest ¼ or ½ hour) and total time for the week. Appendix A shows a weekly summary
example; you can keep a daily log if you prefer. This reporting is the responsibility of each individual. The
email MUST have as its Subject: 4150 Time and must be received by the instructor by noon each Tuesday.
To be most helpful, teams should plan to review each other’s time sheets on a semi-regular basis. In this
way, they will obtain a clearer picture of inconsistencies in the amount of time being spent on project
activities and can work toward balancing the load.
 Peer Evaluations.
Each team member will complete an evaluation of team members (including
themselves). This form will ask you to rate the contribution made by each team member to the
development process. An evaluation form will be distributed near the end of the quarter; it is due
December 6 before the start of the Final Exam.
A Word on Working Together
Stress points WILL arise during the quarter. Your fellow team members will at times be your closest
friends and at others your greatest frustrations. It is the responsibility of ALL TEAM MEMBERS to
communicate regularly and openly with one another. You are all responsible for each other. Each
person is expected to do everything in their power to achieve project success AND everything in their
power to facilitate the success of the rest of the team. If you are having any difficulty with completing
tasks for any reason, don’t keep it a secret; to do so ensures a project of less than optimum quality!
4
Basic Requirements for All Written Documentation
1. Deliverable documents for CSC 4150 will always include the following at their beginning.
1.1. Title Page. This will include the name of the project, name of the document, team name, member
names, and date. Graphics and/or color are optional (but nice). This is the reader’s first impression, so
it needs to be "professional" in appearance. (Example: Pfeiffer page 104)
1.2. Table of Contents. (Example: Pfeiffer pages 106 – 107) This implies that document pages will all be
numbered. If you cannot do this all automatically (because of pages being produced by different
software), pages may be neatly numbered in black ink.
Make sure that all sections are clearly and correctly defined in the Table of Contents. Sections should
be outline numbered in some way. Note how this document is laid out, or use computer science
textbooks as examples. Additional examples are available for you to look at during office hours. Use
dividers are to be used to separate major sections.
1.3. Executive Summary. Use the Executive Summary included in ABC Format 15, page 108 of Pfeiffer as a
guide. The 3rd paragraph (recommendation) should be replaced by the REPORT FORMAT section of
Pfeiffer's Introduction, page 109.
2. At the end of the document, insert the following sections.
2.1. Glossary. This section is optional, but probable. Include the definitions of any technical terms used in
the document or any application area terms a technical reader may not know. Since you cannot make
any assumptions about the experience or expertise of the reader, it is best to be on the safe side and
define more, rather than fewer, terms.
2.2. Bibliography. Include here any and all sources you have consulted for help in defining the application
domain, any CASE and documentation tools used, and any other resources you have used.
3. General requirements and picky points:
3.1. All deliverables are to be submitted in a three-ring binder (or may be more permanently bound if you
prefer).
3.2. You may use any easy-to-read font for word-processed sections of the text. Use an 11- or 12-point size
as your minimum (headings may be larger). Use this as your minimum size for diagram text and labels
as well. Use boldface, underlining and italics carefully to highlight headings and important text.
Remember how useful numbered and bulleted lists are in technical writing.
3.3. Technical documentation is normally single-spaced. However, you should separate document sections
with white space to make them easy to locate (6 or 12 point spacing is fine). Major sections will begin
on their own page (as in this document). Paragraph spacing must be consistent.
3.4. Spelling and grammar count. Excessive errors (defined as more than 1 or 2) will result in a lowered
grade regardless of the quality of information included in the document. Exceptions to the requirement
for grammatically complete sentences include lists of items and entries entered in definition templates.
3.5. Neatness and organization count. Always keep in mind that this document could be for submission to
a customer or a manager.
5
System Requirements Document
Reminder: Refer to “Basic Requirements for All Written Documents" for additional information on
document content and layout.
The following is the “company standard” outline of sections for a CSC 4150 requirements document.
Your audience is a combination of your team and any possible customer/client. Each section except the
Introduction will also include its own “introduction”, a short paragraph telling the reader what to
expect from the section.
Executive Summary – see Pfeiffer page 108. Use this summary to introduce your team, describe your
activities to date, and your plans for the remainder of the project.
1. Introduction
 System Description and Rationale – See Pfeiffer page 109, “PROJECT DESCRIPTION”. What is being

built? By whom? Why is it being built? Who is the customer? What are the expected benefits to
customer and user?
System Scope – Briefly describe what is (and is not) included in the scope of your system’s functionality.
List, but do not describe here, the major system services. See Pfeiffer page 109, “SCOPE OF STUDY” for
style suggestion. Include also how your system will work and interface with other systems (if applicable).
2. System Requirements – See D/W/T Chapter 5, especially pages 124 – 129, and Tsai/Kamar Chapter 6 for
a review of requirements analysis, functional requirements, and nonfunctional requirements.
 Functional Requirements – Provide a brief textual description of the system’s functional requirements.
Outline and briefly describe the services to be provided to the user; a bulleted list of requirements might
be the easiest to create – and reference. One can think of this section as providing the details of the
system services listed in the Introduction’s “System Scope”.
Functional requirements must be related to and traced to the Software System Model (section 4). Include
references to which Use Cases will provide each required service, making sure the reader knows what
these references mean.

Nonfunctional Requirements – List and describe any and all:







System Requirements and Constraints (hardware, memory, networking, etc.)
Software Requirements and Constraints (are there limitations or version concerns?)
Performance Requirements (for example, speed, capacity, reliability)
Security Requirements
Cultural or Political Constraints
Project Constraints (for example, team and time constraints)
Other Constraints (if there are any)
All requirements (functional and nonfunctional) are to be stated in quantifiable, testable language. For
example, NOT “Page download will be fast” BUT rather “Page download time will not exceed 5 seconds.”
3. Hardware and Software (ref. D/W/T Chapter 13, “Physical Architecture Layer Design” and Tsai/Kamar
Section 7.2, “Architectural Design”)
This section places the system to be built in its context and describes HW and/or SW that will be needed in
order to implement and operate the system. Most 4150 projects do not assume purchase of HW/SW. If this
is the case, no purchase cost information is required; target HW/SW minimums still need to be outlined.
6



Description of System Architecture – Is this a stand-alone or interconnected (networked) system? Is it
server-based, client-based or client-server in architecture? Are there client-server tiers? Where are each
of the four “basic functions” (data storage, data access, application and presentation logic) housed?
System Architecture Model – D/W/T Figure 13-9 (page 435) shows three versions of UML Deployment
Diagrams. Provide at least one diagram of your system’s architecture in Figure 13-9’s Version B or Version
C styling. If you wish to include BOTH version B and C style drawings, that is fine (although for standalone
systems it would seem a bit overkill). Include before the drawing(s) a text description of the components
of the system’s environment.
Required Hardware Components
Describe minimum and recommended HW requirements for your system. Include estimated purchase
cost (if applicable).


Required Software Components
What system and support software is required to run your system? Include estimated purchase cost (if
applicable).
Development Software – describe any tools to be used in system development. Include why these have
been chosen.
4. Logical System Model
 Use-Case Diagram (ref. D/W/T Chapter 6; Tsai/Kamar 6.3.2)
Use Visio to create a Use-Case model (VISIO Software / UML Model Diagram / UML Use Case). Remember
that not all readers of a Requirements document are technical types, so be certain to describe in your
introduction to this section what the symbols mean.

Use-Case Descriptions (ref. D/W/T Chapter 6)
Include Use-Case Descriptions to describe the activities of your system. Appendix B of this handbook
includes a sample template (available electronically from my home page:
http://myhome.spu.edu/eweltz/, CSC 4150, Downloads). ALL USE CASES MUST BE DESCRIBED.

Initial Data Model (ref. D/W/T Chapter 7; Tsai/Kamar 7.3.3; CSC 4410 text and/or notes)
For most of you, this will consist of a Class Diagram (VISIO Software / UML Model Diagram / UML Static
Structure). For this initial model, you need only include the Classes you anticipate for the system with
their Attributes and Relationships (that is, no operations at this point). If you prefer, you may use VISIO to
draw an Entity-Relationship Diagram for a database-oriented system.

Data Dictionary
Include Visio screen shots of class and attribute definitions. For all classes (including association classes)
include Name, Visibility, Documentation (1 – 3 sentence description), and attributes. For all attributes,
include Attribute (name), Type, Visibility, Multiplicity, Initial Value (<None> if there is none). Appendix C
shows which documentation is expected and the desired detail. Similar information is required for entityrelationship diagrams, though style can be modified (see instructor if you are unsure if your style is
appropriate).
To be useful, this dictionary must be in alphabetical order by Class (or entity).
5. System Evolution
You may already be aware of system functions that are desired but will not be part of the original version.
These, and any planned or recommended upgrades to hardware or software for continued system use, should
be outlined here. This is also the appropriate place to document which system services are guaranteed for
Version 1 (the one you are building this quarter) and which might be considered optional until later if time
becomes a problem.
7
System Design
Reminder: Refer to “Basic Requirements for All Written Documents" for additional information on
document content and layout.
The following is the “company standard” general outline of content sections for a CSC 4150 design
document. Your audience can now be assumed to be entirely technical (developers and developer
managers). Each section except the Introduction will also include its own “introduction”, a paragraph
telling the reader what to expect from the section.
Executive Summary – see Pfeiffer page 108. This may be pretty much a repeat of that in the System
Requirements Document, except that you will want to update the description of activities to date and the plans
for the remainder of the project.
1. Introduction
What would someone joining your team at this point need to know as background information? The answer
to this question should guide both your content and writing style.




System Description & Rationale
System Scope
Requirements Definition
Hardware and Software Environment
Revise and summarize
Requirements Document sections
1, 2 and 3 as developer overview.
2. User Interface Design (ref. D/W Chapter 12; Tsai/Kamar Section 8.5)
 User Interface Requirements and Constraints
This is the text introduction to the section as a whole. Include any guiding principles or constraints on the
user interface design.

Windows Navigation Diagram
See Figures 12-7 and 12-18 of D/W/T. This diagram is very helpful to the reader of the next parts of this
section, as it will tell them how all of the user interface elements fit together. You do not need to include
every little dialog box or pop-up the user might see, but at least show how the major screen forms and (if
applicable) reports are related. Since you will have already completed a UI prototype, this documents an
at least partially completed interface.

Screen Interface Design
While a UI prototype has already been developed, system builders will also need hardcopy layouts of
screens as part of the design documentation. Any revisions, additions, or deletions made since prototype
completion are to be reflected here.

Report Layout Design
This section will include printouts from the prototype of on-screen reports and designs for printed
reports. If printing interface screens generates “reports”, document that here. If nothing is to ever
printed, this section will simply be a statement of that fact (and why).
8
3. Structural and Behavioral Design (ref. D/W/T Chapters 7 and 10; Tsai/Kamar 7.3.3)
NOTE: If your system is not designable using object-oriented techniques, see the instructor to discuss
alternative program design methods.
 (Complete) Class Diagram (D/W/T Chapter 7)
This final version of the system Structural Model will begin with your Initial Data Model (Requirements
Section 4). Add the operations needed to implement your system, being careful to correctly and
completely define all parameters and return values. Add any new needed classes or attributes; you may
also eliminate classes now determined to be unneeded.


Updated Data Dictionary: Classes with Attributes and Operations
While Contracts (D/W/T) are a good way to describe the outline of classes and operations, their creation
would include some documentation that is redundant to the class and attribute definitions you have
already completed for System Requirements. Therefore, I have chosen to have you submit operation
documentation similar to that for CSC 3150. Appendices C and D provide examples of content and
printouts.
For all current classes (those included in the Complete Class Diagram of the previous section), include:
Name, Visibility, Documentation (1 – 3 sentence description), attributes, operations
For all attributes of these classes:
Attribute (name), Type, Visibility, Multiplicity, Initial Value (<None> if there is none)
For all operations of these classes:
Operation (name), Return Type, Visibility, Scope
For parameters, Parameter (name), Kind and Default Value (or <None>)
Describe the operation (Documentation), and be sure to note if “IsQuery”.
Note: This description need not be complete pseudo code, but should be more detailed
than, for example, “this operation handles a customer request”. The key is that this needs to
supply enough detail that a programmer could use this information, along with the Behavioral
Model of the next section, to code your class.
Behavioral Model (D/W/T Chapter 8)
 Submit either UML Sequence or Collaboration Diagrams showing how your classes will accomplish the
Requirements Document’s Use Cases. Since you want to develop a complete system, it is assume that
all use-cases from System Requirements will be documented by these diagrams.
 Submit a Statechart Diagram to show the states of at least one object type in your system. More are
optional…but a good idea if they will help visualize and create the system.
4. System Evolution
Revise and update this section from your System Requirements Document. You may now have a better idea
of what can be done now and what must be done later…
5. Appendix - System Requirements Document
Does not need to be rewritten, but any substantive changes that have been made to the requirements during
design should be noted. You may make such notations neatly in ink (using blue, red or green so as to contrast
the black printing).
9
Implementation Deliverables
The following 4 items are to be submitted as your completed project. The first two are to be
electronically submitted, but last two must be in paper form (even if you include a ReadMe and/or
online help with your system).
1) Software System (executable)
This may be submitted on CD or other media, or as the address of a Web-based application. Aside from that, I
would prefer not to have to deal with the additional "variables" of downloading a system from the Internet or
as an email attachment…so I won’t.
2) Source Code
This is for the purpose of establishing that your team followed appropriate coding style and documentation
standards. It may be submitted as hard copy or on disk (preferred). Yes, this will be reviewed as part of the
system's evaluation. For database apps, basic DBMS-generated data dictionary materials will be substituted
(or you may include in your User's Manual a section telling "advanced" users how to access embedded code).
3) User's Startup Manual
The outline on the next page is to be used as a guide. Make sure that your User's Manual is accurate and easy
to read. If I run into any difficulties with using your system, guess where I'll look for help!
4) System Development Documentation
Re-submit your System Requirements and Design Documents as an Appendix to the Startup Manual.
10
User's Startup Manual
You may assume that your user is familiar with Windows (and Internet Explorer if a web-based application), but
needs to know how to install and run your system. Use the following outline for your manual. You will find that
some of this material can be pulled and revised from previous documents.
Sometimes students ask if this is really necessary for a Web application. The answer is “Yes”. You might,
however, want to recast it as a “System Information Guide”, letting users know more about your system. Or, you
might find it helpful to differentiate between two types of users: system administrators and (web) users. The
getting started material will need to include how to navigate to your system.
Title Page – Similar to Requirements and Design title pages.
Table of Contents – Be sure all pages are numbered and all sections clearly defined.
Introduction
 System Overview
 Special Features – What the user can expect from the system. Include what makes your system unique,


but remember that you've already made the sale: this is not sales pitch time.
Organization of this Document – what the reader will find in sections II and III
In Case of Difficulty – Who to contact if the system doesn't load or run correctly. Include at least one
each email and telephone contact possibilities that will be valid the week following the end of Autumn
quarter. This can be important!
I. Installation Instructions
 System Requirements
Minimum Hardware Requirements
Required Operating System (including versions)
Required Support Software (including browser version, DBMS, etc.)

Inventory of Materials
Number of discs, including size and format (if applicable)
List of (major) files making up the system
Anything else included with the system

Procedures for Installation
Outline the steps for installing your system (or accessing it from a web site)
II. Getting Started
This section is an outline of basic normal system use. The exact organization of this section is up to you, but it
should be easy for a first-time user to understand. If you prefer to submit this electronically, include a page in
the printed Startup Manual telling the reader how to access the information. Describe:
 Each system function in terms of the screens the user will see and the purpose and result of each menu
choice
 The input expected by each screen
 The output that can be expected along the way
 Any special features, formats or warnings for screen navigation or data input
Glossary - Define any special terms, abbreviations or acronyms that may be unfamiliar to the first-time user
of your system.
Additional on-line user documentation is optional
11
Appendix A – Sample Team Documentation
Meeting Log
Team:
Date:
Members Attending:
Progress Reports on Action Items from Last Meeting:
Concerns and New Items for Discussion:
Action Items and Team Assignments:
Next Meeting Date/Time/Place:
Personal Time-Sheet
Name:
Elaine Weltz
Week Ending: April 28
Time
Activity
2 hours
Use Case Diagram
2½ hours
UI Design
10 hours
UI Prototype coding
1 hour
Team meeting
Comment
Taking longer than expected!
15½ hours
12
Appendix B – Sample Use Case Template
Use-Case name:
Primary actor:
Stakeholders and interests:
ID:
Use-Case type:
Importance:
Brief description:
Trigger:
Trigger Type (circle one):
Relationships:
Association:
Include:
Extend:
Generalization:
Normal flow of events:
External
Temporal
Subflows:
Alternate / exceptional flows:
13
Appendix C – Sample Data Dictionary: Class and Attributes
Note that the inclusion of the Class picture is optional, since it will be a part of the diagram that
precedes the Data Dictionary.
Advisor
+AdvisorID : Long
-Name : String
-Phone : String
-Office : String = DH 100
+QueryGrad(in Student:Student) : Boolean
+ListAdvisees()
14
Appendix D – Sample Data Dictionary: Operations
Class Advisor’s Operations:
The Operations’ Parameters:
QueryGrad Details:
15