CSC 308 Milestone 10

Traceability between Requirements Scenarios and Formal Spec

For the final project deliverable, make sure that all requirements scenarios are consistent with the model, including the preconditions and postconditions. Details of how to accomplish this are in Lecture Notes 4 through 10, and the accompanying examples.

Requirements for File and Edit, plus Error Conditions

Don't forget the scenarios for file and edit functionality, as well as error conditions. Details are in Lecture Notes Weeks 9 and 10 in particular items III and IV.

Formal Modeling

The Java/Spest model must compile with the javac compiler and the Spest checker. Since the Spest checker is experimental, any checking incorrect checking results that are determined to be a problem with the checker will not be your responsibility to address. That is, your models must check with Spest insofar as the checker delivers correct results.

To document those Java files that do not correctly check with Spest, add a file named spest-issues.html into the project administration directory. This file contains a list of the files for which Spest gives incorrect results, with a brief description of what the incorrect results are. Please confirm this file list by sending email to gfisher@calpoly.edu and cjohns71@calpoly.edu.

Prototyping

Typically, each team member must complete two additional prototype GUIs, beyond those done for Milestone 8, for a total of five prototype GUIs per team member. We will discuss details of this in lab meetings.

The prototype deliverables must meet the following requirements:

1. In addition to explaining how to compile and execute the prototypes, the README file must describe for each team member what actions lead to the display of that member's GUIs. For example:

   Team Member     Actions
   ======================================================================
   Jane Doe        Select 'File' in the menubar
                   Select 'View' in the menubar
                   Press 'Add' in the View dialog
                   Press 'Edit' in the View dialog
   
   John Smith      Select 'Edit' in the Menubar
                   Select the 'Preferences' item in the 'Edit' Menu
                   Select the 'X' item in the main tool bar
                   Press the 'Save' button in the 'X Tool' dialog
   ...
   

2. There must be only as many top-level executables as there are separate end-user interfaces to your tool. I.e., individual GUIs must come up from a normal top- level UI, not be executed as separate stand-alone programs.

3. You must provide a UNIX Makefile to build the prototype. The Makefile must build everything to run on unix3; this means that if you use any external libraries, you must include the appropriate .jar files, and implement the Makefile to use them for compilation.

Sections 3, 4, and Appendices of the Requirements Specification Document

Section 3 on non-functional requirements consists of just two subsections:

Section 3.1 System Performance
Section 3.2 Qualitative System Characteristics

In 3.1, describe performance in user-level terms, in these areas:

• interactive commands that should respond immediately; the term to use for these is "effectively instantaneous", which means the command executes instantaneously from the end user's perspective, disregarding any delays that are beyond the control of the software tool itself
• computational commands that may take longer to run; give an allowable maximum amount of time
• maximum size requirements for stored data, in terms of number of data elements, not bytes

In 3.2, describe the following general characteristics:

• security and privacy, as appropriate, and in what areas this is important
• where your tool overall, or where different features of your tool, fit on the simplicity versus power spectrum; i.e., is it supposed to be simple to use for less sophisticated users or does it have advanced features geared towards "power" users

Section 4 is an executive summary of the model, aimed at the deign/implementation team. Summarize the module structure, major objects, and major operations. Include a "heads up" to the implementors for any parts of the project that you think might be particularly difficult to implement. Limit this to the equivalent of one printed page or less.

No appendices are required, in particular no Users Manual (it was listed in the original specification document outline handout). As noted below, if you have any late updates, put them in an Appendix A.

Summary of Final Project Delivery

Organize the project directories and files as described in the handouts:

• the requirements specification document outline,
• file and HTML structure for the document,
• standard operating procedures, volume 1
• standard operating procedures, volume 2 on testing

If there are wide-ranging changes that you do not have time to make, describe them in Appendix A, titled "Late Updates". A good example of what can go in this appendix is a description of changes that should be made to a large number of screens that you do not have time to redraw.

If there are known problems with any aspect of the requirements or specification, or other summary comments your team wants to make, put the comments in the file

administration/project-summary.html

Complete Point Breakdown for the Class

The following table is the complete point breakdown for the class. It has adjustments to the point breakdown shown originally in the syllabus, to remove the second lab quiz and add the UI prototype.

ITEM	POINTS
Requirements Specification Document:
Sec 1 Problem Analysis	2
Sec 2 Functional Requirements	21
Sec 3 Non-Functional Requirements	2
Sec 4 Developer Overview	1
Sec 5 Formal Specification	20
Objects, operations, descriptions (15/20)
Pre and postconditions (5/20)
App A Late Updates (Users Manual NOT REQUIRED)	0
App B,C Other Appendices (optional)	0
Requirements Spec Subtotal:	46/100
UI Prototype	10
Inspection Testing	6
Team Administrative Duties	5
OVERALL PROJECT SUBTOTAL:	67/100
Lab Quiz	3
Midterm	10
Final	20
EXAM SUBTOTAL:	33/100
CLASS TOTAL:	100/100