Functional Requirements Specification <NAME OF PROJECT>

<Project Name and Program1 Code>

Functional Requirements Specification

Version: 2.0

Date: 14.06.12

This is the Banner Finance program code assigned to the project.

FILENAME AND PATH

Page 1 of 23

Functional Requirements Specification <NAME OF PROJECT>

DOCUMENT APPROVAL

Name Arthur Scargill Benvenuto Cellini Tim Finnegan

Position Title Users representative team /stakeholder group Project Manager Business Analyst

Signature

Date

FILENAME AND PATH

Page 2 of 23

Functional Requirements Specification <NAME OF PROJECT>

Contents 1. 2. 3. 4. Purpose of this Document ........................................................................................................................ 5 Reference documents............................................................................................................................... 5 Scope of the Functional Requirements Specification ............................................................................... 5 Business Processes ................................................................................................................................... 6
User Roles .................................................................................................................................................................... 6

5.

Functional Requirements.......................................................................................................................... 7
Business Process Name (eg. Receive Incoming Stock) ................................................................................................. 7

Sub-process Name (eg. Identify Order Details) .......................................................................................... 8 6. Data and Integration................................................................................................................................. 9 Current Data Access Expectations ............................................................................................................ 10 Governance .............................................................................................................................................. 10 Known Data Issues.................................................................................................................................... 10 Data life cycle and archiving ..................................................................................................................... 11 7. Security Requirements ........................................................................................................................... 12 Access & Authorisation............................................................................................................................. 12 Authentication .......................................................................................................................................... 13 Assurance ................................................................................................................................................. 13 8. 9. 10. Performance ........................................................................................................................................... 13 Availability and Recovery........................................................................................................................ 15 Capacity .................................................................................................................................................. 18 End Users .................................................................................................................................................. 18 Online Transaction Rates.......................................................................................................................... 18 Bulk or Periodic Transaction Rates ........................................................................................................... 18 Data Volumes ........................................................................................................................................... 20 Data Archive Requirements...................................................................................................................... 20 11. Data Migration & Conversion ................................................................................................................. 20 Data Sources ............................................................................................................................................. 20 Acceptance Criteria .................................................................................................................................. 20 Decommissioning and Archive ................................................................................................................. 20 12. 13. Glossary of Terms ................................................................................................................................... 21 Document Control .................................................................................................................................. 21 Document Status and Revision History .................................................................................................... 21

FILENAME AND PATH

Page 3 of 23

Functional Requirements Specification <NAME OF PROJECT>

Document Distribution ............................................................................................................................. 23

FILENAME AND PATH

Page 4 of 23

Functional Requirements Specification <NAME OF PROJECT>

1. Purpose of this Document

