The process (often performed by a
SystemAnalyst) that occurs between the gathering of
UserRequirements and the delivery of the
RequirementsSpecification. If performed by a
SystemAnalyst,
BusinessSystemsAnalyst or
BusinessAnalyst, the process typically occurs at the same time as
RequirementsGathering, as skillful questioning is used to 'clarify' the
BusinessRequirements (i.e. iteratively and collaboratively formulate them in a process that is sometimes modestly and diplomatically described as 'understanding' the requirements). Further analysis may then occur in the process described as 'documenting' or 'communicating' the requirements.
Some people would maintain that
RequirementsAnalysis can involve early prototyping,
StrategicPlanning, and
RiskManagement.
From Requirement
Analysis
(Page to be deleted; content to be refactored)
Requirements are what the customer explicitly declares as
the system must do this.
In most projects, such things are generally few and far between. Much of what gets labeled as a requirement really is not. It's a term that has been abused for so long people have forgotten what it was supposed to mean.
Analysis is about reading, understanding, finding out, making clear something, without adding anything that is not already included, but possibly removing unneeded, unwanted or contradicting ideas.
RequirementsAnalysis is when requirements are analyzed so that not too much time/effort/money is spent trying to implement something that is ill conceived.
The next step after
RequirementsAnalysis,
SoftwareDesign, is about finding a solution for the requirements.
CategoryRequirements CategoryAnalysis CategoryPlanning