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

Due: Monday, February 21, at the beginning of class

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 groups 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 partners, 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. 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 groups during the lab period (Monday, February 14th), and then working as a group, finalize a requirements document by the due date (February 21st). 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.

I recommend that you use the book's format when writing up your requirements document. Be sure to also use the ideas from chapter 5, which we will be covering on Tuesday. 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.

Addendum (clarification): First off, I am allowing (in fact, recommending) that you hand in a team requirements document, should you wish to do so. Therefore, be sure that the people you are working with are in agreement on whether you will be turning in a team document.

Secondly, 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, I will expect a Use-Case diagram as on page 72, and brief and step-by-step descriptions for each of the use-cases. Actually, if you have many use-cases, I will expect all of them to have brief descriptions, and at least 3 of them having step-by-step descriptions as well. Since this is "learning by doing", I feel that this is best done by teams uncovering the goals and methods in the book, and applying them to the project at hand.

By the way, I linked in UseCases.org on the course web page (as well as here, of course).

Instructor: Karl Knight