Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Members
Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.

Detailed Business Requirements Deliverable Template

From MIKE2.0 Methodology

Share/Save/Bookmark
Jump to: navigation, search
Under review.png
This article is a stub. It is currently undergoing major changes as it is in the very early stages of development and is only a placeholder. Please help improve MIKE2.0 by adding to this article.
This deliverable template is used to describe a sample of the MIKE2.0 Methodology (typically at a task level). More templates are now being added to MIKE2.0 as this has been a frequently requested aspect of the methodology. Contributors are strongly encouraged to assist in this effort.
Deliverable templates are illustrative as opposed to fully representative. Please help add examples to this template that are representative of the proposed output.

Refine the Requirements to a level of detail from which more detailed design can be conducted. This may involve going to a lower level of granularity through sets of interviews to clarify specific points with users. The focus, however, should be on "drilling-down" on Blueprint requirements (where required) as opposed to adding new requirements not included in the vision

Contents

Examples

Listed below is an example Detailed Business Requirements:

Example for sample Detailed Business Requirements

Introduction

Purpose

This document sets out the Detailed Business Requirements for the CLIENT component of the XYZ programme.

Its purpose is to refine, expand and supersede the requirements set out in the document titled "Business Requirements Document, Core Customer Information Project – Customer Information Repository Stream v1.4". Where there is an inconsistency or conflict between the document titled "Business Requirements Document, Core Customer Information Project – Customer Information Repository Stream v1.4" and this document, this document takes precedence.

Overview

Eighteen requirements have been identified:

ABC

1) Requirement 1

Modify ABC to store additional Core Customer Data.

2) Requirement 2

Perform an initial population of the additional Core Customer Data fields.

3) Requirement 3

Modify ABC NT to capture, search for, display and maintain the Core Customer Data.


Background

The Bank has initiated the "Which new Bank" program with the aim of excelling in customer service. Underpinning this is a requirement to fully understand customers

’ relationships with the Bank. This project is to provide some of the infrastructure required to satisfy this requirement. Refer to the Executive Summary in the Business Requirements document referred to above for additional reasons as to why the Bank initiated the XYZ programme and an outline of the implementation phases.

Stakeholders

Name Business Unit Role with respect to these requirements
  Channel Management Approve requirements
  Channel Management Review and recommend approval of requirements
  GC Approve requirements
  GC Review and recommend approval of requirements
  GC Review and recommend approval of requirements
  GT, XYZ Data Loads Project Review requirements
  IBB Approve requirements
  IBB, Common Platforms Approve requirements
  IBB Review and recommend approval of requirements
  IBB Review and recommend approval of requirements
  CommSec Approve requirements
  CommSec Review and recommend approval of requirements
  GT Approve requirements
  GT, Architecture Review and recommend approval of requirements
  IIS Approve requirements
  IIS Review and recommend approval of requirements

Scope

The Statement of Work sets out the scope of the CLIENT project. The in scope and out of scope statements below relate specifically to the Detailed Business Requirements.

In Scope

The detailed definition of the 18 high-level business requirements listed in the Overview (Section 1.2) forms the basis for this document
The non-functional requirements listed in Section 3 of this document.

Out of Scope

Requirements for cleansing and/or deduplication of data in ABC, DMA or CIS

Requirements for changes to systems downstream of DMA, ABC or GDW

Requirements for authentication of users before gaining access to XYZ data (refer to assumption 1.6.1 and 1.6.2).

The specific requirements listed under Requirement 8 which are future requirements and which are provided to assist with ensuring a transition path is available.

Requirements for the modification of existing DMA data loads and DMA for the Account Access flag which is currently not handled by DMA.

Business rules for controlling access to, processing and display of account involvement types and client to client links (See assumption 1.6.5).

Assumptions

These assumptions relate specifically to the requirements set out in this document. The project assumptions are documented in the Statement of Work.

Existing interfaces, including batch interfaces, authenticate users, their level of access and the functions they can perform before they are granted access to ABC, and this authentication, will be used to control access to Core Customer Data.

New applications that use the services provided by CLIENT will authenticate users, their level of access and the functions they can perform.

The underlying CIS data structures are not changed – ABC will become another source of data about the customer rather than a replacement source for either "Relationships" or "Debtors".

The modulus validation of BN and AN will be performed by ABC. CIS will perform the validations to determine whether an BN or AN is mandatory. ABC is able to include the fields identified in the CIS_XYZ Table of Attachment F.

