If both sides decide that they do want to work together on the application's development, applicable documents are signed (usually a Work Order; this step may also include a Confidentiality Agreement). This step also signifies customer's agreement to cover the necessary expenses as defined in the contracts that are signed.
Next, a comprehensive document is put together that describes the application and its functionality, development cost structure and timetable. We call this document Users Requirements Statement.
This process is somewhat complex, and usually starts with any legacy applications and/or currently handled work processes analysis, and proceeds with different type of users needs and wants analysis.
One, relatively simple, yet very applicable way to explain the relevant processes from the technical prospective, is to say that the information that is being collected from the users can be divided into subject matters (like, for example, companies and people), characteristics of these subject matters (like, for example, name and address), and information flow, which describes, how and in what sequence the users deal with the subject matters.
Based on the users needs analysis, subject matters become tables and the characteristics of these subject matters become table fields.
Information flow related aspects are used for deciding what kinds of user interfaces are needed - for example, what forms, reports and their elements are needed and how the forms should be linked and accessible.
If interested, see the Subject matters and information flow role in application development subsection for more information on how the subject matters and information flow affect application's development.
Application developers often complain that users needs keep changing.
As needed and acceptable to the customer, an application can be developed in versions, so that every version is fully usable, and every subsequent version provides a more advanced set of tools and features.
The users know usually only some of the things that they need in the new application. The project developer should fill in the missing pieces, so that the end result is a description of a usable database application. Further, it usually so happens that different users present and have different points of view. These viewpoints have to be consolidated and merged into an application's description that should be reviewed and approved.
Users Requirements Statement is needed for specifying in writing the objectives and everything that the application must do, the development deadlines, and the relevant cost structure. Briefly, having all of this in writing provides a clear understanding of what needs to be achieved, and helps to minimize any misunderstandings. Such comprehensive written description also helps to minimize the possibility that some development aspects will be overlooked, which may lead to disagreements once the application is ready for delivery.
Putting together the Users Requirements Statement requires effort and time, but having this document saves several times more effort and time during the development process, because it functions as a roadmap, specifying and clarifying what needs to be done and by when something needs to be done. So, the Users Requirements Statement serves both customers and developers interests.
Until the Users Requirements Statement has been completed, project developers cannot estimate reasonably accurately the labor, time and other resource needs that are needed for the completion of the project.
One of the first things that people always want to know is how long the development process will take. At the onset of the project only limited information about the project's requirements is available, so, only a rough guess can be made. The information that is put together in the first stage, Analysis Stage, allows making more informed decisions about the total development time needed. For most projects user interviewing and business and database analysis reveal requirements that could not have been taken into consideration initially. So, for most projects the total development time cannot be reliably estimated before getting together all the needed information. Similarly, the timeframe for the second stage, Production Stage, and for the third and final stage, Delivery Stage, could vary as a range from the best case scenario to the worst case scenario. The Production Stage often involves unexpected nuances that may be rather time consuming. As is pointed out below, the Delivery Stage's length also depends on several variables.
All of this can and should be taken into consideration when project planning is done. If interested, see the Efficiency and effectiveness-focused project planning steps subsection for additional information on this process.
Among other things network configurations, as they may affect the application, and differences in the users hardware and software configurations should also be identified.
Analysis Stage is often the most demanding and difficult project development stage, because it is easier to make mistakes in this stage than anywhere else in the project development process. To put it differently, often it is more difficult to foresee and estimate everything that needs to be done, than it is to actually do it.
Unless the project developer is familiar with all the technologies in question, he or she must find the right IT people to work with and ask them the right questions, and often do so repeatedly.
Further, the project developer must ensure that he or she can interview as many future database application users as possible, or, if the user group is large, ensure that there is a good user representative group in place that consists of people who are both very knowledgeable about the data usage process, users needs and wants, and are very interested in making sure that the application will actually be developed and put to use.
Even if the number of people who will use the database application in the future is small, it is better to have a group of people representing the users rather than just one person in that role. Having only one person as user representative is risky, because incorrectly selected person can kill the project.
Further, the project developer must make sure that the customer's management actually supports the project in every way needed.
The project developer must also make sure that the qualifications and personal characteristics of the programmers and other people who will work on the project match sufficiently well the project's needs.
This is all much easier said than done, but it is doable.
