P1: Project Requirements  Guidelines

Why are requirements necessary? The computer industry has had many painful experiences with projects that delivered something very different from what the client wanted, resulting in wasted time, money, effort, and often resulting in anger and lawsuits. The post-mortem analysis often showed that the mistake wasn't willful, but simply honest miscommunication about what was meant. Thus, your goal is to avoid that to the greatest extent that you can. This document shows how.

Meeting with Client

Project teams and client must meet and agree on the website's purpose, goals, audience, and final location of the website. As soon as you find a client, set up an appointment with both team members present. Before the appointment, meet with your partner to discuss ideas for the proposed site. If possible, check out similar sites on the Web. It is easier if you know something about the content of the site. If not, your client may have to help you learn something about the topic.

During the meeting, introduce yourselves and explain the purpose of your visit. Tell the client a little bit about this project. Be sure that your client understands the ground rules of your collaboration. In particular, be sure they understand that your involvement terminates at the end of the semester. After that they, not you, will be responsible for maintaining the site.

The client should know that the site can't be hosted on the CS110 server; they'll have to find a permanent home for it. You could point the client to the CS110 site client info page, which describes web hosting for details.

During the meeting, ask your client to describe their perceived need for a web presence. Listen carefully to their ideas and desires. Be prepared to offer some suggestions, and do not be afraid to tell them when you are not sure whether something is possible or not. Your first order of business is to assess the client's real need. Will a website really answer this need? Ask your client to specify the site's purpose and audience. Be specific! An answer like: To inform the Wellesley College Community of upcoming events is only a start. Decide whether the site has the right scope: you'd like to build something that is large enough to satisfy the requirements and allow you to demonstrate your skill and creativity. If they just want a short page of text, you won't be able to exercise your skills, but if they want an ambitious website with many dozens of pages, that won't be feasible in a semester.

Decide whether you can work with this person. You do not have to make up your mind on the spot. Take some time to discuss the project with your partner after the meeting.

Once you have agreed to take on the project, your meeting with the client should result in a draft of the requirements for the website, which should be done before the conference with your project advisor.

How to Define Requirements

When you talk to your client, find out what they have in mind regarding the goals of the site, its target audience, site organization, textual content, graphical content, navigation, links, and other aspects of the site. Bring your own ideas to the discussion as well; many clients will be hoping to hear from you on many of these topics. Looking at example sites is a good idea. Anything that can help the parties understand one another is useful. Note that your client may also confuse design with requirements, so if they say it should have a menu on the left, find out if that is an absolute requirement or a design suggestion. Try to distinguish design from requirements from the very start.

The goals of a site are not always obvious. If it's a website for the lacrosse team, should the site encourage people to try out for the team, or is it primarily information for people who are already on the team? What is the client's communicative goal? Is it to persuade people to act (say, writing letters to Congress), to excite them with enthusiasm (say, for classical Greek mythology), to inform them about facts and procedures (say, for the financial aid office), or more than one of the above? The goals of a site are usually related to the target audience. You'll want to think about aspects such as their demographics (age, sex) as well as their interests, computer savvy and so forth. For what reasons are they coming to your site? How will they get what they seek? Is there more than one kind of user? How might a site cater to both an adult researcher and a child with a novice's interest in the area? (Some CS110 students actually created a site that did this!)

Find out if your client has particular organizational needs. Should two topics definitely be on the same page? Should there be a direct link between two things? Many times these won't matter and should be left to design, but sometimes there are particular requirements.

Talk about the client's desires and goals with respect to graphical design. How important is the appearance of the website, compared to the content? Is a particular color scheme required, or does the client have a preferred layout? In general the graphical design of the site will be up to you, but you should discuss the client's specific requirements, if there are any. Once you start talking about graphical design, it is easy to get ahead of yourself. Remember, at this stage you should be collecting the client's requirements, not making design decisions.

Find out if your client has any special, idiosyncratic requirements. Here are some examples:

  • The user should be able to get to any reference page in three clicks or less.
  • The background and fonts should suggest nostalgia and antiques.
  • Every page must load in less than 1 second.

