Talk:Requirements management

From apppm
(Difference between revisions)
Jump to: navigation, search
(→‎NobodyKnows)
(→‎NobodyKnows Peer Review)
 
(42 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
== NobodyKnows Peer Review==
+
'''My answer to the reviews is written in bold'''
  
−
* Is the article free of grammatical, spelling and punctuation errors?
+
= NobodyKnows Peer Review=
−
* Is the article written in an engaging style, e.g. short, precise sentences instead of long-winded, hard-to-follow mega-sentences?
+
I have gone through the wiki article and the review will be based from a chapter overview and finally an overall review. There are only comments if a section is shown below.
−
* 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?
+
== Overview ==
−
* Does the author have the copyright or right to use the figures (e.g. through Creative Common Non-Commercial Share Alike attribution?)
+
* I like the starting definition, but it would be nice with a relevant reference - see below.
−
* 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?
+
** "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''”."
−
* Is the article interesting for a practitioner?
+
*** '''I thought that writing where the quote came from was sufficient, but I have now updated the source
−
* 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?
+
* I would not use acronyms, when writing a "scientific wiki" article
−
* 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.)
+
** 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.
−
* Is there a logical flow throughout the article? Are the parts “tied together” through a red thread?
+
*** '''You are right, it was a inattention mistake that I now have corrected.'''
−
* Is the starting summary appropriate for the article?
+
 
−
* Does the article provide sufficient sources and reference material?
+
*  You state that "Requirements management can be handled by using different kinds of tools, which can either be manual processes or specialised tools."
−
* 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”?
+
** This is not really mentioned in depth throughout the article, but sound very interesting.
−
* Does the article link to other relevant pages in the APPPM wiki?
+
*** '''Some companies use only tools like excel or word (basically lists) but for complex projects it seems that there are kinds of software for managing requirements. I did not see the point in explaining them in the article because there are a lot (there is not only ''one'' good way to manage requirements) and they are produced by private companies.'''
−
* Is “own opinion” clearly differentiated from statements substantiated by literature?
+
 
−
* Does the article seem to be free of “copy & paste” plagiarism?
+
=== Overall impression of the ''Overview chapter'' ===
 +
* It is a real nice overview of Requirements Management and I want to keep reading!
 +
** '''Thank you!'''
 +
 
 +
== 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."
 +
*** '''Actually, this is my own point of view on how to define the success of a project. Of course, I was also helped by the readings I have done, but I cannot add one reference for this statement...'''
 +
 
 +
=== Overall impression of the ''project success'' ===
 +
* It would be very nice if a definition of "customers" regarding projects could be made and maybe a few examples.
 +
** '''I think it was obvious but it seems that it is not, so I added explanation.'''
 +
* Please consider if it is only the customers expectations that needs to be satisfied - if yes - please state why?
 +
** '''I do not understand what you mean here? I detailed 4 criteria to define project success, customer's satisfaction is one of them but there are still 3 other, but they are detailed. I meant here that the customers' requirements are one main aspect to consider in a project in order for it to be successful.'''
 +
 
 +
== Application context ==
 +
* An idea would be to make a reference to a wiki article regarding "System Engineering"
 +
** '''This is true, a link to the article comparing systems engineering and project management is absolutely justified here and can be a good complement to my article. So I have now added the link!'''
 +
 
 +
== System engineering processes ==
 +
* It feels like the section just ends, without a "wrap-up".
 +
 
 +
== Product development projects ==
 +
* Please assign reference
 +
** Product development projects are becoming more and more complex, especially because of the increasing variety of demands from customers
 +
 
 +
* Please assign reference
 +
** A way to keep track of the customer’s requirements in new product development is Quality Function Development, which is a tool used for defining the characteristics of a product as targets to be achieved for the engineering characteristics of the product in a way that customer’s requirements are satisfied.
 +
 
 +
* Good informative chapter!
 +
** '''I have now added references'''
 +
 
 +
== Construction projects ==
 +
* A reference is needed for this.
 +
** Because construction projects are usually experiencing delays and budget overruns, requirements have to be tracked in a satisfactory way
 +
 
 +
 
 +
=== Overall impression of the ''Application context'' ===
 +
* Very good idea to present different aspects, where Requirement management is relevant!
 +
* Overall a very good chapter, but there is a lack of references.
 +
 
 +
== Requirements elicitation==
 +
* Very good chapter, easy to understand.
 +
== Requirements analysis ==
 +
* Very well written section, but it would be very nice with a discussion regarding the Strength and weaknesses etc..
 +
 
 +
== Requirements change management ==
 +
* Very interesting aspect to consider!
 +
* There are no references assigned to this section.
 +
** '''I have now assigned my references'''
 +
 
 +
=Overall feedback=
 +
* Please read the article for grammatical errors (not many, but a few).
 +
* I would properly introduce the section "Main steps of requirements management" earlier so when reading the different areas, where this approach is relevant the reader will already have an idea of what it is.
 +
** '''You are right, it makes more sense to explain the steps first, and add the application chapter as examples in the end.'''
 +
* Please be more critical throughout the article
 +
** state strength, weaknesses and controversial points.
 +
*** '''I wrote my article as an 'introduction and overview' article. It is open to discussion but I do not think it is the purpose of my article.'''
 +
* An example for how to apply requirements management would be very nice, so the reader could get an idea of how to implement this in his/her project.
 +
* An overall comment is that there a missing a lot of references, when doing this kind of article.
 +
* Please be aware of copy&paste.
 +
* Please attach "categories".
 +
** '''Two categories were already attached.'''
 +
 
 +
= MartinKruck peer review =
 +
 
 +
= Formal aspect =
 +
 
 +
'''References'''
 +
As mentioned by NobodyKnows, you should remember to use references.
 +
 
 +
'''Language'''
 +
When rereading your article be mindful of your english, especially when using the suffix -s
 +
e.g.: "As a matter of fact, a new designed product  need (not:needs) to fulfil the customer’s expectations"
 +
* '''why not needs? I do not understand this rule...'''
 +
 
 +
As mentioned by NobodyKnows, you should not use acronyms (don't, shouldn't). But I am sure that was just a slip up, since it only happened once ;-)
 +
* '''Now corrected!'''
 +
 
 +
Also remember that [:] forces capital on the following letter. You have a title saying: "Requirements management: how to make a project successful?"
 +
* '''I did not know this rule (in French, colons call for lowercase!). I think I corrected it everywhere.'''
 +
Further more; this is not a question. Since this is the only title with a colon [:] it looks weird. Consider rewriting the other titles to the same format or rephrase the title to something like: How to make a successful using requirements management
 +
* '''You are right, I did not really know how to turn this title. I think I have now found a better one.'''
 +
Other than those I only stumbled a few times. 8/10 on your english.
 +
* '''Thank you! That's good to know, I was kind of worried about this :\'''
 +
 
 +
'''Figures'''
 +
I feel that most of your partitions could use some figures to illustrate their points, especially chapter 3 and 4, where you discuss some very valid points, which are also though to read since they are very complex.
 +
* '''You are absolutely right. I know I should put figures and I would have liked to add some but unfortunately I could not find very accurate ones and I lacked time, so I wanted to focus on the text...'''
 +
 
 +
= Content =
 +
 
 +
Chapter 1 gives a great definition of the subject, but does not give a great summary of what is to come.
 +
 
 +
Chapter 2 is very well written and could only benefit from a few useful figures.
 +
 
 +
Chapter 3 loses some of its focus. I think that starting each topic with a '''short''' presentation on what each project is about and what/how requirements management is to be used, would help this part.
 +
 
 +
Chapter 4 is a bit confusing. I think that you should look further into your use of layout and/or use appropriate figures.
 +
 
 +
BTW you mention stakeholders. This subject is covered [[Mapping Stakeholders]] code: <nowiki>[[Mapping Stakeholders]]</nowiki>
 +
* '''There are a lot of wiki articles about stakeholders! But I will try to find one to link here, because it is relevant.'''
 +
 
 +
Otherwise I think that the article is great and gave me some new knowledge. Keep up the good work!
 +
* '''Thank you very much for your review! I also learnt a lot when doing this article ;)'''

Latest revision as of 18:31, 1 December 2014

My answer to the reviews is written in bold

Contents

[edit] 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. There are only comments if a section is shown below.


[edit] 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 thought that writing where the quote came from was sufficient, but I have now updated the source

  • 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.
      • You are right, it was a inattention mistake that I now have corrected.
  • You state that "Requirements management can be handled by using different kinds of tools, which can either be manual processes or specialised tools."
    • This is not really mentioned in depth throughout the article, but sound very interesting.
      • Some companies use only tools like excel or word (basically lists) but for complex projects it seems that there are kinds of software for managing requirements. I did not see the point in explaining them in the article because there are a lot (there is not only one good way to manage requirements) and they are produced by private companies.

[edit] Overall impression of the Overview chapter

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

[edit] 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."
      • Actually, this is my own point of view on how to define the success of a project. Of course, I was also helped by the readings I have done, but I cannot add one reference for this statement...

[edit] Overall impression of the project success

  • It would be very nice if a definition of "customers" regarding projects could be made and maybe a few examples.
    • I think it was obvious but it seems that it is not, so I added explanation.
  • Please consider if it is only the customers expectations that needs to be satisfied - if yes - please state why?
    • I do not understand what you mean here? I detailed 4 criteria to define project success, customer's satisfaction is one of them but there are still 3 other, but they are detailed. I meant here that the customers' requirements are one main aspect to consider in a project in order for it to be successful.

[edit] Application context

  • An idea would be to make a reference to a wiki article regarding "System Engineering"
    • This is true, a link to the article comparing systems engineering and project management is absolutely justified here and can be a good complement to my article. So I have now added the link!

[edit] System engineering processes

  • It feels like the section just ends, without a "wrap-up".

[edit] Product development projects

  • Please assign reference
    • Product development projects are becoming more and more complex, especially because of the increasing variety of demands from customers
  • Please assign reference
    • A way to keep track of the customer’s requirements in new product development is Quality Function Development, which is a tool used for defining the characteristics of a product as targets to be achieved for the engineering characteristics of the product in a way that customer’s requirements are satisfied.
  • Good informative chapter!
    • I have now added references

[edit] Construction projects

  • A reference is needed for this.
    • Because construction projects are usually experiencing delays and budget overruns, requirements have to be tracked in a satisfactory way


[edit] Overall impression of the Application context

  • Very good idea to present different aspects, where Requirement management is relevant!
  • Overall a very good chapter, but there is a lack of references.

[edit] Requirements elicitation

  • Very good chapter, easy to understand.

[edit] Requirements analysis

  • Very well written section, but it would be very nice with a discussion regarding the Strength and weaknesses etc..

[edit] Requirements change management

  • Very interesting aspect to consider!
  • There are no references assigned to this section.
    • I have now assigned my references

[edit] Overall feedback

  • Please read the article for grammatical errors (not many, but a few).
  • I would properly introduce the section "Main steps of requirements management" earlier so when reading the different areas, where this approach is relevant the reader will already have an idea of what it is.
    • You are right, it makes more sense to explain the steps first, and add the application chapter as examples in the end.
  • Please be more critical throughout the article
    • state strength, weaknesses and controversial points.
      • I wrote my article as an 'introduction and overview' article. It is open to discussion but I do not think it is the purpose of my article.
  • An example for how to apply requirements management would be very nice, so the reader could get an idea of how to implement this in his/her project.
  • An overall comment is that there a missing a lot of references, when doing this kind of article.
  • Please be aware of copy&paste.
  • Please attach "categories".
    • Two categories were already attached.

[edit] MartinKruck peer review

[edit] Formal aspect

References As mentioned by NobodyKnows, you should remember to use references.

Language When rereading your article be mindful of your english, especially when using the suffix -s e.g.: "As a matter of fact, a new designed product need (not:needs) to fulfil the customer’s expectations"

  • why not needs? I do not understand this rule...

As mentioned by NobodyKnows, you should not use acronyms (don't, shouldn't). But I am sure that was just a slip up, since it only happened once ;-)

  • Now corrected!

