Requirements Analysis

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 RequirementAnalysis (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