High Level Software Requirements

Web-based Financial Supply Chain Exchange

Authors: Ramana
Collaborators Date Approved Projects
Web-based Financial Supply Chain
Manju Rao Exchange OEM
[Type text]

CONFIDENTIAL
The information contained in this document is confidential, and protected from disclosure. If the
reader of this document is not the intended recipient, or an employee or agent responsible for
delivering this document to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately.

Revision History

Date Revisio Description Author

n
1.0 INITIAL REQUIREMENTS RELEASE MC

4 ADDED FUNCTIONALITY TO ENFORCE USER Ramana

UPDATING PASSWORD.
5 CHANGED NAME FROM “MAIN MENU” TO Ramana
“START MP/NET CLIENT”. ALSO MADE
CHANGES TO REFLECT ACTUAL FUNCTIONALITY
AS IT HAS BEEN CHANGED OVER THE LAST
SEVERAL MONTHS TO MEET NEW
REQUIREMENTS.

[Type text]
[Type text]

[Type text]
[Type text]

Table of Contents
1BRIEF DESCRIPTIONOVERVIEW2
2 SCOPE OF WORK2
3 PROCESS SPECIFICATION...............................................................................5
4 PROJECT MANAGEMENT.................................................................................9
5 TECHNOLOGICAL REQUIREMENTS..............................................................15
6 CONTACT..........................................................................................................15

3RELATIONSHIPS...................................................................................................

5
[Type text]

1 Brief Description Project Overview

This document addresses the high-level software requirements for the proposed
Savantis v2.0 Financial Services Exchange (SFSE). The purpose of the SFSE is
to drive paper, costs and IT burden out of the financial supply chain. This system
will marry web-technology and workflow tools with front and back room
processing services, and ultimately financial services, and Automated Clearing
House (ACH) transfer capabilities.
SFSE is design to meet the needs of the primary players within the financial
supply-chain:
 Vendors (billing parties)
 Clients (paying parties)
 Front/Back Room Outsourcing (BPOs)
 Financial Services (Factoring), and Banking Institutions
The system is designed to address those functions and features of greatest
relevance to each of these parties, while not imposing a rigid workflow totally
inconsistent with a “Client” or “Vendors” existing workflow.
The system maintains a series of “portals” with a unique workflow for each of the
groups listed above. These are coordinated through a central application engine.
The application is a hybrid of ASP and intranet based deployment.

2 Scope of Work
 Design, development, testing and deployment of the Savantis Financial
Services Exchange vs2.0 (SFSE) with a web-services based .NET compliant
architecture.
 Project management and technical leadership of the entire development,
management of Indian and US based resources.

2.1.1 Vendor/Biller Portal

Development of a “Vendor/Billers Portal” for the submission of invoices by
vendors to “Clients/Payers” in compliance with industry standards for Electronic
Bill Presentment and Payment (EBPP). This portal must perform the following
functions:
 Secure Registration
 Administration
 Pre-fab tiered access and workflow control (Sr. Admin > Admin > User)
 Parent/Child Company Tracking for complex enterprises
 Searchable Index of Companies (Client/Payers) that will receive
invoices from the system
[Type text]

 Additional registration stages as required by specific “Payer”

workflow
 Application to receive access from “Payer” w/ status report to
interface and e-mail
 Set-up and management of Bank accounts for funds transfer
 Set-up of Credit Cards for use in credits and refunds

2.1.1.1 Manual Invoice Generation

Secure online data entry and submission of invoices (payables) via the SFSE
portal interface.

2.1.1.2 Automated Invoice Submission

The “Automated Invoice Submission” function utilizes Web Service
connection(s) (see Mimeo.com print to web feature for comparison) for all
leading accounting packages, which allow user to “publish” invoices to SFSE,
rather than “print” invoice and mail.

2.1.1.3 Working Invoice Queue

The “Working Invoice Queue” provides a holding space for working invoices
(staging area for incomplete invoices, not ready for submission).

2.1.1.4 Submitted Invoice Queue

