Online Stock Brokerage System

Submitted by: Gouthami Chintalapani
Instructors: Mark Austin and John Baras
ENSE 623: Systems Validation and Verification, Fall 2003.

TABLE OF CONTENTS

  1. Introduction
    Purpose : Setup problem.
    Topics : Overview of online brokerage system architecture; system framework and boundary, terminology.

  2. Goals, Scenarios, and Use Cases
    Purpose : Develop use cases, scenarios and system requirements.
    Topics : Goals and scenarios; actors; initial use cases with activity diagrams.

  3. Generation of Requirements from Use Cases
    Purpose : Generate system/subsystem requiremens.
    Topics : Generate the high level or system requirements from the use cases, synthesize and break down high level requirements into low level requirements, Organize the requirements into layers, traceability of requirements to use cases and scenarios.

  4. Models of System Behavior and System Structure
    Purpose : Create simplified models of behavior and structure.
    Topics : Models of system behavior; models of system structure.

  5. System Level Design
    Purpose : Create architecture-level (logical) design of the system
    Topics : Map chunks of system behavior onto system structure, create logical and physical system design, requirements allocation.

  6. System Design Structure Matrix
  7. System Specifications
    Purpose : Generate the specifications of the requirements to do trade off analysis
    Topics : Assign quantitative and qualitative values to the requirements, and generate specifications.

  8. Systems Trade Off Analysis
    Purpose : Create framework for trade-off analysis for selection of components in a small subsystem.
    Topics : System performance and economics; decision variables; CPLEX problem formulation; trade-off scenarios and analysis results.

  9. Component - System Testing
    Purpose : Develop procedures of system test, verification and validation.
    Topics : Primary Verification plan, Verification traceability matrix, VSN (Verification String Number)s, Coverage and Completeness.

  10. Conclusions
  11. References and Web Resources
  12. Appendix

1. Problem Statement

The purpose of this project is to apply the systems engineering principles, the knowledge of UML and the systems validation and verification strategies to design Online Stock Brokerage System. The online stock brokerage system facilitates the users i.e., individual investors to trade (buy, sell, etc) the stocks online through the internet. It allows clients to keep track of, and execute their transactions, shows performance charts of different stocks in their portfolios, provides security for their transactions, and alerts them to pre-defined levels of changes in stocks, with out the use of any middlemen. The main emphasis of the project in this course is on the systems validation and verification strategies.

1.1 Introduction

Online stock brokerage system automates the traditional stock trading using computers and the internet, making the transaction faster and cheaper. This system also gives faster access to stock reports, current market trends and real time stock prices.

The online stock trading system utilizes the three-layer architecture, consisting of a front-end system, middleware and back-end system, as explained in the following figure.

Figure 1. Online Stock Brokerage System Architecture

1.2 Project Outline

The system design is accomplished using the three-tier architecture explained above and applying the systems engineering principles. Initially use case analysis is done based on the customer/stake holder requirements. From the use case analysis, high-level system requirements are generated and are further synthesized and broke down into low-level requirements. A system structure model consisting of all system components and the interfaces through which components interact with each other is developed. Then the system behavior model is developed.  By mapping the chunks of system behavior onto system structure, a simplified model of the logical system is developed. And then the system tradeoff analysis is carried out to come up with various design alternatives from the system specifications, after allocating requirements to the objects and attributes of system structure. System testing, validation and verification procedures are developed to check the two basic concerns: “are we building the right system?” and “ are we building the system right?” followed by conclusions and references.

1.3 Terminology

1.4 System Framework and Boundary

The online brokerage system is composed of the aforementioned loosely coupled systems, and an interactive model is depicted in the following schematic.

Figure 2. Component interaction model for the Brokerage System

1.5 Assumptions

2. Goals, Scenarios and Use Cases

In this section, various scenarios developed from the stake-holders requirements are recognized through use cases which in case are represented by activity diagrams.

2.1 Goals and Scenarios

Goal 1: The system must be secure.

Goal 2: The system must be efficient.

Goal 3: The system must be economic.

Goal 4: The system must be usable.

Goal 5: The system must be reliable.

Goal 6: The system must be easy to maintain.

Goal 7: The system must track the transactions carefully.

2.2 Use Case Analysis

2.2.1 Actors

2.2.2 Identify the roles of actors

2.2.3 Initial Use Case Modeling

The use cases represent system goals or system functions. A uses case is an abstraction of a system response to external inputs, and accomplishes a task that is important from user’s point of view.

Figure 3. Initial use-case diagram of Online Brokerage System.

2.2.4 Baseline (Textual) Use Cases

In this section, textual use cases are described and activity diagrams are presented to make up the expanded use cases.

Use Case 1: New user registration

 Description
    Investor registers with the brokerage system to use its services.
 Primary Actor
    Investor.
 Pre-condition
    Investor agrees to use the brokerage services by investing some amount initially.

 Flow of Events:

1. Investor selects the “register” option.
2. Investor fills in the new user registration form.
3. After filling the form, investor submits the form.
4. System checks if the information provided by the investor is correct.
5. A new account is created for the investor.
6. System acknowledges the investor with the login/password.


 Abnormal flow

1. If the investor did not provide the required information, system responds with an error message to give that information.
2. If the information provided by the investor is wrong (like credit card information), then also system gives the error message.
3. If at the end investor selects the “abort “ option to cancel his registration, investor receives an acknowledgement that his registration was not completed.
Post-condition
    Investor gets his/her login id and password, which can be used to use the services of the brokerage system.

Figure 4. Activity diagram for New User Registration.

Use Case 2: Login

 Description
    Once registered with the system, investor has to login each time he/she wants to use the service.
 Primary Actors
    Investor, System administrator.
 Pre-condition.
    Investor must have already registered.
 Flow of Events:
1. System prompts the user to enter login name and password.
2. Investor enters his/her login name and password.
3. System administrator checks for a match in the database.
4. If there exists a match, investor is successfully logged in.
5. Investor’s account is displayed.
 Abnormal flow.
1. If the investor’s login and password are not correct, system prompts the investor to reenter the data with a proper message.
2. If the investor has forgot his password, “forgot password” option is provided to the investor
 Post-condition. Investor’s account is displayed.

Figure 5. Activity diagram for “Login”

Use Case 3: View account

 Description.
    Investor sees his/her account for new information.
 Primary Actor.
    Investor
 Pre-condition.
    Investor has successfully logged into his/her account.
 Flow of Events:
1. Investor can select various available options to view the data.
2. The corresponding data is displayed on the screen.
 Abnormal flow.
1. The requested data may not be displayed because of the system crash or network problem.
Post-condition.
    Investor checks his account and can decide to perform one or more possible actions.

Figure 6. Activity diagram for “View Account”.

Use Case 4: Logout

 Description.
    Investor finishes his work and has to logout from the system to protect his account.
 Primary Actor.
    Investor.
 Pre-condition.
    Investor is already logged into his/her account.
 Flow of Events:
1. Investor selects “Logout” option.
2. System prompts for saving the information if there is any unsaved information.
3. System asks the investor to confirm his logout.
4. The investor is successfully logged out.
5. The investor cannot do anything without logging again.
 Abnormal flow.
1. Investor might have logged out accidentally in which case he/she has to login again.
Post-condition.
    Investor is logged out successfully and has to login again if he wishes to use the services.

Figure 7. Activity diagram for “Logout”.

Use Case 5: Change the account information.

 Description.
    Investor changes the information displayed in his/her account.
 Primary Actor.
    Investor and system administrator
 Pre-condition.
    Investor is logged in and is viewing his/her account.
 Flow of Events:
1. Investor views his account.
2. Investor decides to change the information (like credit card information, address change, etc.) that is not appropriate or correct by selecting the “Change” or “Update” option.
3. The new information is typed.
4. Investor selects the “Save” option to save the new information.
5. System administrator updates the database to store the new information.
6. New updated account information is displayed.
 Abnormal flow.
1. System cannot be able to update the investor’s account in the database because of system crash or network problem.
2. System may prompt the investor an error message if any of the data provided by the investor is not correct.
3. Some of the updates like credit card information may take a little longer time to be activated.
 Post-condition.
    Investors account information is updated.

Figure 8. Activity diagram for “Changing account information

Use Case 6: View portfolio.

 Description.
    Investor can view the portfolios of different companies.
 Primary Actor.
    Investor, Exchange service
 Pre-condition.
    Investor is logged into his/her account and selects the “view portfolio” option.
 Flow of Events:
1. Investor selects the “view portfolio” option.
2. The investor’s portfolio is displayed on the screen.
 Abnormal flow.
1. The company’s portfolio requested by the investor may not exist in the exchange service.
 Post-condition.
    The portfolio of the company requested by the investor is displayed on the screen.

Figure 9. Activity diagram for “View portfolio”

Use Case 7: Place an order.

 Description.
    Investor can place an order to buy or sell stocks.
 Primary Actor.
    Investor, System Administrator
 Pre-condition.
    Investor is logged into his/her account.
 Flow of Events:
1. Investor selects the type of transaction i.e., buy or sell.
2. System prompts for stock name and the number of stocks he/she wants to trade.
3. System checks for the deposit, stock availability in order to process the transaction.
4. If everything is satisfied, system prompts for the order confirmation.
5. Once the investor confirms the order, system administrator records the order in the investor’s order history.
6. Investor gets the acknowledgement from  the system.
 Abnormal flow.
1. If the deposit is less than the money needed to buy stocks, system responds with an error message and cancels the order.
2. If the number of stocks to buy is less than the stock availability, system gives an acknowledgement and cancels the order.
3. If the number of stocks to sell is more than the stocks available with the investor, system responds with an error message.
Post-condition.
    Investor has placed an order and that order is recorded in the database.

Figure 10. Activity diagram for “Place an order”.

Use Case 8: Closing account.

 Description.
    Investor can terminate his account.
 Primary Actor.
    Investor, System administrator
 Pre-condition.
    Investor has a valid account.
 Flow of Events:
1. Investor chooses to terminate his/her account.
2. System checks for deposit, stocks.
3. If any deposit or stocks exists, system prompts for bank account number etc.
4. Investor provides the necessary information.
5. System makes the necessary transfer of money.
6. System acknowledges the investor about the transfer through e-mail etc.
7. Once all the necessary transfers are made, system administrator deletes the investor’s account from the database.
8. System acknowledges the investor about the termination of the account.
 Abnormal flow.
1. Transfer of deposit may take longer time.
2. System may not be able to terminate the account because of incomplete transactions.
 Post-condition.
    Investor’s account is terminated.

Figure 11. Activity diagram for “Close the account”

