MCS-270 Lab 1: Requirements Analysis (Spring 2001)
Due: February 13, 2001
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:
- visible functionality
- system attributes
- hidden functionality
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 7th), and then working individually
finalize a requirements document by the due date (February 13th). 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