Professional Documents
Culture Documents
SAMPLE
Requirements Examples
DAVID M WALKER
Version: 0.1
Date: 01/01/2006
Table of Contents
Table of Contents ...................................................................................................................... 2
Synopsis .................................................................................................................................... 3
Intended Audience .................................................................................................................... 3
About Data Management & Warehousing ................................................................................. 3
Business Requirements ............................................................................................................ 4
Data Requirements ................................................................................................................... 9
Dimensions ........................................................................................................................... 9
Performance Measures ....................................................................................................... 11
Query Requirements ............................................................................................................... 15
Interface Requirements ........................................................................................................... 16
Copyright ................................................................................................................................. 17
Page 2
Synopsis
This document has a number of samples of completed sections from the four sets of
requirements (Business, Data, Query and Interface) to aid analysts in completing their own
templates. The requirements are a merger of actual requirements taken from Telcos around
the world. They are not consistent nor should anything be read into any requirements as
coming from any particular operator. There are no examples from the Technical
Requirements as they do not have the same form of template table.
Intended Audience
Reader
Executive
Business Users
IT Management
IT Strategy
IT Project Management
IT Developers
Recommended Reading
Synopsis through to Background
Synopsis through to Background
Entire Document
Entire Document
Entire Document
Entire Document
Page 3
Business Requirements
BUSINESS REQUIREMENT
Business Requirement Number
1
Organisations & Individuals (Customers)
Business Requirement Name
Priority
High
Currently available in the Data Warehouse
Yes
Description
There is a requirement to hold details and build a history of customers activities with Telco,
tracking them through their Telco relationship life cycle, from initial marketing prospect,
through sales, service provisioning, billing, etc.
Organisations and individuals include customers and prospects for Telco products and
services and all others for which information can be obtained. Organisations may also be
OLO (Other Licensed Operators) network customers, third-party dealers, the customers of
third-party dealers, and other organisations such as Telco own business units, OFTEL,
contractors, suppliers, etc.
Note: prospects details are only required for prospects that have become customers or
prospects that form part of the Target Account List.
The information held for organisations and individuals must include name, address,
postcode, etc. and a standardised version the customer name into a common search
format.
For organisations, other details should include:
A detail of all organisations sites e.g. addresses and service locations of installed
equipment.
The relationships between organisations and individuals must be maintained, e.g. multiple
contacts for customer organisations. This should include the individuals full contact details
and what they do, such as influencers, decision makers, finance/procurement contact, IT
director or contact, telephony contact, billing contact, data network contact, marketing
contact, etc.
These is also a need to hold enhanced profile information about organisations such as:
Telecomm profile - Comms spend (not just with Telco), telecomm products/services
used, equipment used, other suppliers used (and products), PBX supplier.
There is a need to maintain a history of the relationship between a customer and other
associated information. This information includes contracts, orders, products and services,
accounts, usage, non-usage, billing, payments, contacts, faults, sites, telephone numbers,
sales channels, sales account manager, market segmentation, etc.
Page 4
Sales channel related hierarchies, i.e. how sales view their customers.
Over time, as history information is accumulated, these hierarchies will allow detailed
analysis of behaviour to be performed by relating the revenue, product, account, orders etc.
together for an organisational structure.
There is a requirement to have the ability to monitor and analyse
Customer profitability. Initially this will only include interconnect in-payments / outpayments against products and services delivered. When available, sources of
actual cost information should be included.
Customer details, e.g. monthly numbers and revenue, by customer life cycle status,
customer hierarchy level, SOV (Sales Order Value), product, price package,
discount plan, actual and potential comms spend, installed equipment, geography,
campaign response or marketing activity, market segment, sector.
Number and names of customers lost, their worth and billing trends.
Other patterns in the customer base, e.g. customer lifecycle, customer historic
trends, customer buying cycle, customer revenue, cost profiles, profitable/nonprofitable, customer site moves, etc.
The dealer and reseller relationship, including revenue and payments, by call type,
Page 5
national, mobile, international, etc. Also, aggregate third party customers into their
respective dealers / suppliers.
Existing resellers and dealers to identify potential reseller and dealer companies.
OLO customer revenue (in-payments and out-payments) and usage patterns and
trends, by routes/points of interconnect, tail costs, time of day, inbound, outbound,
etc.
Dealer: A dealer is a third party organisation that has an existing business base
through which it can sell standard Telco Branded Products. Telco owns the
customer and consequently the Customer benefits from 24hr customer care and
management reports etc. In return for acquiring customers on Telcos behalf the
dealer receives an ongoing 'revenue share this is a proportion the customers
billing.
Reseller: The Reseller purchases Telco products at wholesale rates and 'resells'
them under their own brand. The contractual relationship is between the reseller
and the customer, not Telco. The reseller sets his own retail pricing, bills the
customer, arranges premise routing and provides customer care. Telco will provide
the reseller with a monthly wholesale bill and provide customer care for bill queries
and network faults to the reseller only, contact is not made between Telco and the
reseller's customer.
The reseller can be further subdivided into two groups: those who aggregate carrier
Page 6
minutes (an Aggregator) and those who merely resell (Direct Reseller) from one or
two carriers.
Aggregator: By using 'smart' MLU technology e.g. black box or via sophisticated
PBX software, customer premise routing is made over a number of carriers
according to price.
Aggregators are able to maximise their buying power to secure the best possible
rate for each route. Aggregators approach customers as an independent telecomm
provider. The offer is to remove the purchase and pricing decision from the
customer by pooling rates from all carriers and therefore always offering the best
possible combination of rates. Effectively they will manage a customers telephony
needs.
The solution should not support lead tracking, contact management - Not all the
information that the sales force will require is likely to be held in the warehouse as
this will not be a suitable repository.
Customer profitability - Initially this will only include interconnect payments/outpayments against products and services delivered. Sources of actual cost
information to be investigated and reported on when available.
Performance Measures
Data Overview
Dimensionality / Ordered By / Described By
Turnover
Number of sites
Number of employees
Telco spend (actual and potential)
Account measures
Revenue
Payment amount
Term
Number of accounts
Customer measures
Profitability
Worth
Churn
Number of customers
SOV (Sales order value)
Network event measures (usage)
Network tail cost
Price, charge, discount (usage,
non-usage)
Technical Assessment
Page 7
Other Comments
Page 8
Data Requirements
Dimensions
Dimension Number
Dimension Name
Description
DIMENSION
1
Party
The Party dimension represents individuals, their parent organisations and the higher-level organisation
structure.
Hierarchy Structure
Holding
Company
Customer Reporting
Hierarchy
Customer
Group
Customer
Account
Customer
Site
Customer
Line Identity
Business and trading names of an organisation and all its subsidiaries and parent
companies.
Page 9
Sales channel related hierarchies, i.e. how sales view their customers.
Organisations also include third-party dealers, the customers of third-party dealers, OFTEL,
contractors and suppliers. No hierarchical structure within any of these is required.
Data Steward
Status Changes (Slowly Changing Dimensions)
The customer reporting hierarchy is likely to change at a rate between quarterly and annually.
The Telco sales organisation is likely to change at a rate between monthly for small changes
and annually for large changes.
Currently available in the Data Warehouse
Limitations of current availability
Yes
Implementation Notes
Customers are the holders of (active or deactivated) billing system accounts.
Page 10
Performance Measures
PERFORMANCE MEASURE
Performance Measure Number
1
Vanilla Rated Call Revenue Amount
Performance Measure Name
Measure Type
Basic
Definition
The Vanilla Rated Call Revenue is the amount of revenue generated by a call, and is attached to
a Call Detail Record (CDR) by the first pass of the rating engine.
Additional Commentary
As such, this Vanilla Rated Call Revenue Amount is the basic revenue value attached
to the call record, and includes factors such as the time of day the call was made, the
day of the week, the message source code, the charge band and the specific rating
group.
It excludes any subsequent rating changes that are applied by the billing system, which
turn Vanilla Rated Call Revenue into the Re-Rated Call Revenue.
The Vanilla Rated Call Revenue Amount could also loosely be referred to as unbilled
usage revenue, and should therefore have a revenue status type of unbilled usage
revenue.
Data Steward
Dimensionality / Ordered By / Described By
Yes
For unbilled usage: Vanilla Rated Call Revenue Amount will be accumulated alongside
the Call Duration on a daily basis by telephone number per bill cycle, and will be zeroed
at the start of each bill production run for that telephone number. A later increment
may load individual unbilled usage revenue at the CDR level for both Vanilla Rated Call
Revenue and Call Duration.
Page 11
For billed usage: Vanilla Rated Call Revenue Amount will be stored at the individual
CDR level alongside the Call Duration and the Re-Rated Call Revenue Amount.
Description of Known Data Quality Problems
Page 12
PERFORMANCE MEASURE
Performance Measure Number
2
Number of Services
Performance Measure Name
Measure Type
Count
Definition
The Number of Services is an aggregated performance measure that is a simple count
of the number of occurrences of at least one instance of a product/service code at a
particular chosen level of interrogation
Additional Commentary
For example we may wish to know the number of different service codes and their
descriptions by account number and service location, in order to explore service mix.
Data Steward
Dimensionality / Ordered By / Described By
Yes
Implementation Notes
Page 13
PERFORMANCE MEASURE
Performance Measure Number
3
Performance Measure Name
Bill Balance Brought Forward Amount
Measure Type
Derived
Definition
The Bill Balance Brought Forward Amount is the balance brought forward from the
previous bill cycle's bill
Additional Commentary
The Bill Balance Brought Forward Amount should be the same as the previous bill
cycles Bill Balance Carried Forward Amount.
The Bill Balance Brought Forward Amount will be sourced directly from the source
billing systems.
Data Steward
Dimensionality / Ordered By / Described By
Yes
The speed of response will depend on the available level of pre-calculated aggregates.
This information could be made available from the source systems should the Systems
Roadmap point to this being an area of high priority.
Description of Known Data Quality Problems
Implementation Notes
Page 14
Query Requirements
Query Requirement Number
Query Requirement Name
Description
Query Requirement
1
Credit/aged report
A report that show the outstanding debt by account and credit group
Definition of Key Terms
Requested by
Data Overview
Debts by account and how long that debt has been outstanding
Performance Measures
credit limit
current balance
balance 30 days
balance 60 days
balance 90 days
balance 120+ days
credit class
account number
bill cycle/run
Technical Assessment
Other Comments
Frequency
Type
Weekly
Regular
Page 15
Interface Requirements
Interface Number
Interface Name
Target System Name
Output Type
Output Location
Output File Name
Output File Type
Output Format
Output Character Set
Output Frequency
CSV Specifics
Field Separator
Record Separator
Quoting Character
Escaping Character
XML Specifics
Validation
Validation Location
Description/Purpose of File
Interface
1
Customer Segmentation Groups
CRM System
File
/BI/ftp/outgoing/CRM
csg.csv
CSV
ASCII
US-ASCII
Daily
Comma (,)
Carriage Return Line Feed
Double Quote ()
Double Quote ()
This file is used to update the CRM system with the current market segment group and
score information
Data Definition
Field Name
Customer_id
Market_Segment
Segment_Score
Mandatory?
Yes
Yes
Yes
Yes / No
Yes / No
Yes / No
Yes / No
Yes / No
Yes / No
Yes / No
Yes
Implementation Notes
Page 16
Copyright
2006 Data Management & Warehousing. All rights reserved. Reproduction not permitted
without written authorisation. References to other companies and their products use
trademarks owned by the respective companies and are for reference purposes only.
Page 17