Editing Requirement (section)

== Issues ==

=== Competing standards ===
There are several competing views of what requirements are and how they should be managed and used.  Two leading bodies in the industry are the IEEE and the IIBA.  Both of these groups have different but similar definitions of what a requirement is.

=== Disputes regarding the necessity and effects of software requirements ===
Many projects have succeeded with little or no agreement on requirements.<ref>{{cite book|last1=Checkland|first1=Peter|title=System Thinking, System Practice|date=1999|publisher=Wiley|location=Chichester}}</ref> Some evidence furthermore indicates that specifying requirements can decrease [[creativity]] and design performance <ref>
{{cite conference | url = https://www.researchgate.net/publication/272793687 | title = Is Requirements Engineering Inherently Counterproductive? | last1=Ralph|first1=Paul|last2=Mohanani|first2=Rahul| date = May 2015 | publisher = IEEE | book-title = Proceedings of the 5th International Workshop on the Twin Peaks of Requirements and Architecture
| pages = 20–23 | location = Florence, Italy }}</ref> Requirements hinder creativity and design because designers become overly preoccupied with provided information.<ref>{{cite journal|last1=Jansson|first1=D.|last2=Smith|first2=S.|title=Design fixation|journal=Design Studies|date=1991|volume=12|issue=1|pages=3–11|doi=10.1016/0142-694X(91)90003-F}}</ref><ref>{{cite journal|last1=Purcell|first1=A.|last2=Gero|first2=J.|title=Design and other types of fixation|journal=Design Studies|date=1996|volume=17|issue=4|pages=363–383|doi=10.1016/S0142-694X(96)00023-3}}</ref><ref>
{{cite conference | url = https://www.researchgate.net/publication/265416695 | title = Requirements Fixation | last1=Mohanani|first1=Rahul|last2=Ralph|first2=Paul|last3=Shreeve|first3=Ben
| date = May 2014 | publisher = IEEE | book-title = Proceedings of the International Conference on Software Engineering | pages = 895–906 | location = Hyderabad, India}}</ref> More generally, some research suggests that software requirements are an [[illusion]] created by misrepresenting design decisions as requirements in situations where no real requirements are evident.<ref>{{cite journal|last=Ralph|first=Paul|title=The Illusion of Requirements in Software Development|journal=Requirements Engineering|volume=18|issue=3|pages=293–296|year=2012|doi=10.1007/s00766-012-0161-4|arxiv=1304.0116|s2cid=11499083}}</ref>

Meanwhile, most [[agile software development]] methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead, [[extreme programming]] for example describes requirements informally using [[user story|user stories]] (short summaries fitting on an index card explaining one aspect of what the system should do), and considers it the developer's duty to directly ask the customer for clarification. Agile methodologies attempt to capture requirements in a series of automated [[acceptance test]]s.

=== Requirements creep ===
[[Scope creep]] may occur from requirements moving over time.  In [[Requirements management]] the alteration of requirements is allowed but if not adequately tracked or preceding steps (business goals then user requirements) are not throttled by additional oversight or handled as a cost and potential program failure, then requirements changes are easy and likely to happen.  It is easy for requirement changes to occur faster than developers are able to produce work, and the effort to go ''backwards'' as a result.

=== Multiple requirements taxonomies ===
There are multiple taxonomies for requirements depending on which framework one is operating under.  (For example, the stated standards of IEEE, vice IIBA or U.S. DoD approaches).  Differing language and processes in different venues or casual speech can cause confusion and deviation from desired process.

=== Process corruptions ===
A process being run by humans is subject to human flaws in governance, where convenience or desires or politics may lead to exceptions or outright subversion of the process and deviations from the textbook way the process is supposed to proceed.  Examples include:

* Process with no rigor gets no respect - If exceptions or changes are common, such as the organization running it having little independence or power or not being reliable and transparent in records, it may lead to the overall process being ignored.
* New players wanting a do-over - e.g., The natural tendency of new people to want to change their predecessor's work to demonstrate their power or claims of value, such as a new CEO wanting to change the previous CEO's planning, including business goals, of something (such as a software solution) already in development, or a newly created office objects to current development of a project because they did not exist when user requirements were crafted, so they begin an effort to backtrack and re-baseline the project.
* Coloring outside the lines - e.g., Users wanting more control do not just input things that meet the requirements management definition of "user requirement" or priority level, but insert design details or favored vendor characteristic as user requirements or everything their office says as the highest possible priority.
* Showing up late - e.g., Doing little or no effort in requirements elicitation prior to development.  This may be due to thinking they will get the same benefit regardless of individual participation, or that there is no point if they can just insert demands at the testing stage and next spin, or the preference to be always right by waiting for post-work critique.

Within the U.S. Department of Defense process, some historical examples of requirements issues are
* the M-2 Bradley issues of casual requirements movement portrayed in [[Pentagon Wars]];
* the F-16 growth from lightweight fighter concept of the [[Fighter mafia]], attributed to F-15 program attempting to sabotage competition or individual offices putting in local desires eroding the concept of being lightweight and low cost.
* enthusiasm ca. 1998 for 'Net-Ready' led to its mandate as Key Performance Parameter from the Net-Ready office, outside the office defining requirements process and not consistent to that office's previously defined process, their definition of what a KPP was, or that some efforts might not be appropriate or able to define what constituted 'Net-Ready'.