![]() |
![]() |
![]() |
A fact sheet has the characteristics described in the following paragraphs.
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 ProjectThis field shows to which project the sheet belongs to. The list of projects is configurable during the setup.
Sub-Project 5.3Several 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 PhaseA 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 DateThis date is set automatically at the moment of creation of the sheet.
5.6 SubmitterIt's the name of the user who created the fact sheet.
5.7 SeverityIt's an integer value going from 1 to 4, showing the severity of the problem. The meaning of the values is the following :
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.
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 VersionIndicates 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 TitleDescribes the problem in one line.
5.11 DeadlineThis 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 StatusA fact sheet can have the following statuses :
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 :
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 ResponsibleIt'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 CorrectorIt's the username of the person who has done the correction.
5.16 correction DateDate when the correction has been done.
This date is set automatically when the sheet is passed to the C state.
Corrected Version 5.17This is the version of the product in which the correction should be delivered.
5.18 VerifierUsername of the person having verified the correction.
5.19 Verification DateDate when the verification has been done.
This date is set automatically when the sheet is passed to the V state.
5.20 Verified VersionVersion of the product in which the verification has been done.
5.21 Test ScenarioThis 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 TypeThis field says if the sheet describes a bug or an evolution compared to the specifications.
5.23 ImpactThis 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 EstimateThis field gives a rough idea on the workload needed to solve the problem.
5.25 Time spentWhen 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 / ADPThis 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 HistoryIt'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 AttachmentsIt'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.
The possibility to attach a file to a fact sheet is planned for a future version of GIFFT.
![]() |
![]() |
![]() |