The role of the Party Services is to process information about customers and accounts stored in ABC with as little filtering as possible. Front ends are to provide filtering and control processing based on business rules for access to and processing of core customer data (subject to a minimum set of validations to be performed by the Core Customer Services) which are relevant for that front end.


Functional Requirements

Business Rules – ABC

Requirement 1

Modify ABC to store additional Core Customer Data.

Open Issues

Answers need to take into account subsequent phases.

Resolution of these questions noted here for this release and updates made in appropriate sections of the requirements. In the next release, these questions will be removed.

1. What are the full requirements for the Bank Access Restriction Code? Must include CIS Undisclosed Leasing Accounts and should enable distinguishing of Privacy requirements separately from access requirements (Escalated).

Core Customer Data Attributes

At the core of the CLIENT project is the identification of Core Customer Data to support the

’ Party


’ concept using existing ABC customer data elements as well as newly defined core customer data elements. The definition of the


’ Party


’ concept facilitates the inclusion over time of other parties the Bank has relationships with apart from customers. The mandatory Core Customer Information data elements are identified below. Those fields indicated as new to ABC or with changes to their existing ABC structure have the field


’ s purpose and business rules defined in the following sub-sections.

Category Party Core Customer Data Elements Equivalent ABC Field New to ABC*
Common Identification Data Party ID Client Identifier (ABC ID)  
Party Type Code Client Legal Type Code  
Party Status Code Client Status Type Identifier  
Required Address Client Address  
( Business Number) Client Tax File Number (rules apply) *
Other Systems Customer Identifier


-

*
Person Person Title Code Person Title Code  
Person First Name Person First Name  
Person Middle Name Person Middle Name  
Person Last Name Person Last Name  
Person Name Suffix Person Name Suffix  
Person Birth Date Person Birth Date  
Gender Sex Type Code  
Non-Person Non-Person Name Non-Person Name  
CN Company Number  
Account Linkage Data Source System Account Number State Number


+ Branch Number


+ Account Number

*
Application Code Application Code  
Product Code Product Code  
Sub Product Code Sub Product Identifier  
Account Status Code Account Life Cycle Status Code  
Account Involvement Type Client Account Type Code  
* This column indicates that the specified Party Core Customer Data Element is a new element to ABC (even if a similar/equivalent existing ABC field exists).

BN (Business Number)

  • Add at the client level
  • Business Number
  • The Business Number (BN) is a single identifier for use in business dealings with the Taxation Office (TO) and for future dealings with other government agencies.
  • In practice an BN is required to register for the goods and services tax (GST) and other elements of the New Tax System.
  • Companies registered under the Corporations Act 2001 and business entities carrying on an enterprise are entitled to an BN if they apply.
  • The BN will eventually replace the Company Number (CN) and the Registered Body Number (RBN).
  • When an organisation applies for and receives their BN, the business details from their application become part of the Business Register (BR).
  • Source: AIC Web Site
  • 11 Digit Number
  • Optional, but unique
  • (Note: The CIS Business Rules for details of when the BN is mandatory will be applied to CIS but not ABC in Phase 1).
  • Business rules regarding the population of the BN field are defined in Sections 2.4 and 2.6 (new Party Services).

Addresses

  • Handling of Overseas Addresses to be improved:
  • Overseas suburb field to be introduced
  • Overseas state field (exists, but not currently available through existing services) to be made available
  • Country code exists
  • Overseas postcode field to be introduced, 10 alphanumeric characters, no validations
  • International addressing is very complex. The following are links to sites which contain further information about international addressing (provided for information only):

Source System Account Number

  • Enable original source system account number to be stored within ABC, even if it contains non-numeric characters
  • Field length to remain at 24 characters including State and Branch Identifiers (where they are part of the Source System Account Number), i.e.
  • State – 1 character
  • Branch – 3 characters
  • Account – 20 characters
  • The State and Branch identifiers are also required to be separately accessible, that is, stored in separate fields (where they are part of the Source System Account Number).
  • The State and Branch identifiers will be source system dependent, as they are not mandatory for all products.
  • Mandatory for all accounts
  • Existing front ends and interfaces which cannot handle an alphanumeric account number are not to be adversely affected by this requirement.

Account Involvement Type Data Element Requirements

  • An additional value is required to be available for the existing ABC Client Account Type Code data element, this being:
  • Guarantor – non-owner of account
  • Refer Attachment E for the existing values of the ABC data element, Client Account Type Code, with values defined in the code table D777. ECCT8306.
  • The field is mandatory.
  • Business rules for this value (e.g. display rules) will be defined by the front ends accessing these values.
  • This will impact ABC downstream systems that are passed account linkage information.

