Requirements Document

for Actuate Report

[Enter San# & Short Description]

for

[Enter Project/Client]

Version [#], [draft#/approved]

Created by [Author]

[Date Created]

Cayenta Municipal & Utility Solutions

Table Of Contents

1.  Introduction  3

1.1.  Overview  3

1.2.  References  3

2.  Customer Requirements  3

2.1.  Purpose and Scope  4

2.1  Client Design and Implementation Constraints  4

2.2  Client Performance Requirements  4

2.3  Perceived Business Risks  4

2.4  Audience  4

2.5  Initiation, Scheduling, Frequency  4

2.6  Retention and Archiving  4

3.  Layout Requirements  5

3.1  Report Layout  5

3.2  Report Input Parameters  6

3.3  Report Organization  6

3.4  Report Details: Section 1  6

3.5  Assumptions and Dependencies  7

Document Approval  8

Appendix A: Glossary  8

Appendix B: Analysis Models  8

Appendix C: To Be Determined List  8

Revision History  8

1.  Introduction

1.1.  Overview

[Provide a general description of the report. Describe the reports use and who uses it. Explain how the report is used to measure/analyse an area of business]

Product/Version/Patch Level for which report is required: [Enter System and version]

Actuate Version for which report is required:

Actuate 3  Actuate 4  Actuate 5  Actuate 7

Modification Components:  Interface     Reports

Issue Type:   P1    Go-Live   Funded  Cayenta Internal

Desired Availability Date:  [Enter Required by Date]

Interdependencies upon other modifications for this client:  Yes  No  

       [If yes, enter the SAN # and name of modifications]

Subject Area Expert (SAE) contact for client: [Enter Client contact name]

Subject Area Expert (SAE) for Cayenta: [Enter Cayenta contact]

1.2.  References

The following reference documents are available:

None

3^rd Party technical specification: file layout specifications

Client Contract document(s):

Standards document(s)

Use Case document(s)

Other (list): sample printed report

2.  Customer Requirements

[A description of the reasons why the report is required and what it will be used for.Also, provide information on what the customer expects from the report/interface. Provide information on work flow, process changes etc. here.]

2.1.  Purpose and Scope

[Provide a detailed description of the purpose or reasons behind the report and what it will be used for. Include background and value added to customer with the report]

2.1  Client Design and Implementation Constraints

[Describe any client requirements, such as selection of only a sub-set of data, any set up or configuration constraints]

2.2  Client Performance Requirements

[Provide guidelines for performance requirements. For example, for an aging report, the time frame that the report is run. ]

2.3  Perceived Business Risks

[Enter any known risks to the successful completion of the report, if any. For example, if the data is not currently stored, if tables are large. If none, Enter 'Not Applicable']

2.4  Audience

[Provide details of who will be viewing the report. This will 1 to 2 sentences long. E.g. if finance views the report monthly, and billing views the report daily, indicate this here.]

2.5  Initiation, Scheduling, Frequency

[Describe how the report will be executed, if the report will be scheduled and how often the report will be run. Also include information on whether the report will be printed via a process or menu option as well as any security issues]

2.6  Retention and Archiving

[Indicate how long the report must be kept on record, if at all. If the report must be accessible on the actuate server or if the report can be archived or purged on a regular basis.]

3.  Layout Requirements

[This section will provide the requirements for the actual report/interface. Delete this line when creating document.]

3.1  Report Layout

The following are sample layouts of the [Report Name]. Each component of the report will be described in section 3.4: Report Details.

[Create or insert a mock-up for each report section. To create a mock-up in landscape, insert a page break and re-orient the pages for landscape vs. portrait]

3.1.1  Report Section 1

[This is for the mock-up of section 1 of the report. This line should include a brief description of the section e.g. Details or Summary. For additional sections, copy and paste this section as many times as required.]

3.2  Report Input Parameters

3.2.1  Processing and Extract Logic

[Describe any selection criteria involved. Use pseudo code.]

3.3  Report Organization

This section describes how the report should be organized:

3.1.1  

3.4  Report Details: Section 1

This section describes each component of the report, in greater detail. The component # references the layout in Section 4.1.1 Report Layout-Section 1.

3.5  Assumptions and Dependencies

[Describe, in point form, any assumptions or dependencies for the report. E.g. The assumption is that there will only be one location per account.]

Document Approval

The signatures below indicate the approval of the functional requirements as detailed in this document. If approved, development, testing and sign off will take place on the basis of these requirements.

Accepted on behalf of:

Appendix A: Glossary

[Define all the terms necessary to properly interpret the BRD, including acronyms and abbreviations. If none, enter N/A] ]

Appendix B: Analysis Models

[Include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams. If none, enter N/A]

Appendix C: To Be Determined List

[Collect a numbered list of the TBD (to be determined) references that remain in the BRD so they can be tracked to closure. Please note, design and development will not commence until these have been resolved. If none, enter N/A] ]

Revision History