Scribd
Upload
37 views2 pages

Requirements Analysis Document: Purpose

The Requirements Analysis Document (RAD) describes the system requirements based on elicitation activities with the customer. It serves as the contractual basis between the customer and developer. The RAD contains an introduction, description of the current system, overview of the proposed system, functional and non-functional requirements, system models including use cases and interface mockups, and a glossary. It is written in the customer's domain language without technical terms.

Uploaded by

Srinivas Avrdy
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
37 views2 pages

Requirements Analysis Document: Purpose

The Requirements Analysis Document (RAD) describes the system requirements based on elicitation activities with the customer. It serves as the contractual basis between the customer and developer. The RAD contains an introduction, description of the current system, overview of the proposed system, functional and non-functional requirements, system models including use cases and interface mockups, and a glossary. It is written in the customer's domain language without technical terms.

Uploaded by

Srinivas Avrdy
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

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 The first section of the RAD is an 1.1 Purpose of the system Introduction. Its purpose is to provide a 1.2 Scope of the system brief overview of the function of the system 1.3 Objectives and success criteria of the and the reasons for its development, its project scope, and references to the development 1.4 Definitions, acronyms, and context (e.g., reference to the problem abbreviations statement written by the client, references 1.5 References to existing systems, feasibility studies). 1.6 Overview 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. The third section documents the requirements elicitation and the analysis model of the new system.

3. Proposed system

3.1 Overview

The overview presents a functional overview of the system. Functional requirements describes the high-level functionality of the system.

3.2 Functional requirements ("shall lists") 3.2.1 3.2.2 3.2.3 3.2.4 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 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 interfacenavigational paths and screen mock-ups

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.

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. A glossary of important terms, to ensure consistency in the specification and to ensure that we use the clients terms. A precurser to the Data Dictionary

4. Glossary

Revised from various documents

You might also like