MCS-270 Lab 1: Requirements Analysis (Spring 2000)

Due: February 15, 2000

In this lab, you will develop some potential requirements for a classified ad system intended for use by students (and other campus community members) at a college like Gustavus. To really develop the requirements for such a system, you would need to have conversations with all the stakeholders: not only students, but also other potential users (faculty, staff) and whoever is going to be responsible for administering the system (setting policies, dealing with exceptional situations, responding to complaints, etc.). Since this is not possible in our lab environment, we will do the next best thing, which is have you work in pairs to brainstorm the requirements, so that at least you have the experience of developing requirements within the context of a conversation, rather than solitarily. Try as best you can, together with your partner, to imagine what all the requirements for such a system might be. Be sure you think about a wide range of different kinds of requirements: Also, be sure that you consider not only the most obvious ways the system will be used (to place an ad or to read ads) but also some of the more abnormal actions users or administrators may want to take.

Your goal is to do the initial brainstorming in pairs during the lab period (Wednesday, February 9th), and then working individually finalize a requirements document by the due date (February 15th). In your individual work, you will round out the list of requirements with any additional ones you think of, polish the ones you already have, and, most importantly, organize and clearly communicate the requirements, so that the requirements document has structure, rather than being a unorganized hodge-podge of assorted ideas.

You can use whatever format makes your requirements document clear: you need not stick religiously to the textbook's example format. You might want to illustrate your requirements with some use cases (sample scenarios of usage), which gets into our next textbook topic, but can be a powerful tool for elucidating the visible functional requirements. You might even want to sketch a provisional user interface, not because this is an appropriate time in the system-development process to be seriously addressing the user interface details, but rather because it can help tell the use-case stories and thus help you find functional requirements.

Instructor: Max Hailperin