You will work with your web application team for this assignment.
To give you an idea of what I'm looking for on the Requirements part of this assignment, here are a couple user stories plus implementation notes for two different imaginary web applications.
One important step in developing a user interface (web-based or otherwise) is to sketch the visual and navigational designs of the UI you hope to create. Drawing pictures of your UI and describing the steps a user will have to take to invoke the website's features and move between its pages will help you clarify and refine your vision of the web application and its features. The resulting images are called (depending on who you talk to) wireframes or mockups. Generally, a wireframe is a rough sketch of the visual layout and navigational structure of your user interface, while a mockup is a higher-fidelity picture that includes your intended colors, images, fonts, etc. But some people (including me) will occasionally use the term mockup when they mean wireframe, so watch out for the potential ambiguity.
For this assignment, you will draw wireframes of your web application. Depending on your dataset and your features/user stories, you might want to show multiple views of each page—one image showing each major feature in action.
Often, the wireframe process is quite formal, leading eventually to high-quality mockup images intended for sharing with all stakeholders (including your boss, your boss's boss, the customers, etc.). But for us, this is going to be a rough-and-ready sort of process. Your goal will be to make visually clear roughly what your web application will look like and how it will operate, but without forcing you to commit yet to color palettes, font families, exact images, etc.
You may use a wireframe drawing tool (e.g. the Cloud Trial of balsamiq's Web tool), or a generic drawing tool like gliffy, or just clean drawings on paper, scanned (or photographed with good lighting) once they're ready.
Keep the principles in Don't Make Me Think in mind as you work on this.
If this were a course entitled "Software Engineering", we would spend a fair amount of time studying requirements engineering. Roughly, requirements engineering is the process of figuring out what your product is supposed to do, and writing it down clearly and completely. The goal is to enable the implementers and testers to do their jobs so that they create the desired product at the end. As you might imagine, requirements engineering is very hard to do well, and has been researched extensively. It's a huge topic, well worth studying.
Because our web app project is quite structured and the Carleton term is very short, I've chosen to go with an extremely light-weight approach to the gathering of requirements. Specifically, we're using our user stories, brainstormed by the developers (you) without talking to the intended audience. This is not even a normal approach to creating user stories, which would usually involve getting all the potential stakeholders together for a brainstorming session. User stories are, in fact, mostly a tool for allowing developers and non-developer clients/customers/users to talk together about the goals and visions for an up-coming software project. But even a more formally developed set of user stories would not be a sufficient requirements process for the vast majority of software projects.
So keep that in mind in the future (e.g. CS comps). User stories are a great way to start thinking about the needs of your users, which is why I'm letting you use them for this project if you don't want to do more fleshed-out use cases. But they're not a replacement for a more thorough requirements-gathering process.