Editing Requirements analysis (section)

==Requirements analysis issues==

===Stakeholder issues===
Steve McConnell, in his book ''Rapid Development'', details a number of ways users can inhibit requirements gathering:
* Users do not understand what they want or users do not have a clear idea of their requirements
* Users will not commit to a set of written requirements
* Users insist on new requirements after the cost and schedule have been fixed
* Communication with users is slow
* Users often do not participate in reviews or are incapable of doing so
* Users are technically unsophisticated
* Users do not understand the development process
* Users do not know about present technology
This may lead to the situation where user requirements keep changing even when system or product development has been started.

===Engineer/developer issues===
Possible problems caused by engineers and developers during requirements analysis are:
* A natural inclination towards writing code can lead to implementation beginning before the requirements analysis is complete, potentially resulting in code changes to meet actual requirements once they are known.
* Technical personnel and end-users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied.
* Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.

===Attempted solutions===
One attempted solution to communications problems has been to employ specialists in business or system analysis.

Techniques introduced in the 1990s like [[Software prototyping|prototyping]], [[Unified Modeling Language]] (UML), [[use case]]s, and [[agile software development]] are also intended as solutions to problems encountered with previous methods.

Also, a new class of [[Application Simulation Software|application simulation]] or application definition tools has entered the market. These tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer:
* [[electronic whiteboard]]s to sketch application flows and test alternatives
* ability to capture business logic and data needs
* ability to generate high-fidelity prototypes that closely imitate the final application
* interactivity
* capability to add contextual requirements and other comments
* ability for remote and distributed users to run and interact with the simulation