Ranagreens

ERP Solutions & Staff Management

Functional Requirements Specification

<Section/Department>
<Date>
Version Control

Version
Date Comments
Number
1.0 15th March 2004 Initial draft for review

Approvals

Date Name and Position Signature

Table of Contents

1. INTRODUCTION............................................................................................1

2. Functional requirements.................................................................................1

2.1 <Requirement 1>. .................................................................................1

2.1.1 Description....................................................................................1
2.2 <Requirement 2>. .................................................................................1
2.2.1 Description....................................................................................1

3. Performance Requirements.............................................................................2

4. Database......................................................................................................2

5. Design Constraints........................................................................................2

6. Security and Audit.........................................................................................3

7. Hardware and Software..................................................................................3

8. Interfaces.....................................................................................................3

9. Timeframes..................................................................................................4

10. Reporting...................................................................................................4

11. Operations and Maintenance.........................................................................4

 RANAGREENS
REQUIREMENT SPECIFICATION

1. INTRODUCTION
A description of the intent and goals of the system, what the general current business
process is, and ideally a description or attachment of the new system requirements
from the client’s perspective. Where appropriate, attachments in the form of
flowcharts or process flow diagrams showing overall business processing flows would
be useful.

2. Functional requirements
For each functional requirement the following details should be included:

2.1 <Requirement 1>.

Label or name of the requirement eg. Entering leave requests

2.1.1 Description
A description of the general function to be performed and a clear understanding of
how the function would be tested ie. what identifies that this particular function is
working correctly when in use, as well as any other introductory or background
material that might clarify the purpose and intent of the function.

Subsequent subsections within this function requirement section may vary however
they should detail all required information about this function including:
• When this function is used and by what/whom
• What information is required to be entered
• Volume and frequency of any data input to the function
• Where does the input data come from (eg. Paper form, interface)
• Any validation requirements on the data eg. Valid ranges of data
• Any security requirements eg. function is only authorised for certain users
• What processing is required to be carried out within the function
• What outputs there may be ie. destination of data
• Any specific error handling required
• Any constraints on the function or the inputs to the function
• Reference to interface specifications where appropriate

2.2 <Requirement 2>.

Label or name of the requirement eg. Approve Leave request

2.2.1 Description
A description of the general function to be performed and a clear understanding of
how the function would be tested ie. what identifies that this particular function is
working correctly when in use, as well as any other introductory or background
material that might clarify the purpose and intent of the function.

Subsequent subsections within this function requirement section may vary however
they should detail all required information about this function including:
• When this function is used and by what/whom

Page 1
 RANAGREENS
REQUIREMENT SPECIFICATION

• What information is required to be entered

• Volume and frequency of any data input to the function
• Where does the input data come from (eg. Paper form, interface)
• Any validation requirements on the data eg. Valid ranges of data
• Any security requirements eg. function is only authorised for certain users
• What processing is required to be carried out within the function
• What outputs there may be ie. destination of data
• Any specific error handling required
• Any constraints on the function or the inputs to the function
• Reference to interface specifications where appropriate

3. Performance Requirements
Specific information on how the system is required and/or expected to perform. This
could include information on:
• expected number of users,
• volume of transactions,
• speed of processing responses,
• availability and up-time,
• off-campus or on-campus availability or performance etc.

4. Database
This section relates to those systems where a new central database, or modification to
an existing database, is required. It should identify and specify any specific database
design issues including:
• expected size and growth of the database,
• number of instances (ie. Different environments such as development, test and
production) that are required,
• what version and release of the database is to be used (eg. Oracle v9),
• how the database will be accessed eg. what other systems/applications are
likely to be required to have direct access to the database,
• will users or support staff perform adhoc queries or reports on the data.

5. Design Constraints
This section should identify as many possible technical and design constraints that can
be identified up-front in the project lifecycle as well as how they may be resolved. It
is similar in some ways to identifying particular risks and mitigation strategies.
Specific constraints may relate to different options and recommendations. Some
examples include:
• the ability (or inability) to introduce a specific technology into QUT,
• existing business processes or policies that impact on identifying an
appropriate design solution,
• current hardware or operating software restrictions, and

Page 2
 RANAGREENS
REQUIREMENT SPECIFICATION

• even something that may be affected by QUT’s general user culture.

6. Security and Audit

A description of the security and audit requirements of the system detailing:
• Who has access to what functions or parts of the system
• How the access security is implemented and controlled eg. If restricting certain
functions to users then does this use QUT’s central authentication directory or
QUT Virtual portal access to control this and how.
• If adhoc data access is required how will user access be administered or
contolled.
• How is this monitored or logged.

7. Hardware and Software

A description of various hardware and software platform requirements that need to be
considered where appropriate such as:
• What server(s) specification
• What operating system
• How much memory
• Desktop client requirements or compatability
• Mobile devices
• Specific network equipment or configuration
• Storage requirements such as storage size and/or SAN compatability

8. Interfaces
The majority of systems at QUT require some form of integration or interfacing with
other systems, the network and/or equipment. This section should define or
reference the necessary protocols or specifications for the various interfaces required.
Data interfaces may consist of:
• how one application is embedded in another,
• data movement issues such as where data comes from or goes to,
• how and when the data needs to be moved,
• what other system or timing dependencies there are on the data in the new
system or data from other systems, and
• what system to system access accounts or processes may be required.
Hardware interfaces may refer to specific hardware platforms or equipment being put
in place eg. Network hardware, portable devices etc.
Communication interfaces will relate to any specific requirements for communication
over the network eg. network protocols, as well as those required for communicating
with specific hardware.

Page 3
 RANAGREENS
REQUIREMENT SPECIFICATION

9. Timeframes
Note here any specific timeframes required for this project such as business cycles,
organisational deadlines etc.

Also, note if any agreements have been made with regards the expected timeline for
the project along with relevant dependences and processes to follow for this. An
example may be an agreed timeframe for completion subject to no further change
requests for the project and that if additional requirements do come along they will
affect the timeframe.

10. Reporting
What reports are required from the system. Include a mock-up of their general layout
and design.
Whether or not ad-hoc reporting will be required and how this will be carried out, for
example, a Business Objects Universe.

11. Operations and Maintenance

This section would detail how the system is expected to operate eg:
Business timetables and peak/low periods
Backup and recovery requirements and timing

Page 4