Once you have the business intent, roles, role intents and an essential task list, you should have a pretty good sense of the problems that you are solving (both for the organization and for the various classes of site users) and the high level functionality that the site will provide. From there, you can progress to the detailed specification phase.

Fleshing Out the Specs
You can fully specify the requirements for any task by describing the screens with which the user will interact and the actions that each screen supports (as long as you describe screens and actions sufficiently broadly and deeply). In practice, this tends to be a really straightforward way to gather comprehensive requirements quickly from non-technical users.

Screens
Ask the users to describe all of the screens they'd need for each task. To get full coverage, you also have to consider "screens" that are not web pages. If an email or SMS needs to be sent out, that can be considered as a screen, and if you have a web service or, perhaps, an RSS feed, that also has to be described as a screen to determine what information it displays and what functionality (if any) it provides.

Actions
Most screens support one or more actions. An action is a button or link that allows you to do something (submit a form, view a different screen, buy some products, etc.). Typically actions will comprise one or more steps, which usually involve tasks such as getting or modifying data, sending emails, reading or writing files and/or making conditional choices. For example, the "save" action on a "contact us" form would validate the form data, and display a thank you screen. If the data were invalid, it would redisplay the form along with any validation errors returned.

If you start with the landing screen, get a list of all of its actions, and then repeat for every screen that every action can take you to, you'll eventually get a complete list of screens and actions for that task.

You also need to consider non-standard actions such as receiving email messages or XML requests, or even scheduled requests from a scheduled task, to get complete coverage of the project requirements.

Filling in the Details
Once you've got a good set of screens and actions, you can then start to fill in the details. For each screen you can clarify the fields to display, filter, order by, etc. For each action you can get more detailed information about all of the steps and any business rules required.

MVC Modeling
The great thing about this approach is that it flows perfectly into a Model-View-Controller style architecture - whether you are using a community framework like Fusebox, Mach-II or Model Glue, or whether you are rolling your own.

Every screen corresponds to a view, every action corresponds to a controller method (an event in Model Glue or Mach-II, a fuseaction in Fusebox) and most of the steps that make up an action describe method calls against your model to do things like save an article, get a list of users or get information on a product to display. This makes it extremely easy to flow from the detailed specification into developing the code, and very easy to relate each event, method call and view to the task it supports and hence the role(s) and intent(s) that it is meant to support.

Technical Design
Once you have completed the IDD process, you should be ready for the technical design phase. In that phase you'll consider issues like the appropriate architecture to use, what framework (if any) to implement and how you are going to handle everything from transaction management and error logging, to user authentication and application security.

Once you have that locked, you should be ready to code an application that comes pretty close to meeting your users' expectations first time round - especially if you prototype all of the screens and actions as part of the specification process. You will also have information on all of the fields being imported, exported, listed, viewed, filtered, searched and ordered by and for each object (product, user, article, etc.), so you should find it fairly straightforward to develop a database schema if you don't already have one to work from.

Conclusion
Intent Driven Design is not a complete requirements-gathering process for large, well-funded projects. It doesn't include any explicit discussion of non-functional requirements (performance, latency, load, environment, etc.). It also doesn't include marketing strategy, market research or formal usability testing. Those are usually outside of the budget for smaller organizations (although they can be added to the process quite easily if required).

However, it is a proven, quick and effective methodology for capturing a useful set of functional requirements in a way that easily translates into well-architected working code, and that allows everyone on the project to quickly understand what they're coding and why it matters.