Professional Documents
Culture Documents
Banasthali Vidyapith
Confidential
Table of Contents
1) INTRODUCTION ........................................................................................................................................................................ 3
Purpose of this Document.......................................................................................................................3 Scope of the Development Project..........................................................................................................3 Terms, Definitions, Acronyms, and Abbreviations ................................................................................3 References...............................................................................................................................................3 Overview of Document...........................................................................................................................3
2.1 High-level Design Overview ..................................................................................................................4 2.2 User Interface Issues ...............................................................................................................................6 2.3 Overview of Modules / Layers / Components ........................................................................................6 2.4 Structure and relationships.......................................................................................................................6
3) DATA DESIGN............................................................................................................................................................................. 7
4.1 Description for Component n...................................................................................................................8 4.2 Component n interface description. .........................................................................................................9 4.3 Component n processing detail................................................................................................................9 4.4 Restrictions/limitations ..........................................................................................................................10 4.5 Data structure/table(s) used....................................................................................................................10 4.6 Performance issues.................................................................................................................................10 4.7 Design constraints..................................................................................................................................11
5) USER INTERFACE DESIGN ................................................................................................................................................... 11
5.1 Description of the user interface ............................................................................................................11 5.2 Screen images ........................................................................................................................................11 5.3 Objects and actions ................................................................................................................................11
6) DESIGN RATIONALE.............................................................................................................................................................. 12 7) TESTING ISSUES...................................................................................................................................................................... 13
7.1 Classes of tests .......................................................................................................................................13 7.2 Expected software response...................................................................................................................14 7.3 Performance bounds...............................................................................................................................14 7.4 Identification of critical components .....................................................................................................15
8) APPENDICES............................................................................................................................................................................. 15
8.1 Requirements traceability matrix...........................................................................................................15 8.2 Packaging and installation issues...........................................................................................................15 8.3 Supplementary information (as required) ..............................................................................................15
Confidential
1) Introduction
This section provides an overview of the entire design document. This document describes all data, architectural, interface and component-level design for the software.
1.4 References
This section will include technical books and documents related to design issues. At a minimum, this section should reference the SRS. Give links to documents as appropriate. Be certain that the references you give are complete and in the appropriate format.
Confidential
? ? ?
iBank firewall
T1 Leased Line
Firewall
Confidential
and
Web Interface Trader / Back Office Administrators
Client (Trader)
Trader (administrator)
User Server
Market Server
Order Server
Account Server
CA Server
FIX I/F
User Data
Market Data
Securities Data Base WWSS / Others Rate Feed
Order Data
Orders
Account Data
CA Data
ADP
Confidential
Confidential
3) Data design
A description of all data structures including internal, global, and temporary data structures.
Confidential
StaffMember Table Purpose: Field StaffMemberId StaffName This table is used for storing all details related to a staff. Type Varchar(9) Varchar(90) Description Id representing a Staff Name of Employee Admin Backoffice Trader A string of menu id for the front end, s stating which functions a user can access. This field is for Maker-Checker concept. It can be any one of the following values AddPending ModifyPending Ready , , Not null Constr aints
StaffType
Varchar(1)
Profile
Varchar(100)
StaffStatus
Varchar(9)
Primary Key: Staff Member Id Foreign Key: staffStatus references paramCodein systemParamTbl Methods using this table ? ? ? ? AddStaffMember ModifyStaffMember AddPasswordLogon StaffMemberList
Confidential
Yes
Session Data
No Customer calls the call center and provides the trader with his account details and any 3 digits of the TPIN
Yes
The trader enters the relevant details about quantity, indicative price for selling, order type, order validity
Account Data
No
Insufficient Balance
A
Confidential
Block Account Purpose This function is used to block activity on an account. This will stop all blocks/transactions on the account, unless a ForceTxnis denoted. Input Field SessionId FaccountNo BlockReasonCode BlockReasonText Description Session id of the user making the block Account Number to block Code for the block Text describing the reason for the block Description When the account does not exist When the account is already blocked If the necessary input values are improper then return this error message
Errors/Warnings Error E_ACCOUNT_DOES_NOT_EXIST E_ACCOUNT_ALREADY_BLOCKED E_IMPROPER_VALUES Return Values Return Value Success Message Error Message
Description
Process 1. Check whether that particular account exists or not if it does not exist then return E_ACCOUNT_DOES_NOT_EXIST 2. If the Account exists then check whether that account is already blocked or not .if yes then return a message E_ACCOUNT_ALREADY_BLOCKED 3. If account is not blocked then block that account and return success message.
Confidential
10
Confidential
11
Access Available to Fields Field Name Data type Size Purpose Validation Field Name Data type Size Purpose Validation
Qty (Required)
NUMERIC
10
To enter the quantity of stock to be purchased Should be a positive integer, with no decimals
Execution Price (Required)
CURRENCY
6 To enter the price at which the transaction should be executed.
6) Design Rationale
This section outlines the critical issues and tradeoffs that were considered in generating the design. Its purpose is to document the thought behind the design, and why certain aspects of the design were chosen. This section can also capture good ideas that were abandoned and the reasons for leaving them out of the design
Confidential
12
7) Testing Issues
Test strategy and preliminary test case specification are presented in this section.
For Example
TYPES OF TESTS Unit Tests Unit tests are most commonly done by developers on their own machines or on a common server that is very volatile. It is not necessary that the unit test machines be the same platform and operating system as the target deployment environment, but the movement from the unit test environment to other testing environments should not require material code changes by developers.A plan for one machine per developer plus one small server should be included in the overall system architecture. System Tests The system test environment allows multiple modules to be connected together and executed as in a typical use-case scenario. The choice as to whether this is done on a separate machine from unit testing is up to the implementation and test team. If the target deployment environment is different from the unit test environment, the system test environment should contain a machine that matches the target environment. Although the system test machine need not match the size of the deployment box, it should have the same platform and operating system. A good rule of thumb is to prepare to add one more box for system tests of a smaller size, but the same operating system as the target environment. Again, this will be a relatively volatile environment, so it should not be viewed as a place to do industrial-strength testing by a large team. Integration or Regression Tests To perform integration and regression tests, it is advisable to have a separate environment that is similar to the target environment. Generally, one server will be enough at this point. However, the contents of this server should be strictly controlled. Either the test coordinator or his or her designate should make all software changes to this environment. Stability and auditability are essential to ensuring the accuracy of test results. Plan for at least one more server at this stage in testing. Stress Tests Stress tests should be done in an environment identical to the target hosting environment. In the first development cycle, this can be done in the production site, before the cutover to production. For subsequent development cycles, a separate environment will have to be maintained for stress testing. Plan to replicate the deployment environment as part of the test bed for at least the second development cycle of the site. It has also been observed that the most common problem after performance in a high stress environment is database deadlock due to improper programming. Deadlocks are typically difficult to detect and fix and may not show up until the site is highly stressed in production. So it is important that these conditions be stringently tested during the stress test phase. Acceptance Tests and Staging Acceptance tests are generally performed in the same environment as the stress tests, so additional hardware is not needed to support this phase of testing. Again, during the initial development cycle, the production environment can be used to perform both acceptance testing and staging, but a new environment should be created for subsequent development cycles.
Confidential
13
White-Box Testing This technique cover conditional testing, data flow testing, loop testing. Step 1: Derive Test Cases using the code as a foundation and draw a corresponding flow graph i.e.
1
Path 1: 1 2 3 5 - 6
2
Path 2: 1 2 3 4 - 6
5 6
Step 2: Place the EJB code into scrap book because you can not run EJB code without running test server that takes time. Step 3: Add break points before each control node value in code. Step 4: Run the program and evaluates all possible values and using Step into, Step over check and note the changes accordingly. Step 5: This way java code will be tested for any problems and bugs. 7.2 Expected software response
The expected results from testing are specified.
Confidential
14
8) Appendices
Presents information that supplements the design specification.
Confidential
15