Software Engineering: Portfolio Management System Methodology Report

This report presents a comprehensive analysis of a Portfolio Management System (PMS) using software engineering methodologies. It begins with a detailed specification document, outlining system descriptions, scope, feasibility analysis, and requirement specifications (both functional and non-functional). The document includes use case diagrams, context models, and functional modeling, including data flow diagrams at different levels. The design document covers architectural designs, hardware specifications, class diagrams, interface diagrams, and a business process model. Additionally, it incorporates sequence, interaction, and state diagrams to provide a complete understanding of the system's structure and functionality. The report addresses various aspects of the PMS, including user roles (portfolio manager, fund manager, account manager, executive manager, and client), system functionalities (portfolio management, market updates, report generation), and system constraints (internet connectivity, cost limitations).

SOFTWARE
ENGINEERING
METHODOLOGY

EXECUTIVE SUMMARY
1. Specification Document
This case study is based on the software engineering methodology. In this Software
specification documents are explained with various diagrams and models. In this description of
the system is given. System description gives a brief description of the system and the hardware
components. It gives a description about how the system programs are linked to each other.
Portfolio management system can be used by the portfolio manager, Fund manager, Account
manager, executive manager and at last by the client. The main function of this system is to
manage and maintain the portfolio of the clients. Scope of the system defines the requirements of
the systems or the expectations of the system or interface. In simple words it defines what system
will include or what system will not include, enough details to clearly communicate details to all
the participants or users of the system. This Portfolio management system has all its functions
bifurcated according to the users of the system. Feasibility analysis is the study that is used to
determine viability of an idea like, ensuring the project is technically feasible and legal as well as
economically justifiable. It also tells whether the project is feasible or not. Requirement
specification describes the requirement of a software system to be developed both functional and
non functional requirements. Assumption and constraints related to the system hare also
described below. Specification description also includes Use case diagrams with its description,
Context model and functional modelling.
2. Design Document
In this case study design document description is also given which includes Architectural
diagram, hardware specification, class diagram, interface diagram, Business process model
which is an activity of representing processes of an enterprise or a system, so that the current
process can be improved. In this Allure Investments company does not have a portfolio
management system. So here business process model of the PMS system will be made in order to
understand all the processes of the system. Business process model notation is a simple graphical
representation of specific business processes in a business process model. It uses four types of
objects such as: events, activities, gateways, connections. These objects further consist of many
sub elements. It also consists of sequence diagram, interaction diagram and state diagram.

Table of Contents
EXECUTIVE SUMMARY.............................................................................................................2
1. Specification Document..........................................................................................................2
2. Design Document....................................................................................................................2
1. Specification Document...............................................................................................................4
A.) System Description..............................................................................................................4
B.) Scope.....................................................................................................................................4
C.) Feasibility Analysis...............................................................................................................4
D.) Requirement Specification....................................................................................................5
I) Functional Requirement......................................................................................................5
II) Non-Functional Requirement............................................................................................5
E.) Assumptions and constraints.................................................................................................6
F.) Use Case................................................................................................................................6
I) Diagram..............................................................................................................................7
II) Use Case Description........................................................................................................7
G.) Context model.......................................................................................................................8
H.) Functional Modelling............................................................................................................9
Data Flow Diagram.....................................................................................................................9
Level 0 DFD.........................................................................................................................10
2. Design Document.......................................................................................................................10
A.) Architectural Design...........................................................................................................10
B.) Hardware Specifications.....................................................................................................11
C.) Detailed class Diagram.......................................................................................................11
D.) Interface Diagram...............................................................................................................14
E.) Business process model.......................................................................................................15
F.) Sequence Diagram...............................................................................................................16
G.) Interaction Diagram............................................................................................................17
H.) State Diagram......................................................................................................................18