Finally, you should be clear on what requirements are necessary versus desirable (true, we probably shouldn't call them "requirements," but that's just what we call the document that you're writing).

The discussions about requirements are probably the time in the project when your client must spend the most amount of time with you. Hopefully, you have chosen your client wisely, and they will be willing to do so.

Conference with Project Advisor

Each project team will be assigned a project advisor. This will usually be one or the other of the team member's CS110 lecture instructor or discussion leader. You will receive notification of which of the instructors is your advisor.

Set up an appointment for a project conference with your advisor. Each team must meet with its CS110 advisor before the end of the time period specified on the syllabus for this project phase. Both project partners must be present for the conference. You must already have had substantive discussions with your client, either face to face or by phone or email, so that you are both clear on the requirements for the site.

Prior to the meeting, you must write a draft of a web page called P1_requirements.html and have it uploaded into your Documents folder in your team on the CS110 server. We'll read it online, or print it out, so make sure it is readable.

During the meeting, you and your advisor will discuss the website and the requirements document.

Requirements Document

A requirements document describes the problem to be solved, not the solution. What does that mean? It means that requirements are about what is in the website, its contents and organization, rather than what the website looks like.

Don't jump the gun in writing the requirements document. You will be tempted to start describing the website you will build, but that's the solution, not the problem. Make sure you understand what the client really wants. After all, you can't very well build the website until you know what the client wants.

It is not a bad idea to look ahead at what you'll have to do for the design document (the next assignment). The more you can anticipate that assignment, the easier it will be. For example, by the next assignment, you need to have collected all the textual content of the site. Since much of that content will come from the client, you should begin talking to your client about obtaining it. You don't want the website to be held up waiting to get some text or even graphics from your client.

As you begin drafting your requirements document, it is a good idea to give drafts to your client and discuss them. Once an idea is clearly presented in written form, people often realize that's not what they meant. Discussions with your client are also a good way to ensure that the requirements are clear and complete. This is not an assignment that should be begun the day it's due.

What to Turn in?

Turn in a document, written as a web page, containing a structured essay covering the topics mentioned below. Additionally to the document, you can create your own CSS style file that you can use throughout the semester to style these documents.

  1. At the top of the document, there should be your names, as authors, just as you would for any formal paper, together with the date.
  2. Administrative details: the name of your client, and his or her position in the organization (or company), if applicable.
  3. The site's purpose and goals and how they will be accomplished by the site. Try to draw a connection between the goals and specific content elements of the site.
  4. Who is the intended audience or typical user? Describe them and their needs for information and other content.
  5. A description of the content of the site and how it is organized. Think of this as the outline of a paper: it doesn't have to spell out the sentences or even the paragraphs, but it should mention major sections and even a few salient subsections. In your conference, be prepared to discuss the site's content, and to explore the feasibility of its design.
  6. If known, the server where the site will reside after the project and the names of who will be responsible for the site maintenance.

The document must be in essay form (paragraphs of text, not just a bullet list or set of bullet lists), although you may use bullet lists when they are appropriate. It must be written in HTML; not a MS Word document, PDF file, etc.

How to turn it in?

In the public_html folder of your team account, create a new subfolder called Documents. All the written documents that you create for the project from this point forward will be placed in this folder.

You will hand in your assignment as soft-copy only. Name your document P1_requirements.html. (We will look for a file with exactly that name, so don't be creative.)

Upload the P1_requirements.html to the Documents folder of your team account.

Since an unstyled HTML document that contains text is hard to read, create a sipmle style sheet that will make the document more readable and well organized. You can then reuse this stylesheet for all the further documents you will write in the course of the project.

The timeliness of your assignment is determined by the timestamp on your electronic submission.

Standard Reminders: You should ensure that any submission is clearly marked with the names of both team members. Also, once the deadline has passed, do not edit the file or re-upload it; we will be looking at the file creation times to ensure that you submitted the assignment on time.

You already know that all the deadlines are posted on the schedule. The lateness policy is that you may turn it in up to 24 hours late, with a 10% penalty.


In grading this assignment we will take into consideration these aspects:

  • The requirements document contains all the requested information.
  • The site's purpose and goals are described clearly and in details (as opposed to being vague and generic.)
  • The intended audience is identified accurately. An excellent discussion will describe how its audience differs from a generic one and how those differences pose a challenge for the web design.
  • The site's content is covered properly. An excellent description will be comprehensive and detailed
  • You come to the meeting with the instructor prepared (and as a team). Prior to the meeting you must have met with your client and uploaded a draft of the requirements document into your team directory on the server.
  • The document is well structured, easy to read, follows grammar and syntax conventions, etc.
  • Your HTML code for the document page is valid.


We are providing examples from students in Spring 2014. These examples are not perfect, but will give you an idea of what is expected of you.