Skip to content

Milestone Report #1

buseg edited this page Apr 3, 2019 · 2 revisions

Executive Summary

Project Description

Our project is a traders platform for traders and enthusiasts of finance to easily keep track of everything related to finance. The easy to use interface, availability in Android and web, location-based news search makes this platform perfect for anyone, anywhere. The functionality of the platform differs for different client types. A guest user can view economic events, different aspects of trading equipment, articles and profiles of public users. This way they have a chance to improve themselves in trading by following other experienced users. Basic users can do everything a guest does and much more. They can keep track of their profit/loss by manually entering their investments, they can write articles, rate and comment articles, they can set alarms for economic events and price levels of trading equipment, they can create portfolios and they can make predictions about the price levels estimating whether the prices will drop or rise. Our privileged trader users can use the platform to buy and sell any trading equipment they want by integrating their private bank accounts to the platform. This makes it much easier to track their profits. What makes this platform unique is that it is also a social platform, where you can follow many inspiring users who will give tips on financial matters. You can comment and start discussions about finance and you can learn a lot from others.

Project Status

At the beginning when we were assigned as a group, most of us didn’t even know each other. But even from the first meeting, we felt comfortable around each other and this made a huge positive effect on our group work. We were a group of hardworking students and we all took almost equal workloads in the project, which we believe is rare in a group project where team members are chosen randomly. As a hardworking group, we accomplished each task given by the client. Starting with the search about Git & GitHub onto our last task of preparing the UML design, we have completed every task, never flexing the deadline for more than 1-2 days. Even if we received tons of feedback, we never gave up on our project and tried to make upgrades on our work as soon as possible. So at this point of our project, we can proudly say that we have fulfilled every task that was assigned and our project is going completely as planned without any drawback.

Moving Forward

We plan to continue with our project design and implementation, without losing our enthusiasm. We have worked hard and coherently thus far and we have seen the great results of this. We will continue to meet and evaluate our work together in our meetings and give feedback to each other to perfect our work. We believe the hard part was the design and implementation will be much easier since we are all accustomed to coding. We aim to implement the platform: backend, frontend, and Android parts. Some of us already have experience in some of these parts so we will learn from each other and the project will be very informative for us. In the end, we believe that a great product will surface and every team member will feel proud of their contribution to such a great project.

Deliverables

Deliverable: Status: Update Frequency Description
1- GitHub Wiki Complete Weekly Accessible github wiki pages, up-to-date information related to project can be found.
2- GitHub Readme Complete As improvement needed GitHub readme is updated, includes up-to-date information about the group.
3- GitHub Issues Complete As improvement needed Preparing the issue labelings and usage of the github system.
4- Meeting Notes In Progress Weekly Publishing meeting notes in GitHub Wiki.
5- Communication Plan Complete As improvement needed Publishing communication plan
6- Requirements Complete As improvement needed Sharing the requirements analysis related to the project.
7- User Stories and Persona Complete As improvement needed Posting the example user stories to be used in Mockups.
8- Mockups Complete Per feedback for now Posting Mockups to be shared with the Customer.
9- Design Diagrams Complete Per feedback for now Posting design diagrams to wiki page
10- Project Plan In progress - Preparing the project plan

1- GitHub Wiki: Generally we are in good shape. We try to keep each other and the instructors updated, using the GitHub wiki page to document all of the effort and work have done. Good activity in reading out the wiki, updating in terms of both design and content weekly. Also, we got feedback about not using temporary links of files/images, but to keep it in the related folder of the repository. Considered and took action right away. Overall, the group is good at maintaining the wiki page and utilizing it to keep everyone involved.

2- GitHub Readme: Got a good explanation of the work done in the readme, that explains what we are up to.

