From 85cdbc99e55d847ef76405dbc752d8087e1b2db5 Mon Sep 17 00:00:00 2001 From: mnguye49 Date: Sun, 26 Mar 2023 19:45:17 -0400 Subject: [PATCH 1/7] Add files via upload --- SRS.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 SRS.md diff --git a/SRS.md b/SRS.md new file mode 100644 index 00000000..eb0c540a --- /dev/null +++ b/SRS.md @@ -0,0 +1,79 @@ +# Software Requirements Specification Document + +This serves as a template for each projects' Software Requirements Specification (SRS) document. When filling this out, you will be required to create user stories, use cases, requirements, and a glossary of terms relevant to your project. Each group member must contribute to every section, so it is crucial that your group's GitHub repository shows a commit history that reflects the work of each group member. It is highly recommended that you create separate branches for each member, but since this is one single document, you will need to manually merge the branches together. It is also advisable to have multiple working versions of this document (named separately) so that one person can compile the final SRS document from the multiple working versions. Ultimately, how you go about managing this is up to you, but consistent formatting, clear commit messages, and a thorough commit history with contributions from each group member are required. + +Fill the document out following the guidelines listed in each section. Maintain [proper Markdown syntax](https://www.markdownguide.org/basic-syntax/) and be sure that your group has a `main` branch with this document and the entire [template repository codebase](https://github.com/david-gary/onlineStoreTemplate) either forked or downloaded and copied into your group's repository. If you have arranged to use a different codebase as a template, you do not need to have the original template included, but a `main` branch is still required. + +## Group Members + +* [Name](mailto:email@uncc.edu) +* [Name](mmailto:email@uncc.edu) +* [Name](mmailto:email@uncc.edu) +* [Name](mmailto:email@uncc.edu) + +## Revisions + +When a change is made to the document, a new revision should be created. The revision should be added to the table below with all information filled out. + +| Version | Date | Description | Author | Reviewed By | +| --- | --- | --- | --- | --- | +| 1.0 | 03/22/23 | Initial draft | [David Gary](mailto:dgary9@uncc.edu) | [David Gary](mailto:dgary@uncc.edu) | + +## Table of Contents + +1. [Introduction](#introduction) +2. [Requirements](#requirements) +3. [Constraints](#constraints) +4. [Use Cases](#use-cases) +5. [User Stories](#user-stories) +6. [Glossary](#glossary) + +## Introduction + +In this section, you should give a brief overview of what your project will be. Describe the software system you are building and what problems it solves. You should also give a short description of the stakeholders (users of the system) and what their needs are. There is no set formatting requirement, but you should maintain a consistent structure across future sections. Not all members must contribute to this section. + +## Requirements + +Each group member must supply at least three functional requirements for the project. Each requirement should be written in the following format: + +* **ID:** A unique identifier for the requirement. This should be a number that is unique across the entire document (something like REQ-1, REQ-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Description:** A short description of the requirement. This should be a single sentence that describes the requirement. Do not replace the word `Description` with the actual description. Put the description in the space where these instructions are written. Maintain that practice for all future sections. + * **Type:** The type of requirement. Should be either `Functional` or `Non-Functional`. + * **Priority:** The priority of the requirement. This should be a number between 1 and 5, with 1 being the highest priority and 5 being the lowest priority. + * **Rationale:** A short description of why the requirement is important. This should be a single sentence that describes why the requirement is important. + * **Testing:** A short description of how the requirement can be tested. This should be a single sentence that describes how the requirement can be tested. +* **ID:** A unique identifier for the requirement. This should be a number that is unique across the entire document (something like REQ-1, REQ-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Description:** A short description of the requirement. This should be a single sentence that describes the requirement. + * **Type:** The type of requirement. Should be either `Functional` or `Non-Functional`. + * **Priority:** The priority of the requirement. This should be a number between 1 and 5, with 1 being the highest priority and 5 being the lowest priority. + * **Rationale:** A short description of why the requirement is important. This should be a single sentence that describes why the requirement is important. + * **Testing:** A short description of how the requirement can be tested. This should be a single sentence that describes how the requirement can be tested. + +## Constraints + +In this section, you should list any constraints that you have for the project. Each group member must supply at least two constraints. These can be constraints on the project itself, the software system, or the stakeholders. Constraints can be anything that limits the scope of the project. For example, that this project's template code is written using Flask and Python constitutes a constraint on the backend of the project. Constraints can also be things like the required timeline of the project. Be creative. + +## Use Cases + +In this section, you should list use cases for the project. Use cases are a thorough description of how the system will be used. Each group member must supply at least two use cases. Each use case should be written in the following format: + +* **ID:** A unique identifier for the use case. This should be a number that is unique across the entire document (something like UC-1, UC-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Description:** A description of the use case that gives the user a high-level overview of how the system is interacted with. + * **Actors:** A list of the actors that are involved in the use case. Only include the actors that are directly involved. Actors are the people or things that interact with the system. For example, when ordering at a fast food restaurant, one might have the following actors: the customer, the cashier, and the cook. But only the customer and the cashier are directly involved in the use case of ordering food. The cook is not directly involved in the use case of ordering food. + * **Preconditions:** A list of the preconditions for the use case. This should be a list of the preconditions for the use case, which are the conditions that must be met before the use case can be executed. Continuing with the restaurant example, the customer must have money in their wallet and the cashier must be logged in to the system before the use case of ordering food can be executed. + * **Postconditions:** A list of the postconditions for the use case. This should be a list of the postconditions for the use case, which are the conditions that must be met after the use case has been executed. Continuing with the restaurant example, the customer must have their food and the cashier must have the customer's money after the use case of ordering food has been executed. + +## User Stories + +In this section, you should list user stories for the project. User stories are a short description of how a user will be interacting with the system. Each group member must supply at least two user stories. Each user story should be written in the following format: + +* **ID:** A unique identifier for the user story. This should be a number that is unique across the entire document (something like US-1, US-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Type of User:** The type of user that the user story is for. This should be a single word that describes the type of user. For example, a user story for a customer might be `Customer` and a user story for an administrator might be `Admin`. + * **Description:** A description of the user story that gives a narrative from that user's perspective. This can be any length, but it must paint the picture of what the user wants to do, how they intend to do it, why they want to, and what they expect to happen. + +## Glossary + +In this section, you should list any terms that are used in the document that may not be immediately obvious to a naive reader. Each group member must supply at least one term. Each term should be written in the following format: + +* **Term:** The term that is being defined. This should be a single word or phrase that is being defined. + * **Definition:** A definition of the term. This should be a short description of the term that is being defined. This should be a single sentence that describes the term. From 98c0f4223da831b59b29a4dc85f4c59c4f2a136d Mon Sep 17 00:00:00 2001 From: mnguye49 Date: Sun, 26 Mar 2023 19:46:52 -0400 Subject: [PATCH 2/7] Update SRS.md --- SRS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SRS.md b/SRS.md index eb0c540a..8cb0b420 100644 --- a/SRS.md +++ b/SRS.md @@ -6,7 +6,7 @@ Fill the document out following the guidelines listed in each section. Maintain ## Group Members -* [Name](mailto:email@uncc.edu) +* [Thi Nguyen](mailto:mnguye49@uncc.edu) * [Name](mmailto:email@uncc.edu) * [Name](mmailto:email@uncc.edu) * [Name](mmailto:email@uncc.edu) From 76e3835bacac98f54f35f1e745ca9fa02474c6c6 Mon Sep 17 00:00:00 2001 From: tnguy24 <123698938+tnguy24@users.noreply.github.com> Date: Tue, 28 Mar 2023 15:24:05 -0400 Subject: [PATCH 3/7] Update SRS.md --- SRS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SRS.md b/SRS.md index 8cb0b420..8c0638ff 100644 --- a/SRS.md +++ b/SRS.md @@ -7,7 +7,7 @@ Fill the document out following the guidelines listed in each section. Maintain ## Group Members * [Thi Nguyen](mailto:mnguye49@uncc.edu) -* [Name](mmailto:email@uncc.edu) +* [Tan Nguyen](mmailto:tnguy241@uncc.edu) * [Name](mmailto:email@uncc.edu) * [Name](mmailto:email@uncc.edu) From 694703308762f9f84420f8d84e11a1545a6b52df Mon Sep 17 00:00:00 2001 From: tnguy24 <123698938+tnguy24@users.noreply.github.com> Date: Tue, 28 Mar 2023 15:24:43 -0400 Subject: [PATCH 4/7] Update SRS.md --- SRS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SRS.md b/SRS.md index 8c0638ff..042adaeb 100644 --- a/SRS.md +++ b/SRS.md @@ -7,7 +7,7 @@ Fill the document out following the guidelines listed in each section. Maintain ## Group Members * [Thi Nguyen](mailto:mnguye49@uncc.edu) -* [Tan Nguyen](mmailto:tnguy241@uncc.edu) +* [Tan Nguyen](mailto:tnguy241@uncc.edu) * [Name](mmailto:email@uncc.edu) * [Name](mmailto:email@uncc.edu) From 931eb66b647537a4f07427f78385719f7ee3f524 Mon Sep 17 00:00:00 2001 From: mrao11 <123699305+mrao11@users.noreply.github.com> Date: Tue, 28 Mar 2023 15:34:10 -0400 Subject: [PATCH 5/7] Update SRS.md --- SRS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SRS.md b/SRS.md index 042adaeb..5ee19367 100644 --- a/SRS.md +++ b/SRS.md @@ -8,7 +8,7 @@ Fill the document out following the guidelines listed in each section. Maintain * [Thi Nguyen](mailto:mnguye49@uncc.edu) * [Tan Nguyen](mailto:tnguy241@uncc.edu) -* [Name](mmailto:email@uncc.edu) +* [Mina Rao](mmailto:mrao11@uncc.edu) * [Name](mmailto:email@uncc.edu) ## Revisions From ffa21c3e9255bae7ab135e9ee122f7bc5998515b Mon Sep 17 00:00:00 2001 From: mrao11 <123699305+mrao11@users.noreply.github.com> Date: Tue, 28 Mar 2023 15:36:53 -0400 Subject: [PATCH 6/7] Update SRS.md --- SRS.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/SRS.md b/SRS.md index 5ee19367..b6614576 100644 --- a/SRS.md +++ b/SRS.md @@ -8,7 +8,7 @@ Fill the document out following the guidelines listed in each section. Maintain * [Thi Nguyen](mailto:mnguye49@uncc.edu) * [Tan Nguyen](mailto:tnguy241@uncc.edu) -* [Mina Rao](mmailto:mrao11@uncc.edu) +* [Mina Rao](mailto:mrao11@uncc.edu) * [Name](mmailto:email@uncc.edu) ## Revisions @@ -30,7 +30,8 @@ When a change is made to the document, a new revision should be created. The rev ## Introduction -In this section, you should give a brief overview of what your project will be. Describe the software system you are building and what problems it solves. You should also give a short description of the stakeholders (users of the system) and what their needs are. There is no set formatting requirement, but you should maintain a consistent structure across future sections. Not all members must contribute to this section. +In this section, you should give a brief overview of what your project will be. Describe the software system you are building and what problems it solves. You should also give a short description of the stakeholders (users of the system) and what their needs are. There is no set formatting requirement, but you should maintain a consistent structure across future sections. Not all members must contribute to this section. + ## Requirements From a055c507e3a8202031c58bcf82ba37d0a4985912 Mon Sep 17 00:00:00 2001 From: Thi Nguyen Date: Tue, 28 Mar 2023 21:35:43 -0400 Subject: [PATCH 7/7] updated --- SRS.md | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/SRS.md b/SRS.md index b6614576..05af17bf 100644 --- a/SRS.md +++ b/SRS.md @@ -9,7 +9,6 @@ Fill the document out following the guidelines listed in each section. Maintain * [Thi Nguyen](mailto:mnguye49@uncc.edu) * [Tan Nguyen](mailto:tnguy241@uncc.edu) * [Mina Rao](mailto:mrao11@uncc.edu) -* [Name](mmailto:email@uncc.edu) ## Revisions @@ -18,6 +17,8 @@ When a change is made to the document, a new revision should be created. The rev | Version | Date | Description | Author | Reviewed By | | --- | --- | --- | --- | --- | | 1.0 | 03/22/23 | Initial draft | [David Gary](mailto:dgary9@uncc.edu) | [David Gary](mailto:dgary@uncc.edu) | +| 1.0 | 03/28/23 | Worked on intro and requirements | [Thi Nguyen](mailto:mnguye49@uncc.edu) | [Thi Nguyen](mailto:mnguye49@uncc.edu) | +| 1.0 | 03/28/23 | Worked on requirements | [Tan Nguyen](mailto:tnguy241@uncc.edu) | [Tan Nguyen](mailto:tnguy241@uncc.edu) | ## Table of Contents @@ -32,6 +33,7 @@ When a change is made to the document, a new revision should be created. The rev In this section, you should give a brief overview of what your project will be. Describe the software system you are building and what problems it solves. You should also give a short description of the stakeholders (users of the system) and what their needs are. There is no set formatting requirement, but you should maintain a consistent structure across future sections. Not all members must contribute to this section. +Our final project will be a website for a cake business where the customers can order and customise their own cakes that can be delivered to their homes and other locations. Due to the internet evolving, more and more businesses are adding their services onto online platforms in order to expand. In addition, some customers may not have a means of transportation for reasons and may need their goods to be delivered to them. ## Requirements @@ -43,12 +45,30 @@ Each group member must supply at least three functional requirements for the pro * **Priority:** The priority of the requirement. This should be a number between 1 and 5, with 1 being the highest priority and 5 being the lowest priority. * **Rationale:** A short description of why the requirement is important. This should be a single sentence that describes why the requirement is important. * **Testing:** A short description of how the requirement can be tested. This should be a single sentence that describes how the requirement can be tested. -* **ID:** A unique identifier for the requirement. This should be a number that is unique across the entire document (something like REQ-1, REQ-2, etc. but be sure to replace the word `ID` with the unique identifier). - * **Description:** A short description of the requirement. This should be a single sentence that describes the requirement. - * **Type:** The type of requirement. Should be either `Functional` or `Non-Functional`. - * **Priority:** The priority of the requirement. This should be a number between 1 and 5, with 1 being the highest priority and 5 being the lowest priority. - * **Rationale:** A short description of why the requirement is important. This should be a single sentence that describes why the requirement is important. - * **Testing:** A short description of how the requirement can be tested. This should be a single sentence that describes how the requirement can be tested. +* **REQ-1:** A unique identifier for the requirement. This should be a number that is unique across the entire document (something like REQ-1, REQ-2, etc. but be sure to replace the word `ID` with the unique identifier). + * **Description:** The user must be able to place an order. + * **Type:** Functional. + * **Priority:** 1. + * **Rationale:** It is the main service that is to be provided. + * **Testing:** We can place an order to see if it gets registered or goes through. +* **REQ-2:** + * **Description:** The user must be able to customize their order. + * **Type:** Functional. + * **Priority:** 2. + * **Rationale:** The customer gets what they want and to accommodate for any allergies. + * **Testing:** After an order is placed, we can edit any attributes of the cakes. +* **REQ-3:** + * **Description:** The user must be able to create a rewards account if they want and be able to log into and logout of that account securely. + * **Type:** Non-Functional + * **Priority:** 3 + * **Rationale:** This is for user privacy and if an account is made it can provide rewards (such as a discount) to the user for multiple orders. + * **Testing: We create an account for testing purposes and check if we can still log into said account after logging out of it. +* **REQ-4:**. + * **Description:** After placing an order, the user should be able to enter in their payment information (and if it is a delivery order, the address as well) and the website should process it. + * **Type:** Functional + * **Priority:** 1 + * **Rationale:** So that payments can processed properly, the business gets paid for its work, and so that all deliveries arrive at the correct location. + * **Testing:** After placing an order, we should expect for a form to appear asking the user for their information and if any of the required information is missing, the site should not continue with the order until it is filled in. ## Constraints