|
|
Post by Bradley Goliber on Feb 11, 2010 21:41:05 GMT -5
We should submit whatever we have by Wednesday 2/24 to get some feedback. Here's how I think we should break things down:
Ciprian: do all the work
Scott: sabotage team 1
Me: positive reinforcement
Let me know what you guys think. BTW, you're doing a great job.
I'm going to go over the example SRDs. Check this board over the weekend so we can figure out what we're all doing.
|
|
|
|
Post by Bradley Goliber on Feb 13, 2010 19:36:15 GMT -5
Ok, this is what I have so far in terms of what we need to describe in the SRD. Let me know if I've left anything out, or if anything needs clarification.
Web Page + Content Management System
These components share a database. Content is added to the site via the private admin tools, and is accessed from the public website. Every page of the website will be dynamic, and content can be changed by the admin at any time. The general page structure of the public website will be similar from page to page, retaining menus, logos, etc.
Pages (in no particular order, we can figure that out later)
1.Main Page – This gathers a variety of content from other pages and displays it by category. Upcoming events, recent internships/jobs, recent audio/video, blog, etc.
2.About – General description of SCSE and services provided.
3.Contact
4.Blog
5.Media – recent audio, video, pics
6.Activities/Events
7.Academics/Enrollment
8.Internships/Employment
9.Research Program
10.Student Support – advisement, financial aid, etc.
Components that need to be implemented: calendar, login (just a generic login, don't worry about security yet)
Advisement
These components should use a database separate from the web/CMS database, since it will include confidential information. We will interface with the Banner API to access student grade (and other) information. We'll just treat Banner as a magic black box that gives us all the information we need.
There are 2 dedicated advisors for SCSE. Each should have their own login. Each will have access to info about their assigned students.
Tools
1.List of students – should show GPA differences from one semester to the next, overall GPA, last time they came in for advisement. Information will be color-coded. Red: GPA dropped, hasn't been into a meeting for awhile, etc. Green: Improvement.
2.Student detail – clicking on a student in the list will allow more information to be displayed in a new window: specific classes and professors, contact info, etc
3.Appointment scheduler – using the calendar system, students can set up a meeting online. Advisors can set up blocks of time when they are typically available. Students can also request other time. Advisors will see a list of requests, and choose to confirm or attempt to reschedule them
Administration
Paperwork: name, email address, document #. After each step in paperwork processing is completed they can check a box. Users will be given a private url to enter their name and document # to track the status, and can be emailed when the processing is complete
|
|
|
|
Post by Bradley Goliber on Feb 15, 2010 12:09:11 GMT -5
One thing I forgot is that they requested a tagging system, and we need to add search capabilities on both the public and private side. Users should be able to search by tag or keyword, and limit the search to a category. Advisers should be able to search for a student by name. Also, users should be able to order results. Internships/jobs can be arranged by due date/expiration date. Students can be arranged by GPA, credit hours, last time the came in to see an adviser, etc.
In terms of functional requirements, judging from the other SRDs we can combine web and CMS functions into one requirement. Example:
Internship and Employment Postings
Public: The user can browse through active postings, and choose to view internship postings, employment postings, or both. Postings can be ordered by the date they were submitted (default) or by application deadline (internships) / post expiration (employment). Postings can be searched by tags and keywords.
Private: The user can add, edit or remove postings. Each post will have a title, body, list of tags, submission date, and deadline/expiration date. The expiration date is used for employment postings with no known application deadline. Typically this would be set to 30-60 days so that the posting doesn't remain in the system indefinitely. Posts that are older than the deadline/expiration date will automatically be inactivated and archived. A series of common tags will be available to check off for each post. Custom tags can be used as well. The user can choose to submit the posting to the site only, or to submit to both the site and social media networks.
|
|
|
|
Post by ciprian on Feb 16, 2010 22:41:34 GMT -5
like your division on how we should the project Brad. Scott, you better ruin them haha
.
.
.
wel ok, all this is pretty much it, i guess we have to divide into functionalities like the professor asked us, and then we'll eventually choose two of those, right?
|
|
|
|
Post by ciprian on Feb 16, 2010 22:50:01 GMT -5
actually, sorry, yeah, this is all that we need for the SRD. so how do you guys want to start this?
|
|