3- GitHub Issues: So far good with the label usages, works as planned. As a further improvement, we are planning to get better at reviewing. We are hoping to release a “Code of Review“ to make everyone on the same page, and have a structure and plan for reviews. We are also hoping that this will let everyone be more involved and up to date about the work that is done. Also, we got feedback regarding the use of dates and links to the completed work and started acting accordingly. Overall, we are not in a bad position but we have further things to improve for the remaining period and utilize the issues system better in CMPE451 where we get to the actual coding part.

4- Meeting Notes: As mentioned in the Wiki part, we are using the notes to keep each other up to date. Also, we sometimes go over the previous weeks’ meeting notes to check out the work done, and status of accomplishment. There are a few things to improve, such as including that week’s lecture and PS notes in the meeting notes part. We are hoping to start working on this in the coming weeks.

5- Communication Plan: We are using Slack in the parts where we are divided into sub-groups. For instance, when we were working with the class diagrams, we had a slack channel for that. Also, we use GitHub integrated into Slack to get a commit, issue updates, etc. in real-time. Currently, sharing docs over Drive, using WhatsApp as a communication channel and GitHub issues remain enough for our in-group communication. In the future, we are hoping to better utilize Slack and use more integrated tools, such as utilizing unit test tools, etc.

6- Requirements: Even after a few weeks than the deadline of requirements, we still keep updating the Requirements and its wiki page, both in terms of visuals and its content. As the ideas pop up in the meetings, and there are some points that need clarification, we go ahead and update the related requirement, or sometimes the whole page. Overall, we think we are in good shape in terms of the requirements page and good at updating it according to both instructors’ and team’s feedback. Also, we often go back to requirements and refer to them in different parts of the project, such as Mockups and Design Diagrams. Hence, it is really important for us to keep this part up to date and well-explained.

7&8- User Stories and Persona Page and Mockups: It took 3 weeks to finalize the mockups, persona & user stories and the related design parts. It was a trial and error process, but generally, all of the team members were involved with this part and everybody were involved in either creating, designing, writing or updating its’ content. We feel we did great teamwork when it comes to Mockups.

9- Design Diagrams: This part took straight 3 weeks of our time, but we feel it was worth it. Specifically preparing the use-cases and class diagrams made us understand even more about the structure of the system that we are going to build. During the design process, we obtained the idea of how to system is going to function, what operations we may need in the background, how the system is going to behave and what the user will see. It was actually an assignment but made us aware of what we are up to so far. Hence, the group feels like this part was really beneficial and crucial. During the meetings, while discussing a functionality, we often refer to class diagrams to make it more concrete and we are also utilizing it this way.

10- Project Plan: We have started to prepare project plans to put in use. We are not done with this yet and this is in progress, but we started to think in terms of the time it’s going to take, and the effort it’s going to cause a need for. Hence, although we haven’t delivered yet, we think we gained a lot and starting to use these measures during the meetings.

Evaluation of Tools and Processes Used

figma.com: We have used Figma to design our mockups. The reason we have chosen this platform was that one of our team members already had some experience in it. He gave us a hands-on tutorial, then each assignee was able to design their part quickly. After seeing other teams’ designs, we realized that this platform was a bit too complicated and detailed for designing mockups. Still, we think that the know-how we gained will be useful in UI/UX design which we are going to do next semester. On the other hand, the free version of the Figma platform only supports 2 users to edit a design at the same time, which is very limiting considering there are 11 members in our team.

UMLet, UMLetino: We prepared the first version of our use case diagrams with UMLet. Besides its simplicity, it had no support for online collaboration and looked old fashioned. Therefore, we gave it up and redesigned our use case diagrams with Lucidchart after the feedback.

lucidchart.com: We discovered Lucidchart when watching UML diagram tutorials on YouTube. We first used it to design our class diagram and then moved our use case diagrams also. Its free education package for students gives full access to all of its functionality. It lets multiple users edit diagrams at the same time and looks very professional.

sequencediagram.org: We used this website to design our sequence diagrams. It features a simple programming language to create sequence diagrams with no mouse clicks. We shared sequence diagrams between several assignees, and this feature provided consistency between the diagrams that are designed by different members.

