A fact sheet has the characteristics described in the following paragraphs.

5.1 Number

The number identifies in a unique way each fact sheet and has the following format:

[<project prefix>.]P<subproject prefix>.NNNNN

where

project prefix is an optional field for backward compatibility reasons. Indeed GIFFT version one did not have this part. Fact sheets are always referenced by their number so it is advised to keep the prefix short, two or three characters maximum. This prefix is configurable (see setup) but it should not be changed once there are sheets existing with prefix. If the header of the project is edited and the project name is changed, the name of the sheet will change as well.

P is the phase prefix (see phase). I has one character only, and is fully configurable (see setup). If the header of the project is edited and the phase is changed, the name of the sheet will change as well.

subproject prefix this field shows to which subproject the sheet belongs to. Fact sheets are always referenced by their number so it is advised to keep the prefix short, two or three characters maximum. This prefix is configurable (see setup) but it should not be changed once there are sheets existing with prefix. If the header of the project is edited and the subproject is changed, the name of the sheet will change as well.

NNNNN is a five digit sequence number automatically incremented at each new fact sheet.

5.2 Project

This field shows to which project the sheet belongs to. The list of projects is configurable during the setup.

Sub-Project 5.3

Several different groups can be working on a given project. Often a project is divided into smaller parts which people like to call "phases". Since in this document a phase is a different concept, we would rather use the term of subproject.

A subproject can be a small project with a specification, a development and a delivery, but not necessarily. In fact, it can be any part of a given project.

The list of subprojects is different for each project, and is configurable in the setup.

5.4 Phase

A phase is any part of the V life-cycle of a project: specification, development, validation, and so on.

This variable indicate the phase of the project the fact sheet relates to.

The list of phases being a standard quality concept, all projects have access to the same list of configurable phases.

5.5 Creation Date

This date is set automatically at the moment of creation of the sheet.

5.6 Submitter

It's the name of the user who created the fact sheet.

5.7 Severity

It's an integer value going from 1 to 4, showing the severity of the problem. The meaning of the values is the following :

1. Critical
2. Major
3. Minor
4. Documentation.

The exact meaning of each value is inherent to each project but it's important to see the difference between severity and urgency. Some quality systems have tried many more levels of severity but experience shows that clients have a tendency to put everything as critical which is equivalent to the highest priority of urgency.

5.8 Module

This field indicates the part of the deliverable which is impacted by the problem. Usually it is part of a software delivery, so this field indicates the executable in which the problem was found, but this is not necessarily a limitation.

The list of modules is specific to each project, and is configurable as such in the setup.

5.9 Version

Indicates the version of the product in which the problem has been detected. A version is usually a character string of the form 1.1, 2.1.3, etc, but not necessarily.

When a fact sheet is created, this field is filled with the version of the product at that moment.

The list of versions is specific to each project, and is configurable as such in the setup.

For easier use, one could set up an automatic mechanism to update the appropriate configuration file each time a delivery is made, but such a tool is not part of this software.

5.10 Title

Describes the problem in one line.

5.11 Deadline

This field indicates the version of the product in which the problem should be solved. Of course it is just a wish which is a target for developers. It is understandable if some too optimistic deadlines can not always be met.

In general, this field contains the next version do be delivered at the time of the detection of the problem.

The list of versions is specific to each project, and is configurable as such in the setup. The manager should not forget to update regularly the appropriate configuration file, as more and more future versions are planned.

5.12 Status

A fact sheet can have the following statuses :

• N : new
• OB : being observed (not new but not enough information yet)
• A : being analyzed

• O : open (analysis done, ready to be corrected)

• C : corrected
• V : verified
• NB : not a bug
• D : duplicate (an other sheet is dealing with the same issue)
• NR : not reproducible
• P : postponed to a later date
• AB: abandoned

The fact sheets in the NB, NR, D, AB and P are considered abandoned (temporarily in the case of P).

Reminder : The state changes are done the following way :

• A fact sheet is automatically in the state N at creation
• The manager passes the sheets to the A state by assigning them to the people who should analyze the problem. A fact sheet can be assigned as many times as needed.
• After the analysis is done, the manager gives the green light for correction by passing it to the O state , or he classifies the sheet in one of the abandoned categories NB, NR, D, AB and P.
• The person doing the correction passes the sheet from O to the C state.
• The submitter of the sheet verifies the corrections and passes it to the V state of N if the problem still exists.

5.13 Postpone Date

This is the date to which the handling of the fact sheet has been postponed. Once this date is reached, the state of the sheet changes back to N, and the manager is notified.

5.14 Responsible

It's the username of the person the sheet has been assigned to. It's not necessarily the name of the submitter but of the person who has to analyze the problem or correct it.

5.15 Corrector

It's the username of the person who has done the correction.

5.16 correction Date

Date when the correction has been done.

This date is set automatically when the sheet is passed to the C state.

Corrected Version 5.17

This is the version of the product in which the correction should be delivered.

5.18 Verifier

Username of the person having verified the correction.

5.19 Verification Date

Date when the verification has been done.

This date is set automatically when the sheet is passed to the V state.

5.20 Verified Version

Version of the product in which the verification has been done.

5.21 Test Scenario

This field represents the reference number of the test scenario that has been used to detect the problem. This same scenario should allow to verify the correction once it has been done.

5.22 Sheet Type

This field says if the sheet describes a bug or an evolution compared to the specifications.

5.23 Impact

This field tells the potential impact of the problem. A list of possible impacts could be for example: functional, usability, performance, robustness …

The list of possible impacts is configurable in the setup. Although the list of impacts is specific to each project, this list is shared by all projects in case someone in one of the teams comes up with a good idea, it will be automatically available for the other projects.

5.24 Workload Estimate

This field gives a rough idea on the workload needed to solve the problem.

5.25 Time spent

When the person having done the correction sets the sheet into the C state, he also has the opportunity to say the exact number of days spent on the problem.

The tool suggests a pessimistic value which is the number of working days between the creation of the sheet, and the moment of resolution. The corrector has spent probably less time than that.

5.26 ADC / ADP

This is a reference field for Applicable Document Changes and Precisions.

This field is very important for tracking the reasons of modifications, for example to know what changes are implemented in the version that has been delivered.

5.27 History

It's a history of all events concerning the fact sheet. Every time the sheet changes it's state, a new paragraph is added or edited, or any field is modified, a new line is added to the history.

A global history file is also placed in the data directory to help the monitoring of every event on all the fact sheets at the same time. (see statistics)

5.28 Attachments

It's a short text attached to the fact sheet. The first attachment is always the description of the problem and the way to reproduce it. The following attachments can be comments, analyses, or description of corrections. The sheet ends with the description of the verifications done or the reasons for abandoning the sheet.

Each attachment has a title, a date, an author and a content. The title is a word showing the nature of the attachment.

The date is set automatically, as well as the username of the person writing the text.