Assignment 2

Requirement Analysis, by Zach Tomaszewski

for ICS 667, Fall 2002, taught by Dr. Dan Suthers



Root Concept

Mission
To create a collaborative, electronic personal calendar and task scheduler [as per this requirements analysis assignment].
Rationale
This will be more useful because it will be in an electronic form, accessible by devices used for many other applications. It should also be easier to schedule meetings between users of the system than if they didn't have the system.
Stakeholders
Developer
Project financers (advertisers? stock-holders? grant?)
Customers (those who purchase the software, for themselves or for a company)
End users (in various permutations of experience, preference, and use)
System maintainers
Limitations
Developer skill -- programming quality, interface/graphics attractiveness
Time
Funding
Generating interest in a scheduler-saturated market
Assumptions
That schedulers are valuable tools that people want to use.
That it is possible to build a better (either more efficient, easier to use, or more fun) electronic version than is possible with paper.
Another scheduler is needed--that we will be providing something useful and innovative over existing applications

User Interview

Goal

A number of electronic schedulers already exist, yet many people don't use them or continue to use paper. Why? How do they use schedulers in general?

Open-ended

Tell me about how you currently keep track of your tasks or meetings?
1) An organizer book. Includes a calendar, an address book, area for notes, stickers (such as smiley faces). And I usually use my Hello Kitty pen.
2) In my head. If really busy, I'll write down things do to on an envelope or scrap of paper.
What drawbacks does this entail?
1) The book is too big to always fit in my purse
2) I sometimes forget things. But even if I write them down, I usually forget to check the paper for a couple days, so that doesn't help much either.
What are the advantages of your current system? When are you glad you use your system?
1) No dead batteries. It's easy to use. Helps keep me track of things, though I do have to remember to look at it.
2) When I see stressed out people writing things down in their little organizers, I hope never to be that harried.
Did you use a different method in the past? Why the switch?
1) Used to use a palm pilot. But the batteries would go dead, and then I'd have to reload everything. Also feared losing or breaking it.
2) No. I've played around with computer programs for tasks, but never really worked. Half the things I have to do aren't on or around a computer.
How do you go about scheduling meetings with other people?
1) Ask them what's good for them, then write it down. If it conflicts, ask them for another time.
2) See when they're free. My schedule is usually pretty flexible. If there's a time conflict, I ask them for another time that works. If they pick some time I'd rather be sleeping, I'll be hesitant, but I'll go with it if it's really the best time for them.
What would you want to see in an electronic scheduler?
1) Easy to read with a sharp screen. Should have an attractive interface: color, nice to look at, not drab black and white. [remember the stickers]
2) Easy data entry. Ideally, as easy, cheap and mobile as the back of an envelope, but better [smile]

Specific

Why do you (not) use a scheduler? How long have you been this way?
1) [answered above]
2) [answered above]
What do you like about electronic over paper?
1) It's cooler. And the gizmo can hold more, like games or ebooks.
2) Integrates with other applications. I'm on a computer a lot anyway.
What do you like about paper over electronic?
1) I like having it written down. I have more confidence it'll stay around.
2) For notes and reminders, paper's just easier to use. Typing in things to do is a pain. Also, I can shove it in my back pocket and take it with me.
What platform or medium would you want for an electronic scheduler? (PalmPilot, computer, etc)
1) Palm, since I'd need to carry it around. But both would be okay so I could upload the info.
2) I don't have a PalmPilot, so it better be on a PC
Any other info you'd like to offer?
1) It'd be cool to be able to personalize the palm itself with a face plate or something; accessorize.
2)No.

Artifact Analysis

Scan of such a task list back of the list

Information

Proceedures

Claims Analysis

Just remembering tasks and meetings
+very easy
+no dependence on physical object
-error prone (remembered wrong)
-no reminder (forgot)
Using a slip of paper as a task list
+portable
+cheap
+permanent record
+easy
-not structured
-not easily copied or reorganized (no backup)
-may be hard to read or become cluttered
-flimsy, suffers wear
Using a scheduler book
+portable if small
+may be cheap (can be leather-bound and pricey too)
+tangible and permanent
+easy
+accessorizable (internally with stickers, externally by cover design)
+include other areas for address book, notes, etc.
-not easily copied or reorganized
-may get cluttered
-need to use habitually
Using a palm pilot scheduler
+somewhat portable
+upload or backup to a computer
+medium includes many more portable applications
-expensive for breakage, loss, or theft
-must have batteries
-possibly cramped interface
Using a computer scheduler
+can backup online, access from anywhere
+exporting of information, including asynchronous meeting arrangements possible
+easy to read
+resortable, reorganizable
+can maintain records for years with no physical space (except for computer)
-not portable
-expensive (need a computer)
-have to boot up and log on before use
-possible loss of data in computer crash or upgrade
-slow to input simple things: selecting fields, typing, organizing

