Course Management Software System: Requirements

This document outlines some high-level requirements for a generic course management software system that could be deployed for use within the Computer Science department at Cornell University. The requirements outlined in this document have been collected from a variety of sources, including: Instructors: Greg Morrisett, David Schwartz, Jayavel Shanmugasundaram, Teaching Assistants: Kiri Wagstaff Administrative Staff: Laurie Buck, Kathy Carpenter ADM Staff: Dora Abdullah

Please note that this document is only a first draft, and that the requirements could change once we get feedback from additional sources. The rest of this document is organized as follows. In Section 1, we outline the high-level architectural requirements, and in Section 2, we describe other functionality requirements. Finally, in Section 3, we present some thoughts on the development and maintenance of the system.

1. High-level Architectural Requirements

We outline three architectural requirements, namely security, reliability, and scalability. We now discuss each in more detail.

1.1

Security
Firewall protection: The course management software system should run inside a firewall. It is an open question as to whether this should be the within the CUCS firewall, or a separate firewall (for better security). Kerberos authentication: All users of the system should be authenticated using the Kerberos authentication mechanism provided by CIT. Support for different roles: The system should support different roles for users, such as Instructors, Teaching Assistants, Students, and Administrative Staff. A user logged in with a given role should only be allowed access consistent with that role. For example, a student should only be allowed to see his or her grades, and not the grades of others.

1.2

Reliability
Reliability of data: Since all course-critical data (such as grades) will be stored in the course management system, the reliability of the system is of paramount importance. A simple way to meet this requirement is to use a commercial database system (such as Microsoft SQL Server, Oracle or DB2) for all data management tasks. Note that periodic backup of text files is not sufficient to guarantee reliability of the data. Backups of text files are not sufficient to guarantee reliability because (a) the course management

software system could crash in the middle of updating the text file leaving the data in an inconsistent state, and (b) there could be race conditions when updates are done concurrently with backups. Reliability in the face of concurrent access: If the course management system is to be used for large courses, concurrent access to data becomes an important issue. For example, the system should continue to work correctly when students and TAs are concurrently accessing and manipulating grades. Again, using a commercial database for all data management tasks will solve this problem.

1.3

Scalability
Scaling to a large number of users: Large courses such as CS100 and CS432 have hundreds of students. The system should be able to handle the load for such courses, especially near assignment deadlines when many students can be expected to access the course management system. Scaling to a large number of courses: If the course management system is successful, it is conceivable that a large number of CS courses will end up using the system. The system should thus be able to scale to a large number of courses, while at the same time scaling to a large number of users for each course.

One simple way to meet the above requirements is to dedicate a separate machine and an application server for every large course. All the courses could share the same database backend so that management overhead for the system maintenance staff is minimized.

2. Functional Requirements
We now describe some functional requirements for the course management software system.

2.1

Grade Management

The system should be capable of managing student grades. Specifically, it should support the following features: Allow grades to be entered online: The system should allow TAs and instructors to enter and modify grades online. Allow students to access their grades online: The system should allow students to log in and check their grades at any time. In addition, it would be nice if the system also provides statistical information such as averages, standard deviation, median, etc. Track and Handle Re-grade Requests: The system should be able to track and handle requests for re-grades. All information about re-grades should be available to the student, the associated TAs, and the course instructor. Export grades in standard formats: The system should be capable of exporting the grades in CSV format so that the grades can be sent to the registrar electronically (without having to fill in bubble sheets). Also, exporting grades in CSV format allows grades to be imported by software packages like Microsoft Excel, in case sophisticated statistical analysis is desired.

2.2

Homework Submissions

The system should be capable of automatically accepting homework submissions. Specifically, it should support the following features: Accept submissions in multiple formats: The system should accept submissions in multiple formats, including .zip, .cpp, .txt, .doc, etc. Automatically validate submissions: The system should be able to automatically validate submission using a script so that students can get immediate feedback on faulty submissions. Support for late submissions: The system should provide information about late submissions, and also disallow submissions after a certain period of time. Provide online access to submissions for TAs: The system should allow TAs to download assignment submissions online. Support for online grading: The system should provide the ability to grade submitted code (and other assignments) online and provide good student feedback, without requiring massive printouts. Some ways of achieving this are: (a) providing online grading templates that can be filled out, and (b) automatically annotating code with line numbers. [Note: The Cucoon system may already support this feature.] Integration with grade management: The homework submission system should be integrated with the grade management system so that (a) assignment grades can be automatically posted, and (b) grader comments can be sent along with the grades.

