Faq

From a Business perspective (5)
What to look for in requirements

As a Business representative you can be asked to review Requirements. Probably you can review these on consistency.

Relation to the document

RR_HorizontalAfter your review

You must feel confident to announce that “These requirements fit into the current and future situation, are consistent with the business case and fully describe the wish.”

Review suggestions

  • The requirements do not interfere with other (existing or concept) requirements.
  • Dependencies are described.
  • Requirements that get outdated because of the new requirements are referred to.
  • The requirements are described on the correct level of detail.
  • The context, prerequisites and acceptance criteria are clear and correct.

Permalink.

What to look for in functional designs

As a Business representative you can be asked to review Functional designs. Probably you can review these on functional completeness and functional appropriateness.

Relation to the document

RR_1stSenderAfter your review

You must feel confident to announce that “This functional design is traceable to the requirements and functionally implements the chosen solution.”

Review suggestions

  • The design is traceable to the requirements.
  • The coverage is complete; the design implements the chosen solution.
  • The design is not overcomplete; it does not add (unwished) functionality.
  • The design does not restrict the technical implementation.

Permalink.

What to look for in technical designs

As a Business representative you can be asked to review Techical designs. Probably you can review these on context completeness. There is no need to fully understand or check the designs; you can globally check the design to get a feeling and to check if traceability to the requirements is still correct and complete.

Relation to the document

RR_2stSenderAfter your review

You must feel confident to announce that “This technical design implements (part of) the solution that was defined based on the (business)requirements.”

Review suggestions

  • The design is traceable to the requirements.
  • The design seems to implement the chosen solution.
  • Input- and output with other systems seem to contain the correct contents for correct and complete communication.

Permalink.

What to look for in test cases

As a Business representative you can be asked to review Test cases. Probably you can review these on functional completeness and coverage of identified risks.

Relation to the document

RR_1stReceipientAfter your review

You must feel confident to announce that “I am confident that these test cases at least cover the (changed) requirements and cover the identified risks.”

Review suggestions

  • The test cases are traceable to the requirements.
  • The test cases are traceable to the risk log.
  • The test cases are described in such a way that the purpose of each test case is clear.
  • At least the most probable scenario’s are covered.

Permalink.

How to approve or disapprove

All reviewers, regardless of their participation, receive an approval request when the rework is finished.

For general information check the Approval Phase.

Approved or disapproved

Approve the rework if you are confident that the comments are correctly reworked. You should be able to say from your own perspective that “I agree with the rework which is performed and I agree with the author’s reaction on the rejected comments.”

When you do not agree with the performed rework or with the reaction of the author, notify the moderator. When doing so, state clearly why you disapprove and what you expect to be done to get it approved.

Result of a disapproval can be a second rework round or a decision not to fix it. In all situations both the reviewer and author should feel OK with the decision.

I did not have comments, should I still (dis)approve the rework?

Yes, definitely. The document (which you already considered being “perfect”, since you did not have review comments) is reworked, so it might not be perfect anymore! So, even though you did not have comments, you still must approve or disapprove the rework.

Permalink.

View category→
From a Desigers perspective (6)
What to look for in test cases

As a designer you can be asked to review testcases. From your role you should be able to review the test cases for coverage, completeness and correctness. Look at the test cases on a same level as your design is made. The developers will look into the detailed step descriptions, other testers/test managers will look at the test technique, so stick to your role as much as possible.

Relation to the document

RR_2stSenderAfter your review

You must feel confident to announce that “These test cases are functionally correct and cover my design at least for the most important (risky) parts.”

Review suggestions

  • The test cases are presented in a structured way so I can easily check the coverage.
  • Only baselined documentation / correct versions are used to create these test cases.
  • Identified risks are covered.
  • There are also “rainy day” scenarios created to test unexpected or unwished scenario’s.
  • There are no useless or invalid test cases.

Permalink.

What to look for in requirements