Work Done by Each Member

Team Member Contribution / Work Done
Mert Yüksekgönül
  • Name discussion
  • Github Repo Research
  • Meeting notes
  • Customer meeting
  • Documentation of questions on wiki
  • Formatting new labels
  • User scenario 2
  • Sequence Diagram
  • Agenda preparation
  • Updating sequence diagrams
  • Milestone report - status and evaluation of deliverables part
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes
Rukiye Dilruba Köse
  • Name discussion
  • Github Repo Research
  • Readme Page
  • Opening issues
  • Homepage & Group photo
  • Sequence Diagram
  • Requirements Update
  • Updating sequence diagram
  • Milestone Report - Summary of Work Done, Copy-Paste Part for Deliverables
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes
Muhammet Furkan Gök
  • Name discussion
  • Github Repo Research
  • Wiki Homepage
  • Requirements page
  • User scenario design
  • Class Diagram
  • Class Diagram Update
  • Preparing meeting agenda
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes
Adil Numan Çelik
  • Name discussion
  • Github Repo Research
  • Personal Wiki page
  • Preparing communication plan
  • Requirements Page
  • User Scenario 2
  • Class Diagram
  • Updating mockups
  • Sequence Diagrams
  • Updating Sequence Diagrams
  • Meeting agenda
  • Issue Labels and Customization
  • Lecture and PS notes
Buse Giledereli
  • Name discussion
  • Github Repo Research
  • Personal Wiki page
  • Meeting agenda
  • Requirements Page
  • A wikipage for users
  • Requirements update
  • Updating user types page
  • Scenario 2
  • Use cases
  • Wiki update
  • Meeting notes
  • Updating Scenario2
  • Updating Mockup
  • Updating Acceptance Criteria
  • Issue Labels and Customization
  • Lecture and PS notes
Çağrı Atahan Canbeyler
  • Name discussion
  • Github Repo Research
  • Requirements page
  • Requirements Update
  • User Persona
  • Use Cases
  • Updating use cases
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes
Yunus Kardaş
  • Name discussion
  • Github Repo Research
  • Customer Meeting
  • Agenda for 3rd meeting
  • Scenario 1
  • Use Cases
  • Sequence Diagrams
  • Updating class diagrams
  • Updating sequence diagram
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes
Yunus Emre İnci
  • Name discussion
  • Github Repo Research
  • Customer Meeting
  • Requirements Page
  • Scenario 1
  • Class Diagram
  • Updating requirements page
  • Updating class diagrams
  • Milestone Report - Summary of Work Done, Copy-Paste Part for Deliverables
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes
Özgür Solak
  • Name discussion
  • Github Repo Research
  • Readme Update
  • Scenario 3
  • Sequence Diagram
  • Updating sequence diagram
  • Meeting notes
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes
Murat Can Bayraktar
  • Name discussion
  • Github Repo Research
  • Communication Plan
  • Scenario 1
  • Use cases
  • Updating mockups
  • Updating Scenario1, User Scenario, Acceptance Criteria, Mockup
  • Updating use cases
  • Preparing Meeting agenda
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes
Fatih İver
  • Name discussion
  • Github Repo Research
  • Communication Plan
  • Customer meeting
  • Requirements update
  • Scenario 3
  • Class diagram
  • Updating mockups
  • Updating Scenario3, User Scenario, Acceptance Criteria, Mockup
  • Updating class diagrams
  • Milestone Report - Merging Report, Design Part
  • Personal Wiki page
  • Issue Labels and Customization
  • Lecture and PS notes

Communication Plan


Who Where When Purpose
1- All Members CMPE Lounge Every Wednesday 18.00-19.00 • Discuss general issues
• Check weekly progress
2- All Members GitHub Anytime • Creating and operating issues
• Discussion about issues during week
3- All Members Whatsapp Group Anytime Discuss immediate issues
4- All Members Slack Anytime • General discussions about project
• Functional GitHub tools
5- All Members Phone Call When necessary Discussing immediate situations
6- Communicator Piazza When necessary • Getting customer's demand
• Explaining group's actions

