Requirements Document

Police Activities League Program Involvement

Tracking Project
Table of Contents
1

INTRODUCTION.............................................................................................3

1.1

Overview.................................................................................................................3

1.2

Goals and Objectives.............................................................................................3

1.3

Scope.......................................................................................................................3

1.4

Definitions...............................................................................................................4

1.5

Document Conventions.........................................................................................4

1.6

Assumptions...........................................................................................................4

GENERAL DESIGN CONSTRAINTS.............................................................4

2.1

Product Environment............................................................................................4

2.2

User Characteristics..............................................................................................4

2.3

Mandated Constraints...........................................................................................4

2.4

Potential System Evolution...................................................................................4

NONFUNCTIONAL REQUIREMENTS...........................................................5

3.1

Operational Requirements....................................................................................5

3.2

Performance Requirements..................................................................................5

3.3

Security Requirements..........................................................................................5

3.4

Safety Requirements..............................................................................................5

3.5

Legal Requirements...............................................................................................5

3.6

Other Quality Attributes.......................................................................................5

3.7

Documentation and Training................................................................................5

3.8

External Interface..................................................................................................6

Last Modified: 1/11/2017

Page 1 of 13

Requirements Document

3.8.1
3.8.2
4

User Interface...................................................................................................6
Software Interface............................................................................................6

SYSTEM FEATURES......................................................................................6

4.1
Feature: Youth Database.......................................................................................7
4.1.1
Description and Priority...................................................................................7
4.1.2
Use-case: New Registrant................................................................................7
4.1.3
Additional Requirements.................................................................................7
4.1.4
Description and Priority...................................................................................7
4.1.5
Use-case: Youth Update...................................................................................8
4.1.6
Additional Requirements.................................................................................8
4.2
Feature: Youth Tracking.......................................................................................8
4.2.1
Description and Priority...................................................................................8
4.2.2
Use Case: Youth Login....................................................................................8
4.2.3
Additional Requirements.................................................................................9
4.2.4
Description and Priority...................................................................................9
4.2.5
Use-case: Youth Logout...................................................................................9
4.2.6
Additional Requirements...............................................................................10
4.2.7
Description and Priority.................................................................................10
4.2.8
Use-case: Administrator comments...............................................................10
4.2.9
Additional Requirements...............................................................................10
4.3
Feature: Administrator Access...........................................................................10
4.3.1
Description and Priority.................................................................................10
4.3.2
Use Case: Administrator Login.....................................................................10
4.3.3
Additional Requirements...............................................................................11
4.4
Feature: Database Search...................................................................................11
4.4.1
Description and Priority.................................................................................11
4.4.2
Use-case: Searching the Database.................................................................11
4.5
Feature: Reports..................................................................................................11
4.5.1
Description and Priority.................................................................................11
4.5.2
Use-case: Report Generator...........................................................................11
4.5.3
Additional Requirements...............................................................................12
5

APPENDICES...............................................................................................12

5.1

Appendix A...........................................................................................................12

5.2

Appendix B...........................................................................................................12

Authors Jared Wight

Last Modified: 1/11/2017

Page 2 of 13

Requirements Document

1 Introduction
1.1 Overview
This document defines the requirements for the Program Involvement Tracking Project
currently under development for the Kansas City Police Activity League (PAL). This
document is designed to be beneficial to both the user/customer as well as the
development team. From this document the user will be able to determine our
understanding of the requirements and verify their accuracy. The development team will
be able to use it while developing the software system to ensure that the customer
receives the expected product.
The PAL Program Involvement Tracking Project (PALPIT) will be a web-based system
capable of tracking youth use of three PAL facilities. The system must be easy to use and
allow quick youth login when entering facilities. Several report formats are desirable to
provide quick access to data.
[eeb: good intro]

1.2 Goals and Objectives

PALPIT Goals:
1. Develop database in a format that is maintainable and updatable by customer.
2. Provide a quick and reliable youth login process
3. Develop a user interface that allows customer to enter and access data in an
interactive environment
4. Develop reporting features

