Software Design
Specification
Table of Contents
Table of Contents....................................................................................................................... ii
Revision History........................................................................................................................ iii
Approved By............................................................................................................................. iii
1. Introduction.......................................................................................................................... 1
1.1 Purpose..................................................................................................................................1
1.2 System Overview...................................................................................................................1
1.3 Design Map............................................................................................................................1
1.4 Supporting Materials..............................................................................................................1
1.5 Definitions and Acronyms......................................................................................................1
2. Design Considerations.......................................................................................................... 1
2.1 Assumptions..........................................................................................................................1
2.2 Constraints.............................................................................................................................2
2.3 System Environment..............................................................................................................2
2.4 Design Methodology..............................................................................................................2
2.5 Risks and Volatile Areas........................................................................................................2
3. Architecture.......................................................................................................................... 2
3.1 Overview................................................................................................................................2
3.2 Subsystem, Component, or Module 1 …N..............................................................................2
3.3 Strategy 1…N........................................................................................................................3
4. Database Schema.................................................................................................................. 3
4.1 Tables, Fields and Relationships.............................................................................................3
4.1.1 Databases...........................................................................................................................3
4.1.2 New Tables........................................................................................................................3
4.1.3 New Fields(s).....................................................................................................................3
4.1.4 Fields Change(s)................................................................................................................3
4.1.5 All Other Changes..............................................................................................................3
4.2 Data Migration.......................................................................................................................4
5. High Level Design................................................................................................................ 4
5.1 View / Model Element 1…N..................................................................................................4
6. Low Level Design................................................................................................................. 4
6.1 Module 1…N.........................................................................................................................4
7. User Interface Design........................................................................................................... 4
7.1 Application Controls..............................................................................................................4
7.2 Screen 1… N..........................................................................................................................4
Appendix A: Project Timeline..................................................................................................... 5
Introduction
1.1 Purpose
This design will detail the implementation of the requirements as defined in the Software Requirements
Specification – Binder Workflow – Phase 2.
1.2 System Overview
This project extends the functionality of the Binder Request process that is currently active in PCMS
processes. Additional fields and features will be added to the binder request form, new workflow sub-
processes will be added to the binder request process, and a process report will be developed that is unique
to the binder request process. Metics and TaskViews reports will be available for binder requests, but these
will be implemented as the workflow reporting project and will not be included in this SDS.
1.3 Design Map
SUE - Summarize the information contained within this document or the family of design artifacts. Define
all major design artifacts and/or major sections of this document and if appropriate, provide a brief
summary of each. Discuss any significant relationships between design artifacts and other project artifacts.
1.4 Definitions and Acronyms
Teamplate – 3rd party workflow management software used by Clark Consulting
Process – One instance of a workflow - GI Request, for example
Task – One step or piece of a workflow
Metrics Reporting – Displays process breakdown by task and the amount of time it takes, on
average, to complete a task in a process.
Task Views Reporting – Displays a single process type (Binder Request, Core, etc) tasks
Process Specific Reporting – Process specific reports where the filters are defined on a per process
basis
2. Design Considerations
All design considerations were handled in Binder Release Phase 1.
2.1 Assumptions
Metrics and TaskView reports will be handled in the workflow reporting project.
2.2 Constraints
None that we are aware of.
2.3 System Environment
The Binder Request Workflow process resides in the PCMS system which is a [Link] application that
resides on the client’s machine that has an XP operating system. PCMS is the banking practice’s global
desktop that will be available to all banking practice associates. The database used to store the data will be
SQL Server. Teamplate will be used as the Third Party Workflow product..
2.4 Design Methodology
(Optional) - Summarize the approach that will be used to create and evolve the designs for this system.
Cover any processes, conventions, policies, techniques or other issues which will guide design work.
2.5 Risks and Volatile Areas
None have been identified.
3. Architecture
The architecture provides the top level design view of a system and provides a basis for more detailed
design work
Provide or reference a detailed description and diagrams of the architecture..
3.1 Overview
This section provides a high level overview of the structural and functional decomposition of the system.
Focus on how and why the system was decomposed in a particular way rather than on details of the
particular components. Include information on the major responsibilities and roles the system (or portions)
must play.
3.2 Subsystem, Component, or Module 1 …N
You only need to provide this level of detail for elements which are custom for this design. Do not go into
gory detail. Goal is to get 80% of the elements figured out ahead of time.
Describe an element (subsystem, component, module, etc.) from architecture in further detail. When
appropriate, include information on how the element is further broken down and the interactions and
relationships between these subcomponents.
3.3 Strategy 1…N
Describe the strategy used or decision made. Include information on the alternatives considered and the
reasons for their rejection.
4. Database Schema
4.1 Tables, Fields and Relationships
Provide a description of any new tables, fields and relationships that need to be created for the design.
4.1.1 Databases
BPData production, BPDataPCMSTest for development and testing..
4.1.2 New Tables
List any new tables that will be needed, for each one including table name, table description, and related
tables.
4.1.3 New Fields(s)
List any new tables that will be needed, for each one including table name, table description, and
related tables.
Table Name Field Name Data Type Allow Field Description
Nulls
BinderRequest SellingRep Varchar(50) Get this field from
[Link]
But use actual name (Roy Pinnell)
BinderRequest SigningRep Varchar(50) Get this field from
[Link]
But use actual name (Roy Pinnell)
ProcessBP ParentProcessID Int Yes This will tie a subprocess to a process
BinderRequest ProjectedWireDat Date The earliest [Link] of all
e included policies in the scenario.
4.1.4 Fields Change(s)
For each field change (such as data types, required/not required, or renaming), please complete a row of
the following table. (Insert additional rows as needed.)
Table Name Field Name What to change?
4.1.5 All Other Changes
If any other changes are requested (stored procedures, indexes, relationships, security settings, DTS
packages, maintenance plans, etc), please describe what is needed here.
4.2 Data Migration
(Optional) - Provide a description of how existing data should be migrated to new tables and fields.
5. High Level Design
5.1 Binder Request Form
The notes tab should have fields displayed in the order Date|Author|Note.
Users will select a contact from a dropdown on the binder request form. If no binder contact exists for the
current binder, the user will need to go to the Contacts module and add a binder contact.
Users will now have two places to click to save their binder requests. A new “Submit” button will be added
to the binder request form.
Users will be able to delete binder requests as well. A new “Cancel” button will be added to the binder
request form.
Automatic bank check-in will be removed. The user will be required to manually check in the bank before a
binder request is submitted.
There will be three new fields on the binder request form. “Proposal Rep”, “Signing Rep”, and “Projected
Wire Date” will be added to the form. Whenever a user selects email or fax as a delivery method, these
fields must be set to ‘required’ in the Contacts area of the binder request form.
Account Manager will be added as a new delivery option for both the unsigned and signed delivery method.
5.2 User Interface Modifications
Formatting modifications:
SUE –Will recheck the TRMs for Binder REQUEST.
Process modifications to the User Interface.
Make the task name subprocess reflect the delivery option name.
Null the task completion dates for each process at it’s creation . Teamplate will enter the
completion date.
Automatically generate a note when binder request is created.
Add 30 day, 60 day, 90 day and 120 day tasklists for the [Link] the menu level.
5.3 Workflow sub-processes
Workflow subprocesses will be created for each individual binder in each binder request. The
Teamplate Model that will be used to create the subprocess is called BinderPerCarrier.
Binder Extension subprocesses will be created each time an extension is needed for each binder.
The Teamplate Model name used to create the subprocess is called BinderExtension.
6. User Interface Design
This section provides user interface design descriptions that directly support construction of user interface
screens.
6.1 Application Controls
Detail the common behavior that all screens will have. Common look and feel details such as menus, popup
menus, toolbars, status bar, title bars, drag and drop mouse behavior should be described here.
6.2 Screen 1… N
Illustrate all major user interface screens and describe the behavior and state changes that the user will
experience.
A screen transition diagram or table can optionally be created to illustrate the flow of control through the
various screens.