Requirements Documentation

[A Requirement document must be able to communicate the requirements of the customer to project staff and technical staff. However, the requirements must also be presented in a way which is understandable to the customer, project and sponsor management, and other stakeholders.

The Requirement document’s presentation and content should be constructed in a way which can be expanded or contracted to meet the various needs of customers, executive management, key stakeholders, and technical developers. ]

Requirements documentation describes the business need for the project. There are three levels of requirements:

Business: describes the business processes to be performed, inputs required, outputs generated, and interfaces with other processes and systems. For example: A cashed warrant file must be received from the Controller’s Office and the data must be used to update the status of warrants in the system.

Functional: includes all the detailed requirements deemed necessary to fully and adequately address the business requirements. These requirements must include all actions which must take place within the system to accept and process the inputs and to process and generate the outputs. This should include the specific requirements for business rules – all the necessary steps in a business process. For example: A cashed warrant file must be received nightly at 1800 hours via FTP from the Controller’s Office and then used to update the warrant status for the corresponding payment’s issuance line in our system and then by 7:00 am generate a Cash Warrant file for verification by fiscal staff which is sorted by Case Worker and Warrant Name.

Technical: includes required level of service, system performance, security, availability, retention of data, and sizing considerations. For example: The nightly Cash Warrant file program must be able to process an incoming file and update up to 200,000 system records within one hour.

The system description should be stated in operational and logistical terms. Areas to address include: the system’s desired operational capabilities, physical characteristics, performance parameters, service level objectives or agreements, interfaces and interactions with the environment, documentation and reporting requirements, reliability requirements, logistical requirements, and personnel requirements.

The requirements template itself should include the following components as part of its general outline:

a) Background & Introduction

b) Overview

c) Resources and Documentation

d) Acronyms and Definitions

e) Assumptions

f) Issues Pending Clarification

g) Outstanding Issues

h) Business Process Flow

i) Requirements

· Business

· Functional

· Technical

1. Performance

2. Security

3. Data Retention

4. Size

5. Availability

6. Interfaces (external and internal)

j) Approval Page

[Detailed requirements specifications guidance may be found in the OSI PMO documents referenced in Section 1.3.3 of this template (OSI Admin documents #5357 and 5358).

Appendix B is a sample Requirements Checklist crafted as a series of questions to consider in determining whether the requirements document is complete and clear.]

Date: 2015-02-16; view: 784