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


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

problem analysis and requirement specification activities overlap.The final output is the software requirement specification document(SRS). However it is more likely that problem analysis and specification are done concurrently. PROCEDURE OF DRAWING DIAGRAMS FOR STUDENTS: Step 1. In practice. the specification activity come after the entire analysis is complete. However as all the information for specification comes from analysis. we can conceptually view the specification activity. as shown in figure 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 .For small problems or problems that can be easily comprehended. with movement from both activities to the other.

the university will not release your result until you do). even if they have completed some of the assessment tasks. etc. The system needs to be able to identify which offering a student was enrolled in. (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. 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. different semesters. regardless of whether they actually complete the assignments and exam.enrolled in a unit must be given a result. or who were enrolled and then withdrew from the unit. across different years. and teaching staff use the enrolment list to build their list of student names requiring results). different campuses. Examples attributes of unit enrolment might be: Studen Studen Unit Date Date of Enrolm t name t ID Code of withdr ent enrolm awal status ent Step 2. Unit offerings need to be identified and recorded long before the . Students who withdraw from the unit do not get a result. (Again the timing of data input is relevant here. Adding the details to cope with multiple offerings of units A unit will be offered many times. This means our E-R diagram needs a new entity to record the enrolments in each unit for whom results will be required. Therefore the systems need to be able to record the students who are correctly enrolled. Therefore we need an entity to deal with this information. different times of day (day/evening class).

The system needs to be able to identify these variations. so it would not be very sensible to try to include all the unit offering details as part of the Unit Enrolment entity). It may have alias names or codes or it may change name. we may need a new entity to hold this sort of information about units. Including further student details . Therefore. while still remaining the same unit. to prevent students from doing the same unit twice under different names/codes. Including further student details is given Unit enrolment enrols Unit offering has Unit Step 4. etc.students actually enrol. Sample attributes of Unit might be: Unit Name Unit Code Alias name Alias code Student Result Step 3. 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. code.

etc Course = Course name + Course code + Course type (bachelors. And of course most students are enrolled in a course. so we could add that link to if required. etc) + Course co-ordinator. etc). so we would like a separate entity to define the details of each course. 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. Masters by Research. e-mail. masters by Coursework. Sample attributes for these entities might be: Student = Student name + Student ID+ E-mail + Postal address + Phone. Possible attributes might be as follows: . etc Student Result is given Unit enrolment has Student is enrolled in Course contains enrolls Unit offering Unit has Step 5. Most units are also associated with particular courses. Adding the details of who manages the unit and course Courses are offered by faculties and units are run by departments.We want to record lots of information about students apart from just their enrolment in a particular unit (eg address. date of birth. phone. so we may want/need to extend our model to include information about these entities too.

a code like this can simplify data entry because the name need not be written in full).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. then we may wish to add information about the rooms and other resources needed to run a unit. SIMS is Department Code 931. For example: . 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. eg at Monash. What are the requirements for the classes which are run for the unit? If our system wants to cover resource allocation information.

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 Lecturer Tutors allocations code offering = No Room Unit Unit Lecture Tute Lab allocations code offering theatre rooms s = No .

Therefore this would add two more entities: Student Stud Assi Assi Assi Assi Assign Name ent gn 1 gn 1 gn 2 gn 2 total ID Mar valu Mar valu mark k e k e and Student Stud Exa Exa Exa Exa Exa … Exa 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 .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.

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 .

we finish up with the following big picture.The grade could be entered directly into the student result entity. . so this could be connected all the way back to the Faculty entity mentioned earlier. Grade Letter Lower limit Upper limit abbreviatio mark mark n Assignment result Step 10. Different departments/faculties may use different grading systems. or it could be calculated from the mark by referring to this Entity. Adding the rules for the grading system Exam result comprises Grading rules Student Result Special consideration application changes Combining all these E-R fragments.

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 .


