Home
Minutes
Requirements
Design
User
Documentation
Javadoc

logo

Requirements Specification

CS 262
Calvin College
Professor Keith Vander Linden
Written October 9th 2005
Revision 1.2

Table of Contents

  1. Introduction
    1. Document Purpose
    2. Project Vision
  2. Project Plan
    1. Process Model
    2. Schedule
    3. Resources
    4. Infrastructure
    5. Risk Analysis
  3. Use Case
  4. Non-Functional Requirements
  5. References

  1. Introduction

    1. Document Purpose

      This is the requirements specification for EasyTalk, a product of the Kühabrlüst project. It contains the Kühabrlüst project's vision, the domain and functionality of EasyTalk, and the basic user-level features that EasyTalk will provide. It also contains the Kühabrlüst project's process model, team organization, scheduling, Gantt chart, management reporting, the Kühabrlüst project's stakeholders, hardware, software and system requirements, use case diagram and user descriptions.

    2. Project Vision

      People traveling to foreign countries often have difficulty communicating with the local people. Minor things such as ordering in a restaurant or finding a restroom can be impossible if you are unable to find someone who speaks your language. EasyTalk will be an easy-to-use Palm-based program that allows you to quickly and easily search for commonly-used phrases. It allows you to search in both directions, enabling you to find out what the guy at the bar just called you and to come up with an appropriate response. Due to the limited size of the phrase database we also offer the ability to translate your phrase using Google language tools.

    (back to top)

  2. Project Plan

    1. Process Model

      The development of EasyTalk will follow a spiral software development model, and a democratic organizational structure will be used for team administration.

    2. Schedule

      Here is our roadmap for project completion

      1. Gantt Chart (screenshot) (Excel Spreadsheet)

        A schedule for the semester to keep us on-track.

      2. Management Reporting

        The Kühabrlüst team will meet at least once a week at a time to be determined at the end of the last weekly meeting. Notes will be taken at each meeting and will be recorded in the form of minutes afterwards. These minutes will be kept on file but not submitted unless requested by the customer. At the end of each meeting the agenda for the next meeting will be determined and recorded in the minutes.

    3. Resources

      The members of the kühabrlüst team are Tim Brom, Brian Lubben, Dave Hanson, Matt Kummershek and David Streng. Other stakeholders include Keith Vander Linden, the customer who will evaluate the quality and effectiveness of the system and foreign travelers who will make up our userbase once the product ships.

    4. Infrastructure

      Hardware, software and support necessary for project completion

      1. Necessary Hardware
        • PC for development

          A PC with WSDD installed for development of the software for the Palm.

        • PDA

          A Palm device for testing real-world usability.

        • Server

          A computer with a relational database system and a scripting environment for handling translation requests from the application.

      2. Necessary Software
        • WSDD

          Development environment for writing the palm application

        • Database system

          Database for storage and retrieval of translation data

        • Web server with support for CGI

          Web server to handle translation requests from the palm device

        • Perl

          Our backend script is written using the Perl scripting language

      3. Necessary Support/Documentation
        • WSDD/J2ME resources

          References for help developing the palm application

    5. Risk Analysis

      Potential problems that will come up in the course of project development

      • As the semester advances team members get busier. Finding time for working on the project may become problematic.
        Response: Make sure our goals are realistic and we manage our time wisely
      • Some features may be more difficult to implement than originally anticipated.
        Response: Make sure our focus remains on the core of the project.
      • Unable to translate the phrase at all, using either the database or Google translate.
        Response: Give the user a message asking them to reword the phrase.
      • Google/Babelfish returns a wrong translation.
        Response: Make sure the user knows that the translation is coming from Google/Babelfish and that the translation may or may not be accurate.
      • Arguments may arise out of differences of opinion on implementation details.
        Response: Subject all decisions to a simple majority group vote.

    (back to top)

  3. Use Case

    Use case diagrams for EasyTalk

    use case

    Prioritized use case diagram

    prioritized use case

    (back to top)

  4. Non-Functional Requirements

    (back to top)

  5. References

    (back to top)