CSE 436 Software Engineering Workshop
Instructions for Revised Software Requirements Specification
First Draft due by 10am Monday March 5, 2007

Each team should please submit a revised draft of their software requirements specification (SRS) in .doc, .txt, .ps, or .pdf format via e-mail to cdgill@cse.wustl.edu by 10am Monday March 5, 2007 (late submissions not accepted except in extreme cases).

As for your first draft, please write for clarity, readability, and understanding by a wide audience including people who may never have heard about the project.  Please increase the document’s version number from the version number that was on the first draft, and please list the new date of submission.  Please revise your SRS as follows:

1. please address any concerns that we raised about the first draft of the document, according to the feedback we provided;

2. revise each of your requirements further as needed, so that what is being required is specified very precisely, to the point that moving from the requirements to architectural design becomes very straightforward (or even trivial) – this may involve breaking out sub-requirements in further detail, and/or using models (e.g., state machine, data flow, probability formulas, etc.) to describe key requirement’s semantics, as appropriate.

3. as you revise your requirements further, also continue to decompose your architecture diagram and your mapping of the requirements to it as needed, so that all requirements can be mapped specifically and correctly; and

4. label each of the edges (lines between systems and/or sub-systems) in your architecture diagram to indicate what kind of dependence (e.g., uses, triggers, notifies, etc.) each edge represents.

As before, please check your document for grammatical and spelling errors before you submit it (treat it as though you were submitting it as part of a professional product).

We will grade the revised software requirements specifications using the same rubric as for their first drafts:

25% the architecture decomposition and how well the requirements map to it
25% document’s clarity, readability, and understandability by a general audience
25% completeness of requirements in terms of depth and breadth, and allocation
25% quality of requirements in terms of concreteness, un-ambiguity, and cohesiveness

We will assign each document a numeric score out of 100 possible points, and will give feedback to the teams before and during their meetings on Friday, March 9, 2007.