Group Members

  • Murat Can Bayraktar(Communicator)
  • Mert Yüksekgönül
  • Adil Numan Çelik
  • Buse Giledereli
  • Yunus Emre İnci
  • Çağrı Atahan Canbeyler
  • Fatih İver
  • Muhammet Furkan Gök
  • Rukiye Dilruba Köse
  • Özgür Solak
  • Yunus Kardaş

Customers

  • Suzan Üsküdarlı
  • Meriç Turan

Requirements

Glossary

Note: Aliases for terms are given in parentheses.

  • Annotation: A note or comment typically used to convey information about a resource or associations between resources. For example a comment or a tag on a single web page or image.
  • Article: A piece of writing of users about trading and investment. Articles have a title and meant to be somewhat longer although the system does not put any restrictions on length.
  • Asset: Assets describe investments of trading users which are physically held in the platform.
  • Basic User: A basic is a user who can use all the functionality of the system other than making real investments.
  • Comment: Comments can be written below articles or trading equipments by users to share their ideas.
  • Economic Event (Event): Economic events are important incidents that may effect the economy, such as publication of an economical statistic or figure, a speech of an economic leader, a government's bond auction etc. An event's importance level designated with an integer from 1 to 3.
  • Guest: A user who is using the platform but has not signed up yet.
  • Investment: Two types of investments exists in the platform. One is the type of investments that are manually entered by users, and other is the assets that are physically held in the platform.
  • Parity: A pair of trading equipments. Parities describe a valid conversion from one equipment type to another.
  • Password: A string of characters that allows access to the system. Passwords are at least 8 characters long, can include letters, digits and special characters.
  • Portfolio: A collection of parities the user selects to follow them together.
  • Sign up: Registering to the system by providing the necessary information.
  • Trading equipment (Equipment): Any valuable in which users can invest, such as: indices, stocks, ETFs, commodities, currencies, funds, bonds and cryptocurrencies. A trading equipment does not have a price by itself, price of equipments are only existent within a parity.
  • Trading User (Trader): In addition to basic users, trading users are able to buy and sell trading equipment on the platform.

1. Functional Requirements

1.1. User Requirements

Before getting into user requirements it is necessary to define different user types of the system. The system has 4 types of users: Guest, Basic User, Trading User (Trader) and Admin. The roles of these user types are briefly explained in the glossary and will be defined explicitly throughout the following requirements.

In this section, the word "user" will refer to any user of types Basic User, Trader or Admin. The words "guest", "trader" or "admin" will be used when a requirement is specific to only one type of user.

The reader is highly encouraged to read the glossary before reading the requirements as the meanings of terms used in this document might differ from the common knowledge. The reader may also visit User Types to see a summary of "who can do what".

1.1.1. Sign Up

  • 1.1.1.1. Guests shall be able to sign up by providing their e-mail address, name, surname, location and choosing a password. If the guests wants to register as a trading user, they shall also provide IBAN of their bank account. Location information shall be given using Google Maps.

  • 1.1.1.2. Guests should be able to sign up with their Google account.

1.1.2. Sign In

  • 1.1.2.1. Users shall be able to sign in with their e-mail and password.
  • 1.1.2.2. Users should be able to sign in with their Google account.

1.1.3. Profile

  • 1.1.3.1. Each user shall have a profile page.
  • 1.1.3.2. Users' prediction success rate for each parity shall be visible on their profile page. There should be a lower limit to the number of predictions for the success rate to be visible on the profile page.
  • 1.1.3.3. Users' public portfolios shall be shown on their profile page.
  • 1.1.3.4. Users shall be able to set their profile to be public or private.
  • 1.1.3.5. Public profiles shall be visible to all users and guests.
  • 1.1.3.6. If a user profile is private, then the content produced by that user shall only be visible to its followers.
  • 1.1.3.7. Prediction success rate shall be visible to all users and guests even if a user's profile is private.

