To get started with our design, we are tasked with generating a requirements list of desired behaviors and critical non-functional requirements. From the rough outline of features in the preceding section, we are able to generate a functional requirements list shown below in Table B-1:
| Identifier | Requirement/Description |
|---|---|
| FR-1 | Application must allow users to generate unique user profiles |
| FR-2 | Application must retain recipes within the datastores |
| FR-3 | Application must call recipes and present to the user when requested |
| FR-4 | Application must allow filtering of recipes based upon pre-defined criteria |
| FR-5 | Application must store and build internal associations for video recipes |
| FR-6 | Application must allow for and retain user feedback on recipes |
| FR-7 | Application must allow for each recipe to be user rated and retain that rating |
| FR-8 | Application must be available for iOS (API 13+) and Android (API 23+) |
| FR-9 | Application must implement a service that allows for in-app payment |
| FR-10 | Application must implement location services microservice for grocer locating |
| FR-11 | Application must implement a shopping cart microservice that links to local grocers |
| FR-12 | Application must allow users to search recipes for keywords |
| FR-13 | Application must be accessible by commonly used internet browsers |
Table B-1. Functional requirements for the Chef It! application.
While these features define the basic behavior of the application, they do not paint the entire picture of the system. The non-functional requirements below in Table B-2 will define the targeted user experience of the application.
| Identifier | Requirement/Description |
|---|---|
| NFR-1 | Application must retain user information in a secure fashion |
| NFR-2 | Application must have high availability (>99.999%) |
| NFR-3 | Application must be able to support a high number of connections |
| NFR-4 | Application must be able to reliably transport customer data |
| NFR-5 | Application must have low latency even under heavy load |
| NFR-6 | Application must be computationally efficient |
| NFR-7 | Application must be easy to navigate for non-tech users |
Table B-2. Non-Functional requirements for the Chef It! application.
These requirements will be referenced by their identifier when necessary to further provide implementation detail.
Table B-3 (below) contains a list of the critical design choices in our application. Each design component is given a unique identifier and description.
| Design Component Identifier | Component | Description |
|---|---|---|
| DC-1 | Content Discovery | Process of interfacing between Client and Backend to retrieve and display information and return information to the Backend |
| DC-2 | Load Balancer | Cloud service to route traffic for reliability and efficiency |
| DC-3 | Chef-It! Control Plane | Provides client location data and manages digital interfaces with grocers |
| DC-4 | Datastores | Distributed database to house application information |
| DC-5 | Business Logic Microservices | Loosely coupled subprocesses that perform operational tasks |
| DC-6 | API Gateway Service | API management system that resides between the Client and Backend |
| DC-7 | Application API | A collection of APIs that handle common application tasks |
| DC-8 | Computing Instances | Cloud-sourced distributed processing power |
| DC-9 | Processing Pipeline (Event-Driven Architecture) | Data acquisition and refinement process needed to sustain microservices |
Table B-3. Design Component Matrix describing the components of our high-level design.
The Traceability Matrix below, in Table B-4, relates the Chef-It! functional and non-functional requirements to the design component that enables us to achieve said requirement. Some requirements are not explicity addressed by our primary design components, but are important to include in the lower level design process. These instances are given a "Design ID" of "Sys Req".
| Requirement Type | Requirement ID | Design ID(s) |
|---|---|---|
| Functional | FR-1 | DC-1, 3, 5, 7, 9 |
| Functional | FR-2 | DC-4 |
| Functional | FR-3 | DC-1, 4, 5, 6, 7 |
| Functional | FR-4 | DC-1, 5, 7 |
| Functional | FR-5 | DC-4, 9 |
| Functional | FR-6 | DC-4, 5, 6, 7 |
| Functional | FR-7 | DC-1, 5, 6, 7 |
| Functional | FR-8 | Sys Req |
| Functional | FR-8 | Sys Req |
| Functional | FR-9 | DC-5, 6, 7 |
| Functional | FR-10 | DC-3, 4, 5 |
| Functional | FR-11 | DC-1, 3, 5 |
| Functional | FR-12 | DC-1, 4, 7 |
| Functional | FR-13 | Sys Req |
| Non-Functional | NFR-1 | DC-1, 5, 6, 7 |
| Non-Functional | NFR-2 | DC-5, 8, 9 |
| Non-Functional | NFR-3 | DC-2 |
| Non-Functional | NFR-4 | DC-4, 5 |
| Non-Functional | NFR-5 | DC-2, 6, 7, 8, 9 |
| Non-Functional | NFR-6 | DC-6 |
| Non-Functional | NFR-7 | Sys Req |
Table B-4. Traceability Matrix describing the relationships between requirements and components in our high-level design. “Sys Req” refers to defined system requirements that are needed regardless of components.