When building any project, there are a set of standard recommended steps:
Each of these is covered in more detail below:
It is always best to start with the basic purpose, operations and actions required for the new system, whether these are as formal use cases, user stories, requirements, mocked up screen flows or otherwise is really up to the level of documentation desired and the approach you wish take. However do not skimp on this, as thinking it through is usually invaluable in the longer term.
Once you have an understand of what you wish the system to do, use this to consider what data items (known as entities) of data you need (e.g. for a support system, users will create a ticket, which therefore is one of the core data entities. There are usually relationships between them, these should all be roughly mapped out.
Order features that required into those which are dependent on each other, and those that will give you initial quick win's. It is generally that case as the system crystalizes into a working system, and users start using it, they think of many more features, each of these should be prioritised into the main list - this list in Agile speak is what is called the backlog.
Thrashing out the rough structure of the data and creating the respective tables is the next phase.
As general rules:
Either an external database can be created, or may already exist, in which case the connection details will be needed (ask your Database Administrator), and a new “Data Source” created within your user space. At present, Data Sources are globally accessible to all projects within the users space.
If an external database is not required (often the case), then the tables should be created within the “Data Tables” area of your user space. At present, Data Tables are globally accessible to all projects within the users space.
The initial screens should now be constructed, with data collection being linked to their respective data tables. There is a separate tutorial for this here.
Working down your backlog, you should then add features as required, building processes for each feature. It is generally good practice to categorise the processes into groups (make finding and this maintenance much easier in the future).
The features up to the current point should be tested, the system does not need to be "finished" at this point, just good enough to do something worth while. Any issues and ideas can be raised, prioritised and put back into the backlog, more features are added, system tested etc. This iterative approach is one of the core principles of Agile development, an approach we greatly recommend.
Once the system is sufficient to be released to real users for real data, there are some final steps that should be completed (some of which have there own tutorials)