• Draft customer question list is due for 2nd-week Monday lab meeting
• Completed project deliverables must be checked into project repository by 11:59PM Wednesday, 14 January.

Activities

There are five tasks for Milestone 1:

1. Determine team member duties, as outlined in the syllabus; i.e., overall leader, assistant leader, technical leader, librarian/secretary, documentation specialist, and aesthetic specialist. Record these duties in the project administration directory, in the file governance.html. There is a template for the governance file here:

   http://users.csc.calpoly.edu/~gfisher/classes/308/admin/governance-template.html
   

   which contains additional instructions for filling it in.

2. Have a team brainstorming session to discuss initial ideas for the features your system could have.

3. Begin the search for tools with functionality comparable to the tool your team is specifying.

4. Prepare a list of questions for the customer interviews held during the second week lab meetings.

5. Produce a rough draft of Section 1 of the requirements specification document:

   1. Assign writing duties to individual team members for subsections 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5.0.

   2. Assign writing duties for subsections 1.5.1 through 1.5.6

   3. Write the rough drafts for the assigned subsections.

Discussion of Task 5 (Rough Draft of Section 1)

Section 1 of the requirements document provides a general overview of what the proposed software system will do. The Calendar Tool example illustrates the concrete details. For your projects, Section 1 will have similar information to the Calendar Tool example, but the details will differ appropriately.

Record the work assignments in the work-breakdown.html file in the project administration directory. There is a template for this file in 308/admin/work-breakdown-template.html, which contains instructions for filling in the information. The contents of this file will expand during the next several weeks as the individual work assignments for each team member are determined.

Per the specification document outline, the detailed tool reviews address the following points:

1. What is good about the related system, i.e., what features it has that should be included in the system your team is specifying.

2. What is bad about the related system, i.e., what features should not be included in your system, or what features should be included but done in a different or better way.

3. What is missing, i.e., what new features should be in your system that are not found in the related system.

The general format of the feature comparison matrix is in the attached handout. An example is in Section 1.6 of the Calendar Tool requirements.

Rough drafts for Section 1 are checked into the following files in the project requirements directory:

File	Document Section
intro.html	1.0 Introduction
problem.html	1.1 Problem Statement
personnel.html	1.2 System Personal
setting.html	1.3 Operational Setting
impacts.html	1.4 Impact Analysis
related.html	1.5 Related Systems
toolname-review.html	1.5.X Name of Tool Reviewed
features.html	1.5.7 Feature Comparison Matrix

where "toolname-review" is a suitably mnemonic file name for each of the 1.5.X subsections containing the individual tool reviews.

Format of the Feature Comparison Matrix

To help in the comparison of related tools in Milestones 1, you will construct a taxonomic feature comparison matrix, with the following general structure:

Features:	Tool 1	. . .	Tool N
Feature Category 1
Feature Category 1.1
Feature 1.1.1	yes/no/?		yes/no/?
. . .
Feature 1.1.m	yes/no/?		yes/no/?
Feature 1.2	yes/no/?		yes/no/?
. . .
Feature Category 2:
. . .
Feature Category n
. . .

Notes: (Optional foot notes, referenced from table entries.)

1. ...
2. ...
3. ...
. . .

The left column is the taxonomic feature list (more on taxonomy shortly). The top row lists each tool being compared. The entry for each tool feature is a "yes", "no", or "?". These entries indicate whether or not a particular tool has a particular feature. The "?" entry is used if it cannot be clearly determined from available information if the feature is present or not. Any entry may have a footnote reference for additional explanatory information. For example, suppose the feature is "color support" and the entry for a tool is "yes", but the tool provides color in a more limited fashion than other tools. In this case, the entry for the more limited tool can have a footnote that explains its limitations.

On Feature ``Taxonomy''

The study of taxonomy is pursued significantly in biological sciences, where the goal is to categorize the plant and animal life into a logical hierarchy. For example, biologists start with the largest category of kingdom, which has the two members of plants and animals. From there, the biological taxonomy goes to phyla, classes, orders, etc., down to the smallest category of sub-species.

In a software tool comparison, taxonomy can be used to organize the functionality of the tools. For example, we can consider the function categories found typically in the top-level menubar to be primary candidates for the top-level categories of functionality. Each item in a menu is a subcategory, and items in submenus or dialogs will be subsubcategories. It is likely that most tools will have at most four or five levels of command hierarchy, just by the nature of the user interfaces that modern GUI-based tools use.

Since software tools are not as well organized as the animal kingdom, we will have to look elsewhere than top-level menubars for feature categories. Indeed, some tools have no menubar at all. Overall, the focus of our categorization should be on functions that are accessible anywhere in the tool's user interface, whether through menus, buttons, or typing. We specifically do not care about features that are not directly accessible to the user.

Summary of Deliverables

• Customer question list, for 2nd-week Monday lab meeting.
• Checked-in group governance file.
• Checked-in work breakdown file (initial version).
• Checked-in files for Sections 1.0 through 1.5, and 1.5.X of the requirements document.
• Checked-in meeting notes -- see the meeting minutes template.
• Individual bi-weekly reports -- see the template, due Friday of week 2

Reading

• Syllabus
• Requirements specification document outline
• Lecture Notes weeks 1-2
• Chapters 1 and 2 of the textbook