2.3

Group Management

The system should support group management features. Such features are especially important for courses with group projects. Ability to create groups: The system should allow students to automatically create groups, and enforce certain conditions such as each student should be a member of exactly one group for a given project. The TA and/or course instructor should not be forced to create groups; this is especially important for large classes. Integration with homework submissions: The system should be able to accept group homework submissions. Integration with grade management: The system should support grade management for groups, and track how the group grade translates into individual student grades. Group Maintenance: Invariably, students either switch groups, or drop out from a group altogether. The system should support such transitions and keep track of them.

2.4

Miscellaneous
Course web page management: The system should allow for easy course web page management by supporting bulk-uploads of web pages/other files.

The system should support the following miscellaneous requirements.

Integration with Registrars class lists: The system should periodically upload the latest registrars class list to determine the current set of students enrolled in the course. Integration with newsgroups: The system should allow for easy integration with course news groups (currently supported by CIT).

3. Concluding thoughts
Since we are not aware of any existing software system that supports all of the above features, it seems inevitable that we develop and maintain our own home-grown system. While developing such a system has many advantages, it also comes with the following additional responsibilities. Commitment towards system development and maintenance: Once the system is in operation, bugs and missing features will inevitably crop up. We need to have a strong commitment within the Computer Science department to support the course management software system so that bugs, missing features and personnel changes do not affect the usability of the system. Commitment towards course set-up: Once the course management system is available, there has to be a commitment to setting up the system for every CS course at the beginning of the semester. This way, there will be very little overhead in adopting the system for use in a course. If the system is going to be difficult to set up and configure, then many courses that could potentially use the system may never do so. Training for all users involved (Profs, TAs, Admin Assts, etc) is also a necessary component to ensure success of this endeavor.

SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

FOR Student Attendance Management System (SAMS)
Prepared by: Aparna.R Haritha.S Kavya sri.M RMK.COLLEGE OF ENGINEERING AND TECHNOLOGY(3RD yr) Preface This document contains the Software Requirements Specification (SRS) of an student management document. The main aim of this project is to add functionality to the existing SMS system in order to provide facility for managing the attendance or presence of students in the college.

1. Introduction
This Software Requirement Specification is written accordance with the IEEE model.

1.1. Purpose
This SRS Document contains the complete software requirements for the student attendance management System (SAMS) and describes the design decisions, architectural design and the detailed design needed to implement the system. It provides the visibility in the design and provides information needed for software support.

1.2. Scope
Student attendance management System is developed to replace old paper work system .It helps the parents to know the status of their children in the college.

1.3. Definitions, acronyms, and abbreviations

IEEE The Institute of Electrical and Electronics Engineers, Inc. SAMS Student Attendance Management System SRS J2EE OS Software Requirements Specification Java 2 Platform Enterprise Edition Operating System(windows)

1.4. Overview
In SAMS, the student swipes their ID from which their ID no, date and time of their entry into the college is obtained. All these details are stored in their respective record in the database. Their personal details is fed already in the database. This is updated every-day and when the student is on leave, the system automatically sends a SMS to the corresponding contact number. If the student is on leave with prior information, then the system admin will update the database in prior and prevents from sending SMS.

2. Overall description

This section of the SRS describes all general factors of the product and its requirements.

2.1. Product perspective

2.1.1. System interfaces
In SAMS, the front end used is the visual studio 2010 which will get the input through swipes. The data obtained from the swipe are stored in the backend using the IBMdb2 database.

2.1.2. Hardware interfaces

a. Server Side The server side hardware required is IBM db2. b. Client Side The swipe machine gives the input to the database. when the students swipes their card, the student id no, date, and the time will be stored in their respective column in the database.

2.1.3. Software interfaces

a. Server Side IBMdb2 is used as database. Java code is used for validation purpose. b. Client Side Visual studio 2010 is the software which is used to get the input from the swipe machine.

2.2. System functions

This section outlines all the main feature of SAMS.

2.2.1. Student role

The work of the student is to swipe their ID card as they enter into the college. When the card is swiped,the student name ,date and time are fed as the input to the form.

2.2.2. Administration role