Also remember that [:] forces capital on the following letter. You have a title saying: "Requirements management: how to make a project successful?"

  • I did not know this rule (in French, colons call for lowercase!). I think I corrected it everywhere.

Further more; this is not a question. Since this is the only title with a colon [:] it looks weird. Consider rewriting the other titles to the same format or rephrase the title to something like: How to make a successful using requirements management

  • You are right, I did not really know how to turn this title. I think I have now found a better one.

Other than those I only stumbled a few times. 8/10 on your english.

  • Thank you! That's good to know, I was kind of worried about this :\

Figures I feel that most of your partitions could use some figures to illustrate their points, especially chapter 3 and 4, where you discuss some very valid points, which are also though to read since they are very complex.

  • You are absolutely right. I know I should put figures and I would have liked to add some but unfortunately I could not find very accurate ones and I lacked time, so I wanted to focus on the text...

[edit] Content

Chapter 1 gives a great definition of the subject, but does not give a great summary of what is to come.

Chapter 2 is very well written and could only benefit from a few useful figures.

Chapter 3 loses some of its focus. I think that starting each topic with a short presentation on what each project is about and what/how requirements management is to be used, would help this part.

Chapter 4 is a bit confusing. I think that you should look further into your use of layout and/or use appropriate figures.

BTW you mention stakeholders. This subject is covered Mapping Stakeholders code: [[Mapping Stakeholders]]

  • There are a lot of wiki articles about stakeholders! But I will try to find one to link here, because it is relevant.

Otherwise I think that the article is great and gave me some new knowledge. Keep up the good work!

  • Thank you very much for your review! I also learnt a lot when doing this article ;)
Retrieved from "http://wiki.doing-projects.org/index.php?title=Talk:Requirements_management&oldid=6192"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox