Brs Template 3p3c5
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report 3i3n4
Overview 26281t
& View Brs Template as PDF for free.
More details 6y5l6z
- Words: 1,254
- Pages: 7
Ranagreens
ERP Solutions & Staff Management
Functional Requirements Specification
<Section/Department>
Version Control Version Number 1.0
Date
Comments
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
. .................................................................................1 2.1.1 Description....................................................................................1 2.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
.
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 s • 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
.
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
• • • • • • • • • •
3.
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 s 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
Performance Requirements
Specific information on how the system is required and/or expected to perform. This could include information on: • expected number of s, • 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 s or 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
•
6.
even something that may be affected by QUT’s general culture.
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 s 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 access be istered 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 s 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
ERP Solutions & Staff Management
Functional Requirements Specification
<Section/Department>
Version Control Version Number 1.0
Date
Comments
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
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
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 s • 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
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
• • • • • • • • • •
3.
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 s 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
Performance Requirements
Specific information on how the system is required and/or expected to perform. This could include information on: • expected number of s, • 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 s or 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
•
6.
even something that may be affected by QUT’s general culture.
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 s 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 access be istered 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 s 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
Related Documents 3h463d
Brs Template 3p3c5
December 2019 48
Brs - Physiology 3p561z
November 2019 56
Brs Pediatrics 4g3w9
November 2019 250
Neuroscience-brs x4g3f
October 2019 60
Brs Pathology 59242
November 2019 63