303 873 0288

Planning FileMaker Databases

The information below is an overview of considerations for software planning. By filling out the form you will recieve an email with a detailed PDF document that includes more valuable information.

  • Detailed Doc Take-Away




1. Begin With The End In Mind

To insure that you obtain the desired result when planning FileMaker Databases, make sure you have your software well defined before development begins.  The more specific you are in the beginning, the happier you will be with the end result. Remember a software developer can’t read your mind. Be clear and be detailed!

As you plan your software keep in mind the following key issues:

Data Integrity.

This simply means that you want to maintain consistency of data from one part of the software system with another.  Any time you re-enter information in one part of the software that is already stored in another part of the software you risk user error and data integrity is lost with each error. You want to enter information once and use it many times! Any discussion of data integrity alludes to isolating the different parts of your software system so that there is no repetition of stored data. A customer name shouldn’t be stored in one part and their address stored in another part of the software. All of the information pertaining to the customer should be stored in one part. However, a customer orders many products. Product information should not be stored with the customer but should only be accessed by the customer part of the software from the product part. Another way of looking at this is to consider the customer and product databases as storage and viewing components. In this scenario we are storing the customer information in one area of the system and the product information in another. However, we are viewing/manipulating the product information from the customer area. There are more complicated ways in which data base integrity may be lost such as poor data relationships.

Data Relationships

There are three types of data relationships, one-to-many, one-to-one, and many-to-many. The most common relationship is one-to-many. The other two types have special requirements and to some degree are obscure.

As an example, one part of your software might store information about customers. Another part of your software stores information about products. A customer may order many products. So the relationship between the Customer portion and the Products portion of your software is a one-to-many. You can display many customers that order a given product in the product portion of the software (one-to-many). You can display all of the products ordered by a specific customer in the customer portion of the software (one-to-many). Displaying customer and product information differently then what’s described above is possible but whenever the one-to-many relationship is not considered things tend to get complicated and data integrity issues may result.

Input/Output

One of the most common techniques to help define how software should be developed is to consider input and output of information. What information will be input? What information needs to be output from the software in the form of reports or lists or exported data? This usually means data entry forms and reports. Well-defined forms and reports are essential to successful software development.

Detail

An unerring attention to detail and nuance often makes the difference between a successful long-term software solution and a short-term software nightmare.

User Participation

It is always beneficial to obtain the user base “buy in” on the software idea before things go to far. But, more important is to get their honest participation in making sure that all the details and nuance are covered. Creating a document where everyone can participate often helps weed out issues that would ordinarily be left unresolved until it’s too late.

Define and document (in writing) everything you need in the software including:

2. Data Entry Screens

   Provide detailed drawings of the appearance you desire. STORYBOARDING IS HIGHLY RECOMMENDED!

A. Define appearance

 1.Fields

A. The appearance of the fields can help the user know how to complete a form.

B. A field can be a different color than others.

C. It can have a 3 dimensional engraved or embossed appearance.

D. It can have a box around it or a line under it.

E. Many combinations are possible.

F. Fields can look different on one screen than the same field in use on another screen.

2. Instructions to user

A. Write out specific instructions that need to appear on the screen.

1. Will you need an elaborate on-line help system?

2. Will you need extensive instructions in certain areas of the software?

3. On a given screen or form, will you require brief instructions?

3. Colors

1. Include RGB values and any spot or process colors that need to be matched relative to your company design specifications.

4. Fonts

As per your company design specifications.

B. Form  completion

1. On a given screen (form) how do you want the information entered?

a. Is there a process wherein one piece of information has to been entered prior to another?

b. Are there calculated values that need to be reviewed by the user before they complete the form?

c. What Tab Order do you desire? In what order should the fields on the form be completed?

d. Is there consistent information that needs to be on all forms? Such as:

i. Date

ii. Time

iii. User Name

iv. Page Number

v. Record Number

vi. Found Count

vii. Information particular to your system such as:

1. Customer name

2. Customer serial number

3. Product name and serial number

2. What pop up menus, radio buttons, or check boxes do you need for the fields?

