System Analysis Report for Allure Investments Pty. Ltd. System

This report presents a system analysis for Allure Investments Pty. Ltd., focusing on the development of an information system to manage client portfolios and investments. It begins with an executive summary and system description, followed by a scope definition and feasibility analysis, which highlights the need for a new system to improve efficiency and productivity. The report details both functional and non-functional requirements, outlining the needs of various user roles such as portfolio managers, account managers, fund managers, and clients. Assumptions and constraints are also discussed. Unified Modeling Language (UML) is used to model the system, including use case diagrams, context models, and data flow diagrams (DFDs) to illustrate system processes and interactions. The report provides detailed use case descriptions and DFDs at levels 0 and 1, offering a comprehensive overview of the proposed system's design and functionality. The goal is to create a web-based system that improves data management, provides remote access, and enhances overall operational efficiency.

COVER PAGE
Contents
Executive summary.....................................................................................................................................3
System description......................................................................................................................................3
Scope...........................................................................................................................................................3
Feasibility analysis.......................................................................................................................................3
Requirements specifications........................................................................................................................4
Functional requirements.........................................................................................................................4
Non-functional requirements..................................................................................................................5
Assumptions and constraints......................................................................................................................5
Use cases.....................................................................................................................................................6
Use case diagram.....................................................................................................................................6
Use case descriptions..............................................................................................................................6
Context model.............................................................................................................................................9
Leveled sets of function models................................................................................................................10
Level 0 DFD............................................................................................................................................10
Level 1 DFD............................................................................................................................................10

Executive summary
This report presents a discussion on the system analysis process of the proposed information system for
Allure Investments Pty. Ltd. which is a company specializing in management of client portfolio’s and
active investments on the Australian Stock exchange on behalf of the clients. The company is in need of
an information system that will help them to manage day to day activities while maintaining the data
generated through these activities. The document describes the scope of the proposed system and
presents a feasibility analysis to determine whether or not the proposed system is a viable option for the
company or not. Functional and non-functional requirements of the system are described and all the
system constraints necessary for the implementation of the system are discussed. Unified Modelling
language is adapted for the proposed system as it makes it easier to analyse and document the system
through use of use case diagrams, context models and functional models. These models can then be
used to make the design document for the proposed system.
System description
The current system in use by the company is a manual system which is making work very tedious thus
limiting individual productivity of each employee as well as adding redundancies in some roles. The
proposed system will be designed to solve this problems by making it easy for employees to perform
various tasks. The system will be a web based system thus will require a web server to be deployed. This
will enable remote access of the system for both employees and customers wishing to access their
portfolios.
Scope
The proposed system will be developed within the required time frame and allocated resources. A
project plan defining the project schedule, resources and budget will be followed entirely throughout
the project life cycle. The development team will ensure each stage of the project development life cycle
is followed and all goals are achieved to make sure the final product meets all functional and no-
functional requirements.
Feasibility analysis
Feasibility analysis is done before the project is started to determine whether or not the project is
economically and technically feasible for the company. This involves carrying out a study on the
resources and the time it will take to implement and deploy the system and comparing it to the time it
will take for the system to start returning a return on investment. For the proposed system, there are
many factors that limit the current system thus warranting need for a new system. These factors
include;
 The current manual is tedious for employees for example the portfolio managers thus limiting
their productivity and ability to handle multiple portfolios.
 The current manual system does not give access to a client thus a client has to rely on the
concerned parties to access their portfolios.
 The current manual system is creating redundancies in different roles within the company thus
leading to a higher budget on salaries.

The proposed system will be implemented to make work easier thus improving productivity of the
employees. This means the company will be able to handle more clients and more transactions because
the system will make it easier to track client and information and market information thus leading to
high profits for both the clients and the company. The system will also eliminate redundant roles thus
reducing the amount of money used for salaries.
Based on the analysis presented above, the system is both technically viable and economically viable as
it’s expected to make a return on investment within a short period of time.
Requirements specifications
Functional requirements
Functional requirements are what the end user expects from the system. These are requirements
described by the end user on how he or she should use the application to achieve various goals defined
within the scope of the system. For the proposed system, the functional requirements can be defined in
terms of the different type of end users using the system;
Portfolio-manager
As a portfolio manager, I would like to;
 Access and review client portfolios at any time.
 Buy and record stocks for a client. I should be able to specify the stop-loss and the selling-price
for each buy. The system should notify me if the stock reaches a stop-loss or if the stock reaches
the selling-price.
 Sell and record client stocks
