Requirements analysis
[3] The requirements should be documented, actionable, measurable, testable,[4] traceable,[4] related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
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.
[5][6] Requirements quality can be improved through these and other methods: 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.
Such lists are very much out of favor in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims[citation needed]; but they are still seen to this day.
Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.
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.
[citation needed] Prototypes can be flat diagrams (often referred to as wireframes) or working applications using synthesized functionality.
[citation needed] A use case is a structure for documenting the functional requirements for a system, usually involving software, whether that is new or being changed.
Use cases typically avoid technical jargon, preferring instead the language of the end-user or domain expert.
The following are common categorizations of requirements that relate to technical management:[1] Statements of business level goals, without reference to detailed functionality.
Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS).
The extent to which a mission or function must be executed; is generally measured in terms of quantity, quality, coverage, timeliness, or readiness.
Techniques introduced in the 1990s like prototyping, Unified Modeling Language (UML), use cases, and agile software development are also intended as solutions to problems encountered with previous methods.
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.
