CS 257: Software Design

Web Application, Phase 2: data and user stories

By this time, you know who your partner(s) is/are. Pick one partner's git repository to work in, make sure all partners have read/write access to the repository you have selected, and create a directory called "webapp" at the repository's top level. Your work for the whole web application project will live in the webapp directory.

What to hand in for Phase 2

Create a text file webapp/doc/phase2.txt. (That is, a text file named phase2.txt and located in a "doc" subdirectory of the webapp directory). In that file, include:

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 normally 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 having you write them. But they're not a replacement for a more thorough requirements-gathering process.