Use Case 9: Set preferences and/or alerts.

 Description.
    Investor has the choice to set alerts for certain stocks, and set preferences for certain stock news.
 Primary Actor.
    Investor.
 Pre-condition.
    Investor is already logged into his/her account.
 Flow of Events:
1. System prompts the user to add, or delete a preference or rule.
2. Investor selects either option and enters data.
3. System checks the validity of the data entered.
4. System stores the preferences in the investor’s account.
5. Investor gets the acknowledgement from the system.
 Abnormal flow.
1. If the information provided by the investor is not correct, system responds with a error message.
Post-condition.
    Investor’s preferences are set and he/she receives stock alerts, mails etc.

Figure 12. Activity diagram for “Set preferences”

Use Case 10: Get the stock information or retrieve stock information.

 Description.
    Retrieving the information about the stocks from the exchange service.
 Primary Actor.
    Exchange service.
 Pre-condition.
    The exchange service can be accessed.
 Flow of Events:
1. Investor requests the system for some information.
2. System queries the exchange service for the current information.
3. Exchange service provides the requested information.
4. System displays the information to the investor.
 Abnormal flow.
1. The information provided by the exchange service may not arrive at the client end, if the network is broken.
 Post-condition.
    Information is retrieved from the exchange service.

Figure 13. Activity diagram for “Retrieve information”

Use Case 11: System Recovery

  Description
    System may crash at any time and needs to be recovered as soon as possible.
  Primary Actor.
    System Administrator.
  Pre-condition.
    System has crashed.
  Flow of Events:
1. System administrator selects the most recent backup data.
2. System administrator is prompted for the confirmation of the system recovery.
3. The database is recovered with the selected backup data.
  Abnormal Flow.
  1. If there was no recent backup data, information is lost.
  Post-condition.
    System is recovered and performs all the intended functions.

Figure 14. Activity diagram for “System recovery”

Use Case 12: Account reactivation.

  Description.
    Investor’s deposit amount is less than the subscription fee and the account is frozen. Investor has to deposit some money to use the system services.
  Primary Actor.
    Investor.
  Pre-condition.
    Investor’s account is frozen.
  Flow of Events:
1. Investor’s deposit is less than the subscription fee.
2. Investor deposits money.
3. System checks whether the deposited money is more than the subscription fee.
4. Investor’s account is reactivated.
  Abnormal flow.
1. The deposited amount is not sufficient and the account is not reactivated.
  Post-Condition.
    Investor’s account is reactivated.

Use Case 13: Manage Account.

  Description:
    Investor may not be able to access his account due to some problems in the system. System administrator has to resolve this problem and recover the investor’s account.
  Primary Actor.
    System administrator.
  Pre-condition.
    Investor’s account is frozen.
  Flow of Events:
1. Investor reports that the account is frozen.
2. System administrator queries the database and gets all the details.
3. System administrator creates a new account for the investor with the details.
4. Investor’s account is recovered.
  Abnormal flow.
1. System administrator may not be able to recover the investor’s account from the database, in which case all the account information is lost.
  Post- condition.
    Investor’s account is recovered.

Figure 15. Activity diagram for “Account reactivation” and “Manage account”

Use Case 14: Update portfolio

  Description.
    Investor’s portfolio is updated accordingly with the transactions carried out by him/her.
  Primary Actor.
    Investor
  Pre-condition.
    Investor receives market analysis and stock trends from the analysts and from the market news.
  Flow of Events:
1. Investor selects to update portfolio.
2. Investor adds or deletes the stocks that he/she is interested in.
3. Investor submits the new portfolio information.
4. System validates the portfolio selection.
5. System acknowledges the investor.
  Abnormal Flow.
  1.   The stock selected by the investor may not exist.
  Post-condition.
    The investor’s portfolio is updated.

Figure 16. Activity diagram for “Update Portfolio”

2.2.5 Relationships among use-cases

Figure 17. Use-case relationship diagram.

3. Generation of Requirements from Use Cases

3.1 High-level requirements from Use cases

The following are the high-level system requirements generated from the use case analysis.

Level 1 Requirements
INITIAL REQUIREMENTS FROM USE CASES
  1. The system should be internationalized, should be capable of being used by people of different origins.
  2. The system shoud be secure.
  3. The online stock brokerage system interface should be easy to use.
  4. The system should supply all the possible transactions needed by the user.
  5. The system should be able to provide the services uninterruptedly and equitably for a reasonably large group of people.
  6. The system should let the users set their preferences for the stocks in their portfolio.
  7. The system should be available all the time.
  8. The system database must be protected from illegetimate access
  9. The system should be recovered in case of system crash.
  10. The system should be portable, should be capable of being used by people with minimum software requirements.
  11. The system should provide the users with an integrated messaging and routing subsystem.
  12. The system should guide the user with prompt messaging for all his/her actions.
  13. Well-trained and skilled people must be entrusted with the mission-critical functionalities of the system’s components.

3.2 Synthesis and break down of high-level system requirements

The high level requirements are further synthesized and broke down into low-level requirements as follows.


High-level ( Level 1) Requirements Low-Level Requirements (Level 2, 3 and 4)
1
 1.1 All the information must be presented in English by default.
1.2 The system can also give users the choice to select a language out of the given set of languages.
2 2.1 The system must provide secure access to its services.
2.1.1 The system services must be accessible only to the registered users through a mechanism of secure login.
2.1.2 The system must enforce the new users to register with the system, in order to access the system.
2.1.2.1 The information provided by the user is authenticated.
2.1.2.2 User has to deposit minimal initial amount in his/her account for carrying out the transactions, if he/she is a first time user.
2.1.3 The system can only register specific number of people for using its resources.
2.1.4 The system must validate the login and password provided by the user. 
2.2 The system must support secure transfer of data over the public networks.
2.3 The users account information must be protected from illegitimate access.
2.4 All user account transactions must be committed through secure interfaces only.
2.5 All the account-specific information provided by the customers should be stored in the brokerage system's data bases.
 
3 3.1 The user interface provided by the system must be efficient, fast and convenient.
3.2 The system user interfaces must be compatible with popular browsers.
3.3 The system should assist the user with help documentation for various features of the user interfaces.
4 4.1 User transactions must be validated against the user's account previleges and status.
4.2 Users can cancel their order before the order is executed.
4.3 Users can buy the stocks, depending on the stock availability and the amount deposited.
4.4 Users can execute a sell order depending on the stocks in their possession.
4.5 Users can deposit money in their account.
4.6 Users transaction history must be maintained/logged.
4.7 Users transaction status must be updated regularly.
4.8 Users must receive acknowledgements for their transactions and updates on the status of their transactions.
4.9 The system submits the users transactions to the exchange server for execution.
5 5.1 Multiple sessions must be made available to enable multiple users to access the system concurrently.
6 6.1 The system should allow the users to set their account preferences, alerts for stocks
7 7.1 The system must provide alternate ways to access the system.
7.2 The system shall notify the users in adavance about the downtimes.
7.3 In case of outages, the system must rectify any potential data integrity issues with the system databases and notify the users of any impact on their accounts.
8 8.1 The system databases are accessible by  data administrators
8.2 The system database access must be secured through login/password.
9 9.1 The system should provide regular backup of the data
9.2 Various backup methods/options should be used
10 10.1 The user should be able to use the system services with minimal software requirements
10.2 Users can access the system with a computer and a network connection
11 11.1 Latest stock quotes and information should be provided to the user
11.2 System should let the user browse through information
11.3 System should let the users request the information that they need.
12 12.1 System should provide textual/graphical feedback to the users

3.3 Requirements Arranged in a Tree Format

The above synthesized requirements are arranged in a tree format based on the level of the requirements as follows. Level 1 requirements represent the system level requirements, sub system level requirements are stored at level 2 and component level requirements are stored at level 3 and level 4.

Figure 18. Layered Requirements in a Tree Format/Structure.

3.4 Requirements Traceability

The requirements are traced to the use cases and the scenarios from which they are generated as follows.


Use Cases Scenario Level 2 Requirements Level 3 Requirements Level 4 Requirements
Use case 1 
New user registration		 1.1 2.5 2.1.2 2.1.2.1, 2.1.2.2
Use Case 2
Login		 1.1, 2.3, 4.3 2.2 2.1.1, 2.1.2, 2.1.4  
Use Case 3
View Account		 4.2, 4.3 2.1 2.1.1; 2.1.4;  
Use Case 4
Logout		 1.1, 2.3, 4.3 2.1 2.1.1; 2.1.4;  
Use Case 5
Change the account information		 1.2, 2,.2,  4.2 2.3; 2.4; 2.5;    
Use Case 6 
View Portfolios		 4.2, 4.3 2.2; 2.3; 2.5;    
Use Case 7
Place an order		 1.2, 2.2, 7.1, 7.2 2.4; 4.1; 4.2; 4.3; 4.4; 4.5; 4.6; 4.7; 4.8; 12.1;    
Use Case 8
Closing account		 4.2, 4.3 2.1, 2.4, 12.1    
Use Case 9
Set Preferences and/or alerts		 2.3, 4.2, 4.3 6.1, 11.3, 2.4    
Use Case 10
Get the stock information		 2.1, 1.2 11.1, 11.2    
Use Case 11
System Recovery		 6.1, 1.3, 2.2, 5.1 9.1; 9.2    
Use Case 12
Account reactivation		 7.1 2.1; 2.2; 2.4; 2.5;    
Use Case 13
Manage account		 7.1 2.4; 4.5; 6.1; 11.3;    
Use Case 14
Update Portfolio		 1.1 4.5; 4.3; 4.2; 6.1; 11.3;    

4. High Level System Modeling and Analysis

The simplified models of system structure and system behavior are created. The requirements are allocated to the system objects and their attributes and functions.

4.1 System Structure Diagram

The online brokerage system is structurally modeled with sub-system hierarchies as shown in the following class diagram (see Figure 19).

Figure 19. Class diagram for the structural model of the online stock brokerage system

4.2 System Behavior Sequence Diagrams

Detailed System Behavior for Client account activities

Figure 20. System behavior for Client Activities

Detailed System Behavior for Buying Stocks

Figure 21. System behavior for "Buy Order"

Detailed System Behavior for Selling Stocks

Figure 22. System behavior for "Sell Order".

Detailed System Behavior for Cancelling Order

Figure 23. System behavior for "Cancel Order".

Detailed System Behavior for Depositing Money

Figure 24. System behavior for "Depositing Money".

4.3 Requirements Allocation


