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.
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
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.
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
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:
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.
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
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.
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.
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.
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.
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.)
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.
In grading this assignment we will take into consideration these aspects:
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.