Talk:Requirements engineering
From apppm
(Difference between revisions)
(→General remarks) |
(→Introductory paragraph) |
||
| Line 10: | Line 10: | ||
===Introductory paragraph=== | ===Introductory paragraph=== | ||
| + | *Second sentence: Are you referring to requirements as "formalities"? Difficult to understand. | ||
| + | *See also general remark, consider rephrasing the paragraph to set the scene for your article better | ||
| + | |||
| + | ===Application context=== | ||
| + | *First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ? | ||
| + | *Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article | ||
| + | *Sentences no. 8 and 9 are difficult to understand, consider rephrasing | ||
| + | ===Acceptance and use=== | ||
| + | *In general, this section (and even the header) is a bit difficult to understand. | ||
| + | *As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition | ||
| + | *What is the point of your references to software development issues in the first half of the paragraph? | ||
| + | *It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp | ||
| + | === | ||
Revision as of 21:03, 25 November 2014
Contents |
Review by MrP
General remarks
- Very relevant topic, thorough and well researched article
- Good sample of references and links to other material
- Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent
Specific remarks
Below please find som specific remarks, adressing particular sections in your article
Introductory paragraph
- Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.
- See also general remark, consider rephrasing the paragraph to set the scene for your article better
Application context
- First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?
- Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article
- Sentences no. 8 and 9 are difficult to understand, consider rephrasing
Acceptance and use
- In general, this section (and even the header) is a bit difficult to understand.
- As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition
- What is the point of your references to software development issues in the first half of the paragraph?
- It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp
