Analysis of Slack

CSE 3231 Spring 2021

Team 4: Ali Brugh, Max Herz, Ryan Shaffer 2

Table of Contents

1. Business Analysis 5 1.1. Research of Enterprise 5 1.1.1. Industry Segment 5 1.1.2. Products and Services 5 1.1.3. Market 6 1.1.4. Business and Organizational Structure 7 1.1.5. Value Chain 7 1.1.5.1. Inbound Logistics 7 1.1.5.2. Operations 8 1.1.5.3. Outbound Logistics 8 1.1.5.4. Sales 8 1.1.5.5. Marketing 9 1.1.5.6. Service 9 1.1.6. Stated Areas of Differentiation 9 1.2. Analysis of Enterprise 10 1.2.1. Five Forces Analysis 10 1.2.2. Differentiation vs. Competitive Position 12 1.3. Software Application Portfolio 12 1.3.1. Possible Applications 12 1.3.2. Application to Develop Further 14 2. Intended Software Engineering Process 15 2.1. Spider Diagram 15 2.2. Project Management 16 2.2.1. Release Plan 16 2.2.2. First Iteration Plan 16 2.2.3. Risk Plan 16 2.2.4. Linear and Parametric Estimation 16 2.2.5. Project Schedule 17 2.3. Requirements 17 2.3.1. Problem Statement 17 2.3.2. Storyboards 17 2.3.3. Business Case 17 2.3.4. Use Cases 17 2.3.5. Non-Functional Requirements 17 2.3.6. Acceptance Plan 18 3

2.3.7. System Tests 18 2.4. Analysis 18 2.4.1. Domain Analysis 18 2.4.2. Problem Analysis 18 2.4.3. Solution Analysis 18 2.4.4. Sequence Diagrams 19 2.5. Architecture 19 2.5.1. Subsystem Model 19 2.5.2. Target Environment 19 3. Requirements Analysis 20 3.1. Domain Analysis 20 3.2. Problem Statement 20 3.3. Problem Analysis 21 3.4. Solution Analysis 23 3.4.1. Sequence Diagram for New Availability System 23 3.4.2. Sequence Diagram for New Messaging System 24 3.4.3. Class Diagram for Priority Messaging and Availability System 25 3.4.4. Static Structure 26 3.4.5. Dynamic Behavior 27 3.5. Storyboards 27 3.5.1. Scenario 1 27 3.5.2. Scenario 2 28 3.6. Business Case 28 3.6.1. Cost 28 3.6.2. Benefit 29 3.7. Functional Requirements 30 3.8. Use Cases, User Stories, and Scenarios 30 3.8.1. Use Case (UC1): A user sends a high priority message 30 3.8.1.1. Relevant User Stories 31 3.8.2. Use Case (UC2): A user sends a message with a follow-up notification 32 3.8.2.1. Relevant User Stories 33 3.8.3. Use Case (UC3): A user changes their availability 33 3.8.3.1. Relevant User Stories 34 3.8.4. Use Case Diagram 35 3.9. Non-Functional Requirements 35 3.10. Acceptance Plan 36 3.11. System Tests 37 4

4. Architecture 38 4.1. Overview 38 4.2. Subsystem Model 38 4.2.1. Priority Messaging System 39 4.2.1.1. Priority Message Selection 39 4.2.1.2. Outbound Priority Messaging 40 4.2.1.3. Inbound Priority Messaging 42 4.2.1.4. Sequence Diagram for the Entire Priority Messaging System 43 4.2.2. Follow-Up Notification Messaging System 44 4.2.2.1. Timer Selection 44 4.2.2.2. Outbound Notification Messaging 46 4.2.2.3. Inbound Notification Messaging 47 4.2.2.4. Sequence Diagram for the Entire Notification Messaging System 49 4.2.3. Availability System 49 4.2.3.1. Availability Selection 50 4.2.3.2. Automatic Availability Update 51 4.3. Target Environment 53 4.3.1. Deployment Diagram 53 4.3.2. Explanation of Deployment Diagram 53 5. Project Planning 57 5.1. Release Plan 57 5.2. First Release 58 5.3. Project Estimation 60 5.3.1. Linear Estimation 60 5.3.2. Use Case Point Estimates 61 5.3.3. Comparison of Estimates 66 5.4. Project Schedule 66 5.5. Risk Management Plan 67 6. Resources 68 5

1. Business Analysis 1.1. Research of Enterprise 1.1.1. Industry Segment ● Slack is at the forefront of the collaboration and communication in the digital environment. Slack provides a robust platform for text, audio, and video communication with abundant support for 3rd party applications through the use of their API. ● The platform is available on all devices where business is done. This includes Windows, Mac, Linux, iOS, and Android. ● The main goal of Slack is to connect coworkers and enable efficient organizational operation. With the COVID-19 pandemic and drastic shift to online communication, the market has grown considerably in recent months. They currently have over 12 million daily active users, over 199,000 paid customers, and are used by 65 out of 100 of the Fortune 100 companies. ● While Slack has been a consistently high performer in the communication tools market, it has seen its market share drop with the meteoric rise of Microsoft Teams. Other direct and indirect competitors in the space include Cisco Jabber, Skype, Workplace by Facebook, and Chatter by Salesforce. ● It should be noted that although Slack and Discord share very similar UI, they are unrelated and not direct competitors. Discord is focused on the consumer gaming industry, whereas Slack is concerned with enterprise communication. ● Some notable businesses that use Slack include: Target, Starbucks, Oracle, TD Ameritrade, Panasonic, BBS, E-Trade, and the New York Times.

1.1.2. Products and Services ● Slack’s products and services are integrated into its singular platform. Self-described as “a digital office, a persistent place for users to connect and find information” (Slack, 2021). ○ Basic Features ■ Workspace: ecosystem and platform ■ Channel: shareable and customizable text thread. The basis of the application ■ Direct messaging: send private direct or group messages ■ Voice messaging ■ Video conferencing ■ File sharing ■ API and integration: connect workspaces to 3rd party applications (Google Drive, Office 365, etc.) 6

■ Workflow builder: automated integration with 3rd party applications ■ Smaller features such as: filterable search, conversation history, mentions, pins, etc. ■ Security features: identity and device management, data protection, information governance ○ Enterprise-Specific Features ■ Slack Connect: integrate workspaces between different organizations ■ Improved availability: 99.99% uptime ■ Unlimited workspaces ■ Enterprise level user and data administration ■ Regulatory data compliance ■ Custom automated workflows ○ Pricing: Each tier includes the features of the previous tier(s). ■ Free: $0 per person, per month. Includes up to 10,000 searchable messages, 5GB storage for files, up to ten 3rd party apps and services, and 1:1 video and voice calls. ■ Standard: $6.67 per person, per month (billed yearly). Includes unlimited message archive, unlimited apps, group video calls with screen sharing up to 15 people, Slack Connect, and 10GB file storage per member. ■ Plus: $12.50 per person, per month (billed yearly). Includes guaranteed 99.99% uptime, user provisioning/deprovisioning, SAML based SSO, data exports for all messages, and up to 20GB file storage per member. ■ Enterprise Grid: Variable price per person per month (contact sales team). Includes unlimited workspaces, supports data loss prevention providers, designated customer success teams, and HIPAA compliant messaging and file collaboration.

1.1.3. Market ● Any organization seeking a communication and collaboration tool. ● Fortune 500 Companies: Interested in large-scale custom products and services. The Enterprise Grid plan is popular with very large businesses or those seeking extended features sets in regulated industries. ● Enterprise: Interested in expanded feature sets and improved app integration. The Plus plan is popular with large businesses. ● Small Business: Interested in basic functionality. Free and Standard plans are popular with small and medium-sized businesses. 7

● Other: Free version intended to show potential customers the utility and value of the platform. Limited feature set, but no cost to user.

1.1.4. Business and Organizational Structure ● Business Structure ○ Our industry is a messaging platform. Our business competes with other workplace messaging services like Microsoft Teams, Skype for Business, and Workplace by Facebook. ○ Slack is a channel-based communication platform that is targeted towards companies, although anyone can use it. It is at the forefront of its industry, offering text, video, and audio communication and integration with 3rd party applications. ○ Slack offers four plans: Free, Standard, Plus, and Enterprise Grid. The company makes money from the latter three, which have extra features to entice the user to convert to a paid plan (for example, more file storage, ability to share channels externally, etc.). The pricing for Standard and Plus varies based on whether the user is paying by month or by year, and the pricing for Enterprise Grid depends on how many people are going to be using that plan. ○ Overall, Slack has over 12 million daily active users, and over 119,000 paying users. ● Organization Structure ○ Slack is an American organization that is headquartered in San Francisco, California. It has 16 other offices, located worldwide: the offices are in the USA, Canada, Ireland, England, France, Germany, Australia, Japan, and India. Each office provides technological and service support for Slack’s products. ○ Slack is estimated to have about 2,000 employees total. ○ Slack does development in-house with these employees, but they have also outsourced work: they outsourced logo design, marketing website design, and some software work for the web and mobile applications.

1.1.5. Value Chain 1.1.5.1. Inbound Logistics ● To create a Slack workspace, all Slack needs to receive is the email address of the person creating it, the name of the workspace, and the reason for creating the workspace. ● To add new people to the workspace, Slack receives email addresses which allows the owner of that address to join it. Once they join, they 8

become a user of that workspace, gaining access to all of its channels and apps. ● Slack also collects data from its users. It receives metadata and log data about how users interact with it, device information, and location information. If the owner of the workspace is paying for a plan, Slack also receives billing/banking information from that person.

