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 non-functional 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.
Template
Section/Topic
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
Description
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 Functional requirements describes the
high-level functionality of the system.
lists")
3.2.1 (Input and Output
Requirements)
3.2.2
3.2.3
3.2.4
3.3 Non-functional 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, and 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.3.1 Data dictionary
3.4.3.2 Class Diagrams
3.4.4 Dynamic models
3.4.5 User interface navigational
paths and screen mock-ups
System models describe 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 clients terms. A
precurser to the Data Dictionary
For Requirement Analysis Document -Refer Page Numbers-- 152 and 200
Requirement Analysis Case Study (Example)—ARENA CASE STUDY –Page number 152 to 157
2 System Design Document
2.1. Introduction
2.1.1 Purpose of the system
2.1.2 Design Goals
2.1.3 Definitions, acronyms, and abbreviations
2.1.5 References
2.1.6 Overview
2.2. Current System Architecture
2.3. Proposed Software Architecture
2.3.1 Overview
2.3.2 Subsystem Decomposition
2.3.3 Hardware/Software Mapping
2.3.4 Persistent data mapping
2.3.5 Access control and Security
2.3.6 Global Software Control
2.3.7 Boundary Conditions
2.4. Subsystem services
Glossary
For Object Design Document ---Refer page number -376
Object Design Document Case Study(Example) – ARENA CASE STUDY Refer Page
Numbers – 380 to 385
3. Object Design Document
3.1 Introduction
3.1.1.Object design trade –offs
3.1.2 Interface document guidelines
3.1.3 Definitions, acronyms, and abbreviations
3.1.4 References
3.2 Packages
3.3 Class Interfaces
Glossary
For Object Design Document ---Refer page number -376
4.Testing
4.1 Component Inspection
4.2 Usability
4.3 Unit Testing
4.4 Integration Testing
4.5 System Testing
5. Screens
6. Reports
7. Bibliography
Assessments
First Assessment------50 Marks (Guide and AMC will assign Marks)
Second Assessment ---50 Marks (Guide and AMC will assign Marks)
Third Assessment -----50 Marks (Guide and AMC will assign Marks)
Fourth Assessment ----50 Marks (External Examiner will assign Marks )
Important Dates
Submission of Abstract and Front end and Back end details to your guide on or before
10th January 2022
First Review Date(Tentative Date)—First week of February 2021
Second Review Date (Tentative Date)—First week of March 2021
Third Review Date(Tentative Date)—First week of April 2021
Contents Required for First Review –Requirement Analysis Document
--System Design Document
Contents Required for Second Review—Object Design Document
--- Some portion of Coding
Contents Required for Third Review—Live Execution of project code
Reference Book: Object Oriented Software Engineering
Using UML ,Patterns ,Java Second Edition
by Bernd Bruegge Allen H.Dutoit
Note: If a particular concept is not applicable to your project please ignore that component
and Change the numbering accordingly