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]
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
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.
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
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
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.
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 –
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
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
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.
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
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
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.
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
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.
Top Related