1.3 Scope
PALPIT will provide the ability to store information about youth users of PAL facilities in
a database which will be searchable on any field. PALPIT will also provide the ability to
track the use of PAL facilities by registered youth users and store this information in a
database.

Last Modified: 1/11/2017

Page 3 of 13

Requirements Document

1.4 Definitions
(this section will be expanded in later versions)
Use case describes a goal-oriented interaction between the system and an actor. A use
case may define several variants called scenarios that result in different paths
through the use case and usually different outcomes.
Clock-in time at which a youth participant begins to use a PAL facility
Clock-out time at which a youth participant exits a PAL facility
Registered Youth a PAL facility user who has a record in the youth database
Registrant (see Registered Youth)
Youth Database where information about registered PAL facility users is stored
PAL Police Activity League
PALPIT Police Activity League Program Involvement Tracking Program

1.5 Document Conventions

TBD used to indicate information that still needs to be gathered from the customer
Unknown used to indicate an implementation option that has not yet been decided upon

1.6 Assumptions
It is assumed that all three PAL facilities will have browser based access to a central
server.

2 General Design Constraints

2.1 Product Environment
The PALPIT software will reside on the central server. Administrators will be able to
access the information contained in the database, as well as to generate predefined reports
from remote locations. [eeb: good clarification. This is also a section where you could
mention that the system will be running in an open area that might be subject to rough
treatment. Could also mention that at least one portion will be in an unsecured area.]

2.2 User Characteristics

Youth Primary and Secondary students with varying computer proficiencies.
Volunteers Adults with computer knowledge sufficient to navigate a web-based
interface. These users will be inputting and/or modifying youth registrant information
only.
Administrators Adults with computer knowledge sufficient to navigate a web-based
interface. These users will be accessing the information and generating reports to assess
how the facilities are being used. They will also help the youth interact with the system.
Last Modified: 1/11/2017

Page 4 of 13

Requirements Document

2.3 Mandated Constraints

There are no constraints at this time. However, there are still key decisions which need to
be made (by the customer) which may impose constraints.

2.4 Potential System Evolution

The PALPIT software will most likely be updated in the following ways:
Add new activities for youth users to choose from [eeb: will you provide
procedure for this until it can be automated?]
Add additional youth user information fields (stored in database)
Produce new reports

3 Nonfunctional Requirements
There are no nonfunctional requirements at this time. [eeb: au contraire, usability,
maintainability (talk to the pharmacy teams this semester if you dont think
maintainability is a non-functional requirement), ]

3.1 Operational Requirements

There are no operational requirements at this time.

3.2 Performance Requirements

No requirements for speed have been set forth.
Memory requirements will be nominal (exact size is not known at this time) as the
database will be holding information for approx. 200 people. Queries on this database
should take no more than 4 seconds.

3.3 Security Requirements

Only one type of user will have access to the database information. Therefore, only one
user level is needed. The database will hold some confidential information about the
youth who use the PAL facilities. Only users who are authorized to see the information
should have access to it.

3.4 Safety Requirements

There are no safety requirements at this time.

3.5 Legal Requirements

(See security requirements)

Last Modified: 1/11/2017

Page 5 of 13

Requirements Document

3.6 Other Quality Attributes

There are specific sections above for non-functional quality attributes such as security,
performance, etc. In this section describe any other non-functional quality attributes such
as portability, availability, etc.

3.7 Documentation and Training

The PALPIT documentation will consist of two major portions one dealing with the
administrator features, as well as one dealing with the youth features. Training will be
provided to a select group of administrators on administrator and youth features.

3.8 External Interface

3.8.1 User Interface
Youth InterfaceThe youth interface should have a fun interface which will keep the attention of kids long
enough for them to enter the following information:

Identification (type of identification has not yet been finalized)

Whether the user is coming or going
Activity the user will be using at the facility

Administrators will need to guide the youth through the clock-in procedure at least
once and possibly multiple times.
Administrator InterfaceThe administrator interface will have a more professional appearance geared towards
adults. The interface will provide the following options:
Multi-field database query
Generate predefined reports
Produce custom report
[eeb: good]

3.8.2 Software Interface