1.1.4. Social Interactions and Communication

  • 1.1.4.1. Users shall be able to follow each other. To follow a user who set his profile to be private, a follow request shall be sent first.
  • 1.1.4.2. Users shall be able to deny the following requests came from other users.
  • 1.1.4.3. Users shall be able to share their ideas as an article.
  • 1.1.4.4. Users shall be able to write comments below the articles of other users.
  • 1.1.4.5. Users shall be able to rate articles of other users by clicking the "like" button.
  • 1.1.4.6. Users shall be able to write comments about trading equipment.

1.1.5. Economic Events

  • 1.1.5.1. Users and guests shall have an “Events” section. In this section, users and guests shall be able to view economic events as a table with columns: 'time', 'importance level', 'country base', 'actual', 'previous' and 'forecast'. See example.
  • 1.1.5.2. Users and guests should be able to filter economic events by their importance level and country base.
  • 1.1.5.3. Users and guests should be able to search for economic events.
  • 1.1.5.4. Users shall be able to follow economic events. A user who is following an event should be notified after the event happened.

1.1.6. Portfolios

  • 1.1.6.1. Users shall have one or more portfolios. Empty portfolios may exist.
  • 1.1.6.2. Users shall be able to rename their portfolios.
  • 1.1.6.3. Users shall be able to add or remove parities from their portfolios.
  • 1.1.6.4. Users shall be able to follow each other's portfolios. Followed portfolios shall be shown in user's portfolios section.

1.1.7. Trading Equipment and Parities

  • 1.1.7.1. Users and guests shall be able to view conversion ratio, previous close, percentage and amount change according to the previous close, day's range and moving averages for a parity.
  • 1.1.7.2. Users and guests shall be able to read user comments about trading equipment.
  • 1.1.7.3. Users shall be able to make predictions about the parities for the day. A prediction shall be either "will increase" or "will decrease". The result of the prediction is determined by comparing the last close and today's close of the ratio.
  • 1.1.7.4. Users shall be able to set alerts for certain ratios of parities. Users shall be notified when the target ratio is met.

1.1.8. Investments

  • 1.1.8.1. Users shall have a "My Investments" section which contains information about their assets that are physically held in the platform and also manual investments which they made outside of the platform.
  • 1.1.8.2. Users shall be able to enter manual investments.
  • 1.1.8.3. Traders shall have to verify their e-mail address before making an investment.
  • 1.1.8.4. Traders shall be able to buy trading equipment by selling another equipment from their assets if a conversion exists between those equipments. For example, a trader could sell Turkish liras (TRY) to buy United States dollars (USD) whereas he couldn't directly convert his golds to Apple stocks because such a conversion does not exist.
  • 1.1.8.5. Traders shall also have an option of paying with a credit card instead of selling their assets when making an investment.
  • 1.1.8.6. Traders shall be able to give buy orders for a desired ratio. When the current price goes below the desired ratio, the system shall make the buy automatically.
  • 1.1.8.7. Traders shall be able to give stop/loss orders by specifying a maximum loss. The system shall automatically reverse the investment when the amount of lost goes above the maximum loss.

1.1.9. Profit/Loss

  • 1.1.9.1. Users shall have a profit/loss section. They shall be able to see their profit/loss amount in the currency of their choice. Users' manual investments and assets shall be both accounted when calculating their profit/loss.
  • 1.1.9.2. Users and guests shall not be able to see the profit/loss of other users.

1.1.10. Search

  • 1.1.10.1. Users and guests shall be able to search for trading equipment, parities and other users. The search algorithm shall consider all information available in user profiles (such as portfolios) and shall retrieve semantically similar results to the query.
  • 1.1.10.2. Users and guests shall be able to filter users around a location when searching.