1.1.5.2. Operations ● Slack takes in the email address of the owner of the workspace and immediately creates a default workspace UI for the user. This includes at least a #general and a #random channel. Functionality to add channels, add people, send messages, integrate apps, and search the workspace is then added to the UI. ● Slack focuses on user customization: users can change the color theme of their UI and add the channels/people/apps that they want. All channels are also deletable, except for the #general channel that comes with all new workspaces.

1.1.5.3. Outbound Logistics ● To use Slack, users can log into a workspace through the Slack app on their computer or mobile device, or they can launch Slack through a web browser. Users can create their own workspace or be invited to one via email. Then, inside the Slack UI, they can create channels, connect with apps, and start communicating and collaborating with their teammates.

1.1.5.4. Sales ● Anybody can contact the Slack sales team just by going to Slack’s website. You can submit a message that lets them know who you are, what your company is, and what you are hoping to get from their team. This could be pricing information, more information about Slack, how best to use Slack, etc.. ● Users can create a Slack workspace for free. They can choose to try out a free trial of the paid Standard or Plus plan, both of which offer more features than the free plan. If the users like the paid plans, this encourages them to upgrade. ○ When the trial is close to running out, Slack prompts the user to upgrade to the paid plan so that they don’t lose all of the new features. ● Users can choose to be billed monthly or yearly on the Standard/Plus plans. For the Standard plan, when billed yearly, they are charged $6.67 per person per month, and when billed monthly, they are charged $8 per 9

person per month. For the Plus plan, users are charged $12.50 per person per month when billed yearly, and $15 per person per month when billed monthly. This price scheme encourages users to pay by year, but they have flexibility in choosing which scheme works best for them. ● Users may also choose the Enterprise Grid plan. The price for this depends on how many people are using the workspace. To get a price estimate, companies must contact Slack’s sales team.

1.1.5.5. Marketing ● Online advertisements to promote Slack. ● Satisfied users recommend Slack to their friends or colleagues. ● Slack users can try out a free trial of the Standard or Plus plan. If the users like the paid plans, this encourages them to upgrade. ○ When the trial is close to running out, Slack prompts the user to upgrade to the paid plan so that they don’t lose all of the new features. ● Discounts for certain types of organizations, such as educational institutions or nonprofit companies, which encourages those people to use a paid version of Slack.

1.1.5.6. Service ● Slack provides a quick start guide to help people understand what Slack is and how to use it. ● Slack has a Help Center on their website where you can search for common topics/questions. ○ You can also contact Slack directly by submitting a message detailing your question(s) or feedback through the help center. You can even submit a bug report here. ● Slack offers a Resources Library that further helps you understand how to use the platform and what you can get out of it.

1.1.6. Stated Areas of Differentiation ● Productivity ○ Users can create public and private channels dedicated to separate topics, making for an organized workspace and allowing users to focus solely on what is related to their work. ○ Slack workspaces can connect with over 2,000 apps and tools (such as Zoom, GitHub, Google Drive, Jira Cloud, and more), allowing teams to integrate all of their work in one place so that everybody is kept up-to-date with their projects. 10

○ Based on a 2020 survey of weekly Slack users, teams that use Slack are 31% more productive and work 23% faster (Slack). ○ In the face of COVID-19 and the transition to working from home, this 2020 survey indicates that 91% feel their ability to work remotely has improved because of Slack (Slack). ● Simple Communication ○ Users can communicate using dedicated channels and direct messages rather than unorganized email chains. ○ Users can communicate with their team in real-time without the hassle or formality of an email chain. ○ Based on a 2020 survey of weekly Slack users, 82% say Slack has improved communication and 84% feel more connected to their teams (Slack). ● Scalability ○ Slack prides itself on being a useful tool for any company size. ■ Utilized by university group projects all the way up to 65 of the Fortune 100 companies. ○ Users can connect to Slack from anywhere -- their work computer, their home computer, and/or their mobile device. ○ Archive of 10,000 most recent messages on the Free plan, and an unlimited message archive for all paid plans. ○ 99.99% guaranteed uptime SLA for the Plus and Enterprise Grid plans. ○ Unlimited number of workspaces for the Enterprise Grid plan.

1.2. Analysis of Enterprise 1.2.1. Five Forces Analysis Bargaining Power of Customers ● Customers have fairly low bargaining power with Slack. ○ Slack is a very large company, with over 12 million users and almost 2,000 employees. Individuals do not have much power due to its sheer size ● Users have the choice between using only the free services, or paying for premium services. ○ Vast majority do not pay, meaning they have no power to negotiate or drive down price ● Although there are many substitutes, Slack is commercialized and has foundation in many companies. ○ 65 of the Fortune 100 companies use it 11

Threat of Substitute Products/Services ● As mentioned above, there are a plethora of substitutes, but Slack’s stated areas of differentiation keep it at a competitive advantage. ○ Microsoft Teams, Google Chat, Chanty, Flock, etc. are notable alternatives ○ Discord is a very popular messaging/social platform, extremely similar to Slack, but focuses in the gaming industry ● Most commercial use substitutes pale in comparison due to Slack’s integration. ○ Microsoft Teams, likely the most popular substitute, is mostly used due to integration with other Microsoft tools/services, or privacy concerns ● It’s not difficult to create a substitute product, but it’s very difficult to market to companies/corporations and gain users, which is vital for growth. ● Collaboration software, such as Slack, is fairly vague, since email, Google Drive, social media, etc., could all be considered to be in the category. ○ If one considers these types of products/services to be in the same category, the threat of substitutes will be higher

Bargaining Power of Suppliers ● Not many suppliers in the industry of team-based communication software. ● These products are generally created from an idea, and all the work that needs to be done is development. Once this is done, the product is “finished.” ● For Slack, it’s possible to argue that the integrated services are suppliers, as some users likely chose it for those services. ○ GitHub, Google Drive, Zoom, etc. ○ These other services could possibly have some power or leverage over Slack and the company’s decisions

Threat of New Entrants ● As already mentioned, there are plenty of options in this collaborative and social team messaging space. It is not hard to enter this industry, and due to the recent surge of people working from home, competition is as high as ever. ● The real difficulty comes from growing the user base. A new product/service would either need to cater to a specific group, or have wildly better features than Slack. 12

● As a result, the threat of new entrants is technically high, but the threat of major competition and loss of users is quite low. As Slack and its existing competitors continue to grow at a lightning fast pace, the more unlikely it is for a new entrant to make a meaningful impact in the industry.

Competitive Rivalry ● The above forces have come together to ensure that the market is relatively competitive, even more so in the last year. As discussed, there is already high competition, and as the industry is relatively new, it will continue to have high growth prospects. Profits are likely to continue to increase as the existing companies grow and new ones come into play.

1.2.2. Differentiation vs. Competitive Position As one of the first collaborative, company-based social messaging platforms, Slack established a significant foothold in the market and continues to have competitive advantages over other similar products/services. Its areas of differentiation include simplicity, ease-of-use, scalability, and productivity. The Slack UI is simple, yet effective. Not only is it easy to create channels, it’s easy for employees to join and immediately start talking to others. Channels can also support hundreds, if not thousands, of members with ease. From a start-up with 10 employees to corporations the size of Apple, the tools Slack gives to users are just as effective. Finally, the continuously-added support for 3rd parties such as calendars, GitHub, and cloud-storage keep Slack relevant and increase the edge it has over competitors. These individual areas give competitive advantages of their own, but also come together to create a dominant force in the vast majority of industries. In conclusion, it is clear that Slack’s areas of strategic differentiation are justified by its competitive position.

1.3. Software Application Portfolio In support of furthering Slack’s mission and profitability, we are suggesting the consideration of several new software products and services to add to the current platform. These new software applications and features aim to improve the user experience and further the competitive position of Slack in the communication tools industry.

1.3.1. Possible Applications Outbound Logistics ● Availability Options ○ Currently with the Slack UI, a user can set themselves as “active” or “away.” This availability could be expanded to have more options, such as “offline,” “busy,” and “be right back.” 13

■ Offline would indicate that you are not online at all, and busy would indicate that you are online but are occupied and focusing on something. These are different from away, which indicates that you are online but not currently active. Slack does have a Do Not Disturb mode, but busy would differ from that because the user would still receive notifications when their availability is set to “busy.” ■ Be right back indicates that you are only temporarily away from your computer, and that you will be active again shortly. ○ All of these additional options give the user’s team more information about their current whereabouts and preferences. If someone’s status is “away,” it is hard to tell whether they are even online and whether or not they want to be messaged -- it is much clearer with “offline,” “busy,” and “be right back.” This will allow the team to communicate more effectively overall, since they will have a better idea of when (and when not) to message teammates. ● Voice Channels ○ Currently, Slack has channels where you can send messages or start a voice or video call. This could be expanded so that Slack has both text channels (where you can still start a voice or video call) and voice channels. The voice channel would be a permanent open voice channel where people could come and go easily (like possible competitor Discord has). This is helpful for quick questions and does not require the formality of scheduling a call. ● Sub-Channels ○ Currently, there is no way to further divide a workspace into smaller sections. The best practice is to name channels in the best way possible to reflect what its purpose is. This isn’t much of a problem for small, and even some mid-size companies, but large corporations require structure and organization. They could choose to have workspaces for individuals sectors of the company (e.g. sales, marketing, IT, accounting), but that means there is no company-wide communication, as well as worse security. Sub-channels would allow these huge companies (likely 1000+ employees) to further narrow down the sectors. For example, there may be a Technology channel with subdivisions for Hardware, Software, IT, Testing, etc. This addition wouldn’t hurt smaller companies, as they are free to make use of it as well. 14

