|This article is of interest to the following WikiProjects:|
I reworked the article to improve flow and correctness and added some references. This article needs more work but I did the best I could with the time I had. Paul Ralph (Lancaster University) (talk) 16:54, 15 March 2013 (UTC)
The intro states that "However, recent research suggests that software requirements are often an illusion created by misrepresenting design decisions as requirements in situations where no real requirements are evident ". This is a strong statement. How often is "often"? The cited paper's abstract says "This viewpoint explores the possibility that many software development projects may have no useful requirements.... In [these] situations of sparse requirements, analysts may misrepresent design decisions as requirements, creating an illusion of requirements in software development." Right, so there is a danger of mistaking design decisions for requirements. Okay, but that does not imply that "software requirements are often an illusion". Changing the text accordingly... 126.96.36.199 (talk) 16:19, 18 March 2013 (UTC)
The abstract doesn't say that software requirements are often an illusion, but the paper does. I know, because I wrote it. You're right, though, about it being a strong statement. I've created a new subsection, Criticism, and moved there. Paul Ralph (Lancaster University) (talk) 20:45, 20 March 2013 (UTC)
@The Authors of the first sentence: did you think about the possibility, that requirements could exist somewhere else in the development universe than just in software? Next: if "Paulralph" wants to advertise his article, he is not supposed to do it here. This whole article is a harm rather than a clarification. Google will give you more information and less disturbance in short time. I'd vote for deletion. — Preceding unsigned comment added by 188.8.131.52 (talk) 15:44, 8 October 2013 (UTC)
Requirements Engineering is a much wider field than just Software Engineering. And the same principles and practices apply across many other fields. It should not be assumed that Software Engineering is the context for Requirements Engineering. Rather "Systems Engineering" is the wider field -encompassing all types of engineering- and Requirements Engineering is a subset of that - as is Software Engineering. In practice "Software Requirements" may be an illusion - but that is only because most Software Engineers (or actually "programmers" for whom the designation 'Engineer' would be too elevating as they are not that professional) are not well-trained in Requirements Engineering - and so don't practise it. In principle, however, there are Software Requirements even if in practice they are not properly articulated and often in-fact mis-used to represent design decisions. So to say "Software Requirements are an Illusion" is too strong; Software Requirements should/do exist but many programmers are deluded about them and don't write them down properly - they exist only as (intersubjective) ideas in the heads of people and unconscious influences (rules of thumb, personal experiences) on software design decision-making. This is why software development generally is still not a profession - not an engineering profession. — Preceding unsigned comment added by 184.108.40.206 (talk) 13:49, 28 February 2016 (UTC)
The purpose of Requirements Analysis is precisely the identification of such requirements (there is no separate phase for this called identification). The first versions of the Requirements Specification (RS) are drafts and the final version must be validated and then the official RS is produced. I also made some re-wording and improvement. I would like to hear your comments, I am going to be bold and delete that item. This is not accurate right now. If you want to object, let us discuss it here.
- Ralph, Paul (2012). "The Illusion of Requirements in Software Development". Requirements Engineering.