Shopping list and recipe app development plan

 So this is going to be the first of a series of posts that are going to follow along developing a desktop application (mostly cause I don't have an IDE in which I can create a mobile app) that will store recipes, allow the user to make meal plans, and then based on those meal plans create shopping lists for all the ingredients.

The overall plan is going to include:'

• Defining the requirements that the software has to fulfill from a user perspective.  This would be the functionality that the user expects the software to perform.
• Defining the technical approach that is going to be used to fulfill the user's requirements defined in the previous bullet.
• Create a test script to be used to ensure that the software is functioning adequately.  Each of the tests will check that one or more of the requirements have been fulfilled.
• Perform the testing and then do any required remediation to correct any discovered test failures.
• At this point, I may end up discussing what additional or changed user requirements could be used for the next version of the software.  But let's not get ahead of myself.

So what are the user requirements?  While I'd like to use a table here, I'd have to create it by writing raw HTML as the blog's UI isn't accommodating of tables so you will have to bear with me as I present it as a numbered list.  While the numbered list will not allow me to, within the list, add a prefix, for any cross-references, pretend that Recipe requirements are prefixed with an R, Ingredient requirements are prefixed with an I, Meal Plan requirements are prefixed with an M, Shopping list requirements are prefixed with an S, and general requirements with a G.

Recipe module

1. The user will enter for each recipe:
1. A title
2. A category for the recipe
3. The number of servings the recipe makes
4. One or more ingredients
5. One or more cooking steps
2. Recipe categories can be created, edited, and deleted.
3. Recipe categories will be pre-populated with:
1. Entrée
2. Side
3. Appetizer
4. Dessert
5. Snack
4. Do not allow Recipe Category to be deleted if it is used in an existing dish.  Advise the user of at least one recipe title that they need to address if they try to delete in this case.
5. For each ingredient, the user will specify:
1. Quantity to be used
2. Unit of Measurement of consumption quantity
6. For each cooking step, the user will specify:
1. Step number
2. Text of the step instructions
7. Recipes can be exported.
8. Recipes can be imported.

Ingredient Module

1. For each ingredient, the user will enter:
1. Ingredient name
2. Purchase Quantity
3. Purchase Unit of measurement
4. Zero or more unit of measurement conversions
2. Ingredients can be exported.
3. Ingredients can be imported.
4. Ingredients can be created, edited, and deleted.
5. Ingredients cannot be deleted if they are used in a Recipe.

Meal Plan Module

1. The user can populate the meal plan module with a meal record consisting of:
1. A Recipe
2. The number of people dining
3. The date of the planned meal
2. An export can be created for a date range showing all the meals planned within that date range.  The export will be a table modeled to simulate a calendar.  Also a multi-level list format will be available.
3. Meal records can be created, edited, and deleted.

Shopping list Module

1. The user can create a shopping list for a user-selected date range.  This will produce a shopping list for all the ingredients that will be consumed in the preparation of all the meals in the selected date range for the indicated number of diners and indicate to the next whole purchase Unit of measurement.

General requirements

1. The user can create different databases.
2. The user can open a specific database.
3. There are no security requirements.

In writing this, I've had some thoughts already about other behaviours I'd like the program to have, but I think this is already enough to get on with.  The next post, hopefully within the coming week will discuss the technical approach I will take to providing the functionality defined above.