need to make a Functional Requirements Specification document for my system engineering project "RFID tags with phone applications ". I already finished doing the scopedocument and system requirements specification which will be attached below to have an

profileMichelle_Michy
functionalrequirementsspecification.docx

XYZ System Documentation

Functional Requirements Document Template

[subtitle]

Author: Judy McManus

Document Date: 04/10/2008

Version 1.1

© 2016

XYZ Company [logo]

Table of Contents

1 Introduction 4

2 Current System Summary 5

3 Functional Requirements 6

4 Use Case 8

List of Figures

Figure 51: Generic Context Diagram 7

Figure 52: Sample Requirements Group 1 7

Introduction

[Provide an overview of the system and some additional information to put the system in context.]

Purpose

[Provide an overall description of the Functional Requirements Document (FRD) and its purpose. Reference the system name and identifying information about the system to be implemented.]

Scope

[Discuss the scope of the document and how it accomplishes its purpose.]

Background

[Describe the organization and its overall responsibilities. Describe who is producing the document and why.]

Project References

[List references and controlling documents, including: meeting summaries, white papers, other deliverables, etc.]

Assumptions and Constraints

[Provide a list of contractual or task level assumptions and/or constraints that are preconditions to preparation of the FRD. Assumptions are future situations beyond the control of the project, whose outcomes influence the success of the project.

Describe any assumptions and constraints that will affect development and operation of the system. Identify any limitations affecting the desired capability, any desired capabilities that will not be provided by the proposed system, as well as any anticipated operational changes that will affect the proposed operation of the system.]

Assumptions

Examples of assumptions include: availability of a technical platform, legal changes and policy decisions.

Constraints

Constraints are boundary conditions on how the system must be designed and constructed. Examples include: legal requirements, technical standards, strategic decisions.

Constraints exist because of real business conditions. For example, a delivery date is a constraint only if there are real business consequences that will happen as a result of not meeting the date. If failing to have the subject application operational by the specified date places the organization in legal default, the date is a constraint.

Preferences are arbitrary. For example, a date chosen arbitrarily is a preference. Preferences, if included in the FRD, should be noted as such.

Document Overview

[Provide a description of the document organization.]

Current System Summary

This section describes (in non-computer-oriented language) the existing system functions to establish a context for the proposed system. If the existing system is a manual process, describe that.

Background

Provide background information concerning the uses and purposes of the current system. Refer to interfacing systems when needed to enhance the general description.

System Objectives and Current Functionality

State the major requirements and goals of the current system. These statements should be concise, quantified if possible, and may include examples. When applicable, related events may be discussed.

Provide an explanation of how the current system interacts with the functional processing supported. Identify products from other systems used with the current system.

Current Methods and Procedures

Briefly describe the current methods and procedures being employed to satisfy the existing information requirements. Provide a graphic representation that depicts the existing data flow through the functional system from data acquisition through its processing and eventual output. The graphic may be complimented by a narrative explanation of the sequence in which the user performs the operational functions. Include in your explanation the information requested in the following subsections.

Equipment Being Used

Discuss equipment being used.

Input and Output

Discuss input and output, including volume and frequency.

Provide a general description of each of the batch and online inputs and outputs. Include information regarding the following:

Reports and queries to be generated by the system

Interfaces to other systems

Online input, including data from presently used manual forms

Provisions in the Existing System Design

Discuss provisions in the existing system design, including operation in degraded modes or at alternate sites in the event of emergency, disaster, or accident.

Deficiencies

Discuss deficiencies, including limitations, such as time delays.

Functional Requirements

Context

[Provide a context diagram of the system, with explanations as applicable. The context of a system refers to the connections and relationships between the system and its environment.]

Figure 51: Generic Context Diagram

Functional Analysis and Allocation

[Decompose the top-level system functional flow block diagram to second-level functions, third-level functions, and etc.]

Functional Requirements

[List the functional requirements of the system.]

Functional Requirements Group 1

[List the functional requirements for each functional requirements group. Here you will be breaking down your Type A functional requirements into Type B hardware and software requirements.]

Section/ Requirement ID

Requirement Definition

FR1.0.

The system shall [parent requirement group 1].

FR1.1

The system shall [child/parent requirement].

FR1.1.1

The system shall [child requirement].

FR1.1.2

The system shall [child requirement].

Figure 52: Sample Requirements Group 1

Functional Requirements Group 2, etc.

[same]

Use Case

[Provide a use case diagram of your project and a fully dressed use case here. You should include in the fully dressed use case the following: brief description of use case, name of use case, primary actor(s), assumptions, preconditions, main success scenario (MSS), adverse conditions, extensions/alternative scenarios, functional requirements derived from use case, nonfunctional requirements derived from use case, and post-conditions.]

Glossary

[Define terms, acronyms, and abbreviations used in the FRD.]

malware Malware (for "malicious software") is any program or file that is harmful to a computer user. Thus, malware includes computer viruses, worms, Trojan horses, and also spyware, programming that gathers information about a computer user without permission. Source: www.whatis.com

Revision History

The Revision History lists all versions of the Functional Requirements Document Template:

Date

Version

Author/SME

Description

04/10/2008

1.0

Judy McManus

Created from www.jiludwig.com and www.hud.gov.

1.1

Adapted for general use. Note that not all headings may apply; delete as required.

Data 6

Data 1

Data 3

Data 4

Data 7

Data 2

Data 8

System/

Application

Name

Interface

Name 2

Interface

Name 4

Interface

Name 1

(User)

Interface

Name 3

Data 5