Requirements Analysis Document

Purpose

The results of the requirements elicitation and the analysis activities are documented in the Requirements Analysis Document (RAD). This document completely describes the system in terms of functional and nonfunctional requirements and serves as a contractual basis between the customer and the developer. The RAD must be written in the language of the customer's domain of business/expertise. Under no circumstances should any "computerese" terminology creep into this document.

Audience

The audience for the RAD includes the customer, the users, the project management, the system analysts (i.e., the developers who participate in the requirements), and the system designers (i.e., the developers who participate in the system design). The first part of the document, including use cases and nonfunctional requirements, is written during requirements elicitation. The formalization of the specification in terms of object models is written during analysis. We use an example template for a RAD introduced in the book.

Template

Section/Topic Description
1. Introduction
    1.1 Purpose of the system
    1.2 Scope of the system
    1.3 Objectives and success criteria of the project
    1.4 Definitions, acronyms, and abbreviations
    1.5 References
    1.6 Overview
The first section of the RAD is an Introduction. Its purpose is to provide a brief overview of the function of the system and the reasons for its development, its scope, and references to the development context (e.g., reference to the problem statement written by the client, references to existing systems, feasibility studies). The introduction also includes the objectives and success criteria of the project.
 
2. Current system The second section, Current system, describes the current state of affairs. If the new system will replace an existing system, this section describes the functionality and the problems of the current system. Otherwise, this section describes how the tasks supported by the new system are accomplished now.
 
3. Proposed system The third section documents the requirements elicitation and the analysis model of the new system.
 
    3.1 Overview The overview presents a functional overview of the system.
 
    3.2 Functional requirements ("shall lists")
        3.2.1
        3.2.2
        3.2.3
        3.2.4
Functional requirements describes the high-level functionality of the system.
 
    3.3 Nonfunctional requirements
        3.3.1 Usability
        3.3.2 Reliability
        3.3.3 Performance
        3.3.4 Supportability
        3.3.5 Implementation
        3.3.6 Interface
        3.3.7 Packaging
        3.3.8 Legal
Nonfunctional requirements describes user-level requirements that are not directly related to functionality. This includes usability, reliability, performance, supportability, implementation, interface, operational, packaging, and legal requirements.
 
    3.4 System models
        3.4.1 Scenarios
        3.4.2 Use case model
        3.4.3 Analysis object model
        3.4.4 Dynamic model
        3.4.5 User interface—navigational paths and screen mock-ups
System models describes the scenarios, use cases, object model, and dynamic models for the system. This section contains the complete functional specification, including mock-ups illustrating the user interface of the system and navigational paths representing the sequence of screens. The subsections Object model and Dynamic model are written during the Analysis activity.
 
4. Glossary A glossary of important terms, to ensure consistency in the specification and to ensure that we use the client’s terms. A precurser to the Data Dictionary

Revised from various documents Copyright assigned to public