CSC 308 Standard Operating Procedures,
[V&S, Use-case Document, Data Dictionary and] Requirements Testing

(much of the information here was developed by Dr. Fisher)

Introduction

The purpose of thorough requirements testing is to ensure that the publicly accessible documents we produce are of high quality. Since the requirements cannot be executed in the conventional programming sense, testing of requirements is done by careful human inspection.

Each team project will appoint an official inspection tester on a rotating basis. A rotation will last one week, starting on week 5 of the quarter, or week 6 for teams of fewer than five members. The assignment of inspection test duties for each team should be determined by the start of week 5, and entered in the following table, a copy of which should be stored in the project repository, here is a good format:

Week No.	Team Member	Initials
5
6
7
8
9

The second column of the table has the name of the team member who is the inspector for the given week. The third column has the official two- or three- letter initials for the inspector, which will be used in the inspection test record described below.

It is the responsibility of the inspector to enforce the inspection testing standards described below. This enforcement should be performed before the functional requirements are publicly released. 

Standards for Inspection of Functional Requirements

The standards described here apply to the 308 requirements specification document -- the Functional Requirements. Since this section of the document is written in HTML-formatted English prose and pictures, the inspection test procedure is defined in terms of the HTML document elements that organize the prose and pictures. Specifically, the functional requirements are subdivided into components denoted as follows:

	Denotation	Required Inspection
Text	For any level n>=2, a section of functional requirements is denoted by the Dewey-decimal style numbering for that section.	follows the recommended template, compared to the worked out examples in the text and from the class website spelling, grammar, presentation style (simply written and understandable?) correctness (has it been verified by customer or alternative?)  traceable to its source? testability (has a simple, realistic test been written for the requiirement?  No bad words?) consistent with the entire set of requirements consistent use of data items from problem domain, use of the customer's naming for terms (did the user approve your data dictionary as accurate and understandable for the problem domain?) complete (is anything missing, does the context provide enough to meet the requirement?)
Pictures, Diagrams	Each image in a (sub)section is numbered "Figure n", with n starting at 1. For example, "2.2.1 Figure 3" is the denotation of the third picture or diagram in Section 2.2.1.	existence of image file, spelling, grammar, presentation style, image quality, aesthetics (in consultation with team artist as necessary) attachment to the physical document does the picture, diagram or model add value over the text (redundant information must be justified and carefully kept consistent so avoid it unless absolutely necessary.) has the customer approved, does it increase understanding?

Inspection Test Plan and Record

A functional requirements inspection test plan is a five-column table consisting of a row for each component of the requirements, i.e., section, paragraph, image, and anchor. The five columns are:

1. requirement component denotation, e.g., 2.2.1 Figure 3
2. three-letter inspector initials, as specified in the inspection-roster file
3. the date of the most recent inspection
4. status, which is one of "DONE" or "FIX", where DONE means the component passes inspection or FIX means the component requires fixing of some form; a blank status entry means no inspection has been performed on the corresponding requirement component
5. remarks describing what fix(es) need to be made

A functional requirements inspection test record is a completed or partially completed plan. For example, the following is the beginning of a typical inspection test record:

Component	Inspector	Date	Status	Remarks
2.1	GLF	21oct06	DONE
2.1P1	GLF	21oct06	DONE
2.1 Figure 1	GLF	21oct06	FIX	image quality is poor due to small size; rescan from original into larger GIF format
2.1A1	GLF	21oct06	FIX	the anchor target is not found; check file existence and protection
2.1.1	GLF	21oct06	DONE
2.1.1P1	GLF	21oct06	DONE
2.1.1 Figure 1	GLF	21oct06	DONE
2.1.1P2	GLF	21oct06	FIX	grammatical error in sentence 1: "number" => "numbers"
2.1.1P3	GLF	21oct06	DONE
. . .	. . .	. . .	. . .

Procedural Details

For the weekly rounds of requirements testing, it is the job of the assigned inspector to identify problems, not correct them. The inspector is responsible for writing the test plans for each file, per the guidelines presented above. The inspector is then responsible for performing the tests and filling in the results in each test-plan file. These filled-in test plan files are the official record of the inspection testing, and when completed are checked into the project repository.

The specific time-line for inspection testing goes like this:

1. Each member checks in work to the repository.
2. The inspector updates her/his working directory from the repository.
3. The inspector performs the inspection of all files.
4. The the inspector checks in the inspection test record.
5. The librarian updates the projects/work release directory.
6. At a subsequent team meeting, the inspector outlines the results of the inspection testing to the rest of the team, and informs specific individuals of corrections that need to be made.

It is important to note that the formal inspection is only the last step of the weekly testing process. Each individual team member should inspection test her/his work prior to check in. In particular, the inspector deserves to be non-plussed if there is a lot of sloppy work checked in for inspection testing.