Sds Format

15
 Confidential 1 Apaji Instit ute of Mathematic s & Applied Compute r Technologi es Bana sthali Vi dyapit h Software Design S pec ification  [Project Name]  [ Group – I D ]  Submitted By: [Student Name with RollNo.] [Class] Guided By: [Teacher Name]

Transcript of Sds Format

Page 1: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 1/15

 

Confidential 1

Apaji Institute of Mathematics & Applied Computer Technologies

Banasthali Vidyapith

Sof t w are Design Speci f i ca t ion  

[ Pr o j e ct N am e]  

[ Gr o u p – I D]  

Submitted By:

[Student Name with RollNo.][Class]

Guided By:

[Teacher Name]

Page 2: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 2/15

 

Confidential 2

Table of Contents 

1) INTRODUCTION ................................................... ........................................................... .......................................................... 3 

1.1 Purpose of this Document.......................................................................................................................3

1.2 Scope of the Development Project..........................................................................................................31.3 Terms, Definitions, Acronyms, and Abbreviations ................................................................................3

1.4 References...............................................................................................................................................3

1.5 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..................................................................................................................................115) 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

Page 3: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 3/15

 

Confidential 3

1) Introduction

This section provides an overview of the entire design document. This documentdescribes all data, architectural, interface and component-level design for thesoftware.

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 toproperly interpret the SDS. This information may be provided by reference to oneor more appendices in the SDS or by reference to documents. This informationmay 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 asappropriate. 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 foundin the rest of the document. This is *not* simply a table of contents. Motivateand briefly describe the various parts.

Page 4: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 4/15

 

Confidential 4

2) System Architectural Design

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

2.1 High-level Design Overview

Introduce the various components and systems at a high conceptual level. Apictorial representation of the system architecture is presented.

For Example –

?  Traders

?  Back Office

?  Administrators

?  Traders

?  Back Office

?  Administrators

Windows

NT

Server

(Central) 

T1 Leased Line

iBank firewall

Firewall

Page 5: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 5/15

 

Confidential 5

an d 

 

Socket Communication

over GRN/Internet

- Exist Component- External Systems- Data

Orders

Rate

FeedSecurities

Data Base

Market CAAccountOrder

Data

User

WWSS / 

Others

S & P FX-Link iCSBroker

ADP I/F

ADP

- New Component- System Software- Optional case

in project

User

Server

Market

Server

Order

Server

Account

Server

CA

Server

Rate feed

I/FFIX I/F

Servlets

Web server

iStock Server

Client

(Trader)

Trader

(administrator)

XML/HTTPS

Web Interface

Trader / Back

Office Administrators

Page 6: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 6/15

 

Confidential 6

2.2 User Interface Issues

This subsection will present the main principles of the product's userinterface. If you used persons in section 2.1 of the SRS, use them againhere to make specific examples. This section should not touch on the technicaldetails. 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 areelaborated 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 goodidea is to use a simple finite state machine that demonstrates the operation of theproduct you are designing. There should always be explanatory text to help thereader understand any charts.

Page 7: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 7/15

 

Confidential 7

3) Data design

A description of all data structures including internal, global, and temporary datastructures.

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 shouldclearly specify the data entities and relationship between them. Afternormalization, each table must be described with purpose, methods using it, all itsfields description, their data type, and integrity constraints.

For Example –

Page 8: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 8/15

 

Confidential 8

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 implementingthe product.

4.1 Description for Component n

A detailed description of each software component contained within thearchitecture is presented. A description of each major software function, along withdata flow or class hierarchy (OO) is presented.

StaffMember Table

Purpose: This table is used for storing all details related to a staff.

Field Type DescriptionConstraints

StaffMemberId Varchar(9) Id representing a Staff 

StaffName Varchar(90) Name of EmployeeNotnull

StaffType Varchar(1)

Admin

Backoffice

Trader

Profile Varchar(100)

A string of menu id’s for the front end,

stating which functions a user can

access.

StaffStatus Varchar(9)

This field is for Maker-Checker

concept. It can be any one of the

following values –AddPending’,’ModifyPending’,’Ready’ 

Primary Key: Staff Member I d

Foreign Key: staffStatus references ‘paramCode’ in systemParamTbl

Methods using this table

?   AddStaffMember

?   ModifyStaffMember

?   AddPasswordLogon

?   StaffMemberList