Requirement # System/Sub-system/components Attribute Method
1.1 Manage Portfolio
Database		 Language
Recorded		 SetPreferences()
UpdateAccount()
1.2 Other Interfaces preferences IsSet()
2.1 System Administrator Database key AuthenticateUserInfo()
2.1.1 Login/Logout interface
System administrator		 Username, password
database key		 IsOk()
IsLoggedin()
AuthenticateUserInfor()
2.1.2, 2.1.2.1 & 2.1.2.2 Deposit amount
Amount
System Administrator		 Amount
TypeOfAmount
amountToDeposit
database key		 depositAmount()
isValidInfo()
CreateAccount()
2.2 Login/Logout Interface Username, password, ok, cancel IsLoggedin()
IsOk()
IsCancel()
2.3 System Administrator database key AuthenticateUserInfo()
2.4 Transaction interface secureInterface IsSecure()
2.5 System administrator database key AuthenticateUserInfo()
2.6 Transaction interface secureInterface IsSecure()
3.1 User interface subsystem interfaceType
Response, timeforresponse		 Interface()
SendFeedback()
IsFast()
3.2 User interface subsystem browserCompatible isBrowserCompatible()
3.3 User interface subsystem Help ProvideHelp()
IsHelp()
4.1 Transaction subsystem Transaction IsValidTransaction() 
UpdateTransactionhistory()
4.2 Cancel order
Transaction Interface		 Transaction
UserId, orderType, stock		 CancelOrder(), IsCancel(), is Ok()
DisplayOrderStatus(), UpdateOrderStatus(), isSecure()
4.3 Buy Stock
Deposit amount
System administrator
Database		 UserId, Stock, amount, database key, recorded IsStockAvailable(), IsAmountAvailable(), BuyStock()
UpdateOrderStatus(), Depositamount(), AuthenticateUserInfo(), RetrieveuserInfo()
4.4 Sell stock
Transaction interface		 userid, stock, ordertype IsStockAvailable()
UpdateOrderStatus()
SellStock()
IsOk(), isCancel(), displayOrderStaus(), isSecure()
4.5 Deposit money
amount
account interface		 Amount
Amount type
amountToDeposit
Update		 Depositamount() 
IsValidInfo()
AmountDeposited()
IsAmountAvailable()
PlaceOrder()
IsOk()
IsCancel()
UpdateInfo()
4.6 Transaction interface Userid, secureinterface DisplayHistory()
4.7  Buy stock
sell stock
cancel order
execute order
order		 Userid, order UpdateOrderStatus()
UpdateStatus()
4.8 Transaction interface Feedback sendFeedback()
DisplayOrderStatus()
4.9
Execute order		 Order, ordered ExecuteOrder(), RemoveOrderfrmQueue()
5.1 database capacity, number of servers Isserverdown()
6.1 portfolio
other interfaces		 Stocks, font, language, preferences, appearance SetPreferences(), viewGraphs(), setAlerts(), IsOk(), isCancel(), isSet(), updateInfo()
7.1 System availability,
number of servers		 IsAvailable()
IsServerDown()
7.2 System Userid, Feedback SendFeedBack()
7.3 System Userid, feedback, numberof servers, availability IsServerDown(), SendFeedBack()
8.1 database name, passwd IsSecureAccess(), IsAdmin()
8.2 System administrator database key AccessDatabase()
9.1 System administrator database key RecoverSystem()
9.2 System  database key, backup BackupUsing(Option 0)
10.1 System, Users Software IsExtraSoftwareNeeded()
10.2 System, Users User terminal, network connectivity, availability Isavailable(), isConnectedToNetwork()
11.1 Users, Userinterface subsystem Information DisplayInformation()
11.2 Users, User interface subsystem Information, userid SearchInformation(), DisplayInformation()
11.3 Users, User interface subsystem Information, userid IsLoggedin(), searchInformation(), requestInformation(), displayInformation()

5. System Level Design

5.1 Creating the Logical Design

The architecture-level design (logical design) is created by decomposing the system into a network of logically connected components and by mapping models of system behavior onto system alternatives.
 

Decomposing the system into a network of components

Figure 25. Schematic of Logical Design for the System

5.2 Mapping models of system behavior onto system structure

FFBD for Client account activities

Figure 26. Functional flow block diagram for client account activities.

FFBD for client transaction activities

Figure 27. Functional Flow Block diagram for Client Trading Activities

FFBD for client transaction order execution

Figure 28. Functional Flow Block diagram for Client Order Execution through Brokerage System.

6. System Design Structure Matrix

A design structure matrix is a compact, matrix representation of a system or project, consisting of a list of all constituent subsystems/activities and the corresponding information exchange and dependency patterns that are required to start a certain activity and the feedback. Of all the available types of design structure matrices, I am considering the Activity Based Design Matrices, which enables us to observe three different types of interactions, dependent tasks, independent tasks and interdependent or coupled tasks.

Column sends, Row receives A B C D E F G H I J K L M N
Use case (1): New user registration A A                          
Use case (2): Login B   B                        
Use case (3): View account C   X C     X                
Use case (4): Logout D   X   D                    
Use case (5): Change the account information E   X X   E                  
Use case (6): View portfolios F   X X     F       X       X
Use case (7): Place an order G   X X     X G     X        
Use case (8): Closing account H   X           H            
Use case (9): Set preferences and/or alerts I   X X           I X        
Use case (10): Get the stock information J   X               J        
Use case (11): System recovery K                     K      
Use case (12): Account reactivation L   X             X     L    
Use case (13): Manage account M                 X          
Use case (14): Update portfolio N   X X                      

7. System Specifications

The above-specified requirements are realized in quantitative and qualitative terms known as specifications as follows.

1. The languages supported are English, Spanish, French, German and Chinese.

1.1. A drop down menu consisting of all the above languages must be implemented.
1.2. The selected language must be shown highlighted and the content is displayed in the selected language.

2. The online stock brokerage system must be secure.

2.1. System should display the login/logout interface screen, whenever the users try to access the system services without logging in.
2.1.1. The system must display the user-preferred settings, once the user has logged in.

2.1.2. When a new-user initiates the registration process, a query form consisting of the user name, age, date of birth, current address, permanent address, home telephone number, work number, ssn must be presented to the user.

2.1.2.1. The information provided by the user must be checked against the official records.

2.1.2.2. User login ids must be unique. No two users can have the same login name.

2.1.2.2.1. The login name entered by the user is verified with the system database.
2.1.2.2.2. If there is no user with that name, then the user can have that login name.

2.1.2.2.3. If there already exists a user with that login name, the system should display the message “Login name already exists. Please enter a different name”.

2.1.2.2.3.1. A new window with the previous login name and a list of suggested login names pops up.
2.1.2.3.  The password must be at least 6 characters long.
2.1.2.3.1. The password characters must be displayed as ‘*’, while typing the password.
2.1.2.4. The user is required to deposit $1000 as initial deposit to open an account.
2.1.2.4.1. This payment has to be made through a check. A confirmatory message is sent to the user after the check is cashed and the account is created for the user.
2.1.3. The system current capacity will allow it to render its services to 100,000 people at the least.
2.1.4. The login/password provided by the user is verified against the system’s database.
2.1.4.1. If the information is correct, system lets the user login and displays his settings screen.
2.1.4.2. If the information is incorrect, system displays the message “ Invalid login/password” and prompts the user to re-enter his correct login and password.
2.2. Support for cryptographic algorithms like RSA or MD5 should be implemented for the secure transfer of data over the network.
2.2.1. Additional protocol layer may be implemented to ensure secure transfer of data over the network.
2.3. The system must be Thawte™ or VeriSign™ compliant.
2.3.1. A lock symbol will be displayed at the bottom of the browser window to let the user know his transactions are secure.
2.4. The information provided by the user is directed to the middleware systems from the web server.
2.4.1. The following are the specifications for a few possible system configurations.
Option 1 Option 2
BEA Web Logic/Windows NT servers Apache 1.3.22/SPARC Solaris
Oracle 9i SQL Server
700 MHz Intel Xeon  SPARC Ultra AXI 440 MHz
2 GB 50 ns ECC Viking RAM 1 GB RAM
Telnet/SSH access Telnet/SSH access
RSA-256/RSA-512, 3DES RSA-256/RSA-512, 3DES
FTP, POP, IMAP, SMTP FTP, POP, IMAP and SMTP servers
2.4.2. Network connectivity:
Multiple full Gigabit Ethernet or DSL
Data centers in the USA, Europe and United Kingdom
Cisco routers and switches
Redundant power backup
24/7 data center monitoring
2.4.3. The web servers run dual SCSI and Raid I drive configurations for backup. Also there is a 24-hour accessible user volume backup.

3. User interface specifications

3.1. Latency: Users must get a response for their actions in at most 45 seconds.
3.2. Users must be provided with a message confirming the action, along with the progress information, and possible future actions.
3.3. The system must be compatible with Microsoft Internet Explorer 5.5, and Netscape 6.0.
3.4. There should be a help option in the user interface, to provide users with help documentation.

4. Transaction Subsystem

Once an order is placed, the system will check whether the order is a valid one or not.
Each order is modeled as an object consisting of orderId, userId, status, orderType, orderDate, stockName, amount, and the number of stocks traded.
orderId must be unique, userId is the user’s login name who placed the order.
status could be “Not Executed”, “Executed”, or “In Process”.
orderType could be “buy”, “sell”, “cancel”.
orderDate is the date when the order is placed.
stockName is the name of the stock being traded.
amount refers to the money.
numStocks is the quantity(number) of the stock being traded.
4.1. If orderStatus = “Not Executed”, only then can that order be cancelled by the user.
4.2. If orderType = “buy”
            If (numStocks <= amount of stock available in the market)
                If  (amount <= amount deposited in the user’s account)
                    User can buy the stocks.
                Else
                    Prompt the user to deposit money in the account
4.3. if orderType = “Sell”,
 Check the number of the stocks to sell <= amount of the stock owned by the user in his/her account.
4.4. Users can deposit the amount in their account either by credit card or by mailing a check. If the credit card is used, the credit card transaction authentication is made through secure interfaces.
4.5. All the transactions made by the user are saved into the account history and are displayed when the user selects “display history”.
4.6. The orderStatus attribute must be updated whenever they are changed by the transaction subsystem.
4.7. A confirmatory message must be sent to the users as an acknowledgment for their transactions.

5. The system should render its services uninterruptedly and equitably to at least 10,000 users concurrently.

5.1. The user sessions per server are limited to 1000 at a time.

6. Users can select the stocks that they wish to monitor into their portfolios, along with their preferences for language, font settings, alerts etc.

