Skip to main content

Ways of Writing Reviews for a Research Paper

Peer review of a given research paper highlights its strength and its weaknesses in terms of the quality of the research paper written. The ways of writing reviews for a research paper discussed in this blog are among the most common methods adopted for peer reviews. When writing a review for any given research paper following are the questions to be answered:
  1. How sound is the research design?
  2. What do we now know that we did not know before?
  3. What can we do now that we could not do before?
  4. Are the reported conclusions generalized?
  5. What is the most questionable issue of the paper?
  6. Why is the experience not very representative?
  7. How sound is the solution?
  8. What is the next step to take?
  9. Whose goals are served or helped by this?
  10. Why wouldn't I use the same approach?
Another method adopted for writing a review of a given research paper is rather simple and requires less effort. This method contains the following sections to be answered:
  1. Summary: This section summarizes the contents discussed in the paper under peer review.
  2. Major Comments: This section discusses the most significant observations made in the context and content of the paper under peer review.
    • Positive Comments i.e. points in favor of the paper.
    • Negative Comments i.e. point not in favor of the paper.
  3. Minor Comments: This section discusses the least significant observations made in the context and content of the paper under peer review.
    • Positive Comments i.e. points in favor of the paper.
    • Negative Comments i.e. point not in favor of the paper.
  4. Suggestions: This section of the paper should suggest the writer of the paper under peer review with ways to further improve the quality of the paper. The section can include suggestions related to the paper itself and to the context of the paper under peer review.

Comments

Popular posts from this blog

Quality Practices in Agile Approaches

Agile Approaches Agile is an umbrella consisting of different methods adopted by the practitioners depending upon the circumstances. In the recent years  Agile has been gaining popularity among software practitioners due to its ability in assisting the development team to deliver the software product in a short amount of time.  Original Agile Approaches Based on the circumstances under which the agile methodologies have been used can be classified into the following 3 categories: Classification of Agile Approaches Agile Methodologies consist of the  original agile methods Hybrid Agile Methodologies consist of a combination of several original agile methodologies e.g. Industrial Extreme Programming merged with practices of Rational Unified Process Miscellaneous category consists of methodologies adopting only certain aspects of the original agile methodologies Extreme Programming, Test Driven/Test First Development, and SCRUM are among the most popular agile met

How traceability of non-functional requirements is managed throughout the software development process?

1. Requirements Traceability: Requirements traceability is the process of describing and keeping track of a set of requirements throughout the system’s lifecycle. The process assists in managing changing requirements of a particular software product. Requirements traceability of is two types, forward traceability where a particular requirement involved during the design and implementation phases of the software system, and backward requirement traceability where a particular requirement is being traced back to its source. 2. Proposed Solutions for the Traceability of Non - Functional Requirements : The author J. Merilinna [8], proposed a framework supported by a tool to trace the non-functional requirements in both forward and backward direction. The proposed method is based on the context of DSM (Domain Specific Modeling).  The NFR+1 framework involved are used for the elicitation, definition and redefinition of the system’s non-functional requirements. The proposed

Software Architecture Views and Structures

Description of Views: In the year 1995 Kruchten presented his 4+1 architectural view model consisting of the following five types of views: Logical Development Process Physical Scenario Later with further development and research in the domain of architectural view following new views were developed to represent their respective structures: Views Sub-View of Description Logical None Highlights the functionalities provided by the system to the end-users. Unified Modeling Language (UML) diagrams such as the Class diagram, Domain diagram, Use Case diagram, State diagrams and Activity diagrams can be used to represent the logical view of the architecture. Development None It is also known as an implementation view. It is mainly concerned with the software project management. It represents the system with the programmer’s perspective. Process None It deals with the representation of