DOCX

Functional Requirements Specification

By Brent Perry,2014-03-28 00:05
10 views 0
Functional Requirements SpecificationFuncti

    Functional Requirements Specification

    

    1 Code>

    Functional Requirements Specification

    Version: 2.0

    Date: 14.06.12

    1 This is the Banner Finance program code assigned to the project. FILENAME AND PATH Page 1 of 23

    Functional Requirements Specification

    

DOCUMENT APPROVAL

    Name Position Title Signature Date Arthur Scargill Users’ representative

    team /stakeholder group

    Benvenuto Cellini Project Manager Tim Finnegan Business Analyst

FILENAME AND PATH Page 2 of 23

    Functional Requirements Specification

    

Contents

    1. Purpose of this Document ................................................................................................................... 5 2. Reference documents ......................................................................................................................... 5 3. Scope of the Functional Requirements Specification............................................................................ 5

    4. 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. Performance ..................................................................................................................................... 13 9. Availability and Recovery................................................................................................................... 15 10. 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. Glossary of Terms .............................................................................................................................. 21 13. Document Control ............................................................................................................................. 21

    Document Status and Revision History ................................................................................................ 21 FILENAME AND PATH Page 3 of 23

    Functional Requirements Specification

    

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

FILENAME AND PATH Page 4 of 23

    Functional Requirements Specification

    

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 Version

    Eg. Business Requirements Statement

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

    2 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

    

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 Name Process Owner Process

    Reference

    Eg 2 Receive Incoming Stock 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 Responsible for the overall warehouse Senior Manager

    Manager operations and all warehouse staff. Operations

FILENAME AND PATH Page 6 of 23

    Functional Requirements Specification

    

5. Functional Requirements

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

    Business Process Name (eg. Receive Incoming Stock) Insert here the process model for the Business Process

    3 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

    

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 (Mandatory / High Priority / Optional) Formulas

    Test Verification

    Functional Requirement 2

    Functional Requirement Description

    Business Requirement Cross Ref

    Business Rules

    Business Importance (Mandatory / High Priority / Optional) Formulas

    Test Verification

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

    Description Format Business Rules Business Data Data Related Mandatory Object/Entity Element Classification5 To or (meaning & purpose explicit) (in scope) (where Optional

    known)

    Eg. Order 3 Order Mandatory The number must be unique. Order A unique number assigned to Numeric up to 10

    Number each order. digits The Order Number cannot be changed

    by the user.

5 Note 1. Data Security Classification level:

    ; Level 1 (Highly Confidential) See also:

    ; Level 2 (Confidential) http://www.csu.edu.au/division/dit/eal/resources/staff_only/Master-Data-governance-framework.pdf ; Level 3 (Internal Use)

    ; Level 4 (Public)

FILENAME AND PATH Page 9 of 23

    Functional Requirements Specification

    

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. It’s

    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 Frequency of Access Retrieval Time Expectation

    Eg. 1 5 years 1 time per day < 20 seconds

Governance

    Identify the business unit that has responsibility for data governance.

    Data Business Unit Responsible Are there any identified governance issues Req.

    No.

    Eg 1 Student Identity DSA 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 Situation Impact Stakeholders Proposal

    Eg User Identity DLTS Allowing a Change of Login uniquely identifies Link all data via

    Login by user user and links to unique identifier

    existing records. User (eg PIDM) to

    will lose access to permit login

    FILENAME AND PATH Page 10 of 23

Report this document

For any questions or suggestions please email
cust-service@docsford.com