6.1. Alerts can be implemented as sending an email, or flashing a message window with an alert notice, when the user logs in.
6.2. User can select the stocks from the available list of stocks.

7. The system must be available 99.9% of the time, ideally 24 hours and 7 days a week, 365 days a year.

7.1. Customer service must be provided when the system goes down.
7.2. When the system goes down, the transactions must be supported/routed through telephone systems.
7.3. The system must send a message to clients through email about the system outage and how long it is going to take.

8. The system database should be secure.

8.1. Access to the database systems, must be regulated by the system administrator only.
8.2. The system administrator has to login through his login name and password to access the database. The administrator password must be atleast 8 characters long and must be an alphanumeric string. The password must be changed every week.

9. The system should be recovered from crashes.

9.1. The backup should be taken daily at 12am.
9.2. The system databases should be recoverable from crashes and data corruption through redundant servers and backup systems. 3 redundant database systems are to be used. In case of a crash in a database, all the data can be restored from the redundant database systems, without any loss of data.

10. Users can access the system through a computer and a network connection, or through a wireless network and a PDA, or through a phone.

10.1. Minimum Windows workstation: Intel Pentium 550MHz, 32 MB RAM, 2 GB hard drive, 3.5" diskette drive, 14” monitor, mouse, Windows 95/98, Windows NT 4, 2000, or XP. Recommended: Same with 128 MB RAM.
10.2. Minimum PDA Configuration: Windows CE, 16MB RAM, Wireless Connectivity (CDMA, GSM or WLAN).
10.3. Minimum Macintosh workstation: G3 300 MHz, 64 MB RAM, one GB hard drive, monitor, mouse, Mac OS X. Recommended: Same with 128 MB RAM. (Remote Desktop Web Connection configuration required.)

11. Integrated Messaging and Routing subsystem

11.1. Users can query the system for latest quotes on some specific stocks.
11.2. Users can request for latest news, such as stock upgrades/downgrades, mergers/spin-offs from the stock market or the business world with regard to specific stocks they may be interested in.

12. The system should provide feedback to the users as an answer to their actions.

12.1. The feedback can be provide using textual messages such as “your transaction is complete” or “ An email is sent” or “ Please verify the login and password” etc. The graphical images like “=>”, ??? etc could be provided to guide the user in carrying out his/her transaction.

13. The technical staff is paid at a rate of $30 per hour, and the maintenance staff is paid at a rate of $25 per hour.

13.1. All staff members work 8 hrs a day.
13.2. At least 20 technical and 15 non-technical staff is necessary to run the day-to-day operations.

8. System Tradeoff Analysis

In the online stock brokerage system, there are many factors that affect the performance of the system. All these factors must be carefully studied and a tradeoff must be done between them prior to the actual design and implementation of the system. The following are the main objectives of the system.

8.1 Performance Characteristics

1. Minimizing the operating costs of the system per day – includes the cost of the salaries of the people, maintenance costs, software and hardware costs, all calculated per day.
2. Maximizing the system throughput – this directly depends on the number of transactions per sec. A transaction here refers to the point where a user’s request enters the system, and a response is sent back to the user.
3. Maximizing the security – Security of transactions and information plays an important role in online stock brokerage system. Various security protocols can be implemented.
4. Maximizing the utilization level or operational capacity – this depends on how well the system resources are utilized. During the peak hours or time, system resources may not be sufficient to support all the users, which results in delay in the transaction processing.
5. Minimize the response time – Response time directly relates to the time the system takes to give a response or feedback to the users actions. It depends on the network throughput, processing speed and the delays due to disk access, network congestion etc.
6. Maximizing the availability – system should be available 24/7 365 days
7. Scalability – The system functions should be scalable to a large number of users. During the peak trading time, system must be capable of extending its services to support large number of users without interruption.
 
 

8.2 Decision Variables

1. X: Type of Security
Security of the system can be viewed as the data security and the security against unauthorized access and hackers.
Communication System security
X11:  256 bit key length encryption
X12: 512 bit key length encryption

System security
X21: Firewall mechanism
X22: Intrusion detection systems (IDS)

2. Y: Type of processors
Y1: cluster of 16 pentium Xeon processors
Y2: cluster of 16 Sparc processors

3. D: Type of database
d1: Microsoft SQL database
d2: Oracle 9i database

4. N: People
n1: number of technical people
n2: number of non-technical people
 

8.3 CPLEX Formulation

After identifying the performance characteristic and the decision variables, we have to conduct the tradeoff analysis to come up with a non-inferior solution or design alternative for the real system design. I have chosen to perform tradeoff analysis between Cost, throughput and the security.

As per the requirements and the specifications, the multiple objectives can be expressed as follows.

Objective 1: Maximize the security

 This depends on the security protocol used by the system for encryption and decryption of the user responses and requests. Also the secure mechanism of firewall or IDS must be implemented to prevent unauthorized access to the system resources. At the same time, the staff may need to apply patches to the security software, check the log files continuously and also protect the corporate form virus and DoS attacks.

 Max security = S1 X11* S2 X12 * S3 X21* S4 X22* S5 n1
 Max log(security) = x11 logS1 + x12 logS2 + x21 logS3 + x22 logS4 + n1log S5

After assigning weights,
        Max log(security) = 0.6 x11 + 0.78 x12 + 0.85 x21 + 0.48 x22 + 0.05 n1

Objective 2: Maximize the system throughput

 Throughput of the system is defined as the number of transactions per sec. A transaction is defined as the user request being processed in the system and sending the response back to the user. Initially, when the user request enters the system through the web server, the request is decrypted, and then it is processed by the integrated messaging and the routing phase and is forwarded to the corresponding server. It involves several disk read write access to the database. The response is sent back to the user in the same way. The bottleneck occurs at the database, as it is a mechanical device.

Max throughput = T1  x11 * T2 X12 * T3 y1 * T4 y2 * T5 d1* T6 d2

Max log(throughput) = x11 logT1 + x12 logT2 + y1 logT3 + y2 logT4 + d1logT5+ d2logT6

After calculating the coefficients,
     Max log(throughput) = 2.6 x11 + 2.3 x12 + d1 + 1.22 d2 + 1.8 y1 + 1.6 y2

Objective 3: Minimize the cost

 Operating costs of the system involves the salaries of the people, hardware costs and the software costs.

Minimize cost = 138 x11 + 552 x12 + 27.4 x21 + 19.2 x22 + 240 n1 + 200 n2 + 250 d1 + 400 d2 + 23.3 y1 + 34.3 y2

Constraints

x11 + x12 = 1         ! either one of the security protocols must be selected
 x21 + x22 = 1         !either one of the security mechanism is implemented
 y1 + y2 = 1            ! either one type of processors are used
 d1+d2 = 1             ! either one of the database must be used.
 20 <=  n1 <= 35    ! atleast 20 and atmost 35 technical staff are appointed.
 n2 >= 15               ! atleast 15 nontechnical staff are appointed.
 

8.4 CPLEX results

 
Run #
x11
x12
x21
x22
y1
y2
d1
d2
n1
n2
security
throughput
Cost
1
0
1
0
1
0
1
1
0
20
15
2.08
4.9
8655.5
2
0
1
0
1
1
0
1
0
20
15
2.08
5.1
8644.5
3
0
1
0
1
0
1
0
1
20
15
2.08
5.12
8805.5
4
1
0
0
1
0
1
1
0
20
15
2.08
5.2
8241.5
5
0
1
0
1
1
0
0
1
20
15
2.08
5.32
8794.5
6
1
0
0
1
1
0
1
0
20
15
2.08
5.4
8230.5
7
1
0
0
1
0
1
0
1
20
15
2.08
5.42
8391.5
8
1
0
0
1
1
0
0
1
20
15
2.08
5.62
8380.5
9
0
1
0
1
0
1
1
0
20
15
2.2
4.9
8655.5
10
0
1
0
1
1
0
1
0
20
15
2.2
5.1
8644.5
11
0
1
0
1
0
1
0
1
20
15
2.2
5.12
8805.5
12
1
0
0
1
0
1
1
0
20
15
2.2
5.2
8241.5
13
0
1
0
1
1
0
0
1
20
15
2.2
5.32
8794.5
14
1
0
0
1
1
0
1
0
20
15
2.2
5.4
8230.5
15
1
0
0
1
0
1
0
1
20
15
2.2
5.42
8391.5
16
1
0
0
1
1
0
0
1
20
15
2.2
5.62
8380.5
17
0
1
1
0
0
1
1
0
20
15
2.27
4.9
8663.7
18
0
1
1
0
1
0
1
0
20
15
2.27
5.1
8652.7
19
0
1
1
0
0
1
0
1
20
15
2.27
5.12
8813.7
20
1
0
1
0
0
1
1
0
20
15
2.27
5.2
8249.7
21
0
1
1
0
1
0
0
1
20
15
2.27
5.32
8802.57
22
1
0
1
0
1
0
1
0
20
15
2.27
5.4
8238.7
23
1
0
1
0
0
1
1
0
20
15
2.27
5.42
8399.7
24
1
0
1
0
1
0
0
1
20
15
2.27
5.62
8388.7
25
0
1
1
0
0
1
1
0
20
15
2.46
4.9
8663.7
26
0
1
1
0
1
0
1
0
20
15
2.46
5.1
8652.7
27
0
1
1
0
0
1
0
1
20
15
2.46
5.12
8813.7
28
1
0
1
0
0
1
1
0
20
15
2.46
5.2
8489.7
29
0
1
1
0
1
0
0
1
20
15
2.46
5.32
8802.7
30
1
0
1
0
1
0
1
0
20
15
2.46
5.4
8478.7
31
1
0
1
0
0
1
0
1
20
15
2.46
5.42
8639.7
32
1
0
1
0
1
0
0
1
20
15
2.46
5.62
8628.7
33
0
1
1
0
0
1
1
0
21
15
2.64
4.9
8903.7
34
0
1
1
0
1
0
1
0
21
15
2.64
5.1
8892.7
35
0
1
1
0
0
1
0
1
21
15
2.64
5.12
9053.7
36
1
0
1
0
0
1
1
0
24
15
2.64
5.2
9209.7
37
0
1
1
0
1
0
0
1
21
15
2.64
5.32
9042.7
38
1
0
1
0
1
0
1
0
24
15
2.64
5.4
9198.7
39
1
0
1
0
0
1
0
1
24
15
2.64
5.42
9359.7
40
1
0
1
0
1
0
0
1
24
15
2.64
5.62
9348.7
41
0
1
1
0
0
1
1
0
28
15
3
4.9
10583.7
42
1
0
1
0
1
0
0
1
31
15
3
5.62
11028.7
43
1
0
1
0
1
0
0
1
33
15
3.1
5.62
11508.7
44
0
1
1
0
0
1
1
0
30
15
3.1
4.9
11063.7
45
1
0
1
0
0
1
1
0
33
15
3.1
5.2
11369.7

 