● Local File Storage/Improved Cloud ○ Files are saved within workspaces based on the members’ plans. The more they pay, the more files will stay visible, up to a limit, before they are archived. Both visible and archived files are stored in Slack’s cloud, meaning there are privacy and security concerns. As Slack expands, its official business opportunities expand. Ensuring high security and protection of files is vital, which a local storage could help with. Furthermore, there’s nothing stopping other people from sending files in the workspace that could push your own important file out of the limit, archiving it. ● Priority Messaging ○ This tool would allow messages to be sent with varying priority levels. Default messaging would remain unchanged, but additional options for special circumstances would be added. This includes “Response Required”, “High Priority”, and “Urgent” designations. Users would also gain the ability to automatically notify the recipient if they have not responded. If a reply and resolution was left unmarked after a user specified period of time, the recipient would receive a push notification reminding them of the unresolved priority message.

Inbound Logistics ● User and Administrator Polls ○ Offer random users within a particular workspace a survey on their usage on the platform. Cross-reference their responses to collected analytics on application usage. Offer workspace administrators a similar survey on their opinions and usage of the platform. As a reward, customers would receive upgraded features for a limited time. This data could be used to improve the user experience and find new features to implement.

1.3.2. Application to Develop Further We believe that the features set comprising the priority messaging and availability options brings about the most business value for the company. By adding priority messaging and expanded availability options to the core platform, users will gain more control of their messaging and organizations can improve their productivity. This development project fits in perfectly with the areas of differentiation previously mentioned, specifically productivity and communication. Increased control, accountability, and responsiveness will allow for users to get more work done with a higher degree of confidence and allow organizations to enable more seamless 15

communication company-wide. By improving upon the chain-link of outbound logistics, these new features can change the way the product is delivered to customers. It will enhance customers' experience implementing and interacting with the platform, therefore reducing the threat of substitute products.

2. Intended Software Engineering Process 2.1. Spider Diagram

Size: The implementation should not need more than a small to medium-sized team. It is a relatively simple feature that other platforms have implemented before, and is localized within the system (only user profiles are affected).

Personnel: Slack developers likely have a wide range of experience, with both people that have been in the industry for decades, and new hires/interns. Overall, the team will likely be fairly experienced.

Criticality: The feature is low-risk, and is not critical to the platform. There is no rush to complete the project either. Slack functions normally without this addition, and can handle errors in the implementation. 16

Dynamism: It is unlikely for the requirements of the project to change much over time. There may be small details that need changed or fine tuning, but the basic feature and vision is already set.

Culture: It can be assumed that Slack operates similarly to other modern tech companies, in that they prefer agile development over a structured, waterfall approach. The nature of this project also fits the agile process.

Conclusion: Most of the metrics indicate an agile process will be best-suited for the project, thus it will be the process chosen. It is a small, experienced team developing a low-risk feature, in a technology company that has experience with the agile methodology. The lack of changing requirements is the only metric that favors a structured approach.

2.2. Project Management 2.2.1. Release Plan A release plan is important to determine time estimates on various requirements, as well as the entire project. It will be created based on the gathered requirements, and will prioritize which are the most important. If there are multiple releases, it will highlight what is expected in each.

2.2.2. First Iteration Plan Similar to the release plan, this iteration plan will document what is expected in the first iteration of the project. Iterations are based on requirements’ priority, and the goal is to have a deliverable at the conclusion of each step. At the end of each iteration, feedback will be given and the team will reflect on their progress, adapting to whatever changes are needed for the next iteration.

2.2.3. Risk Plan The goal of the risk plan is to identify potential risks all throughout the project. Unforeseen circumstances will be thought of, along with clear, executable plans to mitigate these risks. Having a plan to take care of problems will combat any chaos and possible delays. Each identifiable risk will also have estimates for likelihood and impact (damage).

2.2.4. Linear and Parametric Estimation These estimations are useful to compare actual versus estimated performance. They are created by assigning sizes to each iteration based on how long they are 17

expected to take. Using tools such as burndown charts allows comparison between the two, allowing further refinement on future estimates.

2.2.5. Project Schedule The project schedule is a more detailed version of the release plan. It will be a clear visual that details each iteration and step of the project, as well as the time estimates for each. The schedule will serve as a master reference, and is important for the same reasons as the release/iteration plans.

2.3. Requirements 2.3.1. Problem Statement The problem statement is a vital work-product as it serves as a consistent guideline to the project. It will precisely define what the problem is that is trying to be solved. It can be used as a reference during the project to ensure that the team is on track. For example, at the end of every iteration, they can ask how the deliverable helps solve the problem.

2.3.2. Storyboards With the precise problem in mind, storyboards will be drawn up to visualize how users will interact with the final product. In this case, the User Interface (UI) is what’s most important. The team must define what information the user expects to see, how they can interact with it, and what the effects of each interaction are.

2.3.3. Business Case The business case is important to estimate financial requirements. Physical costs, time, labor, etc. are estimated to create a rough estimate of the required time and capital.

2.3.4. Use Cases A number of use cases will be drafted to document all of the possible interactions in the product’s system. These will likely be all of the interactions an end user can have with the feature. Each use case will define actors and actions, emphasizing what is required, as well as specifically what needs to happen.

2.3.5. Non-Functional Requirements These requirements are specific to the operation of the system/product, as opposed to the functional behaviors. The non-functional requirements will be created from use cases and user stories, and will likely involve aspects such as 18

security (what all can the users access), scalability (how many users can the system handle), longevity, performance, and maintenance/longevity.

2.3.6. Acceptance Plan An acceptance plan will serve as a series of agreements between the stakeholders of the project on what will be expected. The acceptance plan is based on the initial requirements, and can be referenced to during and after the project is complete. In this way, no conflict can occur if a stakeholder is unhappy with the final results, since they already agreed on the work-products’ requirements.

2.3.7. System Tests System tests will be implemented at various points during the project to validate work up until that point. A usable system with quality interactions is necessary, and it is easier to check the quality of the product at stages, instead of dealing with all testing at the end.

2.4. Analysis 2.4.1. Domain Analysis A domain analysis is an important tool for understanding a problem and its environment. We will produce a diagram that visualizes Slack’s domain: its market, logistics, products, services, competitors, and more. This analysis serves as a guide for developers and others to understand the problem and solution space.

2.4.2. Problem Analysis The problem analysis will focus on the problem at hand, describing it and documenting possible causes. In our case, this analysis will discuss the importance of availability states and priority messaging. It will be in the form of a visual sequence diagram. This work-product goes hand-in-hand with the problem statement and the solution analysis.

2.4.3. Solution Analysis The solution analysis will reference the problem described in the above analysis and describe how we plan to solve it. It will be in the form of a class diagram, which will utilize elements from the domain analysis. The diagram will outline classes, attributes, and relationships, highlighting how the solution will fit in the domain. 19

2.4.4. Sequence Diagrams We will make use of a few sequence diagrams to help illustrate the problem at hand and our proposed solution. They will be associated with the problem and solution analyses.

2.5. Architecture 2.5.1. Subsystem Model This model will illustrate the various subsystems that address the function and non-functional requirements. Each subsystem will consist of various use cases for different users, and will contain sequence diagrams to represent the interactions users have.

2.5.2. Target Environment In the target environment, we will take the subsystems defined above and describe how they are implemented within our system. We will also address each of our stated requirements, explaining how they are fulfilled using our architecture. 20

3. Requirements Analysis 3.1. Domain Analysis The domain analysis diagram below illustrates Slack’s domain. It contains information on Slack’s industry, market, stated areas of differentiation, products and services, value chain (inbound logistics and sales), and competition.

3.2. Problem Statement As a collaboration tool, users of Slack are interested in quick and seamless communication with their peers. Many companies use Slack to close the gap that digital communication can create, but we have noticed lacking features that continue to distance coworkers. Currently, users are allowed to set a status message but are confined to two availability options: active or away. Availability is automatically updated based on the user’s activity and is shown in a small circle next to the user’s name. Limiting availability 21

to a binary setting does not give other users a clear understanding of their coworker’s presence on the platform. Furthermore, users who wish to send important messages with time-sensitive or otherwise critical content have no avenue to do this. All messages, whether sent to users or to channels, appear in the same manner. There is currently no option to mark a message as critical or otherwise indicate priority.

3.3. Problem Analysis Slack users need to be able to clearly indicate their availability and the priority of their messages. This is important in a digital environment, where the users are relying on their text-based communication to talk with others and get work done. Without a more transparent availability system, users may be messaging someone who is busy or not currently at their computer. Since the receiver’s status is “active,” they are expecting a quick response, even though the receiver is not actually paying attention to incoming messages! The sequence diagram below illustrates the frustration and inefficient communication that arises without clear availabilities. The Message Interface object represents the single interface that both users are reading and sending messages with. 22

Without a priority system, it is easy to get lost in a sea of channels and messages, and fail to see or respond to an important message. This leads to poor communication and a possible decrease in work performance. The next sequence diagram demonstrates what could happen when waiting for a response from someone. As before, the Message Interface object represents the single interface that both users are reading and sending messages with.

Not having these systems leads to annoyances and a delay in completing work, especially if a high-priority or time-sensitive message was missed. 23

3.4. Solution Analysis 3.4.1. Sequence Diagram for New Availability System The sequence diagram below represents the solution to the first sequence diagram presented in the Problem Analysis section. It showcases the new, clear availability system. As in that section, the Message Interface object represents the single interface that both users are reading and sending messages with.

