Introduction

This document describes the software quality requirements for the Mall on Rails project. Unless otherwise noted, all requirements specified in this document are of high priority and required to be implemented for the version of MoR presently in development.

Intended Audience

This document is intended to be used by developers and other stakeholders for the implementation of Mall on Rails. This document may also be used by other interested parties, including store owners interested in using the Mall on Rails platform, current or prospective clients, or the greater open-source community, to learn more about the development and implementation of MoR.

Where's the SRS?

Traditionally, WTI projects have a Software Requirements Specification, which contain a section on Software Quality Attributes, typically in a chapter titled "Non-functional Requirements".

The MoR project is being developed in a "full Agile" methodology, for several reasons.

Firstly, and most importantly, most of the requirements for Mall on Rails centre around L-CRUD functionality on collections, items, and orders. There would be many similar, duplicative requirements written to cover functionality that is obvious to anyone developing the system.

Secondly, there was a strong desire to prototype the system during development to facilitate the addition and removal of features during discussion. By avoiding the front-loading work of defining requirements, we were able to ship a more refined and leaner product.

Requirements are therefore derived solely from the User Stories and Jira work items. There is no formal SRS. However, we do desire the ability to define formal quality attributes that we intend to develop the software against.

This has led us to write this SQS. It captures the various requirements we have that cannot be captured solely in user stories and Jira.

Preface

This document contains preliminary information about a forthcoming software product from Wilcox Technologies Inc.

The information contained within may not reflect the final product, and may change rapidly during the development process.

Always ensure you have the latest document revision before raising an issue.

Abstract

This document describes the quality specification of Mall on Rails, a software project being developed by Wilcox Technologies Inc.

Performance Requirements

The Performance requirements describe the desired performance characteristics of the Mall on Rails system.

Definitions

Page render

Page render is defined as all layout, visual, and text elements displayed fully, including placeholders, but not necessarily item image assets.

Goals

1. To ensure customer satisfaction and high SEO ranking with fast performance.
2. To allow store owners to maxnage their store expediently.

Exclusions

Requirements

Page Display

Order Confirmation Email

Creating an Item

Signing In (Customer)

Security Attributes Overview

This section defines the quality attributes that are most relevant to the security dimension of the software.

Availability

We define "Available" as the Web site being online and accepting requests. This implies that the application server, cache server, database server, and job server are all running.

The Availability requirements define our availability targets, downtime handling and reporting, scheduled maintenance windows, and other relevant requirements.

Confidentiality

The Confidentiality requirements define our intent to keep both customer and administrator PII safeguarded from unauthorised disclosure. Additionally, this section covers constraints from GDPR, CCA, and other regulations.

Integrity

The Integrity requirements define anti-malware and identity verification requirements, and how the system will ensure data contained within stays consistent.

Observability

The Observability requirements define how the system will report events to external systems, and track both security- and performance-critical data.

Availability Requirements

The Availability requirements define our availability targets, downtime handling and reporting, scheduled maintenance windows, and other relevant requirements.

Definitions

Available

We define "Available" as the Web site being online and accepting requests. This requires that the application server, cache server, database server, and job server are all running. This requires the network connection between all the components to be functional. This requires the network connection between the application server's access point and the wider Internet to be functional.

Degraded Availability

We define "Degraded Availability" to be an instance where the system is available for processing requests, but with a violation of performance requirements or characteristics. For instance, if a network issue was causing requests to process much slower than usual, but requests were still being processed otherwise normally, this would be Degraded Availability.

Goals

1. To facilitate commerce by being as highly available as possible within the constraints of our present resources.
2. To communicate both planned and unplanned instances of downtime effectively to all concerned parties.

Exclusions

1. The system handling WTI email is not included in MoR availability planning. If the email system is down, but all components of MoR are running, the system shall still be considered available.

Requirements

