eGroup

Requirements Specification

Computer Science 262
Calvin College
Professor Keith Vander Linden
Written March 11th, 2004
Revision 1.1, Last Modified March 11th, 2004

Table of Contents

  1. Introduction
    1. Purpose
    2. System Vision
  2. Project Plan
    1. Process Model
    2. Schedule
    3. Resources
    4. Hardware, software, systems/technical support
    5. Risk Analysis
  3. Use Cases
  4. Non-Functional Requirements
  5. Bibliography
  6. References

I. Introduction

  1. Purpose

    This document is a requirements spec for eGroup's project, that contains eGroup's system vision, what eShopper will do, the domain of eShopper, and the basic high-level features that the user wants from eShopper. It contains eGroup's process model, team organization, detailed vision of scheduling, the Gantt chart, management reporting and lists people involved as well as the hardware, software and system requirements This document also includes a Rational Rose use case diagram, with use case and user descriptions.

  2. System Vision

    Almost everyone has to do grocery shopping. Many people make lists on paper of what to buy, others keep lists of what they need in their head. Still others just go to the store and buy whatever strikes their fancy. In any case, people tend to decide what they want to eat and use, and then buy food and products that meet their wants and needs. Additionally, it can be a time consuming task to plan out meals, figure out which ingredients are needed for these meals, writing these out in a list, and going shopping for the items. Many people have PDAs today, and there are already shopping list applications for the PDA. Unfortunately, it is cumbersome to have to do all of the list management on the PDA with a stylus.

    eGroup will make these tasks easier by making it possible to do the management on the desktop, and transfer the data to the PDA for shopping checkoff. We will be creating an application that will allow people not only to plan out their meals, but easily create shopping lists from meal plans and share recipes with others. There will be a central web site where people can download recipes and share their recipes with others. Users can rate the recipes they have tried, search for new ones and download layouts of local stores to arrange the grocery list by aisle. These can be imported into a desktop application, and meals can be arranged in a schedule. Users will not be restricted to downloading recipes from the web site, but will also be able to add recipes with the desktop application. From that point, they will be able to choose the meals they plan to make that week, and a shopping list will be automatically generated. They can then add to the list shopping items not included in any meal. This list can be synced with a PDA, so that the user can just carry it with them in the store.

(back)

II. Project Plan

  1. Process Model

    Our team will be organized by a hybrid structure, splitting the management into the technical, headed by Adam Goforth, and administrative, headed by Pam Betten. In developing our software we will use the synchronize and stabilize model.

  2. Schedule
    1. Gantt Chart Screenshot  Excel File
    2. Management Reporting

      Members of eGroup are required to attend customer and group meetings at the scheduled times, or make other arrangements with the administrative manager. Meeting agendas will be due by the beginning of each meeting, and meeting minutes will be due within two days of each meeting. The agendas and minutes will be completed by the administrative manager unless otherwise specified. Computer Science 262 class attendance and fulfillment of class requirements is highly recommended for each member of eGroup by the administrative manager in order to effectively contribute to the group project.

  3. Resources

    1. Stakeholders: Members of the Design Team
      • Adam Goforth
      • Pam Betten
      • Jim Laing
      • Shahzad Qureshi
      • Nathan Edwards

    2. Stakeholders: Other individuals with an interest in the project
      • Keith Vander Linden: He will ultimately evaluate the quality and effectiveness of the system.
      • Current users of PDA shopping programs: This is the initial user base, both for the desktop application and the online community.
      • People who buy food at the grocery store: These individuals are potential users of the system.
      • Current developers of PDA shopping programs: The system will strive for integration with these applications.
      • Web host: Webspace must be secured for the web-related element of the system.
      • Store managers, owners, and workers: The employees of the stores.

  4. Hardware, software, systems/technical support

    1. Hardware needed to design eShopper
      • A PC with a GUI (Graphical User Interface)
      • A PDA
      • A web host

    2. Software needed to design eShopper
      • A Java SDK on the PC

    3. Technical Support resources for additional design help
      • HandyShopper Documentation
      • Email list/contact with HandyShopper group

  5. Risk Analysis

    Time constraints for completing the project.
    Especially as the semester progresses and the team members get busier, we may have problems finding the time to put in the work necessary to complete the project.
    Response: Be disciplined in our time usage and realistic in our goals.

    Programming difficulties.
    Some features may be difficult to implement and some bugs may be very elusive.
    Response: Focus on core subset of features, not including any that are unreliable or broken.

    Inadequate hardware for testing and development (e.g. a palm).
    It will be difficult to make the program without the platform to test on.
    Response: Borrow handspring PDA for the sections that require a PDA.

    Difficulty interfacing with existing PDA applications.
    As we are using existing applications as black boxes, there could be difficulty getting our application to work with them.
    Response: Use HandyShopper documentation and users group if help is needed. Work with other shopping application development group to integrate with their product

    Lack of cooperation and communication.
    Due to different schedules and domains of the project, people could be working on different parts of the project at the same time. It will be essential that working communication exists.
    Response: We need to rely on the hybrid group structure to delegate responsibility to the appropriate people and ensure good communication.

    Artistic disagreements.
    As in any creative effort different people will have different ways of doing things and they could be in conflict.
    Response: Subject decision to a popular vote. The ultimate decision goes to the appropriate leader when necessary.
(back)

III. Use Cases


The actor in this use case is the shopper. On the left you can see the shopper can edit the shopping list, recipes (along with food items for these two) and the calendar view. At the bottom the shopper can import or export recipes to and from the recipe web host site. The bottom right shows the users ability to edit the layout of a store where he/she would go shopping. At the top the shopper can view the calendar or the recipe and sync to the PDA. Finally, at the right the shopper can clear the list, or move the entire meal plan calendar back by a day.

The complete Rational Rose MDL File is available here.

IV. Non-Functional Requirements

V. Bibliography

VI. References

(back)