ICSG707 -- Programming Practices

Group Project -- SRS Document and Peer Review

Last change date: March 31, 10pm

0. Problem description

Initially you will want to get together and determine what type of system you would like to develop. Once this has been decided, you can then begin the process of formally defining your project.

1. Software Requirements Specification (SRS)

The SRS is a document that forms the contract between the customer and the software developer. It is a complete description of the external behavior of the system, showing specifically how the system would look to a user. In addition the SRS will form the basis for your overall system testing by defining exactly how the system will perform.

For this part of the project you will not be writing a complete SRS (we want to highlite the system requirements). Instead you will have to produce a document that clearly defines the intended system and all it's behavioral requirements. For this the following simplified form of the SRS document can be used:

Overview - what is this system suppose to do (high level)
General description
- Product functions - the major functions/modes of the system. Show relationship between functions
System requirements
- External Interfaces - data, menu, window formats for input/output/errors
- Functions - flow through the system for each function
Appendices - for any related material

The SRS rough draft is due in class April 7th. You will be required to bring in a non-stapled copy of your SRS. I will be copying these to be distributed to a different group during class, so that we will be ready for the peer reviews.

2. SRS Peer review

Each group's document will be reviewed by another group, the assignments will be made by the instructor.

The purpose of the review is to give constructive criticism of the document to help make the final result more effective and professional. The reviewers should look at the following areas when reviewing the SRS document:

Organization: does the document cover the important parts of an SRS document.
Content: does the document clearly explain what is being delivered, and does it form a solid contract between the customer and the developer.
Grammar: is the document clear and grammatically correct.

Each person will be individually graded on the quality of their review preparation and their participation during the actual peer review.

Each group is working on different projects so you will be given a couple of days in which to evaluate the other groups work. The draft copies will be distributed April 7th and the peer reviews will take place in class on April 9th.

3. Final Due Date

The final version of the document is due in class on April 14. Incorporate as many of the comments from your peer review as you feel are appropriate. Turn in all the peer review materials and your final document for grading.

3.1 Deliverables

Here is a complete list of what to turn in on April 14

Each group should turn in the following documents:

Final SRS document
All the reviewed copies of your draft document. After the in class review, each group should collect all the reviewed copies of the document. This will allow them to update their own document. Make sure to turn in all copies.

Each individual should turn in:

Self evaluation
One evaluations for each person on your team
A single peer evaluation to for the group that evaluated you SRS.

4. Grading

Grading will be done using the following criteria:


    Component						Weight
    ---------------------------------			------
    Quality of the original document			15%
    Quality of you review of the other persons work	30%
    Quality of your final document			50%
    Evaluation by your teammates			5%