Unknown.

4 System Features
Last Modified: 1/11/2017

Page 6 of 13

Requirements Document

4.1 Feature: Youth Database

The Youth Database will be where all of the information about the users of the PAL
facilities will be kept. This section describes how new registrant information will be
added to the database.

4.1.1 Description and Priority

The New Registrant process allows a volunteer or administrator to add an unregistered
youth to the database.
Cost: medium
Risk: low
Value: high

4.1.2 Use-case: New Registrant

Actors: volunteer or administrator
Description: The use-case begins when an unregistered youth submits a registration form
(hard copy). It is assumed that the administrator or volunteer has already completed the
login process.
Basic Path:
1. The user will be prompted to enter all of the information found in Appendix A
2. The user will enter at least the information which is required to register
3. The information will be recorded in the database and acknowledgement sent back
to the user.
Alternate Path:
1. If step 2 is unsuccessful the user will see an error message on screen indicating
what information still needs to be provided
2. The user will then be prompted to go back and fill out the remaining required
items
3. The user now returns to step 2 of the Basic Path

4.1.3 Additional Requirements

N/A

4.1.4 Description and Priority

The Youth Update process allows an administrator to modify or delete any information in
a registrants record.
Cost: medium
Risk: low
Value: medium

Last Modified: 1/11/2017

Page 7 of 13

Requirements Document

4.1.5 Use-case: Youth Update

Actors: administrator
Description: The use-case begins when after the user has logged in to the administrator
interface and wishes to update a registrants information.
Basic Path:
1. The user will navigate to the youth update page
2. The user will be prompted to enter the name of the person whom they will be
updating information on
3. The user will be presented with all information about the registrant stored in the
database
4. The user will be able to modify any of the information
5. The user will enter changes into the appropriate fields
6. The user will submit the changes
7. The system will update the registrants record

4.1.6 Additional Requirements

The administrator will be able to add a new registrant or delete a current registrant.

4.2 Feature: Youth Tracking

The Youth Tracking portion of the software will allow administrators to keep track of
how much time registered participants use the facilities, as well as how they use the
facilities (i.e. what activities they participate in).

4.2.1 Description and Priority

The Youth Login Screen Access will allow an administrator or volunteer to bring up the
youth login screen.

4.2.2 Use Case: Youth Login Screen Access

Actors: administrators or volunteers
Description: The use case begins when an administrator or volunteer wants to display the
youth login screen.
Basic Path:
1. User opens a web browser and navigates to the web-interface of the system
2. User will choose the Youth Login Screen option from a list
3. System will prompt user for a username and password
4. User will enter username and password
5. System will verify username and password
6. Youth Login Screen will be displayed

Last Modified: 1/11/2017

Page 8 of 13

Requirements Document

Alternate Path:
1. if step 5 fails user will be notified that the username or password entered was
incorrect
2. user will be prompted to reenter username and password
3. return to step 5 of basic path
4. if login fails 3 times user will be prompted to have their password sent to their
email address

4.2.3 Additional Requirement

N/A

4.2.4 Description and Priority

The Youth Login will gather the following information:
Identification information
Time the user begins using the facility
What activity the user will be using
Cost: medium
Risk: low
Value: high

4.2.5 Use Case: Youth Login

Actors: Registered Youth
Description: The use-case begins when the registered youth enters the PAL facility to
participate in an activity.
Basic Path:
1. User is prompted to provide identification to the system
2. User provides identification to system
3. System verifies the identification. If the id is verified the system will store the
current time as the users clock-in time.
4. System prompts user to select which activity they will be participating in
5. User selects which activity (or activities) they will be participating in
6. System stores the activity and notifies user of successful login
7. System returns to Youth Login Screen automatically
Alternate Path:
1. If step 3 is not completed this indicates that the system does not recognize the
users identification information. The system will prompt the user to retry
inputting the identification information. If retry is successful use-case resumes at
step 4 of Basic Path. If retry is unsuccessful use-case proceeds to step 2 of
Alternate Path.
2. System notifies the user that they are not recognized by the system and, therefore,
will require assistance from an administrator.
3. Return to step 7 of basic path
Last Modified: 1/11/2017