The “Submitted Invoice Queue” provides a point for discrepancy notification and
reconciliation real-time through a portal interface. Status reporting (Declined,
Discrepancy, Pending, Approved, Paid, Partial-Paid).

2.1.1.5 Approved Invoice Queue

Invoices upon approval by the “Client/Payer” are moved to the “Approved
Invoice Queue”.
 Once approved, a “Vendor/Biller” can elect through the queue to place
an invoice for “Factoring”. Once the invoice is placed for “Factoring”
the information about the invoice, amount and “approving” entity is sent
to the “Financial Services” portal.
 A digital signature is associated with this funding request, and a log is
generated for all activities within the “Vendor/Biller” portal.
 Factoring companies see the basic information without the contact
information of the “Vendor/Biller”. Factoring companies can then
respond with an offer on the invoice in competition with other factoring
companies.
 The “Vendor/Biller” remains anonymous until they choose a Factoring
Company to service the invoice.
 Upon selection of a “Factoring Company” a digital signature is
[Type text]

associated with all digital documentation required to execute the

funding.
 This information will be accessible through a reporting interface in both
the “Vendor/Biller” portal and the “Financial Services” portal.
 Savantis is paid a margin on all funding that occurs through the SFSE.
 The SFSE engine will track the margin income arrangements made
with the “Factoring Companies” to insure payment is correctly routed.
 Funds will generally be transferred in 24/48 hours via an ACH/EFT into
the “Vendor/Biller’s” ABA account.
 Once an offer is accepted, the SFSE engine is notified, and routing is
automated upon funds disbursement from the “Client/Payer” to the
“Factoring Company”.

2.1.2 Client/Payer Portal

Development of a “Client/Payer” portal that must perform the following functions:
 Administrative Control
 Pre-fab/Customizable access control and workflow control
 Manages internal workflow, routing and escalation
 Dispute and conflict resolution
 Imaging lookup/presentment
 Service Level Agreements (SLA)
 Help-Desk tie-in
 ACH/EFT authorization and transfer
 P-cards integration
 ERP package integration (reporting/reconciliation)
 Legacy integration, PKI w/ digital signatures
 Pre-fabricated and ad-hoc reporting
[Type text]

2.1.3 Financial Portal

Development of a “Financial Portal” for “Factoring Companies”, allowing them to:

3 “Bid” for “approved payables” that “Vendor/Billers” have placed for

factoring.

4 Payables auction, with back-end interfaces for “Factoring Companies”

to set rates, enter banking/financial transaction requirements and
administer user/agent access.

5 Management interface for administering communication/offer process

between “Factoring companies” and anonymous “Vendor/Biller”.

6 Upon winning bid, the portal will manage the ACH/EFT process for the
“Factoring Company” and the “Vendor/Biller”.

7 Upon distribution of funds from the “Client/Payer” to SFSE, the SFSE

routes appropriate payment to the “Factoring Company”.

7.1.1 BPO Portal

The BPO portal already exists in a 1.0 version. Please see the most recent
software requirements documentation for the established functionality of the
existing version. The current version will be enhanced to reflect the following
features:
 Rule base, workflow engine to accommodate specific “Client/Payer”
workflow requirements dynamically through the administrative interface
 Enhanced SLA/Issues resolution engine with automated escalation
based on SLA policies
 Enhanced imaging management features
 ERP Package integration via Web Services
 XML conversion engine for all META data
 Dispute resolution interface
 Enhanced batch and scanning interface
 Industry specific – pre-fab configurations (construction, freight, etc…)
 Bar-code integration and batch/invoice look-up via Bar-code
 Enhanced reporting functionality (pre-fab & ad-hoc queries)
 Digital signatures/PKI integration
 Integrated unified messaging options
[Type text]

8 Process Specification
Our foundational premise is a software engineering approach to web application
development. This process approach aims at producing a highly superior and
much more reliable solution.

8.1 Staged Delivery Model

