Membership List Production System

Submitted June 6, 1997
Accepted with Modifications: June 8, 1997
Revised and Submitted: June 13, 1997
Table of Contents
  1. Product Overview
  2. Processing Environment
  3. System Model
  4. Data Definition
  5. Requirements Specification
  6. Design Considerations
  7. Appendices

  1. Product Overview

    2. After many years of bitter feuding the Association for Polarity and the Collaborative for Neutrality have decided to settle their differences. The result of their agreement is a new organization, the Terminal Institute. The two groups have decided to recognize any existing memberships in the two organizations in the formation of this new organization.

    The Terminal Institute seeks automation of the new organization's membership department. The board of directors realize that successful marketing requires improved information access regarding current subscribers and the ability to target specific market segments. Hence, the board has agreed to fund the development of a system that can provide income potential through targeting specific segments of the intitute's membership population. The income potential is realized through selling mailing lists of members targeted by particular attributes defined by the requesting organization.

    The operational scenario for the system indicates that the clerk receives requests for reports and mailing lists in the form of report and list specifications. The clerk then activates that portion of the system to generate the requested material. Material generated can be produced in either hardcopy or file formats. File formats (disk-based files) are kept on the system until the end of the business day, at which time the clerk transfers to the requestor according to the guidelines provided.

  2. Processing Environment

    3. System must run in a maximum of 32Mb of RAM with existing applications. Current usage indicates approximiately 1Mb of RAM available for program and data.

    External storage requirements are based calculations for a member record of 176 bytes (see Data Defintion) and an estimate of 20000 members yielding the need for 3520000 bytes for the membership list. Additional storage is needed for lists generated and saved to disk. Any mailing list required 143 bytes per entry. With the maximum of 20000 entries any mailing list could occupy 2860000 bytes of space. Multiple lists therefore could consume considerable space. It becomes a matter for the users to manage their external storage to contend with the generation and saving of multiple mailing lists.(see design consideration 1)

  3. System Model

    4. Context Diagram
    Figure 1

    3.1 Membership List Conversion Process

    List Conversion Process
    Figure 2

    List Conversion Process 2
    Figure 3

    3.2 Generator

    Generate Lists and Reports-Level 1
    Figure 4

    Result Generation Process
    Figure 5

  4. Data Definition

    5. Data Formats

    See appendix for guidance on notation.

    MembershipList={Member} (MembershipList is to be maintained in ascending alphabetic order based on Member name (lastname+firstname+initial))

    Member=FirstName+(Initial)+LastName+PersonalInformation+MemberInfo+MailAuthorization+[HomeAddress|BusinessAddress]

    MailingList={MailingInfo}

    MarketList={MailingInfo} (every entry on a market list must from a record where MailAuthorization=TRUE)

    MailingInfo=[BusinessMailing|HomeMailing]

    BusinessMailing=Name+<newline>BusinessName<newline>+(Location)<newline>+StreetAddress<newline>+City+", "+State+" "+Zipcode

    HomeMailing=Name+<newline>+StreetAddress<newline>+City+", "+State+" "+Zipcode

    Name=FirstName+(Initial+".")+" "+LastName

    HomeAddress=StreetAddress+City+State+Zipcode

    BusinessAddress=BusinessName+Location+StreetAddress+City+State+Zipcode

    PersonalInformation=SSN+Gender+DateOfBirth+MaritalStatus

    MemberInfo=MemberNumber+MembershipDate+MemberType

    LastName=NameString
    FirstName=NameString
    Initial=Character
    MailAuthorization=[TRUE|FALSE]

    BusinessName=NameString
    Location=NameString (used to identify a room, mail stop, or building otherwise empty)
    StreetAddress=AddressString
    City=NameString
    State=2{"A".."Z"}2
    Zipcode=5{digit}5+("-"+4{digit}4)

    SSN=9{digit}9
    MemberNumber=5{digit}5
    MembershipDate=DateString
    DateOfBirth=DateString
    MemberType=["Gold"|"Silver"|"Bronze"]
    MaritalStatus=["Single"|"Married"|"Divorced"|"Widowed"]
    Gender=["Male"|"Female"]

    DateString=Year+Month+Day
    NameString=1{character}20
    AddressString=1{character}30
    Year=["19"|"20"]+2{digit}2
    Month="01".."12"
    Day="01".."31"
    character=["A".."Z"|"a".."z"|"'"|"."|" "]
    digit="0".."9"

    Report Formats

    Reports generated for management are frequency distributions represented in either tabular or bar graphical form.

    Mailing lists and market lists are provided in either column format where the clerk specifies the number of columns (1-4) needed. For columns greater than 1, the names appear horizontally first then proceed to the next row.

  5. Requirements Specification

    1. Produce a single, unduplicated, ordered (ascending based on name) membership list from the Neutrality and Polarity membership lists.

    2. The system shall maintain a list of all members of the organization.

    3. The system shall maintain the following information on each member:
      • name
      • mailing address (business or home)
      • gender
      • marital status
      • date of birth
      • subscription date
      • membership category (Gold, Silver, Bronze)
      • membership id
      • SSN
      • mailing authorization

    4. The system should generate the following membership mailing lists on demand:
      • all subscribers
      • all subscribers with a certain membership category

    5. The system should generate the following members market lists on demand:
      • all subscribers giving mailing authorization
      • all mailing authorized subscribers of a particular gender
      • all mailing authorized subscribers in a specified age range
      • all mailing authorized subscribers by marital status

    6. The system should generate the following demographic reports of all members on demand:
      • distribution of subscribers by age category
      • distribution of subscribers by gender
      • distribution of subscribers by subscription length
      • distribution of subscribers by age category by gender
      • distribution of subscribers by age category by subscription length
      • distribution of subscribers by gender by subscription length
      • distribution of subscribers by gender by age category by subscription length
      • distribution of subscribers by marital status
      • distribution of subscribers by marital status by age category
      • distribution of subscribers by marital status by gender
      • distribution of subscribers by marital status by age category by gender

    7. The system should generate market lists as either hardcopy or file based on user preference.

    8. The system should allow the user to describe the format of output for mailing lists.

  6. Design Considerations

    1. Dealing with space available on the external device is not a design issue. The issues related to adequate space is the concern of the clerk. It is however proper to expect the clerk to enter a full path specification to save a file.

    2. Though the initial problem as described indicates this is simply a report generation system, it is clear that is the initial set of requirements. The next release of the system is probably relatd to the moving the system to include complete membership maintenance (adding, deleting and modifying membership information). Considering that it seems reasonable to include a way of indicating status in the creation of the Terminal Membership file.

    3. Requirement 3 specifies the information that must be maintained for each members. The previous item in the design considerations lists indicates the potential need for a current flag. Other than the items listed and the current flag there are no constraints on the organization of that structure.

  7. Appendices