Talk:Requirement/Archives/2013

General comments

Questions

1. This page has been very much in need of a cleanup for several years. Re-reading it now, it is clear that the structure of the page reflects several different worldviews, each with their own (most likely partial) classifications of requirements, including how desirable and useful they are. And the References and External Links in particular are "selective" at best and urgently need balancing. Ideally each such list (in fact the whole page) would approach the topic by showing and referencing the main alternative points of view. Perhaps some of these (please extend!) are:

• "Reqs begin the life-cycle" vs "Reqs continually evolve during life-cycle"
• "Reqs are functional/non-functional" vs "Reqs are of very many kinds"
• "Reqs shall contain 'shall/should' to show priority" vs "Reqs have explicit priorities"
• "Reqs are purely text" vs "Reqs are database records"
• "Reqs are purely contractual" vs "Reqs include goals, scenarios, context..."
• "Reqs are individual functions" vs "Reqs can be stories, scenarios, use cases"
• "Reqs are for systems/software" vs "Reqs are for user/stakeholder needs, specifications are for systems/software"

Chiswick Chap (talk) 10:13, 22 November 2010 (UTC)

1. Certain requirements, by their very structure, are not testable. These include requirements that say the system shall never or always exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements are often rewritten to state a more practical time period.

   So a requirement such as the pacemaker should never fail becomes the pacemaker should fail after a testable time...?

   I would argue that the initial requirement is inherently wrong and should be changed to something can be at least calculated (if not tested) and derived from the failure rate of the parts that make the pacemaker. If you could only guarantee a pacemaker would work for 12 months - then it would be replaced at that interval given the severe consequences on failure. —Preceding unsigned comment added by Pauldouglas72 (talk • contribs) 13:47, 2 November 2010 (UTC)

2. What is the relation between requirements (as in this article) and specifications in (software) engineering?

   They are the same thing although often represented in different styles, Software Requirements are a Software Specification.

3. Shouldn't a page about requirements be required to be cleaner? —Preceding unsigned comment added by 216.156.83.110 (talk) 03:15, 9 October 2010 (UTC)

--Abdull 19:39, 1 June 2007 (UTC)

I removed the phrase "JOEL BURNS MONKEY FISH!" despite being pretty amused by it. -MCF —Preceding unsigned comment added by 12.111.169.2 (talk) 15:55, 26 October 2007 (UTC)

In the "disputes" section I added a reference to a recent journal article arguing that software requirements are often an illusion. Perhaps this page needs a Criticism subsection, as is common in wikipedia articles, to describe criticism of the concept of requirements in principle. Paul Ralph (Lancaster University) (talk) 16:27, 15 March 2013 (UTC)

Questions and Issues

Observable requirements

The fact that observable requirements are judged as being a poor principle seems subjective, albeit the alternative argument is given. I'd suggest changing the wording to reflect two sides of an argument subjectively, rather than the article coming to a conclusion about which side is better.

Derived Requirement

I'd like to know exactly what a "derived requirement" is. I can't seem to get a straight answer that is sufficiently robust. It'd be nice if this article discussed derived requirements a bit. Vincent J Ree Jr (talk) 14:32, 20 December 2007 (UTC)

A "derived requiement" is a more detailed requirement than the original (decomposition in the systems engeering process" or it is a requirement which was created by an associated analysis. Examples would be:

 "An integral fan shall provide cooling air."
 "The device shall include a fuseholder that is externally accessible."

Often derived requirements come from reliability, maintainability, safety, envirdonmental, etc. The basis for the requirement is related to compliance with regulatory (government) or industry recommendations. Bjbuelow (talk) 18:27, 6 February 2008 (UTC)

Another view of this is that a derived requirements is a requirement that came from the decomposition of a higher level requirement in design or architectural activities. An example would be a system level requirement that states, "The indicator on the product shall flash at 10 Hz." This could then be decomposed during system design into a software controlled LED. This would then drive two requirements: 1) "There shall be a hardware LED indicator onthe face of the product." and 2) "The product software shall supply a 10 Hz signal to the LED indicator." Both of these requirements were 'derived' (and subsequently traced back to) the higher level requirement with the system design providing the rationale for the derivation. Dchristie1a (talk) 22:55, 30 June 2010 (UTC)

"Derived" is saying it is a requirement emerging from some process or analysis. Usually 'derived' refers to something other than 'decomposed' requirements coming from dividing a more abstract or generic phrasing into multiple more specific ones. As it says in the article, requirements taxonomy varies, and applications of the term 'derived' vary, e.g.

• Requirements which may or may not be explicitly stated in the customer requirements, and which may be inferred from commercial requirements, e.g. applicable standards, laws, policy, common proactice, and management decisions. Derived requirements can also arise during analysis and design partitioning of the system [SECMM-95-01, v1.1] In the requirements process, system requirements are derived from approved operational requirements.
• Requirements that are not explicitly stated in the customer requirements, but are inferred (i) from contextual requirements (e.g. applicable standards, laws, policies, common practice, and management decisions), or (ii) from requirements needed to specify a product component. [CMMI-SE/SW/IPPD, V1.1 Dec 2001]
• Requirements management provides traceability from any derived lower level requirement up to the applicable source from which it originates. [Defense Acquisition Guidebook, 4.3.5] In the US DOD model, requirements should proceed from Operational need statements to Functional (behaviour or I/O phrased) Requirements and Non-Functional(qualities and lifecycle objectives, e.g. weight/ower/space, applied standards and policies, etcetera).

Markbassett (talk) 18:30, 18 July 2013 (UTC)

Usenet

Are there any usenet groups for software requirements engineering? A link in the article, or at least a bullet item, would be helpful. DRogers (talk) 15:27, 9 April 2008 (UTC)

talk There is one here http://tech.groups.yahoo.com/group/Requirements-Engineering/ . Not sure of it fits this page though. Craigwbrown (talk) 11:00, 16 January 2012 (UTC)

Documented

I don't think all requirements need to be documented, especially in this lightweight methods era. Requirements can be written or spoken or simply inferred (see the 'derived requirements' above for example.) Craigwbrown (talk) 11:09, 16 January 2012 (UTC)

It's an opinion, and as such WP:OR if written - either for or against, unless it's properly cited. As you suggest, that should be easy with all the "agile" books around. (Is the opposite "maladroit" or what? Ahem.) Seriously, the right approach is to describe "traditional" or "deliberate" style and "agile" style, each with quotations and citations. There is a tricky propaganda element here, which is that the term "requirement" itself implies (a need for) documentation. Perhaps you should be looking to other articles to make the comparison. I think that if you were to write up your proposed additions in full, you'd be heavily duplicating the content of other articles such as Requirements Engineering and the rest of the "see also" list: we should focus this article tightly on the thing itself, which is basically the preserve of the traditional shopping-list school. As soon as you touch on methods you're into the other articles. Chiswick Chap (talk) 11:22, 16 January 2012 (UTC)

Good points. I think I'd rather just see this concept addressed though the proposals I put down below. I'll be chasing up others to help out with the changes. — Preceding unsigned comment added by Craigwbrown (talk • contribs) 11:48, 16 January 2012 (UTC)