MCS-270 Lab 1: Requirements Analysis

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 types of requirements, as described in the FURPS+ model (pp. 42-43 of our textbook). Use this as an opportunity to explore the meaning of the various FURPS+ categories. 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, and then working individually or as a pair, finalize a requirements document by the due date. In your 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.

Let me make some comments as to what I am expecting in your document. Generally, I would like you to apply the strategies that the textbook's author outlines, in particular in chapter 6, about writing a requirements document. Since this is "learning by doing", I feel that this is best done by teams uncovering the goals and methods, and applying them to the project at hand.

In particular, I recommend that work through the 4-step process described in section 6.9. In particular, you should choose the system boundary, uncover actors, categorizing them as primary or supporting, identify goals, and name your use cases. For the use cases, at least should be briefly elaborated, one should be casually elaborated and one should be (reasonably) fully dressed.