This diagram fixes the problem because User 2 knows that User 1 is not at their computer, so they do not get frustrated when they don’t get an immediate response from User 1. 24

3.4.2. Sequence Diagram for New Messaging System This diagram represents the solution to the second sequence diagram presented in the Problem Analysis section. It shows our solution to Slack’s current messaging system, demonstrating the new message priority and follow-up notifications.

This diagram illustrates our solution because it shows how User 2 is made aware of how important the message that User 1 sent is, ensuring that they respond in a timely manner and thus help User 1 reach their deadline. 25

3.4.3. Class Diagram for Priority Messaging and Availability System The below class diagram shows both the proposed priority messaging and availability concepts, giving another view of the solution to our problem. 26

Workspace: This class demonstrates a Slack workspace. It has its own unique name as an attribute. It also has the ability to create a channel (passing the channel’s name as a parameter), delete a channel, add a user to the entire workspace (passing their email address as a parameter), and remove a user from the workspace. A Workspace contains at least one Channel.

Channel: This class represents a Slack channel, where users collaborate with each other through messages. The channel has a name, description, and keeps track of the number of people in that channel. Users can use this Channel class to add or remove another user from the channel, pin a message so that it is easily findable and visible, and view the members inside that channel.

User: The User class represents a Slack user that has already been added to a Workspace. This User participates in that Workspace and its Channel(s). The User’s personal information is attributed to them (email address, password for this Workspace, and first and last name). They have the ability to create a new message or availability.

Message: This class demonstrates messages that Users send to each other or to all Users in a Channel. It keeps track of the sender and the message content. It has a priority attribute, which cues the receiver into how important this message is: low, medium, high, or immediate action required. If it is just a regular message, it could also be sent with no priority. Message has a reminderTime attribute, as well, which is something that the sender indicates. This is the amount of time that will pass before a reminder notification is sent to the recipient, prompting them to respond to the unresolved priority message.

Availability: This class indicates a User’s availability. It expands on Slack’s current “active” and “away” availability, allowing a User to set their availability type as offline, busy, be right back, or online.

3.4.4. Static Structure The static structure of the solution presented in the class diagram in Section 3.4.1 consists of an application that has options for a user to send messages with heightened importance, and update their availability. Users will be able to prioritize incoming messages, as well as send out clearly-marked urgent messages in time-sensitive or critical situations. Users will also be able to see others’ availabilities. This will help them know when or when not to message someone and give them clear expectations on response time (for example, you probably shouldn’t send a message to someone who is busy, but if you do, don’t expect a quick response!). 27

3.4.5. Dynamic Behavior The dynamic behavior of the solution involves users, messages, and availabilities. The system must track what workspaces and channels one user is a part of, who that user is messaging, when to send a reminder notification if a message has not been replied to, and what a user’s availability currently is. The system must be able to keep a persistent history of messages (including their senders, contents, and priorities) between users/channels and remember to send a reminder notification if the reminder time has passed.

3.5. Storyboards 3.5.1. Scenario 1 Title: Aaron wants to alert his team about a critical bug the day of deployment. Description: In this storyboard, we will look at how priority messaging can be beneficial in common software development scenarios. Cast: - Aaron: The main actor in this scenario and a software development manager at the prestigious Gaagle.com - Jake: a QA engineer who tests software projects from Aaron’s team. - Kim: a newly hired software developer on Aaron’s team - Nathan: a software developer on Aaron’s team - Megan: a senior software developer on Aaron’s team

Aaron has a busy Friday and is in and out of meetings. He is excited however because his team is finishing up a 2 week Scrum sprint and his schedule should be less hectic soon. They are wrapping up a sprint with many user stories related to improving password management on Gaagle’s online shopping platform.

All is well until Aaron checks his phone at 4:30 pm and sees a slack message from Jake the QA engineer. Jake has alerted Aaron that he has found a critical bug in this sprint’s code. Jake has found a vulnerability that results in users’ passwords being sent through the network in plain text.

Aaron is surprised that this bug was not discovered sooner but quickly realizes that he needs to alert his team of this vulnerability before it is rolled out into production. Aaron quickly pulls out his phone and navigates to the Slack mobile application. After typing out his important message to his team in their dedicated channel, #paymentdevs, he taps the options button next to his message. He changes the priority of the message to “HIGH PRIORITY: Immediate Action Required” so that his team understands the importance of his message and the bug. 28

Because of the high-priority marking, his team receives push notifications alerting them of this message. They see that their boss, Aaron, has sent them a critical message. Thanks to the priority level, several of the team members read the message immediately and fill in the rest of the team. Kim, Nathan, and Megan are able to stop the automated deployment of the vulnerable code before it reached the production servers. The password management software stays free of vulnerabilities and the team is able to shift its focus to finding the source of the bug. Thanks to priority messaging, passwords remained safe and encrypted.

3.5.2. Scenario 2 Title: Aaron heads into a meeting while a development release is being deployed. Description: In this storyboard, we will look at how availability options can be beneficial in common software development scenarios. Cast: - Aaron: The main actor in this scenario and a software development manager at the prestigious Gaagle.com - Jake: a QA engineer who tests software projects from Aaron’s team. - Kim: a newly hired software developer on Aaron’s team - Nathan: a software developer on Aaron’s team - Megan: a senior software developer on Aaron’s team

Aaron is busy as usual as the development manager for a team of 5 at Gaagle.com. Today he is in and out of various meetings with different product owners as well as talking to business development. This is especially unfortunate because his team of developers is doing the important task of deploying their last sprint on the development server. This is especially critical because his team works on front-end code that will become visible to millions of users upon release.

Knowing that his team is working hard to deploy this software while he is in and out of meetings, Aaron uses the new availability Slack feature to indicate that he is “busy”. This tells his team of developers that he is online on Slack, but should not be bothered unless it is important. Previously Aaron could only indicate to his team if he was active or away, but now he can use the added feature to let them know that he is reachable, but only if it is critical.

Aaron’s team deploys the software successfully while he is in a meeting. They can rest easy knowing that if they need to reach him, he is online.

3.6. Business Case 3.6.1. Cost Being a pure software feature, the costs associated with this product are almost entirely in its production. These features will likely have to interface with many other internal API’s and 29 thus, the developers will have to work with many other teams. These features impacts on server usage should be negligible but are included in our price estimates below.

Initial Development: ➔ 5 developers x 3.5 months @ $100,000/year = $145,833 ➔ ½ product owner x 3.5 months @ $150,000/year = $21,875 ➔ ½ QA engineer x 3.5 months @ $100,000/year = $14,583 ➔ Total: $182,291

Initial Development Chart: Item Cost / Unit /Year Total

5 Developers $100,000 $145,833

½ Product Owner $150,000 $21,875

½ QA Engineer $100,000 $14,583

= $182,291

Ongoing Maintenance (yearly): ➔ ½ developer @ $100,000/year = $50,000/year ➔ 0.5% increase in server usage

Ongoing Maintenance (yearly) Chart: Item Cost / Unit/ Year Total

½ Developer $100,000 $50,000 / year

3.6.2. Benefit As features enclosed within a large platform, the direct benefits of these products will be difficult to measure. These features are implemented to increase user satisfaction and sell more software, so the benefits will be estimated in terms of user interaction with the platform.

➔ 0.5% increase in platform usage ◆ Equivalent to 60,000 additional daily active users. ◆ Up to $4,500,000 of additional revenue from paid customers. ➔ 20% adoption of priority messaging feature ➔ 30% adoption of new availability options 30

Benefit Chart: Item Target Metric

Increased Platform Usage 0.5% increase

Increase Daily Active Users 60,000 increase

Generate Revenue $4,500,000 increase

Priority Messaging Adoption 20% of user base

Availability Options Adoption 30% of user base

3.7. Functional Requirements Functional requirements are prioritized from highest (1) priority to lowest (9) below: 1. The platform will allow users sending a direct message to set a message priority from [none (default), low, medium, high, immediate action required] 2. The platform will allow users sending a channel message to set a message priority from [none (default), low, medium, high, immediate action required] 3. The platform will allow users receiving a message to identify the priority level. 4. The platform will allow users to select their availability from [offline, busy, be right back, online] 5. The platform will display the user's availability choice 6. The platform will allow users to set a follow-up notification time from [none (default), 5min, 10min, 30min, 1hr, 2hrs, 6hrs, 12hrs, 24hrs] 7. The platform will send a follow-up notification according to the sender’s designated follow-up notification time if one is present. 8. The platform will send recipients of messages marked “high priority” and “immediate action required” an immediate notification. 9. The platform will continue to update the user’s availability between offline and online unless the user makes a selection.

3.8. Use Cases, User Stories, and Scenarios 3.8.1. Use Case (UC1): A user sends a high priority message ❏ Functional Objectives: 1, 2, 3, 8 ❏ Description: A user wants to send an important message (either via direct message or channel message) through the Slack platform. Using the new platform, this simple operation allows the user to select from multiple priority levels. ❏ Scenario: Sending a high priority message 31

Actors Sender, Recipient

Assumptions ● The sender and the recipient exist in the same Slack workspace ● This workspace pays for a level of service that includes priority messaging

Happy Path 1. Sender navigates to the channel or user they would like to send a message to. 2. Sender types out or otherwise inputs the message they want to send. 3. Sender selects the “!” symbol for message priority, found next to the other message options. 4. Sender selects from the list of priority options. a. Options from [none (default), low, medium, high, immediate action required] 5. Sender selects the send button, and the message is sent with the designated priority level 6. Recipient receives the sent message with the indicated priority level a. If the message priority is marked as either [high, immediate action required] the recipient will receive a notification.

