Design Document: Determining the Site Requirements

Defining the requirements of the site is absolutely, positively the most critical and important step in the design of a web site. From the requirements, all other aspects of the site will evolve.

What are requirements?
The requirements establish what the web site is supposed to achieve. All parties working on the site must agree upon them. The requirements will define what needs to be accomplished and why that is important.

If you don't know where you are going, how will you know when you get there?

Requirements establish observable and measurable business and user objectives. Business objectives include how the site will directly or indirectly impact revenues, expenses, or meet specific business needs of the sponsoring organization. User objectives deal with what the end user of the site takes away with them after the visit. Included should also be any devices that will be used to measure the extent to which the requirements have been accomplished.

Defining the Requirements with your Client
The client is whom you are developing the site for. If it is your own site, or for your business, then it is you! If it is for the company you work for it may be your supervisor, manager or owner of the company. If you are developing the site for someone else, the client may be the person with whom you meet to discuss the site or ultimately, the person who pays the bill.

TIP: Always establish who is paying the bill and who has final say on the web site project. Try to include that person whenever possible, especially at those points of time where agreement is critical before moving on to the next phase of the project. I've seen and heard too many tales of projects nearly done where the client says 'let's get so and so in here to take a look". Try to avoid 'so and so', they are never up to any good.

At this stage you will have to establish what sort of process you will use to gather information from and report back to the client. Key factors in determining the process are time and money. Even though you may not understand he full scope of the project, chances are you will have some clue as to how soon the client wants the site and how much they may be willing to spend. The larger the project is, the more time that you should spend ensuring that you have fully researched and reported on each phase of the design document.

A formal process may consist of focus groups to evaluate certain phases of the web site project. The focus groups may consist of internal employees or external customers who may be using the site. Formal meetings may be held in typical boardroom fashion to discuss the various phases with client and those related to the project.

Informal research may consist of casual one-on-one conversations and meetings with key people to get their input on the various phases of the project. Small, informal meetings with a few members of the organization may be used for the same purpose.

A combination of both formal and casual techniques may be combined. The key is to select a process early on that will fit the scope of the projects and the culture of the organization. Let the client know what you will be asking and needing from them and when you will be doing so. Ensure that they are comfortable with your meeting and research process.

Who should be involved in defining the requirements?
Ultimately, who ever is paying the bill, the sponsor, should be involved as much as possible, as that person will have final say on accepting the web site from you. Typically, the realm of control for something like this (depending on the size of the organization) will fall onto someone further down the ladder. This is not a bad thing, but it is critical that you try to include the sponsor at each phase where it is important to have agreement. You may even wish to have the sponsor sign-off on the various phases.

If you are not dealing with the person at the highest level, you will likely be dealing with someone, who has been given reasonable authority to make decisions, in other words, management. You will be working closely with this person during the project and they are likely to shape the outcome significantly.

The staff of the organization will also have plenty of good ideas of what the site should and should not be. Today, many people have a good concept of what a successful web site is versus a poor one. You will want to capitalize on this experience as much as possible. For example, if you were including a 'Frequently Asked Questions' area on your site, who would be the best to create that content? Would it be upper management, middle management or your front-line staff who answers the phone. How and when various staff members will be involved will be at the discretion of management.

Remember that good ideas can come from anyone. The more people you can discuss the potential of the site with the better.

Controlling the Process
Regardless of how formal your requirement research process is, you want to keep a few things in mind. First, really listen to what people have to say and write everything down. If you are holding a meeting, try to get input from all people present and not let one or two people lead the group.
Questions you may ask:

1. What problem does the site solve?
2. What solution will it provide?
3. What is the purpose of the site?
4. Why should it exist?
5. What does the company hope the outcome(s) of the site is?
6. Who does the site benefit and how will it benefit them?

Sorting out the information
After you have completed your research, you need to sort out the collected information. You need to get to the key pieces of information that speak to why the site should exist.

One approach you can take is to review the answers to questions you may have asked and rephrase those questions as requirements

From your research you will create a list of requirements that the site will achieve. Where requirements share a common theme or objective, group those together. Each requirement should meet an observable and measurable business or user objective. State each requirement as a straightforward point. Be precise and be specific as in the example above. After each requirement, you should define why that requirement is important in a short paragraph.

You should now have a full list of requirements that answer to why the site should exist and what the expectations of the site will be. Before proceeding, you need to present this list of requirements to the client. As I've said before, if you can get the big fish in on this do so. During the presentation, modify, delete and add requirements if you must. Also, you will want to identify which requirements are possible. You may have plenty of good requirements, but not the time or budget to implement them immediately. At the end of the meeting, you want to have a final, master list of requirements the site should achieve.

Document the requirements
After the meeting, take the final list and publish it as section 1 of your design document, which is 'site requirements'. As you should have already done, each requirement should be clear and specific and be supported by a paragraph stating why it is important. You also want to consider if the requirement is short or long-term. The published list of requirements should be made available to all of those who had input into the requirement research. If possible, have the client sign-off on this final approved list of requirements.

This list will serve as your road map to guide you through project completion. Satisfying the requirements should result in completing the project and getting paid.