1. The system shall be available for at least 99.9% of each month.
2. The system shall have at least degraded availability for 99.99% of each month.
3. The system may be down for maintenance on Wednesday evenings, 18:00 through 20:00 inclusive, in the prevailing time zone controlling the territory of Oklahoma (typically "Central Time"). This maintenance window shall not affect the calculation of system availability. If the system is unavailable during this window, the availability percentage shall not be reduced.
4. The system shall be monitored by an external service for availability.
5. Any instance of planned maintenance, degraded availability, or general unavailability shall be announced in a centralised location which is accessible to the public.
   1. The announcement must include an estimated time of resolution.
   2. When the system returns to full availability, a further announcement shall be posted noting the system has been restored.
6. The system shall provide an option to store owners to protect from AI bot crawlers using the Anubis system. This requirement is of low priority for the initial release of MoR.

Confidentiality Requirements

The Confidentiality requirements define our intent to keep both customer and administrator PII safeguarded from unauthorised disclosure. Additionally, this section covers constraints from GDPR, CCA, and other regulations.

Definitions

Customer Personally Identifiable Information ("PII")

PII is defined as the customer's name, address(es), and phone number(s), and email address(es).

Goals

1. To ensure that all authentication information is kept secure from all parties other than that it belongs to.
2. To ensure that all order information is kept secure from all parties other than the store owner and the customer who performed the order.
3. To ensure that all collected information from customers is stored in a manner compliant with all identified regulations, and is easy to manage for privacy and compliance tasks.
4. To ensure that all network traffic is encrypted using high strength encryption to protect all MoR data in transit.
5. To ensure that all stored data is encrypted at rest to protect against physical intrusion attacks.

Exclusions

1. Email sent to external services may not be possible to encrypt due to the nature of the SMTP protocol. It is considered an acceptable risk to have order information sent via email to the customer.

Requirements

1. The system shall ensure all HTTP traffic is encrypted with TLS 1.3, or a later version of TLS, using the ciphers and protocols listed in the "Modern" configuration of the Mozilla SSL Configuration Generator.
   1. The team shall, no less than once per quarter, ensure that the system is still in full compliance with the "Modern" configuration guidance. This includes adding or removing any ciphers or protocols necessary.
2. The system shall store customer authentication information using the Blake2a encryption standard, with a minimum cost of at least 15.
3. The system shall authenticate store owners against the WTI SSO infrastructure using the SAML standard, over HTTPS only, with strict certificate checking.
4. The system shall allow order information to be retrieved by a customer only if the requester is authenticated as the customer who originally placed the order.
   1. The system shall consider an order placed by a signed-in customer as being authenticated if the same account is presently signed in.
   2. The system shall consider an order placed by a signed-out customer as being authenticated if the order ID and email address used are both provided.
5. The system shall store all database content on an encrypted volume.
6. The system shall allow an authenticated customer to remove their personally identifying information ("PII") from the system.
   1. If the customer is authenticated to a valid account, the system shall replace all PII with appropriate placeholders.
   2. If the customer does not have an account, a confirmation email shall be sent. The customer shall be prompted to input the code from the email to confirm account deletion.
   3. If the customer does not have an account, and cannot receive the confirmation email, then the system shall allow them to remove all PII except their email address. This is to ensure that a malicious actor cannot preempt the ability of a guest customer to view their order history.
7. The system shall allow a store owner to remove a customer's PII on behalf of the customer. The system shall allow the store owner to additionally remove the customer's email address, with the warning/caveat that the customer will no longer be able to access their order history.
8. Upon either the customer or store owner removing a customer's PII, the system shall perform all the following actions:
   1. Send an email to the customer that their PII has been removed. This step must occur before the removal of the email address, if the store owner has chosen to remove the customer's email address as well.
   2. Send an email to the store owner that the customer has had their PII removed, and any external CRM and stored email will need to be scrubbed to ensure full compliance.
9. The system shall attempt to send email to external systems via TLS before falling back to plaintext SMTP.
10. The system shall ensure that adequate security headers are present on all responses, including:
    1. Strict-Transport-Security (HSTS).
    2. Content-Security-Policy (CSP).
    3. X-Content-Type-Options.
    4. X-Frame-Options.

