Software Requirement Specification (SRS) for

Real-Time System
Personal Investigation Management System
(PIMS)
1. Introduction

1.1 Purpose:
Personal Investment Management System (PIMS) is intended to help the
user keep account of his/ her money invested in institutions such as Banks
and Share Market.

This document is meant to delineate the features of PIMS, so as to serve

as a guide to the developers on one hand and a software validation document
for the prospective client on the other.

1.2 Scope:
We describe what features are in the scope of the software and what are
not in the scope of the software to be developed.
In Scope:
a. Managing investment of a single user, which would include maintaining
bookkeeping information about entities like Portfolio, Security, and
Transaction.
b. Compute ion of Net -Worth and Rate of Investment (ROI) of the Investor.
c. Giving alerts to the user, if he requests for one.
d. Downloading the current prices of shares from the web.
e. User authentication.

Out of Scope:
a. Features for actual purchasing and selling of securities. That is, actually
buying and selling of shares/ securities is done outside PIMS.
b. Tax computations for gains/ losses.
c. Any market related prediction.
2. Overall Description:

2.1 Product Perspective:

PIMS is aimed toward a person who has considerable number of investments
in stock market and banks, and so needs software assistance for book keeping
and computations regarding the investments. PIMS should be user-friendly,
‘quick to learn’ and reliable software for the above purpose.

PIMS is intended to be a stand -alone product and should not depend on the
availability of other software. It should run on both UNIX and Windows
based platform.
2.2 User Characteristics:
a. The user should be familiar with the Investment Management related
terminology like Portfolio/ Security/ Transaction.
b. The user should know the details of a transaction.
 2.3 Principal Actors:
The two principal actors in PIMS are “user” and “system”.

2.4 General Constraints:

a. For full working PIMS requires Internet connection.
b. PIMS is single -user software.

2.5 Assumptions and Dependencies:

a. Full working of PIMS is dependent on the availability of Internet connection.
b. The downloading of share prices in PIMS is customized to
www.indiainfoline.com. PIMS would not work for any other website.
c. The company shares registered in the National Stock Exchange
(NSE) are only considered by PIMS.
3 Specific Requirements:

3.1 Functional Requirements:

We describe the functional requirements by giving various use cases.

Use case related to installation:

Use Case 1: Installation
Primary Actor: User
Pre-Condition: Internet connection available.
Main Scenario:
1. User initiates PIMS installation program.
2. System asks the user for the home directory in which all the
working files will be created. User is also asked for the initial
login and password.
3. User specifies the home directory and login/ password.
4. System creates the working files in the specified home
directory. Working files contain:
a. Authorization information.
b. List of company names.
c. Current share prices.
d. Investment structure.
5. System downloads the list of companies (registered in NSE, from
www.indiainfoline.com) and the current share prices. It initializes
the files containing the list of companies and the current share
prices with the downloaded data.
Alternate Scenario:
5(a). Network failure.
5(a)1. Installation aborted.

Use cases related to system authorization:

Use Case 2: Login Primary Actor:
User Pre-condition: Nil
Main Scenario :
1. Start the application. User prompt ed for login and password.
2. User gives the login and password.
3. System does authentication.
 4. Main screen is displayed.
Alternate Scenario:
4(a). Authorization fails
4(a)1. Prompt the user that he typed the wrong password
4(a)2. Allow him to re -enter the password. Give him 3 chances.

Use Case 3: Change Password

Primary Actor: User
Pre-Condition: User logged in
Main Scenario:
1. User initiates the password change command.
2. User is prompted for old pas’ sword, new password and confirm new
password.
3. User gives the old password, new password and confirm new
password.
4. System does authentication.
5. New password is registered with the system.
Alternate Scenario:
4(a). Authorization fails
4(a)1. Prompt the user that he typed the wrong password
4(a)2. Allow him to re -enter the password. Give him 3 chances.
4(b). New password and confirm new password do not match.
4(b)1. Allow him to re -enter the attributes. Give 3
chances.

Use cases related to portfolios:

Use Case 4: Create Portfolio
Primary Actor: User
Pre-Condition: User logged in.
Main Scenario :
1. User initiates the “create portfolio” functionality.
2. System asks the user for the portfolio name .
3. User enters the portfolio name.
4. An empty portfolio is created.
Alternate Scenario :
4(a). Portfolio with the same name exists.
4(a)1. System asks the user for a different name.
4(a)2. User enters a different name.
4(a)3. Empty portfolio gets created.