Error Path(s) ● Recipient has the sender blocked on the Slack platform ● Sender does not have sufficient internet connection to send their message ● Recipient does not have sufficient internet connection to receive the message

Outcome(s) ● Recipient receives the message sent by Sender with the appropriate priority level marked.

3.8.1.1. Relevant User Stories ID As a... I want to... So that...

US01 User Send a message with My recipient(s) know that they need (sender) “immediate action required” to respond as quickly as possible priority designation

US02 User Send a message with “high” My recipient(s) know that the (sender) priority designation information contained is critical

US03 User Send a message with “medium” My recipients know that the (sender) priority designation information contained is important. 32

US04 User Send a message with “low” My recipients know that the (sender) priority designation information contained is not particularly important

US05 User See received message priorities I know how critical the message is (receiver) next to the message

US06 User Send a push notification to My recipients will see my important (sender) recipients of messages marked message sooner. “high” or “immediate action required”

3.8.2. Use Case (UC2): A user sends a message with a follow-up notification ❏ Functional Objectives: 6, 7 ❏ Description: A user wants to send an important message that requires a response (either via direct message or channel message) through the Slack platform. This new feature allows the platform to send a follow-up notification to the recipient if they have not responded to the message after the sender-specified amount of time. ❏ Scenario: Setting a reminder timer for an important message

Actors Sender, Recipient

Assumptions ● The sender and the recipient exist in the same Slack workspace ● This workspace pays for a level of service that includes reminder messaging

Happy Path 1. Sender navigates to the channel or user they would like to send a message to. 2. Sender types out or otherwise inputs the message they want to send. 3. Sender selects the “timer” symbol for message reminders, found next to the other message options. 4. Sender selects from the list of timer options. a. Options from [none (default), 5min, 10min, 30min, 1hr, 2hrs, 6hrs, 12hrs, 24hrs] 5. Sender selects the send button, and the message is sent with the designated timer. 6. Recipient receives the sent message with the indicated timer level 33

a. If Recipient responds before the timer has completed its countdown, no further action occurs. b. If Recipient does not respond before the timer has completed its countdown, a notification is sent to Recipient. c. If the “none (default)” timer is chosen, the message does not exhibit any changed behavior.

Error Path(s) ● Recipient has the sender blocked on the Slack platform ● Sender does not have sufficient internet connection to send their message ● Recipient does not have sufficient internet connection to receive the message

Outcome(s) ● Recipient receives the message sent by Sender with the appropriate notification timer. If the timer runs out, a follow up notification will be sent.

3.8.2.1. Relevant User Stories ID As a... I want to... So that...

US07 User Send a message with a timed My recipient will be reminded to (sender) notification option set respond to my important message within the designated time

US08 User Receive a message with a timed I am reminded to respond to urgent (receiver) notification option set messages

3.8.3. Use Case (UC3): A user changes their availability ❏ Functional Objectives: 4, 5, 9 ❏ Description: A user wants to change their availability on the Slack platform to correlate with their level of responsiveness. This new feature allows the user to choose between several new availability options. ❏ Scenario: Changing availability

Actors User

Assumptions ● The users workspace pays for a level of service that includes increased availability options

Happy Path 1. User navigates to their profile tile in the workspace 34

2. User selects their availability 3. User selects from the drop-down list of availability options a. Options from [offline, busy, be right back, online] 4. User closes out of their profile.

Error Path(s) ● User does not have sufficient internet connection

Outcome(s) ● Users availability is changed to match their selection.

3.8.3.1. Relevant User Stories ID As a... I want to... So that...

US09 User Change my availability to Other users know that I cannot be “offline” reached

US10 User Change my availability to Other users know that I am occupied “busy” but can still receive messages

US11 User Change my availability to “be Other users know that I cannot be right back” reached now, but will return soon

US12 User Change my availability to Other users know that am available to “online” message

US13 User See my own availability next to I know what I am broadcasting to my profile other users

US14 User See other users availability next I know the availability of my to their profile tile coworkers 35

3.8.4. Use Case Diagram The user is on both sides in this scenario. They want to set their availability as well as see other users availability, etc.

3.9. Non-Functional Requirements Non functional requirements are prioritized from [1 (most critical) - 5 (least critical)] Availability 1. (1) The system must have 100% availability outside of monthly maintenance patches (10min downtime per month) 2. (1) The system will keep priority level and message notification timer available on 100% of messages 3. (2) The system should not negatively affect the platform's current availability Security 4. (2) The system must prevent unreasonable (server abusive) spamming of notification timer 5. (1) The system should maintain its current level of message security Scalability 6. (3) The system must allow every user to use the new features at the same time 36

Performance 7. (3) The system should send out reminder notifications within 5 seconds of their timer ending. 8. (4) The system should deliver messages at 99.5% of current delivery speed Usability 9. (3) The system should update the users availability between offline and online when no user selection is made 10. (4) The system should allow for the user to quickly choose a messages priority (average selection time under 10 seconds) 11. (4) The system should allow for the user to quickly choose a messages notification timer (average selection time under 15 seconds) 12. (4) The system should allow for the user to quickly change their availability (average selection time under 15 seconds) 13. (3) The system should use intuitive icons so that the new features can be easily identified Development 14. (2) The system must be unit tested at the user story level 15. (4) The system must be developed by a team of no more than 10 developers 16. (5) The system must be developed in less than 6 months 17. (4) The system’s code should not need extensive redesign to make extensions and reasonable modifications

3.10. Acceptance Plan Availability - Features should be available at all times outside of scheduled maintenance periods. - NFR: 1, 3 - Notify developers if any of the features become unavailable. - NFR: 1, 2, 3 Security - No more than 50 active message notification timers per user active at once. - NFR: 4 - No degradation of security critical code. - NFR: 5 Scalability - Can handle 100% of messages carrying a priority and timer designation. - Tested assuming 1000 users send messages concurrently. - NFR: 6 Performance - Sends out reminder notifications within 5 seconds of their timer ending. - NFR: 7 37

- Monitors performance of messaging and availability, notifying developers if there are performance issues. - NFR: 7, 8 - Deliver messages at 99.5% of current delivery speed. - NFR: 8 Usability - The new features should be easily understood by users of the platform. - NFR: 9, 10, 11, 12, 13 - The new features should be adopted by 20% of users in the first year. - NFR: 9, 10, 11, 12, 13 Development and Testing - All user stories tested by the development team. - NFR: 14 - Developed by a team of <11 developers in <6 months. - NFR: 15, 16, 17

In addition to all of the above, the system must also implement all of the functional requirements.

3.11. System Tests ● Test messages sent with priority designation ○ All users see the priority designation icon as a message option. ○ Users are correctly able to interact with the icon and see the list of priority options. ○ Users are able to select any of the priority options. ○ Users sending a message with priority designation can see the priority of that message after sending. ○ Users receiving a message with priority designation can see the priority of that message after receiving. ○ Messages with no priority designation remain unchanged. ○ Users receiving messages marked “high” or “immediate action required”, get a notification about the message. ● Test messages sent with notification timer ○ All users see the notification timer icon as a message option. ○ Users are correctly able to interact with the icon and see the list of notification timer options. ○ Users are able to select any of the timer options. ○ Users sending a message with a notification timer can see the timer associated with the message after sending. ○ Users receiving a message with a notification timer can see the timer associated with the message. 38

○ Messages with no notification timer remain unchanged. ○ Recipients of a message with notification timer receive a notification upon the timer's expiration. ○ One user cannot exceed 50 concurrent messages with notification timers. ● Test messages sent with priority designation and notification timer ○ Users can select both a priority level and a notification timer for a message. ○ Users receiving messages with a priority level and notification timer can see both the priority and message timer next to the message. ○ Users sending messages with a priority level and notification timer can see both the priority and message timer next to the message. ○ Recipients of a message with a priority level and notification timer receive a notification upon the timer's expiration. ● Test added availability options ○ All users have expanded availability options available. ○ Users are able to select from any of the availability options shown. ○ Users are able to see other users' availability. ○ Users availability is automatically changed to “online” if they return from inactivity and have not made an availability selection. ○ Users availability is automatically changed to “offline” if they are inactive and have not made an availability selection.

4. Architecture 4.1. Overview The architecture presented in Section 4 uses requirements from previous sections to design systems for the new messaging and availability features.

4.2. Subsystem Model The priority messaging, messaging with follow-up notification timer, and availability systems all work together to create the entire expanded messaging and availability features system for Slack. 39

4.2.1. Priority Messaging System This subsystem is primarily responsible for the implementation of the priority messaging feature. Comprising the priority selection system, outbound priority message system, and the inbound priority message system, this architecture allows users to seamlessly send and receive priority messages.

4.2.1.1. Priority Message Selection

Name Priority Message Selection

Description This subsystem is activated when the user selects the priority message icon next to an unsent message. This subsystem will allow the user to select the message priority of the unsent message from a list of priority options.

Supported Functional ❏ FR01: The platform will allow users sending a direct message Requirements to set a message priority from [none (default), low, medium, high, immediate action required]. 40

❏ FR02: The platform will allow users sending a channel message to set a message priority from [none (default), low, medium, high, immediate action required].

Supported ❏ NFR01, NFR03, NFR02, NFR06: The platform will Non-Functional implement this subsystem client side to ensure that it is always Requirements available to users. ❏ NFR10, NFR13: The subsystem will use a small and intuitive dropdown of preset priority options for quick message priority selection. ❏ NFR14: The selection of each priority level will be unit tested for a variety of user profiles and workspaces.

