Editing Requirements analysis (section)

== Requirements analysis topics ==
{{unreferenced section|date=October 2009}}

=== Stakeholder identification ===
See [[Stakeholder analysis]] for a discussion of people or organizations (legal entities such as companies, and standards bodies) that have a valid interest in the system. They may be affected by it either directly or indirectly.

A major new emphasis in the 1990s was a focus on the identification of ''stakeholders''. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:
* anyone who operates the system (normal and maintenance operators)
* anyone who benefits from the system (functional, political, financial, and social beneficiaries)
* anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing, and sometimes sales act as surrogate consumers (mass-market customers) to guide the development of the product.
* organizations that regulate aspects of the system (financial, safety, and other regulators)
* people or organizations opposed to the system (negative stakeholders; see also [[Misuse case]])
* organizations responsible for systems that interface with the system under design.
* those organizations that [[horizontal integration|integrate horizontally]] with the organization for whom the analyst is designing the system.

=== Joint Requirements Development (JRD) Sessions ===
Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained [[facilitator]] (Business Analyst), wherein stakeholders participate in discussions to elicit requirements, analyze their details, and uncover cross-functional implications. A dedicated scribe should be present to document the discussion, freeing up the Business Analyst to lead the discussion in a direction that generates appropriate requirements that meet the session objective.

JRD Sessions are analogous to [[Joint application design|Joint Application Design]] Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements.

=== 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.

=== Measurable goals ===
{{main|Goal modeling}}
Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, [[Software prototyping#Throwaway prototyping|rapid prototyping]] and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.

===Prototypes===

{{main|Software prototyping}}

A prototype is a computer program that exhibits a part of the properties of another computer program, allowing users to visualize an application that has not yet been constructed. A popular form of prototype is a [[mockup]], which helps future users and other stakeholders get an idea of what the system will look like. Prototypes make it easier to make design decisions because aspects of the application can be seen and shared before the application is built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably. {{Citation needed|date=December 2011}}

Prototypes can be flat diagrams (often referred to as [[Wire-frame model|wireframes]]) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have a [[graphic design]] applied to it. This helps to prevent confusion as to whether the prototype represents the final visual look and feel of the application. {{Citation needed|date=December 2011}}

===Use cases===
{{main|Use case}}
A use case is a structure for documenting the functional requirements for a system, usually involving software, whether that is new or being changed. Each use case provides a set of ''scenarios'' that convey how the system should interact with a human user or another system, to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the [[end-user]] or ''[[domain expert]]''. Use cases are often co-authored by requirements engineers and stakeholders.

Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of how users are intended to work with the software or system. Use cases should not describe the internal workings of the system, nor should they explain how that system will be implemented. Instead, they show the steps needed to perform a task without sequential assumptions.

===Requirements specification===
{{Main article | Requirements specification}}
{{Expand section|date=February 2018}}
Requirements specification is the synthesis of discovery findings regarding current state business needs and the assessment of these needs to determine, and specify, what is required to meet the needs within the solution scope in focus. Discovery, analysis, and specification move the understanding from a current as-is state to a future to-be state. Requirements specification can cover the full breadth and depth of the future state to be realized, or it could target specific gaps to fill, such as priority software system bugs to fix and enhancements to make. Given that any large business process almost always employs software and data systems and technology, requirements specification is often associated with software system builds, purchases, cloud computing strategies, embedded software in products or devices, or other technologies. The broader definition of requirements specification includes or focuses on any solution strategy or component, such as training, documentation guides, personnel, marketing strategies, equipment, supplies, etc.