Plot of non-inferior solutions in the objective space

Analysis of Pareto points

 

x11 x12 x21 x22 y1 y2 d1 d2 n1 n2 security throughput cost
1 0 0 1 1 0 1 0 20 15 2.2 5.4 8230.5
1 0 1 0 1 0 0 1 20 15 2.46 5.62 8628.7
0 1 1 0 1 0 1 0 21 15 2.64 5.1 8892.7
1 0 1 0 1 0 0 1 33 15 3.1 5.62 11508.7

 
 


 

The point 43 corresponds to high security and also high throughput, but at the same time highest cost. If we move to point 14, we get less throughput, and less security but with less cost. Hence on the pare-to curve, if we move from one point to another point, we have to lose at least one objective.
I have selected my design alternative to be point 34.
 
 


x11 x12 x21 x22 y1 y2 d1 d2 n1 n2 security throughput cost
0 1 1 0 1 0 1 0 21 15 2.64 5.1 8892.7

9. Component-System Testing

9.1 Primary Verification Plan

The primary verification for the online brokerage system is proposed as follows.

Requirement 1.1.1 All the information must be presented in English by default.

Demo 1.1.1   Customer/Investor enters the url for the system in any internet browser.
    System fails if the text displayed in the browser is not in English.
    System fails if the language option does not show “English”.

Examination 1.1.1 See whether the GUI is showing English on the language option.
    System fails if it does not show English.
 

Requirement 1.1.2 The system can also give users the choice to select a language out of the given set of languages.

Demo 1.1.2.1 Customer/Investor clicks on the “language” option on the home page.
     System fails if it does not show the menu of the available languages.
Demo 1.1.2.2 Customer selects one language from the menu.
     System fails if customer is not able to select the language from the menu.
     System fails if the language of the text is not changed to the selected language.
     System fails if the language option does not indicate the selected language.

Examination 1.1.2.1 See if the GUI has an option of selecting the language.
      System fails if GUI does not provide such option
Examination 1.1.2.2 See if the GUI is showing the correct language in which the text is displayed.
     System fails if GUI does not show it correctly. For example, if the text is in Mexican and GUI shows English.

Test 1.1.2 Measure with a stopwatch, the time it takes to change the language of text to the selected language, start the watch when the user selects the language and stop when the text is converted.
     System fails if it takes more than 45sec.
 
 

Requirement 2.1.1 The system services must be accessible only to the registered users through a mechanism of secure login.

Demo 2.1.1.1 A new user clicks on “view account information” tab, without registering.
     System fails if the browser window does not show the secure lock icon
     System fails if it doesn’t prompt the user to login or new user registration.
Demo 2.1.1.2 A new user clicks on “transaction” tab, without registering.
    System fails if the browser window does not show the secure lock icon
     System fails if it doesn’t prompt the user to login or new user registration.
Demo 2.1.1.3 A new user clicks on “update portfolio” tab, without registering.
     System fails if the browser window does not show the secure lock icon
     System fails if it doesn’t prompt the user to login or new user registration.

Examination 2.1.1.1 See whether the GUI provides a login interface with login, password, change password and new user options.
     System fails if the GUI does not provide all these options.
 

Requirement 2.1.2 The system must enforce the new users to register with the system, in order to access the system

Demo 2.1.2.1 A new user enters the url in the browser.
     System fails if it does not prompt user about the new user registration.
     System fails if it does not explain the terms and conditions for registering.

Requirement 2.1.2.1 The information provided by the user is authenticated.

Demo 2.1.2.1.1 A new user clicks on the “new user” option.
     System fails if the new user registration form is not displayed.
Demo 2.1.2.1.2 User fills in the form and submits it.
     System fails if the user cannot enter the information.
     System fails if the user cannot submit the form.
    System fails if the user is not notified of the incorrect information.
    System fails if the user is registered immediately after submitting the form.
    System fails if the user is not notified about the registration through email.
 Demo 2.1.2.1.3 All the information provided by the user must be secured by the interface.
      System fails if the browser does not display the secure lock.
      System fails if the encryption and decryption standards are not used.
Demo 2.1.2.1.4 User is prompted to enter a login name and password which are required to access the system later.
     System fails if the form does not have that option.
     System fails if the password typed is not hidden.

Examination 2.1.2.1 See whether the new user registration form has important details like name, address, phone number (work, home), social security number, login name, password, confirm password.
     System fails if the new user registration form does not have all these options.

Simulation 2.1.2.1 A new user clicks on the new user registration option, a form with all the important details is provided to the user, which he/she fills in and submits.  If any information is in wrong format, the user is asked to reenter the wrong information in the correct format. An acknowledgement is sent to the user, if everything is correct.
     System fails if the form is not provided to the user.
     System fails if the user cannot fill in the details by typing.
     System fails if the user cannot submit the form.
     System fails if it does not prompt the user of wrong information.
    System fails if it does not send an email to the user about his registration and future actions.

Requirement 2.1.2.2 User has to deposit a minimal initial amount in his/her account for carrying out the transactions, if he/she is a first time user.

Demo 2.1.2.2.1 A new user submits the new user registration form successfully.
     System fails if it does not notify the user about the initial deposit.
     System fails if the GUI does not show the deposit option.
Demo 2.1.2.2.2 User selects to pay the deposit by clicking on the “deposit” option.
     System fails if the GUI does not show the options to pay the deposit.
     System fails if the information provided by the user is not secured by the interface.
     System fails if the browser does not display the secure lock icon.
     System fails it the user is not given a receipt of his/her payment.
Demo 2.1.2.2.3 System verifies the credit card information provided by the user.
     System fails if it does not notify the customer about the information validity.
     System fails if it does not accept the payment even the information is valid.

Examination 2.1.2.2 See whether GUI has different options for different kinds of payment methods. For each option, examine whether all the necessary information is provided.
     System fails if it does not prompt for all the necessary information for each payment method.

Simulation 2.1.2.2.1 User selects to deposit the initial amount, selects to pay by credit card, fill in all the credit card details like card member name, card number, expiry date, phone number. And then selects to deposit the amount.
     System fails if it does not validate the credit card information.
     System fails if it does not notify the user of incorrect information.
     System fails if it lets the user register without valid deposit of amount.
Simulation 2.1.2.2.2 User selects to deposit the initial amount, selects to pay by phone call.
     System fails if it does not display the phone number where the user can do his payment.
     System fails if it does not display the necessary information that he/she need to have during the conversation.

Requirement 2.1.3 System can only register specific number of people.

Demo 2.1.3 Users submit their registration form successfully.
     System fails if it does not check the threshold.

Requirement 2.1.4 The system must validate the login and password provided by the user.

Demo 2.1.4 User enters login and password.
     System fails it does not validate the login and password with the database.
     System fails if it lets the user login even though the login and password are not the same.
     System fails if shows the password typed by the user.

Examination 2.1.4.1 User enters correct login but incorrect password.
     System fails if the user is logged in.
Examination 2.1.4.2 User enters incorrect login, see whether the user is logged in or not.
     System fails if the user is logged in.
Examination 2.1.4.3 User types in the password, see whether the characters are hidden by *’s
     System fails if the password is not displayed as *’s.

Requirement 2.2 The system must support secure transfer of data over the public networks.

Demo 2.2 User types in his/her transaction details, the details are traversed through the network.
     System fails if the details are not encrypted before sending them over the network.
     System fails if the details are not decrypted after receiving them.
     System fails if the browser does not show the secure lock icon.

Examination 2.2 See whether the data is encrypted by catching the data at a router, and check whether the data is decrypted correctly.
     System fails if the data is not encrypted.
     System fails if the data is not decrypted correctly.

Simulation 2.2 User enters transaction details, information is encrypted, and packets of encrypted information is sent over the network, few packets are examined at some router in the network before reaching the destination. Packets are decrypted at the destination and are examined.
     System fails if the data is not encrypted.
     System fails if the data is not decrypted correctly

Requirement 2.3 The user’s account information must be protected from illegitimate access.

 Demo 2.3.1 A user clicks on “view account” before logging in to the system.
      System fails if it does not prompt the user to log in.
      System fails if it shows some other users information.
 Demo 2.3.2 A user clicks on “view account” after logging in to the system.
      System fails if the user is prompted to enter login/password.
      System fails if the user account information is not displayed.

Examination 2.3 See whether the system displays user account information if he/she does not log out before they close the browser.
     System fails if it still displays the user information.
     System fails if it does not logout the user when he/she closes the browser.
 

Requirement 2.4 All user account transactions must be committed through secure interfaces only.

Demo 2.4.1 User clicks on “transaction” tab.
     System fails if the secure lock icon is not displayed.
     System fails if the data is not encrypted before transmitting.
Demo 2.4.2 User clicks on “account information”
     System fails if the secure lock icon is not displayed.
     System fails if the data is not encrypted before transmitting.
Examination 2.4 See whether the secure lock icon is displayed as the users browse through the system.
     System fails if it does not display the icon.
 

Requirement 2.5 All the account-specific information provided by the customers should be stored in the brokerage system’s databases.

Demo 2.5 User updates his account information.
     System fails if the updated information is not written into the database.
     System fails if the updated information is not validated.

Simulation 2.5 User changes his/her account information and selects “update account” option, query the data base for his/her record and see whether the information is same as the updated information.
     System fails if the database record shows some other information.
 

Requirement 3.1 The user interface provided by the system must be efficient, fast and convenient.

Demo 3.1.1 Users click on the tabs provided by the GUI.
     System fails if it does not respond with in 45 seconds.
     System fails if it does not show the progress bar in the browser.
     System fails if it does not give feedback to the user.
Demo 3.1.2 Users move the mouse on the page.
     System fails if it does not highlight the GUI tab under the mouse.
     System fails if it does not show the information popup with mouse over action.

Examination 3.1 See whether the GUI components are highlighted and mouse popups are shown as the user moves his/her mouse over the page.
     System fails if it does not do the above specified actions.

Test 3.1 With a stop watch, measure the time taken to do the action, when the user clicks on some component, to the result of that action.
     System fail if it takes more than 45 sec.
 

Requirement 3.2 The system user interfaces must be compatible with popular browsers.

Demo 3.2.1 User enters the url in Internet Explorer 5.0
     System fails if it does not load the page.
     System fails if it does not load the images, icons and the text correctly.