Quality Scenarios The user navigates to the priority message icon next to their unset message. They are then prompted to choose from a list of priority options. If one is selected, then this change is reflected onto the unsent message. If no selection is made or the user selects the “none/default” option, no change is made to the unsent message.

4.2.1.2. Outbound Priority Messaging

Name Outbound Priority Messaging 41

Description This subsystem is activated when the user sends a message with a selected priority level. This subsystem will allow the user to send the priority message to the intended user/channel.

Supported Functional ❏ FR01: The platform will allow users sending a direct message Requirements to set a message priority from [none (default), low, medium, high, immediate action required]. ❏ FR02: The platform will allow users sending a channel message to set a message priority from [none (default), low, medium, high, immediate action required].

Supported ❏ NFR01, NFR02, NFR03: The subsystem will implement a Non-Functional heartbeat ping to ensure that the sending of messages is always Requirements online. ❏ NFR05: The subsystem will use encryption to ensure that messages are kept confidential. ❏ NFR06, NFR08: The subsystem will implement parallelization to ensure that many priority messages can be sent at once and without delay. ❏ NFR13: The subsystem will implement intuitive icons and colors to clearly identify a message's priority level. ❏ NFR14: The sending of each priority level will be unit tested. for a variety of user profiles and workspaces.

Quality Scenarios After the user has typed a message and selected a priority level, they click the send button. The subsystem will then forward the message to the appropriate recipients with the indicated priority level. 42

4.2.1.3. Inbound Priority Messaging

Name Inbound Priority Messaging

Description This subsystem is activated when a user sends a message with a selected priority level. This subsystem will allow the user to receive said priority message addressed to them.

Supported Functional ❏ FR03: The platform will allow users receiving a message to Requirements identify the priority level.

Supported ❏ NFR01, NFR02, NFR03: The subsystem will implement a Non-Functional heartbeat ping to ensure that users can always receive Requirements messages. ❏ NFR05: The subsystem will use decryption to ensure that messages are only readable by the intended recipients. ❏ NFR06, NFR08: The subsystem will implement parallelization to ensure that many priority messages can be received at once and without delay. ❏ NFR13: The subsystem will implement intuitive icons and colors to clearly identify a message's priority level. ❏ NFR14: The receiving of each priority level will be unit tested for a variety of user profiles and workspaces.

Quality Scenarios A user sends a priority message through the outbound priority 43

messaging subsystem. The inbound priority messaging subsystem will receive the message with associated priority level, and forward the corresponding view to the user.

4.2.1.4. Sequence Diagram for the Entire Priority Messaging System A sequence diagram depicting the sending and receiving of a priority message including the functions of all three subsystems is included below. 44

4.2.2. Follow-Up Notification Messaging System This subsystem is responsible for the implementation of the follow-up notification and timer. A notification will be sent some amount of time after a message has been sent, if that message has not been replied to. This amount of time is the timer selected by the user before they send the message. This architecture is composed of the timer selection system, the outbound notification messaging system, and the inbound notification messaging system.

4.2.2.1. Timer Selection

Name Timer Selection

Description This subsystem allows users to select from a predefined list of options that dictates when a follow-up notification will be sent. It is activated when a user opens up the timer selection menu. Whatever they choose is then tacked on to the outbound message as an attribute, so that the system knows when to send a follow-up notification. 45

Supported Functional ❏ FR06: The platform will allow users to set a follow-up Requirements notification time from [none (default), 5min, 10min, 30min, 1hr, 2hrs, 6hrs, 12hrs, 24hrs].

Supported ❏ NFR01, NFR02, NFR03: The subsystem will implement a Non-Functional heartbeat ping to ensure that the timer option is always online. Requirements ❏ NFR04: The subsystem will use detection, checking system logs, to ensure that no one abuses the notification timer system. ❏ NFR06: The subsystem will localize and reduce coupling to ensure that this system’s performance does not hinder any other system’s. ❏ NFR07: The subsystem will implement parallelization and check response time to ensure that notifications are being sent promptly. ❏ NFR11, NFR13: The subsystem will use an intuitive user interface that contains predefined options for quick timer selection. ❏ NFR14: The selection of each timer will be unit tested for a variety of user profiles and workspaces.

Quality Scenarios A user creates a message and navigates to the timer selection screen. They can select 1 time to set as the timer for the follow-up notification. This won’t be processed until the menu is closed, so they can unselect the time and exit the menu, canceling the selection without consequence. If a selection is made, the reminder time will be updated for the unsent message. If no selection is made or the user selects the “none/default” option, no change is made to the unsent message. 46

4.2.2.2. Outbound Notification Messaging

Name Outbound Notification Messaging

Description This subsystem is activated when a user sends a message. It will send a follow-up notification to the recipient after the chosen (or default) notification timer ends.

Supported Functional ❏ FR06: The platform will allow users to set a follow-up Requirements notification time from [none (default), 5min, 10min, 30min, 1hr, 2hrs, 6hrs, 12hrs, 24hrs]. ❏ FR07: The platform will send a follow-up notification according to the sender’s designated follow-up notification time if one is present.

Supported ❏ NFR01, NFR02, NFR03: The subsystem will implement a Non-Functional heartbeat ping to ensure that the messaging and notification Requirements system is always online. ❏ NFR04: The subsystem will use detection, checking system logs, to ensure that no one abuses the notification timer system. ❏ NFR05: The subsystem will use encryption to ensure that messages are kept confidential. ❏ NFR06: The subsystem will localize and reduce coupling to ensure that this system’s performance does not hinder any other system’s. ❏ NFR07, NFR08: The subsystem will implement parallelization 47

and check response time to ensure that messages and notifications are being sent promptly. ❏ NFR11, NFR13: The subsystem will use an intuitive user interface that contains predefined options for quick timer selection. ❏ NFR14: The selection of each timer will be unit tested for a variety of user profiles and workspaces.

Quality Scenarios A user creates and sends a message to another user or channel. If they selected a specific notification time, a follow-up notification will be sent if no response has been received after the allotted amount of time has passed. If they did not select a time, then no follow-up notification will be sent, as the default is no follow-up notification.

4.2.2.3. Inbound Notification Messaging

Name Inbound Notification Messaging

Description This subsystem is activated for the recipient when a user sends a message. It will show a follow-up notification to the recipient after the chosen (or default) notification timer ends. 48

Supported Functional ❏ FR07: The platform will send a follow-up notification Requirements according to the sender’s designated follow-up notification time if one is present.

Supported ❏ NFR01, NFR02, NFR03: The subsystem will implement a Non-Functional heartbeat ping to ensure that the messaging and notification Requirements system is always online. ❏ NFR04: The subsystem will use detection, checking system logs, to ensure that no one abuses the notification timer system. ❏ NFR05: The subsystem will use decryption to ensure that messages are only readable by the intended recipients. ❏ NFR06: The subsystem will localize and reduce coupling to ensure that this system’s performance does not hinder any other system’s. ❏ NFR07, NFR08: The subsystem will implement parallelization and check response time to ensure that messages and notifications are being sent promptly. ❏ NFR14: The selection of each timer will be unit tested for a variety of user profiles and workspaces.

Quality Scenarios A user creates and sends a message to another user or channel through the outbound notification messaging system. If this message was sent with a follow-up notification timer, then the system constantly checks if a response has been received. If a response has not been received and that timer ends, a follow-up/reminder notification is sent to the recipient. 49

4.2.2.4. Sequence Diagram for the Entire Notification Messaging System For clarity and convenience, a sequence diagram depicting the full notification messaging system, including the functions of all three subsystems, is included below.

4.2.3. Availability System This subsystem is responsible for the implementation of the expanded availability feature. It allows users to set their availability, which is something that other users can see. 50

4.2.3.1. Availability Selection

Name Availability Selection

Description This subsystem allows users to select their availability from a predefined list of expanded options. It is activated when a user opens up the availability menu in order to select and set their current availability. Whatever they set is internally updated and made public so that other users can see what this user’s availability is.

Supported Functional ❏ FR04: The platform will allow users to select their availability Requirements from [offline, busy, be right back, online]. ❏ FR05: The platform will display the user's availability choice.

Supported ❏ NFR01, NFR03: The subsystem will implement a heartbeat Non-Functional ping to ensure that the availability setting is always online. Requirements ❏ NFR06: The subsystem will localize and reduce coupling to ensure that this system’s performance does not hinder any other system’s. ❏ NFR12, NFR13: The subsystem will use an intuitive user interface that contains predefined options for quick availability selection. ❏ NFR14: The selection of each availability will be unit tested for a variety of user profiles and workspaces.

Quality Scenarios A user navigates to the availability selection screen. They can select 1 51

availability to set. This won’t be processed until the menu is closed, so they can unselect the new availability or reselect their old availability and exit the menu, canceling the selection without consequence.

4.2.3.2. Automatic Availability Update If a user does not open the availability selection menu and choose one, the system will automatically update that user’s availability between online and offline, corresponding to when that user is on/off Slack.

Name Automatic Availability Selection

Description This subsystem is activated whenever a user opens or closes Slack. It automatically updates a user’s availability as on- or offline, unless that user selects an availability using the subsystem shown in 4.2.3.1.

Supported Functional ❏ FR05: The platform will display the user's availability choice. Requirements ❏ FR09: The platform will continue to update the user’s availability between offline and online unless the user makes a selection.

Supported ❏ NFR01, NFR03: The subsystem will implement a heartbeat Non-Functional ping to ensure that the availability setting is always online. 52

