CS 257: Software Design

Web app: requirements and wireframes

Folder: webapp/doc

Tag: wireframes

You will work with your web application team for this assignment.

Goals

Your tasks

  1. Requirements/features. Create a text file requirements.txt in your webapp/doc directory. In this file, include:
    • Your names
    • A brief description of your dataset. Include instructions for how to get the dataset (typically, just a URL and maybe a note about where to click should do the job).
    • A list of short use cases or user stories you would like to support in the final version of your web application. You may use any of the templates described in the Wikipedia articles on user stories or use cases. For each use case or user story, provide a brief description of how it might be implemented on your website.
  2. Wireframes.
    • Create wireframe image files with descriptive names (see below for more details).
    • Create a subdirectory doc/wireframes, and put your images (jpg, png, pdf,...) there.
    • [Optional] Put a readme.txt file in doc/wireframes if you want to provide context for your wireframe images.

Example stories

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.

STORY: A tennis fan can get a list of all the winners of the Wimbledon women's singles championship, so they can figure out whether Serena Williams has won more times than Martina Navratilova. IMPLEMENTATION: One simple way (maybe not the best way—we're still thinking about it) to support this would be to have a drop-down list for tournaments, in which the user could select Wimbledon, and another drop-down for sub-tournaments (women's singles, women's doubles, men's singles, etc.), and maybe a third for what information I want (champions, all participants in a specific year, etc.). Kind of clunky, but it would work. STORY: A Senate campaign staffer could get demographic and voting data about a county in their state to help plan advertising and campaign events. IMPLEMENTATION: We could have a county map of the state, and the user could hover over a county to get quick summary data, or click on a county to go to a page with more detailed current and historical information.

About wireframes

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.

A note about requirements

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.

Have fun!