Use Case 5: Rename portfolio.

Primary Actor : User
Pre-Condition: User logged in.
Main Scenario :
1. User initiates the “rename portfolio” functionality.
2. System asks for the portfolio to be renamed and the new name.
3. User enters the new name.
4. Portfolio is renamed.
Alternate Scenario :
4(a). The portfolio whose name is supposed to change does not exist.
4(a)1. Renaming fails, the error message is displayed.
 4(b). Portfolio with the same new n ame exists.

3.2 Performance Requirements:

(a) Should run on 500 MH z, 64 MB machine.
(b) 90% of the responses should be within 2 sec, except for downloading
current prices for which more time is acceptable.

3.3 Design Constraints:

1. Security: The files in which the information regarding securities and
portfolios should be secured against malicious deformations.
2. Fault Tolerance : Data should not become corrupted in case of system
crash or power failure.

3.4 External Interface Requirements:

The user screen is split vertically into two panes. The left pane contains
the Investment tree, which expands and contracts as per user action. The
right part displays the information related to investment/ portfolio/ security
that is specified on the left pane. Appendix B shows the intended user
screen.

4. Future Extensions:
a. PIMS is intended to be a sing le user software. A possible future
extension would be to make it multi user.
b .Renaming fails, the error message is displayed.

Use Case 6: Delete portfolio.

Primary Actor : User
Pre-Condition: User logged in.
Main Scenario :
1. User initiates the” d e l e t e portfolio” functionality.
2. System asks for the name of the portfolio.
3. The portfolio is deleted.
Alternate Scenario :
3(a). Portfolio does not exist.
3(a)1. Deletion fails, error message is displayed.

Use cases related to securities:

Use Case 7: Create a security.
Primary Actor : User
Pre-Condition: User logged in.
Main Scenario :
1. User selects the portfolio in which the security is to be created.
2. User initiates the “create security” functionality.
3. System asks the user to enter the attributes of the security.
4. User specifies the following fields:
a. Name
b. Type : bank or share.
c. Rate of interest : if the type is bank.
d. Company name: if the type is share. Choosing the company
from a list companies does this. (Companies registered in the
National Stock Exchange, names downloaded at the installation
 time. Refer use case 1)
5. An empty security of specified attributes is created.
Alternate Scenario :
5(a) A security with the given name already exists.
5(a)1. Security creation fails, error message is displayed.

Use Case 8: Rename security.

Primary Actor : User
Pre-Condition: User logged in.
Main Scenario :
1. User selects the portfolio.
2. User initiates the “rename security” functionality.
3. System asks the user for the security and the new name.
4. User enters the security name and the new name.
5. Name is changed.
Alternate Scenario :
5(a). The security whose name is supposed to change does not exist.
5(a)1. Renaming fails, the error message is displayed.
5(b). Security with the same new name exists.
5(b)1. Renaming fails, the error message is displayed.

Use Case 9: Delete security.

Primary Actor : User
Pre-Condition: User logged in.
Main Scenario :
1. User selects the portfolio.
2. User initiates the “delete security” functionality.
3. System asks for the security name.
4. Security is deleted.
Alternate Scenario
4(a). Security does not exist.
4(a)1. Deletion fails, error message is displayed.

Use cases related to transactions:

Use Case 10: Adding a transaction.
Primary Actor : User.
Pre-Condition: User logged i n.
Main Scenario :
1. User selects the portfolio and the security.
2. User initiates the “add transaction” functionality.
3. System prompts the user for following details, depending
on the security type
(i) If the security is of sha re type:
a. Number of shares transacted
b. Type of transaction: buy or sell
c. Price of one share
d. Date of transaction
e. Any detail user might want to enter.

(ii) If the security is of bank type:

 a. Amount of money transacted
b. Type of transaction: credit or debit.
c. Date of transaction
d. Any detail user might want to enter.
4. New transaction is created.
Alternate Scenario :
4(a). Invalid attribute value is entered. For example field (i)(a) is not an
integer or (i)(c) is not a float.
4(a)1. User is shown the error displayed and prompted to enter the
incorrect fields again.