The system administrator must be able to: 1. Continuously updating the database 2.5 Assumptions and dependencies When the card is swiped, it enters the data into the database indicating their presence in the college. It is programmed in such a way that when the entry is empty it will send the SMS to the phone number which is fed already into the database. The correct functioning of SAMS will partly be dependent on the correctness of the data stored .Also, the event of the server failing due to an error with one of these applications might result in SAMS becoming temporarily unavailable.

3. Specific requirements
3.1. Functional requirements
3.1.1. User class Student
1. Student registration form. Student can be register on the system and fill in all detail and forward to choose project/supervisor.

2. Change Detail. Student can change detail if information is incorrect such as telephone number.

3.1.2. User class Academic Staff

All staff can view the details of any student. 3.1.4 User class Unit Cohort co-ordinator Certain staff may be designated as Unit or Cohort Co-ordinators and can change the details of any student doing their unit or project cohort. Change Student Detail Unit Cohort co-ordinator can change student detail for incorrect information. View Student Detail Unit Cohort co-ordinator can view student information and monitor their progress. List Student Unit Cohort co-ordinator can list all students in different period of different group. 3.1.5 User class System Administrator List Student System Administrator can list all students in different period of different group to check any error. 3.1.6 User class Administration Staff List Student Administration Staff can list all students in different period of different group. 3.2 Design constraints The system need to design base on the existed code and database using JAVA. 3.3 Software system attributes 3.3.1 Security The system needs to log clients information of registration such as IP address and time for security purpose. 3.3.2 Maintainability The system developing using Struts, all action is detailed in struts-config.xml and web.xml that easy to modify and make update. 3.3.3 Portability The application is coding in J2EE and Struts, therefore, it should be transferable between different OS and Java. 3.4 Other requirements For further extending, is able to send notification by SMS. *** End of the SRS ***

4. Data flow diagrams 4.1 What is a data flow diagram?

A data flow diagram (DFD) is a graphical description of the ebb and flow of data in a given context. A DFD allows you to identify the transformations that take place on data as it moves from input to output in the system. (DFDs pre-date UML diagrams, but still have a complementary role to play in describing systems.) The Case Study below provides an example of a DFD used to describe the Open University's eTMA system (electronic Tutor Marked Assignment system). It uses the notation described in Table 1 below.

Case study: An electronic tutor-marked assignment (eTMA) system

As you may already know, the Open University (OU) operates what we call the eTMA system a system that, among other things, enables students to submit their assignments electronically. The eTMA system came about through pressure, in the mid-1990s, from both students and the University. Students had begun to use word processors to prepare their assignments and they wanted to submit them electronically rather than print out the assignments and submit them using the postal system. At the same time, the University wanted to extend its reach to non-UK residents in countries where the postal system was less reliable and less efficient than that in the UK. Both sets of goals could be satisfied by an electronic system. At much the same time, demand for an electronic system was also coming from a small number of course teams in different academic units (the Faculty of Mathematics and Computing, the Faculty of Technology and the Business School). Although there was only a small number of courses involved, these were among the largest courses in the University (one of the Technology courses had 12,000 students on its first presentation!). Prior to the development of the eTMA system, the University's assignment handling system was entirely paper-based with assignments written (often by hand) on paper and posted to tutors. Paper-based TMAs were accompanied by a multipart control form (known as a PT3 form), the naming of which was lost in the sands of time, but we do know that PT stood for part time' and 3 indicated the third in a sequence of forms dealing with different aspects of assignment handling. The tutors mark the paper-based assignments, fill in the PT3 forms and send the amended documents to the University by post. The University operates a large Assignment Handling Office headed by the Head of Assignment Handling who is responsible for ensuring that all University policies and

functions relating to assignments are carried out appropriately. Among other things, assignment handling clerks (a) enter the marks into the student records database, (b) copy some assignments for monitoring (quality assurance) purposes, and (c) send the marked paper-based assignments back to the student using the postal service. The paper-based system runs in parallel with the eTMA system as there are still courses for which the eTMA system is not suitable for the types of assessment materials involved, and it acts as a back-up system should the eTMA system be unavailable. However, the University wants more courses to use the eTMA system because it provides a better service to students, gives more management information and is potentially less expensive.

The eTMA system

