Requirements Analysis Document[Insert Product Name Here in Header]

CptS323

Requirements Analysis Document

Format and Content Guide

What follows is a specification of the format and content of an acceptable Requirements Analysis Document for CptS323.

All sections specified in this guide (except the sections labeled as “[not required]”) must be included in your document, with content as described herein.

Font size, document layout/format, section numbering, and section headings must be as described herein.

Items and/or notes shown in square brackets, i.e. […], must be replaced with appropriate content (brackets omitted).

Instructions, examples, etc, shown in this guide should NOT appear in your document.

Each major section (1, 2, 3, …) must begin on new page.

[Insert date of this version in footer][page #][Insert team name in footer]

Requirements Analysis Document[Insert Product Name Here in Header]

Requirements Analysis Document

for

<Project>

Team: [Insert Team Name]

Project: [Insert Project Name]

Team Members:
[Insert Member 1 Name]

[Insert Member 2 Name]

[Insert Member 3 Name]

[etc.]

Last Updated: [Date and time of this document version goes here]

Table of Contents

[Update the Table of Contents]

Table of Contents

Document Revision History

List of Figures

List of Tables

1. Introduction

1.1Purpose of the System

1.2Audiences and Goals

1.3Scope

1.4Definitions and References

2. Proposed System

2.1 Overview

2.2 Functional Requirements [not required]

2.2 Nonfunctional Requirements [not required]

2.4 System Models

Document Revision History

Revision Number / Revision Date / Description / Rationale


List of Figures

Figure # TitlePage #

S-xTitle of Figure S-x goes here#

S-yTitle of Figure S-y goes here#

(etc.)


List of Tables

Figure # TitlePage #

1Title of Table 1 goes here#

2Title of Table 2 goes here#

(etc.)


1. Introduction

[Write a brief description of your product here.]

1.1Purposeof the System

[Provide a brief overview of the function of the system]

1.2Audiences and Goals

[First, write a brief summarization of the goal of this document.

Then, list out the intended readers of this document, i.e., the users of your product, developers, managers, etc. And explain how they are expected to use the document. Refer to Section 5 of the text book for more information.

The audience for the Requirements Analysis Document 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).]

1.3Scope

Simply list the sections included in this document. i.e.

Section 2 includes …

Section 3 includes …

1.4Definitions and References

Put any necessary definitions, acronyms, abbreviations, references here.

2. Proposed System

[This section documents the requirements elicitation and the analysis model of the new system]

2.1 Overview

[Provide an overview of the analysis activities including: building the object model (class diagrams) and dynamic model (sequence, state machine and activity diagrams). You don’t need to describe the refinement of use cases.]

2.2 Functional Requirements[not required]

[Functional requirements describes the high-level functionality of the system]

2.3 Nonfunctional Requirements [not required]

[Nonfunctional requirements describe user-level requirements that are not directly related to functionality. This includes usability, reliability, performance, supportability, implementation, interface, operational, packaging, and legal requirements.]

2.4 System Models

2.4.1 Scenarios [not required]

[Provide scenario descriptions]

2.4.2 Use case model [not required]

[Provide UML use case model]

2.4.3 Object Model

[Provide the detailed descriptions for the objects identified in use cases. For each object provide a very brief textual description and its attributes and operations (You may need to revise your object definitions and add more operations/attributes after you draw the sequence diagrams).

Also provide find the associations between the classes and draw the class diagrams.

In phase two (Software Design Document) , you’ll be asked to refine your class diagrams and organize them into several subsystems (packages), each of which will have its own elaborated class diagram.]

2.4.4 Dynamic Model

[This section document the behavior of the object model in terms of state machine diagrams, sequence diagrams, and activity diagrams.

  1. Provide the sequence diagrams for at least 3major use cases (provide at least 3 diagrams).
  2. Provide the activity diagrams for 2major use cases (select 2 of the use cases that you chose in 1).
  3. Provide the state machine diagrams forat least2 major classes(provide at least 2 diagrams). Note that, it is not necessary to build state machines for every class in the system. Only objects with an extended lifespan and state-dependent behavior are worth considering.

[Insert date of this version in footer][page #][Insert team name in footer]