Requirements

Early in the course, you are expected to identify a hypothetical user and a problem that you wish to help them address with your project. Requirements are the specific features and qualities that you must implement for your application to be successful, and solve the problems it was designed to address.

Given that every team is tackling a different problem, you should expect that each team will have different requirements e.g., everyone will be producing an application with a graphical user interface (a standard requirement), but the structure and layout of your application will be unique to you and your team (unique requirements). Your application will ultimately need to address both sets of requirements.

Purpose of this Document

In this course, you are assessed on the quality and completeness of final product, as well as your use of suitable practices. This document focuses on the requirements for the final product itself and what you must deliver.

For details on how to deliver your product, see the guidelines instead.

Standard Requirements

You will design and build a desktop or mobile application that solves a problem for a particular user. Regardless of the problem that you set out to solve, your application must meet all of these requirements.

1. Supported platform

You must design and build your application for one of the following platforms.

• Windows, macOS, or Linux desktop
• Android mobile phone
• iOS mobile phone ¹

This requirement can be replaced by the multiplatform support advanced requirement below.

2. Graphical user interface

Your application should have a user interface built using Compose Multiplatform (desktop/iOS) or Jetpack Compose (Android). Your application should include at least three different screens, and you must support navigating between them.

For a desktop application:

• Your screens should be windowed.
• Users should be able to minimize, maximize and resize windows as you would expect for a desktop application, and windows should have titles.
• Your application should have a custom icon both when running (in the Dock or Taskbar), and when installed (in the Applications folder or Start Menu).

For a mobile application:

• Users should be able to use normal gestures to navigate between screens. You must support back-stack navigation.
• When rotated, your screens should rotate to match the orientation, and layouts should modify themselves to fit the screen dimensions in either orientation.

Your user interface should also have a custom theme that you have produced i.e., custom colors, fonts and so on. Marks will be deducted if you simply use the default Material theme included in Compose.

3. Consume a public API

You must use a public API that offers value to your application, and consume data that it provides. e.g., your calendaring application could use a public API to determine holidays, or your journal could look up the current weather for a new journal entry, or your recipe application could look up a recipe from a service online. See the public APIs for some suggestions.

You are only expected to read data from this API.

This requirement can be replaced by the hosted service advanced requirement below.

4. Use a SQL database

Your application uses and stores its data in a SQL database e.g., recipe for a recipe tracking application; user profile information needed to login; the choice of theme to use in the UI.

We will demonstrate and use SQLite with the Exposed framework.

This requirement can be replaced by the online database advanced requirement below.

5. One advanced feature

Every project must choose one of these advanced features to implement.

Your choice should be determined largely by which of these is most suitable for your specific project e.g., adding multiplatform support to target both Android and iOS for a workout app (since you wil use it in a gym), or a shared database for a recipe application that lets people exchange recipes (since a shared database would enable data sharing).

Option 1: Multiplatform

Your application builds and runs on at least two different platforms from this list: Desktop/JVM, Android, iOS. You have built your app using Kotlin Multiplatform and Compose Multiplatform, and reused most of your application code. All functionality is available on both platforms.

Option 2: Hosted Service

Instead of just consuming data from someone else’s API, you have written your own web service using Ktor and have it hosted online. This service must provide essential functionality required by some of your other features.

Option 3: Online Database

Instead of running your application against a local SQL database, you choose to host your data in Supabase - an online instance of PostgreSQL - using the Supabase SDK. Of course, since it’s now online, you need to make your application secure by using Supabase username/password authentication. You would need to handle login, logout, password reset and other related functionality. You also would need to support multiple users i.e. more than one user, each with their own username/password.

Custom Requirements

As part of your project proposal, you must define a user, their problem, and user-stories i.e., problems and expected solutions. You must also list a number of custom features that you will implement to solve that problem for them.

These are features that you will propose that are specific to your application e.g., sorting recipes in a cooking application, display a social feed for other users in a multiuser application.

This list of features will be different for each project but should be sufficient to address all of the functionality that the user might expect. Your grade will depend on how well you address the user’s problem, and how well the features are designed.

How to document these

Your project proposal is focused on identifying users, their problem, and the custom features that will address this problem. Refer to the project proposal for details.

Exceptions

You are not allowed to deviate from the Standard Requirements without explicit, written permission from the instructor.

Requesting an exception

If you wish to deviate for any reason, (a) discuss with the instructor first, and (b) if informally approved, email them for a formal, written confirmation of the deviation, and finally (c) include that confirmation email in your project documentation.

Deviating without written permission will result in a significant penalty to your grade.