a. Pop up menus are usually used when one item is entered from a lengthy list (referred to as a value list)

b. Radio buttons are used when the value list is small (all items are shown on the form at all times) and a user must choose only one of the displayed items. If the user changes their mind the previous choice is deleted.

c. Check boxes are used when a user can choose multiple items from a value list. (all items are shown on the form at all times)

For example, a “Month” field might have all of the months of the year listed in a pop up so that the user wouldn’t worry about spelling or incomplete entry. They would simply select the appropriate month from the list. A field for “Product” would feature a list of products. These lists are called “value Lists.”

d. Will the value list change occasionally? With the above examples in mind a “Month” value list would never change but a “Product” value list would change every time you add a new product to your companies product offering.  A “Customer” value list would change every time a customer is added or removed as a customer.

i. Value lists can change from :

1. moment to moment

2. minute by minute

3. hour to hour

4. day to day

5. week to week

6. month to month

7. year to year

8. never.

e. A Value list can be a simple list that is typed into the software once (static) or it can require a complete software behind the scenes to supply ever-changing values (dynamic) to the list. It can also refer to values typed in another field somewhere else in the software.

f. Value lists are important to “data integrity.”

3. Navigation

a. Flow chart the system

b. How the user moves through the system will dictate how friendly the system is to the user and how the user completes their work.

c. Will one type of user need to complete information before another type of user can make use of the information?

d. How do you want them to navigate through the software?

e. How will an individual enter the system?

4. Reports (Provide detailed drawings of what you want each report to look like.)

A. What calculations should be included? (Supply these in writing.)

B. Define report appearance

1. Colors

2. Fonts

3. Fields

4. Instructions (Write out specific instructions that need to appear on the screen.)

5. Navigation needs (Flow chart the system)

C. Who can access them? (Define groups or levels of access.)

D. How will reports be accessed?

E. Do reports need to be archived?

5. Security

A. Password levels (Management, Administrative, Other)

What will each level of access be able to do? (Define groups or levels of access.)

B. Who will maintain passwords?

C. What areas of the software will be secure?

6. Validation of Data

What data needs to be compared to standards or entered in a specific way to maintain data integrity?

Define lists for each piece of data. For example, a field entitled, “State” would need a list of all the 50 States. These are called “Value Lists.”

Are there any fields that might require a value automatically entered when a record is created. For example a field entitled, “Today’s Date” would have today’s date automatically entered.

What data can be supplied to the main system from ancillary documents? The idea here is to enter the data once and to use it throughout the system (many times).

7. Maintenance requirements

What information must be maintained over time?  For example, do any of the value lists change on a regular basis? In some systems that are product oriented one software might supply product information and specifications to another system designed to process product orders. Obviously, product specifications change over time and must be maintained.

What data needs to be stored indefinitely versus data that might be removed from the software after a given time period. (Be specific.)

8. Networking requirements

Will the current network handle the software traffic quickly?

9. Navigation

How will users navigate through the system? Do you need different navigational routes through the software for different types of users?

10. Printing

What printing needs will the system require? Will there be more than one printer used?

11. Back Up

How will the software be protected from loss? Will regular backups be done?

12. Future needs

2 Years from now?

5 Years from now?

13. Automate The Mundane

The main reason we use the computer is to automate the mundane. Creating one to many relationships is one way of thinking about automation. One to many relationships reduces the amount of data entry (among other things) . This means that a user enters the information once and uses it any many related software activities. This is to help free the user of mundane tasks and to allow them to concentrate on higher level tasks. Define areas that should be automated in order to make the software be friendly and fast. Examples are:

A. Auto entry of common values.

B. Software that supply common information to other systems.

C. Scripts and programming features that enable the user to push a button and run a report or complex series of
steps.

D. Provide training

The best most well designed software still needs to be explained to the user.

E. Documentation

Will you have a written manual for the software so that complex aspects of the software are documented and training of new employees will be possible? Who will write it? The more complex your software, the more necessary this becomes.

Please do not hesitate to contact us if you have additional questions about Planning FileMaker Databases. Additionally please see FileMaker’s help article on “About Planning A Database!”