Workplace Themes

Transportable
--small enough to be easily carried
--sturdy enough to sustain damage incurred during transit
--cheap enough to replace if damaged, lost, or stolen
Permanence
--backed up somehow to sustain loss of data (or of the device itself)
--the scheduler feels tangible and reliable
Input
--quick and easy to input
--relationships easy to record (possibly as simply as by how/where the task is input/recorded)
Compatability/Expandability:
--platform should be able to include other applications
(Book scheduler included address book and notes; palm pilot included other applications; even paper slip includes room for notes. Reason to use on computer is already using computer for other things)
Appearance
--should be pleasing in appearance
--customizable, both in the interface and externally, if applicable
Reminder
--users often forget to check if something is due
--(Must be transportable to be a constant reminder)

Problem Scenario

Anastasia is a college student. She uses a colorful scheduler book to keep track of her assignments, her list of things to do, her friends birthdays and anniversaries. She also jots phone numbers and shopping lists in the notes section of the book.

Anastasia starts a Tuesday by checking her scheduler--both today and the next few pages--while riding to campus on the bus. She sees she has an English assignment due today which she has already completed. She is also supposed to stop by Bob's and water the plants today since he's out of town for a few days. (She has the directions and the door key code written down in her notes section.) She has a physics assignment due tomorrow, and she sees that her friend has a birthday on Friday, so she'll have to pick up a gift some time today or tomorrow.

During lunch after class, her friend Shanon asks her if she can make it to a volunteer group meeting next Monday. Anastasia says yes, since she doesn't have class that day. After lunch, she works on her physics homework in the lab. During the lab she remembers she scheduled a session to tutor another student. She checks her scheduler and sees that it's on Monday--the same time as the volunteer group meeting. She'll have to call Shanon and tell her she can't make it after all, unless she can catch up later.

On the way home she waters Bob's plants but decides she'll pick up the birthday gift tomorrow morning.

Comments and Conclusions

The Root Concept is a nice idea. It's a good idea to lay down exactly what we're trying to do before we get distracted by the details. I think it's a good idea to decide whether we're going to produce this product regardless, or are we going to only do it if it's better than what's already available.

The User Interview was helpful early on just to get a feel for unexpected needs and to be exposed to the users. I see now that even my "specific" questions are pretty general. I like that a lot--just trying to get the user to talk without already having a trail already in mind. I didn't expect so much focus on appearance and interface. Yet there's a lot that didn't come through in the interview. For instance, I imagine organizing a meeting, especially of more than two people, is more complex than users imply. (However, no one I've talked to regularly schedules group meetings either.) Also, one reason for using a slip of paper for a task list that wasn't revealed was because it is only temporary--it's often discarded at the end of the week with some tasks incomplete. So talking to users is a good way to get a broad overview, but actually watching them in "the wild" is obviously also necessary.

During Artifact Analysis, I found that there is a fuzzy boundary a simple checklist of tasks and an actual scheduler. Some people seem to prefer to write down tasks by when they need to be done, while some write down tasks related to subject or category. Forcing one or the other organization scheme could be detrimental. Yet there always seems to be some sort of classification or emphasis or relationship encoded just in how or where the tasks are written. Again, seeing these things in action would help.

On the Claims Analysis, more claims are quite possible, but I wanted to focus the current methods and the pros and cons of each. It's hard to be complete and unbiased in listing all the advantages and disadvantages. What some find pleasing, others could care less for, or even dislike.

I have a feeling I strayed on the Workplace Themes. I found I had an urge to start consolidating some of my findings into a "list of groovy scheduler qualities," rather than simply describing the themes of the current state.

I found the Problem Scenario to be only marginally helpful. Yes, it's handy to show to people who don't have all the background info. But as a document to take forward to the next stage, I find it lacking. I guess I would rather have more of a waterfall method document. I imagine some sort of extension of my Themes document, listing all the guidelines or recommendations for a good system, backed up by the research. Some of these guidelines would only apply to some users, and surely there would be contradictions and tradeoffs. But I would feel more confident with a stronger consolidation of the findings.

Actually doing some of these was a good learning experience--it add a lot over just reading about them in the book. Overall, I'd want to do more field work before moving on to design. The other thing is that it sounds like the best scheduler option for the general population is the book form.

Assignment 3: Activity Design-->