Planning a Complete Production App From Scratch
One of the biggest things that gets overlooked whenever people start a project is planning. I have noticed this on individual projects, as well as in the corporate environment. On individual projects, there might not be any planning at all, while in corporations there might just not be enough. So here I will give the minimal planning that I do for every flutter project that I start, but a similar planning method can be applied to any other OOP language. We’re going to go over figuring out your Use Cases (Features), Diagrams, and Folder Structure.
Use Cases
First things first, you need to figure out what the actual app is going to be, and what it is going to do. Without knowing that there can be no planning. I like to sketch out all the app screens that there will be, and think about how I would use it, and what features it will have. Then create a list of every single thing you want the app to accomplish. Not how you are going to accomplish it, but just the “what” it will accomplish. Let’s take any app that a user needs to log in, this use case should say what method they will use to log in (Email & Password, Google Log In, Fingerprint, etc). It should mention whether they will need to login every time they open the app. So one example for a Use Case here would be “User needs to login using email and password every time they open the app”. Now you need to go through the whole app, and make sure you write these down somewhere, and you can use it as a checklist of what needs to be accomplished when you’re writing the app.
Now if you’re working with a bigger team this is the part where I would go even deeper. Each one of those Use Cases should have a list of requirements. These requirements should dive deeper into what each Use Case is saying to do, and give technical “requirements” for what the software should do. From our previous example you need requirements for things like how many log in attempts they have, what errors to return if email doesn’t exist, what errors to return if password doesn’t match, etc.
