2 The Societal Problem

2.1 Problem Statement

The Problem Statement is a description of some process (or operation) that can be improved. It is

• succinct - the minimum amount of language is used (i.e., any unnecessary words, sub-phrases, or sub-statements are pruned).

• complete - the full context that an observer needs to understand the problem is captured by the statement.

• unambiguous - any one reading the statement will walk away with the same understanding. If you show the statement to twenty (20) different people… all of them will agree on the overall meaning.

You will find that this is very similar to writing requirements in an SRS.

2.2 Problem Characteristics

These are statistics, quotes, or additional context that serve to justify a software solution for the selected problem.

Motivate the need for a software solution.

2.3 Current Process Flow

A flowchart that summarizes the steps that a person would currently take using available tools and technology (i.e., the current process).

At the end of the day… we need to capture:

1. Steps that can be automated
2. Steps that can be partially automated
3. Steps that are repetitive
4. Steps that are tedious
5. Steps that are subject to error
6. Shortcomings in the current process

3 Solution

3.1 Solution Statement

Analogous to the Problem Statement. The Problem Statement succinctly, unambiguously, and completely states what the Societal Problem actually is.

The Solution Statement succinctly, unambiguously, and completely states what the software-based solution will be:

1. Type of software that will be built (e.g., smartphone app, web app, desktop application)
2. What will the software do at a very high level (i.e., how would I explain to a friend, family member, or acquaintance?)

3.2 Solution Process Flow

3.3 What it Will Do

This is a slightly more detailed breakdown of features and functionality. Think of this as an initial clarification of our Solution Statement. A short list of goals and sub-problems.

3.4 What it Will Not Do

What problems (more aptly aspects of the problem) will we not address? …why?

3.5 Competition Matrix

The Competition Matrix focuses on four (4) questions:

1. What solutions already exist?
2. What features and functionality do existing solutions offer?
3. What features and functionality do existing solutions not offer?
4. How do will our solution compare?

One thing that arises out of this process… is the notion of direct and indirect competitors.

• A direct competitor is something that offers a comparable service or solution that may be selected over our product (e.g., Firefox vs Google Chrome). Must be listed in our competition matrix.

• An indirect competitor is something that offers functionality similar to a portion our product (Khan Academy vs YouTube Channel). Acknowleging that it exists and clarifying why it is not a true competitor.

Note… make sure that our product lists in the first column after feature.

We want to emphasize:

1. Our claims to fame, i.e.,
   1. what we are doing
   2. what we are doing better
   3. what we are not doing
2. Our main features
3. Who we are (i.e., show that we are not just doing one thing better or doing all the things)

Let us keep the following rules in mind…

1. Features and functionality must be listed in the left-most column.

2. Our RWP must be listed in the second column. (It should be clear who we are.)

3. Leave cells/entries blank if it does not apply to our solution or a competitor.

4. Use a symbol (e.g., a check) to indicate when something does apply.

5. Use an asterisk or the word “partial” if a feature is only partially available.

4 Development Tools

What tools and software will your team use during development. These are not part of what you are building.

You will start with:

5 Major Functional Components

Software and technologies that will form our tech stack. The most common tech stack (historically speaking) was the LAMP stack:

• L for Linux (Operating System)
• A for Apache (Web Server)
• M for MySQL (Database)
• P for PHP (Server Side Language)

More recently the use of

• L - Docker and Docker Compose have decreased the importance of the selected operating system.

• A - Django and Flask (in Python) and Node.js (in JavaScript) have supplanted Apache as The Webserver. Note that while NGINX is quite common… it is more than just a webserver and is beyond the scope of this discussion.

• M - PostgreSQL has become the goto for relational databases over MySQL. MongoDB and Firebase are the goto choices for NoSQL databases. SQLite exists for local applications.

• P - Python and Server-Side JavaScript have supplanted PHP.

5.1 Major Functional Components Diagram

This is a diagram that shows would tools and technologies your software will require. This will include:

• Off-The-Shelf software
• Off-The-Shelf hardware (if applicable)
• What we will build

The diagram should communicate:

1. What technologies currently exist and will be used as part of our product

2. What components and functionality we need to build (software)

3. What is in the box

6 Risks

These are any issues or problems that we will encounter. Our categories of interest include:

1. Customer & End User

2. Technical

3. Security

4. Legal

Slides will need to describe each risk, the probability of each risk, and the impact of each risk. The scale will be from 1 (lowest) to 5 (highest).

Each risk will be accompanied by a description of how that risk will be mitigated (Mitigation) and how that impact and probability will decrease.

We will discuss risks in more detail during a future lecture.

7 Appendix

Material in this section does not apply to the Feasibility Presentation and, if present in your slide deck, should be located in an Appendix section after your References slide.

7.1 Real World Product vs Prototype Table

This is is a table with four (4) columns:

1. Features & Functionality - This column lists features and functionality discussed in the presentation materials (e.g., the Competition Matrix).

2. RWP - This column indicates that the feature or functionality will be present in the RWP.

3. Prototype (Planned) - This column indicates whether a feature or functionality will be present in the prototype. The word “partially” may be used of part if the feature will be available.

4. Prototype (Actual) - This column tracks any changes to prototype functionality and features based on lessons learned throught CS 411W. This column is usually not present in CS 410 presentations.

8 Your (Immediate) Tasks

As a team…

1. Create a slide deck in Google Slides.

2. Make sure everyone has edit access.

3. Create a placeholder slide for each of the deliverables listed within this document.

4. Complete the Title slide.

5. Complete a Team Bio slide.

   Populate this slide with an entry for each team member (name and photo).

6. Create an Elevator Pitch slide.

   Provide a high-level overview of the software to be built.

7. Create a Table of Contents slide.