Talk:Requirement/Archives/2015

Suggestions

Specific points for improvement

Proposed Deletions

• Remove many of the in-test hyper links to make the site more readable. Add the topics to the "See Also" section

Proposed modifications

• 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 :)
• Inconsistency: In Characteristics, Unitary overlaps with Atomic. Modelpractice (talk) 10:52, 15 July 2015 (UTC)

Proposed Additions

• 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.)

Structural improvement

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)

Definition

IEEE, IIBA, SWEBOK, etc definitions. Possibly in a table form to show the similarities and differences.

Attributes

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

Contention

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.

Architecture

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.

Craigwbrown (talk) 11:40, 16 January 2012 (UTC)

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)

Agree the pages should be short and focused. Can you nominate which sections above should be deleted? (Just delete them.) Also - any suggestions for what should go on the topic page? — Preceding unsigned comment added by Craigwbrown (talk • contribs) 21:44, 16 January 2012 (UTC)