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

Sartaj

Su bmitted by: Baveja l No. RA3803B28 No.10807675 MCA(hons.) Reg Course Tarun Rol

The final output is the software requirement specification document(SRS).For small problems or problems that can be easily comprehended, the specification activity come after the entire analysis is complete. However it is more likely that problem analysis and specification are done concurrently. In practice, problem analysis and requirement specification activities overlap, with movement from both activities to the other, as shown in figure 1. However as all the information for specification comes from analysis, we can conceptually view the specification activity.

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

ER

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: Stude Stude Unit Date Date of Enrolm nt nt ID Code of withdr ent name enrolm awal status ent

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: Unit Year Semest Campu Time (Day or code er s evening class)

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: Unit Name Unit Code Alias name Alias code
Student Result

Step 3. Including further student details

is given
Unit enrolment

enrols Unit offering has Unit

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).
Student Result

is given Unit enrolment has Student is enrolled contains in Course offered by Faculty has Unit runs Department Belongs to

enrolls Unit offering

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
Unit offering Unit

Room requirements

Resource requirements

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: Staff Unit Unit Lecture Tutors allocation code offering r s= No Room Unit Unit Lecture Tute Lab allocations code offering theatre rooms s = No

Staff allocations

Unit offering

Unit

Room allocations

Room requirements

Resource requirements

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: Studen Stud Assi Assi Assi Assi Assign t Name ent gn 1 gn 1 gn 2 gn 2 total ID Mar valu Mar valu mark k e k e and Studen Stud Exa Exa Exa Exa Exa Exa t Name ent m m m m m etc m ID Q1 Q2 Q3 Q4 Q5 Tot mar mar mar mar mar al k k k k k

Step 8. Recording the details of assessment items

Assignment result

Exam result

comprises Student Result

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
Assignment result

Step 9. Including the recording of special consideration information

Exam result

comprises Student Result Special consideration application

changes

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
Assignment result

Step 10. Adding the rules for the grading system

Exam result

comprises Grading rules Student Result Special consideration application

changes

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

Assignment result

Exam result

comprises Grading rules based on Student Result changes

Special consideration application

is given Unit enrolment has

lodges Student is enrolled contains in Course offered by Faculty has Unit needs needs runs Department belongs to

is taught by Staff allocations

enrolls Unit offering is taught in

Room allocations

Room requirements

Resource requirements

ER DIAGRAM FOR STUDENTS AND TEACHERS: -

NAME ADDR NAME COURSE STUDYIN G IN UNIVERSITY ADDR

STUDENT

MARKS WORKS IN TAUGH T BY ATTENDANCE

ATTENDANCE

TEACHER

NAME

SUBJEC T SALARY

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. This document follows the IEEE standard for a requirements specification document, with some variations.

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 3.3 General Constraints

Not applicable.

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. 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. 4.3 External Interface Requirements

User Interface: Only one user command is required. The file names can be specified in the command line itself or the system should prompt for the input file names.

4.4 Performance Constraints

For input file 2 containing 20 courses and up to 5 preferences for each course, the reports should be printed in less than 1 minute.

4.5 Design Constraints

Software Constraints Hardware Constraints Acceptance Criteria
The system is to run under the UNIX operating system.

The system will run on a Sun workstation with 256 MB RAM, running UNIX. It will be connected to an 8-page-per-minute printer. Before accepting the system, the developer must demonstrate that the system works on the course data for the last 4 semesters. The developer will have to show through test cases that all conditions are satisfied.