Other Systems Customer Identifiers

Identifiers from other systems are to be stored within ABC. The components required to be stored for each Party are:

  • Customer ID (from other system)
  • Application Code

Note that because duplicate client records can exist in other client based systems which map to the same Party, there is a need to allow for multiple Other System Customer IDs per Application Code.

In addition, the Other System Customer ID must be the equivalent of a Party and cannot represent a group of parties (eg a CIS Debtor).

Lists of Allowable Values

  • Lists of allowable values to be delivered and maintained according to existing ABC methodologies, unless otherwise specified.

Requirement 2

Perform an initial population of the additional Core Customer Data fields in ABC.

Initial Population of ABC Core Customer Data

The initial population of the new or changed Core Customer Data fields, uses existing relevant ABC fields as well as, where appropriate, defined defaults for new fields. Details for the specific fields are set out below.

BN Initial Population Requirements

As there are only a small number of BNs in ABC (approximately 10,000), the Initial Population approach is to extract the BNs into a file that can be manipulated using Microsoft Access or Excel, manually validate the values, and then to load the validated values into the new Core Customer Data BN field. In order to do this:

  • Provide a file in a format and environment that can be accessed via Access or Excel
  • File to contain a record for all ABC clients that have an account with a valid BN
  • Fields to be included:
  • ABC ID
  • Client Name
  • Client Address
  • Account Number and BN for each account owned by the client that had an BN
  • Provide a facility to upload the manually corrected file into the Core Customer Data BN field. This file to include only one BN per ABC ID
  • The upload facility to
  • ensure that BNs are valid as per Attachment D
  • ensure that BNs are not duplicated
  • report validation of duplication errors
  • Relevant customer records in DMA also need to be updated with the same Core Customer Data BN value.
  • Subsequent to this, there will be a population of BN from CIS into ABC.

AN Initial Population Requirements

Notes: The following requirements are based on following statistics about ANs and approach for correcting them:

  • There are 22,000 records with a non-zero AN
  • Of these, 21,000 are unique, leaving approximately 1,000 duplicates
  • These will be fixed manually, either by combining the clients if appropriate or removing the AN from one of the clients
  • Data Prep at Lids to be engaged to perform this work
  • Validate the existing ABC Company Number (CN) field using the check digit validation in Attachment D to determine whether the number stored is a valid AN.
  • If not, delete the entry from the field and report the Party. Details to be reported:
  • ABC ID
  • Client Name
  • Client Address
  • AN that was deleted
  • If valid, leave the AN field as is
  • Provide a file in a format and environment that can be accessed via Access or Excel that lists Parties with duplicate ANs. Details to be included:
  • ABC ID
  • Client Name
  • Client Address
  • AN that is duplicated
  • All Parties with the duplicate AN to be included
  • Subsequent to this, there will be a population of AN from CIS into ABC.
  • The resulting Core Customer Data AN value will be that which is used for the initial conversion/population into DMA.

Source System Account Number Initial Population Requirements

  • Where there is no translation of the source system account number in ABC, this data element will initially be populated with the existing ABC Account Number field for each account.
  • Where there has been translation of the source system account number, source system account number is to be migrated from an alternative source (currently only CommInsure and Paxus account numbers are translated).
  • The State and Branch identifiers are also to be incorporated.

Other Systems Customer Identifiers

Any other existing system identifiers are required to be populated from other systems into ABC, DMA and GDW. The initial list of systems from which this data is to be sourced is:

  • PAXUS
  • CIS
  • CRIL

CommSee Client-to-Client Relationships

Existing CommSec Relationships are to be pre-populated into CLIENT from the CommSee Oracle database currently used, such that these existing relationships can be accessed within CLIENT. There are approximately 332,000 existing relationships (May 04)

The new services which will enable access to this data are defined in Requirement 10.

The existing code tables supporting client-to-client relationships may also need to be updated to support CommSec relationship types not currently supported by ABC. A mapping of ABC to SSV Relationship types is included in Attachment H.

Initial Population Verification

Provide totals (e.g. row counts) to enable confirmation that the initial population has proceeded correctly.


Requirement 3

Modify ABC NT to capture, search for, display and maintain the Core Customer Data.

This requirement comprises:

  • Modifications to the existing ABC NT front-end to reflect the new Core Customer Data elements.
  • Modifications to the ABC NT services to enable users to utilise the data elements in mandatory Core Customer Data.

