IBNU – Requirements Summary

Purpose
The purpose of this document is to define the system and environmental requirements for
an online student incentive system, sponsored by a regional professional. There are other
related documents including:
• Business Context Diagram
• Navigation Diagram
• Wireframes
• Features List
• Data Model

Overview
The web site referred to here as “IBNU” will help a sponsor (e.g. a local doctor) gain PR
in their community by sponsoring an goal-oriented academic incentive web site through
one or more local schools. Schools will be approached first by IBNU staff to solicit their
interest in the program. Then sponsors will be found in their region who want to
participate. A sponsor will have exclusive rights to the program through a given school.
The schools will promote the web site to the parents, who will register and then sign up
their kids. For the system to be effective, Parents must use the personal incentive program
to reward their children. They do so by setting up point-based goals and then giving
behavior-based tickets to their children. These tickets help children achieve goals and win
parent-provided rewards. A grand prize will be offered by the sponsor and given away at
a school PR event.

Roles
The following roles (job functions) affect and/or are affected by the system:

1. Public – people who visit the site to learn about the program
2. Student – a child who redeems tickets for rewards from a parent and who may also
win a grand prize from the Sponsor
3. Parent – the parent of a child in the incentive program.
4. Sponsor – the local organization that financially provides this program through one
or more schools
5. School – an Elementary school, Jr. High, High School
6. Staff – Customer personnel set up sponsors, schools, etc.

Customer (IBNU) will conduct interviews of sponsors, schools, parents, and the kids audience
during the “mock-up” stage of the project and solicit their feedback on the the design.

Goals
The business goals for this solution are:
• High quantity of participants
• Maximum exposure for the sponsor
• Zero complaints or issues for the schools involved
• Minimum support needs for IBNU staff

11/14/2007 Dynamic Answers, Inc. Page 1 of 4

 IBNU – Requirements Summary
Design goals for the solution are:
• Simple for Parents
• Fun for kids
• Standard technologies
• Fast for everyone

Design Drawings
The design drawings included with this blueprint are intended to show functionality and
do not constitute a full graphical treatment of the user experience. Builder should treat all
visual elements as preliminary and offer their own concepts during design approval.

Web Links
Always open external links (e.g. school web site) in a new browser window.

Marketing Links
Each instance of a Sponsor’s marketing graphic should also be a link to the sponsor’s
profile in IBNU. From the Sponsor profile, we will link to the Sponsor’s web site.

Risk Matrix
The following are perceived risks to the project. This list will be expanded in the
construction proposal. Severity of impact will be High, Medium, or Low.

Risk Impact
Not enough sponsor interested High
Not enough schools interested High
Not enough parents interested High
Capacity is underestimated Low
Fraud (fake ticket numbers) Low

Capacity
In the first 24 months, IBNU desires to sign up (A) 200 sponsors. Each sponsor will
support a program for an average of (B) 2 schools. Participation at each school, on
average, is estimated at (C) 100 children. Each student will receive an average of (D) 50
tickets during the year. The system capacity, therefore, must accommodate a minimum of
A x B x C x D x 2 years = 4,000,000 tickets. Since tickets are purged when the academic
year is archived, the system will only have to support peak capacity toward the end of the
school year.

Performance
Based on the above capacity estimates, at the end of year 2, the system must
accommodate a typical demand of 200 sponsors x 2 schools x 100 students = 40,000
transactions per day. Based on this demand estimate, the system should perform well
using any of the mainstream relational database products, given that the coding of the

11/14/2007 Dynamic Answers, Inc. Page 2 of 4

 IBNU – Requirements Summary
application is also efficient. The response requirement is 2 seconds or less for any page in
the application.

Hosting
IBNU will be an internet application hosted on a shared server. Security and performance
considerations do not justify the leasing and maintenance of a dedicated server during the
first year. After the first year, the server hosting situation should be reviewed in light of
the projected demand curve to see if performance will degrade significantly over time
using a shared server.

Test Environment
Pre-rollout: Build will test in their own labs, using the same technologies as required by
the agreed-upon solution. Customer will be given access from time to time in order to test
and give feedback on various phases of the project.

Post-rollout: After the system is “live” (rolled out), each release (a collection of
enhancements or other changes to the software) will be staged on the builder’s server for
testing and approval by the customer. Once approved, the release will be applied to the
production server.

Maintenance
Customer requires an ongoing relationship with the builder so that bugs discovered in the
production version can be fixed rapidly and scheduled enhancements can be added. A
separate maintenance agreement must be included with the solution proposal.

Quality Control
A given feature will be considered usable, and therefore complete, when it functions
according to the written requirements for the project.

The builder will supply a construction standards document. This standard will be
approved by the buyer and shall be used to insure internal code quality.

Ownership
The system to be developed will be the sole property of the Customer and the Customer
will retain all rights of authorship, licensing, branding, and use. The builder is being
asked for design and construction services and is to build this web application as a “work
for hire.”

Source Code
Source code used in the construction of the web application will be archived on CD-
ROM media and given to the Customer every 30 days and upon the completion of the
project. Builder may retain a copy of the source code for maintenance purposes only.

Backups
Data backup services are required as part of the solution. The Customer’s data must be
safeguarded against loss to the builder, loss to the data center, and loss to the Customer’s
11/14/2007 Dynamic Answers, Inc. Page 3 of 4
 IBNU – Requirements Summary
own infrastructure. Present a backup strategy as part of the solution proposal. Include at
least one method for the Customer to download and archive their data from the online
server. Example of use: Prior to scheduled maintenance by the hosting company,
Customer will likely want to export all data for safety purposes.

User Manual
No user manuals or help systems are desired. The system should be easy enough to use
without the aid of a printed manual or online help systems.

Customer Staff Training

Include up to one full day of train-the-trainer teaching, to be attended by up to five (5)
Customer personnel.

11/14/2007 Dynamic Answers, Inc. Page 4 of 4