We use a staged delivery process for most e-business applications. The benefit
of this approach is that critical functionality in applications must be available
earlier so that project risks are reduced early during development and any
problems become evident early.

Application
Concept Staged Application
Delivery Model

Requirement
Analysis

Architectural
Design

Stage 1: Detailed design, code, debug, test & delivery

Stage 2: Detailed design, code, debug, test & delivery

Stage n: Detailed design, code, debug, test & delivery

[Type text]

8.2 Software Development Process

We expect a staged application delivery model indicated below. This is tailored
for the requirements of the specific project. The tailoring is part of the project plan
to be provided to Eccompli Systems/Savantis.

Requirement Analysis Design

Requirement/ & Acceptance Process
Information
Acceptance User Interface User Interface
Requirements Architecture
Criteria Design Acceptance
& Design
Sign-off

Data-source Low-level Code Phased

Architecture Design Construction Development
ASP/VB/VC++ Process
Phased Milestone
Unit Functional System
Deployment Acceptance &
Testing Testing Tests
& Release Completion

Acceptance
Final Final Process
Final Training Warranty
System Acceptance &
Deployment & Handoff Maintenance
Tests Completion

Performance Post-Delivery
Performance
Testing Maintenance
Tuning
System Audit

8.2.1 Requirement Analysis & Acceptance Definition

A detailed requirement analysis will be done at in order to draft the technical
specification. In addition to this the acceptance criteria for the application will be
established.
The sign-off on technical specification indicates a jointly committed base-line for
expectations, with respect to which any future changes requests will be tracked.
Sign-off on acceptance criteria indicates a minimum level of expectation the
products must meet, in order for to deem the product as acceptable.
[Type text]

8.2.2 Information Architecture & Design

The focus of this phase will be developing architectural design document,
functional specifications, interface definitions and data source design for the
application.
We adopt the following standards for Information Architecture:
 Unified Modeling Language (UML) (as appropriate)
 Use Case Diagrams
 Class Diagrams
 Sequence Diagrams
 Collaboration Diagrams
 State Charts
 Component Diagram
 Activity Diagrams
 Entity Relationship Design (ERD) and Data Flow Diagrams (DFD)

8.2.3 Code Construction

The application will be coded and inspected based on industry best-practice
coding standards and conventions. Code validation is to be performed with a
system of “peer reviews”, where developers exchange the code. Remarks on
code inspection are documented.
Coding goes on till a release is declared as “code-freeze”. After this milestone,
the focus is on fixing the code for defects. A “code-freeze” is defined as the point
at which the software performs the functions detailed in the approved technical
specification document. Coding stops at this point and the focus moves to error
checking and repair. Changes made at this point are extremely impactful on
project timelines and budgets, thus any change made during this time must be
seriously weighed before authorization.
The code is versioned using Microsoft Visual SourceSafe or a similar code
storage utility.

8.2.4 Application Integration & Installation

The application integration & installation process will focus on making the
application available for testing. It may be possible that this may be done in a few
incremental iterations of releases.
Every release is accompanied by a release note from the Project
Manager/Technical Lead (PM/TL) about the additions /changes to the release, as
well as any known defects.User Validation Testing
Based on the requirement specification, test plans are created. Interactive tests
[Type text]

are carried out against these test-plans for every phased release of the
application. We have a
dedicated and independent Entered
Defect Lifecycle
by Submitter Designated
team to carry out the testing. New
DefectID

Defects reported by testing Assigned by

are submitted to developers Assigned

PM/TL
Resolved by
via a defect tracking system. Developer
Reopen
The defined defects are Resolved

validated and then resolved Unconfirmed Wontfix

by developers. Next, the Invalid Worksforme Verified

testers verify if defects are by QA

actually resolved, and Verified

Closed
defects that aren’t resolved by
Submitter
are re-opened.
Closed
will be provided access to a
defect tracking system on request.
After code-freeze, the focus is entirely on fixing code for defects.
Known defects are reported along with release notes.

8.3 Documentation Standards