As a designer you can be asked to review requirements. Probably you will need these requirements to create your designs, so it should be fit for that purpose. Maybe you are already known with the subject, so maybe you can also check if the requirements correctly fit in the current environment. Lastly, you need to understand the requirements without having to make any assumptions.

Relation to the document

RR_2ndReceipientAfter your review

You must feel confident to announce that “These requirements are complete, unambiguously clear to me and match to the current system(s).”

Review suggestions

  • The requirements are SMART (Specific, Measurable, Acceptable, Realistic, Time bound)*
  • The requirements are traceable (numbered/uniquely named)
  • The requirements are complete

 

 

* There are more definitions of SMART and more ideas about requirements, but the idea remains the same. See wikipedia

Permalink.

What to look for in architectural designs

As a Design representative you can be asked to review Architectural designs. Probably you can review these on understandability, ambiguity and completeness.

Relation to the document

RR_1stReceipientAfter your review

You must feel confident to announce that “The architecture is clear, complete and provides me support when creating my designs.”

Review suggestions

  • Standards and their reasons are clear.
  • Abbreviations, descriptions and context is clear.
  • The architecture provides support for this project and it´s design phase.
  • The architectural design is set up in a useful and recognisable way.

Permalink.

What to look for in functional designs

As a Design representative you can be asked to review Functional designs. Probably you can review these on consistency.

Relation to the document

RR_Horizontal

Permalink.

What to look for in technical designs

As a Design representative you can be asked to review Techical designs. Probably you can review these on completeness.

Relation to the document

RR_1stSender

Permalink.

How to approve or disapprove

All reviewers, regardless of their participation, receive an approval request when the rework is finished.

For general information check the Approval Phase.

Approved or disapproved

Approve the rework if you are confident that the comments are correctly reworked. You should be able to say from your own perspective that “I agree with the rework which is performed and I agree with the author’s reaction on the rejected comments.”

When you do not agree with the performed rework or with the reaction of the author, notify the moderator. When doing so, state clearly why you disapprove and what you expect to be done to get it approved.

Result of a disapproval can be a second rework round or a decision not to fix it. In all situations both the reviewer and author should feel OK with the decision.

I did not have comments, should I still (dis)approve the rework?

Yes, definitely. The document (which you already considered being “perfect”, since you did not have review comments) is reworked, so it might not be perfect anymore! So, even though you did not have comments, you still must approve or disapprove the rework.

Permalink.

View category→
From a Developers perspective (4)
What to look for in functional designs

As a Development representative you can be asked to review Functional designs. Probably you can review these on understandability and connectivity with current functionality.

Relation to the document

RR_2ndReceipientAfter your review

You must feel confident to announce that “I understand the functionality and I can use this design to perform my development activities without having to make any assumptions.”

Review suggestions

  • The design must be unambiguously clear. Look for
    • a description of the goal of the design;
    • vague words;
    • incomplete lists;
    • missing boundary values;
    • incomplete or incorrect definitions;
    • examples, charts, pictures;
    • consistency with existing functionality.
  • The design must be correct and complete, at least to your knowledge of the current system.
  • The design must contain enough details to perform your development activities.
  • The design must have a clear relation to technical documentation (if any).

Permalink.

What to look for in technical designs

As a Development representative you can be asked to review Techical designs. Probably you can review these on ‘buildability’.

Relation to the document

RR_1stReceipient

Permalink.

What to look for in test cases

As a Development representative you can be asked to review Test cases. From your role you can review these on technical coverage and correctness of the test steps.

Relation to the document

RR_1stSenderAfter your review

You must feel confident to announce that “These test cases cover the built functionality in the way it is intended for this test level and the test cases can be executed following the described prerequisites, test actions and checks.”

Review suggestions

  • The test cases are presented in such a way that I can easily check the technical coverage.
  • The described test actions can be executed in the way it’s described. Order, action, prerequisites and expected results are conform what’s built.
  • The test cases cover the built functionality as expected based on the test plan,  technical risks or technical scenario’s.

Permalink.

How to approve or disapprove

All reviewers, regardless of their participation, receive an approval request when the rework is finished.