Use Case 11 : Editing a transaction.

Primary Actor : User.
Pre-Condition: User logged in.
Main Scenario :
1. Users lets the portfolio, security and transaction.
2. User initiates the “edit transaction” functionality.
3. System asks the user to enter new fields for the transaction. The
fields are the same as given in Use case 1.
4. The modified transaction is saved.

Alternate Scenario :
4(a). Invalid attribute value entered. For example field (i)(a) is not an
integer or (i)(c) is not a float.
4(a)1. User is shown the error displayed and prompted to enter
the incorrect fields again.

Use Case 12: Deleting a transaction.

Primary Actor : User.
Pre-Condition: User logged in.
Main Scenario :
1. User specifies the portfolio, security and transaction.
2. User initiates the “delete transaction” functionality.
3. The transaction is deleted.

Use cases related to information display:

Use Case 13 : Display Investment
Primary Actor: User.
Pre-Condition: User logged in.
Main Scenario:
1. User selects the option of viewing the Investment (from the left
pane, refer user screens in Appendix C).
2. System computes the net worth for each portfolio. Refer use case
16.
3. System displays the name of all portfolios with their net -worth. It also
shows the net -worth of entire investment by adding up the net -
worth of each portfolio.

Use Case 14 : Display Portfolio

Primary Actor: User
Pre-Condition: User logged in.
 Main Scenario:
1. User selects the option of viewing a particular portfolio
(selects a portfolio from the left pane, refer user screens in
Appendix A).
2. System computes the net -worth and ROI of each security. Refer
use cases 16 and 17.
3. System displays the securities in the portfolio with the net-worth and
ROI computed. It also displays the net -worth of the portfolio by
summing up the net -worth of each security.

Use Case 15 : Display Security

Primary Actor: User
Pre-Condition: User logged i n.
Main Scenario:
1. User selects the option of viewing a particular security (selects
a portfolio from the left pane, refer user screens in Appendix
C).
2. System displays all the transactions.

Use cases related to computations

Use Case 16: Compute Net-Worth.
Primary Actor : System.
Pre-Condition: User logged in & investment/ portfolio/ security specified
Main Scenario :
1. System computes net -worth for investment/ portfolio/ security
specified (Appendix B shows the detailed method for computing the
net-worth).

Use Case 17 : Compute Rate of Investment.

Primary Actor : System.
Pre-Condition: User logged in & security specified
Main Scenario :
1. System computes ROI for the security s pecified ( Appendix A shows
the detailed method for computing the ROI) .

Use cases related to share prices

Use Case 18: Getting the current prices of shares.
Primary Actor : User.
Pre-Condition: User logged in and internet connection exists.
Main Scenario :
1. User initiates the “download current prices” functionality.
2. The system down loads the current share prices from a particular
website.
Alternate Scenario:
2(a). Not able to download (due to network failure, site down, …)
1. Display current value saved from before; ask the user to change it

Use Case 19 : Editing the share prices.

Primary Actor : User.
Pre-Condition: User logged in.
Main Scenario :
 1. User initiates the “Edit share prices” functionality.
2. The system shows the list of all the companies and their current
share prices (as known to the system).
3. User edits the price of the company share he wants to edit.

Alternate Scenario:
3(a). The entered price is invalid.
3(a)(i) User is shown the error displayed.
3(b). The company name does not exist in the list of companies
3(b)1. This is not handled by PIMS. PIMS is customized for the 760
-
800odd companies registered in the NSE.
Use cases related to alerts
Use Case 20: Setting alerts
Primary Actor : User.
Pre-Condition: User logged in.
Main Scenario :
1. User initiates the “set alert” functionality.
2. The system asks the user for the date and details of the alert.
3. The alert is set.

Use Case 21: Show the pending alerts.

Primary Actor : User.
Pre-Condition: User logged in.
Main Scenario :
1. User initiates the “show pending alerts” functionality.
2. System shows the pending alerts.

Use Case 22 : Delete alerts.

Primary Actor : User.
Pre-Condition: User logged in.
Main Scenario :
5. User initiates the “delete alerts” functionality.
6. User is asked for the alert to be deleted.
7. The alert is deleted.
4.Future Extensions:
a. PIMS is intended to be a sing le user software. A possible future extension
would be to make it multi user.