Why are requirements necessary? Haven't you and your client already agreed: You're going to build a website for the new Wellesley Society for the Protection of Little Brown Birds, 'nuff said, right? Alas, that's too vague. 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.
The way to avoid this miscommunication is, obviously, to communicate: discuss with your client, your partner, and your advisor exactly what everyone has in mind.
Here's a list of what's on this page for the requirements phase:
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 check out the hall of fame sites (so you know what things are possible) and 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.
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 hyperlink 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. 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.
The grade for the conference will be incorporated into the grade for 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 following topics.
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; you can use NotePad or TextWrangler or Dreamweaver or any web-page authoring software you like, but the finished product is a web page, not a MS Word document or any other non-web document. It should be about a page long.
In the
public_html folder of your team account,
create a new subfolder called Documents. All the 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.
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 your team name and 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 web here. No assignments will be accepted late.
Because each team will be doing a different project, your advisor will necessarily have to exercise some judgment when grading. Nevertheless, we will follow these guidelines:
Here are some examples of requirements documents. Notice that they're all different, so don't treat any of them as a template. However, reading them may give you some idea of how people have done this in the past. Note that these students did well, but not perfectly, so you should strive to do even better!
© Computer Science 110 Staff
This work is licensed under a Creative Commons License
Date Modified:
Wednesday, 27-Feb-2013 12:40:02 EST
