Wikipedia:Articles for deletion/Business requirements


 * The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review).  No further edits should be made to this page.

The result was   no consensus. Most people would prefer first attempting to rewrite it so that it sounds a bit more meaningful.  Sandstein  08:38, 5 February 2012 (UTC)

Business requirements

 * – ( View AfD View log )

Partial attempt to explain concerns below - please also see article and form own opinion: I'm not convinced this article is encyclopaedic or needed - it's clear that "business requirements" is a term that is often used in a business environment (as confirmed by an easy web search). If one takes the (obvious?) definition "business requirements are things a business needs to do or be able to do" is the article needed?. There are multiple issues arising from lack of references, ie - is this not just a "two word pair" on which an essay has been written?, does an accepted definition even exist? Is this WP:OR or just a well written essay (not actually suitable for an encyclopaedia)? Use of jargon, and lack of a lead suitable for layman complicate analysis. This really reads like a jargon heavy MBA dissertation - I'm not convinced that this is a topic suitable for encyclopedia (ie why is this not covered in the article Business), or that the coverage is encyclopedic - my view is that this is a "meta article" attempting to define business related jargon. (rhetorical examples) what about articles on "business technology" "business computing" "business networking", "business relations" etc etc. it creates a never ending list - also see the "see also" section of this article that links to many more articles with similar or related issues - to be honest I see a developing issue with what I would call "business fan cruft" - the danger is the reader is lost in a sea of jargon - that may have already happened. If people agree with my concerns I think a whole raft of similarly written articles may need to be looked at. How do I say bullshit - totally obfuscated article - nominator suggests may not actually be written in english.


 * Summary - over extensive coverage of common business jargon - either needs deletion, extensive cleanup, merge to much smaller redirect to section of business, or simple wiktionary definition. User:Mddkpp


 * Delete - an exceptionally badly-written article with a remarkably poor References section - only to company sites, too, so this is probably not only WP:OR but WP:SPAM. The term 'business requirement' is however in fairly wide use in industry; it doesn't just mean "things a business needs to do" but "things a business needs to have done... most likely by a software or other system which we're about to procure". But WP:TNT applies here: blow up and start over would be easiest. If it's needed at all, other than as a mention in Requirement and Requirements analysis. Chiswick Chap (talk) 00:04, 29 January 2012 (UTC)
 * Note: This debate has been included in the list of Business-related deletion discussions.  • Gene93k (talk) 01:12, 29 January 2012 (UTC)


 * keep. Improvable. If the topic is notable, there's no justification for deletion. In fact,I do not find it exceptionally badly written. True,  the paragraphs are longer than in our usual style based on the manner or elementary school primers, but this  is easy to fix; true, and there's too much wordiness and jargon, which is almost as easy to fix. But  everything is understandable. The references do need improvement. I agree with Chiswick Chap that the title seems poorly chosen (perhaps it should be Business requirement analysis)( but the material covered does seem like a distinct topic.  Once we start deleting for poor writing, there won't be much of Wikipedia remaining. Our way or working is not well suited for elegant style--though better than the present state of this can certainly be achieved. FWIW, the German  Wikipedia I am told does delete for low quality writing--but that WP also gladly accepts articles with much lower than our standard of referencing when the sources seem reasonably obvious. If anyone proposes we emulate them, let them first find the qualified authors able to do educated writing based on common sense knowledge that the deWP seems to have available.  DGG ( talk ) 01:33, 30 January 2012 (UTC)


 * I vote for keep+improve. Blow it away and it will just come back in just as ugly a form.  There are actually appropriate references for this topic - most notably from IEEE and the engineering world.  Page is definitely full of cruft. The problem is that so many people who analyse and design logical relationships, structures and convey this via document writing actually can't :) I propose we design a simpler structure on the BUSINESS REQUIREMENTS talk page and test drive some new/old content combos.  Thoughts?Craigwbrown (talk) 11:45, 30 January 2012 (UTC)


 * Keep, total rewrite OK, I can see which way this is going. For me, the choice is therefore between a total rewrite under this title, with new text and citations, or a merge to Requirement (despite the total muddle in the article - is it about BR or Analysis?) which obviously includes System Requirement as well as Business R. Guess it doesn't matter a lot which way we do it. Let's all have a go at Improve, then. Chiswick Chap (talk) 12:10, 30 January 2012 (UTC)


 * Delete, strongly. If an article requires a total rewrite, deletion probably should be considered; but this requires a rewrite because the underlying idea is so bloody obvious as to have no focus: Business requirements describe what a business needs to be able to do, and any required constraints such as necessary performance, security, or safety that apply at the business level.  Being unconstrained by an actual subject to be about, the prose can expand by the leisure and vocabulary of the originating editor until it reaches the stage where no reasonable person can be expected to make any sense of it, and that's what we have here:
 * Stakeholders who help define requirements come in early, and later hand over to the project development teams who build the business system; others test and evaluate final deployed system or working solution. Clarity requires traceability of requirements, making necessary a well administered process to control the process of determining business requirements. This regularises the process, determining which template to use, determining to who fills what section, and who modified next and released which version.
 * To address these challenges, early stage stakeholder buy-in achieved through demonstration of prototypes and joint working. Stakeholder workshops are common, either as facilitated sessions or simple huddled discussions help in achieving consensus, especially for sensitive business requirements and where there is potential conflict of interest. Complexity of a business process is a factor of such interest conflicts among stakeholders or due to an inherently complex business process, such as one where there is much specialized knowledge required to comprehend legal or regulatory requirements, internal company wide guidelines such as branding, corporate commitments to social responsibility, and the like.
 * It wanders from flower to flower, dribbling abstract nouns and glittering generalities as it goes, without ever settling in one place. News searches find results for "business requirements", of course; different businesses require many things.  But nothing suggests that "business requirements" is an appropriate or even possible standalone subject for an article. - Smerdis of Tlön - killing the human spirit since 2003! 16:26, 30 January 2012 (UTC)
 * I am perfectly willing to rewrite those two paragraphs so it matches your preferred style of prose, or at least as close as my ordinary style can get--I haven't the least difficulties in understanding; a little attention can reduce jargon to more standard English, but to some extent jargon is inevitable for discussing subjects which are generally discussed in that style--I dislike some of the contemporary business vocabulary as much as you do, but it's the vocabulary used in that segment of the RW.. To help me in rewriting, I'm curious what phrase you are unable to comprehend. (I will admit some subjects defeat me: I am unable to understand the articles on cricket in Wikipedia, and I can only understand the ones on baseball because I was brought up watching it.)  DGG ( talk ) 00:15, 1 February 2012 (UTC)
 * If either of those paragraphs mean anything more than "hold meetings, then pass off the project to the people who will actually do the work, all while taking notes" go ahead. But if that's the gist of it, I still think it's both trivial, and deceptive because it seeks to give self-importance to this triviality. - Smerdis of Tlön - killing the human spirit since 2003! 18:22, 1 February 2012 (UTC)

Comment I chose this article to AfD because it seemed at least a potential "real article" - I've already "prodded" many lesser articles, and there still are many left - eg Knowledge process outsourcing, Value process management, Agent-based computational finance, Human interaction management, Business process improvement, Business process illustration, Value grid - that have similar or different issues - it's a random list - some are better than others - one issue here is the extent of it - please start at Category:Business and browse downwards - maybe 25% or more of the articles have serious issues? And I'd estimate 10% might fail a WP:PROD, more an AfD - that's a problem.
 * One option (in many cases) would be to delete the text and convert to redirects a lot of these to a List of business terms and jargon - with minimal one line definitions or links.
 * There is a wide range eg consider the obviously notable article Customer satisfaction that needs work, to the article "Consumer confusion" which I am not sure needs to exist
 * What is the official way to deal with such a large number of articles needing improvement or deletion?Mddkpp (talk) 18:52, 30 January 2012 (UTC)
 * An honest question. I fear the proper answer is "one at a time, and very carefully", because topics like these do in fact often have their own "literature" - often textbooks, conferences, white papers, and whole schools of both industrialists and academics beavering away at improving the state-of-the-art. Such is certainly true of requirements engineering. I hesitate here because jargon changes quickly, but perhaps if I just say that "requirement" was fashionable and now is not; that people used to say "Functional Requirements" meaning requirements of all kinds at a level higher than design; now they don't; people then said "User Requirements", meaning the same thing; then a few said "Stakeholder Requirements" or "Business/User Requirements", and now (presto!) some say "Business Requirements", and guess what, it's mainly the same thing again. Worst is, each time the books and conferences and research of the previous mob are discarded, and a new lot starts over making the same mistakes. A business requirement is a need felt by a business for, usually, a bit of software, to fix some problem or other. I'm sorry that Smerdis (whose opinion I rate very highly) thinks this is all dross - the article as it stands is, but the subject is not. Sorry if TLDR. Chiswick Chap (talk) 19:51, 30 January 2012 (UTC)
 * A large part of the problem, IMO, is that the field tends to re-invent the wheel, or rather to repackage the same old wheel under a new name to enable a claim that the latest model does so much more than its forerunners. I did look through some search results, mostly Google Books and Scholar, and most results seemed to me to be adventitious.  I was unable to determine whether there was a clear distinction between "business requirements" and supply chain management, as suggested by one; or whether it instead related to business intelligence or business analytics, as suggested by another.  I'll wager that none of those just-linked phrases are anywhere near as red as they ought to be, either.  I'll wager all of them will give you a headache if you try to read them, too.  (And finally, I'll wager that all of them are written from a viewpoint that will inevitably suggest that computers and software are vital and central to the subject at hand.  This is obviously not true, and seems parochial, our inherent biases at work.)  My preference would be to clear much of them away, myself, for the simple reason that the prose they're written in is not built to inform. - Smerdis of Tlön - killing the human spirit since 2003! 21:15, 30 January 2012 (UTC)
 * My opinion is that this is an example of how not to write a dictionary - At a simple level - if you want to be in business selling apples your business requirements include - having apples to sell, having a shop to sell them from, having some bags to put them in, having change, having staff to do the selling etc etc - a business requirement document is a list of the things I just mentioned. A business analyst writes the list. Yes we probably need a reliable definition including a modern scoping, but I get the feeling all the words in the article are trying to hide an inherent lack of need for any article at all. (Supply chain management is getting the apples delivered by the way)
 * To support a stand alone article I'd would need to see evidence that there is anything needed other than a definition of the 'jargon' in a list of business jargon terms. I think the admission above by Chiswick Chap that the term is nebulous (or fragmented or whatever they actually said) suggests this is not a "stand alone" encyclopedic topicMddkpp (talk) 21:32, 30 January 2012 (UTC)
 * Agree with chiswic chap that TLC is needed - but before that a haircut and a de-louse please.Mddkpp (talk) 21:36, 30 January 2012 (UTC)
 * The first step, I think, would be to identify a set of core topics that are needed articles, and make sure they are in English, and avoid referring to "processes", "systems", or "stakeholders". Articles that pop up outside the core group can then be redirected to them.  My grave suspicion is that most of these unintelligible articles on these things are coatrack spam, designed to increase the visibility of buzzwords.  At any rate, I am fairly certain that "business requirements" is not one of the core terms or needed articles.  - Smerdis of Tlön - killing the human spirit since 2003! 15:39, 31 January 2012 (UTC)
 * Smerdis, what words would you substitute for "systems" or "processes". There are synonym phrases to say in in a wordier fashion, such as "inter-related groups of procedures", but they are not more precise. I dislike "stakeholders,", but again, the nearest equivalent is "those having an interest or concern in the matter". Have you any single word that expresses exactly the same meaning?  The business world has no need to Wikipedia to increase the visibility of the most common buzzwords. That's not what coatrack means--go look at that page you cite.  DGG ( talk ) 00:21, 1 February 2012 (UTC)
 * That's the problem with those words in a nutshell. They overgeneralize; they ignore the aspects of business that do belong in an encyclopedia, like the details of manufacturing, equipment, and raw materials, or the unique aspects of individual firms' corporate governance.  (And I do want intelligible articles to be written on these aspects of business.)  And my impression is that most articles on vague management theories, of the sort that are presented at the system/process/stakeholder level of abstraction, would appear to be trivial variants on each other.  The different names that are applied to them strike me as attempts at branding rather than attempts at drawing meaningful distinctions; and if the presentation is at that level of abstraction it becomes more difficult to tell whether they are or not.  This is why I tend to believe that vaguely worded articles on management subjects strike me as likely being coatrack spam. - Smerdis of Tlön - killing the human spirit since 2003! 16:25, 1 February 2012 (UTC)


 * Keep - Business requirements are a topic unto themselves. The quality of the article isn't in such a state that it is unusable.  Sources abound.  For example this. -- Whpq (talk) 17:30, 31 January 2012 (UTC)
 * Keep, rename to Business requirements (software development), and clean up accordingly. This is not an article about business requirements in general, it is in fact about business requirements within SDLC (see, for example, overview section). In SDLC world, all these things start to make sense and are indeed well-known (enough to pass WP:N with flying colors). Ipsign (talk) 13:16, 4 February 2012 (UTC)
 * The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.