Author(s):
Instructor: Michael Johnson michael.b.johnson@mail.sprint.com
Affiliation: CS 451 Software Engineering (Winter 2002)
Date: February 20th, 2002
Document Version Control Information: 1.0
1.
Introduction
1.1 Purpose of the requirements
document
The purpose of this document is to describe the specifications for the Teach for American Project. It is intended to serve as a model for the team members so the objective of the project is straightforward and concise.
1.2 Scope of the Product
The scope of the product is to allow Teach for America placement personal to efficiently maximize the placement of the available teaching applicants based on location and subject.
1.3 Definitions, acronyms and
abbreviations
VBA – Visual Basic for Applications
TFA – Teach for America
MDB – Microsoft Database file format used by Microsoft Access
MHz – Megahertz (processing speed of the computer)
1.4 References
· Teach for America Application Form (forthcoming)
· Written work flow process (forthcoming)
2. General
Description
2.1 Product Perspective
This product is from the perspective from TFA placement personnel and how they will interface with the software.
2.2 Product Functions
There will be multiple interfaces/forms and options that will allow the user to get the data they are seeking in a timely manner.
2.3 User Characteristics
The TFA placement personal needs to be able to navigate through Microsoft Windows and the Office Suite using a mouse and keyboard.
2.4 General Constraints
Teach for America, being a non-for-profit organization, might not have a large budget allotting for PC equipment. Understanding this, the application must be developed for use on a single workstation, which may not have the processing speed that today’s computers do. This application must also be direct, forward, intuitive and easy to use so that any type of user can use it.
2.5 Assumptions and Dependencies
We are assuming the client has a licensed copy of Microsoft Access 97 running on a system, which meets its minimum specifications. We are also assuming the user has a moderate level of computer knowledge and is familiar with MS Windows as well as other applications such MS Excel and MS Word.
3. Specific
Requirements
3.1 Functional
|
1.) User shall be
able to query the applicants by Region (both “Highly preferred” and
“Preferred”). |
|
Description: A TFA placement person will need the ability to see which applicants chose
a particular region as either “Highly Preferred” or “Preferred”, sorted by
preferred subject, then by the first name. |
|
Criticality: This component is very important to meet the needs of the project,
since it is highly beneficial to be able to clearly see all the applicants
who could potentially be used in a particular region. |
|
Technical
Issues: There will have to be a prompt or pull down menu that allows the user
to select the particular region they are interested in and then have the resulting
query of applicants to ONLY apply to the chosen region. |
|
Dependencies with
other requirements: There must be at least one person in that
has chosen that region as either “Highly Preferred” or “Preferred” or the
result of this query could be NULL or blank. |
|
2.) User shall be
able to run a query such that a particular Region (say Highly Preferred)
along with a particular Subject (say Highly Preferred as well) so that the
“optimal” applicant list is presented to the end user. |
|
Description: The TFA placement person needs the ability to see an optimal, but
precise number of available applicants who can teach say math in a particular
region. Presently, this is a
completely manual process, which is very labor intensive and time consuming. |
|
Criticality: This component is very important to meet the needs of the project, so
that the manual process of shuffling applications is completely eliminated. |
|
Technical
Issues: The user will need to have some kind of button (perhaps on the
switchboard) that prompts them for first region, then type of class, which
will then be passed to a query, which is presented in the form of a
report. The output should be the
optimal, concise list of applicants, who can teach the particular type of class
in the particular region chosen by the TFA placement person. There could potentially be some regions
where there is no applicant that fits the need exactly. |
|
Dependencies with
other requirements: There must be at least one person in that
has chosen that region as either “Highly Preferred” or “Preferred” or the
result of this query could be NULL or blank. |
|
3.) User shall be able to add, delete, or
modify the list of applicants: There needs to be some kind of intuitive GUI
form that allows the user to easily add, delete, or modify applicant
information from the database. |
|
Description: The TFA user needs an easy to use, intuitive GUI interface that they can
use to update the database information by editing existing information or
simply adding and deleting applicants’ information into the database. |
|
Criticality: This component is
very important to meet the needs of the project, so that the applications are no longer filed
away, but instead - completely converted into an easy to access electronic
format. |
|
Technical
Issues: The user could possibly want to jump from this form to an array of
different types of queries. Another
tab could potentially be used to house links to a vast array of different
queries and reports. Some buttons
could be on the form as well that potentially call VBA code, which filters
out the exact data, which they are seeking. |
|
Dependencies with
other requirements: In order for the potential queries,
reports, or buttons to work, there must be the back in piece present in order
for them to work correctly. |
|
4.) User shall be
able to drop the CD with our application in their CD-ROM and install the necessary
files to their hard drive, plus necessary shortcuts. |
|
Description: This will make deploying our application as easy as possible for the
end user, just like a true “shrink wrapped” application one would buy from
some retail store. |
|
Criticality: This component is
very important to meet the needs of the project, so that the end user does not have to
manually copy certain files and manually configure anything. All they have to do is click on the
executable. |
|
Technical
Issues: A Winbatch executable should be able to achieve all this without any
user intervention. The Winbatch
routine should copy over the necessary files as well as configure a shortcut
on their desktop/start menu so they can access the program with a single
icon. Also, an Auto run routine will
help facilitate a smooth, effortless install on the end user’s behalf by
calling the Winbatch executable. |
|
Dependencies with
other requirements: In order for
the setup to kick off automatically without any problems, we need to nail
down the syntax on configuring Autorun.inf files along with Autorun.exe, etc. |
|
5.) Switchboard to
access all the functions of the program. |
|
Description: Users will have one launch pad to get to all the different functions, queries, and reports. |
|
Criticality: This is not highly critical, but it would be nice and easier for the end user. |
|
Technical Issues: There could be problems with fitting all the different functionality given to the user on a single switchboard. Multiple switchboards might need to be created. |
|
Dependencies with other requirements: We need to find out find out what that limitation is. We might very well have to develop our own switchboard from scratch. |
|
6.) Have the
ability to do a bulk insert by importing from a CSV (Comma Separated Value)
file that contains the information from a Scantron file. |
|
Description: Allow the user to populate the database with applicant information gathered from Scantron forms. |
|
Criticality: This is not highly critical, but this would provide them with added flexibility. |
|
Technical Issues: The users would have to have the CSV file in the format we specify so that the fields correctly line up. The correct format will ultimately be explained in the user’s manual. |
|
Dependencies with other requirements: This is dependent on some program that TFA has to generate a correct CSV file that can be imported in to the database. |
3.2 Non-Functional
|
1.) The form of
preferences filled out by the applicants which contains strict ranking from
“not preferred” to “preferred” to “highly preferred”. |
|
Description: The applicants on the day of their interview with TFA are asked to fill
out a form which first has all the regions, each they rank in preference on
if they would like to teach there if needed. |
|
Criticality: This is highly critical for the entire
program to work and emulate the work process of the TFA placement
personnel. It is key that we have
this form in order to emulate it with our program. |
|
Technical
Issues: N/A. |
|
Dependencies with
other requirements: Mike Johnson was going to try and get this
form for us so that we can have more insight on how the process works, what
fields we will have to query on, etc.
We still do not have this document yet; so much of the process is
ambiguous. This document should
coincide with some kind of workflow document that describes their thought
process on determining which applicants get placed in the various regions. |
|
2.) The workflow
document which describes how TFA currently determines exactly which
applicants go to which regions and teach which classes. |
|
Description: This document (either existent) or created by us via data collection
over some kind of conference call with TFA personnel in conjunction with Mike
Johnson. |
|
Criticality: This is highly critical for us to clearly understand exactly what they
currently do and duplicate that in our program. |
|
Technical
Issues: Mike Johnson has contacted TFA to try and get them involved, but to
date, there has been no response on their behalf. |
|
Dependencies with
other requirements: We as well as Mike Johnson are at the mercy
of TFA and can merely ask for the documents or their involvement. |
3.3 Interface Requirements
|
1.) Add, modify,
and delete applicant information. |
|
Description: Provide the users with an interface, which they can add, modify, and delete all of the applicant information. |
|
Criticality: This is highly critical for the success of this project, since it one of the things that is going to frequently be used. |
|
Technical Issues: Creating the form the most efficient way for the end user is important. |
|
Dependencies with other requirements: The form, which we are waiting on, will help fill in the gaps of understanding on how to best lay this out. |
|
2.)Add, modify, and
delete region information. |
|
Description: Provide the user with an interface, which they can add, modify, and delete all of the region information. |
|
Criticality: This is highly critical for the user to be able and add new regions as well as change their address information if necessary. |
|
Technical Issues: We would need to create a simple GUI form for them to modify the region table. |
|
Dependencies with other requirements: The region table must already be defined. |
|
3.) Add, modify,
and delete subject information. |
|
Description: Provide the user with an interface to modify the subjects, which are taught at the various regions. |
|
Criticality: This is highly critical for the user to be able and add new regions as well as change their address information if necessary. |
|
Technical
Issues: We would need to create a
simple GUI form for them to modify the region table. |
|
Dependencies with other requirements: The subject table must already be defined. |
|
4.) Query by region
and subject. |
|
Description: Provide the user with an interface to find the optimum number of applicants that can teach a specific subject with a specific region being of “Preferred” or “Highly Preferred” preference. |
|
Criticality: This is highly critical for the
success of this project, since this is one of the core objectives. |
|
Technical Issues: We need to know if they want to query by more than one subject at a time. This query should prompt the user first for the region of choice, then for the subject of choice. The output should be in the form of a report, which is sorted first by preference then by name. |
|
Dependencies with other requirements: The applicant table must be populated with “good” data. |
|
5.)Query by region
only |
|
Description: Provide
the user with an interface to find the number of applicants that can teach
any subject with a specific region being of “Preferred” or “Highly Preferred”
preference. |
|
Criticality: This is not highly critical, but would be useful to see all the applicants that are seeking a particular region. |
|
Technical Issues: The output of this query will be in the form of a report that sorts the applicants first by preference, then by name. |
|
Dependencies with other requirements: The applicant table must be populated with “good” data. |
|
6.) Query by
Subject(s) Only |
|
Description: Provide the user with an interface to find all the applicants who can teach a particular subject across all regions. |
|
Criticality: This is not highly critical although again, this will be useful for the TFA users. |
|
Technical Issues: The output of this query will be in the form of a report that sorts the applicants first by subject(s), then by name. |
|
Dependencies with other requirements: The applicant table must be populated with “good” data. |
|
7.) Search for Applicants
by SSN |
|
Description: Provide the user an interface that allows them to find an applicant by their Social Security Number (SSN). |
|
Criticality: This is not highly critical, but will be useful for the users. |
|
Technical Issues: The output of this query will be in the form of a report that has all the personal applicant information coinciding with the particular SSN that is searched for, such as First Name, Last Name, Address, City, State, Zip, Phone Number. |
|
Dependencies with other requirements: The applicant table must be populated with “good” data. |
|
8.) Switchboard |
|
Description: Provide the user with an interface to do all of the most common tasks, such as adding/modifying applicant info |
|
Criticality: This is not highly critical although again, this will be highly useful for the TFA users. |
|
Technical Issues: There could be limitations on how much can be squeezed onto a single switchboard, there for requiring multiple switchboards to be developed. |
|
Dependencies with other requirements: All the different back end things like table, queries, and reports that are launched by the switchboard buttons must already be present and populated with “good” data. |
3.4 External Interface
The only external interface required for this product would be a keyboard and a mouse. No other external interface would be used.
3.5 System Functionality
The system needs to run off of a Windows operating system of Windows 95 or newer. This includes Windows 95/98/NT/ME/2000/XP. Also required would be a copy of Access 97, which comes in Microsoft Office 97 Professional. Any other version of Office may not include Access. Newer versions of Microsoft Office Professional are acceptable as well. This includes Microsoft Office 2000 and XP.
3.6 Performance
In order to run this application,
the computer must at least have a Pentium 166 MHz processor with 32 MB of RAM.
For maximum performance, a Pentium 300 or higher with 128 MB or RAM or more
would be necessary. Execution time for this application is largely based on
system performance. The higher processor and more RAM would cut down on
processing speed dramatically.
3.7 Logical Database Requirements
3.7.1 Logical Database Description
The database will consist of one main table that contains all the applicant information containing all of their preferences. There could also be other tables such as the tables containing the various regions (currently a total of 17) as well as tables containing the different subjects taught.
3.7.2 Data Model of the Logical
Database
The data models in the database management system include hierarchical, network, relational, and object-oriented. The hierarchal data model allows the user to represent each one-to-many relationship and many-to-many relationships between clients need and design attributes in product definition. In this project, we are going to use Microsoft Access, which is a relatively easy to use software package system for the Windows environment with powerful database management capabilities. As a virtual programming tool with strengths in relational database applications, it provides event-driven mechanism to build graphical user interface easily. Its floating toolbar, along with cue cards and powerful wizards simplify many programming tasks, resulting in a professional looking program.
3.7. 3 Logical Database
Design
Data modeling is an important step following requirement analysis to help the database designer conceptualize the entities and their relationships. In the logical database design, the conceptual data schema (ER model) is translated into a logical schema tailored to the specific database management system (Microsoft Access). All these issue are implemented during the physical database design by using Microsoft Access database software.
3.8 Design
Constraints
The project should be easy for the clients to use. Extensive use of real examples allows for an easy understanding of the systems selection criteria, relationships and interfaces which are all part of the design process. All of important subsystems will be addressed and their key relationships and interface requirements discussed.
3.9 Emergent System Properties
3.9.1 Describe of Emergent
System Property
An emergent system property is a property of the system that is not attributable to any specific subsystem or component. Emergent properties arise from complex relationships between components, i.e. the whole is greater than the sum of the parts.
3.9.2 Typical emergent
properties
The emergent properties include reliability, efficiency, safety, and security. This depends on the reliability of system components and the relationships between the components. Teach For American will be very reliable software. The following is what makes it reliable.
· It is very user friendly
· The Window based system make it easy for the user to use the software.
· Check for user input errors
· Write changes as they are made
Whenever something needs to be updated or changed, the software will make a copy of whatever that needs to be modified and make modification on the copied version. Once the changes are made, the user may choose to finalize the update so that the update is saved into permanent memory, or he/she may quit the modification process. If the user chooses to quit, no harm is done to the permanent data.