Revision as of 22:25, 25 November 2014

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.

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.

• 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.

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 project success

• 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 - if yes - please state why?

Application context

• An idea would be to make a reference to a wiki article regarding "System Engineering"

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!

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.

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.
• Please be more critical throughout the article
  • state strength, weaknesses and controversial points.
• 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".

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"

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 ;-)

Also remember that [:] forces capital on the following letter. You have a title saying: "Requirements management: how to make a project successful?" 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

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

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.

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.

Lastly I feel that the article ends rather abruptly. Either think about rounding the last partition or add a fifth chapter.

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