For general information check the Approval Phase.

Approved or disapproved

Approve the rework if you are confident that the comments are correctly reworked. You should be able to say from your own perspective that “I agree with the rework which is performed and I agree with the author’s reaction on the rejected comments.”

When you do not agree with the performed rework or with the reaction of the author, notify the moderator. When doing so, state clearly why you disapprove and what you expect to be done to get it approved.

Result of a disapproval can be a second rework round or a decision not to fix it. In all situations both the reviewer and author should feel OK with the decision.

I did not have comments, should I still (dis)approve the rework?

Yes, definitely. The document (which you already considered being “perfect”, since you did not have review comments) is reworked, so it might not be perfect anymore! So, even though you did not have comments, you still must approve or disapprove the rework.

Permalink.

View category→
From a Maintenance perspective (5)
What to look for in requirements

As a Maintenance representative you can be asked to review Requirements. Probably you can review these on involvement of maintenance aspects.

Relation to the document

RR_1stReceipientAfter your review

You must feel confident to announce that “The requirements completely cover maintenance aspects with the correct priority and the nonfunctional requirements are realistic.”

Review suggestions

  • The requirements fit into the current environment/situation.
  • Requirements to perform (and prevent) maintenance are described.
  • Requirements are realistic to be fitted in the current system/environment.
  • Previous production incidents are prevented or described as risks including preventive and repressive measures.

Permalink.

What to look for in functional designs

As a Maintenance representative you can be asked to review Functional designs. Probably you can review these on understandability and maintainability.

Relation to the document

RR_2ndReceipientAfter your review

You must feel confident to announce that “This functional design is unambiguously clear, does not contain assumptions and takes into account that what is described can be maintained when it’s in production.”

Review suggestions

  • The design is completely clear, providing insight in impact, risks and tasks when this functionality gets implemented in production.
  • The main risks are prevented or covered by error handling.
  • Alternative handling is described (e.g. manual instead of automated) for the most risky parts.
  • Production issues which occurred in the past are prevented.

Permalink.

What to look for in technical designs

As a Maintenance representative you can be asked to review Technical designs. Probably you can review these on understandability and maintainability.

Relation to the document

RR_2ndReceipientAfter your review

You must feel confident to announce that “This technical design is unambiguously clear, does not contain assumptions and takes into account that what is described can be maintained when it’s in production.”

Review suggestions

  • Values should be designed to be parametrized/configurable instead of hard coded.
  • Error codes and messages must be unique and detailed enough.
  • Production issues which occurred in the past are prevented.

Permalink.

What to look for in test cases

As a Maintenance representative you can be asked to review Test cases. Probably you can review these on coverage of maintenance options and handling error situations.

Relation to the document

RR_1stReceipientAfter your review

You must feel confident to announce that “These test cases cover all maintenance needs in order for me to prevent or handle (functional) production problems when they occur. Risks based on previous experiences are covered by these test cases.”

Review suggestions

  • Previous production incidents related to the same scope or functionality are covered by the tests in order to check that it will not occur again or can be handled.
  • The test cases can be repeated by the maintenance team to test production fixes.
  • The coverage of (production) risks is clear and complete enough.

Permalink.

How to approve or disapprove

All reviewers, regardless of their participation, receive an approval request when the rework is finished.

For general information check the Approval Phase.

Approved or disapproved

Approve the rework if you are confident that the comments are correctly reworked. You should be able to say from your own perspective that “I agree with the rework which is performed and I agree with the author’s reaction on the rejected comments.”

When you do not agree with the performed rework or with the reaction of the author, notify the moderator. When doing so, state clearly why you disapprove and what you expect to be done to get it approved.

Result of a disapproval can be a second rework round or a decision not to fix it. In all situations both the reviewer and author should feel OK with the decision.

I did not have comments, should I still (dis)approve the rework?

Yes, definitely. The document (which you already considered being “perfect”, since you did not have review comments) is reworked, so it might not be perfect anymore! So, even though you did not have comments, you still must approve or disapprove the rework.

Permalink.

View category→
From a Management perspective (3)
What to look for in requirements

As a Management representative you can be asked to review Requirements. Probably you can review these on prioritization and risks.

Relation to the document

RR_2ndReceipient

Permalink.

What to look for in functional designs

As a Management representative you can be asked to review Functional designs. Probably you can review these on scoping and impact on teams.

Relation to the document

RR_1stReceipient

Permalink.

What to look for in test cases

As a Management representative you can be asked to review Test cases. Probably you can review these on conformance to the test strategy.

Relation to the document

RR_2ndReceipient

Permalink.

View category→
From a Moderator perspective (3)
What to do when a document is delivered late

If the review is already announced, a message needs to be send to the reviewers containing the new date and a request to reschedule the review activity. When the new delivery date is unknown, mention to the reviewers that the review is cancelled for now and a new announcement or review request will follow as soon as the new delivery date is known.

If the review is not announced yet, check if the delay is already known by the responsible manager(s). If so, update your review planning accordingly.

Permalink.

New comments during approval

In theory, new comments during the approval phase should only be related to reworked parts of the document. The formal review phase is passed so all comments should be noted in the review form.

However, during the approval phase you might run into the situation where new comments arise. There are different reasons for that and different actions to take. In all situations common sense of the moderator and willingness of the involved will determine what needs to happen.

Causes for new comments

  • Disapproval of rework
  • New insights and second thoughts
  • Changes in context
  • Review was done perfunctory or was done not at all

How to deal with this

Normally, all issues that need to be fixed before the next project phase is entered will help in saving time and money. The need is to be decided by the author and the reviewer, with some help of the moderator.

  • Majors need to be fixed.
  • Lot’s of minors: need to be fixed.
  • Typo’s don’t need to be fixed.

Depending on the amount of fixes, the approval phase needs to be redone or the updated document needs to be spread “for your information” to all reviewers. A good moment for this last action is during the finalization of the process. (Together with the review report)

Next to the question about fixing or not, the moderator has an action to take to discourage this behavior in the future. All comments (except for disapprovals of rework) in the approval phase cause the review process to become inefficient. Since the review process is owned by the moderator, the moderator is responsible for keeping it as efficient as possible.
Inform the reviewers about the extra work they cause by providing comments in the approval phase. Let them know you’ll try to get everything reworked, but also that the new rework will cause extra work for all other reviewer to re-check.

Permalink.

Late comments

Sometimes announced, sometimes not announced: comments can get delivered áfter the review deadline. The moderator has to deal with this, depending on the situation but always with a doses of common sense.

If announced

When a reviewer announces not to be able to make the review deadline, this must be encouraged. Open communication is a good thing and it opens possibilities to search for a solution. Some possibilities are:

  • Stretch the deadline for all reviewers
  • Stretch the deadline for the single reviewer, and wait for his comments before merging. Inform the author of a delay in delivery of comments.
  • Stretch the deadline for the single reviewer, but don’t wait for this comments. Inform the author of a delay in delivery of comments from this specific reviewer.
  • Try to get a colleague or second reviewer to take over the review activities.
  • See if the reviewer’s priorities can be rescheduled.
  • Accept the risk of not having the comments from this reviewer (especially if this was an optional reviewer). This must be done together with the QA-manager.

If not announced

This must be discouraged. The moderator has already requested and reminded the reviewer to be in time or to inform the moderator if the deadlines can not be made. Comments that are too late must be checked for impact and the moderator, together with the QA-manager and author, must decide what to do with it. Some possibilities are:

  • Accept the late delivery and send an update of the merged review form to the author.
  • Accept part of the comments
  • Reject all comments

If Majors still can be fixed before the next project phase commences, it might still be worth it to let it be fixed since it will save time or money.

The moderator needs to protect the review process. So, the reviewer must be made clear this behavior is not accepted and good alternatives are available. (Namely: the reviewer is asked to mention it in time if the deadline can not be met.)

Permalink.

View category→
From a Reviewers perspective (3)
Comment or question

Did you read I am a reviewer?

Comments belong in a review form, questions do not.

Comments will lead to rework of the document, improving the quality of the document. A comment is about fixing defects, preventing defects (for instance by asking for clarification) and making the document fit for purpose.  If a comment gets rejected, the author can provide a valid reason for that.

A comment is a statement with a few purposes. A comment

  • is clear about what the reviewer wants;
  • helps, or directs, the author in reworking the document based on the comment;
  • is complete in terms of what is found, what is expected and what is wrong/unclear;
  • is (also) complete in terms of spelling, grammar and interpunction;
  • is written as a statement and is prioritized;
  • shows respect to the author, is aimed at the document and is objective and factual.

Questions tend to be answered in the review form, causing the knowledge to fade since a review form is not part of the project’s documentation.

A question is something a reviewer might have when performing a review. A question can arise because of

  • missing information;
  • a gap in the reviewers’ knowledge.

In the first case: note down a comment in the form  of a statement that more information is required. In the second case: ask a colleague to clarify or ask yourself if you are correctly selected as a reviewer for this (part of the) document.

Permalink.

How do I find Majors?

First, read Find your Majors.

Second, ask your more experienced colleagues about their strategy, way of working, checks and methods.

Third, browse the internet and read some books:
How to write a peer review
Perspective based reading
A Structured Approach for Reviewing Architecture Documentation
Object-Oriented Reading Techniques for inspection of UML Models

Permalink.

How do I determine what to review for?

Reviewing without a specific goal can be OK, but it can also lead to unnecessary long reviews, less important comments or missing issues. To get focus, contact your moderator to get things to explicitly look for. Maybe your moderator already provided you some suggestions.

Read Risk based reviewing and Implement lessons learned to understand how to get focus in your reviews.

Permalink.

View category→
From a Testers perspective (6)
What to look for in functional designs

As a tester you can be asked to review a design. Probably you will need this design to create your test cases, so it should be fit for that purpose. Maybe you are already known with the subject, so maybe you can also check if the design correctly fits in the current environment. Lastly, you need to understand the design without having to make any assumptions.

Relation to the document

RR_1stReceipientAfter your review

You must feel confident to announce that “I can use this design to create my test cases without having to make any assumptions”

Review suggestions

  • The design must be unambiguously clear. Look for
    • a description of the goal of the design;
    • vague words;
    • incomplete lists;
    • missing boundary values;
    • incomplete or incorrect definitions;
    • examples, charts, pictures;
    • consistency with other designs.
  • The design must be correct and complete, at least to your knowledge of the current system.
  • The design must contain enough details to create your (logical) test cases.
    • all IF…ELSE constructions must be complete;
    • all functional paths should lead somewhere;
    • alternatives must be described
  • The design must be traceable to requirements

Permalink.

What to look for in test cases

As a tester you can be asked to review test cases. Except for a peer-review situation, most likely these test cases will be created for an other test level then yours. For example you might receive Integration Test test cases if you’re a System Tester.

Be sure to stick to your role; coverage and correctness will primarily be reviewed by a designer!

Relation to the document

RR_HorizontalAfter your review

You must feel confident to announce that “These test cases complement my test cases and do not overlap or leave a gap with my test cases.”

Review suggestions

  • It is clear to me how these test cases where created. (Test technique)
  • The test cases do belong to the test level they are created for.
  • The test plan is followed.
  • Input, output, interfaces and screens are tested on the correct way for the test level at hand.
  • The test cases complement my test cases.
  • The way the test cases are described makes them transmissible to an other tester for execution.
  • Execution steps contain an actor and an action. (e.g. “The user presses the red button.“)
  • Expected results describe a verifiable result. (e.g. “The output file on location A contains parameter ABC with value XYZ.“)

Permalink.

What to look for in implementation plans

As a tester you can be asked to review implementation plans. Your main task will be to check if any issues found during the testing phase affect the implementation.

Relation to the document

RR_1stSenderAfter your review

You must feel confident to announce that “The issues found during the testing phase which could influence the implementation are taken care of.”

Review suggestions

  • Open test defects/findings are related to a risks mentioned in the implementation plan.
  • Issues encountered during implementation on a test environment are covered in the implementation plan.
  • The (functional/technical) scope of the implementation is consistent with your test scope.

Permalink.

What to look for in technical designs

As a Test representative you can be asked to review Techical designs. Probably you can review these on testability, functional correctness and technical correctness.

Relation to the document

RR_1stReceipient

Permalink.

What to look for in requirements

As a Test representative you can be asked to review requirements. Probably you can review these on testability, but also you are thé quality minded reviewer, so look for ambiguities, SMART requirements and missing requirement types.

Relation to the document

RR_1stReceipientAfter your review

You must feel confident to announce that “These requirements are complete, SMART, unambiguous and I can define my (risk based) test strategy on it.

Review suggestions

  • All requirements (functional and non-functional) are described.
  • (Non-)Functional requirements are traceable to business requirements.
  • Each requirement is specific (what/why/who/where/which? etc.)
  • Each requirement is measurable (how much/how many/how is determined if the requirement is met?)
  • Each requirement is attainable and realistic (how can it be accomplished?)
  • Each requirement is relevant (MoSCoW; right time/right efforts/correct stakeholders involved?)
  • The requirement are time-bound (when is it needed/what sequentiality applies? etc.)
  • Each requirement has a relation with a stake holder.
  • There are no ambiguities in the requirements.
  • Requirements are traceable and are uniquely numbered/marked.

Permalink.

How to approve or disapprove

All reviewers, regardless of their participation, receive an approval request when the rework is finished.

For general information check the Approval Phase.

Approved or disapproved

Approve the rework if you are confident that the comments are correctly reworked. You should be able to say from your own perspective that “I agree with the rework which is performed and I agree with the author’s reaction on the rejected comments.”

When you do not agree with the performed rework or with the reaction of the author, notify the moderator. When doing so, state clearly why you disapprove and what you expect to be done to get it approved.

Result of a disapproval can be a second rework round or a decision not to fix it. In all situations both the reviewer and author should feel OK with the decision.

I did not have comments, should I still (dis)approve the rework?

Yes, definitely. The document (which you already considered being “perfect”, since you did not have review comments) is reworked, so it might not be perfect anymore! So, even though you did not have comments, you still must approve or disapprove the rework.

Permalink.

View category→
From an Architecture perspective (4)
What to look for in requirements

As an Architecture representative you can be asked to review Requirements. Probably you can review these on effectiveness.

Relation to the document

RR_1stReceipient

Permalink.

What to look for in architectural designs

As an Architecture representative you can be asked to review Architectural designs. Probably you can review these on consistency with existing architecture.

Relation to the document

RR_Horizontal

Permalink.

What to look for in functional designs

As an Architecture representative you can be asked to review Functional designs. Probably you can review these on functional suitability and compliancy with the architecture.

Relation to the document

RR_1stSender

Permalink.

How to approve or disapprove

All reviewers, regardless of their participation, receive an approval request when the rework is finished.

For general information check the Approval Phase.

Approved or disapproved

Approve the rework if you are confident that the comments are correctly reworked. You should be able to say from your own perspective that “I agree with the rework which is performed and I agree with the author’s reaction on the rejected comments.”

When you do not agree with the performed rework or with the reaction of the author, notify the moderator. When doing so, state clearly why you disapprove and what you expect to be done to get it approved.

Result of a disapproval can be a second rework round or a decision not to fix it. In all situations both the reviewer and author should feel OK with the decision.

I did not have comments, should I still (dis)approve the rework?

Yes, definitely. The document (which you already considered being “perfect”, since you did not have review comments) is reworked, so it might not be perfect anymore! So, even though you did not have comments, you still must approve or disapprove the rework.

Permalink.

View category→
From an Authors perspective (4)
When is my document ready for review?

