The purpose of this review is to verify that all the requirements of the system have
been listed and correctly described. It shall also be verified that the listed requirements
are valids.
Other review goals include:
- english mistake
- understanding
- adequacy to user needs
- coherence
- precision
- feasability
As there is no designed peers for this review, anybody that whish to contribute to the
project shall fill the Defects list according to the concepts listed in the Notes
section of this document, and submit the modified document to the review moderator before
the Review submission date.
|
- Concepts definition
| Defect |
A defect in a system (or component) is a factor preventing the system (or component) from fullfilling
its desired function. When a defect becomes active, errors may ensue, in turn causing a system failure.
|
| Defect severity |
The severity of a defect is used to decide on the course of action to be taken when a defect is encoutered:
| Spotted |
Defect non-recorded which is communicated to the author informaly (eg. spelling mistakes)
|
| Minor |
Defect recorded but the correction of which is left to the author's discretion
|
| Major |
Defect recorded which must be imperatively corrected
|
| Critical |
Defect recorded which must be imperatively corrected. The effect of the correction being
considered important enough to justify a new review, following correction.
|
|
| Defect type |
To help the corrective action process, any defect found during the peer review, shall be
categorized using the following types:
| Label | Type | Description |
|---|
| CSH |
Crash |
System's component stop functionning in specific (or unknown) conditions.
Examples :
- Application XYZ crash upon user action W.
|
| BHV |
Behavior |
System's component doesn't behave the way it should.
Examples :
- Emailer print email instead of emaling it.
|
| CHG |
Change |
System or system's component shall integrate a given change.
Examples :
- Allow the user to do X with Y, when W running.
|
| PRF |
Performance |
Performance requirements (CPU load, occupation memory, time of processing) no satisfied. The description is correct but ineffective.
Examples :
- The system's perfomance is damaged by this specific requirement,
- Performance criteria are not specified,
- Code not optimized,
- The set of tests does not allow users to measure performance, etc.
|
| ITF |
Interface |
Interface errors when an element is combined with other components: incomplete interface description, communication problem (protocol, arguments, calling parameters, etc.).
Examples :
- Incorrect calling protocol,
- Incorrect arguments of interface,
- Initialization of hardware component,
- Initialization and dialogue between processor.
|
| RMA |
Maintenance and Re-use |
The element is difficult to maintain or re-use; it is too complicated or sophisticated
Examples :
- Cannot transfer code (whithout comments),
- Missing,unclear or irrelevant comments within the code,
- Illegible code,
- The origin of the error cannot be identified by the error messag.
|
| STD |
Standard |
Non compliance with standards, procedures and guides of the baseline. Non compliance with the methods and tools defined for the unit and for the business baseline.
Examples:
- Non compliance with the model plan,
- Non compliance with the coding rules (variables and functions names', etc.),
- Non compliance with standard,
- Non compliance with the software baseline guidelines.
|
| FCT |
Functional / upper requirements |
Problem of the element regarding to the amont requirements, such as tracking, coherence, compliance, monitoring.
Examples :
- Incomplete tracking matrix ,
- The code does not cover all the assigned requirements,
- The design does not describe all the assigned requirements,
- Unexpecteed method of functionning,
- requirement not taken into account.
|
| DOC |
Documentation / Understanding |
DOC - Documentation / Understanding
The content of the document does not allow a complete understanding. It is written in an ambiguous or incorrect way.
Examples :
- Incorrect reference to a document,
- The descriptions are irrelevant, inadequate, insufficient,
- The detailed design (in a document or in a code itself) does not clearly describe the arguments or the feature of every coded function,
- The purpose of each test is not clearly defined, etc.
|
| TEC |
Technique / Algorithms |
The technical content is incorrect and ambiguous: errors in the calculation of algorithms, incorrect sequencing, etc.
Examples :
- Digital instability
- No deallocation of the memory
- Incorrect model
- Error not modified
- Risk of division by zero
- Mismanaged interruption
- Overflow
- Useless or redundant code.
|
| DON |
Data / Programming language |
Data errors are: structure, size, initialization. Programming errors concerning: operators, functions and procedures, typing errors,etc.
Examples :
- Variables, pointers not initialized,
- Confusion between assignment and comparison,
- Size of a table, a buffer,
- Scope of a local variable,
- Typing errors,
- Confusion between names of two variables, etc.
|
|
- What is a peer review ?
Peer reviews (PR) are reviews carried out during the development process to detect and correct defects
as early as possible. They are based on a comparison of the standpoints of several experts, guided by
a checklist procedure, and contribute to reduicing lead time and risks. They also improve the project
quality by ensuring better control over the development.
They are also an excellent mean of communication and learning.
- PR roles
During a PR, there is 3 differents type of players:
| Author |
The author is the designed or the manager of the document/code beeing examined.
|
| Moderator |
The moderator is an important player in the implementation of the review of which
he is the coordinator. He must be capable of evaluating the impact of a defect. He
can be a peer also. His tasks are:
- motivation and control of the participants
- meeting management
- control of the review effectivieness
- drafting the PR Kit and review report documents
|
| Peers |
Peers are responsible for carrying out the review according to their technical background and
to the review goals.
|
|