1. Specification Document
A.) System Description
System description gives a brief description of the system and the hardware components.
It gives a description about how the system programs are linked to each other (Shehory and
Sturm, 2016). Portfolio management system can be used by the portfolio manager, Fund
manager, Account manager, executive manager and at last by the client. The main function of
this system is to manage and maintain the portfolio of the clients. With the help of this system a
single portfolio manager will be able to handle more than 12 clients together. This system will
also help managers to maintain, sell or buy shares for customers and will be able to maintain the
record of customers stock buy or sell activities. This system will require one computer system
with network connection. Computer will be needing internet connection to run this PMS system.
All the calculations related funds will be automatically done by the system. All the users of the
system will be able to access their profile only and will not be able to access or interfere in
others profile.
B.) Scope
Scope of the system defines the requirements of the systems or the expectations of the
system or interface. In simple words it defines what system will include or what system will not
include, enough details to clearly communicate details to all the participants or users of the
system. This Portfolio management system has all its functions bifurcated according to the users
of the system. This system requires internet connection to update the market movement of the
shares or the funds clients want to sell or buy. It will enable managers to respond quickly
according to any movement in the market. This system will also maintain the portfolio of all the
clients their funds and dividend. This system will also enable managers to generate tax report.
C.) Feasibility Analysis
Feasibility analysis is the study that is used to determine viability of an idea like, ensuring
the project is technically feasible and legal as well as economically justifiable. It also tells
whether the project is feasible or not.
 Enough technical resources are available in the company for the system to be developed.
It helped the technical to develop the portfolio management software.
 It would be difficult for the technical team to complete the whole project within the
limited cost of the project.

 The time period given for the project to be completed is sufficient to develop the
complete system.
D.) Requirement Specification
Requirement specification describes the requirement of a software system to be
developed both functional and non functional requirements. Both functional and non functional
requirements of the system are as follows:
I) Functional Requirement
 System should be connected with the internet so that market movements can be updated.
 Client shall be able to update their portfolio details.
 Client shall be able to get market information and their balance enquiry.
 Users of the system should be logged in according to their user type.
 Client portfolio's should be automatically get assigned to the portfolio manager according
to the client requirements.
 Fund manager should update the database if any shares are bought or sold.
 Database should automatically get updated if any changes are done in the customer's
portfolio and dividend.
 Tax report should automatically get generated and easily downloaded for users use.
II) Non-Functional Requirement
 Users should be able to change or update their passwords according to their convenience.
 Executive manager should ensure that portfolio details of a particular client can only be
excessed that that particular client only.
 Password should not be viewable to the users it should be hidden from the user.
 Users should get only three login attempts and each attempt should be recorded.
 Users shall receive notification whenever they change their password or whenever they
login.

 Response time of the system should be less sop that efficiency of the software can be
increased.
 Portability of the software should be easy like it can easily be transferred from one
hardware to another.
 Instability of the system should be easy i.e. it can easily be installed or uninstalled or
reinstalled. Confidentiality of the system must be high i.e. all the sensitive data must be protected and
accessed by only authorized person and no one else should be able to access it.
E.) Assumptions and constraints
 This Portfolio management system will not work on Linux operating system and work
on all the other operating systems.
 This system will be able to handle only single changes made by a single user at a time.
Duel changes made by a single user simultaneously will result in error.
 This system will provide with download facility for every portfolio details for the
managers.
 One of the main constraint of the system is its limited cost for development.
 Rules, laws and regulations of the company was also one of the major constraint.
 Internet connection was also one of the main constraint as this system will not work
offline it compulsorily needs an internet connection in order to run the system.
F.) Use Case
Use case diagram is the simplest representation of user's interaction with the system that
shows relationship between the users and different use cases in which users are involved. It has
two components that is An actor who is the user and a use case.

I) Diagram
II) Use Case Description
Allows All the managers to login into the system from their respective user id's. Then
Executive manager will assign portfolio's to the portfolio manager according to the client
requirement. Then portfolio manager will update the dividend according to the clients request for
the share (whether they want to buy the share or sell the shares). Fund manager will update the
market movements of the shares and inform the client and accordingly will buy or sell the shares
and update the database. At last fund manager will be able to generate and download the tax
report of the client.
 Use case name: Portfolio management system
 Actors:
◦ Executive manager
◦ Portfolio manager
◦ Client
Illustration 1: Use case Diagram

◦ Fund manager
 Pre-conditions:
◦ All the users should have their account with authentic user id and password in order
to login.
◦ Clients should update their balance first in order to maintain their funds (buying or
selling of shares).
 Post-conditions:
