Talk:Requirements engineering

General remarks

• Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)
• Good sample of references and links to other material
• You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition
• 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 itself) 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

Creating requirements

• In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.

Major concepts

You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"

Requirements elicitation

• This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications

Design and validation

• It becomes a little unclear where we are now in the RE lifecycle?

Context

• You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.

Functional requirements

• Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.
• If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.

Non-functional requirements

• Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.
• You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.

Requirements management

• Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?

Discussion

• It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.

General remarks

Language

Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.

Layout

Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the Help page on formatting)

Specific remarks

Introduction

Grammatical things

"among the involved parties"

"from a client" => "of a client"

"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.

"the developers create" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words I, you, he/she/it, we, You, they :)

"to specific" => "to specify"

"is suppose" => "is supposed"

"the basis to get" => "the basis for getting"

"a iterative" => "an iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is an

"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.

The introduction is (besides the above stuff) very well written and explanatory.

Background

due to the header it is difficult to see that the text is an introduction to the following sub-headers..

Application context

Grammatical things

"basis for" => "basis of"

"and that is where" => "and this is where"

"to understand" => "understanding"

"the need", "the problem"

"is done" => "is reached" or "has been established"

"need of" => "need for"

"be clear defined" => "be clearly defined"

"It is about" <= speech, and what is It in this sentence?

"creating stable" => "creating a stable"

"the destination" <= I think "where you might end" sounds a bit better?

I'd scrap "though" and start at "The intention of the requirements"

you mix times.. "is" and "would".. use "will"

"management requirements" ? missing a komma? and then "form" without s

"There exists multiple examples" => "Multiple examples exist"

"because poorly" => "because of poorly"

"shows the problems" => "shows that the problems"

perhaps use ":" to list the three categories?

Perhaps elaborate bit more about the challenge you mention

Acceptance and use

layout

a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.

Grammatical things

"requirements engineering"

"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.

"the could cause" => "this could cause a"

"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".

"for example" => "for example;"

again "requirements engineering" be consistent in that one, not mentioning it again.

"applies" => "also applies"

try to read the sentence without the insert.. "components which.." consider revision of the last part.

"There exist several standards" => "Several standards exist"

"define." and "where in" => "In"

"likely the" => "likely that the"

Interesting and with substance

Creating requirements

Layout

remember the header issue

Grammatical things

"different ways" <= perhaps add an indicator of ammount? several, many, some.

"accordingly" => "according"

"a system" => "the system" ?

"supposed"

"achieve the"

"best as possible." => "the best." ?

ouch.. missing the s in your text for the picture as well.

"in this article".... are they? which article.. the one I'm reading or the one you are referring to?

Major concepts

no intro?

Requirements elicitation

Layout

Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.

Beautiful table. well thought.

Grammatical things

req-s again.. is the header or text incorrect?

"to understanding" => "to understand"

take out "Though"

"use full" => "useful"

"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?

"called more like a" speech language => "called a"

"where some like" => "where something like"

"in to" => "into" (best test.. make the space a deliberate pause when reading)

"desires"

"through"

impressive chapter, very few errors and very understandable.

Design and validation

I will continue my revision from here tomorrow wednesday.