The eTMA system allows students to submit their answers to tutor-marked assignments (TMAs) electronically, as computer files, to the University via a website. Whenever a TMA file is submitted, it is stored in a central database and a receipt' (a simple me ssage containing a unique number) is sent to the student to acknowledge that the TMA has been received. Tutors (Associate Lecturers) are informed, by email, that a TMA is waiting for them to be marked. The system enables tutors to download their students' submissions, mark and comment on the assignments on-screen' and submit the marked TMAs back to the University. A marked TMA is stored in a database and the student is informed, by email, that their TMA has been marked and is available to be retrieved electronically. When the tutor downloads an unmarked TMA, she also receives an electronic version of the PT3 form on which the marks awarded for each question and the overall comments on the TMA must be entered. The completed PT3 form accompanies the TMA when it is sent to the OU database, and eventually both of them are sent electronically to the student. The data flow diagram given in Figure 1 summarises the basic system.

Figure 1 The basic electronic tutor-marked assignment system Whilst not shown in Figure 1, the fact that both the unmarked and marked assignments are saved by the University enables it to implement a number of web-based reports that provide summary information to students and tutors on the current status of their assignments within the system, as well as providing management information for the University's Assignment Handling Office. To match the existing paper-based TMA system, marks and tutor comments are extracted from marked assignments and added to the students' records. Since the number and size of eTMAs is potentially huge, the University has decided that complete marked and unmarked assignments would be stored only for a short period of time. From the start, the aim was to provide a web browser interface for both students and tutors. However, for security reasons, there would be two subsystems: one for students and one for tutors. Should the eTMA system ever fail and be unavailable to students, a back-up system has been implemented in which students are able to submit an assignment as an attachment to an email. The attachment is extracted by the University and fed into the eTMA system once the eTMA system is operational again. The basic system has been gradually enhanced and now provides a number of facilities not shown in Figure 1. For example, one of the OU's quality control systems involves monitoring, that is, examining

samples of each tutor's work to ensure that standards of marking are being maintained. In the paperbased TMA system, clerks in the central Assignment Handling Office take samples of marked TMAs, photocopy them, and send the copies to the monitors (academic staff who review the work of tutors and report back on the quality of the work). In the current version of the eTMA system, electronic copies of the tutors' work are sent to the monitors who will send back electronic versions of their reports. The eTMA system also checks a number of business rules regarding the submission of TMAs. For example, a student can make as many submissions as he likes, but only the last one will be marked (provided the submissions are made before the cut-off date or before the tutor has downloaded the eTMA). The system also rejects any submission that either contains a virus or is too large.

Table 1 DFD notation

Item External entity Process or activity Representation Meaning A producer or consumer of information that is outside the process being modelled. A transformer of information that is within the scope of the system being modelled. The input to, or output from, a given process, which is associated with each arrow in a DFD.

A rectangle

A circle

Data (flow)

A line with an arrowhead that indicates the direction of data flow

Data store

Two parallel lines with the name of the A repository of data for use by one or more data store between them processes.

The description inside each process bubble should be as terse and as meaningful as possible. The use of an imperative verb and a simple object can easily indicate the desired transformation. In the Case Study above for example, you can find processes called Submit assignment' and Download unmarked assignment'. It is common to use a decimal numbering system to identify each process or activity at its given level of abstraction. For example, in Figure 1, we could label the six process bubbles from 1 to 6 with Submit assignment' being number 1, say. Then, if we wanted to show the details of Submit assignment' in another DFD we would label the processes in the new diagram 1.1,1.2, and so on to show the connection with the original DFD.

When you decompose or refine an activity and show the result in a new DFD it is essential, for the development of a consistent set of models, that the inputs and outputs of each successive decomposition or refinement remain the same. In addition to the set of DFDs that describe something like the eTMA system, you should also prepare a dictionary or glossary of the terms you have used in the diagrams like assignment' and tutor identifier'. In particular, you need to re cord your understanding of the content of the data associated with each arrow and the stores. An important aspect of a DFD, and its main benefit in a requirements process, is that there is no explicit indication of the sequence of processing in the notation. A DFD identifies what is happening and what is being passed in and out of each activity, but it does not specify the order in which things happen. In other words, you can identify the activities that take place at a given level of abstraction, such as Figure 1 above, but some other technique is needed to indicate the time-ordering of those activities. Some kind of sequence may be implied by the naming of activities, as in Figure 1, although any combination of the activities may be somewhere between their starting and finishing points at a given point in time. The convention followed in DFDs to minimise the number of overlapping lines is to allow external entities and data stores to be duplicated.