Integrity Requirements

The Integrity requirements define anti-malware and identity verification requirements, and how the system will ensure data contained within stays consistent.

Definitions

Goals

1. To prevent unauthorised access to the system.
2. To protect the system, store owners, and customers from malware.
3. To enshrine the privacy and safety of data entered.
4. To verify the identity of the entity performing an action before allowing the action to proceed.

Exclusions

1. HTML entered by the store owner for page content is assumed to be safe.

Requirements

1. The system shall require any administrative action to require a valid login session from a store owner.
2. The system shall automatically expire a store owner login session after seven days, to prevent session reuse attacks.
3. The system shall allow a store owner to sign out of a login session at any time, upon which no further administrative action can take place until the store owner signs in again.
4. The system shall allow a store owner to manage any authentication token(s) or external device sign ins from a centralised page.
5. The system shall scan all files uploaded by the store owner for malware.
   1. If the system detects malware, the system shall perform the following actions:
      1. The system shall remove the file containing malware from storage.
      2. The system shall notify the store owner that the file contained malware and that it could not be uploaded.
      3. The system shall write a log message with all of the following information:
         1. The remote IP of the computer where the upload originated.
         2. The logged in store owner account that attempted the upload.
         3. All request headers of the request containing the malware.
      4. The system shall put the store into maintenance mode until an administrator with WTI can review the store and the account.
6. The system shall allow a customer to sign up for an account to track their order history and optionally receive offers via email.
   1. The system shall send a confirmation email to the email provided to ensure the customer has control of the email address they provided.
   2. The system shall consider the email address already authenticated if the customer authenticates using an external service.
   3. If the system identifies previous orders under the same email address, the system shall associate them with the account after the email address has been confirmed.
7. Upon the request for deletion of customer PII from a customer or store owner, the system shall replace the PII with placeholder data. The existing data must not be able to be recreated using this placeholder data. The account must be disabled in a way that does not allow further logins. The account must not be removed from the database to preserve referential integrity in the database.
8. The system shall not allow items that have been previously purchased to be removed. The system shall instead offer to hide them.
9. The system shall not allow collections that contain items to be removed. The system shall instead offer to hide them.
10. The system shall not allow shipping services that are associated with an order to be removed. The system shall instead offer to hide them.
11. All data stored by the system in any database system shall be stored in a manner that prevents access to the data by unauthorised parties. This shall include, but is not limited to:
    1. The data shall be encrypted at rest to prevent tampering and unauthorised access.
    2. The data shall be encrypted at all points in transit.
    3. The data shall be stored in a volume that is inaccessible to any other container-based workloads on the system.
    4. The data shall be backed up no less often than once per week, and the contents of the backup shall be encrypted in a manner that allows only authorised WTI administration to read and restore it.
12. All pages that contain store owner-controlled HTML stanzas shall be scanned no less often than once per week for malicious links, code, iframes, images, and other data that may cause any harm to a visitor or another storefront.
    1. If malicious data is found, the system shall immediately be placed in maintenance mode until an administrator with WTI can review the store and the account.
13. All changes made to the store data shall be logged to an Audit Log with at least the following properties:
    1. The logged in store owner account that made the change.
    2. The remote IP of the computer that initiated the change.
    3. The properties that were changed, including old and new values.
14. The Audit Log shall be stored in a manner that it cannot be tampered with, modified, or read by a store owner or customer. The Audit Log shall only be readable by authorised administrators with WTI.

Observability Requirements

The Observability requirements define how the system will report events to external systems, and track both security- and performance-critical data.

Definitions

Common WTI log requirements

The enterprise-wide logging requirements for HTTP-connected systems as defined in the Wilcox Technologies Inc. Network Handbook, 4th Edition.

Runtime error

An error condition that raises an exception that is not handled, or a condition that is caught but is still determined by the implementation team to deem a log message necessary. These conditions will be determined as features are developed and implemented.