There are two guidelines to consider. The first are the (project) agreements that are made. For example: version number is correct, the document is saved on a specific location, the template is used and the document is written in the the agreed language.

The second guidelines to consider are more of the ‘social’ kind. For example: the glossary is updated, the text written for the correct audience, unused template chapters are explicitly marked as such, changes are marked with a color in case of an updated document etc.

You must feel confident that the document is, within the agreed boundaries, 100% fit for review. After all, the review is meant to fix defects, not to let the reviewers finish your document!

Permalink.

What can I do when I can not finish my document?

If within the project it’s decided that unfinished documents still must be reviewed “as is”, then the author must clearly mark the spots of which the author is aware that information is missing.

Use “not applicable”, “not available”, “to be filled on <date>” or “to be decided by <name>”. This is more clear to the reader than “N/A” (what does this abbreviation mean?) or “intentionally left empty” (unclear to the reader what this intention might be).

Permalink.

I do not agree with the Importance of a comment

The importance of a comment should not have any impact in the rework that is done. Starting point is that all comments will be handled seriously and rework will be done in case the comment is accepted.

If  the author does not agree with the Importance marked by the reviewer, it’s suggested that the author contacts the reviewer to discuss this. There can be various reasons for this difference in insight. One of these can be that the author does not fully understand the value the document has for the reviewer. This is a good moment to straighten that out!

In all cases: do not argue too much about the importance. It’s the product quality that counts!

Permalink.

Accept or reject comments

In the rework phase the author updates the document based on the provided review comments. A comment can be accepted, rejected or open. The first two states are end states, the status open can be used to mark comments that need discussion. After the discussion the status must be changes to accepted or rejected.

Open

If a comment is not clear, if it needs discussion or if it can not be reworked at the moment (e.g. because of missing information), this temporary status can be used. If the review is finished with issues on status open, this issue must be logged on a to do-list (or equivalent) to be tracked. In case of unclearity, contact the reviewer who noted the comment. Initials and name are mentioned in the review form.

Accepted

If a comment leads to rework, the status accepted is the correct one. Note in the remarks, in short, what has been changed. Just “Updated” or “Reworked” is not clear enough. Respect your reviewers and make whole sentences, eg. “Added paragraph 5.1.3”.

Rejected

A comment can be rejected if the comment did not lead to rework. The author must clearly note the reason for the rejection. Just “I disagree” is not clear enough. Respect your reviewers and make whole sentences, eg. “See [ref1], paragraph 13.4 for the current settings.”

Permalink.

View category→
From an Implementation perspective (4)
What to look for in requirements

As a Implementation representative you can be asked to review Requirements. Probably you can review these on (non-functional) requirements related to implementation.

Relation to the document

RR_1stReceipient

Permalink.

What to look for in functional designs

As a Implementation representative you can be asked to review Functional designs. Probably you can review these on implementation impact.

Relation to the document

RR_2ndReceipient

Permalink.

What to look for in test cases

As a Implementation representative you can be asked to review Test cases. Probably you can review these on coverage of implementation risks.

Relation to the document

RR_2ndReceipient

Permalink.

How to approve or disapprove

All reviewers, regardless of their participation, receive an approval request when the rework is finished.

For general information check the Approval Phase.

Approved or disapproved

Approve the rework if you are confident that the comments are correctly reworked. You should be able to say from your own perspective that “I agree with the rework which is performed and I agree with the author’s reaction on the rejected comments.”

When you do not agree with the performed rework or with the reaction of the author, notify the moderator. When doing so, state clearly why you disapprove and what you expect to be done to get it approved.

Result of a disapproval can be a second rework round or a decision not to fix it. In all situations both the reviewer and author should feel OK with the decision.

I did not have comments, should I still (dis)approve the rework?

Yes, definitely. The document (which you already considered being “perfect”, since you did not have review comments) is reworked, so it might not be perfect anymore! So, even though you did not have comments, you still must approve or disapprove the rework.

Permalink.

View category→