◦ Portfolios have been successfully assigned to portfolio manager.
◦ Clients funds have been successfully updated.
◦ Changes made in database has also been updated.
 Flow:
◦ Portfolio's assigned to the respective portfolio manager.
◦ Clients updates their available balance.
◦ Client request for funds updates (buying or selling of shares)
◦ Fund manager updates the system with current market movements and buys or sells
the shares of the clients as desired by them.
◦ Database and client balance is updated according to the changes made.◦ At last tax report is generated and downloaded of the client.
G.) Context model
It defines how the data is structured and maintained. It simply aims to produce a semi-
formal or formal description of information regarding the system.

H.) Functional Modelling
It generally gives the process representation of the system or overview of what system
does. This is generally represented with a hierarchy of DFD's
Data Flow Diagram
It is the graphical representation of the system that shows all the inputs of the system. It is
made in various levels but the most common levels are context level and zero level data flow
diagram.
Context level DFD
Ill
ustration 2: Context Model

Level 0 DFD
2. Design Document
A.) Architectural Design
It is the high level structure of the system.
Illustration 3: Context level DFD
Ill
ustration 4: Level 0 DFD diagram

B.) Hardware Specifications
Hardware specification of the system are as follows:
 Processor: more than 500 MHZ
 Ram required: 2 GB or above
 Hard disk capacity required: minimum hard disk required is 80 GB or above
 Display type: Standard VGA or SVGA card.
 Database required: MySQL version 5.0
Il
lustration 5: Architectural Diagram

C.) Detailed class Diagram
Class diagram is the Unified Modelling Diagram which is a static structure diagram. It
describes the structure of a system by showing the system's classes, operations ( or methods ),
Classes attributes and the relationship among the objects. It is mostly used for modelling of the
systems (Torre and et.al, 2018).
D.) Interface Diagram
Interface diagram of the system are designed to understand the development process of
the system at an early stage. It is a high level diagram which represented the interfaces. It is
similar to data flow diagram but different from it.
Ill
ustration 6: Class Diagram

E.) Business process model
It is an activity of representing processes of an enterprise or a system, so that the current
process can be improved. In this Allure Investments company does not have a portfolio
management system. So here business process model of the PMS system will be made in order to
understand all the processes of the system. Business process model notation is a simple graphical
representation of specific business processes in a business process model. It uses four types of
objects such as: events, activities, gateways, connections. These objects further consist of many
sub elements.
Ill
ustration 7: Interface Diagram

F.) Sequence Diagram
Sequence diagram simply shows the interaction between all the objects which are
arranged in a time sequential order. This diagram depicts all the classes and objects involved in
the scenario and the sequence of messages exchanged between all the objects which are needed
to carry out the functionality of the scenario. This diagram depicts how and in what order all the
objects in a system functions (Torre and et.al, 2018).
Ill
ustration 8: Business process model

G.) Interaction Diagram
Interaction diagram are models that describes how a group of objects collaborate in some
behaviour. This diagram shows many objects and the messages that are passed between these
objects.
Il
lustration 9: Sequence Diagram

H.) State Diagram
State diagram is a diagram used to describe the behaviour of the system. This diagrams
require that the system described is composed of a finite number of states. It is a dynamic nature
system of unified modelling language ( UML ). These diagrams define different states of the
during its lifetime and states that change the event. These are the most useful diagrams when the
system is reactive (Störrle, 2018).
Illustratio
n 10: Interaction diagram

Illu
stration 11: State diagram

REFERENCES
Books and Journals
Shehory, O. and Sturm, A., 2016. AGENT-ORIENTED SOFTWARE ENGINEERING.
SPRINGER-VERLAG BERLIN AN.
Störrle, H., 2018. On the impact of size to the understanding of UML diagrams. Software &
Systems Modeling. 17(1). pp.115-134.
Torre, D., and et.al., 2018, May. UML diagram synthesis techniques: a systematic mapping
study. In 2018 IEEE/ACM 10th International Workshop on Modelling in Software
Engineering (MiSE) (pp. 33-40). IEEE.
Torre, D., and et.al., 2018. A systematic identification of consistency rules for UML
diagrams. Journal of Systems and Software.