University of Maryland

Division of Information technology

Application and IT Governance Name: xxxxxxxxxx

Requirements Document

PRJ-xxxxx, Project Name: xxxxxxxxx

Deliverable Due Date: mm/dd/yy — Revision x

University of Maryland

Division of Information Technology

Requirements Document

Application and IT Governance Name: xxxx/xxx

Project Name: xxxxxxxxx

Project Number: PRJ-xxxx

Revision 0

SIGN-OFF

Based on my review and in accordance with the requirements as set forth by the University of Maryland - Divisionof Information Technology I, by my authority, have issued the following approval of the referenced deliverable:

______Approved

______

DIT ApproverDate

Revision History

[The version number on the cover page, in the header, and the last entry in the Revision History table must always match. The initial version number is always 0 just as the template is set up. Once delivered, increase by whole numbers for major versions and increase by .1 for minor changes. When there is more than one author, the authors’ names are separated by a slash “/.”]

Version Number / Date / Description / Author
[0] / [mm/dd/yyyy] / [Details regarding changes made to document, including section(s) and paragraph(s) affected.] / [First and Last Name]

[Text that is blue and enclosed in square brackets indicates sample information, instructions or requests for information. The purpose of blue text is to help the author complete a document. The author removes the square brackets and blue text during the document’s development.]

Table of Contents

1.Introduction

1.1Purpose

1.2Scope

1.3References

2.Requirements

2.1Functional Requirements

2.2Hardware and Software Requirements

2.3Non-Functional Requirements

3.Glossary

4.Attachments, Minutes and Process Flow

List of Tables

Table 1: Functional Requirements

Table 2: Hardware and Software Requirements

Table 3: Non-Functional Requirements

  1. Introduction
  2. Purpose

The purpose of this document is to provide a comprehensive description of the requirements for <Initiative Name or Project Name>. This includes defining and documenting the following:

  • Business functional requirements
  • Hardware/infrastructure requirements
  • Non-functional requirements
  • Scope

[Reference the Scope Statement document for this section as well as for assumptions, dependencies, and constraints.]

Enter text here …

1.3References

[List all the documents and other materials referenced in this document. For example Analysis Paper, SDLC Deliverables, Technical Review Assessment, New Project & Enhancement Request form, etc.]

Enter text here …

  1. Requirements
  2. Functional Requirements

[Describe in detail what the application must do to fulfill the business requirements. Functional Requirements begin with "The system shall…" and each should be an unambiguous, testable and verifiable statement.

Indicate the requirement type:

  • Input - Indicates how information will be entered and modified in the system.
  • Output - Indicates what will be produced by the system, e.g. files, reports, queries, etc.
  • Logical Process - Describes the logic used inside the processes to manipulate data, e.g. business rules and calculations
  • Data Conversion - Describes the requirements of the conversion effort. the details of identifying, selecting, and converting data from the old application to the new application.
  • Interface - Specifies the logical characteristics of each interface between the application and other hardware, software, and communication protocols. Describes the purpose of the interface, the interchange mechanism, the internal or external system being interfaced to/with
  • Security – Describes any security considerations for accessing or changing data and any factors that will be added or changed to protect the software from misuse or modification such as cryptography or activity logging.
  • Other - Any additional requirements that do not fit in the preceding requirement types, including the need for 508 compliance to be met for any changes being made

Table 1: Functional Requirements

Req # / Req Type
Input, Output, logical process, Data conversion, Interface,Security, Other / Requirement Description / Technical Reference**
1 / Input / The system shall provide data validation to ensure that all required data has been entered.
2 / Output / The system shall support printing on local printers.
3 / Logical / The system shall calculate the amount of child support payments as a percentage of NCP’s salary
4 / Data Conversion / The system shall provide the ability to perform a bulk transfer of data prior to production processing.
5 / Interfaces / The system shall process and store information received from ABC system on the XYZ file.

**Technical Reference information will not be completed at submission of the Requirements Document deliverable

2.2Hardware and Software Requirements

[This section defines the hardware, system software, network and telecommunications, storage, and other configurations to which the architectural design, development, and implementation must conform. Include any unique disaster recovery considerations. ]

Example of Hardware/Software Requirements table:

Table 2: Hardware and Software Requirements

Req # / Requirement Description
1 / Provide support for 640 X 480 resolution monitors for web-based data retrieval
2 / Provide support for Microsoft Visual Studio 2005

2.3
Non-Functional Requirements

[Specify any additional non-functional requirements for the initiative that will be important to either the clients or the developers. For example, 'system must be available 97% of the time and handle 100,000 transactions per day'). The following are examples of non-functional requirements:

  • Training – Indicates specific training expectations (train-the-trainer, reference materials, user guides, etc.)
  • Availability – when the system is available for use (include when maintenance will be performed)
  • Performance - Specify the throughput, maximum number of users, response times, maximum workloads, and other performance characteristics of a system.
  • Reusability – extent to which software and associated artifacts can be reused in another application
  • Usability – effort required to learn, operate, prepare input, and interpret output

Example of Non-functional Requirements table:

Table 3: Non-Functional Requirements

Req # / Requirement Description
1 / The system shall be available from 7:00 am to 7:00 pm Monday-Saturday.
2 / The system administrator manual will be updated to reflect changes

  1. Glossary

[List all terms and acronyms used in the document and their corresponding definitions]

Term/Acronym / Definition
  1. Attachments, Minutes and Process Flow

[Include attachments, if applicable.]

Enter text here …

DIT_Requirements_Document_Template (2)Page 1 of 9

Date last modified: 5/20/2016