1.1.11. Recommendations

  • 1.1.11.1. Users shall receive article and trading equipment recommendations based on their investments, users and events they follow.

1.1.12. Admin Panel

  • 1.1.12.1. Admins shall have an admin panel to administrate the platform.
  • 1.1.12.2. Admins shall be able to add new trading equipment and parities.
  • 1.1.12.3. Admins shall be able to ban or delete users. Banned users shall not be able to sign in.
  • 1.1.12.4. Admins shall be able to delete articles and comments.
  • 1.1.12.5. Admins shall be able to add or delete events.

1.2. System Requirements

1.2.1. Interactions

  • 1.2.1.1. The system shall support sharing ideas as an article.
  • 1.2.1.2. The system shall support commenting and rating ideas of other users.
  • 1.2.1.3. The system shall support commenting about trading equipment.
  • 1.2.1.4. The system shall let users follow other users and trading equipment.
  • 1.2.1.5. The system shall provide an alert mechanism which lets traders to get notified about certain levels of trading equipment.
  • 1.2.1.6. The system shall provide an alert mechanism which lets users to get notified about other users activities, when they follow another user.

1.2.2. Recommendation

  • 1.2.2.1. The system shall provide a recommendation mechanism recommending articles, portfolio or trading equipment to the users based on their histories.
  • 1.2.2.2. The system shall let users to make predictions about trading equipment.

1.2.3. Searching

  • 1.2.3.1. The system shall contain a searching mechanism that lets users to search users, trading equipment and economic events.
  • 1.2.3.2. The searching mechanism shall consider all the information available in user profiles and trading equipment.
  • 1.2.3.3. The system shall allow the semantic search which enables users to make a search by using user defined tags in order to make more specific search.
  • 1.2.3.4. The system shall support location-based search.

1.2.4. Trading Equipments and Parities

The system shall support following equipments and possible conversions between them:

  • 1.2.4.1. Trade indices such as S&P 500, Dow 30, DAX...
  • 1.2.4.2. Stocks such as Apple, Alibaba, IBM...
  • 1.2.4.3. ETFs such as SPDR S&P 500, SPDR DJIA, iShares Russel 2000...
  • 1.2.4.4. Commodities such as Gold, Natural Gas, Silver...
  • 1.2.4.5. The application should support chief monetary units in the world. Currencies such as Euro, American Dollar, Turkish Lira...
  • 1.2.4.6. Funds such as Pimko Total Return, Vanguard Total Stock Market Index Fund, American Funds Growth Fund of America...
  • 1.2.4.7. Bonds such as Euro Bund, UK Gild, Japan Government Bond...
  • 1.2.4.8. Cryptocurrencies such as Bitcoin, Ethereum, XRP...

2. Non-Functional Requirements

2.1. Security

  • 2.1.1. The website and the mobile application shall use secure HTTP (HTTPS) for all transfers.
  • 2.1.2. The website shall be secure against SQL injection, cross-site scripting, and cross-site request forgery attacks.
  • 2.1.3. User passwords shall be stored in the database using a secure hashing algorithm.
  • 2.1.4. The system should backup periodically.

2.2. Performance

  • 2.2.1. The system shall be able to handle 1000 HTTP requests per second.
  • 2.2.2. The system shall be capable of serving 1000 users at the same time.
  • 2.2.3. The system shall respond to search queries in less than 3 seconds.

2.3. Availability and Accessibility

  • 2.3.1. The website and the mobile application shall be available in English.
  • 2.3.2. The project should work on any web browser.
  • 2.3.3. The application shall work on Android 4.4 and later.
  • 2.3.4. The project shall be provided for both mobile and web platforms.
  • 2.3.5. The system should work 7/24 with no more than 1% downtime.
  • 2.3.6. The project should contain auxiliary features for disabled people.
  • 2.3.7. The system shall use UTF-8 character encoding for all texts.