Requirements ❏ NFR06: The subsystem will localize and reduce coupling to ensure that this system’s performance does not hinder any other system’s. ❏ NFR09: The subsystem will automatically update the availability user interface to reflect the user being on- or offline. ❏ NFR14: The automatic availability will be unit tested for a variety of user profiles and workspaces.

Quality Scenarios A user opens Slack. Slack recognizes this, and their availability is automatically set to online. If the user closes Slack, Slack will recognize that, automatically setting their availability to offline. 53

4.3. Target Environment The target environment details a suitable software architecture for the functional and non-functional requirements. It is highlighted by a visual for the deployment plan and describes each of the systems involved.

4.3.1. Deployment Diagram

4.3.2. Explanation of Deployment Diagram Name Cross-platform UI

Description User interface to support various devices, operating systems, and screen sizes (Android, iOS, desktop browsers/apps, etc.)

FR’s Met 3, 5

NFR’s Met 1, 3, 6, 17: The UI will support any available actions, and will be available 100% of the time. 54

4: The UI’s will support a time-out system or time limit. 10-13: The UI’s will clearly and cleanly show availability and options to change availability/message priority, without hassle.

Quality The user navigates to the priority settings when sending a message to a Scenarios colleague. The message contains important information, so they choose the option in the UI to give it priority.

Name Web Server

Description Takes front-end requests (from the user) as input, identifies and executes the corresponding back-end changes/work.

FR’s Met None directly; relevant to most NFRs.

NFR’s Met 1-4, 6, 8: The web server processing is inexpensive, light, and balanced. This allows scalability, i.e. more servers to accommodate requests.

Quality 20,000 users change their availability preference, and 5,000 add priority Scenarios to a message within a channel, all within a minute. The web server should handle all requests, each within 1 second.

Name Availability Modification System

Description The system behind changing a user’s availability option. Choosing an option will send changes to the database server.

FR’s Met 4, 9

NFR’s Met 9, 12-14: The system will have simple icons to reflect changing availability, and will default to normal online/offline status behavior.

Quality A user wants to hide their online status in Slack. They choose the Scenarios “Offline” setting within the availability options. 55

Name Availability Viewing System

Description The system behind viewing users’ availability. The web server will send it a request for a certain user, and the system will pull the appropriate information from the database server. It will then be sent back to the web server for displaying.

FR’s Met 5

NFR’s Met 9, 13, 14: The system will allow users to easily view others’ availability, with simple icons and interfaces.

Quality A user wants to check whether their colleague is online. They navigate to Scenarios their name/profile, such as within a workspace/channel, and click to view their status.

Name Message Creation System

Description The system behind changing a message’s priority setting. Appropriate setting information will be sent to the database server for storage and future use. Also includes reminder notification options/information.

FR’s Met 1, 2, 6, 7, 8

NFR’s Met 2, 7, 10, 11, 13: The system will have simple icons and easy-to-use interfaces and drop-down menus. The UI will be intuitive so that users can easily change priority settings. 5: Message security and encryption will be persistent. 8: Priority will not affect message speed, nor will the number of people utilizing it.

Quality A user wants to send a high priority message to their boss, within the Scenarios company workspace. While drafting their message, they can choose to set the priority as “high,” to help ensure that their boss sees it and can respond. 56

Name Message Viewing System

Description The system behind viewing a message, specifically for priority information. The web server will send the system a request for a message, and the system will pull the appropriate information from the database server. It will then be sent back to the web server for displaying. In addition, the system makes requests for reminder notifications, if applicable.

FR’s Met 3, 7, 8

NFR’s Met 2, 7, 13: The interface will clearly show a message’s priority, and notifications will be persistent and reliable. 5: The security of a message will not be compromised by the addition of priority and notifications; any encryption will still be intact.

Quality A user checks a new message they got from a friend. The message is Scenarios tagged with low priority, so they know that it is not very important and can take their time responding.

Name Database Server

Description Handles storing of data as well as retrieval based on requests from other systems. The database will be passively backed up periodically.

FR’s Met 1-6, 9

NFR’s Met 1: The database is backed up continually, so the information will always be available. 2: Priority level and notification data will be persistent. 5: Messages will continue to be encrypted to provide security. 9: Automatic updates will change the database accordingly, and will be persistent.

Quality Once a user’s availability setting has changed, the appropriate data should Scenarios be able to be found in the database, with the same encryption as before. 57

Name Issue Tracker

Description This system communicates with all of the other backend systems to ensure that they are active, functional, and have no errors. If not, employees will be notified with detail.

FR’s Met None

NFR’s Met 1: Any systems with errors can be fixed immediately. 3: No system will negatively impact performance or availability.

Quality A rough lightning storm takes out one of the web servers. Employees are Scenarios immediately notified of the outage so that they can reboot it.

5. Project Planning 5.1. Release Plan The following release plan assumes that development work will start on May 3, 2021 and continue for 3.5 months. This development work starts after the 2-week Pre Release Inception and Elaboration period.

● Release 1: Priority Messaging (release on June 3, 2021) ○ Completion of basic UI menu that allows user to select message priority ○ Completion of basic UI icons that allow users to see message priority on the message ○ Completion of basic UI icons that allow users to see message priority on the notification for the message ○ Allow users to send a direct message with a priority ○ Allow users to send a channel message with a priority ○ System ensures all messages are encrypted ● Release 2: Availability (release on June 24, 2021) ○ Completion of basic UI menu that allows user to select availability ○ Completion of basic UI icons that allow users to identify another user’s availability ○ System automatically updates a user’s availability to “online” when they open Slack, unless another availability was already chosen ○ System automatically updates a user’s availability to “offline” when they close Slack, unless another availability was already chosen ● Release 3: Follow-Up Notification Messaging (release on July 23, 2021) ○ Completion of basic UI menu that allows user to select a timer ○ Completion of basic UI for the follow-up notification 58

○ Allow users to send a message with a follow-up notification timer ○ System creates a timer with the selected time, keeping track of how long it has been since the initial message was sent ■ System sends a notification after the timer is up, only if the recipient did not respond before the timer was up ○ System ensures all messages are encrypted ● Release 4: Cleanup (release on August 10, 2021) ○ System sends immediate notification for “high priority” and “immediate action required” messages, bypassing the recipient’s availability/notification settings if needed ○ All UI is enhanced, ensuring it is intuitive and well-designed ○ Extra functionality is added based on user requests

5.2. First Release The following is a description of the first planned iteration of development. Being the first iteration of the system, we have prioritized the most valuable features and requirements to be developed.

● Release 1: Priority Messaging (release on June 3, 2021) ○ Completion of basic UI menu that allows user to select message priority ○ Completion of basic UI icons that allow users to see message priority on the message ○ Completion of basic UI icons that allow users to see message priority on the notification for the message ○ Allow users to send a direct message with a priority ○ Allow users to send a channel message with a priority ○ System ensures all messages are encrypted ● Functional Requirements ○ This release will implement our three highest priority functional requirements, detailed below. FR01 is of highest priority, FR09 is of lowest priority. ○ FR01: The platform will allow users sending a direct message to set a message priority from [none (default), low, medium, high, immediate action required] ○ FR02: The platform will allow users sending a channel message to set a message priority from [none (default), low, medium, high, immediate action required] ○ FR03: The platform will allow users receiving a message to identify the priority level. ● Non-Functional Requirements ○ This release will support some of our relevant and highest priority non-functional requirements, detailed below. The priority level on a scale from 1-5 is noted in parentheses. 59

○ NFR01, (1): The system must have 100% availability outside of monthly maintenance patches (10min downtime per month). ○ NFR02, (1): The system will keep priority level and message notification timer available on 100% of messages ○ NFR03, (2): The system should not negatively affect the platform's current availability ○ NFR05, (1): The system should maintain its current level of message security ○ NFR06, (3): The system must allow every user to use the new features at the same time. ○ NFR08, (4): The system should deliver messages at 99.5% of current delivery speed ○ NFR10, (4): The system should allow for the user to quickly choose a messages priority (average selection time under 10 seconds) ○ NFR13, (3): The system should use intuitive icons so that the new features can be easily identified ○ NFR14, (2): The system must be unit tested at the user story level. ● Implemented Use Case ○ This release directly implements features detailed in our first use case. ○ UC1: A user sends a high priority message. ○ Description: A user wants to send an important message (either via direct message or channel message) through the Slack platform. Using the new platform, this simple operation allows the user to select from multiple priority levels. ● Implemented User Stories ○ This release will implement the following user stories: ID As a... I want to... So that...

US01 User Send a message with My recipient(s) know that they need (sender) “immediate action required” to respond as quickly as possible priority designation

US02 User Send a message with “high” My recipient(s) know that the (sender) priority designation information contained is critical

US03 User Send a message with “medium” My recipients know that the (sender) priority designation information contained is important.

US04 User Send a message with “low” My recipients know that the (sender) priority designation information contained is not particularly important 60

US05 User See received message priorities I know how critical the message is (receiver) next to the message

5.3. Project Estimation The Project Estimation includes two methods of estimating the total effort, in hours, needed for the project. The first, Linear Estimation, is based on the expected tasks involved in each of the releases. The second method, Use Case Point Estimates, assigns weightings and values to actors, use cases, and technical and environmental factors to produce a final time estimate.

5.3.1. Linear Estimation The below table lists the tasks included in the project release, with each given an estimate for the number of hours taken to complete. These values are summed to produce the final effort estimate.

Task Effort (Hours)

UI: Message priority selection menu 100

UI: Message priority viewing on message itself 100

UI: Message priority viewing on notification 100

User ability to send direct message with priority 200

User ability to send channel message with priority 175