Goals

1. To accurately report events that occur in the Mall on Rails system.
2. To be able to gain insights into how to maintain Mall on Rails in the most efficient and error-free manner.
3. To have sufficient actionable evidence in the event of potential or actual breaches of security to effectuate recovery and prosecution.

Exclusions

1. The system shall not cause any customer PII to be written to logs that are not explicitly managed for PII. This includes payment information, name, password, address(es), and phone number(s). As email addresses are a type of login information, these may be required to be logged for the purposes of intrusion detection and authentication.

Requirements

1. The system shall log all incoming HTTP requests using the common WTI log requirements, including IP anonymisation after 30 days.
2. The system shall log all runtime errors to an external reporting system.
3. The system shall log client runtime errors to an external reporting system.
4. The system shall write a log message when storage is at 90% and 95% full.
5. The system shall emit an alert when storage is at 98% and 100% full.
6. The system shall write a log message for any attempted customer login, including all of the following information:
   1. The remote IP of the computer where the login attempt originated.
   2. The email address of the account attempting to be logged in.
   3. Whether the login attempt was successful or failed.
   4. All request headers (including User-agent, Referer, and X-Forwarded-For).
7. The system shall write a log message for any attempted store owner login, including all of the following information:
   1. The remote IP of the computer where the login attempt originated.
   2. The login name (whether username, email, or other) that was attempted.
   3. Whether the login attempt was successful or failed.
   4. All request headers (including User-agent, Referer, and X-Forwarded-For).

User Attributes Overview

This section defines the quality attributes that are most relevant to the users of the software - both store owners and their customers.

Accessibility

The Accessibility requirements are pulled out of the Usability requirements to explicitly define how the software will handle users with disabilities. This includes screen readers, limited motion, colour-blindness, and others.

Interoperability

The Interoperability requirements define the ways in which Mall on Rails works with other systems to deliver the user a seamless experience with the other systems they work with regularly.

Robustness

The Robustness requirements define how the system is intended to ensure data is handled in a fault-tolerant way, and the methods in which the system should handle invalid or corrupted data. Additionally, this section covers how the system should handle fault conditions such as disk full and network outages.

Usability

The Usability requirements define how the system will ensure that users are able to complete tasks in a consistent and approachable manner.

Accessibility Requirements

The Accessibility requirements are pulled out of the Usability requirements to explicitly define how the software will handle users with disabilities. This includes screen readers, limited motion, colour-blindness, and others.

Definitions

ARIA standard

The W3C WAI-ARIA standard is available on the W3C work group's official ARIA page.

Goals

1. To ensure the Mall on Rails system can be used by customers and store owners with disabilities relating to vision and motor skills.

Exclusions

1. Custom colours, when available, may affect contrast requirements.

Requirements

1. All pages in the system shall be compliant with W3C ARIA standard.
2. The system shall be accessible without JavaScript enabled on the user agent.
3. All pages in the system shall be tested in light mode and dark mode. Proper contrast, defined as 5:1, shall be shown for all elements in both light mode and dark mode.
4. All pages in the system shall be tested with a screen reader. Pages must be understandable and navigateable using a screen reader.
5. Elements and buttons on pages shall have text and not be differentiated solely by colour.

Interoperability Requirements

The Interoperability requirements define the ways in which Mall on Rails works with other systems to deliver the user a seamless experience with the other systems they work with regularly.

Definitions

The Schema.org specification

The Schema.org specification defines structured data schemas for use on Web pages. The Product specification is especially important to the Mall on Rails project and can be read online.

Goals

1. To allow customers of storefronts utilising the Mall on Rails system to save time and effort when purchasing items from the store.
2. To allow store owners utilising the Mall on Rails system to integrate their existing business processes and systems into their storefront.

Exclusions

1. The system shall not allow store owners to use their owner account as a customer account.
2. The system shall not integrate with the social network platform formerly known as Twitter.

Requirements