All documentation will be done as per industry best-practice standards which is a
combination of:
 Rational Unified Process (RUP)
 UML
Significant attention is to be paid to creating, reviewing and continually updating
system and user documentation. This is to be an enterprise level, supported
package with a high-degree of accountability in the code-writing, and support
process.

8.4 Source Control Standards

All Source Control will be done using Visual Source Safe or a similar code
storage utility with strict version control and accountability.
[Type text]

9 Project Management

9.1 Management Approach

Steering team meetings will be held on monthly basis, and will assess project
status, and address issues and risks during the course of the project.

Steering Team Members Organization Represented

Client representative TBD
Client IT Contact TBD
Account Manager TBD
Sr. Project Director TBD
Project Manger TBD
Technical Lead TBD

9.2 Project Delivery Organization

Project
Director

Project Account
Manager Manager

Manager Technical
Technical
QA Technical
Lead
Lead
Lead

UI & Graphic Technical

Technical Technical
Developers Technical
Testers Technical
Technical
Designers Technical Technical Technical
Writers
Lead Lead Lead Lead
Lead Lead Lead Lead

The organization of delivery is indicated below:

[Type text]

Role Responsibility
Account Manager Responsible for any escalations &
commercials
General Manager- SW Action on escalations
Development
Manager QA Responsible for adherence to Quality
system
Project Manager Responsible for schedules, change
management, tracking & reporting, risk
management & delivery
Technical Lead Responsible for technical delivery &
architecture
UI & Graphic Designer Responsible for “look and feel” and
usability
Senior Developer/ Developer Responsible for quality of application
Tester Responsible for robustness and
performance of app.
Technical Writer Responsible for online documentation

9.3 Project Management Practices

9.3.1 Project Management Plan

A detailed Project Plan will be shared with using MS Project 2000 format.

9.3.2 Project Reviews

The following reviews are held during the project lifecycle.
Name of Review When/Why/Who
Requirements When: During completion of requirements phase
Review Purpose: Verify and sign off requirements
specification
Who: Steering Team
Requirements QA When: After functional requirements are complete
Purpose: Review requirement specification from a
Quality Assurance point of view
Who: Project Team, QA Representative
Design Review When: Completion of design phase
Purpose: Signoff functional specifications
Who: Steering Team
[Type text]

Detailed Design When: After detailed design and system architecture

QA are complete
Purpose: Review detailed design and system
documentation and approach from QA and testing
stand-point
Who: Project team, QA
Code Reviews When: During construction phase
Purpose: Quality of coding
Who: Project Team
Test Plan When: At the end of Detailed design phase
Reviews Purpose: Quality of testing
Who: Project team
Pre-Deployment When: Release of every build to production
Reviews Purpose: Build release note
Who: Project Team
Project When: Project deployment
Completion Purpose: Verify successful project completion
Reviews Who: Steering Team

9.3.3 Configuration Management

All work-products are maintained under version control. SourceSafe is used for
this purpose.
Configuration Approach Who
Management Steps
Version Identification Identify staged builds delivered Project Team
and internal builds. Identify
product baselines
Identify Configuration Identify all work-products to be Project Team
Items put under version control
Track change control Review change control Build Engineer
Build released - testing The build is staged for the specific Project Manager
purpose of testing and Build
Engineer
Build release Build released for production. Project Manager
Along with release note.
[Type text]

9.3.4 Issue Management

The project team uses issue management methods.
IM Steps Approach Who
Submit issue Enter issue in issue log (online) All
Review issue Review issue in weekly meeting Project Team
or immediately depending on
severity level
Issue disposition Assign responsibility of Project Manager
addressing issue and follow-up
Notify all involved Update the issue log with the Project Manager
action taken and notify all
involved people
Close out issue Close the issue, update issue log Project Manager

9.3.5 Change Management

