- 1 Questions and Issues
- 2 Suggestions
- 2.1 Specific points for improvement
- 2.2 Structural improvement
- 2.2.1 Definition
- 2.2.2 Attributes
- 2.2.3 Origins and history
- 2.2.4 Contention
- 3 General comments
Questions and Issues
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.
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).
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)
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)
Specific points for improvement
- Remove many of the in-test hyper links to make the site more readable. Add the topics to the "See Also" section
- Modify the initial sections to become Types of Requirements to address the concept of Requirements taxonomy. This would be a good place to list many of the requirements related Wikipedia pages out there. To give them a home :)
- Add a section on the roots of the Requirements concept for system development.
- ( I presume there is some stuff from the 60's or at least 70's on taxonomies and attributes. At some stage someone decided to formalise the definition of product (and software) requirements)
- Add an industry definition (or comparison of definitions) from IIBA, IEEE and related bodies to get a clear understanding of definition (or lack thereof.)
I think the following structure would simplify the page. What do you people think?
- No. I think that as presented is giving proposals for separate articles, any case for this particular structuring in one article was not shown or given as one section in the Talk with the line above. Regarding discussion of structure for this article, I think that this is the overall 'Requirement', so should be things applicable worldwide and all approaches as much as it can, including mention where diversity or conflicts exist. Then point to more specific articles such as IEEE or Requirements (IEEE model) or Requirements (IEEE model)#History done separately. There seems to be four taxonomies and processes (Agile, DoD, IIBA, and IEEE,) and I think you can find overall comparisons out there to cite in the general article, but should not extend 'Requirements' into many pages and cannot put them in step by step matching presentation or comparison because they don't have the similarity such as same number of steps or basis of what requirement is and does. Markbassett (talk) 13:37, 30 August 2013 (UTC)
IEEE, IIBA, SWEBOK, etc definitions. Possibly in a table form to show the similarities and differences.
Common attribute lists for requirements, probably sourced from IEEE journals
Origins and history
Again, likely from IEEE; a description of how the term entered the world of product development. Perhaps some milestones along the way such as;
- The introduction of Functional & Non Functional as categories
- The introduction of standards around declarative requirements (IEEE?)
- The abandonment of declarative standards as people moved away to other modes
- The introduction of interaction requirements (originally something to do with sense-respond, and eventually use cases)
- The introduction of rules based requirements with the business rules movement
Competing frameworks such as IIBA, IEEE, and others
What are the implications of these competing views?
Agile approaches to requirements via the User Story
A User Story isn't a requirement, but many people use them in lieu of requirements. What they are missing is that the requirements are often in this context transmitted orally or in temporary media.
Elicitation and analysis v discovery
Some groups such as IIBA recommend distinguishing the elicitation and analysis of requirements. Others have a model where requirements are discovered - with elicitation and analysis conflated.
Test and validation
The continuing research that says requirements and testing should be tightly coupled, and industry's general failure to do this well or consistently.
Where does architecture fall into this model?
Project vs product
What is the difference between a project and product requirement and why do people get them confused? This is related to the multiple definitions of 'scope' in the project and product management world.
- I am concerned that the majority of these directions stray into process matters, ie Requirements engineering rather than Requirement, hence we are in danger of creating a content fork. All additions must be properly cited - most of the existing article could and maybe should be deleted for lack of sources. Chiswick Chap (talk) 14:34, 16 January 2012 (UTC)
- 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"
- 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)
- 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.
- Shouldn't a page about requirements be required to be cleaner? —Preceding unsigned comment added by 18.104.22.168 (talk) 03:15, 9 October 2010 (UTC)
--Abdull 19:39, 1 June 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)