Demo 3.2.2 User enters the url in Netscape
     System fails if it does not load the page.
     System fails if it does not load the images, icons and the text correctly.

Simulation 3.2 User enters the url in internet explorer, browses through some services of the system. Then does the same action but in netscape.
     System fails if it fails to load the images, text and icons correctly.
Examination 3.2 See whether the images  and text are displayed correctly in both the internet explorer and netscape.
    System fails if it fails to load the images, text and icons correctly.
 

Requirement 3.3 The system should assist the user with help documentation for various features of the user interfaces.

Demo 3.3 User clicks on “Help” option.
     System fails if it does not display the help table of contents.
     System fails if it does not display any of the sub section in the help.

Examination 3.3.1 See whether there is help option on the gui.
     System fails if there is no such option on the gui.
Examination 3.3.2 See whether the table of contents for help is displayed when the user clicks on help.
     System fails if the table of contents is not displayed.

Test 3.3 Measure the time it takes to display the help content with a stopwatch.
     System fails if it takes more than 30sec.
 

Requirement 4.1 The user transactions must be validated against the user’s account privileges and status.

Demo 4.1.1 User carries out a transaction, whose account does not have privileges to carry out the transactions.
     System fails if it executes the transaction.
Demo 4.1.2 User carries out a transaction.
     System fails if it does not let the user carry out the transaction.
 

Requirement 4.2 Users can cancel his/her order before the order is executed.

Demo 4.2.1 User tries to cancel an executed order.
     System fails if it lets the user cancel the order.
     System fails if the order is cancelled.
Demo 4.2.2 User cancels an order that is not yet executed.
     System fails if the order is not cancelled.
     System fails if the user cannot cancel the order.

Simulation 4.2 As soon as the user selects to cancel the order, system checks whether the order is executed or not and cancels the order if it is not executed.
     System fails if it does not cancel the order which is not yet executed.
     System fails if it cancels the order that is already executed.

Examination 4.2 See whether the order status is updated depending on whether the order is cancelled or not.
     System fails if it does not show “cancelled” for order status when the order is cancelled.
     System fails if it shows “cancelled” for order status when the order is not cancelled.
 

Requirement 4.3 Users can buy the stocks, depending on the stock availability and the amount deposited.

Demo 4.3.1 User tries to buy stocks valued more than his deposit.
     System fails if it lets the user buy the stocks.
     System fails if it does not prompt the user to add to the current deposit.
Demo 4.3.2 User tried to buy stocks whose value is less than his deposit.
     System fails if it does not let the users buy the stocks.
     System fails if it does not notify the user about his/her new transaction.
    System fails if it does not update the order status and stock availability in user portfolio.
    System fails if it does not update the order status and stock availability in user portfolio.

Simulation 4.3 User buys stocks valued more than his/her deposit, then deposits the additional amount and buys the stocks.
    System fails if it does not notify the user about the extra deposit.
    System fails if it lets the user buy more stocks without depositing the amount needed.
     System fails if it does not let the user buy stocks with available money.
     System fails if it does not update user portfolio.
     System fails if it does not update the order status.
 

Requirement 4.4

Demo 4.4.1 User tries to sell stocks more than what is available.
     System fails if it let the user sell stocks.
Demo 4.4.2 User tries to sell stocks that are available.
     System fails if it does not let the user sell stocks.
     System fails if it does notify the user after selling stocks.

Simulation 4.4 Users sells stocks more than what is available, and then sells the available stocks.
     System fails if it does not notify the user about the excess of stocks sold.
     System fails if it lets the user sell excess stocks which are unavailable.
     System fails if it does not let the user sell the available stocks.
     System fails if it does not update user portfolio.
     System fails if it does not update the order status.

Requirement 4.5 Users can deposit money in his/her account.

  The test plan for this is similar to the one specified for the new user initial deposited money.
 

Requirement 4.6 Users’ transaction history must be maintained / logged.

Demo 4.6.1 User buys stocks.
     System fails if the new order does not appear in the transaction history of the user.
     System fails if the transaction history of the user is not displayed.
Demo 4.6.2 User sells stocks.
     System fails if the new order does not appear in the transaction history of the user.
     System fails if the transaction history of the user is not accessible.
Demo 4.6.3 User cancels order.
     System fails if the new order does not appear in the transaction history of the user.
     System fails if the transaction history of the user is not displayed.

Examination 4.6 See whether the transaction history is updated or not as soon as an order is executed.
     System fails if the transaction history is not updated.
 

Requirement 4.7 Users’ transaction status must be updated regularly.

Demo 4.7.1 User cancels an order.
     System fails if the transaction status is still “in execution”.
     System fails if the transaction status has not changed to “Cancelled”.
Demo 4.7.2 User’s order is executed.
     System fails if the transaction status does not show “Completed/Executed”.

Examination 4.7 See whether the transaction status is changed when the user cancels his/her order and when the order is executed.
    System fails if the transaction status in the history does not reflect the actual state of transaction.
 

Requirement 4.8 Users must receive acknowledgements for his/her transactions and updates on the status of their transactions.

Demo 4.8.1 User carries out a transaction.
     System fails if it does not send an email with all the details of transaction.
     System fails if it does not give periodic feedback about the transaction.
Demo 4.8.2 User’s order is executed.
     System fails if the user is not notified about the execution of transaction.
     System fails if the user is not updated with the new portfolio, and a detailed explanation of all the additions and deletions through email.
     System fails if it does not send the details of users’ portfolio once in every month through mail.
     System fails if the GUI does not support constant feedback while carrying out the transaction.

Examination 4.8 See whether the user receives email/mail regularly and when the transactions are carried out.
     System fails if it does not periodic notifications to the user.

Requirement 4.9 The system submits the user transactions to the exchange server for execution.

Demo 4.9 User completes the transaction.
     System fails if the completed transaction is not passed on to the exchange server.
     System fails if it does not notify the user about the transaction, whether it is executed or not.
     System fails if it does not update the user portfolio information as it receives information from the exchange server.

Simulation 4.9 As soon as the user completes his/her transaction, the order is sent to the exchange server, and are executed based on first come, first served basis. As soon as the system receives feedback from the server, user is acknowledged with that information and his account information is updated.
     System fails if the order is not put on the exchange server.
     System fails if the user is not notified of the order status.
     System fails if the user’s transaction status is not updated.
 

Requirement 5.1 Multiple sessions must be made available to enable multiple users to access the system concurrently.

Demo 5.1 Two users login to the system on two terminals at the same time.
     System fails if it cannot let the users to login.
     System fails if it cannot let the users use all of its services effectively.

Simulation 5.1 Write a process that attempts to connect to the system web server, and see whether the system is capable of supporting multiple connections.
     System fails if it cannot support 100000 multiple connections simultaneously.
     System fails if it cannot provide its services to all the simultaneous users.

Examination 5.1 See whether all the services are available to the user without any problem.
     System fails if the users cannot access system services.
     System fails if it takes more than 2sec to respond to the user.

Test 5.1 Measure the time it takes to load the system when the number of simultaneous users reaches the threshold, say 100000.
     System fails it take more then 3 minutes.
 

Requirement 6.1 The system should allow the users to set account preferences and alerts for stocks.

Demo 6.1.1 User sets his/her account preferences which include language, home page settings, welcome information, portfolio summary, icons.
     System fails if it does not set the browser language to the user selected language.
     System fails if it does not load the home page settings as soon as he logs in.
     System fails if it does not show the welcome information.
     System fails if it shows the wrong information.
     System fails if it does not load the user preferred icons.
Demo 6.1.2 User sets alerts for stocks.
     System fails if the user cannot set an alert for the stock.
     System fails if it does not alert the user at right time.

Simulation 6.1 As soon as the user sets his preferences, he/she should be able to see the preferences.
     System fails if the user cannot see his new preferences.

Examination 6.1 See whether the GUI provides all the options to set the possible preferences.
     System fails if the GUI does not have these options.
 

Requirement 7.1 The system must provide alternate ways to access the system, when there is any access problem

Demo 7.1 User tries to use the system when the system has some problem.
     System fails if it cannot provide access to its services.
     System fails if it cannot let the user carry out transactions through phone or email.
 

Requirement 7.2 The system shall notify the users in advance about its outages or downtimes when possible.

Demo 7.2.1 The system goes down because of before-known outage.
     System fails if it does not inform the user about the possible down time through email.
Demo 7.2.2 The system goes down because of unexpected outage or problem.
     System fails if it does not inform the user about the problem immediately after the problem has occurred.
 

Requirement 7.3 In case of outages, the system must rectify any potential data integrity issues with the system databases, and notify the users of any impact on their accounts.

Demo 7.3 System goes down for a while and comes up and starts functioning normally.
     System fails if it does not inform the user about the problem.
     System fails if any of the data is corrupted.
     System fails if it does not restore the data using the backup.

Simulation 7.3 The system can be forced to crash and then recovered.
     System fails if it cannot recover the data.
     System fails if it cannot function properly after recovery.

Examination 7.3 See whether the data restored after recovery is same as when it crashed.
     System fails, if the data is corrupted.
     System fails, if the data cannot be restored from the backup.
 

Requirement 8.1 The system databases are accessible by the data administrator

Demo 8.1.1 Data administrator accesses the database.
     System fails if the administrator is not given access.
Demo 8.1.2 Non – administrator accesses the database.
     System fails if the non-administrator is given access to the database.

Simulation 8.1 Administrator can access the database by logging in as administrator and then access the database as a user.
     System fails if it grants access to the administrator when he logged as a user.
     System fails if it does not grant access to the administrator when he logs in as an administrator

Requirement 8.2 The system database access must be secured through a login/password

Demo 8.2.1 Administrator tried to access the database.
     System fails if it does not prompt the administrator to enter login and password.
     System fails if it does not validate the password.
Demo 8.2.2 Administrator enters the login/ password.
     System fails if the login/password are not verified.
     System fails if the administrator can access the database with wrong login and/or password.
 

Requirement 9.1 The system should provide regular back up of the data

Demo 9.1 Data is backed up automatically.
     System fails if it does not backup the data every day.
     System fails if it maintenance staff does not check whether backup is taken or not.
 

Requirement 9.2 Various back up methods/options should be used.

Demo 9.2 Three different backup disks are used.
     System fails if it does not backup the data on to three different backup disks.

Simulation 9.2 Back up the data and see whether the backup disks have the correct data.
     System fails if the backup disks do not store the data correctly.
 

Requirement 10.1 & 10.2  The users should be able to use the system services with minimal software requirements.

