Present to Your Client - File Maker

Once you’ve got the requirements written down, show them to the client. If he thinks that the requirements fit his needs, then it’s time to come up with a design for your database system that will transform the requirements into geek-speak.

That is, you’ll turn a requirement like “The system will be able to generate a report of item IDs that need to be verified” into “When a user wants to generate the ‘Item ID Verification List’ report, they will first go to the following Report menu screen [add a screenshot of it] and click the ‘Item ID Verify Report’ button . . . ”

In other words, you will map the more general requirements onto a detailed specification of exactly how the functionality will be built using the selected database management tool which, you hope, will be FileMaker Pro (although it’s likely that if you get to the design phase you’re already fairly certain that FileMaker can provide the required functionality).

To FileMaker or Not to FileMaker, That is the Question
Inevitably you’ll run into someone who will try to tell you that FileMaker Pro is not up to the job for whatever database system you are about to build. Hopefully, you can persuade the person that this just isn’t true. FileMaker can do just about anything you want and it’s currently running the show in many a Fortune 500 company. But if you are interested in seeing how FileMaker Pro stacks up against other popular database programs, see the following articles:

  • “FileMaker Pro and Microsoft SQL Server Integration” which is also at the above-mentioned link, discusses how to get FileMaker Pro and Microsoft SQL Server to work together, but also discusses the differences between the two RDBMSs.

Design Document
Part of a design document might look like this:

Design 33.3.2 Report Menu Options
From screen 127, the user has 3 options: Go to the main menu by clicking the Main Menu button, go to the Reports menu by clicking the Report Menu button or print the Records Entered report for the current found set of records by clicking the Records Entered button. If the user decides to print the report once it is presented in Preview mode, he will be returned to the Reports menu once printing is complete.

In addition to this narrative description of how the database ystem will operate, a good design document spells out every element that will be a part of the database system. Therefore, it’s probably a good idea for your design to contain the following appendices:

Diagram Your Workflow
You should build a logic flow diagram (also known as a flow chart or workflow diagram) even for somewhat simple processes that need to be emulated or created in your database. For instance, a specific workflow or set of steps must be followed when entering a new contact name on a company’s detail screen so that the data is entered correctly, at the right time, in the right order, and with the right bits of data. A very basic workflow diagram for a process you do every day would look like Figure below.

Basic workflow diagram.

Basic workflow diagram.

Other Design Document Sections
Field report (a list of all the fields and their definitions)
Relationship report (a list of all the relationships and their definitions)
Security/password report (a list of all passwords, groups and access privileges)
Layout report (a list of all layouts and what objects will be on them)
Value list report (all the value lists from all databases)
Entity relationship diagram (shows how all the databases in the system relate to one another)


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

File Maker Topics