I always do the following:
Take pen and paper or the digital equivalent
I prefer doing both first on paper because its faster , then on draw.io for documentation for the customer.
Get a quick overview
Draw the 30 000 feet perspective of the application, what should the app do and in which order here is the short check list I do, Do not go into details as this list will change a lot during the process. draw a simple diagram based on input. This will most likely change.
- platform(s)?
- online offline use cases is data needed to be persisted somewhere ?
- technology requirement (sometimes you have to use Java, somewhere)
- What degree of user control is needed(user admin panel etc)?
- Any security issues
- Need/have a database ?
- Need file Storage(local and cloud) ?
- What kind of internal and external dependencies ( like it needs to communicate with sharepoint or fancy microsevice ABC)
- what is the minimum this thing needs to do
- How many users/connections directly/inderectly expected (users can be devices for IoT as well)
- How much data expected (rough estimate that you will calculate as you go)
- What data should be logged if any
- what is this going to do when all done (draw up view/screens on a separate paper to)
Now you should have a rough system overview and a GUI overview that will most likely change as we go.
Describe the user interface in a wireframe
reference the GUI overview and do the following for each screen.
I take an A4 paper and split it two by drawing a line. and draw the first screen on the left hand side. For every bit of logic on the screen; name it and put it in a list on the right hand side. You should never run out of space on the right hand side. if you do, most likely the View needs to be redesigned or you should not write so explicitly what you are doing.
Do this for all the screens.
Describe the logic
From your first view start at the top of the list and se how to best implement the desired functionality.
take each functionality and split it up on its own sheet try to make groups as in Data storage/GUI/Calculations/External resource etc. and get a rough overview of what can be reused or grouped together.
Put it together
By now you should have a rough overview of everything the application should do. draw a diagram over the entire system or update the first overview you made. most likely there are new views and more blocks in the functionality overview. I tend to redo the entire thing as its just as fast.
Segregate the view Depending on the questions asked you should have a good overview over what goes where.
This is not Agile development and its not waterfall production but a healthy combination of the two I have been using this methodology for almost 20 years small and large projects.(from small services and web pages to enterprise apps with 7 million users and heavy data loads)
just to clarify its not waterfall because you should update as you go and the real world problems present them selves (there is always something)
and its not agile because you will spend a lot of time planning in the beginning.
But !
You have documented the entire process for the customer , given accurate pricing and most likely are delivering on time because you have sorted things out.
Finally , the end of this post.
The architecture will become evident while asking the questions and starting with the views. As a rule of thumb I tend to segregate as much as possible, try to keep dependencies as low as i can. and use the right language for the job.
If I were to talk pure architecture I would need specifics of your projects since there are more ways than one to do things.
However with the right approach to starting something the architecture usually reveals itself automatically.
Also I will rewrite this as a blogpost if someone is interested in me elaborating on details I did not mention that you should also put estimated cost and time in order to really blow your customer away with your professionalism.
I hope something in my ramblings are of use to you.
