Editing Requirements analysis (section)

=== Contract-style requirement lists ===
One traditional way of documenting requirements has been contract-style requirement lists. In a complex system such requirements lists can run hundreds of pages long.

An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favor in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims{{citation needed|date=July 2019}}; but they are still seen to this day.

====Strengths====

* Provides a checklist of requirements.
* Provide a contract between the project sponsor(s) and developers.
* For a large system can provide a high level description from which lower-level requirements can be derived.

====Weaknesses====

* Such lists can run to hundreds of pages. They are not intended to serve as a reader-friendly description of the desired application.
* Such requirements lists abstract all the requirements and so there is little context. The Business Analyst may include context for requirements in accompanying design documentation.
** This abstraction is not intended to describe how the requirements fit or work together.
** The list may not reflect relationships and dependencies between requirements. While a list does make it easy to prioritize each item, removing one item out of context can render an entire use case or business requirement useless.
** The list does not supplant the need to review requirements carefully with stakeholders to gain a better-shared understanding of the implications for the design of the desired system/application.
* Simply creating a list does not guarantee its completeness. The Business Analyst must make a good faith effort to discover and collect a substantially comprehensive list and rely on stakeholders to point out missing requirements.
* These lists can create a false sense of mutual understanding between the stakeholders and developers; Business Analysts are critical to the translation process.
* It is almost impossible to uncover all the functional requirements before the process of development and testing begins. If these lists are treated as an immutable contract, then requirements that emerge in the Development process may generate a controversial change request.

====Alternative to requirement lists====

As an alternative to requirement lists, [[Agile software development|Agile Software Development]] uses [[User stories]] to suggest requirements in everyday language.