ALAO Membership Database Development: Request for Proposals

Functional requirements for the Membership Database:

BASIC

1. Be interactive and web-based.
2. Maintain total counts by each variable. For example: How many members are from The University of Akron? How many members are ACRL members?
3. Record members' preference for use of work or home address.
4. Suppress a member's record from the public web directory based on that member's preference.
5. Be a secure database that allows for a public view and three passworded levels of authority. For example: Certain officials could search and generate reports; other officials could input/delete/change data.
   
   
   1. Level-one administrator rights:
      1. view public data; view general site, not any secured data
      2. search/output/view all data
      3. post files like budget spreadsheet to secure site
      4. post web pages to secure site
      5. input/delete/edit/search/output/view all data/
      6. ability to create accounts for staff users with fewer rights
      7. access to all configurable system options
   2. Level-two administrator rights:
      1. view public data; view general site, not any secured data
      2. search/output/view all data
      3. post files like budget spreadsheet to secure site
      4. post web pages to secure site
      5. input/delete/edit/search/output/view all data/
   3. Level-three administrator rights:
      1. view public data; view general site, not any secured data
      2. search/output/view all data
   4. Level-four rights (public view):
      1. view public data; view general site, not any secured data
   
   
6. Have a flag(s) for each variable that can be set by the local level-one administrator to include or not include the variable in the public view.
7. Support twenty (20) simultaneous logins by authorized staff and officers.
8. Support 100 simultaneous page accesses by site visitors.
9. Accommodate at least 1,000 member records.
10. Be built with a current popular technology like ASP or PHP or the like that dynamically generates web pages from a back-end database.
11. Generate valid HTML.
12. Generate HTML that meets minimum accessibility (ADA) guidelines.
13. Generate web pages that load quickly. (Some staff rely on dial-up ISP.)
14. Store its data in an ODBC-compliant database like SQL or mySQL or the like.
15. Effectively integrate with any Windows client that is delivered (by vendor) to perform specialty applications like mailing label printing.
16. Source code:
    1. Preferred: vendor delivers all source code at install date.
    2. Required: vendor contracts to deliver source code upon separation.
17. Be an extensible system. For example, ALAO officers may decide at a later date to extend the system to track member dues charges and payments. They may decide later to extend the system to handle other budget or financial data. The system designer should make the best possible effort to design the system so that it could accomodate these extensions.
18. Support SSL.
19. Ensure privacy of personal data. If developer hosts the application, specify in detail how member privacy will be maintained.

Please suggest other functionality that you would recommend for such a directory.

SEARCH/SORT

1. Be searchable by one variable (For example: Provide a list of all Directors ) or by multiple variables (For example: Provide a list of members from Kent State that have been members for more than 10 years) (For example: How many members are student members of ALAO AND are ACRL members?)
2. Be searchable by any combination of any number of variables.
3. Provide a primary sort by any one variable; primary/secondary sort by any two variables; primary/secondary/tertiary sort by any three variables.
4. Provide search, count and report on any/every variable.
5. Provide a configurable default sort order that can be modified by a level-one administrator.
6. Allow member to see own complete record by logging on with their own ID/password.

Please suggest other functionality that you would recommend for such a directory.

OUTPUT

1. Have the option to list any or all variables in the output.
2. Generate output in various formats, including:
   1. mailing labels
   2. printed lists
   3. electronic spreadsheets
   4. on-screen reports