Demo 10.1 A user with a terminal, popular internet browsers installed in the terminal and a network connection launches the system.
     System fails if he/she is not able to use the system services.
     System fails if it requests the user to install additional software.
Examination 10.1 See whether the user is able to browse the system with a computer, network connection and the browser installed on his/her computer.
     System fails if he/she is not able to use the system services.
     System fails if it requests the user to install additional software.
 

Requirement 11 Latest stock quotes and information should be provided to the user, without logging on to the system.

Demo 11.1 Users click on the news option on the home page without logging into the system.
     System fails if the user cannot view the news.
     System fails if the GUI does not have this option.
Demo 11.2 User clicks on the news/info about stocks on the GUI, after logging into the system.
     System fails if the user cannot view the news/information.
     System fails if the GUI does not have this option.

Examination 11 See whether the GUI provides the options to query stock quotes.
     System fails if there is no such option on the GUI.
 

Requirement 12 The system should provide textual or graphical feedback to the users for their actions.

Demo 12.1 User sets an alert for a stock.
     System fails if the GUI does not highlight the recent highlight.
     System fails if the GUI does not notify the user about the alert.
     System fails if the GUI does not show the stock in the alerts list.

Examination 12.1 See whether some kind of feed back is given to the user either using text or graphics.
     System fails if there is no such feedback to the user.

9.2 Verification Traceability Matrix

 
Requirement #
Tests
Simulations
Demonstrations
Examination
1.1.1
    
1.1.1
1.1.1
1.1.2
1.1.2
  
1.1.2.1&1.1.2.2
1.1.2.1 & 1.1.2.2
2.1.1
    
2.1.1.1 thru 2.1.1.3
2.1.1.1
2.1.2
    
2.1.2.1
  
2.1.2.1
  
2.1.2.1
2.1.2.1.1 thru  2.1.2.1.4
2.1.2.1
2.1.2.2
  
2.1.2.2.1 & 2.1.2.2.2
2.1.2.2.1 thru 2.1.2.2.3
2.1.2.2
2.1.3
    
2.1.3
  
2.1.4
    
2.1.4
2.1.4.1 thru 2.1.4.3
2.2
  
2.2
2.2
2.2
2.3
    
2.3.1 & 2.3.2
2.3
2.4
    
2.4.1 & 2.4.2
2.4
2.5
  
2.5
2.5
  
3.1
3.1
  
3.1.1 & 3.1.2
3.1
3.2
  
3.2
3.2.1 & 3.2.2
3.2
3.3
3.3
  
3.3
3.3.1 & 3.3.2
4.1
    
4.1.1 & 4.1.2
  
4.2
  
4.2
4.2.1 & 4.2.2
4.2
4.3
  
4.3
4.3.1 & 4.3.2
  
4.4
  
4.4
4.4.1 & 4.4.2
  
4.6
    
4.6.1 thru 4.6.3
4.6
4.7
    
4.7.1 & 4.7.2
4.7
4.8
    
4.8.1 & 4.8.2
4.8
4.9
  
4.9
4.9
  
5.1
5.1
5.1
5.1
5.1
6.1
  
6.1
6.1.1 & 6.1.2
6.1
7.1
    
7.1
  
7.2
    
7.2.1 & 7.2.2
  
7.3
  
7.3
7.3
7.3
8.1
  
8.1
8.1.1 & 8.1.2
  
8.2
    
8.2.1 & 8.2.2
  
9.1
    
9.1
  
9.2
  
9.2
9.2
  
10
    
10.1
10.1
11
    
11.1 & 11.2
11
12
    
12.1
12.1

9.3 VSN (Verification String Number)s

9.4 Coverage and Completeness

The verification traceability matrix and the verification string numbers refer to leaf level requirements. We have to make sure that all the high level requirements are verified from the VTM and VSN's to ensure that the verification plan proposed above covers all the requirements and is complete.


Req # Level 1 Requirements Tests Simulations Demonstrations Examinations
1
The system should be internationalized, should be capable of being used by people of different origins.
 1.  
1.1


1.2.1& 1.2.2
1.1


1.2.1 & 1.2.2
2 The system should be secure  
2.1.2.1,


2.1.2.2.1 &2.1.2.2.2,
2.2, 2.5
2.1.1.1 thru 2.1.1.3, 2.1.2.1,


2.1.2.1.1 thru 2.1.2.1.4,
2.1.2.2.1 thru 2.1.2.2.3,
2.1.3, 2.1.4,
2.2, 2.3.1 & 2.3.2, 2.4.1 & 2.4.2, 2.5
2.1.1.1


2.1.2.1
2.1.2.2
2.1.4.1 thru 2.1.4.3
2.2, 2.3, 2.4
3
The online stock brokerage system interface should be easy to use.
 3.1, 3.3 3.2 3.1.1 & 3.1.2
3.2.1 & 3.2.2
3.3		 3.1
3.2
3.3.1 & 3.3.2
4
The system should supply all the possible transactions needed by the user.
   4.2
4.3
4.4
4.9
4.1.1 & 4.1.2


4.2.1 & 4.2.2
4.3.1 & 4.3.2
4.4.1 & 4.4.2
4.6.1 thru 4.6.3
4.7.1 & 4.7.2
4.8.1 & 4.8.2, 4.9

 4.2
4.6
4.7
4.8
5
The system should be able to provide the services uninterruptedly and equitably for a reasonably large group of people.
 5.1 5.1 5.1 5,.1
6
The system should let the users set their preferences for the stocks in their portfolio
   6.1 6.1.1 & 6.1.2 6.1
7 The system should be available all the time   7.3
7.1


7.2.1 & 7.2.2, 7.3

 7.3
8
The system database must be protected
   8.1 8.1.1 & 8.1.2
8.2.1 & 8.2.2		  
9  The system should be recovered in case of system crash   9.2 9.1
9.2		  
10 Minimal software/hardare requirement     10.1 10.1
11 The system should provide the users with an integrated messaging and routing subsystem     11.1 thru 11.2 11
12
The system should guide the user with prompt messaging for all his/her actions.
     12.1 12.1

Thus all the high level requirements are verified by the verification plan proposed for the low level requirements.

Also, the VSNs defined above verify the system level, subsystem level and component level requirements. Few requirements are joined and given a verification string number, which specifies that all the tests can be done at the same time. VSN 1 checks the security issues of the system. VSN 1, VSN 3 and VSN 4 together ensure transaction security along with the feed back to the customer through the integrated messaging and routing system, VSN 1 and VSN 2 verify user account information security. VSN 5 verifies the software and hardware requirements of the system. VSN 6 and VSN 7 ensure the verification of database component and the effective backup method and the system behavior when crashed.

Thus all these VSN's verify the complete system, including the security, performance and maintenance issues. If the system passes the above specified plan, it can be assured that the final system will meet the requirements and its components interact in the way specified.

10. Conclusions

Online stock brokerage system helps people to trade stocks through internet, without using middlemen, thus making the transactions faster than before. But the system has its own limitations. In this project, I have successfully applied the systems engineering methodology to design the brokerage system.

Applying systems engineering principle from the stake holder requirements to the system validation and verification phase results in a system that is consistent from the beginning to the end and that serves the intended purpose effectively when designed. Initial stake holder requirements are used to develop the use cases and scenarios which reflect the actual purpose of the system. From the use cases, system level requirements are generated which are then synthesized and broke down into low level requirements. These requirements are traced onto the use cases to ensure that all the scenarios and use cases are reflected in the requirements. System modeling and analysis results in the system structure and system behavior. Requirements are allocated onto objects and attributes of system structure and methods of system behavior. Qualitative and quantitative requirements are then assigned possible values and are known as specifications. The system tradeoff analysis is carried out after identifying the measures of effectiveness and the parameters. This results in the best possible system design alternative among group of alternatives depending on the specified criteria.

The two important parts of this systems approach are System validation and verification, as they check the correctness of the system designed so far. Validation - "Are we building the right product? " and Verification - " Are we building the product right?" Satisfactory answers to both the questions are a prerequisite to customer acceptance. A verification plan is proposed to test all the leaf level requirements. The tests, demonstrations, simulations and examinations defined in the verification plan are traced on to the requirements. Some of the tests, demonstrations, simulations and examinations  are joined together and are assigned a verification string matrix which saves the cost and time involved in testing. Coverage and completeness criteria explains how the test plan covers all the requirements. If the system passes all the tests, it can be assured that the final system after actual implementation will meet the customer requirements. Thus the application of systems engineering principles and methods result in effective system design with reduced costs and time.

11. References

12. Appendix

A.    Coefficient Calculation for LP formulation of objectives

Salary for each technical staff = $30
Salary for each non-technical staff = $25
Number of working hours per week = 40
Average number of transactions per day = 138000
Cost of security per transaction (256 bit key length) = .10 cents
Cost of security per transaction (512 bit key length) = .40 cents
Cost of firewall per year contract = 10000
Cost of IDS per year contract = 7000
Cost of Pentium Xeon processor with 4 yr life time = 1700
Cost of sparc processor with 4 yr life time = 2500
Cost of oracle 9i db per day = 400
Cost of sql database per day = 250

Time for encryption and decryption using 256 bit length key = 10ms
Time for encryption and decryption using 512 bit length key = 20ms
Time for one disk read write for sql db = 100ms
Time for one disk read write using oracle 9i db = 60ms
Time for processing using Pentium xeon processor = 15ms
Time for processing using sparc processor  = 25ms

B.    Database costs

 
Number of CPUs Oracle 9i
Enterprise Edition		 SQL Server 2000 Enterprise Edition With SQL Server, you save...
1
 $40,000 $19,999 $20,001
2
 $80,000 $39,998 $40,002
4
 $160,000 $79,996 $80,004
8
 $320,000 $159,992 $160,008
16
 $640,000 $319,984 $320,016
32
 $1,280,000 $636,968 $640,032

C.    Security costs to break keys of various lengths

 
Cost
40-bit
56-bit
64-bit
80-bit
128-bit
$0.1 M
2 sec
35 hrs
1 yr
70,000 yrs
10 e+19 yrs
$1.0 M
.2 sec
3.5 hrs
37 days
7,000 yrs
10 e+18 yrs
$100 M
2 millisec
2 min
9 hrs
70 yrs
10 e+16 yrs
$1.0 B
.2 millisec
13 min
1 hr
7 yrs
10 e+15 yrs
$100 B
2 microsec
1 sec
32 sec
24 days
10 e+13 yrs

 

D.    CPLEX Log for few cases

Case 1
display problem all
Minimize
 obj: 138 x11 + 552 x12 + 27.4 x21 + 19.2 x22 + 240 n1 + 200 n2 + 250 d1
 + 400 d2 + 23.3 y1 + 34.3 y2