1. The system shall allow customers to sign in using an external authentication service in lieu of registering a new account.
   1. The system shall not allow multiple accounts to exist with the same email address.
   2. The system shall support the following external authentication services:
      1. Apple ID (Sign In with Apple).
      2. Facebook.
      3. Google.
      4. Microsoft (This requirement has low priority for the initial release.)
   3. The system shall authenticate with the external service to ensure the email address provided is accurate and owned by the user.
2. The system shall require store owners to sign in using the WTI SSO service.
   1. Each storefront shall have its own SSO group, and the system shall be configured to only allow store owners from the specified store group to authenticate.
3. The system shall process customer payments via the customer's choice of method, based on the payment integration systems configured in the store.
4. The system shall allow store owners to configure payment integration details for at least the following systems:
   1. Stripe.
   2. PayPal.
   3. Square. (This requirement has low priority for the initial release.)
5. The system shall support bidirectional synchronisation of inventory with external inventory systems: (This requirement has low priority for the initial release.)
   1. Square POS.
   2. Auctions+.
6. The system shall support sharing of items to Pinterest, including tracking pins via an existing pin ID set on the item by the store owner.
7. The system shall provide Open Graph tags on all pages, including detailed product information as specified in the Schema.org specification.
8. The system shall support sharing of items to Facebook, using the same Facebook App ID provided by the store owner to enable Sign In with Facebook.
9. The system shall support generating tracking links for shipments sent via these carriers:
   1. United States Postal Service (USPS).
   2. FedEx.
   3. UPS.
10. The system shall support retrieving delivery status when provided a tracking number from one of the carriers listed in Interoperability-9.
11. The system shall refresh the delivery status of provided tracking numbers every hour during business hours, which are defined at 7 AM to 9 PM Eastern.
12. The system shall send a notification to the customer when their package has been marked delivered by the carrier.

Robustness Requirements

The Robustness requirements define how the system is intended to ensure data is handled in a fault-tolerant way, and the methods in which the system should handle invalid or corrupted data. Additionally, this section covers how the system should handle fault conditions such as disk full and network outages.

Definitions

Goals

1. To ensure the Mall on Rails system provides a reliable ecommerce platform.
2. To alert administrators if a failure condition has occurred.

Exclusions

1. The system may not be able to detect all forms of sign in providers being unavailable. If the sign in provider displays their own error message, this is acceptable for the fulfilment of Robustness-4.

Requirements

1. When the store owner submits a form containing invalid input (number out of range, string too long, or other similar error), the system shall perform all of the following tasks:
   1. Re-display the form page.
   2. Highlight the field(s) that contain an error.
   3. Display a message describing the error(s).
   4. Leave all valid fields as they were when the form was submitted.
2. The system shall be written to ensure no ORM methods are called in a way that could allow for SQL injection attacks via user-provided or user-controlled input fields.
3. The system shall display an error message if the store owner attempts to upload a photo if their store has no remaining storage space.
4. If a sign in provider is unavailable, the system shall display an error message and suggest that the user try again later.
5. If a payment processor is unavailable, the system shall perform all of the following tasks:
   1. Display an error message notifying the customer that the payment processor is experiencing technical difficulties, and that their bag has been saved and that administrators have been notified.
   2. Log an error including all of the following information:
      1. The response received by the payment processor, or the system error encountered when attempting to connect to the payment processor.
      2. The Bag ID that was being sent to the payment processor.
      3. The date and time of the request.
      4. The remote IP of the customer computer that attempted to check out.

Usability Requirements

The Usability requirements define how the system will ensure that users are able to complete tasks in a consistent and approachable manner.

Definitions

Action button

A button or link to browse to a page that would allow a store owner to perform an action on an object. For example, "Create New Item", or "Edit Shipment".

Goals

1. To ensure that the Mall on Rails system is simple and efficient to learn.
2. To reduce support cost and burden.
3. To provide store owners the ability to feel confident in their ability to manage their store.

Exclusions

1. Custom colours, when implemented, may override some contrast requirements.

Requirements