Page 9: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 9/15

 

Confidential 9

4.2 Component n interface description.

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

4.3 Component n processing detail

A detailed algorithmic description for each component is presented. A diagramshowing the flow of information through the function and the transformation itundergoes is presented. For Example -

Yes

User

Data

AccountData

Is TPIN right?

Is available balance >transaction amount

(quantity @ indicative price- commission).

Trader inputs the order into World Trader

Yes

Unsuccessfullogin try

No

InsufficientBalance

No

Yes

A

Customer calls the call center andprovides the trader with his accountdetails and any 3 digits of the TPIN

The trader enters the relevant details aboutquantity, indicative price for selling, order

type, order validity

Is user already

TPIN verified?

No

SessionData

Page 10: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 10/15

 

Confidential 10

4.4 Restrictions/limitations

4.5 Data structure/table(s) used

4.6 Performance issues

Special performance required for the component is specified.

Block Account

Purpose

This function is used to block activity on an account. This will stop all

blocks/transactions on the account, unless a ‘ForceTxn’ is denoted.

Input

Field Description

SessionId Session id of the user making the block

FaccountNo Account Number to block

BlockReasonCode Code for the block

BlockReasonText Text describing the reason for the block

Errors/Warnings

Error DescriptionE_ACCOUNT_DOES_NOT_EXIST When the account does not exist

E_ACCOUNT_ALREADY_BLOCKED When the account is already blocked

E_IMPROPER_VALUES

If the necessary input values are

improper then return this error

message

Return Values

Return Value Description

Success MessageError Message

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.

Page 11: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 11/15

 

Confidential 11

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 ispresented.

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’s purpose, datatype, properties and responses for different events.

For Example –

The Execution Order Function

General Detail

Purpose To execute a Buy Transaction

Path The Confirm Transaction function

Page 12: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 12/15

 

Confidential 12

Access Available

to

Administrator

Back Office

Trader

FieldsField Name Qty (Required)

Data type NUMERIC

Size 10

Purpose To enter the quantity of stock to be purchasedValidation Should be a positive integer, with no decimals

Field Name Execution Price (Required)

Data type CURRENCY

Size 6

Purpose To enter the price at which the transaction should beexecuted.

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

6) Design Rationale

This section outlines the critical issues and tradeoffs that were considered ingenerating 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 thedesign

Page 13: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 13/15

 

Confidential 13

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 ispossible 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 andoperating system as the target deployment environment, but the movement from the unit testenvironment 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 theoverall system architecture.

System Tests

The system test environment allows multiple modules to be connected together and executed as ina typical use-case scenario. The choice as to whether this is done on a separate machine from unittesting 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 thatmatches the target environment. Although the system test machine need not match the size of thedeployment 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 asthe 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 issimilar to the target environment. Generally, one server will be enough at this point. However, thecontents 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 areessential to ensuring the accuracy of test results. Plan for at least one more server at this stage intesting.

Stress Tests

Stress tests should be done in an environment identical to the target hosting environment. In thefirst 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 stresstesting.

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 highlystressed in production. So it is important that these conditions be stringently tested during thestress test phase.

Acceptance Tests and Staging

Acceptance tests are generally performed in the same environment as the stress tests, so additionalhardware 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 newenvironment should be created for subsequent development cycles.

Page 14: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 14/15

 

Confidential 14

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.

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.

1

4

5

3

2

6

Path 1: 1 – 2 – 3 – 5 - 6

Path 2: 1 – 2 – 3 – 4 - 6

Page 15: Sds Format

8/3/2019 Sds Format

http://slidepdf.com/reader/full/sds-format 15/15

 

Confidential 15

7.4 Identification of critical components

Those components that are critical and demand particular attention during testingare 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 softwarerequirements is developed.

8.2 Packaging and installation issues

Special considerations for software packaging and installation are presented. ForExample –

8.3 Supplementary information (as required)

Server Side implementation Steps:

The EJBs deployment iStock package requires a Pentium II I machinehaving minimum 256 MB (512 MB recommended) RAM and W indowsNT/ 2000 or LINUX 7.2 as the operating system.

Network should properly installed.

Install WebSphere Application Server & DB2 UDB 7.2 with administrationagent.

Install database first

Then deploy your EJBs on WebSphere application Server

Configure WebSphere Application Server according to your network anddatabase 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 prog ram.