Subject To
 c1: x11 + x12  = 1
 c2: x21 + x22  = 1
 c3: y1 + y2  = 1
 c4: d1 + d2 = 1
 c5: n1 >= 20
 c6: n2 >= 15
 c7: 0.6 x11 + 0.78 x12 + 0.85 x21 + 0.48 x22 + 0.05 n1 >= 2.08
 c8: 2.6 x11 + 2.3 x12 + d1 + 1.22 d2 + 1.8 y1 + 1.6 y2 >= 4.9
Bounds
 0 <= x11 <= 1
 0 <= x12 <= 1
 0 <= x21 <= 1
 0 <= x22 <= 1
      n1 >= 0
      n2 >= 0
 0 <= d1 <= 1
 0 <= d2 <= 1
 0 <= y1 <= 1
 0 <= y2 <= 1
Generals
 x11  x12  x21  x22  n1  n2  d1  d2  y1  y2

CPLEX> optimize
Tried aggregator 1 time.
MIP Presolve eliminated 2 rows and 1 columns.
Aggregator did 4 substitutions.
Reduced MIP has 2 rows, 5 columns, and 6 nonzeros.
Presolve time =    0.01 sec.
Clique table members: 1
MIP emphasis: optimality
Root relaxation solution time =    0.00 sec.

Integer optimal solution:  Objective =    8.6555000000e+03
Solution time =    0.01 sec.  Iterations = 1  Nodes = 0
 

CPLEX> display sol obj -
Integer optimal solution:  Objective =    8.6555000000e+03
CPLEX> display sol var -
Variable Name           Solution Value
x12                           1.000000
x22                           1.000000
n1                           20.000000
n2                           15.000000
d1                            1.000000
y2                            1.000000
All other variables in the range 1-10 are zero.
 

Case 2
Minimize
 obj: 138 x11 + 552 x12 + 27.4 x21 + 19.2 x22 + 240 n1 + 200 n2 + 250 d1
 + 400 d2 + 23.3 y1 + 34.3 y2
Subject To
 c1: x11 + x12  = 1
 c2: x21 + x22  = 1
 c3: y1 + y2  = 1
 c4: d1 + d2  = 1
 c5: n1 >= 20
 c6: n2 >= 15
 c7: 0.6 x11 + 0.78 x12 + 0.85 x21 + 0.48 x22 + 0.05 n1 >= 2.2
 c8: 2.6 x11 + 2.3 x12 + d1 + 1.22 d2 + 1.8 y1 + 1.6 y2  >= 5.4
Bounds
 0 <= x11 <= 1
 0 <= x12 <= 1
 0 <= x21 <= 1
 0 <= x22 <= 1
      n1 >= 0
      n2 >= 0
 0 <= d1 <= 1
 0 <= d2 <= 1
 0 <= y1 <= 1
 0 <= y2 <= 1
Generals
 x11  x12  x21  x22  n1  n2  d1  d2  y1  y2

CPLEX> optimize
Tried aggregator 1 time.
MIP Presolve eliminated 2 rows and 1 columns.
Aggregator did 4 substitutions.
Reduced MIP has 2 rows, 5 columns, and 6 nonzeros.
Presolve time =    0.00 sec.
Clique table members: 2
MIP emphasis: optimality
Root relaxation solution time =    0.00 sec.

        Nodes                                         Cuts/
   Node  Left     Objective  IInf  Best Integer     Best Node    ItCnt     Gap

      0     0     8233.1595     1                   8233.1595        1
*                 8238.7000     0     8238.7000 Fractcuts:  1        2

Gomory fractional cuts applied: 1

Integer optimal solution:  Objective =    8.2387000000e+03
Solution time =    0.00 sec.  Iterations = 2  Nodes = 0
CPLEX> display sol obj -
Integer optimal solution:  Objective =    8.2387000000e+03
CPLEX> display sol var -
Variable Name           Solution Value
x11                           1.000000
x21                           1.000000
n1                           20.000000
n2                           15.000000
d1                            1.000000
y1                            1.000000
All other variables in the range 1-10 are zero.
 

Case 3
CPLEX> display problem all
Minimize
 obj: 138 x11 + 552 x12 + 27.4 x21 + 19.2 x22 + 240 n1 + 200 n2 + 250 d1
 + 400 d2 + 23.3 y1 + 34.3 y2
Subject To
 c1: x11 + x12  = 1
 c2: x21 + x22  = 1
 c3: y1 + y2  = 1
 c4: d1 + d2  = 1
 c5: n1 >= 20
 c6: n2 >= 15
 c7: 0.6 x11 + 0.78 x12 + 0.85 x21 + 0.48 x22 + 0.05 n1 >= 2.46
 c8: 2.6 x11 + 2.3 x12 + d1 + 1.22 d2 + 1.8 y1 + 1.6 y2  >= 5.62
Bounds
 0 <= x11 <= 1
 0 <= x12 <= 1
 0 <= x21 <= 1
 0 <= x22 <= 1
      n1 >= 0
      n2 >= 0
 0 <= d1 <= 1
 0 <= d2 <= 1
 0 <= y1 <= 1
 0 <= y2 <= 1
Generals
 x11  x12  x21  x22  n1  n2  d1  d2  y1  y2
CPLEX> optimize
Tried aggregator 1 time.
MIP Presolve eliminated 2 rows and 1 columns.
Aggregator did 4 substitutions.
Reduced MIP has 2 rows, 5 columns, and 6 nonzeros.
Presolve time =    0.00 sec.
Clique table members: 1
MIP emphasis: optimality
Root relaxation solution time =    0.00 sec.

        Nodes                                         Cuts/
   Node  Left     Objective  IInf  Best Integer     Best Node    ItCnt     Gap

      0     0     8436.7000     1                   8436.7000        2
*                 8628.7000     0     8628.7000      Cuts:  2        5

Mixed integer rounding cuts applied:  1

Integer optimal solution:  Objective =    8.6287000000e+03
Solution time =    0.00 sec.  Iterations = 5  Nodes = 0

CPLEX> display sol var -
Variable Name           Solution Value
x11                           1.000000
x21                           1.000000
n1                           21.000000
n2                           15.000000
d2                            1.000000
y1                            1.000000
All other variables in the range 1-10 are zero.
CPLEX> display sol obj -
Integer optimal solution:  Objective =    8.6287000000e+03

Case 4
CPLEX> display problem all
Minimize
 obj: 138 x11 + 552 x12 + 27.4 x21 + 19.2 x22 + 240 n1 + 200 n2 + 250 d1
 + 400 d2 + 23.3 y1 + 34.3 y2
Subject To
 c1: x11 + x12  = 1
 c2: x21 + x22  = 1
 c3: y1 + y2  = 1
 c4: d1 + d2  = 1
 c5: n1 >= 20
 c6: n2 >= 15
 c7: 0.6 x11 + 0.78 x12 + 0.85 x21 + 0.48 x22 + 0.05 n1 >= 2.64
 c8: 2.6 x11 + 2.3 x12 + d1 + 1.22 d2 + 1.8 y1 + 1.6 y2  >= 5.1
Bounds
 0 <= x11 <= 1
 0 <= x12 <= 1
 0 <= x21 <= 1
 0 <= x22 <= 1
      n1 >= 0
      n2 >= 0
 0 <= d1 <= 1
 0 <= d2 <= 1
 0 <= y1 <= 1
 0 <= y2 <= 1
Generals
 x11  x12  x21  x22  n1  n2  d1  d2  y1  y2
CPLEX> optimize
Tried aggregator 1 time.
MIP Presolve eliminated 2 rows and 1 columns.
Aggregator did 4 substitutions.
Reduced MIP has 2 rows, 5 columns, and 6 nonzeros.
Presolve time =    0.00 sec.
Clique table members: 1
MIP emphasis: optimality
Root relaxation solution time =    0.00 sec.

        Nodes                                         Cuts/
   Node  Left     Objective  IInf  Best Integer     Best Node    ItCnt     Gap

      0     0     8700.7000     1                   8700.7000        1
*                 8892.7000     0     8892.7000      Cuts:  2        4

Mixed integer rounding cuts applied:  1

Integer optimal solution:  Objective =    8.8927000000e+03
Solution time =    0.01 sec.  Iterations = 4  Nodes = 0
CPLEX> display sol obj -
Integer optimal solution:  Objective =    8.8927000000e+03
CPLEX> display sol var -
Variable Name           Solution Value
x12                           1.000000
x21                           1.000000
n1                           21.000000
n2                           15.000000
d1                            1.000000
y1                            1.000000
All other variables in the range 1-10 are zero.

Case 5
CPLEX> display problem all
Minimize
 obj: 138 x11 + 552 x12 + 27.4 x21 + 19.2 x22 + 240 n1 + 200 n2 + 250 d1
 + 400 d2 + 23.3 y1 + 34.3 y2
Subject To
 c1: x11 + x12  = 1
 c2: x21 + x22  = 1
 c3: y1 + y2  = 1
 c4: d1 + d2  = 1
 c5: n1 >= 20
 c6: n2 >= 15
 c7: 0.6 x11 + 0.78 x12 + 0.85 x21 + 0.48 x22 + 0.05 n1 >= 3.1
 c8: 2.6 x11 + 2.3 x12 + d1 + 1.22 d2 + 1.8 y1 + 1.6 y2  = 5.62
Bounds
 0 <= x11 <= 1
 0 <= x12 <= 1
 0 <= x21 <= 1
 0 <= x22 <= 1
      n1 >= 0
      n2 >= 0
 0 <= d1 <= 1
 0 <= d2 <= 1
 0 <= y1 <= 1
 0 <= y2 <= 1
Generals
 x11  x12  x21  x22  n1  n2  d1  d2  y1  y2

CPLEX> optimize
Tried aggregator 1 time.
MIP Presolve eliminated 2 rows and 1 columns.
Aggregator did 4 substitutions.
Reduced MIP has 2 rows, 5 columns, and 6 nonzeros.
Presolve time =    0.00 sec.
Clique table members: 1
MIP emphasis: optimality
Root relaxation solution time =    0.00 sec.

Integer optimal solution:  Objective =    1.1508700000e+04
Solution time =    0.00 sec.  Iterations = 2  Nodes = 0

CPLEX> display sol obj -
Integer optimal solution:  Objective =    1.1508700000e+04
CPLEX> display sol var -
Variable Name           Solution Value
x11                           1.000000
x21                           1.000000
n1                           33.000000
n2                           15.000000
d2                            1.000000
y1                            1.000000
All other variables in the range 1-10 are zero.