Developing models is a good way to start distilling all of the information you have gathered so far. Models, by definition, are a good way to convey an understanding of the components that make up a system. Teachers frequently use models as aids to explain complex ideas; physicists use atomic models, automobile designers frequently build many models of a new vehicle before creating a prototype. As the functional spec writer, you are responsible for creating information models to help convey the concepts of the application you are developing.

It may be useful to consider creating three different models:

• User’s Conceptual Model
  Building this model will be helped greatly by your development of use cases and user personas. Here, you will build a model of your system based around the user’s perceptions of the system: not what the system actually is, but how it will be perceived by the user.
  A good example of this is take an e-mail list or a “Clubs” application (like Yahoo! Clubs). The user does not really care whether it is an e-mail list, a club, a web page, or anything. All they care about is the subject: whether that be baseball, german polkas, or Mad magazines. The user’s model of the system doesn’t incorporate things like “text fields” or “recursive paths,” they’re only concerned about the subject or information that is most directly related to them.
• Designer’s Model
  The designer’s model is really the nuts and bolts model for the functional spec writer. This is where the interface components and relationships to be seen and experienced by the user are defined. It details the available objects in the user’s universe and how they can use them to accomplish certain tasks.
  It’s easier to try and break things out into objects and classes at this point. I find that when I start doing this, the whole system becomes simpler and less complex. Although this topic is much larger than the scope of this tutorial, we can briefly take a look at an example designer’s model.
  View Example Model -This example was created in Visio and represents a "User Account" of the example application used throughout this tutorial.

• Programmer’s Model
  The programmer’s model is typically only relevant to the programmer. Ideally, we would create user and designer models, and then pass those off to the programmer who would then build the application. However, if you have done this any number of times you will soon realize that every programming environment has inherent limitations and that those constraints must be incorporated into the designer’s model. What typically works for me is to have a meeting with the programmer assigned to the project and go over the designer’s model with them. From that, I can usually walk away with a good idea of what we need to change, what we can work around, and what I need to watch out for as we move forward.

The most important model for us to consider, as functional spec writers, is the designer’s model. This will be the one we spend the most time on and the one that we refer to the most when explaining the application to other stakeholders in the project. It will also form the foundation for writing the spec.