Editing Requirements analysis (section)

== Overview ==
Conceptually, requirements analysis includes three types of activities:{{Citation needed|date=February 2012}}
*[[Requirements elicitation|Eliciting requirements]]: (e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering or requirements discovery.
*Recording requirements: Requirements may be documented in various forms, usually including a summary list, and may include natural-language documents, [[use case]]s, [[User story|user stories]], [[process specification]]s, and a variety of models including data models.
*Analyzing requirements: determining whether the stated requirements are clear, complete, unduplicated, concise, valid, consistent and unambiguous, and resolving any apparent conflicts. Analyzing can also include sizing requirements.

Requirements analysis can be a long and tiring process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs, and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. These may include the development of scenarios (represented as [[User story|user stories]] in [[Agile software development|agile methods]]), the identification of [[use case]]s, the use of workplace observation or [[ethnography]], holding [[interview]]s, or [[focus group]]s (more aptly named in this context as requirements workshops, or requirements review sessions) and creating requirements lists. [[Prototyping]] may be used to develop an example system that can be demonstrated to stakeholders. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced.<ref>{{Cite journal |last=Amin |first=Tauqeer ul |last2=Shahzad |first2=Basit |date=2024-09-01 |title=Improving requirements elicitation in large-scale software projects with reduced customer engagement: a proposed cost-effective model |url=https://link.springer.com/article/10.1007/s00766-024-00425-2 |journal=Requirements Engineering |language=en |volume=29 |issue=3 |pages=403–418 |doi=10.1007/s00766-024-00425-2 |issn=1432-010X|url-access=subscription }}</ref><ref>{{Cite journal |last=Pacheco |first=Carla |last2=García |first2=Ivan |last3=Reyes |first3=Miryam |date=August 2018 |title=Requirements elicitation techniques: a systematic literature review based on the maturity of the techniques |url=https://onlinelibrary.wiley.com/doi/10.1049/iet-sen.2017.0144 |journal=IET Software |language=en |volume=12 |issue=4 |pages=365–378 |doi=10.1049/iet-sen.2017.0144 |issn=1751-8806|url-access=subscription }}</ref> Requirements quality can be improved through these and other methods:
* Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
* Consistent use of templates. Producing a consistent set of models and templates to document the requirements.
* Documenting [[dependency (project management)|dependencies]]. Documenting dependencies and interrelationships among requirements, as well as any assumptions and congregations.