You are on page 1of 14

Design Problem # 1 Of Software Engineering Submitted to: Mr.

Sartaj

Su bmitted by: KAPOOR l No. RA3803B35 No.10810263 MCA(hons.) Reg Course JITEN Rol

PROCEDURE OF DRAWING ER DIAGRAMS FOR STUDENTS: Step 1. Recording the unit enrolments

Who are the students who need to be given results? We cannot rely on the assignment and exam results only as our source of student names. All students enrolled in a unit must be given a result, regardless of whether they actually complete the assignments and exam. Likewise any student who is not correctly enrolled is not entitled to be given a result (eg if you have not paid your enrolment fees for a unit, the university will not release your result until you do). Students who withdraw from the unit do not get a result, even if they have completed some of the assessment tasks. Therefore the systems need to be able to record the students who are correctly enrolled, or who were enrolled and then withdrew from the unit. This means our E-R diagram needs a new entity to record the enrolments in each unit for whom results will be required. (Note the

establishment of a separate entity to hold this data is also a timing issue Students enroll in units many months before they take their assessment, and teaching staff use the enrolment list to build their list of student names requiring results). Examples attributes of unit enrolment might be:

Step 2. Adding the details to cope with multiple offerings of units

A unit will be offered many times, across different years, different semesters, different campuses, different times of day (day/evening class), etc. The system needs to be able to identify which offering a student was enrolled in. Therefore we need an entity to deal with this information. (Again the timing of data input is relevant here. Unit offerings need to be identified and recorded long before the students actually enrol, so it would not be very sensible to try to include all the unit offering details as part of the Unit Enrolment entity). Attributes of Unit Offering might be as follows:

Step 3. Including further student details

Over time a unit may also change some of its details. It may have alias names or codes or it may change name, code, etc, while still remaining the same unit. The system needs to be able to identify these variations, to prevent students from doing the same unit twice under different names/codes. Therefore, we may need a new entity to hold this sort of information about units. Sample attributes of Unit might be:

Step 4. Including further student details

We want to record lots of information about students apart from just their enrolment in a particular unit (eg address, e-mail, phone, date of birth, etc), so we would not want to have to record all that in every unit enrolment. Therefore we want a separate entity to record details about each student. And of course most students are enrolled in a course, so we would like a separate entity to define the details of each course. Most units are also associated with particular courses, so we could add that link to if required. Sample attributes for these entities might be: Student = Student name + Student ID+ E-mail + Postal address + Phone, etc Course = Course name + Course code + Course type (bachelors, Masters by Research, masters by Coursework, etc) + Course co-ordinator, etc
Student Result is given Unit enrolment has Student is enrolled in Course contains enrolls Unit offering Unit has

Step 5. Adding the details of who manages the unit and course

Courses are offered by faculties and units are run by departments, so we may want/need to extend

our model to include information about these entities too. Possible attributes might be as follows:

Faculty = Faculty name + Faculty code +

Faculty contact person + Phone + etc Department = Department name + Department code + Department contact person + Phone etc (note that these entities like these are sometimes created simply to define a code by which the faculty or department can be identified; eg at Monash, SIMS is Department Code 931; a code like this can simplify data entry because the name need not be written in full).

Step 6. What are the requirements for the classes which are run for the unit?

If our system wants to cover resource allocation information, then we may wish to add information about the rooms and other resources needed to run a unit. For example:

Room requirements = Unit code + Lecture

room requirements + Tutorial room requirements + Lab requirements + Studio requirements + etc Resource requirements = Unit code + Software needed + No. of licences + Specialist hardware needed + etc

Step 7. What rooms and staff are allocated to a particular unit offering?

For any given offering of a unit we may want to record information about the staff and rooms which were allocated to each unit offering:

Step 8. Recording the details of assessment items

Leaving the unit information and returning to our original Student Results entity, our results system might want to record the detailed information about assignment and exam marks for each student. Therefore this would add two more entities: and

Assignment result

Exam result

comprises Student Result

Step 9. Including the recording of special consideration information

