Business Requirements Document

for Software Enhancements

<San# & Short Description>

for

<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.  Business Requirements  3

2.1.  Background & Purpose  3

2.2.  Value Provided to Customers  4

3.  Customer Requirements  4

3.2.  Perceived Business Risks  5

Appendix A: Glossary  6

Appendix B: Analysis Models  6

Appendix C: To Be Determined List  6

Revision History  6

Document Approval  7

1.  Introduction

1.1.  Overview

Product/Version/Patch Level for which modification required:

Modification Components: * Software Modification  * Interface             * Reports

Issue Type:  * P1  * Go-Live  * Funded  * Cayenta Internal

Desired Availability Date:

Interdependencies upon other modifications for this client:  * Yes  * No  If yes, then list:

Subject Area Expert (SAE) contact for client:

Subject Area Expert (SAE) for Cayenta:  

<To select a checkbox, highlight empty box and press <shift>-R>

1.2.  References

* None

* 3^rd Party technical specification:

* Client Contract document(s):

* Standards document(s)

* Use Case document(s)

* Other (list):

<List other documents or web addresses which this BRD references. All referenced documents must be stored on a Cayenta internal public drive. Provide enough information so that the reader could access a copy of each reference, including title, author, version number, date, and source or location.>

2.  Business Requirements

<The business requirements provide the foundation and reference for all detailed requirements development. You may gather business requirements from the customer or development organization’s senior management, an executive sponsor, a project visionary, the marketing department, or other individuals who have a clear sense of why the project and project modifications are being undertaken and the ultimate value it will provide, both to the business and to customers.>

< The people providing input on the requirements should be identified, along with their relationship to the modification>

2.1.  Background & Purpose

<This section summarizes the rationale for the new modification(s). Describe in detail the purpose for creating this modification. Provide a general description of the history or situation that leads to the recognition that this modification should be built.>

2.2.  Value Provided to Customers

<Describe the value the customers will receive from the modification and indicate how the modification will lead to an improved customer business process (and therefore, improved satisfaction) – i.e. explain why this modification is a good idea for the customer and the product Express this customer value in terms such as:

improved productivity or reduced rework

cost savings

streamlined business processes

automation of previously manual tasks

ability to perform entirely new tasks or functions

conformance to current standards or regulations

improved usability or reduced frustration level compared to current applications

and so on

Modifications that do not contribute to the maintainability, usability, or functionality of Cayenta’s products may be rejected.>

3.  Customer Requirements

<Describe the needs of the customer that this modification is to address. Present the requirements in a numbered list so that more detailed user or functional requirements can be traced to them.>

3.1.1  Needs that are not met by the clients existing system

3.1.2  Problems client currently encounters that the new functionality should address

3.1.3  Product Functions

<Summarize the major functions the product must perform or must let the user perform. Details will be developed for Section 6, so only a high level summary (such as a bullet list) is needed here. Create any data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams the will help illustrate the Customer Requirements >

3.1.4  Client (user classes) who will use the new functionality

<Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the most important user classes for this modification from those who are less important to satisfy.>

3.1.5  How each client user (use class) will use the new functionality

<If necessary, create a separate Use Case document to detail specific use case information required for Development to adequately understand the functional requirements of the modification.>

3.1.6  Client hardware and software environment

<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.>

3.1.7  Client performance requirements

<You might want to note here that if the client says that the ‘real-time’ performance is required, they need to be made to define an actual requirement IE system updates every 5 seconds. They should also provide an explanation of why this level of performance is required.>

3.1.8  Client Design & Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might include: RFP items, corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; databases to be used; security considerations, and so on. For RFP items, include >

3.2.  Perceived Business Risks

<Summarize any major business risks Cayenta or client associates with the modification – if any. Estimate the severity of the risks and identify any risk mitigation actions that could be taken.(e.g. client is concerned about how the functionality in this modification will effect another 3rd party system they own, client is concerned they will need upgraded hardware to run the new system, client is worried about difficulties getting staff trained to use new modification, client is concerned that modification will effect other business practices, client is concerned that someone not represented will need to buy into the new process forced by the modification). or client is concerned >

<Define any other requirements not covered elsewhere in the BRD. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary

<Define all the terms necessary to properly interpret the BRD, including acronyms and abbreviations. >

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams. >

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. >

Revision History

Document Approval

Accepted on behalf of: