IMAT1401 Information Systems Development

Jared Leto is Head of Corporate Information Systems at Di Caprio.  One of his main priorities is to web-enable the University’s core business systems.  This project is to develop a system that will provide online access to the existing student records system.   The system will be used by the faculty office administrators, lecturers, course leaders and faculty managers throughout the University.  

Due to a backlog of work, Jared has decided to outsource part of the work to an IT consultant.  You have been awarded the contract to deliver a specification for the system and then to develop a limited software prototype.

The Project Initiation Document identifies the following main functional areas.  These should be analysed in more detail in the specification.  However, the prototype version of the system will not cover all the functional areas – only one use case is to be designed in detail and implemented at this stage.

Faculty Office Clerical Staff

·Handle all student enrolments – input new students, edit existing students (e.g. to correct errors or to update address details) and terminate students who have left

·Input and edit student marks on modules, both for coursework and exams

·Query the database, for example to find out student contact details

·Produce printed reports, e.g. for assessment boards to review student marks

Faculty Office Supervisors

·All tasks that clerical staff can carry out, plus access to the same reports as faculty management Academic Staff (Lecturers and Course Leaders)

·Read only access to the system at a detailed level, for example to find out student contact details, grades, class lists, etc.

·Academic staff must not be able to edit any data on the system Faculty Managers

·Read-only access to onscreen reports, for example to find out the overall number of students on a course, the overall level of marks for a module, etc.

The system will have a simple three layer distributed architecture.  The front-end (user interface) will consist of web pages.  The middle layer will use C# scripts to handle web requests and pass them to the database, and to format the database output for display.  The third layer is the database.  This will be programmed in SQL and will run in Sequel Server.

The specification is due on SPEC DATE and the prototype is due on PROT DATE.

Data Requirements

The software prototype needs a test database that must be capable of supporting the following queries:

·Find a given student by name, student id, date of birth (or possibly other criteria) and show their personal details, the course they are enrolled on, the modules they are enrolled on, and their marks (if any) for each module.

Further information: each student must be enrolled on one course and also on a number of modules.  Each course limits, but does not fully determine, the modules a student can take, since some modules are options on a given course while others are compulsory.

·Find a given module by code or by name and show all courses that take it, all students enrolled on it, all lecturers that teach it, and all marks awarded so far.  

Further information: some modules have more than one member of staff.  The staff on a module may change from one year to the next.  A student may have a mark for each module, but only after the assessment has taken place and the mark has been entered.

·Produce timetables that show the relevant classes for an individual student, an individual lecturer, a specific room, a module or a whole course.

Further information: modules are delivered as a series of classes.  A ‘class’ – a single timetable event – involves a group of students, a member of staff, a room and a specific time and date.

·Find a given course by name or by code and show (for a given year) all modules taken on it, all lecturers that teach on it, all students enrolled on it and all marks awarded so far.

Further information: the students enrolled on a module will obviously change from one year to the next.  The modules offered on a course might also change over time, so each annual run of a module must be recorded separately.

The test database should also support the updates needed to enter and amend all data.  This will allow thorough testing of the user interface and process layers of the system.

This covers both requirements and design.  It must include the following:

·A Use Case Model showing all the main use cases and actors

·A single top-level (Level One) Data Flow Diagram for the proposed system (Context Diagram is not required).

·An Entity Relationship Diagram for the proposed system, plus a document giving full table definitions with all attributes, primary and foreign keys clearly shown.

·Detailed screen designs for two functional screens with information content, guidance or help, colours, fonts, controls, etc. all clearly shown.  ‘Functional’ means some input or output of data – e.g. enrol a new student – not just menus or confirmation message screens. Screen designs can be hand-drawn and included as images in your document.