This document specifies the functions that any proposed solution needs to support in order to meet the high level business requirements, set out in the Business Requirements Statement (BRS). For example a stated business requirement could be enrol students. Related functional specifications would include enter, update and cancel student enrolments and the specifics for each. The development of the Functional Requirements Specification therefore should occur following the approval of the BRS. If the solution involves changes to the existing business operation(s) the usual starting point is to create a model of this, identifying the current processes. Process modelling is a useful technique to achieve this. If the business operations are large and/or complex it is often easier to perform a functional decomposition of the business operation to split this into more manageable components (refer to the CSU Functional Decomposition guide http://www.csu.edu.au/division/psc/pmguides/ ) prior to process modelling. The Functional Requirements Specification will:

Define the scope of business objectives, business functions, and organisational units covered, Identify the business processes that the solution must facilitate, Facilitate a common understanding of what the functional requirements are for all parties involved, Establish a basis for defining the acceptance tests for the solution to confirm that what is delivered meets requirements.

The business analyst is responsible for preparing the functional specification.

2. Reference documents
Document Eg. <Project X> Business Requirements Statement Version

3. Scope of the Functional Requirements Specification

Indicate what business objectives business functions and organisational unit(s) are covered in this functional requirements specification. If there are other FR documents indicate what these are2

In Scope

Out of Scope

i.e. it may be that functional requirements comprise a number of documents elaborating on the same Business Requirements Specification
FILENAME AND PATH Page 5 of 23

Functional Requirements Specification <NAME OF PROJECT>

4. Business Processes
Provide a list of business processes analysed and represented by these functional requirements. Group business processes according to their functional decomposition (where possible).

The following business processes were analysed for the purposes of determining the functional requirements.
Process Reference Eg 2 Process Name Receive Incoming Stock Process Owner Warehouse Manager

User Roles
This section provides some information about the user roles involved in the business processes. It can help to provide depth and context to the information described in the functional requirements

User Role

Role Description

Reports To

End user capacity 1

Eg. Warehouse Manager

Responsible for the overall warehouse operations and all warehouse staff.

Senior Manager Operations

FILENAME AND PATH

Page 6 of 23

Functional Requirements Specification <NAME OF PROJECT>

5. Functional Requirements
A range of techniques are open to the analyst to specify functional requirements . An alternative to that set out below is to 4 describe the requirements via use cases, where e.g., process diagrams are grouped with the relevant use case .
3

Business Process Name (eg. Receive Incoming Stock)

Insert here the process model for the Business Process

Moreover, it may be necessary to develop multiple models using different techniques to completely analyse and document requirements, as suggested on page 105 of A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2, International Institute of Business Analysis (IIBA), 2009.
4

Depending on volume and complexity of use cases the analyst may determine that a separate Use Case document is warranted. In such cases, the analyst must clearly link documents as appropriate whether as reference links or as embedded objects. FILENAME AND PATH Page 7 of 23

Functional Requirements Specification <NAME OF PROJECT>

Sub-process Name (eg. Identify Order Details)

Insert here the process model for the sub-process

Sub-Process Name: Objective Trigger\Events Inputs Outputs Functional Requirement 1 Functional Requirement Description Business Requirement Cross Ref Business Rules Business Importance Formulas Test Verification Functional Requirement 2 Functional Requirement Description Business Requirement Cross Ref Business Rules Business Importance Formulas Test Verification (Mandatory / High Priority / Optional) (Mandatory / High Priority / Optional)

FILENAME AND PATH

Page 8 of 23

6. Data and Integration

Consider all forms of documents and data produced by this project including files, such as PDF, video, etc. If specific data elements have been identified then provide these

Business Object/Entity (in scope) Eg. Order

Data Element (where known) Order Number

Description (meaning & purpose explicit)

Data Classification5

Related To

Format

Mandatory or Optional Mandatory

Business Rules

A unique number assigned to each order.

Order

Numeric up to 10 digits

The number must be unique. The Order Number cannot be changed by the user.

Note 1. Data Security Classification level:

Level 1 (Highly Confidential) Level 2 (Confidential) Level 3 (Internal Use) Level 4 (Public) See also: http://www.csu.edu.au/division/dit/eal/resources/staff_only/Master-Datagovernance-framework.pdf

FILENAME AND PATH

Page 9 of 23

Functional Requirements Specification <NAME OF PROJECT>

Other Items State or Lifecycle Models (could also choose to add a diagram like this to add additional clarity at some point in the document. Its not that commonly needed though, so probably not worth adding to the template). Output templates [report layouts, letter templates, etc] (This is a good bit to put as an appendix, which can be then removed if not required for a particular project.) Screen Designs / Wireframes (relevant for web/form type projects helps define the user flow and how the information needs to be displayed for users. Again, would put as an appendix, and gets used if required/relevant. Could also go as a stand-alone template if you want

For each data group (or holistically), describe: Data Access Expectations, Data Governance, Known Data Issues & Data Lifecycle & Archiving,

Current Data Access Expectations

Age of Data Eg. 1 5 years Frequency of Access 1 time per day Retrieval Time Expectation < 20 seconds

Governance
Identify the business unit that has responsibility for data governance.

Req. No. Eg 1

Data Student Identity

Business Unit Responsible DSA

Are there any identified governance issues Data can only be created and changed by DSA staff. Data access is restricted by confidentiality requirements.

Known Data Issues

If possible, identify any existing data issues that have been raised during the business analysis and may impact the project.

Data Eg User Identity

Situation Allowing a Change of Login by user

Impact Login uniquely identifies user and links to existing records. User will lose access to

Stakeholders DLTS

Proposal Link all data via unique identifier (eg PIDM) to permit login
Page 10 of 23

FILENAME AND PATH

Functional Requirements Specification <NAME OF PROJECT>

Data

Situation

Impact previous data

Stakeholders

Proposal changing by user

Data life cycle and archiving

Describe the life cycle of the data and the archival requirements. Are there compliance requirements attached to the data life cycle? There are requirements to be met for NSW State Records.

What is the lifecycle of the data Business Requirements for archiving data access archived data retaining archived data eg. Data is archived yearly Archived data needs to be available within 24 hours

Legislative Compliance Requirements related to Archiving & Retention

FILENAME AND PATH

Page 11 of 23

Functional Requirements Specification <NAME OF PROJECT>

7. Security Requirements
All applications need to operate in an environment that has an appropriate level of security. Security controls will be determined by the data classification level of the data. Refer to the Master Data Classifications It is the data owner that dictates what level of sensitivity the data holds, and what level of availability is appropriate (It should be the responsibility of the data owner to define the classification level of the data. CSU has adopted AS/NZS ISO/IEC 27002:2006, S7.2.1 as the basis for its security standard. IT staff will manage the businesses data in accordance with the requirements laid down by the business.

Access & Authorisation

In determining access to the information managed by the application, consideration should be given to the following three conditions: Who should have access to the information; What level of access is appropriate for each role; Who should not have access to this information.

Role

Description

<Function 1 eg. Edit Data via Maintenance Screens >

<Function 2 eg. Invoke Specific Update Functions> NO

<Function 3 eg. Run Reports>

<Function 4 eg. View Confidential items>

Eg.

NO

NO

NO

Alternatively, it may be more appropriate to express the access requirements to files, reports or records using a simple CRUD table. An example is provided below:

Role

Description

<Function 1 eg.Admin Account> CR

<Function 2 eg. Report C> CRU

<Function 3>

<Function 4>

Eg.

None

KEY: C=Create; R=Read; U=Update; D=Delete

FILENAME AND PATH

Page 12 of 23

Functional Requirements Specification <NAME OF PROJECT>

Authentication
Authentication relates to the identification of the user and their role. The requirement here should steer clear of stating the solution unless that has already been determined as a result of one of the constraints already stated. Rather it should specify any specific business needs, such as seamless/single sign-on, the source of any existing User ID and or password that should be re-used, any user considerations in setting and maintaining passwords (eg users only have number pads, so should only contain numbers). Where appropriate, the functional requirements relating to authentication should be stated in the functional requirements area and the relevant processes documented. Definitions can be found in http://www.csu.edu.au/division/dit/eal/glossary.htm: Single Signon: once-only assertion / authentication per session, per credential Same Signon: The process whereby infrastructure presents the same authentication credentials (or some other predetermined information or token) to a subsequent application, without the user re-entering it, or even being aware of it. This enables those thirdparty packaged applications that have their own built-in authentication that is not able to be detached, to behave as though they are participating in a Single Sign-on solution

Role System Administrator CSU End user Public user

Description Application administrator Application user Application user

Account type Local ad-hoc account CSU credentials none

Credential type Username/pass word/ security token Username/pass word n/a

Single sign on no

Same sign on no

no n/a

yes n/a

Assurance
Assurance of systems seeks to prevent loss, modification or misuse of user data in applications. ie. How does the organisation assure itself that the security controls that have been put into place, are working, eg. Separation of Duties, Audit Logging, Reporting of Auditing (eg. Who is using the system), any information required by the Audit Office of NSW. This section may also be specified in the Functional Requirements or Technical Specification Document. For further information, see Section 10.10 of AS/NZS ISO/IEC 27002:2006

8. Performance
Provide system performance targets for the various usage scenarios. This should include: * Response times for key functions * Elapsed processing time for report or bulk processing operations It is normal to express performance requirements in bands, eg: 70% of transactions < 2 seconds 85% of transactions < 10 seconds
FILENAME AND PATH Page 13 of 23

Functional Requirements Specification <NAME OF PROJECT>

100% of transactions < 30 seconds Performance targets should be realistic and reflective of the actual need. Insisting on sub-second response for every activity could add substantial hardware and/or software design costs to a project.

FILENAME AND PATH

Page 14 of 23

Functional Requirements Specification <NAME OF PROJECT>

9. Availability and Recovery

System availability is usually defined as "the degree to which a system suffers degradation or interruption in its service to the customer as a consequence of failures of one or more of its parts". In other words, it is the amount of time a system is available and ready for use. The nature of systems availability can have a dramatic impact on the cost to develop and operate an application. The statement of availability requirements must be considered in terms of realistic business requirements and present a reasonable and practical match to the business process. If you are considering a new system, then the availability requirements will need to be determined, however if you are considering additional functionality to an existing system, you should state the current availability requirements as they stand (or reference a base document which already states this.) The only exception to this is where the new functionality you are describing would result in changes to system availability requirements. Use cases may also be of assistance in determining an appropriate level of system availability. This following matrix should be completed for each business function or high level process covered by the proposed solution. For example if several distinct groups are using a common solution in significantly different ways to support different processes or there are different usage aspects of the same solution such as Publish Documents by staff versus View Documents by customer. Some impacts may not apply in all scenarios, and should be so indicated if not applicable. Elaborate on answers where appropriate to provide a clearer picture of people or process impacts.

System Availability Question Business Process or Function During which hours is the solution required to support the business Function. (per user group) Can the solution tolerate scheduled maintenance windows and if so when are the most appropriate times for these? (intra-day times or calendar periods) Critical Availability Times (intra-day times or calendar periods) Number of Affected Clients and Types affected by outages of the solution Describe the Business Process Reliance on System Recovery Point (The maximum amount of data loss tolerable expressed as time.) In the event of a data loss how easy is it to reconstitute the data. A=Simple (re-enter from paper forms) B= Difficult (advise remote users to resubmit) C= Impossible Recovery Time (The maximum amount of business function outage tolerable expressed as time.)
FILENAME AND PATH

Example Answer Eg Online subject enrollment Staff data entry 8Am 6Pm AEST Student Access any time Between 8:00Pm 4:00Am AEST During session breaks 8 weeks prior to start of session 20 Staff & 5,000 Students High 10 Minutes B

Answer

3 Hours

Page 15 of 23

Functional Requirements Specification <NAME OF PROJECT>

System Availability Question Describe any Compliance requirements such as legislative or dependent funding that affect availability of the solution Provide a brief description of the impacts of an outage in relation to this business function.

Example Answer Annual Government reports must be lodged by the end of the Fiscal Year Direct enrolment students will not be able to enroll online and DSA staff will be unable to progress already submitted applications.

Answer

FILENAME AND PATH

Page 16 of 23

Functional Requirements Specification <NAME OF PROJECT>

System Outage Impacts Categorize the scope of the impact of a system failure E=Enterprise Wide D=Department only (state which) Categorize the scope of the impact of outages on the Business function C=Customer Facing I=Internal Function, How Many staff will be left substantially idle due to system failure Workaround options (How can business process continue without the system) Would a system outage result in lost customer recruitment opportunities Would a system outage result in a direct financial loss Could a system outage directly result in Damage to the Universitys reputation Could a system failure compromise any of the following P=Personal Safety, S=Data Security, I=Data Integrity C=Client Confidentiality (provide explanation)

Example Answer E

Answer

20 Admin Staff Students fill in paper enrollment forms. Yes Sales are reliant on the system Yes S, I

FILENAME AND PATH

Page 17 of 23

Functional Requirements Specification <NAME OF PROJECT>

10.

Capacity

This section is used to detail the expected volumes of data and transaction flows. This should be laid out in a similar manner to the following.

End Users
Detail the expected user loads for each of the distinct user functions or roles. The user roles or titles should line up with the actor definitions provided in the business process requirements.

Connected Concurrently Role Average Eg. Data Entry 20 Max 35 Growth 10%

Online Transaction Rates

Detail the expected volumes for each of the online activities. Ignore low volume activities. The Transaction Descriptions should cross reference to a Use Case in the Business process Requirements.

Transactions per annum Transaction Descriptions Average Online company searches refer UC217 Search for Company 3.5m Max 4.7m Growth 30%

Bulk or Periodic Transaction Rates

Detail the expected volumes for each of the bulk processing activities. Ignore low volume activities. Note that transaction growth rates may be negative is some instances. As with online transaction loads, the Transaction Descriptions should cross reference to a Use Case in the Business Process Requirements.

Transactions per annum Transaction Descriptions Average ROP's to non-complying org, refer UC101 Dispatch Notices 3.5m Max 4.7m Growth 30%

FILENAME AND PATH

Page 18 of 23

Functional Requirements Specification <NAME OF PROJECT>

Transactions per annum Transaction Descriptions Average Max Growth

FILENAME AND PATH

Page 19 of 23

Functional Requirements Specification <NAME OF PROJECT>

Data Volumes
This section is used to detail the expected storage requirements in terms of numbers of entities. This will form the basis for later data storage calculations once the data storage design work has been completed. The Business Entities must match to entities shown in the entity model in the Business Process Requirements.

Business Entity Eg. Corporation

Initial Volume 1.2m

Additions p.a. 0.1m

Growth in Rate of Addition 10%

Data Archive Requirements

Data archiving is a useful mechanism to reduce overall long term disk space requirements and hence storage costs. Data archiving can also ensure consistent levels of performance over time by limiting the amount data that must be searched or processed for a particular task. State the retention period for historic information with regard to each entity listed above.

11.

Data Migration & Conversion

Data Sources
Identify and briefly describe each of the source systems from which data will be migrated. For each system identify which entities are being extracted and converted.

Acceptance Criteria
On what basis will the migration be deemed a success, eg by entity or source system what percentage of target records must be migrated successfully? What balancing figures will be checked and what degree of variance will be accepted? Is it a requirement that the new system be implemented prior to or after migration? How much data will be migrated, eg last 3 years only or data since inception? What degree of data discards during migration will be accepted. How will the conversion / migration be verified?

Decommissioning and Archive

Describe the process to be followed where an existing system is to be decommissioned partly or fully. Stipulate the archive requirements for preserving the historic data records of the system being decommissioned.

FILENAME AND PATH

Page 20 of 23

Functional Requirements Specification <NAME OF PROJECT>

12.
Term

Glossary of Terms
Definition Higher Education Contribution Scheme)

(E.g. HECS

13.

Document Control
Author C.Cox C.Cox C.Cox Issue date 13th October 16th February 2012 17th February 2012 Following Workshop 1 with BA, EA, SA, SCs Following workshop 2, changes as follows: Remove section titled Impact on current businesses processes and the nature of the impact: (migrated from the FR Checklist). This should be covered as part of the business requirements analysis sub process. CC to pursue whether and how this is covered in that area. Remove the section titled Legislative and compliance requirements (migrated from the FR checklist) and insert a note regarding legislative /compliance in the functional Requirements section because: Revisions

Document Status and Revision History

Version DRAFT DRAFT 2 DRAFT 3

Legislative implications really belong at the business requirements analysis stage where the BA would be aware of legislative/compliance considerations when developing the BR requirements. This flows through to the functional requirements specification. Should any additional legislative / compliance need be suggested in the course of specifying functional requirements, then these should be noted against relevant requirements.
The sub section data archiving requirements within the Capacity section, to be reviewed and compared to other sections to see what overlap exists and to resolve as appropriate. Mavis will lead a short exercise to resolve this and include representation from EA and SA members from this working group.

The subsection Data creation and management under the section: Data and Integration is removed. A column Data classification is added to the table under Data definition and a legend and link provided on classification.
Move the section Data migration and conversion after the section Data and integration. Rethink the section Availability and Recovery. Kieran to lead this exercise with assistance from BA and SA representatives. Update to the Data Definition example table suggested by C.Middleton to include at left an additional column titled:
Page 21 of 23

DRAFT 4

C.Cox

2nd March 2012

1.

FILENAME AND PATH

Functional Requirements Specification <NAME OF PROJECT>

Version

Author

Issue date

Revisions 2. Business Object/Entity.(CM) In the Data Definition section change the format of the note at the end on Data Security Classification Level so that it looks more like a note (MW). Updated Availability and Recovery section following Kierans working group efforts

3. DRAFT 5 C.Cox 7th March 2012

Changes from Mavis sub group 1. Move the Section on Data & Integration to before Security (& after functional requirements)

Rationale: Data is the section you generally work on next after you have worked through the functional, and that the other sections (Security, Performance etc) will stem from accurately identifying both functional & data components. 2. Have Colleens Data Definitions table as the first item in Data & Integration, and changed to landscape Retained the section Data Archive Requirements in Capacity, but removed the example

Rationale: This is the master data list 3.

Rationale: There is still a need for capacity estimates on archived data but the example was confusing and worked against the intent of the section. Moving the Data & Integration section before Capacity makes this section more logical. 4. Introduced a sub-section Data Access Expectations into Data & Integration Restructured the heading in Data Life cycle & archiving table to make it clearer about archiving data requirements Suggestion to remove Integrity, Event Logging & Audit Trails

Need example from Marian for this. 5. 6.

Rationale: these items should be in the functional requirements/use cases (thinking from a couple of BAs) 7. Re-arrange the headings in the Data & Integration section Rationale: so it logically flows more easily for the BA. So the Data & Integration Section should be moved in the document & now has the headings Data Definitions Table Current Data Access Expectations Governance Known Data Issues Data Lifecycle & Archiving

DRAFT 6`

12.2.20 12

C.Cox.

Section: Data & Integration - Update the prompter for Data Definition and also the Data definition table - change received from Colleen.

FILENAME AND PATH

Page 22 of 23

Functional Requirements Specification <NAME OF PROJECT>

Version DRAFT 7 DRAFT 8 Version 2.0

Author 22.3.12 14.6.12 14.6.12

Issue date C.Cox M.Jenkins C.Cox

Revisions Include sample table under Current Data Access Expectations from MW Introduction of Word styles & tidy up of formatting. Updating of Security section. Finalised following review session with Mavis.

Document Distribution
No. Recipient Position

FILENAME AND PATH

Page 23 of 23