2. 1
Table of Contents
Executive Overview ……………………………………………………………………………………………………..2 – 3
Database Design…………………………..…………………………………………………………………………..4 -10
Database Screenshots…………………………………………………………………………………………………..5-9
Entity Relationship Diagram………………………………………………………………………………………….10
Processing Design Detail…………………..………………….…………………………………………………..11-15
Functional Decomposition ……………………………………………………………………………………………12
Context Diagram…………….. ……………………………………………………………………………………………13
FDD Primitive Design…………….. ……………………………………………………………………………………..14
Data Flow Diagram…………….. …………………………………………………………………………………………15
Processing Design Detail…………………..………………….…………………………………………………….16-23
Input and Output List……………………………………………………………………………………………….…….17-19
Output Design……………………………………………………………………………………………….……………....20-21
Input Design……………………………………………………………………………………………….…………………..22-23
OOA’s and OOD’s………….…………………..………………….…………………………………………………….24-36
Class Diagram…………….. ………………………………………………………………………………………….………25
Sequence Diagrams…………………………………………………………………………………….…………………..26-27
Use Case Diagram……………………………………………………………………………………………………………28
Use Case Narratives………………………………………………………………………….…………………………....29-36
Project Plans…….………….…………………..………………….……….…………………………………………….37-45
Network Component………………………………………………………………………………………………………38
Security Design……….………………………………………………………………………………………………………39
Budget……….……………………………………………………………………………………………………………………40
Feasibility Analysis……………………………………………………………………………………………………..…...41
Resource Requirements……….……………..…………………………………………………………………………..42
Problem Analysis Matrix……………………..…………………………………………….…………………………....43-44
Gnatt Chart……….………………………………………………………………………………………………………..……45
Appendix…….………….…………………..………………….……….…………………………………………………..46-47
System Request………………………………………………………………………………………………………………..47
3. 2
Group name: RoadRunner Step Team
Derek Engelhorn
Brandon Sine
Trong Nguyen
Pierce Power-Quitmeyer
Name of the Organization: College of Business
Project Title: Academic Catalog Development
The Chair of the College of Business would like a software that students can use to track
their academic schedule for up two future semesters. The current system to track academic
progress is hard to follow for students and we are looking for solutions to improve it. The
problem is with the CAPP reports are with students not being able to access the correct one or
a legible one without going to see a counselor. This causes many problems for the student, but
also causes problems for the counselor as well because they are being overbooked with
students trying to figure out what classes they need to take, can take, or the prerequisites that
are required. Students and counselors need something that is easily viewable and user friendly.
Our team will need to create a systemthat is simple to use and easy to navigate. Our
system will be for the College of Business majors to easily track academic progress, look at
future classes two semesters down the road and look at available courses. It will search for
general electives all the way to the major course, as well as tell you the prerequisites that each
course requires. The database will be stored on a Netbeans program using SQL statements to
create, update, and alter tables. The GUI interface will also been programmed and stored on
a Netbeans interface with java coding on a stand-alone system. When this Java applet opens up
you will be asked to login with you student ID number and this will register to the database to
bring up information about the student, and if nothing is found about this student it will add
them to the database and asked to enter any classes in which they have already taken. This way
the student will be added to database with the correct information to the best of their
knowledge. This applet will show the student a list of classes that would be available for them
to take for up two semesters based on their standings. It will show the student electives and
core classes that a student will need to take. Also this interface will have an option to look up
classes already taken by student to show progress through there academics and help the
student decide in which they need to register for the next semester. Students or counselors will
be able to look up courses for the future with a dual scroll box that will update each time the
student selects a new class by changing the classes available.
The project team will consist of Derek Engelhorn, Brandon Sine, Trong Nguyen, and
Pierce Power-Quitmeyer. The Academic Catalog Development project will have three delivery
dates with the final production due in May 5th. This project will be a group effort by every team
member and each time a project is due there will be a peer evaluation to let students rank their
fellow group members to make sure everyone is doing the fair share of the project. These will
make sure that every one of the group pulls their part.
Our first objective is to design a database containing the information of the College of
Business register. This phase will also include parts of the project like how we plan to set up our
database with an ERD diagram. Use case diagram to show all of the actors plus actions along
with natives for each one of these actors. Data flow diagram on how things will flow through
4. 3
our system and a Gantt or Pert chart to show how we plan to work on this project and of course
a program design on how are database will work. There will be no testing with in this phase due
to nothing being able to be tested at this time. After we have done all aspects of this project we
will have a brief fifteen minute presentation of what our plan will be for this project and to
show our finding thus so far.
Second, we will implement a GUI using Java script for user interaction. This phase will
take many testing plans just to make sure that the GUI interface is working properly
with dummy data. Also with this phase we will be figuring out how we would like to design our
interface, this will all depend on how what functionality will work with our database and how
we feel how we can implement these two projects together to make the best result for the
user. We will also have to have an input and output designs. Evaluating if the system would be
feasible will be another aspect of this project in which we will have to figure out. There will be
sequence diagrams showing how information will pass through the system. This project will
incorporate all of the previous items from the first project. After this project is completed there
will be a fifteen minute presentation on how to market our product.
Finally, we will finalize this project with everything we have completed with a polish
version. This will be the toughest phase of our project and take many testing scenarios to make
sure that both the database is full up to date and that GUI interface runs without flaws. Once
we have submitted the interface of the final project we will have a presentation in showing our
new system off and how it will help improve student/counselors with their registration and
course requirements instead of the systemwhich is being implemented right now.
In conclusion, the new Academic Catalog will assist students in the College of Business
to track their academic progress as well as plan their future courses. Students will be able to
self-service their courses without the help of their counselor but if students still feel the need to
get help from the counselor they still will be able to. This counselor will be able to logon and
due everything a student can do. This system will be user friendly compared to the previous
system and will give the students a more detailed description of everything that is required for
the College of Business.
13. 12
Functional Decomposition
Student Future
Semester System
Student Login ExitCheck for Classes
Retrieve Student
Information
Displays classes
available next
semesterbasedon
Prerequisites
Exits program
Displays classes
for following
semesterbasedon
Prerequisites
15. Functional Decomposition
Diagram Primitive Design
Start
Login
Enter
User
Info
Retrieves
User Info
Select
Courses
Displays Next
Semester Class
Possibilities
Displays
Semester Class
Possibilities Two
Semesters Out
Print
End
Print or
Logout
Logout
14
16. 15
Data Flow Diagram
1
Login
1
Search Courses Retrieve
Report
2 3
1.0
Input User
Info
1.1 Student
Reads Info
1.2
Select Courses
Taken
1.3
Select Courses
1.4
Majors
Gen Ed
2.0
Update User Info
2.1
Search Classes by Major
2.2
3.0
Show courses available next two
semestersbasedonprerequisites
3.1
21. 20
Output Design
Identify System Outputs and Review Logical Requirements
Data Structure Defining Logical Requirements Comment
900 #
Major Option
Class Taken List
Semester Option
Class by Major
Summary
Unique Identifier of Output
All School of Business Major
List of Classes Taken by Student
Available Semesters
List of Class Available
Summary Page that Display Choosen
Fields
Specify Physical Output Requirements
Output Type: Screen
Purpose: To display information for students on the monitor of their computers.
Operational feasibility : The system output should be running 98% of the time and display the
correct information in the corresponding field.
Technical feasibility: The skill level to use the systemshould be minimal. There will be drop
down box and text field to display information.
Economic feasibility: The systemoutput should not cost more than $120,000 to build. It should
not take longer than three and half months to build.
(Internal Output) Detailed and summary information displayed on monitors for students to use.
Reports will be tabular output. The best implementation output is the screen output. The
format will display tabular output and also zoned output. The recommended screen resolution
is 1024 by 760, but will be able to handle anything below and up to 1800 by 1800. The output is
generated on the next screen when user click the next button.
22. 21
Designs
Screen Design Consideration: Design Guidelines:
Size There will not be a universal monitor. The
screen should support the lowest resolution
available and up to 1800 by 1800. The
recommended resolution is 1024 by 740.
Users should be able to resize the output
display according to their screen size.
Scrolling If outputs are bigger than the size of the
limited text display, it is important that users
are able to view the rest of the information
by scrolling.
Dropdown Box To save limit screen room, dropdown box will
hold multiple selection of information for the
users.
Navigation Users will have the ability to navigate
between screens. They will have the option
to go back and forth.
Heading There should be heading on each window so
users will not get lost.
23. 22
Input Design
Identify System Inputs and Review Logical Requirements
Data Structure Defining Logical Requirements Comment
900 #
Password
Major Selection
Semester
Subject
Add
Delete
Unique username of user
Authentication of the username
Major student wants information about
Semesters available
Class by department
Users can add future class
Users can delete future class
Select Appropriate GUI Controls
(900 # and Password) have a limited scope that the users should be able to edit so we use a 1
line text field.
(Major Selection, Semester, and Subject) all have multiple predetermine results that should not
crowd the screen at the same time. The best control will be a combo box that hides unused
potential user's inputs.
(Add and Delete) should use a button to simplify future class selection.
24. 23
Designs
If Necessary, Design the Source Document
Our source document is put into different screens instead of sections. See inputs and outputs
detail list.
27. 26
Sequence Diagrams
Provide
userLogon Logon() GetStudent()
Return
StudentData
Return
Interface
ReturnMain
Page
SelectMajor SendStudentID#()
Return
studentRecords()
GetRecords()
Return
recordsPage
Display
recordsPage
Student
View Classes Use Case Sequence Diagram
:View
Student
User
Interface
:View
Student
Interface
Controller
::Student ::Records
28. 27
Search for Classes Use Case Sequence Diagram
Provide
userLogon Logon() GetStudent()
Return
StudentData
Return
Interface
ReturnMain
Page
SelectMajor SendStudentID#()
Return
studentRecords()
GetRecords()
Return
recordsPage
Display
recordsPage
Student
Click
nextButton
sendStudent
information()
getClasses()
returnClasses
returnClasses
Page
Display
classesPage
:View
Student
User
Interface
:View
Student
Interface
Controller
::Student ::Records ::Classes
29. Use Case Diagram
Student Administrator
Counselors
View Classes Taken
Update Class Schedule
Enter Information
Search for Classes
Credits Still Required
Prerequisites Requirements
28
30. 29
Use Case Name: CreditsNeedforGraduation USE CASETYPE
BusinessRequirements:
SystemAnalysis:
Use Case ID: 138 - 1
Priority: Moderate
Source: Requirement–Studentmustbe alreadythroughfirstsemester
Primary BusinessActor: Student
Other ParticipatingActors: Counselor–Helpstudentfigure outhow manycreditsare still
needed
Other Interested
Stakeholders:
Administrator–Must have database runningproperlysoall datacan
be compiledtosee how muchcreditsare remaining.
Description: Thisuse case describeshow the systemwillshow how manycredits
are requiredtograduate fora student.Once the GUI isopenedup
there will be an optionforthe systemto calculate how manycredit
hoursthere are still requiredforastudentto graduate.
Pre-Condition: Student/Counselormustbe loggedintosystem.
Trigger: Student/Counselorclicksbuttontocalculate creditsrequired.
Typical Course of Events: Actor Action
Step3: User thencan printoff
report.
Step4: User can thenexitscreen
that pulledupforreport.
SystemResponse
Step1: Systemcalculates
requiredhoursthatthe student
needstograduate.
Step2: Systemthenpopsupwith
amountof creditsthatthe
studentneeds,andcourse in
whichthe studentcan take to
make up those credits.
Step5: Systemclosesoutof
report.
Alternate Courses: Alt– Step4: Systemthenprintsoff reportforstudentso studentcan
keepa hard copyof whatis needed.
Conclusion: Thisuse case pullsupa reportshowinghow manycreditsa student
needsandthe coursesavailable theystill needtotake.
Post-Condition: Thiswill helpthe studentdesignaplanforthe classesthattheywill
needtograduate is specifictime theywanttospecify.
BusinessRules: Studentwill notbe able toregisterforthe classesfrom
screen
Systemwill notprintoutcourse planor desiredactionfor
the studentto graduate
ImplementationConstraints
and Specifications:
Making sure all classesare matchedup withrequiredclasses
and notprintingclassesthatare alreadytakenbystudent.
Assumptions: Studentwill know whichmajortheyhave declaredandthe database
will be update todate withstudentinformation.
OpenIssues: Making sure that all credithoursthat a studentare beingregistered
withinthatdatabase.
31. 30
Use Case Name: ViewClasses USE CASETYPE
BusinessRequirements:
SystemAnalysis:
Use Case ID: 689-1
Priority: High
Source: Requirement–Enteringstudentinformationandsystemstartup
Primary BusinessActor: Student
Other ParticipatingActors: Counselor–Helpingstudentchoose classesafterknowingwhich
classestheyhave alreadytaken.
Other Interested
Stakeholders:
Administration –Makingsure studentisupto date withclasses
alreadytaken.
Description: Thisuse case describeswhatastudentwill dotolookup the classes
theyhave takenthroughthere yearsof schooling.Once astudent
entersthere informationtheywill be able tolookupwhatclasses
theyhave alreadytakensotheyknow whichonestheyneedtotake
inthe future.
Pre-Condition: The studentmustalreadyhave takena semesteratof classes.
Trigger: Thisuse case istriggeredwhenastudentwhenastudententers
there informationandcallsfora CAPPReport.
Typical Course of Events: Actor Action
Step1: The studentprovidesall
there information,suchasID
numberandname.
Step3: StudentclicksCAPP
ReportinGUI interface.
SystemResponse
Step2: Systemretrievesdata
aboutstudent.
Step4: Systemthenprintsonto
screenstudentdetailed
informationof perviousclasses
takenbefore new registration.
Alternate Courses: Alt– Step2: Information studentprovidesisnotcorrectand no
reportcan be foundonstudent.
Alt–Step3: StudentclicksonCAPPReportbut hasno previous
coursesat universityandinterfacepopsupwitherrormessage.
Alt– Step4: Studenthastakenclassesbefore atuniversitybutno
informationpopsup,analertissentadministratortoupdate.
Conclusion: Thisuse case pullsupCAPPthat can be printedoutif necessary.
Post-Condition: Thisgivesstudentanideaof what classestoregisterforand whathe
still needstofill forprerequisites.
BusinessRules StudentorCounselorswill notbe able toregisterfornew
classesfromthisscreen.
Doesnot show whichclassesare still requiredfor
graduation.
ImplementationConstraints
and Specifications
GUI will be providedforstudenttoaccessas well forthe
counselor.
Database will be update withclassesalreadytakenby
student.
Assumptions: StudentorCounselorwill have right informationof studenttoenter.
OpenIssues: How to make sure that everystudentisupto date witheveryclass
alreadytaken.
32. 31
Use Case Name: Enter StudentInformation USE CASETYPE
BusinessRequirements:
SystemAnalysis:
Use Case ID: 419-3
Priority: High
Source: Requirement–GUI readyfor studentuse
Requirement–Studentisalreadyaddedtodatabase
Primary BusinessActor: Student
Other ParticipatingActors: Counselor–Goingover studentrecords,canaccess withstudent
information
Other Interested
Stakeholders:
Administrator–Makingsure thatthe studenthashad there student
ID enteredintothe system
Description: Thisuse case describeshow astudentwill logintothe database
usingthe GUI to lookupthere classes taken(CAPPReport),required
courses,andprerequisitesrequirementsrequiredtotake higherlevel
course.Once the GUI instartedthe studentwill be askedtoenter
there ID number,name andif the firsttime loggingontodatabase
the firsttime,asking formajorand coursestakenalreadyif a
transfer.
Pre-Condition: ID numbermustbe enteredintosystem, andGUI mustbe up and
running.
Trigger: Student/CounselorstartingupGUI
Typical Course of Events: Actor Action
Step1: Student/Counselorenter
ID and name
Step5: Student/Counselorthen
entersinformationif necessary.
SystemResponse
Step2: Database searchesfor
informationentered.
Step3: If informationthatis
enteredisnotvalid,GUI comes
up witherrormessage.
Step4: Systemthensearches for
previouslogonsandif none
foundrespondsbyaskingfor
previousclassesif any.
Step6: Systemthenpopsupwith
optionsavailabletodorequired
actions
Alternate Courses: Alt– Step4: Systemfoundpreviouslogonsandstepfiveisskipped.
Conclusion: Thiscase letsstudentlogontodatabase tomanage classes.
Post-Condition: OpensGUI to mainscreen
BusinessRules: Doesnot give managementpermissiontouserlogginginon
thisaccount
Will notrun if studentisnot a part of the university
ImplementationConstraints
and Specifications:
GUI will have tobe up andrunningfor student/counselor
access
Assumptions: Accountfor studentwill be alreadycreatedsotheycanaccess
informationabouttheirclasses
OpenIssues: Administratormusthave enteredall informationonstudentsothat
theycan access thisinformation.
33. 32
Use Case Name: PrerequisitesRequirements USE CASETYPE
BusinessRequirements:
SystemAnalysis:
Use Case ID: 239 - 1
Priority: Moderate
Source: Requirements –Studentisenteredwithinthe database
Primary BusinessActor: Student
Other ParticipatingActors: Counselor–Helpstudentsdetermine whichclassestheyneedbefore
signingupforhigherlevel courses.
Other Interested
Stakeholders:
Administrator–Makingsure all coursesthathave a prerequisite
requirementhave aconstraintonthem
Description: Thisuse case describesinwhichprerequisitesastudentwill needto
move upintohigherlevel courses.Whenastudentislookingup
classes,the studentwill be informedonce theyselectthatclasses
that the class prerequisites.
Pre-Condition: Studentmusthave a loggedonand the studentmustbe lookingin
the class searchoption.
Trigger: Studentclicksonthe class searchoption
Typical Course of Events: Actor Action
Step1:User thenselectsif they
wantto lookup there major
coursesor general electives.
Step3: User thenhasthe option
to searchby drop downlistor
entera course number.
Step6: User thencan selecta
course fromnew drop down
menuor exitnew screen
SystemResponse
Step2: Systemthenpullsupthe
classlistina dropdownmenu.
Step4: Once userselectsa
course,the systembringsup
course information,withinthe
informationthere will be anarea
for prerequisites.
Step5: Systemthenwill list
prerequisitesinadropdown
menu.
Step7: If course is selectedfrom
prerequisitesitwillpull up
course informationforthe
prerequisite.
Alternate Courses: Alt– Step6: Studentcan print off listof prerequisitescourses
Alt– Step7: Systemprintsoutprerequisiteslist
Alt– Step7: Systemexitsscreenandgoesbackto mainpage.
Conclusion: Thisuse case will show youwhatisrequiresforthe studenttotake
certaincourse if it has a prerequisite.
Post-Condition: Thiswill helpthe studentdesignaplanforthe classesthattheywill
needtotake before otherclasses.
BusinessRules: Studentwill notbe able toregisterforthe classesfrom
screen
Systemwill notprintoutcourse planto meetprerequisite
requirements.
ImplementationConstraints
and Specifications:
GUI will be providedforstudenttoaccessas well forthe
counselor.
Prerequisiteswillalreadybe programmedintothe course to
tell youwhatis requires.
34. 33
Assumptions: Studentwill know whichmajortheyhave declaredandwhatclasses
theyhave takenso theydon’ttake a course overagain.
OpenIssues: Making sure that classesthatrequire aprerequisitesshow these
requirements.
35. 34
Use Case Name: Searchfor Classes USE CASETYPE
BusinessRequirements:
SystemAnalysis:
Use Case ID: 750 - 1
Priority: High
Source: Requirement–Classesbeingofferedmustbe uptodate
Primary BusinessActor: Student
Other ParticipatingActors: Counselor–Can searchfor classesforstudentif theyneedhelp
Other Interested
Stakeholders:
Administrator–Must make sure that the tablesare upto date.
Description: Thisuse case describeshow astudent/counselorwill be able to
searchavailable classes.Once astudententersthe GUIsystem, there
will be anoptionto choose if theywouldlookforcertainclasses.
Theywill be able tolookby majorclasses,general electives,orby
course number.
Pre-Condition: Student/Counselormustbe loggedintoGUI
Trigger: Student/Counselorclicklookupclassbutton
Typical Course of Events: Actor Action
Step2: User selectsif there
majoror general electives
Step4: Student/Counselorlooks
up classby dropdownmenuor
can search bycourse numberto
see if itbeingoffered.
Step6: Student/Counselorclicks
exittoexitoutof classsearch
menuand goback to GUI main
page
SystemResponse
Step1: Systemwill pullupan
optiontoeithersearchby a
majoror general electives.
Step3: Systemwill have abox in
whichyoucan entercourse
numberor a drop downlistof
available classes.
Step5: Systemsearchesfor
classesif course numberentered.
Step7: Systemexitsclasssearch
screen.
Alternate Courses: Alt– Step5: If course numberentered doesnotmatchanyexisting
coursesan error box will show up.
Conclusion: Thisuse cases pullsadetailedlistof classesbeingofferedandable to
printoff listif wantedtoby user.
Post-Condition: Thisgivesa studentof an ideaof what classesthat theycould
registerfornextsemester.
BusinessRules: User will notbe able to registerforclasses
If class isnot listedindropdownmenu,course isnotbeing
offeredthissemester.
ImplementationConstraints
and Specifications:
Studentmustknow whichmajortheyare involved/declared
for
Assumptions: All classeswill be listedalreadysostudentcangeta full
understandingof whatisbeingoffered.
OpenIssues: Studentdoesnotknow whichmajortheywantto declare,oris
interestedin.
36. 35
Use Case Name: Update ClassSchedule USE CASETYPE
BusinessRequirements:
SystemAnalysis:Use Case ID: 728-1
Priority: Moderate
Source: Requirement–Database alreadycreated
Primary BusinessActor: Administrator
Other ParticipatingActors: Student– Needupdatedschedule forregistrationfornextsemester
Other Interested
Stakeholders:
Counselor–Needtohave updatedclassoptionstohelpstudents
registerforclasses.
Description: Thisuse case describesthe administratorupdatingtablesforeach
departmentof businessschool.Eachsemesterthere will be an
updatedcourse directoryforeachdepartmentof the school,some
coursesmay be dropped,andsome new courseswill be added.To
update the drop of classesor the addingof classeswill fall onthe
administrator.
Pre-Condition: The departmentshave togive a listtoof new or droppedclassesto
the administrator.
Trigger: The administratorreceivesnew classesordroppedclassesfrom
departments
Typical Course of Events: Actor Action
Step1: The administratorsigns
intodatabase so theycan
manage tables
Step3: Administratorchooses
whichtable he wouldlike to
update.
Step5: Administrator
removes/addsclassesto
requiredrows.
Step7: User thencan update
anothertable or choose toexit
database.
SystemResponse
Step2: Systempullsupthe listof
tables.
Step4: Systemopenstable for
updates.
Step6: Systemupdatestables
withstatementsenteredbythe
user.
Step8: Systemswitches/shuts
downdependingonwhichuser
inputs
Step9: Tablesare updatedupon
closingandshow up on GUI for
students/counselorstoview.
Alternate Courses: Alt– Step1: User doesnot enterrightinformationtologonto
database and informationisdisplayedsayingwrongusername or
password
Alt– Step4: Error isreportedthattable is corruptand table has tobe
deletedandrecreatedagain.
Alt– Step6: Systemcomesup witherrormessage if information
enteredforrow if data mismatchor wrongset of commands.
Conclusion: Thisuse case will update tablesfornew/droppedclassesinthe
database
Post-Condition: Thiswill give studentsadetailedshowingof whatisbeingofferedfor
theirclassesforthe nextsemester.
BusinessRules: No one else will be able toupdate tables beside the
administrator
37. 36
The updateswill onlybe able tobe changedback by
administrator.
ImplementationConstraints
and Specifications:
Administratormusthave updatedclassesfromeachof the
departmentstoupdate tables.
Assumptions: The classeslistadministratorishandediscorrectandhas no errorsin
whichclassesshouldn’tbe available.
OpenIssues: Database crashesif too much informationisbeingaddedatonce and
not beingupdated continuously fromswitchingtables.
39. 38
Network Component
The systemthat we are designing right now is going to be a stand-alone system. There
will be no need to design at network for it at this stage. If there was more time we would be
able to make it a web applet, but with time restraints we will not be able to do so. This project
will be ran a Netbeans coding and database program which is a stand-alone system.
40. 39
Security Design
The security design that we have for are system is small but for that systemwe are
designing does not to need to be big. Most people are not trying to hack into student records to
see what classes they can register for and what they have taken. This makes it easy to set up
security systemfor our catalog development project. The only security that we have for our
system at the time is that the user will have to enter the nine hundred number of the student
they want to look up. With this there will be a password as well that will be specified by the
student, making so that no one access the student information with out there consent. This is a
basic security thing so that students have a sense of security that no one is looking at there
records.
41. 40
Budget
When breaking down the budget we need to look at everything it will take to put this
project together. This project requires a team to put together a semi-complex system within a
three month window. The project will need a new database created based on courses the
school of business deems necessary to graduate. Along with this database there is also a new
GUI interface necessary to be created as well. Considering the expertise of the four individuals
going to put this project together, the required budget will be about $120,000.00 in total.
42. 41
Feasibility Analysis
Operational Feasibility
The system meets the basic requirements of which the School of Business at Metropolitan State
University of Denver specified. The system has lost features in development that would have
been great to implement but with the time schedule that was put upon the project team,
features were lost. The big one that was lost was the web applet in which could be
implemented easily once the systemis down the road when it has no bugs. Most other features
that were lost were made up in another areas of the design or were small features that were
not required.
Cultural Feasibility
The students and counselors both are looking forward to the system to be ready here in the
future. From questions that we asked to both students and counselors around campus we find
that most of the users of the current system are not happy with it. Most of the users want a
user friendly system to make things more manageable. From this data we have gathered we
figured most users are looking forward to the new system.
Technical Feasibility
The solution that we are trying to create is technology practical for the university. The system
can be easily implemented by Metropolitan State University of Denver. Our project team has
the technical skills to complete this task as well. We all have background in java programing and
the understanding of management skills to get task done. We also have the technology to
develop the system besides not having the right amount of server space to implement the
system in the beginning. We are hoping that Metropolitan State University of Denver will have
the right amount of server space to implement the new system once it is complete.
Schedule Feasibility
The schedule that was put our project team was feasible for our team. The time period was a
short three and half month schedule that was given to our team. Each aspect of the project that
was required of the team and of the systemwas finished within each schedule time period.
Economic Feasibility
The project would be cost effective for Metropolitan State University of Denver. The project
would only cost the university around $120,000. This would be a substantial hit to the funds of
the university in the beginning. The system though could save the university money in the
future by reducing the need for as many counselor hours on the budget.
Legal Feasibility
This systemwould have no legal constraints on the side of our company or project team. We
would not make Metropolitan State University of Denver sign for anything that would require
to keep our system. Just the onetime fee that would be contracted with the university
beforehand. The only legal constraint would be on the universities side with the existing
system they have already implemented.
43. 42
Resource Requirements
* Software to develop Database
* Software to develop GUI to interact with Database
* List of all classes to fulfill Business school requirements
* Access to current system
44. 43
Problem Analysis Matrix Analysis
Problems:
1) There is not a systemthat currently allows students in the College of Business to effectively
plan their path through their program to graduation, or to track their current progress.
2) Students register for wrong classes, or classes that they do not need/do not count towards
their major.
3) Students try to register for classes for which they do not have the proper prerequisites.
4) Taking wrong classes may lead to delayed graduation dates for students. Results in students
getting a class schedule that is not the times they want and is inefficient.
Opportunity:
We have the opportunity to invent a systemfor the students to track their progress on their
own.
Proposal:
Our system will allow students to effectively plan and track their path through their degree
requirements. We propose a team to create a database that stores all of the college of business
class. Then we will need to create a program that allows us to retrieve the information from our
database and project it to the user of the program.
45. PROBLEM ANALYSIS MATRIX
Project: Homework Assignment #4 Project Manager:
Created by: Pierce Quitmeyer, Trong Nguyen, Brandon Sine,
Derek Englehorn
Last Updated by:
Date Created: 2/9/2015 Date Last Updated:
CAUSE AND EFFECT ANALYSIS SYSTEM IMPROVEMENT OBJECTIVES
PROPOSED SOLUTION
Problems Causes and Effects System Objective System Constraint
1. There is not currently a
systemthat allows students in
the College of Business to
effectively plan their path
through their program to
graduation, or to track their
current progress.
Students register for wrong
classes or classes that they
do not need/do not count
towards their major.
Students try to register for
classes for which they do
not have the proper
prerequisites.
Taking of wrong classes
may lead to delayed
graduation dates for
students.
Results in students getting a
class schedule that is not the
times they want and is
inefficient.
Create a simple systemwhich
allows students to plan their
own class schedule.
Properly show all
prerequisites on degree path
so that students do not
register for wrong courses.
Show required courses for
different departments.
Allow students to search for
classes taught by a specific
instructor.
System must be intuitive
enough for students to be
able to use without any
assistance from faculty or
advisors.
System must be able to
update any new degree
requirements or prerequisites.
System must be complete
before the end of the Spring
Semester 2015.
Our systemwill allow students to
effectively and easily plan and track
their path through their degree
requirements.
44
44
4
48. 47
Request for System Services
Metropolitan State University of Denver is looking for new system for students and
faculty to use for student registration. They users of the system want something that is user
friendly without reading through all of the pages from a CAPP Report to figure out classes
required. This systemshould have an easy way to navigate the system to figure out that the
user is requiring. Users would like a systemthat can show a student’s record of what courses
they have already taken. This report should be easily readable and have all the courses
categorized by type of course in which is falls under like general electives, major electives, and
major required courses. The systemalso needs to have a way to show the prerequisites in
which are required to take certain courses. It does not need to show each prerequisite for each
class but cannot let the student select classes in which they do not have the prerequisite
courses completed. Letting the student select there major is another object in which the
university would like just in case the student wants to switch majors and see the courses that
could transfer. The final thing the systemwould need to have would be a summary page of all
the courses the student has taken and the courses the student is planning to take in the future.
All solutions can be created on any programming language that would fit the description above.
Metropolitan State University of Denver would like to have the project done by May 5th
2015. From this request was put in it would give the team about three and half months to
complete the project. This project budget should not exceed over $120,000 limit that
Metropolitan State University of Denver has put towards this system. If this is a systemin which
your team would like to handle please get in contact with us.