1. Admin Dashboard pages shall be structured to have similar locations for common elements. For example, all details pages shall have an Actions heading at the bottom with further actions to be performed on the object.
2. All action buttons shall have defined wording and colouring to make them immediately understandable.
3. All Admin Dashboard pages shall have a help icon which links to the relevant page in the Handbook describing the page and the actions available to the store owner.

Developer Attributes Overview

This section defines the quality attributes that are most relevant to the development and administration teams caring for the software.

Efficiency

The Efficiency requirements define the constraints on the system regarding resource utilisation: disk, CPU, RAM, network, and other similar resources. Additionally, this section defines how the system should behave under load and during periods of traffic spikes (whether organic or attack in nature).

Flexibility

The Flexibility requirements define parts of the system that are the most likely to require ongoing changes or augmentation, and ways in which the system can best be amenable to these forthcoming changes.

Maintainability

The Maintainability requirements define ways in which we intend the system to be as simple as possible to administer and maintain, both from a systems administrator role and a developer role.

Portability

The Portability requirements define the platforms where the system is expected to run on and function properly.

Efficiency Requirements

The Efficiency requirements define the constraints on the system regarding resource utilisation: disk, CPU, RAM, network, and other similar resources. Additionally, this section defines how the system should behave under load and during periods of traffic spikes (whether organic or attack in nature).

Definitions

CPU core

CPU core utilisation is dependent on many factors, such as architecture, microarchitecture, cache size and utilisation, shared workload, and more. We intend to measure CPU core utilisation by using the docker ps utility on our staging application server.

Normal conditions

We define "normal conditions" as one request per second, which is just over 2.5 M monthly requests.

Peak load

We define "peak load" as one hundred (100) requests per second.

"The system"

For the purposes of CPU and RAM resource consumption, we define the system as being the container running Ruby application code (Rails and Sidekiq) and the container running Redis. We do not include the database container (Postgres) in CPU and RAM resource requirements.
For the purposes of disk resource consumption, we define the system as being all containers related to a single MoR instance.
The front-end load balancer is never counted towards resource consumption. If the load balancer becomes a significant factor in scaling, the team have collectively decided we will need to investigate an alternative load balancer.

Goals

1. To ensure that Mall on Rails has reasonable usage limits, even under what is considered a significant load (take only what you need from it).
2. To ensure customers have a pleasant experience shopping with storefronts using the Mall on Rails system by not wasting their time, bandwidth, or data caps on unnecessary overhead.
3. To allow multiple Mall on Rails deployments to live on a single application server, effectuating decent scaling for hosts of multiple storefronts.

Exclusions

1. The system shall not paginate the Collections#index page.

Requirements

1. The system shall utilise a maximum of 512 MB RAM under normal conditions, and 768 MB RAM under peak load.
2. The system shall utilise a maximum of 20% of one CPU core under normal conditions, and 100% of two CPU cores under peak load.
3. The system shall ensure that customer browsers are instructed to cache assets (item photos, collection thumbnails) for a period of seven days.
4. The system shall set generated assets (such as CSS, JavaScript) to have a cache time of at least one year.
   1. We allow this because the Rails asset pipeline changes the filename of generated assets when the contents themselves change. If this were to change in a future release of Rails, this requirement will need to be re-evaluated.
5. The system shall process all photo assets uploaded by the store owner into the JPEG format. The files shall be stored with a quality level of 80, and a maximum resolution of 2000x2000 pixels.
6. The system shall paginate the Collections#show page with a count of 20 items per page.
7. The system shall paginate admin collection and item indexes with a count of either 15, 30, 45, or 60 items, with a user-settable default of 15.

Flexibility Requirements

The Flexibility requirements define parts of the system that are the most likely to require ongoing changes or augmentation, and ways in which the system can best be amenable to these forthcoming changes.

Definitions

Active Setting

The settings system that presently lives in the repository under the lib/active_setting directory.

Payment Processor Integration

The module of the Mall on Rails system that integrates order and checkout with the processor of the payment. For the initial release, this is Stripe.

