Chair for Applied Software Engineering Lehrstuhl für Angewandte Softwaretechnik

Home  |  Home  |  Changes  |  Index  |  Search Prentice Hall  |  Pearson UK  |  Pearson Studium  |  Search

Requirements Analysis Document Template

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 client and the developers.

Audience

The audience for the RAD includes the client, 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

Outline 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 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 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.

Related Topics

 

OOSE: RequirementsAnalysisDocumentTemplate .
Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History:  | More topic actions
r0 - 30 Sep 2003 - 16:20:44 - TimoWolf
Copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding the website? Send feedback