Account manager
As an account manager, I should be able to;
 Add a new client after conducting an interview with the client.
 Assign a portfolio manager to a new client
 Add and update the yearly funding level for a client
 Review portfolio manager performance.
 Place sell orders issued by the portfolio manager
 Receive and record dividends received from different companies.
 Report client positions.
Fund manager
As a fund manager, I should be able to;
 Access and maintain buy and sell orders for each client
 Access and maintain information regarding buy and sell parcels
 Access and maintain information regarding dividends.
Client
As a client, I should be able to;

 Access and check my portfolio balance
 Deposit funds to my portfolio
 Generate reports on my buy and sell orders
 View my profile
Non-functional requirements
Non-functional requirements specify the constraints that the system should follow in order to achieve
different functional requirements. The following are the non-functional requirements for the proposed
system;
 Performance- The proposed should be able to perform all actions using the least amount of time
possible.
 Availability- The proposed system should be available at all times and should be accessible from
any remotely from any location.
 Security- This is perhaps the most critical non-functional requirement for the proposed system.
The system should be able to ensure security at all levels and at all times considering the nature
of the application since the data generated by the system is critical and sensitive thus falling on
a malicious user could lead to losses.
 Robustness- The proposed system should be robust meaning it should continue operating
despite encountering an error.
Assumptions and constraints
The proposed system will be implemented based on the following assumptions;
 The system will be implemented as a web application allowing remote access for both
employees and customers.
 The system will use third party applications like payment merchants to take advantage of
existing solid APIs that will make the development process easy.
 The system will be deployed in a private cloud instead of deploying the web application in an on
premise server room.

Use cases
Use case diagram
Figure 1: Use case diagram
Use case descriptions
Use Case ID: UC1
Use Case Name: Login
Actor: Portfolio-manager, client, fund manager, account manager
Description: Any of the actors logs in to access their account
Preconditions: The user must be connected to the internet
Postconditions: A user session is created
Frequency of Use: Regular
Normal Course of Events: 1. User enters username and password

2. System validates the credentials
3. System creates user session and redirects the user to the
specific dasboard
Alternative Courses: 2. System validates the credentials
2.1 Credentials are not correct
2.2 Display message to the user and go back to step 1
Exceptions: None
Includes: None
Use Case ID: UC2
Use Case Name: Add Customer
Actor: Account manager
Description: Account manager creates an account for a customer after
conducting an interview with the customer
Preconditions: User must be logged in
Postconditions: A new customer record is added to the database
Frequency of Use: Regular
Normal Course of Events: 1. User enters details of the customer and submits
2. System validates the details entered.
3. System adds the record to the database and creates a new
customer portfolio.
4. System displays success message to the user
Alternative Courses: 2. System validates the credentials
2.1 Credentials are not correct
2.2 Display message to the user and go back to step 1
Exceptions: None
Includes: None
Use Case ID: UC3

Use Case Name: Access client sell orders
Actor: Fund manager
Description: A fund manager accesses and retrieves a customer’s sell orders
Preconditions: The user must be logged in into their account
Postconditions: None
Frequency of Use: Regular
Normal Course of Events: 1. User enters name or id of the customer and submits form
2. System retrieves the customer based on the search
parameter and value.
3. System displays the sell orders in a tabular format
Alternative Courses: 2. System retrieves the customer based on the search
parameter and value
2.1 System finds no results under the search value and
parameter.
2.2 System displays no record found
Exceptions: None
Includes: None
Use Case ID: UC4
Use Case Name: Buy client stock
Actor: Account manager
Description: An account manager buys stock for a client
Preconditions: The user must be logged in into their account
Postconditions: None
Frequency of Use: Regular
Normal Course of Events: 1. User enters name or id of the customer and submits form
2. System retrieves the customer based on the search
parameter and value.
3. User enters the amount of cash the stocks cost.

4. System checks client has enough balance.
5. User enters the details of the purchase and submits.
6. System processed the purchase and updates the customer
balance.
7. System creates a new parcel for the buy order.
8. System displays a success message
Alternative Courses: 9. System retrieves the customer based on the search
parameter and value
a. System finds no results under the search value and
parameter.
b. System displays no record found
Exceptions: None
Includes: Record stop loss, record selling-point
Context model

Leveled sets of function models
Level 0 DFD
Level 1 DFD
This figure below shows level 1 DFD for check balance which is initiated by external actor client.