Modifications to the Client Locate ABC NT online interface:

  • The BN and AN fields are required to be added as search options to the Client Locate online interface (Search Criteria U2W3 Window).
  • BN Field Requirements:
  • BNs are unique, that is, only one legal entity should be using a specific BN.
  • BN – 11-digit numeric field of the display format XX-XXX-XXX-XXX.
  • The BN field is applicable to both persons and non-persons, so needs to be available as a search criterion for both.
  • The BN field is to be used as standalone search criteria, that is, no other fields can also be used as part of the search.
  • It is mandatory to enter a complete BN for search purposes.
  • If there is a direct match, the Client Profile window should automatically be launched with the profile of the matching client loaded, otherwise a message should indicate that there were no matches.
  • AN Field Requirements:
  • ANs are unique, that is, only one legal entity should be using a specific AN.
  • AN – 9-digit numeric field of the display format XXX-XXX-XXX.
  • The AN field is not valid when trying to locate a person, and will only be used when searching for a non-person.
  • The AN field is to be used as standalone search criteria, that is, no other fields can also be used as part of the search.
  • It is mandatory to enter a complete AN for search purposes.
  • If there is a direct match, the Client Profile window should automatically be launched with the profile of the matching client loaded, otherwise a message should indicate that there were no matches.

Modifications to the Personal Details window (U2W2) for Persons

  • The BN field is required to be added to the Personal Details window, from where it will be added or maintained for Persons.
  • BN Field Format – 11-digit numeric field of the display format XX-XXX-XXX-XXX.
  • The BN field for Person clients is optional.
  • The BN field can be populated by :
  • Upon selecting a client from the Search Results, the Personal Details window, accessed from the menu bar on the Client Summary window (U2W2), will display the selected client

’ s personal details including their BN; or

  • If the BN hasn

’ t previously been recorded for the client, or the client is completely new, the BN can be manually entered in the Personal Details window.

  • Upon entering the BN in the Personal Details window, the BN field is required to undergo a check-digit validation as defined in Attachment D.
  • If an invalid or non-unique BN is supplied, an error should be produced to indicate so, with further progress prevented.
  • In addition to the specific new requirements defined above, any validation of existing Core Customer Data fields currently undertaken in ABC NT when creating or maintaining clients is to be continued.

Modifications to the Non Person Details window (U2W4) for Non-Persons

  • The BN field is required to be added to the Non Person Details window, from where it will be added or maintained for Non-Persons.
  • BN Field Format – 11-digit numeric field of the display format XX-XXX-XXX-XXX.
  • The BN field for Non Person clients is optional; however in practice a non person client should have either an BN or AN recorded.
  • The BN field can be populated by:
  • Upon selecting a client from the Search Results, the Non Person Details window, which is accessed from the menu bar on the Client Summary window (U2W2), will display the selected non-person


’ s details including their BN; or

  • If the BN hasn


’ t previously been recorded for the client, or the client is completely new, the BN can be manually entered in the Non Person Details window.

  • There is a requirement to cater for scenarios where a non-person record doesn


’ t have an BN or AN recorded, and a user is attempting to update another component of the client’ s record. The update to the record should be able to proceed, by way of an information message indicating that neither an BN nor AN has been entered, providing the user with the choice of whether they wish to proceed with the update.

  • Upon entering the BN in the Non Person Details window, the BN field is required to undergo a check-digit validation as defined in Attachment D.
  • Also, upon entering the AN in the Non Person Details window, the AN field is required to undergo a check-digit validation as defined ephedrine in Attachment D.
  • If an invalid or non-unique BN or AN is supplied, an error should be produced to indicate so, with further progress prevented.
  • In addition to the specific new requirements defined above, any validation of existing Core Customer Data fields currently undertaken in ABC NT when creating or maintaining quick weight loss clients is to be continued.

Modifications to the ABC NT Client Address fields for Person and Non-Persons

  • The relevant ABC NT screens need to be updated to enable the capture, retrieval and display of the new Overseas Addressing fields, Overseas Suburb and Overseas Postcode. Overseas State, an existing ABC field, should also be available in ABC NT.
  • Overseas Address fields are not required on the Client Locate screen

Incorporate the Source System Account Number in ABC NT

  • The ABC NT screens need to be updated to provide access to the new Source System Account Number field for Persons and Non-Persons.
  • The ABC NT users require the capability to view and maintain the source system account number for a client

’ s portfolio of accounts; therefore client account details need to include Source System Account Number for these purposes.

Wiki Contributors
Collapse Expand Close

View more contributors