Special consideration applications affect the Student result, so we may wish to add an entity to record the details of applications and their outcomes: Student Student Date of Reasons/con Decisio name ID applicati dition n on

The grade could be entered directly into the student result entity, or it could be calculated from the mark by referring to this Entity. Different departments/faculties may use different grading systems, so this could be connected all the way back to the Faculty entity mentioned earlier. Grade Letter Lower limit Upper limit abbreviati mark mark on

Step 10. Adding the rules for the grading system

Combining all these E-R fragments, we finish up with the following big picture

ER DIAGRAM FOR STUDENTS AND TEACHERS: -

GENERAL SYSTEM REQUIREMENT SOFTWARE:-

1. INTRODUCTION

1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and abbreviation 1.4 Reference 1.5 Overview 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraint 2.5 Assumptions and Dependencies 3.1 Functional, non-functional and interface requirement

2. OVERALL DESCRIPTION

3. SPECIFIC REQUIREMENTS

4. APPENDICES 5. INDEX Software Requirements Specification Document for Student:1 Abstract

This is the requirements document for the UMS that will be used throughout the university. The system to be developed is for the students to view their

attendance, view marks and online fee submission. Different conditions have to be satisfied by the final schedule.

2 Introduction

2.1 Purpose

The purpose of this document is to describe the external requirements for UMS scheduling system for an academic department in a University. It also describes the interfaces for the system.

2.2 Scope

This document is the only one that describes the requirements of the system. It is meant for use by the developers and will be the basis for validating the final delivered system. Any changes made to the requirements in the future will have to go through a formal change approval process. The developer is responsible for asking for clarifications, where necessary, and will not make any alterations without the permission of the client.

2.3 Definitions, Acronyms, Abbreviations


Not applicable.

2.4 References
Not applicable.

2.5 Developers Responsibilities


The developer is responsible for (a) Developing the system

(b) Installing the software on the clients hardware (c) Conducting any user training that might be needed for using the system, and (d) Maintaining the system for a period of one year after installation.

3 General Description 3.1 Product Functions Overview

In the LPU there are a set of departments. Every department offers courses, which are chosen from the set of department courses. A course has expected enrollment and could be for graduate students or undergraduate students. In each course, students are reading. They give attendance in each lecture i.e. in theory as well as practical classes. LPU take MTE and ETE for evaluation of students. Fee payment is done online. The system is to produce a schedule for the LPU that specifies the viewing marks, attendance and online fee payment facility for students along with their roll no., name , registration no., course and subjects. Some time when server is down the system should produce a conflict report that you cannot view the marks, attendance and payment of fee online and the reasons for the inability to schedule them.

3.2 User Characteristics

The main users of this system will be students, who are somewhat literate with computers and can use programs such as editors and text processors.

3.3 General Constraints


Not applicable.

The system should run on Sun 3/50 workstations running UNIX 4.2 BSD.

3.4 General Assumptions and Dependencies 4 Specific Requirements 4.2 Functional Requirements
1.

Determine the registration no, roll no, marks, and fee payment for the courses such that the following constraints are satisfied: (a) Only the students which enter the correct registration no. and password would access the marks. (b) Only the student which enters the correct registration no. and password would access the attendance. (c) Roll no must be the combination of section, group and position in the class. (d) Registration must be within range given above i.e. [10000000, 20000000] (e) No two students given one registration no. (f) No two students given one roll no in a manner that does not violate these constraints.

Inputs: Input file 1 and Input file 2. Outputs: Schedule.

2. Produce a list of all students that could not be scheduled because some constraint(s) could not be satisfied and give reasons for unschedulability.

Inputs: Input file 1 and Input file 2. Outputs: Output 2, i.e., list of unschedulable

courses and preferences

and why. 3. The data in input file 2 should be checked for validity against the data provided in input file 1. Where possible, the validity of the data in input file 1 should also be checked. Messages should be given for improper input data, and the invalid data item should be ignored. 4

Inputs: Input file 1 and Input file 2. Outputs: Error messages.

You might also like