Talk:Requirements management

From apppm
(Difference between revisions)
Jump to: navigation, search
(NobodyKnows Peer Review)
(NobodyKnows Peer Review)
Line 1: Line 1:
 
= NobodyKnows Peer Review=
 
= NobodyKnows Peer Review=
 +
I have gone through the wiki article and the review will be based from a chapter overview and finally an overall review.
  
== Formal Aspect ==
+
== Overview ==
* Is the article free of grammatical, spelling and punctuation errors?
+
* I like the starting definition, but it would be nice with a relevant reference - see below.
* Is the article written in an engaging style, e.g. short, precise sentences instead of long-winded, hard-to-follow mega-sentences?
+
** "According to The Office of Government Commerce in United Kingdom, requirements are “''capabilities and objectives to which any product or service must conform and are common to all development and other engineering activities” and requirements management is “the process of eliciting, documenting, organising, and tracking requirements and communicating this information across the various stakeholders and the project team''”."
* Are all main points illustrated with an appropriate figure?
+
* Are the figures clear and understandable?
+
* Are the figures free of formal errors (e.g. labeling of axes in diagrams)?
+
* Are the figures referenced in the text?
+
* Does the author have the copyright or right to use the figures (e.g. through Creative Common Non-Commercial Share Alike attribution?)
+
* Is the article formatted properly, i.e. are the typical Wiki-features such as sub-headings, proper bullet-point list, and Wiki-style references used? Are graphics, videos etc. integrated correctly?
+
== Content Aspect ==
+
* Is the article interesting for a practitioner?
+
* Does the article clearly relate to a project, program or portfolio management topic?
+
* Is it clear which one of the four “content categories” the article belongs to?
+
* Does the length of the article seem appropriate? Does it contain less relevant passages or excessive details? Does it miss critical details? (The suggested length is “on the order of 3500 words”. Articles can be longer or shorter if it makes sense to do so in order to deliver a quality argument.)
+
* Is there a logical flow throughout the article? Are the parts “tied together” through a red thread?
+
* Is the starting summary appropriate for the article?
+
* Does the article provide sufficient sources and reference material?
+
* Are sources and reference material of high quality? I.e., does the article mostly rely on books, journal articles, standards, and to some degree on high-quality websites, instead of “blog posts”?
+
* Does the article link to other relevant pages in the APPPM wiki?
+
* Is “own opinion” clearly differentiated from statements substantiated by literature?
+
* Does the article seem to be free of “copy & paste” plagiarism?
+
  
== Other Aspects that should/could be considered ==
+
* I would not use acronyms, when writing a "scientific wiki" article
 +
**A good requirements management is the key to projects success and better business results. A poor requirements management often lead to project failure [2] : delayed projects, budget overruns, or products that '''''[[don't]]''''' come out as designed.
 +
 
 +
* Requirements management can be handled by using different kinds of tools, which can either be manual processes or specialised tools.
 +
** [[Bliver dette berørt?]]
 +
 
 +
=== Overall impression of the ''Overview chapter'' ===
 +
* It is a real nice overview of Requirements Management and I want to keep reading!
 +
 
 +
== Definition of project success ==
 +
* Please add a reference for this. A strong statement needs a reference.
 +
** "The success of a project can be described in different ways, but the common criteria is the ability of a project manager to deliver a project in respecting time and budget constraints as well as respecting the customer's expectations. The system or product that have been promised must be the one to be delivered; this is only possible when all the requirements are fulfilled."
 +
 
 +
*
 +
 
 +
=== Overall impression of the ''Overview chapter'' ===
 +
* It would be very nice if a definition of "customers" regarding projects could be made and maybe a few examples.
 +
* Please consider if it is only the customers expectations that needs to be satisfied - yes - please state why.
 +
*
 +
 
 +
== Poor requirement management as a cause for project failure ==

Revision as of 17:12, 25 November 2014

Contents

NobodyKnows Peer Review

I have gone through the wiki article and the review will be based from a chapter overview and finally an overall review.

Overview

  • I like the starting definition, but it would be nice with a relevant reference - see below.
    • "According to The Office of Government Commerce in United Kingdom, requirements are “capabilities and objectives to which any product or service must conform and are common to all development and other engineering activities” and requirements management is “the process of eliciting, documenting, organising, and tracking requirements and communicating this information across the various stakeholders and the project team”."
  • I would not use acronyms, when writing a "scientific wiki" article
    • A good requirements management is the key to projects success and better business results. A poor requirements management often lead to project failure [2] : delayed projects, budget overruns, or products that don't come out as designed.
  • Requirements management can be handled by using different kinds of tools, which can either be manual processes or specialised tools.

Overall impression of the Overview chapter

  • It is a real nice overview of Requirements Management and I want to keep reading!

Definition of project success

  • Please add a reference for this. A strong statement needs a reference.
    • "The success of a project can be described in different ways, but the common criteria is the ability of a project manager to deliver a project in respecting time and budget constraints as well as respecting the customer's expectations. The system or product that have been promised must be the one to be delivered; this is only possible when all the requirements are fulfilled."

Overall impression of the Overview chapter

  • It would be very nice if a definition of "customers" regarding projects could be made and maybe a few examples.
  • Please consider if it is only the customers expectations that needs to be satisfied - yes - please state why.

Poor requirement management as a cause for project failure

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox