Talk:Requirements engineering

Reworked

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... 78.141.139.10 (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 159.51.236.31 (talk) 15:44, 8 October 2013 (UTC)

Why does the definition include the software systems only? --ViseMoD (talk) 08:47, 4 December 2014 (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 82.152.149.139 (talk) 13:49, 28 February 2016 (UTC)

The "Criticism" section is way overemphasized for the topic, as both referred articles are "exploring the possibility" by the same author but no further work has been created to show any of the criticism is factual. In the research community, positive results vastly outnumber this chapter, which I consider to be harmful only. — Preceding unsigned comment added by 86.60.209.176 (talk) 12:52, 2 September 2020 (UTC)

References

Identification phase

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. George Rodney Maruri Game (talk) 10:11, 13 May 2017 (UTC)

RE Priorization

Topic is missing completely. Reference books such as Engineering and Management Software Requirements or others have dedicated chapters. Specialized techniques exist. and paths to Agile "Story Planning", e.g. XP--LS (talk) 14:12, 20 August 2019 (UTC)

References

RE Tools

I would like to suggest that this page has a section that covers Tools for Requirements Engineering. This might include manual tools for diagramming and describing requirements (visio, balsamiq, powerpoint, CASE tools, and tools for manipulating Use Case diagrams. Most modern tools around requirements focus on requirements management mainly. Our own tool (I declare conflict of interest) <<spamlink redacted>> can help with 5 of the 6 activities described in this article and therefore would also be a suitable candidate. Colinrhammond (talk) 08:04, 21 March 2021 (UTC)

Requirements Engineering vs Reguirements Management

Both, RE and RM, are defined very similar. The question is, if both are so similar, chances are high, that there are just two synonymes for the same task. In my opinion, there is no difference in RE and RM. Requirements engineering IS the management of requirements in the technical field of engineering. Maybe someone should rework the articles of RE and RM so that this is more obvious. I propose to remove one of the activities: the point 6. Requirements management – Managing all the activities... — Preceding unsigned comment added by 217.110.196.152 (talk) 11:52, 2 June 2022 (UTC)