Requirements Analysis Document (RAD)

This document takes the URD as a starting point and looks at the problem from a designer’s point of view. However, instead of diving directly to implementation details, the analysis focuses on the system and software requirements needed to implement the user requirements. This document gets detailed, but does not delve into programming details. Instead, take the user’s requirements and clearly identify all of the details and mitigating factors that will affect the solution that the user wants. An analysis may indicate a preference for a particular programming language that best suits the problem domain rather than an algorithm to satisfy a particular requirement. The RAD looks at the URD as defining an entire system, and then breaks the URD down into bite-size chunks (divide and conquer). These chunks identify the subsystems of the overall solution, and the relationships between them. But the RAD also goes further and identifies the actual details of the problem that the user may not be aware of.

The RAD also maps the domain of software systems onto the user requirements. For example, the RAD may indicate that a database is needed for a particular subsystem, or that an expert system can satisfy certain other requirements. The RAD is written from the designer’s perspective. An astute software designer is one who is aware of available software systems and paradigms. He/she should know what types of systems and solutions work best in different environments. The RAD, then, identifies the software systems and paradigms that will best fit the user requirements. The RAD doesn’t design a solution; it merely identifies the most beneficial means for an implementation.

 

The RAD has:

  •  designer’s interpretation of the user’s requirements: identify the “real” problem(s)
  •  breakdown the problem into high level constituent parts
  •  deep analysis of these parts and identification of all relevant details
  •  identify existing solutions
  •  identify alternative technical solutions
  •  link these solutions to the problem(s), especially with respect to details
  •  suggest the best solution and break it into parts
  •  devise ways to test the solution

The RAD does not have:

  •  user’s point of view
  •  implementation details
  •  algorithms
  •  user interface specification