2.4. Annotations

Mockups

Scenario 1: Searching in articles and Looking for a parity


  • User: Emre Tur
  • Platform: Web
  • User Type: Guest

1- Our guest user Emre is on another watch in the hospital. He got so much leisure time during the night. He is interested in economic news. While he is surfing on the internet, he encounters our platform and visits it. He looks economic events.


2- Emre clicks on the ARTICLES button then. Realizes the website is full of economy experts' articles. But he is not interested any article on the first-page.


3- Emre realizes the SEARCH bar. Decides to use it to filter articles. He is using "Trump" as a keyword. After entering the word, there are related articles based on his keyword.


4- But there is a problem. Emre's English skills are inadequate to read an article:( He is also curious about the current USD/TRY parity for a year to invest in. Then he clicks the USD/TRY on the portfolio bar, goes to the USD/TRY page.


5- He looks to the daily details of the parity. He sees other (signed in) users are making 'clever' comments about the parity. He realizes he has to sign in to make comments about the parity. He also finds a daily expectation tool and clicks to the increase button as he guessed.


6- After clicking the increase button, he gets an alert that invites him to sign in. Emre gets a feeling that this platform serves so many tools and information about the economy and trading equipment. He decided to sign in but he couldn't do it because his advisor doctor suddenly came into the room and said: "I'VE BEEN LOOKING FOR YOU FOR AN HOUR!!".


Scenario 2: Looking at profiles of other users


  • User: Özge Bozkurt
  • Platform: Web
  • User Type: Basic User

1- Özge opens the homepage of TrAiders as usual after her favorite TV show ends. She clicks the Sign In button since she wants to stalk the great users she is following and sees if they posted any articles.

2- Sign In Screen shows up, Özge signs in with Google because she doesn't want to enter her email and password manually. She thinks this site is great because it provides such an easy sign-in option.

3- Özge's email is filled automatically by her browser, she simply clicks the next button and she gets logged in.

4- Özge is redirected to the homepage, where she lands on the event stream. She casually looks at the events that took place today. She sees nothing extraordinary happened, so she clicks the articles to see if any of the great users she follows posted anything interesting.

5- She clicks on the article about Trump. She invested in oil so she got concerned of the latest news.

6- She reads the article and thinks her investments are at risk.

7- She gets furious at Trump and she wants to share her anger by commenting. She then clicks the post button.

8- She sees the comment of Marshall Hiepler, it seems like a clever comment. She thinks she should check his page to see if he is worthy of stalking.

9- She looks at Marshall's prediction success rate in USD/TL and becomes amazed. His articles look really clever. She sees that he shared his portfolio recently, so she clicks on the portfolio.

10- She likes the portfolio of Marshall, she thinks oil is not safe to invest in anymore and since she loves social media platforms this Tech Stocks portfolio is perfect for her. She believes Facebook will rule the world one day. She decides to follow the portfolio, she clicks the follow button.

11- She closes the portfolio.

12- She follows Marshall, from now on she will stalk him regularly on her homepage.

Scenario 3: Making an investment & Setting an alarm


  • User: Muazzes Çolak
  • Platform: Mobile
  • User Type: Trader

1- Muazzes launches the application.


2- Muazzez wants to invest her turkish liras to dollars and clik usd/try to see the fluctuations in detail.



3-She believes there will be increase in USD/TRY parity so she decides to vote up.



4-She confirms her prediction since predictions cannot be changed after a certain hour.



5-After analyzing the fluctuations, she decides to buy US dollar and click buy button .



6-She puts a limit order to buy some amount of dollars.



7-After she gets notified, she goes to the investment tab to see her new investment.

Use Case Diagrams

Class Diagram

Sequence Diagrams

Sign In

Follow a User

Sharing an Article

Post Comment to Article

Make Manual Investment

Creating a Portfolio

Buy Order

Sign Up

Track Event

Predict Equipment

Clone this wiki locally