3. Allow reports to be saved to a restricted portion of the hosting server, accessible via ID/Password by current officers and staff.
4. Allow reports to be downloaded.
5. Allow reports to be e-mailed.
6. Generate generic tab-delimited file output.
7. Generate tab-delimited spreadsheet file for report.
8. Generate comma-delimited output suitable for import into office products like Microsoft Word mail merge.
9. Generate reports on demand (For example: Provide a mailing list of all members who have indicated that they are interested in Curriculum Centers.
10. Generate reports on established schedules. (For example: generate a list of new members monthly.)
11. Generate e-mail of prescribed texts (form letters) to a set of email addresses gathered via a search (renewal reminders, letters to new members.)
12. Be able to output annoucements to e-mail addesses, from level-one, level-two, and level-three administrators.

Please suggest other functionality that you would recommend for such a directory.

UPDATE

1. Allow member to submit proposed edits to own record to administrative staff.
2. Provide web-based input of selected variable list values for level-one and level-two administrators. ( For example: Values of "Institution" variable must be standardized, like "Miami University." Edits to user records would use a pull-down to select the institution.)

Please suggest other functionality that you would recommend for such a directory.

Variables in the Membership Database.

1. Title (Ms, Miss, Mrs, Mr, Dr, other)
2. Last Name
3. First Name
4. Middle Name/Initial
5. ID and password (secure)
6. Institution (from list of choices)
7. Mailing Address Line 1(work)
8. Mailing Address Line 2(work)
9. City (work)
10. State (work)
11. Zip (work)
12. Mailing Address Line 1(home)
13. Mailing Address Line 2(home)
14. City (home)
15. State (home)
16. Zip (home)
17. Fax
18. Phone
19. E-mail
20. current Membership year (yyyy)
21. Membership history [ e.g. member for 16 years ] This must be a free-text field that can handle various input like: 94, 96-98, 2000
22. Student member (y or n)
23. ACRL member (y or n)
24. Library Type (from list of choices) ( e.g. academic, special, other)
25. Library Position (from list of choices) (position on the job) (e.g. director, assistant director, dept head, staff)
26. Library Unit (from list of choices) (e.g. technical services, public services, archives, systems, other)
27. Position/office (current) within ALAO (from list of choices)
28. Position/office (historical) within ALAO (from list of choices)
29. Liaison for ALAO at place of employment (y or n)
30. Liaison (current) for ALAO to outside organization (from list of choices)
31. Liaison (historical) for ALAO to outside organization (from list of choices)
32. Interest Groups for which member would like more information and/or be willing to participate in (from list of choices)
33. Interest Group membership current
34. Interest Group membership historical
35. Member permission to have information published in online directory (Y or N)
36. Unique record number for individual database entry
37. Cumulative Record of ALAO Annual Conference Attendance
38. Cumulative Record of other ALAO attendance [e.g. workshops]
39. Record of Executive Board Service, office and year
40. URL of personal web page
41. URL of work web page
42. general free-text notes fields with tracking of date of note input

Please suggest other variables that you would recommend for such a directory.

Extent of Service

1. build the membership database
2. maintain the database (code, not content)
3. install the database on an ALAO-affiliated server
4. host the database on your own (vendor's) server
5. provide staff training on install
6. provide staff training on maintenance
7. provide staff training on use
8. other

Please suggest other services that you would recommend for such a project.

Submission Guidelines

1. We are not following a strictly formal bid process, though we would like proposals that are well-organized and address all of the detail in this document.
2. We prefer that you contact us to clarify any questions before submitting a proposal.
3. Proposals should address each numbered item in each section (Specifications, Variables, and Extent of Service,) even if it is only with a "No," or an "N/A."
4. Please itemize costs for each item you respond to in the "Extent of Service" section.
5. You may submit multiple proposals. For example, one proposal to build and sell an application, and a second proposal to build, license, and host an application.
6. Specify technical requirements (hardware, operating system, web server, etc.)
7. Specify guarantees and warranties.
8. Specify limits of liability.
9. Submissions can be paper or electronic.
10. Electronic submissions should be in text, email, Microsoft Word, and/or Microsoft Excel. If you wish, you can post your proposal on your own secure web site and send us access details.
11. Specify who can modify source code.
12. Specify any update and/or maintenance costs.
13. Specify timeline that indicates the time periods (in # of calendar days) that will obtain between these events:
    1. contract
    2. delivery
    3. testing
    4. production
    Timeline to be finalized by vendor and ALAO Board at contract signing.
14. Submit a draft penalty clause that addresses your (the vendor's) failure to perform.
    Clause to be finalized by vendor and ALAO Board at contract signing.
15. ALAO reserves the right to reject any and/or all proposals.
16. Proposals become the property of ALAO and cannot be returned.
17. ALAO will keep all proposals confidential.

Project Timeline

1. Public RFP, Fall 2001.
2. Proposals accepted until the right system is found at the right price.
3. Goal for system deployment: Summer 2002.