We understand that software development is but a translation of an idea.
Changes are integral to any software development, and hence are to be provided
for as a process.
We use the signed requirement specification as baseline to define changes in
requirements. The project team uses change management methods.
CM Steps Approach Who
Submit change Enter the change in change log (online) All
request
Review and Review and changes in weekly meeting Project Team
notify impact depending on severity level. Notify all
(schedule and people involved
costs)
Approve Get e-mail or fax approval to act on Customer or
changes changes. Alternatively reject, defer or Steering
re-visit impact Committee
Implement Incorporate changes. Update all Development
changes affected documentation. team
Close change Close the change, update change log. Project Manager
Investment Raise invoice on customer approved Account
changes changes Manager
[Type text]

9.3.6 Risk Management

The PM is responsible to identify for relevant risks, and the plans to manage
them. The project team uses risk management methods.
RM Steps Approach Who
Submit risks Enter the risk in risk log (spreadsheet) All
Review risks and Review and rank risk in weekly meeting Project Team
rank (probability, depending on severity level
impact)
Mitigation Develop mitigation plan and assign Project Manager
planning responsibility
Tracking of Update the risk log with the mitigation Project Manager
mitigation actions plan, notify all involved people, and
and risks track status of mitigation plan
Close out risk Close the risk, update risk log Project Manager

9.3.7 Project Status Reporting and Communication

The Project Manager is responsible for providing weekly status reports directly to
the Steering Committee coordinator. The status report focuses on progress, plan
for upcoming week, issues pending with customer, status on defect & changes
and known risks.
Residential phone-numbers and mobile numbers of key people Project Manager/
Technical Leads are provided for 24x7 access.
All communication is generally handled through e-mail.
As required there may be telephonic or video conference to address specific
issues or discussions. All meetings are planned, in advance, with an agenda and
followed up with record/minutes of discussion. All participants confirm the
minutes.

Type Project Tracking

Method Project schedule updates
Status reports
Update risks, issues and changes
(Internal) Senior Management Reviews
Frequency Weekly status reports
Biweekly project team reviews
Monthly Steering Committee members
Reports delivered to Steering team members
Tools used MS Project
Web-based Project Portal/Extranet
Excel
Person responsible Project Manager
[Type text]

9.3.8 Project Acceptance Procedure

For deliverables that require customer sign off, will have seven business days
after delivery of item to sign-off. If the deliverable is not signed off within the
seven-day period, the deliverable will be considered accepted by default

Deliverables/Major Acceptance Criteria Acceptance Procedure

Features
Requirement Customer review and Requirements review
Specification sign-off
Functional Specification Customer review and Design review
System Architecture sign-off
Detailed Project
Schedule
Acceptance Test Plan
Application Acceptance test plan Pre-deployment review
Implemented based on requirements
and functional spec
Project closeout plan Successful acceptance Project Compilation
tests Review with Steering
Team

9.3.9 Escalation Policy

If wishes any matter of concern may be escalated to the following people, in
order of increasing priority
Name Designation E-mail
TBD TBD TBD
TBD TBD TBD
TBD TBD TBD
TBD TBD TBD
[Type text]

10 Technological Requirements
A portion of the technological requirements are defined below, other are yet to be
determined (based on feedback from developer):
 Currently runs on Win. 2000 AS, IIS 5.0, MS SQL 2000 (standard)
 Proposed solution platform TBD – based on portal requirements, and
developer input (BEA, Oracle 9i - ???)
 Best-of-Breed portal software base to support rapid development and
enterprise workload (SilverStream, PlumTree, ClearPath - ???)
 Web service (.NET) compliant architecture to support integration with
ERPs, legacy, Vendor Financial Packages, reporting and reconciliation
functions, and ease of future release/updates to client-side software
 Enterprise level infrastructure capable of managing 158,000,000
transactions a day
 Multi-language, and double-bit character set support for international
functionality
 Installed and ASP version of package with associated documentation for
Field Engineers
 Installed version – Web Service to report transaction volumes
 NAS/SAN storage support for imaging data
 Fast-search technology integration
 RSA SecurID Tokens for Login Authentication
 Internet Explorer 5.0 + Browser Requirement