To start this process, try and make an outline of everything you currently know. Since this tutorial is geared towards web projects, make a list of all the pages you know will be included at this point. Underneath your pages, start listing all of the elements, to date, to be included. For example, you could start listing search fields, login buttons, dynamic and static content, etc. Then make this your beginning table of contents. A lot of this should be easy after creating your models for the application.

Three specific items you'll want to attack:

• Define the navigational elements
  Start creating the "buckets" in which your application is going to be divided up and then identify what is going to be filling up those buckets. Do this from the user's perspective. Seek out what will be your global navigation and how the sub-navigation will work under that to support your user's goals.

• Diagram the organization of the information (i.e., create flowcharts)
  Creating flowcharts can be very handy when trying to work through a lot of information or a very deep navigation set. Anything you develop now will change over time, but ultimately you'll want a thorough flowchart of the application included with your spec. Also include the navigational path through the information on this diagram (e.g., parent-child directories, where the user can jump to from each page, etc.). Visio is a good tool for developing technical diagrams and flow charts such as these.
  View a sample flow diagram.

  jjg.net has a fine downloadable shape library for Visio. I would also suggest complimenting this stencil with Visio's own Basic Shapes and Basic Flowchart Shapes.

• Create a prototype
  A prototype of a web application is just a set of static html pages put together to show the key pages of the application and the user interface. It allows the functional spec writer to have something close to a working model to test their ideas out on, start focusing on the layout, and begin gathering input about the look and feel. It is debatable in some circles whether you want to create a prototype at this stage or not. For me, I prefer to have one at this point. In the iterative process, I believe it helps to have this big picture look at a potential finished product while also seeing how the components of the system affect the overall product. Instead of boxes and arrows, bulleted comments, and a list of functions, you have an actual web page to look at and experience. Also, as a web designer I have the capability to do this; which, I realize not every spec writer will have. Whether you create a prototype now or later, you should definitely have one before you start writing the actual spec. Aside from being a convenience for you and allowing you to possibly iterate your design much faster, it allows your colleagues and stakeholders the opportunity to look at the application and deliver much more specific and useful input about what you are doing. Not everyone can look at an informational flowchart and realize something is way they want it. Most people can when looking at a prototype.

Essentially, what you are doing at this stage is defining the relationships of the objects in your designer's model. You are laying the groundwork for what will become the structure of your application.