APPENDICES 5. INTRODUCTION 1.5 Assumptions and Dependencies 2.2 Scope 1.3 Definitions. INDEX Software Requirements Specification Document for Student:1 Abstract . non-functional and interface requirement 4.3 User characteristics 2.1 Functional.2 Product functions 2. Acronyms and abbreviation 1.1 Purpose 1.1 Product perspective 2.4 General constraint 2.GENERAL SYSTEM REQUIREMENT SOFTWARE:1. OVERALL DESCRIPTION 3.4 Reference 1. SPECIFIC REQUIREMENTS 3.5 Overview 2.

2 Scope This document is the only one that describes the requirements of the system. 2. Acronyms. This document follows the IEEE standard for a requirements specification document. 2. The developer is responsible for asking for clarifications. The system to be developed is for the students to view their attendance. 2. It is meant for use by the developers and will be the basis for validating the final delivered system. 2 Introduction 2. and will not make any alterations without the permission of the client.This is the requirements document for the UMS that will be used throughout the university. It also describes the interfaces for the system. with some variations.5 Developer’s Responsibilities . Any changes made to the requirements in the future will have to go through a formal change approval process. Abbreviations Not applicable.1 Purpose The purpose of this document is to describe the external requirements for UMS scheduling system for an academic department in a University.3 Definitions. 2. Different conditions have to be satisfied by the final schedule. where necessary. view marks and online fee submission.4 References Not applicable.

A course has expected enrollment and could be for graduate students or undergraduate students. students are reading. Fee payment is done online. Some time when server is down the system should produce a “conflict report” that you cannot view the marks. Every department offers courses.The developer is responsible for (a) Developing the system (b) Installing the software on the client’s hardware (c) Conducting any user training that might be needed for using the system.1 Product Functions Overview In the LPU there are a set of departments. registration no.. who are somewhat literate with computers and can use programs such as editors and text processors.e.2 User Characteristics The main users of this system will be students.. attendance and payment of fee online and the reasons for the inability to schedule them. name . and (d) Maintaining the system for a period of one year after installation. which are chosen from the set of department courses. 3 General Description 3. . The system is to produce a schedule for the LPU that specifies the viewing marks. LPU take MTE and ETE for evaluation of students. In each course. 3. They give attendance in each lecture i. in theory as well as practical classes. course and subjects. attendance and online fee payment facility for students along with their roll no.

20000000] (e) No two students given one registration no. Outputs: Schedule. and fee payment for the courses such that the following constraints are satisfied: (a) Only the students which enter the correct registration no. (f) No two students given one roll no in a manner that does not violate these constraints. . and password would access the marks.e. roll no. Determine the registration no.4 General Assumptions and Dependencies 4 Specific Requirements 4.3 General Constraints Not applicable. [10000000. group and position in the class.3.2 BSD.2 Functional Requirements 1. marks. (b) Only the student which enters the correct registration no. and password would access the attendance. 3. (d) Registration must be within range given above i. (c) Roll no must be the combination of section. Inputs: Input file 1 and Input file 2. The system should run on Sun 3/50 workstations running UNIX 4.

the validity of the data in input file 1 should also be checked. Outputs: Output 2. . i. The data in input file 2 should be checked for validity against the data provided in input file 1.e. 4 Inputs: Input file 1 and Input file 2. Inputs: Input file 1 and Input file 2. 4.4 Performance Constraints 4. Produce a list of all students that could not be scheduled because some constraint(s) could not be satisfied and give reasons for unschedulability. 3. the reports should be printed in less than 1 minute. 4. Messages should be given for improper input data.2.5 Design Constraints Software Constraints For input file 2 containing 20 courses and up to 5 preferences for each course. and the invalid data item should be ignored. The file names can be specified in the command line itself or the system should prompt for the input file names. Outputs: Error messages..3 External Interface Requirements User Interface: Only one user command is required. list of unschedulable courses and preferences and why. Where possible.

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

Sign up to vote on this title
UsefulNot useful