Often the hardest part of developing an application is getting agreement on what exactly it should do.
Intent Driven Design (IDD) is an approach that simplifies and standardizes the process of getting detailed technical requirements from non-technical business users so you can develop more complete and consistent requirements in less time.
The Importance of Intent
One of the most frustrating elements of application development is having to continually change the way an application works because of conflicting requirements from different stakeholders. Most such problems come from the lack of a clear focus for a site. You have to agree, in writing, with all of the stakeholders - why you're building the site, who will use it, and what their motivations will be - before you can even start to discuss how the site should work. If you don't, you are guaranteed weeks of wrangling as different stakeholders disagree on fundamental design decisions or priorities because of the lack of a shared vision for the site - often after much of the application has been coded.
The goal of IDD is to provide a standard but lightweight approach to capturing all of the key information that you need to specify a site. For a simple site, you might be able to go through the entire process in a couple of hours. For a more complex project, you might be discussing the issues raised for a number of weeks. Either way, you should end up with a well-structured set of somewhat traceable requirements that you can provide to your development team, and use to turn the high-level business objectives into the appropriate code to achieve those agreed objectives.
No Silver Bullet
In his classic book "The Mythical Man Month," Frederick P. Brooks wrote an entire chapter about an important distinction between "accidental difficulties" and "essential difficulties." For example, memory management/garbage collection is accidentally difficult - it is a problem that can be solved with a smarter programming language (Java or C# instead of C++). However, building a flexible object model for a real world application is actually difficult - there is no "silver bullet" (methodology, IDE, code generator, etc.) that can make this fundamentally difficult problem simple.
So, IDD is not a silver bullet. It doesn't make it easy to specify complex systems or to handle conflicting requirements. However, it does allow you to clearly and consistently document why you're building the system and what each group of users is expecting from it. It also allows you to "start at the beginning" with a formal process that lets you lock down the objectives which drive the tasks, which drive the screens and actions, which, in turn, drive the data model and the scripts required to implement the requirements. In short, it tries to simplify the process of capturing requirements in a way that doesn't require a degree in computer science to understand!
How Big Is Too Big?
It is often better to build a small project to meet a limited, but valuable, business intent than to try to put your entire business online, delaying the benefits of your supplier extranet or online store, while trying to decide exactly what format your online job application form should take or how to track vacation days online. I have found that if I have more than three to five major intents for a given phase of a project, unless they are being handled by independent teams, I'm probably going to end up with problems.
Too many intents make it hard to keep the focus required for developing a great site, and they increase the likelihood that different intents will conflict, leading to a "nobody likes it, but nobody hates it" kind of compromise design. Overly ambitious projects are also much more likely to ship late or even to fail to ship at all.
This doesn't mean that you can't specify complex applications using Intent Driven Design. It does mean that you might want to break down large, complex projects into smaller projects, and run through the IDD process for each phase. My general rule-of-thumb is that, if the coding (excluding specification, testing, revisions and deployment) for a phase takes more than a couple of weeks, the phase is too big. With application generators becoming more common, there are very few collections of 10-to-20-use cases that take more than a couple of weeks to implement (assuming two-to-five-use cases per programmer over the two weeks, and a maximum team size of five developers before you need a more robust methodology).
These estimates exclude "rocket science," where you're trying to solve fundamentally hard technical problems (such as seamlessly integrating Hibernate with ColdFusion). They also exclude "lab experiments" where issues like performance or load are critical and you may need to build a couple of prototypes before you find the right approach. Such projects can take orders-of-magnitude more developer time to complete, but can still benefit from the IDD approach.
Business Intent
The first step in IDD is to write a paragraph describing the business intent. Why bother building the site? What exactly will it do for your organization? Writing down and agreeing on the business intent upfront makes many of the later decisions easier by creating a shared focus. If the intent is to increase your online sales, the job board and the HR benefits pages are not essential to that intent so they can be pushed off to phase 2.
Roles
What people (and computer systems) are going to use the site? From a requirements-gathering perspective, it is usually best to break down your audience by the collections of tasks they will want to perform (as opposed to by demographics, psychographics or other such approaches). A given user will often perform multiple roles, so you may well have users that are both customers (for buying things online) and administrators (for managing site content), or are both sales people (for accessing the sales reporting system) and employees (for accessing HR benefits online). Roles in a typical project may also include one or more classes of administrators, such as data entry, content editors, approvers and reviewers, and may also include various reporting-based roles.
Roles are not always performed by a person. To capture all of the tasks that the system needs to support, you might also have roles for scheduled tasks, imports, exports or any web services and other interfaces that you provide.
Role Intent
Once you've identified all of the roles, the next step is to document the key reasons why each role would be performed. By documenting why a customer would choose to order online, or what business information a manager is looking for from an online report, you will be able to make better design decisions regarding trade offs such as balancing ease-of-use with flexibility. Also, if there is no good reason for someone to use your website, they probably won't use it. You will only achieve your objectives from your site to the extent that you help your users get what they want out of it. Don't worry if not every role has a meaningful intent, but do go through the process as you'll capture distinctions that will help when you're working on the detailed design.
Compare your role intents with your overall business intents to make sure they are consistent. If you want to increase revenues and your customers want to place orders online 24/7, supporting that intent will meet their needs and yours. However, if your customers want to be able to find the lowest cost supplier, that is probably not an intent you want to support within your site as it is unlikely to help you increase your sales.
For a medium-sized e-commerce system, you can probably document the business intent, roles and role intents on just two or three sheets of paper. Indeed, with a small team (one to five developers), if you have much more than three sheets of intents, you will probably find it hard to deliver a system that can achieve them in a timely manner.
Essential Tasks
Once you have a list of roles and their associated intents, the next step is to figure out what functionality your system must provide to help achieve your business intent by helping your users achieve their goals.
A task is just another name for what most programmers would call a "use case." We've found that by calling it a task, our non-technical clients grasp the concept more easily. A task is a series of screens and actions that allow a user to achieve a valued outcome. Examples might be "order products online," "check order status" or "compose email newsletter." The specification for each task should include any alternate paths (along with their screens and actions) for different choices and for handling error conditions.
Now, instead of having the usual "wouldn't it be cool if the site could . . ." discussions, you can come up with a much more focused list of tasks by asking what exact tasks the site must support to allow each of the roles to achieve their intents, and in a way that helps the organization get what it wants from the site. I tend to focus on essential tasks (as opposed to "nice to haves") as I prefer to deliver the absolute minimum amount of software required to meet a useful set of business and role intents. If you want, you can add "nice to have" tasks depending on the time and budget constraints on your projects, but classify your tasks into essential, useful and optional so that you can deliver the most important functionality first.
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.