Goals

1. To ensure that Mall on Rails is able to grow in the way the project champions desire without undue burden on the development team.
2. To allow future expansion of Mall on Rails to new and emerging markets.

Exclusions

No explicit exclusions have been identified for this section.

Requirements

1. An experienced developer with existing knowledge of the system shall be able to add a new payment processor integration with no more than two days of work effort.
   1. Documentation shall be written on how payment processor integration is implemented.
2. The system shall be architected to allow an eventual expansion of the definition of 'item' to include item specific characteristics. For example, a bracelet may have sizing options, or a watch may have band choices.
3. The system shall allow for the eventual split of Active Setting into its own Gem, including independent tests and releases.

Maintainability Requirements

The Maintainability requirements define ways in which we intend the system to be as simple as possible to administer and maintain, both from a systems administrator role and a developer role.

Definitions

User-facing string

A user-facing string is a string that is displayed to either a customer or store owner. This does not include strings in the logging or observability components of the system.

Goals

1. To ensure the Mall on Rails system is as easy as possible to run for systems administrators.
2. To allow continued iteration on features and functionality to make the Mall on Rails system the best ecommerce platform possible.
3. To enter new and emerging markets by supporting different use cases.

Exclusions

1. Model data (items, collections) is not localisable.
2. When the currency code is changed, prices are not automatically updated. The store owner must change the price amounts when changing currency.

Requirements

1. All user-facing strings in the system shall be translatable to multiple languages.
2. The currency code used by the system shall be changeable by a store owner from the administration panel.

Portability Requirements

The Portability requirements define the platforms where the system is expected to run on and function properly.

Definitions

Server software

The server software includes the principal Mall on Rails application server: the Rails backend, and the job server. It does not include the database or caching servers, though it is expected that these systems are already sufficiently portable.

Client software

The client software is the HTML, CSS, and JavaScript that make up the client-side experience of interacting with the Mall on Rails system as both a customer and a store owner.

Minimum viable experience

The customer shall be able to view collections and items, add items to their bag, update the quantities in their bag, remove items from their bag, and check out including facilitating a payment. The customer shall be able to sign in and sign out of an account, and register a new account.
The store owner shall be able to sign in, sign out, and perform basic L-CRUD operations where already defined on the following models: Item, Collection, Order, Shipment, Shipping Method.

Goals

1. To allow Mall on Rails to be deployed in different environments based on administrator and store owner need.
2. To ensure that future developments in the computing space can be leveraged by the Mall on Rails system.

Exclusions

1. The server software will not be explicitly tested on Windows. If support for the Windows Server environment is required at a later time, this exclusion may be revisited.

Requirements

1. The server software shall be written to be reasonably portable to any platform where a Ruby interpreter is available.
2. The server software shall be tested on the following platforms before each formal release is made. No failures shall be present.
   1. Adélie Linux, x86_64.
   2. Adélie Linux, AArch64.
   3. Adélie Linux, PowerPC 64-bit.
   4. Darwin, AArch64.
   5. FreeBSD, x86_64.
   6. FreeBSD, AArch64.
3. The system shall be accessible via both IPv4 and IPv6 protocols, utilising TCP and HTTP/1.1 with TLS 1.3.
4. The client software shall run without layout issues, functionality issues, or JavaScript console errors, on the following browsers:
   1. Safari 15, 16, 17, and 18, on iOS, iPadOS, and the Mac OS.
   2. Chrome 123 and 131 on Windows 11.
   3. Edge 125, 130, and 135 on Windows 11.
   4. Firefox 128 on Windows 11, the Mac OS, and Adélie Linux x86_64.
5. The client software shall provide a minimum viable experience for both customers and store owners on the following browsers:
   1. NetSurf 3.11 on Adélie Linux AArch64.
   2. Safari 18 on the Mac OS with JavaScript disabled.
   3. Firefox 128 on the Mac OS with Ghostery, Noscript, and uBlock Origin extensions enabled.