System ensurance of encryption on all messages 100

Release 1 (Priority Messaging) testing 120

UI: User availability selection menu 100

UI: User availability icons for identification 90

Automatic availability updates to online when user opens Slack 100 (if no default)

Automatic availability updates to offline when user closes Slack 100 (if no default)

Release 2 (Availability) testing 120 61

UI: timer selection menu 100

UI: follow-up notification 120

User ability to send a message with a follow-up notification timer 200

System creation and tracking of timer; send notification if timer 150 elapses without any recipient response

System ensurance of encryption on all messages 100

Release 3 (Follow-up Notifications) testing 110

Immediate notifications for high priority messages (possible 120 system bypasses)

Enhancement of UI; well-designed and intuitive 150

Extra functionality based on user requests 150

Release 4 (Cleanup) testing 110

Total: 2715

5.3.2. Use Case Point Estimates In the below Actors table, each actor involved with the system is assigned one of three types based on the complexity of their interactions within the system. Each type has a set weighting associated with it (Simple = 5, Average = 10, Complex = 15). These values are summed to produce the Unadjusted Actor Weight (UAW).

Actor Type Weighting

User sending message Complex 15

User receiving message Complex 15

User setting availability Complex 15

User viewing availability Complex 15

Unadjusted Actor Weight 60 (UAW) 62

In the below Use Cases table, each use case for the project is assigned one of three complexity types based on the difficulty of its implementation. Each type has a set weighting associated with it (Simple = 5, Average = 10, Complex = 15). These values are summed to produce the Use Case Weight, which is combined with the Actor Weight to produce the final Unadjusted Use Case Point (UUCP).

Use Case Type Weighting

UI: Message priority Average 10 selection menu

UI: Message priority viewing Simple 5 on message itself

UI: Message priority viewing Simple 5 on notification

User ability to send direct Complex 15 message with priority

User ability to send channel Complex 15 message with priority

System ensurance of Average 10 encryption on all messages

Release 1 (Priority Complex 15 Messaging) testing

UI: User availability selection Simple 5 menu

UI: User availability icons for Simple 5 identification

Automatic availability Simple 5 updates to online when user opens Slack (if no default)

Automatic availability Simple 5 updates to offline when user closes Slack (if no default) 63

Release 2 (Availability) Complex 15 testing

UI: timer selection menu Simple 5

UI: follow-up notification Simple 5

User ability to send a Complex 15 message with a follow-up notification timer

System creation and tracking Complex 15 of timer; send notification if timer elapses without any recipient response

System ensurance of Average 10 encryption on all messages

Release 3 (Follow-up Complex 15 Notifications) testing

Immediate notifications for Average 10 high priority messages (possible system bypasses)

Enhancement of UI; Complex 15 well-designed and intuitive

Extra functionality based on Average 10 user requests

Release 4 (Cleanup) testing Complex 15

Unadjusted Use Case 225 Weight (UUCW)

Unadjusted Use Case Point 285 (UUCP) = UAW + UUCW 64

The below Technical Complexity table describes various technical factors. Each factor has a set weight, and is given an assigned value (0-5) based on its importance to the project. The Technical Factor (TF) is calculated using the final weighted values, and then adjusted to produce the Technical Complexity Factor (TCF).

Factor Description Weight Assigned Value Weight*Assigned Value

T1 Distributed system 2.0 5 10

T2 Response time/performance 1.0 5 5 objectives

T3 End-user efficiency 1.0 5 5

T4 Internal processing 1.0 3 3 complexity

T5 Code reusability 1.0 2 2

T6 Easy to install 0.5 1 0.5

T7 Easy to use 0.5 5 2.5

T8 Portability 2.0 3 6

T9 System maintenance 1.0 3 3

T10 Concurrent/parallel 1.0 1 1 processing

T11 Security features 1.0 4 4

T12 Access for third parties 1.0 2 2

T13 End user training 1.0 4 4

Total (TF): 48

Technical 1.08 Complexity Factor (TCF) = 0.6 + (TF/100) 65

The below Environmental Complexity table describes various environmental factors. Each factor has a set weight, and is given an assigned value (0-5) based on its importance to the project. The Environmental Factor (EF) is calculated using the final weighted values, and then adjusted to produce the Environmental Complexity Factor (ECF). This final environmental value is used, in addition to the UUCP and TCF, to calculate the final work/effort estimate.

Factor Description Weight Assigned Value Weight*Assigned Value

E1 Familiarity with 1.5 3 4.5 development process

E2 Application experience 0.5 5 2.5

E3 Team object-oriented 1.0 4 4 experience

E4 Lead analyst capability 0.5 5 2.5

E5 Team motivation 1.0 2 2

E6 Stability of requirements 2.0 3 6

E7 Part-time staff -1.0 1 -1

E8 Difficult programming -1.0 3 -3 language

Total (EF): 17.5

ECF = 1.4 + 0.875 (-0.3*EF)

Use Case Points 269.33 (UCP) = UUCP * TCF * ECF

Total Estimate 4039.88 hours (UCP * 15 hours) 66

5.3.3. Comparison of Estimates The linear estimate produces an expected time of 2715. This estimate was calculated from dividing all of the project work into singular tasks with end products. Each of these tasks was then given a time estimate. It is likely that the true final estimate is higher or lower than the calculated, since the team is not yet aware of how labor-intensive each task will truly be. The use case point estimate was calculated by assigned weights and values to actors, use cases, as well as technical and environmental factors. These estimates were adjusted and gave a final estimate of 4039.88. The team believes that this estimate is significantly conservative, as the individual weights tended to be generous and conservative. In the end, our team has decided to use the linear estimate over the use case points. We are more confident in our individual estimates in it, and more familiar with the factors involved. The team does not anticipate the project’s true timeline to be much higher than the estimate.

5.4. Project Schedule The following is a Gantt chart outlining the projected project schedule. Each of the four releases are color coded and all associated tasks are listed in chronological order. This project schedule is based off of the linear estimation from 5.3 and the assumption of 5 developers.

A full size .pdf version of this chart can be found here. 67

5.5. Risk Management Plan The below table details some possible risks and how the team would manage them.

Risk Impact Transition Mitigation Containment Indicator

Budget Cut Less resources Corporate Consistently Determine which and/or developers informs the communicate with requirements can be would be available project manager the project owner cut from the project, to for the project, of reduction in and corporate to help the project be making the project the budget. receive feedback and finished on time even more difficult to discuss plans for the with a lower budget. complete. project. To lower costs, Create demo releases remove dependencies for the project owner on expensive external and corporate which resources or, if showcase the team’s needed, remove progress. developers from the project.

Inaccurate Team would be Team is more Re-estimate already Simplify or remove Estimations behind and would than 2 weeks completed tasks; features from the need to reevaluate behind the initial review the rest of the project. their tasks and project schedule. project and use the current project re-estimations to If needed, ask schedule. They may provide more corporate for more need to simplify or accurate estimations resources and/or an remove features, or for the remaining extension on the ask for more tasks. project timeline. resources, to finish the project on time. Have the developers If it cannot be consistently finished on time, communicate with they would need to each other to provide alert corporate of the updates and get help delay and create a with tasks as needed. new project schedule. 68

Sudden Team would need to Project owner Create a new project Meet with project Increase in reevaluate their informs the schedule; review the owner to go over new Scope current project project manager rest of the project requirements and schedule, adding of several new and add estimations scope out the new more tasks and requirements for the use cases and tasks needed to meet possibly extending and/or use cases. tasks related to the those requirements. the project timeline new requirements. to fit in the new To avoid extending requirements. Have the developers project timeline, meet consistently with project owner to communicate with simplify or remove each other to provide planned features from updates and get help the project. with tasks as needed.

6. Resources ● https://slack.com/about ● https://www.theverge.com/2019/7/11/20689143/microsoft-teams-active-daily-users-stats- slack-competition ● https://www.businessofapps.com/data/slack-statistics/ ● https://slack.com/connect ● https://slack.com/features ● https://app.slack.com/plans ● https://s23.q4cdn.com/371616720/files/doc_financials/2021/q1/FY21-Q1-Earnings_-CE O-CFO-prepared-remarks.pdf ● https://slack.com/help/articles/115003205446-Slack-plans-and-features- ● https://www.businessinsider.com/what-its-like-to-work-at-slack-san-francisco-office-202 0-1 ● https://slack.com/help/articles/202878523-Try-a-paid-plan-for-free#if-you-dont-upgrade- 1 ● https://slack.com/help/articles/206646877-Apply-for-the-Slack-for-Education-discount ● https://slack.com/help/articles/204368833-Apply-for-the-Slack-for-Nonprofits-discount ● https://slack.com/contact-sales?slug=home ● https://slack.com/help ● https://slack.com/resources/using-slack/your-quick-start-guide-to-slack ● https://slack.com/resources ● https://slack.com/trust/privacy/privacy-policy#collect ● https://slack.com/ ● https://slack.com/scale 69

● https://slack.com/engage-users ● https://slack.com/features/channels ● https://slack.com/why/slack-vs-email ● https://slack.com/integrations ● https://en.wikipedia.org/wiki/Slack_(software) ● https://www.cayenneapps.com/blog/2019/04/08/slack-swot-analysis/ ● https://kinsta.com/blog/slack-alternatives/ ● https://www.statista.com/statistics/652779/worldwide-slack-users-total-vs-paid/#:~:text= Slack%20had%20around%2012%20million%20daily%20active%20users%20as%20of% 20October%202019 ● Class Notes: The How Competitive Forces Shape Strategy PDF by Michael E. Porter