Apaji Institute of Mathematics & Applied Computer Technologies

Banasthali Vidyapith

Software Design Specification [Project Name] [Group ID]

Guided By: [Teacher Name] Submitted By: [Student Name with RollNo.] [Class]

Confidential

Table of Contents
1) INTRODUCTION ........................................................................................................................................................................ 3

1.1 1.2 1.3 1.4 1.5

Purpose of this Document.......................................................................................................................3 Scope of the Development Project..........................................................................................................3 Terms, Definitions, Acronyms, and Abbreviations ................................................................................3 References...............................................................................................................................................3 Overview of Document...........................................................................................................................3

2) SYSTEM ARCHITECTURAL DESIGN ................................................................................................................................... 4

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

3.1 Temporary data structure .........................................................................................................................7 3.2 Database description ................................................................................................................................7

4) DETAILED DESCRIPTION OF COMPONENTS.................................................................................................................. 8

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.1 Purpose of this Document

Full description of the main objectives of the SDS document.

1.2 Scope of the Development Project

This will be similar to what was written in the SRS.

1.3 Terms, Definitions, Acronyms, and Abbreviations

Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SDS. This information may be provided by reference to one or more appendices in the SDS or by reference to documents. This information may be provided by reference to an Appendix.

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.

1.5 Overview of Document

A short description of how the rest of the SDS is organized and what can be found in the rest of the document. This is *not* simply a table of contents. Motivate and briefly describe the various parts.

Confidential

2) System Architectural Design

NOTE: This section is the main focus of the high-level conceptual design. The reader should come away with a good view of exactly how your solution is to be organized.

2.1 High-level Design Overview

Introduce the various components and systems at a high conceptual level. A pictorial representation of the system architecture is presented. For Example
? ? ? Traders Back Office Administrators

? ? ?

Traders Back Office Administrators

iBank firewall

T1 Leased Line

Windows NT Server (Central)

Firewall

Confidential

and
Web Interface Trader / Back Office Administrators

XML/HTTPS Web server

Client (Trader)

Trader (administrator)

Socket Communication over GRN/Internet

Servlets iStock Server

User Server

Market Server

Order Server

Account Server

CA Server

Rate feed I/F

FIX I/F

User Data

Market Data
Securities Data Base WWSS / Others Rate Feed

Order Data

Orders

Account Data

CA Data

ADP I/F S&P FX-Link iCSBroker

ADP

- Data - Optional case in project

- External Systems - System Software

- Exist Component - New Component

Confidential

2.2 User Interface Issues

This subsection will present the main principles of the product's user interface. If you used persons in section 2.1 of the SRS, use them again here to make specific examples. This section should not touch on the technical details. You may want to include sketches and/or specific text messages of the user interface.

2.3 Overview of Modules / Layers / Components

This subsection will introduce the various components and subsystems that are elaborated in section 4.

2.4 Structure and relationships

This subsection will make clear the interrelationships and dependencies between modules/layers/components. Structure charts can be useful here. Another good idea is to use a simple finite state machine that demonstrates the operation of the product you are designing. There should always be explanatory text to help the reader understand any charts.

Confidential

3) Data design
A description of all data structures including internal, global, and temporary data structures.

3.1 Temporary data structure

Files created for interim use are described.

3.2 Database description

Database(s) created as part of the application is (are) described. E-R Model should clearly specify the data entities and relationship between them. After normalization, each table must be described with purpose, methods using it, all its fields description, their data type, and integrity constraints. For Example

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

4) Detailed Description of Components

NOTE: This section is the main focus of the technical design portion of the SDS, the detailed design. This section will provide most of the basis for implementing the product.

4.1 Description for Component n

A detailed description of each software component contained within the architecture is presented. A description of each major software function, along with data flow or class hierarchy (OO) is presented.

Confidential

4.2 Component n interface description.

A detailed description of the input and output interfaces for the component is presented.

4.3 Component n processing detail

A detailed algorithmic description for each component is presented. A diagram showing the flow of information through the function and the transformation it undergoes is presented. For Example -

Yes

Is user already TPIN verified?

Session Data

No Customer calls the call center and provides the trader with his account details and any 3 digits of the TPIN

No User Data Is TPIN right? Unsuccessful login try

Yes

The trader enters the relevant details about quantity, indicative price for selling, order type, order validity

Account Data

Is available balance > transaction amount (quantity @ indicative price - commission).

No

Insufficient Balance

Yes Trader inputs the order into World Trader

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.

4.4 Restrictions/limitations 4.5 Data structure/table(s) used 4.6 Performance issues

Special performance required for the component is specified.

Confidential

10

4.7 Design constraints

Any design constraints that will impact the component are noted.

Note: Section 4.1 to 4.7 is repeated for each of n components.

5) User Interface Design

A description of the user interface design of the software is presented.

5.1 Description of the user interface

A detailed description of user interface including screen images or prototype is presented.

5.2 Screen images

Representation of the interface form from the user's point of view.

5.3 Objects and actions

All screen objects and actions are identified. Describe each object purpose, data s type, properties and responses for different events. For Example

The Execution Order Function

General Detail Purpose Path

To execute a Buy Transaction The Confirm Transaction function

Confidential

11

Access Available to Fields Field Name Data type Size Purpose Validation Field Name Data type Size Purpose Validation

Administrator Back Office Trader

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.

Should be a positive integer, and allow up 5 decimal places

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.

7.1 Classes of tests

The types of tests to be conducted are specified, including as much detail as is possible at this stage.

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.

7.3 Performance bounds

Special performance requirements are specified.

Confidential

14

7.4 Identification of critical components

Those components that are critical and demand particular attention during testing are identified.

8) Appendices
Presents information that supplements the design specification.

8.1 Requirements traceability matrix

A matrix that traces stated components and data structures to software requirements is developed.

8.2 Packaging and installation issues

Special considerations for software packaging and installation are presented. For Example
Server Side implementation Steps: The EJBs deployment iStock package requires a Pentium III machine having minimum 256 MB (512 MB recommended) RAM and Windows NT/2000 or LINUX 7.2 as the operating system. Network should properly installed. Install WebSphere Application Server & DB2 UDB 7.2 with administration agent. Install database first Then deploy your EJBs on WebSphere application Server Configure WebSphere Application Server according to your network and database settings EJBs, servlets and JSPs are ready to from this server Client side implementation Steps: iStock package client side requires a Pentium machine having minimum 64 MB RAM and Windows or LINUX as the operating system. Install network properly. Install Java Virtual Machine and any Java enabled web browser (IE/NN). Start the program jar to run your program.

8.3 Supplementary information (as required)

Confidential

15