Talk:Requirements analysis

message: I removed the  template here, for two reasons: 
# The template is replaced by the a new :Template:Software Engineering template and will probably be removed sone.
# This vertical template about software engineering is confusing any way, because it pretends the article is for most parts a central part of templates subject, which is not. 
The central scope of this article is systems engineering, and not software engineering so this template is not acceptable here. The alternatiev template is allready present. -- Marcel Douwe Dekker (talk) 13:06, 21 October 2008 (UTC)
thread_title:  Removed <nowiki>{{Software development process}}</nowiki> 

message: If "Brainstorming" is a mainstream technique, then there should be reliable sources available that talk about it. If there is just one book promoting the topic, then any inclusion of the technique should be minimal at best. AliveFreeHappy (talk) 21:20, 11 August 2010 (UTC)
thread_title:  Brainstorming section 

message: Firstly I'd like to acknowledge the fine work done by authors and contributors to get this article to it's current state.  I think it's sufficient to give a new requirements engineer/analysts insight into some key issues.
However, when it comes down to it this article needs some solid rework.  Apart from the conflation between requirements engineering and analysis there are a number of issues.  In many ways this article exhibits the characteristics of poor requirements cited by academics and industry observers and is the antithesis of what a god requirements analysis description should be.
I don't want to jump in half-cocked so I want to pose some questions to start, get a bit of discussion and then look to either some major reshaping of the content or developing a framework for continuous small improvements.
Questions
1. What is requirements analysis?
* Is it a subset of a requirements engineering process? 
::From the RE Yahoo group comes this definition of a requirement;
Below is IEEE-610â€™s definition of requirement:
::
1. A condition or capability needed by a user to solve a problem or achieve an
objective
2. A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally
imposed document
3. A documented representation of a condition or capability as in 1 or 2
The above definitions separate users from software or system. We often say to
install, configure systems that exclude users. The sharp distinction of boundary
of software make it easy for us to see other levels of abstraction, such as
agent and business levels. We must process information in the order of the level
of abstraction from the most abstraction to the most concrete. In object
oriented paradigm, we must know abstract class before know the derived classes.
Current software engineering text and practice donot make sharp or scentific
distinctions of levels and begin with concrete levels, causing rework and
failures. And we give ourselves excuses of requirements change. Requirements
donot change in most cases. It is our understanding of them that keep change.
The reason for which is lack of scientific knowledge to define requirements.
Example
* Does a new Requirements Engineering page need to be (re) created?
* Is Requirements Analysis a sub-system or sub-process of any higher level models?  For example; I think it's an activity in the Business Analysts Body of Knowledge AND a process step in the Requirements Engineering (and Software engineering) paradigms.
2. Who performs Requirements Analysis?
* Examples I can think of; Business Analysts, Software engineers, Product Managers, and Process Managers.  No doubt there are more.
3. Why is Requirements Analysis performed?
* There is a cost for doing this work. What's the benefit?  Is there any variation in value and importance based upon who is doing the work?  For example a software engineer is probably approaching an issue with a different focus to a process manager.
3.1 What is the contribution of good requirements analysis to business and project outcomes.
4. Where is requirements analysis performed?
* Some examples that spring to mind include; Software houses, Product development labs, "enterprises" (i.e. large companies and give dept's.)  Got More?
5. How is requirements analysis performed?  
* There are so many approaches that this article should probably only refer to schools of thought.  I guess the argument around software engineering could inform this.  I don't know enough to break this down into a manageable list.
* Are there any universally acknowledged best practices?  —Preceding unsigned comment added by 138.217.71.115 (talk) 05:04, 1 January 2011 (UTC)
replies: text: Hello, I agree with you. Feel free to rewrite the article to make it better. Pm master 19:51, 6 January 2011 (UTC)
thread_title:  Time for a rewrite? 

message: The reference to McConnell's book is incorrect. It is unclear, if the list below the reference is taken from the book unmodified. 
* If the section pretends that the list was suggested by McConnell, then it lies; there is no such a list in the book.
* If the list is a paraphrase of the McConnell's book, then it is a very far from the original text. The similar list is present in the section related to the development Risks and not to the requirements analysis specifically.
* If the list is a generalization of the McConnell's thoughts taken from 'Rapid Development', then this section represents an original research and should be marked as such.  — Preceding unsigned comment added by 46.0.73.122 (talk) 21:04, 17 December 2011 (UTC)
replies: text: Thank you. Obviously the section has been edited since someone put in the McConnell citation. I'll take a look at it - all welcome to help tidy up the section. Chiswick Chap (talk) 10:01, 18 December 2011 (UTC)
thread_title: Stakeholder issues

message: I've cut down the Prototyping section to a couple of simple paragraphs with links to other articles (and a MAIN: link to Software prototyping). The rest of the text is below if anyone feels like editing and sourcing it. Chiswick Chap (talk) 12:24, 18 December 2011 (UTC)
thread_title: Prototyping - unsourced text removed

message: "In the mid-1980s, prototyping was seen as the best solution to the requirements analysis problem.
However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem:
* Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
* Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
* Prototypes principally help with design decisions and user interface design. However, they can not tell you what the requirements originally were.
* Designers and end-users can focus too much on user interface design and too little on producing a system that serves the business process.
* Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations."  (cut text) Chiswick Chap (talk) 12:24, 18 December 2011 (UTC)
thread_title: Prototyping text cut from article:

message: I am the inventor of ScopeMaster, the first tool to automate several aspects of requirements analysis, so I do have specialist knowledge in this topic.  One might even argue that I could have a potential conflict of interest, notwithstanding readers of this article will be interest in automation and I have quoted a couple of independent verifiable sources.  I trust this is acceptable. 
Colinrhammond (talk) 20:09, 13 December 2019 (UTC)
replies: text: As you've been told several times, your self promotion and repeated attempts to insert references to your products are not acceptable. - MrOllie (talk) 20:41, 13 December 2019 (UTC)

text: Since Wikipedia is not meant to be a vehicle for advertising, readers of Wikipedia will have to discover your company on some other web site. - MrOllie (talk) 21:15, 13 December 2019 (UTC)

text: No, Wikipedia is not a vehicle for sharing the latest knowledge. Wikipedia is a vehicle for sharing widely accepted knowledge, not for promoting technology that is only sold by a single vendor. That would be advertising. - MrOllie (talk) 12:59, 14 December 2019 (UTC)

text: It was not neutral because it served to emphasize a feature of your product. I can't think of any wording that accomplishes that aim and would be acceptable. - MrOllie (talk) 16:35, 14 December 2019 (UTC)

text: So many products are mentioned on Wikipedia, are they not ok?  For now you would prefer that the world remains uninformed about the automated requirements analysis successes that are taking place?  Surely there must be some wording that is acceptable? Colinrhammond (talk) 17:35, 14 December 2019 (UTC)
thread_title:  Proposed new section