Page 9 of 13

Requirements Document

4.2.6 Additional Requirements

N/A

4.2.7 Description and Priority

The Youth Logout will store the time that the registered youth participant leaves the PAL
facility.
Cost: low
Risk: low
Value: high

4.2.8 Use-case: Youth Logout

Actors: Registered youth who have been using a PAL facility
Description: The use-case begins when the registered youth finishes participating in an
activity at a PAL facility.
Basic Path:
1. System prompts user for identification information
2. User provides identification information to system and indicates to the system that
they are clocking out
3. System verifies that the user is currently clocked-in
4. Upon verification system stores the clock-out time and notifies user of successful
clock-out
5. System returns to Youth Login Screen automatically
Alternate Path:
1. If step 3 is not completed this indicates that the user never clocked in.
2. System will prompt the user to select which activity (or activities) they have been
using
3. User selects which activity (or activities) they have been using
4. System stores this information and notifies user of successful clock-in
5. Return to step 5 of basic path

4.2.9 Additional Requirements

If a user fails to clock out, the system will automatically store the closing time of the
facility as the users clock out time. Administrators will have the ability to edit clock-out
times if needed. [eeb: good]

4.2.10

Description and Priority

The administrator will be able to add comments to the record of a registered youth
participant.
Cost: low
Risk: low
Last Modified: 1/11/2017

Page 10 of 13

Requirements Document

Value: medium

4.2.11Use-case: Administrator comments

Actors: administrators
Description: The use case begins after the administrator has logged in and wishes to add
a comment to the record of a registered youth.
Basic Path:
1. The user will navigate the administrator user interface to the page that prompts
the user to identify the registered youth they wish to comment on
2. The user will identify the youth they intend to comment on
3. The user will be prompted to enter the comment
4. The user will enter and submit the comment
5. The system will store the comment in the youths record

4.2.12

Additional Requirements

N/A

4.3 Feature: Administrator Access

4.3.1 Description and Priority
The Administrator Access feature will provide a means to access the information stored
in the database.
Cost: low
Risk: medium
Value: high

4.3.2 Use Case: Administrator or Volunteer Login

Actors: administrators
Description: The use case begins when the user decides to access the administrator or
volunteer functions of the system.
Basic Path:
1. The user will open up the web-interface of the system in a web browser
2. The user will navigate to the login page
3. The system will prompt the user for user name and password
4. User will provide user name and password
5. System will verify user name and password
6. The user will be presented with the options listed in Appendix B
Alternate Path:
1. If step 5 is unsuccessful the system will notify the user that the login attempt
failed
2. The user will be prompted to retry the login
Last Modified: 1/11/2017

Page 11 of 13

Requirements Document

3. If the login attempt fails the user will be given one more opportunity to login in
4. If step 3 fails the user will be prompted to have their password sent to their email
address
5. Upon approval by the user the password will be sent to the users email address

4.3.3 Additional Requirements

N/A

4.4 Feature: Database Search

4.4.1 Description and Priority
The Database Search feature will allow administrators to search the database by any of
the information fields in the youth registrant records.
Cost: medium
Risk: medium
Value: medium

4.4.2 Use-case: Searching the Database

TBD

4.5 Feature: Reports

4.5.1 Description and Priority
The Report Generator will produce predefined and custom reports for administrators.

4.5.2 Use-case: Report Generator

TBD

4.5.3 Additional Requirements

N/A

5 Appendices
5.1 Appendix A
Youth Registrant Information

Last Modified: 1/11/2017

Page 12 of 13

Requirements Document

Name
Address
Ethnicity
Age
Sex
School
Student ID #
Date of Birth
Parent Name
Home Phone
Emergency Contact / Phone Number
Medical Insurance Information
Family Physician Name
Family Physician Phone
Hospital Preference
Known Allergies or Medical Conditions
GPA

5.2 Appendix B
Administrator Options
Multi-field database query
Generate predefined reports
Generate custom reports
Update Youth Record
TBD

Last Modified: 1/11/2017

Page 13 of 13