Software Requirements Specification on Student Information System (SRS on SIS)

Student Information System
Software Requirements Specification and Analysis
November 29, 2014
SE-406

SE-406
Submitted by
BSSE0502 - Jobayer Ahmmed
BSSE0509 - Minhas Kamal
BSSE0516 - Md. Rakib Hossain
BSSE0522 - Md. Abdul Mannan
BSSE0528 - Naima Afroz
BSSE0535 - Khandaker Mamun Ahmed
Submitted to
Dr. Kazi Muheymin-Us-Sakib
Associate Professor
Institute of Information Technology
University of Dhaka
Submission Date
29th November, 2014

i
LETTER OF TRANSMITTAL
29th
November, 2014.
Dr. K. M. Sakib
Associate Professor
Institute of Information Technology,
University of Dhaka.
Sir,
We have prepared the report on Software Requirements Specification
of ‘Student Information System for IIT DU’ for your approval. This
report details the requirements we gathered for the project.
The primary purpose of this report is to summarize our findings from
the work that we completed as our Software Requirements
Specification and Analysis course project. This report includes the
details of each step we followed to collect the requirements.
Sincerely Yours,
Jobayer Ahmmed (BSSE-0502)
Minhas Kamal (BSSE-0509)
Md. Rakib Hossain (BSSE-0516)
Md. Abdul Mannan (BSSE-0522)
Naima Afroz (BSSE-0528)
Khandaker Mamun Ahmed (BSSE-0535)
Enclosure: SRS Report

ii
Executive Summary
A Student Information System (SIS) is proposed by Institute of
Information Technology, University of Dhaka (IIT, DU) for the students
of Post Graduate Diploma in Information Technology (PGDIT) and
Master of Science in Information Technology (MIT). It would be a web-
based system where students and the course teachers are provided
with different kinds of information about their course materials,
financial activities and their whole academic life.
Acknowledgements
By the grace of Almighty Allah we have completed our report on
Software Requirements Specification of Student Information System on
the course of PGDIT & MIT for IIT, DU.
We are grateful to our honorable sir Dr. K. M. Sakib for his supervision
throughout the working time. He helped us a lot by sharing his
invaluable knowledge with us.
We are also thankful to the Program Coordinators of PGDIT & MIT.
They greatly helped us collecting information among all business.
The Program Officer & the Accountant was also a big help. We just
cannot thank them enough.

iii
Table of Contents
Chapter 1: Introduction ........................................................................... 1
1.1 Purpose 1
1.2 Intended Audience 1
Chapter 2: Inception .................................................................................. 3
2.1 Introduction 3
2.1.1 Identifying Stakeholders 3
2.1.2 Asking the First Questions 5
2.1.3 Recognizing Multiple Viewpoints 5
2.1.4 Working towards Collaboration 7
2.2 Conclusion 9
Chapter 3: Elicitation ................................................................................ 12
3.1 Introduction 12
3.2 Eliciting Requirements 12
3.3 Collaborative Requirements Gathering 12
3.4 Quality Function Deployment 13
3.4.1 Normal Requirements 13
3.4.2 Expected Requirements 14
3.4.3 Exciting requirements 14
3.5 Usage Scenarios 15
3.6 Elicitation Work Product 17
Chapter 4: Scenario-Based Model ........................................................ 20
4.1 Introduction 20
4.2 Use Case Scenario 20
4.3 Use Case Descriptions 22
4.3.1 Student Information System 23
4.3.1.1 Authentication 24
4.3.1.2 Admission Process 34
4.3.1.3 Manage Program Office Work 44
4.3.1.4 Administrative Work 63
4.3.1.5 Maintain Course Program 73
4.3.1.6 Provide Resource & Marks 83

iv
6
Table of Contents
Chapter 5: Data Model .............................................................................. 90
5.1 Introduction 90
5.2 Data Object Selection 90
5.3 Data Objects & Attributes 95
5.4 Relationship between Data Objects 96
5.5 E-R Diagram 97
5.6 Schema Diagram 98
5.7 Table Creation Statement 100
Chapter 6: Class-Based Model .............................................................. 101
6.1 Introduction 101
6.2. General Classification 101
6.3 Selection Characteristics 104
6.4 Attribute Selection 105
6.5 Defining Methods 107
6.5.1 Verb List 107
6.5.2 Selected Methods 109
6.6 Class Diagram 110
6.7 Class Card 111
Chapter 7: Flow-Oriented Model .......................................................... 113
7.2 Data Flow Diagram (DFD) 115
Chapter 8: Behavioral Model .................................................................. 118
8.2 Identifying Events 118
8.3 State Transition Diagram 120
8.4 Sequence Diagram 126
Chapter 9: Conclusion .............................................................................. 142
Appendix ........................................................................................................ 143

Software Requirement
Software Requirements Specification & Analysis
Specification & Analysis

1
Chapter 1
Introduction
1.1 Purpose
This document is the Software Requirements Specification (SRS) for the IIT, DU
Student Information System (SIS). It contains detailed functional, non-functional,
and support requirements and establishes a requirements baseline for
development of the system. The requirements contained in the SRS are
independent, uniquely numbered, and organized by topic. The SRS serves as the
official means of communicating user requirements to the developer and
provides a common reference point for both the developer team and stakeholder
community. The SRS will evolve over time as users and developers work together
to validate, clarify and expand its contents.
1.2 Intended Audience
This SRS is intended for several audiences, including the customer, as well as the
project managers, designers, developers, and testers.
 The customer will use this SRS to verify that the developer team has
created a product that is acceptable to the customer.
 The project managers of the developer team will use this SRS to plan
milestones and a delivery date, and ensure that the developing team is on
track during development of the system.
 The designers will use this SRS as a basis for creating the system’s design.
The designers will continually refer back to this SRS to ensure that the
system they are designing will fulfill the customer’s needs.
 The developers will use this SRS as a basis for developing the system’s
functionality. The developers will link the requirements defined in this SRS
to the software they create to ensure that they have created software that
will fulfill all of the customer’s documented requirements.

2
 The testers will use this SRS to derive test plans and test cases for each
documented requirement. When portions of the software are complete,
the testers will run their tests on that software to ensure that the software
fulfills the requirements documented in this SRS. The testers will again run
their tests on the entire system when it is complete and ensure that all
requirements documented in this SRS have been fulfilled.

3
Chapter 2
Inception
2.1 Introduction
Inception is the beginning phase of requirements engineering. It defines how does
a software project get started and what is the scope and nature of the problem to
be solved. The goal of the inception phase is to identify concurrence needs and
conflict requirements among the stakeholders of a software project. To establish
the groundwork we have worked with the following factors related to the
inception phases:
 Identifying Stakeholders
 Asking the First Questions
 Recognizing Multiple Viewpoints
 Working towards Collaboration
2.1.1 Identifying Stakeholders
Stakeholder refers to any person or group who will be affected by the system
directly or indirectly. Stakeholders include end-users who interact with the
system and everyone else in an organization that may be affected by its
installation. To identify the stakeholders we consulted with Program Chair and
asked him following questions:
 Who is paying for the project?
 Who will be using the project outcomes?
 Who gets to make the decisions about the project (if this is different
from the money source)?
 Who has resources I need to get the project done?

4
 Whose work will my project affect? (During the project and also once
the project is completed)
Concluding thoughts on Stakeholders, We identified following stakeholders for
our automated Student information system for IIT DU:
1. Program Chair: The Program Chair is the person who has the final
authority over our budget, our personal resources, and ultimately the
finished product. His position empowers him to veto a decision made by
the other Stakeholders. As head of Program Courses, the Program Chair
has direct authority over our Systems budget, and our team— the
people developing the site and doing much of the “management” end of
this project.
2. Program Coordinator: Program coordinator will directly interact with
the system. But program coordinators are selected from the faculty
member so they have two different roles in this system.
3. Program Officer: Program officer will directly interact with the system.
He will provide a lot of information and has a responsibility to maintain
the system.
4. Program Accountant: Program accountant will directly interact with the
system related to any financial activity.
5. Registered Students: The largest user group of the system. They will
provide with all that information which is essential to them. Besides
they will search for items, renew items and reserve items. They will
directly interact with the system.
6. Faculty Members: Faculty member are also responsible for providing all
that information which is essential to the student on a particular course.
They will directly interact with the system.
7. Developers: We selected developers as stakeholder because they
develop this system and Work for further development. If occurs any
system interruption, they will find the problem and try to solve it.
8. Alumni: Alumni’s will also interact with the system. They provide
information in the system and also are provided with the system.
9. Guest: They indirectly interact with the system through an interface to
get information that is essential to them.

5
2.1.2 Asking the First Questions
We set our first set of context-free questions focuses on the customer and other
stakeholders, overall project goals and benefits. The questions are mentioned
above. These questions helped us to identify all stakeholders, measurable benefit
of the successful implementation and possible alternatives to custom software
development. Next set of question helped us to gain a better understanding of
problem and allows the customer to voice his or her perception about the
solution. The final set of question focused on the effectiveness of the
communication activity itself.
2.1.3 Recognizing Multiple Viewpoints
We collect these view points by discussing with the Program Chair, Program
Coordinator, Program Officer, Program Accountant, Registered Student, Faculty
members and Alumni of Institute of Information Technology University Of Dhaka.
Besides we also collect some viewpoints from some non-registered students as
guest.
1. Program Chair:
a. Maintain a database of all items in the student information system.
b. Restrict access to functionality of the system based upon user roles.
For example, only Administrators of the system will be provided
functionality to change user types, configure new changes.
c. Verify all items if any major changes occurs within the system.
d. Restrict access to functionality of the system based upon user roles.
2. Program Coordinator:
a. Web-Based Interfaces.
b. Allow the system to be accessed via the Internet.
c. The application can be accessed from any computer that has Internet
access.

6
3. Program Officer:
a. Allow program officer to check-out and check-in items for valid users.
b. The application should be installed and maintained on one computer.
c. Web-Based Interfaces.
d. Allow Program officer to generate reports, editing information on the
items in the system.
e. A user guide describing how to use SIS IIT DU need to be deployed
with the system.
f. A product reference manual describing how to install, setup, and run
the application shall be provided.
4. Program Accountant:
a. Allow the system to be accessed without internet.
b. Easy Access.
c. Allows valid users to temporary information online by logging into
the system.
d. To allow Program Account to log in the system with the official
computers.
5. Registered Students:
b. Easy Access.
c. Enable to log in from smart phones or tablets.
d. Allow the system to be accessed via the Internet.
e. The application can be accessed from any computer that has Internet
access.
f. Easily maintainable profile.

7
6. Faculty Members:
b. Easy Access.
access.
7. Alumni:
b. Easy Access.
access.
2.1.4 Working towards Collaboration
Every stakeholder has their own requirements. We followed following steps to
merge these requirements:
 Identify the common and conflicting requirements
 Categorize the requirements
 Take priority points for each requirement from stakeholders and on the
basis of this voting prioritize the requirements
 Make final decision about the requirements

8
Common Requirements:
 Web-Based Interfaces.
 The application can be accessed from any computer that has Internet
access.
 Easy Access.
 Enable to log in from smart phones or tablets .
 Maintain a database of all items in the student information system.
Conflicting Requirements:
 Easy access and Strong Authentication.
 Allow any user to use the system and allow valid user to use the system.
 To allow Program Account to log in the system with the official computers.
Final Requirements:
We finalized following requirements for the system by categorizing and
prioritizing the requirements:
 Error free system (Maximum 5% error may be considerable).
 Web-based interfaces.
 Accessible via the Internet.
 Allow valid users to login and logout.
 Restrict access to functionality of the system based upon user roles.
 Allow administrators of the system to change user types and configure
parameters of the system.
 Allow any guest user to search for information in the student information
system‘s home page without having to log in to the system.

9
 Allow valid users that log in to renew items, reserve items, and view the
items they have checked out.
 Allow Program chair and Program Officer to check-out and check-in items
for valid users.
 Allow Program officer to generate reports, editing information on the items
in the system.
 Allows valid users to renew items online by logging into the system.
 Maintain a database of all items in the Student Information System.
 Restrict access to functionality of the system based upon user roles. For
example, Only Administrators of the system will be provided functionality
to change user types, configure new changes to maintain database.
2.2 Conclusion
Inception phase helped us to establish basic understanding about Student
information system for IIT, DU; identify the people who will be benefited if
student information system becomes automated, define the nature of the
student information software and establish a preliminary communication with
our stakeholders.
Group Meeting
1. Date: July 06, 2014
Subject: Identifying Stakeholders
Place: Institute of Information Technology, University of Dhaka

10
Members:
○ BSSE 0502- Jobayer Ahmmed
○ BSSE 0509- Minhas Kamal
○ BSSE 0516- Md Rakib Hossain
○ BSSE 0522- Md Abdul Mannan
○ BSSE 0528- Naima Afroz
○ BSSE 0535- Khandaker Mamun Ahmed
2. Date: August 12, 2014
Subject: Identifying Stakeholders
Members:
3. Date: September 08, 2014
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology University of Dhaka
Members:

11
Members:
Members:

12
Chapter 3
Elicitation
3.1 Introduction
Elicitation is a task that helps the customer to define what is required. To
complete the elicitation step we face many problems like problems of scope,
problems of volatility and problems of understanding. However, this is not an
easy task. To help overcome these problems, we have worked with the Eliciting
requirements activity in an organized and systematic manner.
3.2 Eliciting Requirements
Unlike inception where Q&A (Question and Answer) approach is used, elicitation
makes use of a requirements elicitation format that combines the elements of
problem solving, elaboration, negotiation, and specification. It requires the
cooperation of a group of end-users and developers to elicit requirements .To
elicit requirements we completed following four works.
1. Collaborative Requirements Gathering
2. Quality Function Deployment
3. Usage Scenarios
4. Elicitation work products
3.3 Collaborative Requirements Gathering
Many different approaches to collaborative requirements gathering have been
proposed. Each makes use of a slightly different scenario .We completed
following steps to do it.

13
 The meetings were conducted with Program Chair .He was questioned
about their requirements and expectations from the automated Student
information system.
 He was asked about the problems he is facing with the current manual
system. At last we selected our final requirement list from the meetings.
3.4 Quality Function Deployment
Quality Function Deployment (QFD) is a technique that translates the needs of the
customer into technical requirements for software .It concentrates on maximizing
customer satisfaction from the Software engineering process .With respect to our
project the following requirements are identified by a QFD.
3.4.1 Normal Requirements
Normal requirements consist of objectives and goals that are stated during the
meeting with the customers. Normal requirements of our project are:
1. Accessible via the Internet.
2. Allow any valid user to log in and log out to the system.
3. Allow Program Chair and Program Officer to check items for valid users.
5. Restrict access to functionality of the system based upon user roles.
6. Allow valid users that log in to renew items and view the items.
8. The application only needs to be installed and maintained on one
computer.
9. Help feature to explain what they are looking for.
10. A product reference manual describing how to install, setup and run the
application will be provided.

14
3.4.2 Expected Requirements
These requirements are implicit to the system and may be so fundamental that
the customer does not explicitly state them. Their absence will be a cause for
dissatisfaction.
1. Maintain a database of all items in the student information system.
2. The system shall enable the administrator to change a user’s type to any
user type.
3. Administrator will be able to configure the any changes.
4. The system shall enable the program officer to change or update any
information.
5. The system shall allow the user to log in based upon an assigned login ID
and password.
6. The system shall automatically send notification to the user when
program chair uploads any emergency notice.
7. The user interface of the system shall be easy to use and shall make use
of drop-down boxes, radio buttons, and other selectable fields wherever
possible instead of fields that require the user to type in data.
3.4.3 Exciting Requirements
These requirements are for features that go beyond the customer's expectations
and prove to be very satisfying when present.
1. The user interface should provide appropriate error messages for invalid
input as well as tool-tips and online help.
2. The user interface should follow standard web practices such that the
web interface is consistent with typical internet applications.
3. Offer log in with smart phone and tablets.
4. The system’s configuration shall be documented and updated as changes
to the system are made due to patches, new releases, new Changes etc.

15
3.5 Usage Scenario
Student Information System for IIT DU
A Student Information System (SIS) is proposed by Institute of Information Technology,
University of Dhaka (IIT, DU) for the students of Post Graduate Diploma in Information
Technology (PGDIT) and Master of Science in Information Technology (MIT). It would
be a web-based system where students and the course teachers are provided with
different kinds of information about their course materials, financial activities and their
whole academic life.
Admission Process:
In every year IIT DU publishes two circulars (September to December) to enroll new
students in these two course programs (PGDIT & MIT). These circulars contain a full
description of admission processes. The admission test has two phases, first one is
written test and second one is viva test. Students who are qualified in the written test
are requested to attend for the viva. At the end, total 40 students are selected from this
whole admission process along with two waiting lists containing 10 students in each list.
Regular Program Office (RPO) is responsible for publishing and updating all these
notices and circulars.
Registration Process:
After completing the selection procedure, new students are enrolled in their respective
course programs. Selected students have to pay semester fee in bank at the beginning
of the registration process. Besides they are requested to fill-up their necessary
documents and submit their previous academic documents in the program office.
Students also have to do a registration in their assigned halls. Students who have
completed their registration process (both in IIT and Hall) are treated as regular
students and a student profile is created for every student.
Regular Program Office (RPO):
Both MIT and PGDIT programs are semester based. MIT program contains four
semesters for one and a half year and PGDIT program contains three semesters for one
year. For both programs, the length of every semester is four months. At the beginning
of every semester, it is the responsibility of RPO to publish all the notices related to
both programs (PGDIT & MIT) separately, such as academic calendar, class routine,
amount and submission deadline of each semester fee and other cultural activity fees
and forms.
Responsibility of Program Officer (PO):
PO manages program office works. He creates student and course teacher profile;
uploads academic calendar, class routine, exam routine and all other notices. Besides,

16
students who want to withdraw their academic papers, character certificates or want to
change their profile information such as phone number, present address etc. contact to
the PO.
Responsibility of Program Accountant (PA):
For doing any financial activity at IIT, students are requested to contact the PA. At the
beginning of every semester, students have to pay semester fee at the bank. For this
submission every student has to fill-up a form provided by the PA. After submitting the
fee at the bank, students are requested to return the institute part of that form to the
PA. It is the PA’s responsibility to ensure that every student has submitted the returning
part to IIT.
Responsibility of Program Chair (PCh):
Program chair is the administrator of the whole system. He assigns program
coordinator, program officer and program accountant. He can see and remove all the
notices.
Responsibility of Program Coordinator (PCo):
Each program (MIT, PGDIT) has a PCo. The PCo is responsible for maintaining the
course program. He verifies documents, controls emergency issues, registers students
and course teachers and publishes notices.
Responsibility of Assigned Course Teacher:
It is an inquiry of every registered student to have the knowledge about their courses,
course materials, reference books and web links, course objectives and marks
distribution policies. It is the responsibility of assigned course teachers to provide the
above resources with the students at the beginning of every semester. At the end of
every semester or during a running semester, students are also interested to know their
marks and grades in every section of their assigned courses. Teachers are also
responsible to submit their course mark sheets within a dead line. In case of any
changes of the marks distribution, assigned teachers are responsible for making those
changes.
The Alumnus:
Students who have successfully completed any program (MIT or PGDIT) are considered
to be a alumnus of IIT. All the information of alumnus, such as their academic profile,
their contribution to IIT, current job position, address, phone number, email address
etc. are preserved to RPO. If any change is occurred in the personal information of any
individual alumnus, it is his/her responsibility to make the change.

17
3.6 Elicitation Work Product
The output of the elicitation task can vary depending on size of the system or
product to be built. Our elicitation work product includes:
 A statement of our requirements for automated book circulation system.
 A bounded statement of scope for our system.
 A list of customers, users and other stakeholders who participated in
requirement specification.
 Set of usage scenarios.
 Description of the system’s technical environment.
Group Meeting
Subject: Meeting with the Program Chair
Members:
Subject: Meeting with Program Officer, Program Accountant

18
Members:
Subject: Meeting with the Program Chair, Registered Student
Members:
4. Date: October 21, 2014
Subject: Meeting with the Program Coordinator
Members:

19
Subject: Discussion on the QFD
Members:
Subject: Preparing the user scenarios
Members:

20
Chapter 4
Scenario-Based Model
4.1 Introduction
In this model the system is described from the user’s point of view. As this is the
first model, it serves as input for creation of other modeling elements.
4.2 Use Case Scenario
As requirements are gathered, an overall vision of system functions and features
begins to materialize. To understand how these functions and features will be
used by different classes of end users, developers and users create a set of
scenarios, called use case scenario, that identify a thread of usage for the system
to be constructed.
Use Case Scenario
Level-0 Level-1 Level-2 Actors
Student
Information
System
Authentication Sign In Program Officer,
Program Coordinator,
Program Chair,
Program Accountant,
Course Teacher,
Student, Alumnus
Sign Out Program Officer,
Program Chair,
Program Accountant,
Course Teacher,
Student, Alumnus
Maintain Profile Program Officer,

21
Program Chair,
Program Accountant,
Course Teacher,
Student, Alumnus
Admission
Process
Publish Admission
Notice
Program Officer,
Program Chair
Publish Result Program Officer,
Program Chair
Create Student
Profile
Program Officer
Manage
Program
Office Work
Publish Notice Program Officer,
Program Chair
Provide Course
Outline
Program Officer,
Course Teacher
Create Course
Teacher Profile
Program Officer
Change Profile
Information
Program Officer,
Program Chair
Keep Financial
Record
Program Accountant
Provide Form Program Officer
Administrative
Work
Create & Assign
Program Office Staff
Program Chair
Assign Program
Coordinator
Program Chair
System Manipulation Program Chair
Maintain
Course
Program
Verify Document Program Coordinator,
Program Chair
Control Emergency
Issue
Program Chair
Assign Course
Teacher
Program Coordinator
Provide
Resource &
Marks
Provide Course
Resource
Course Teacher
Submit Course Marks Course Teacher,
Program Officer

4.3 Use Case Description
We shall elaborate use case scenario to use case diagram, description,
activity diagram & swim-
level-0 for SIS:
Figure
4.3 Use Case Description
-lane diagram. Here is the use case diagram of
4.3: Use Case Diagram of SIS
(Level-0)
22
the use case diagram of

4.3.1 Student Information System
This is the elaborated form of level
Figure
the elaborated form of level-0 for SIS:
4.3.1: Use Case Diagram of SIS
(Level-1)
23

4.3.1.1 Authentication
We can further section Authentication system into three sub
Figure 4.3.1.1: Use Case Diagram
Authentication
can further section Authentication system into three sub-systems:
: Use Case Diagram of Authentication
(Level-1.1)
24
systems:
of Authentication

25
4.3.1.1.1 Use Case: Sign In
Primary Actor:
1. Program Officer
2. Program Coordinator
3. Program Chair
4. Program Accountant
5. Course Teacher
6. Student
7. Alumnus
Goal in Context: To enter the system.
Precondition: Must have an account on this system.
Scenario:
1. Visit the login page.
2. Click on ‘Sign In’ button.
3. Input username & password.
4. Proceed to the next activity.
Exceptions:
1. Unrecognized username.
2. Wrong password.
3. User is blocked.
Priority: Essential, must be implemented.
When Available: First increment.
Frequency of Use: Many times per day.

FigureFigure a1: Activity Diagram- Sign In
26

FigureFigure a2: Swim-Lane Diagram- Sign In
27

28
4.3.1.1.2 Use Case: Sign Out
Primary Actor:
1. Program Officer
3. Program Chair
5. Course Teacher
6. Student
7. Alumnus
Goal in Context: To exit from the system.
Scenario:
1. Click the ‘Sign Out’ button.
2. Get out of the system.
Exception:
1. System error.
2. Network error.
Precondition: Must be logged in.
When Available: Last increment.

FigureFigure b1: Activity Diagram- Sign Out
29

FigureFigure b2: Swim-Lane Diagram- Sign Out
30

31
4.3.1.1.3 Use Case: Maintain Profile
Primary Actor:
1. Program Officer
3. Program Chair
5. Course Teacher
6. Student
7. Alumnus
Goal in Context: To update one's information.
Precondition: Must be logged in.
Scenario:
1. Sigh in to the system.
2. Click ‘Edit Profile’ button.
3. Change information.
4. Save changes.
Exceptions:
1. Function not configured for the system.
2. Unable to update.
3. Null information.
When Available: Second increment.
Frequency of Use: Moderate frequency.

Figure c1: Activity Diagram: Activity Diagram- Maintain Profile
32

Figure c2: Swim: Swim-Lane Diagram- Maintain Profile
33

4.3.1.2 Admission Process
We can divide Admission Process
1.2 Admission Process
Admission Process into three following sub-systems:
: Use Case Diagram of Admission Process
(Level-1.2)
34
systems:
Admission Process

35
4.3.1.2.1 Use Case: Publish Admission Notice
Primary Actor: Program Officer
Secondary Actors:
2. Program Chair
Goal in Context: Provide information on admission process.
Scenario:
1. Sign in to the system.
2. Click on ‘Admission Process’.
3. Select ‘Publish Admission Notice’.
4. Attach notice file.
5. Upload the file.
Exceptions:
1. System is not responding.
2. File format mismatch.
3. Unable to upload.
Frequency of Use: Once per six months.

Figure d1: Activity Diagram: Activity Diagram- Publish Admission Notice
36
Notice

Figure d2: Swim: Swim-Lane Diagram- Publish Admission Notice
37
Notice

38
4.3.1.2.2 Use Case: Publish Result
Primary Actor: Program Officer
Secondary Actor: Program Chair
Goal in Context: Provide result of admission process.
Scenario:
3. Select ‘Publish Result’.
4. Attach result file.
5. Upload the file.
Exceptions:
1. File size out of bound.
3. Unable to upload.
Frequency of Use: Once per six months.

Figure e1e1: Activity Diagram- Publish Result
39

Figure e2: Swim: Swim-Lane Diagram- Publish Result
40

41
4.3.1.2.3 Use Case: Create Student Profile
Primary Actor: Program Officer.
Goal in Context: To register students to the system.
Scenario:
3. Select ‘Create Student Profile’.
4. Input information.
5. Click ‘Create’ button.
Exceptions:
1. Profile already exists.
2. Missing required information.
3. Unable to create profile.
Frequency of Use: Several times during a year.

Figure f1: Activity Diagram: Activity Diagram- Create Student Profile
42
Profile

Figure f2: Swim: Swim-Lane Diagram- Create Student Profile
43
Profile

4.3.1.3 Manage Program Office Work
We found six sub-systems in this level:
Manage Program Office Work
systems in this level:
: Use Case Diagram of Manage Program Office Work
(Level-1.3)
44
Manage Program Office Work

45
4.3.1.3.1 Use Case: Publish Notice
Secondary Actors:
1. Program Chair
2. Program Coordinator.
Goal in Context: To provided academic information.
Scenario:
2. Click on ‘Manage Program Office Work’.
3. Select ‘Publish Notice’.
4. Attach required files.
5. Click ‘Upload’ Button.
Exceptions:
1. File formats miss match.
2. Unable to attach files.
3. File size is too large to upload.
Frequency of Use: Many times per week.

Figure g1g1: Activity Diagram- Publish Notice
46

Figure g2: Swim: Swim-Lane Diagram- Publish Notice
47

48
4.3.1.3.2 Use Case: Provide Course Outline
Primary Actor: Program officer.
Secondary Actor: Course teacher.
Goal in Context: Provide students and course teachers with course
details.
Scenario:
1. Sign to the system.
3. Select ‘Provide Course Outline’.
4. Attach file.
5. Click ‘Upload’ button.
Exceptions:
1. File format miss-match.
2. Unable to attach file.
3. File size is too large to upload.
Frequency of Use: Several times per year.

Figure h1: Activity Diagram: Activity Diagram- Provide Course Outline
49
Provide Course Outline

Figure h2: Swim: Swim-Lane Diagram- Provide Course Outline
50
Outline

51
4.3.1.3.3 Use Case: Create Course Teacher Profile
Primary Actors: Program Officer.
Secondary Actor: Program Coordinator.
Goal in Context: To register students to the system.
Scenario:
3. Select ‘Create Course Teacher Profile’.
5. Click ‘Create’ button.
Exceptions:
1. Profile already exists.
2. Missing required information.
3. System error.
4. Unable to create profile.

Figure i1: Activity Diagram: Activity Diagram- Create Course Teacher Profile
52
Profile

Figure i2: Swim: Swim-Lane Diagram- Create C. Teacher Profile
53
Profile

54
4.3.1.3.4 Use Case: Change Profile Information
Primary Actors:
1. Program Officer
2. Program Chair
Goal in Context: To give the opportunity to edit profile information.
Scenario:
3. Select ‘Change Profile Information’.
4. Edit the information.
5. Confirm changes.
Exceptions:
1. System error.
2. Network error.
3. Null information provided.
4. Unable to update the changes.

Figure j1: Activity Diagram: Activity Diagram- Change Profile Information
55
Change Profile Information

Figure j2: Swim--Lane Diagram- Change Profile Information
56
Change Profile Information

57
4.3.1.3.5 Use Case: Keep Financial Record
Primary Actor: Program Accountant.
Goal in Context: To keep the records of financial activities that
students perform.
Scenario:
3. Select ‘Keep Financial Record’.
4. Input the record.
5. Update the record.
Exceptions:
1. Null point exception.
2. System error.
3. Wrong input.
4. Unable to update.
Frequency of Use: Several times per day.

Figure k1: Activity Diagram: Activity Diagram- Keep Financial Record
58
Keep Financial Record

Figure k2: Swim: Swim-Lane Diagram- Keep Financial Record
59
Record

60
4.3.1.3.6 Use Case: Provide Form
Goal in Context: To provide the students with necessary forms.
Scenario:
3. Select ‘Provide Form’.
4. Attach the form.
5. Upload the form.
Exceptions:
1. System error.
2. Cannot attach the form.
4. Unable to upload the form.
Priority: Moderate, may be implemented.
Frequency of Use: Several times per month.

FigureFigure l1: Activity Diagram- Provide Form
61

Figure l2l2: Swim-Lane Diagram- Provide Form
62

4.3.1.4 Administrative Work
We divided administrative work in three sections:
1.4 Administrative Work
divided administrative work in three sections:
: Use Case Diagram of Administrative Work
(Level-1.4)
63
of Administrative Work

64
4.3.1.4.1 Use Case: Create & Assign Program Office Staff
Primary Actor: Program Chair.
Goal in Context: To assign program officer, program accountant to
the system.
Scenario:
2. Click on ‘Administrative Work’ button.
3. Select ‘Assign Program Office Staff’.
5. Update the information.
Exceptions:
1. Null point error.
2. Wrong information provided.
3. Cannot update the information.
Frequency of Use: Few in a year.

Figure m1: Activity Diagram: Activity Diagram- Assign Program Office Staff
65
Assign Program Office Staff

Figure m2: SwimSwim-Lane Diagram- Assign Program Office Staff
66
Assign Program Office Staff

67
4.3.1.4.2 Use Case: Assign Program Coordinator
Goal in Context: To assign the program coordinator of each program
to the system.
Scenario:
2. Click on ‘Administrative Work’ button.
3. Select ‘Assign Program Coordinator’.
5. Update the information.
Exceptions:
1. Null point error.
2. Coordinator is already assigned.
3. Wrong information provided.
4. Cannot update the information.
Frequency of Use: Once in a six month.

Figure n1: Activity Diagram: Activity Diagram- Assign Program Coordinator
68
Assign Program Coordinator

Figure n2: Swim--Lane Diagram- Assign Program Coordinator
69
Assign Program Coordinator

70
4.3.1.4.3 Use Case: System Manipulation
Goal in Context: To make any changes of the resources in the
system.
Scenario:
2. Click on ‘Administrative Work’.
3. Select ‘System Manipulation’.
4. Manipulate (add, edit, delete) the system information.
5. Confirm manipulation.
Exceptions:
1. Unable to sign in.
2. System error.
3. Network error.
4. Not authorized for the manipulation.
When Available: Third increment.
Frequency of Use: No specific frequency.

Figure o1: Activity Diagram: Activity Diagram- System Manipulation
71
System Manipulation

Figure o2: Swim: Swim-Lane Diagram- System Manipulation
72
System Manipulation

4.3.1.5 Maintain Course Program
We have found three sub
1.5 Maintain Course Program
have found three sub-systems in this system:
: Use Case Diagram of Maintain Course Program
(Level-1.5)
73
of Maintain Course Program

74
4.3.1.5.1 Use Case: Verify Document
Primary Actor: Program Coordinator.
Secondary Actor: Program Chair.
Goal in Context: Verify notice before publishing.
Scenario:
2. Click on ‘Maintain course program’.
3. Press ‘Unverified Documents’ button.
4. Press button ‘Verify’.
Exceptions:
1. Unable to sign in.
2. No unverified document found.
3. Network error.
Priority: Moderate priority, should be implemented.
Frequency of Use: Several times per week.

Figure p1p1: Activity Diagram- Verify Document
75

Figure p2: Swim: Swim-Lane Diagram- Verify Document
76

77
4.3.1.5.2 Use Case: Control Emergency Issue
Secondary Actors: Program Chair.
Goal in Context: Check & solve emergency issues.
Scenario:
1. Sign in.
2. Click on ‘Maintain Course Program’.
3. Select ‘Control Emergency Issue’.
4. Solve or remove the issues.
Exceptions:
1. Error in network.
2. Not authorized to change the error.
Priority: High priority; should be implemented.
Frequency of Use: Hardly once in a month.

Figure q1: Activity Diagram: Activity Diagram- Control Emergency Issue
78
Control Emergency Issue

Figure q2: Swim: Swim-Lane Diagram- Control Emergency Issue
79
Control Emergency Issue

80
4.3.1.5.3 Use Case: Assign Course Teacher
Goal in Context: Assigning right teacher to right subject.
Scenario:
2. Click on ‘Maintain Course Program’.
3. Press ‘Assign Course Teacher’ button.
4. Select teacher for a course.
5. Press ‘Assign’ button.
Exceptions:
1. Course teacher already assigned to a course.
2. Network error.
3. System error.
Frequency of Use: Few in six months.

Figure r1: Activity Diagram: Activity Diagram- Assign Course Teacher
81
Assign Course Teacher

Figure r2: Swim: Swim-Lane Diagram- Assign Course Teacher
82
Assign Course Teacher

4.3.1.6 Provide Resource & Marks
We have sectioned it into two following parts:
Provide Resource & Marks
have sectioned it into two following parts:
: Use Case Diagram of Provide Resource & Marks
(Level-1.6)
83
of Provide Resource & Marks

84
4.3.6.1 Use Case: Provide Course Resource
Primary Actor: Course Teacher.
Goal in Context: Provide the students with course related resources
like- *.pdf, *.djv, *.txt, *.ppt, *.doc & links.
Scenario:
1. Sign in.
2. Click on ‘Provide Course Resource & Marks’.
3. Press ‘Upload Resource’ button.
4. Press ‘Attach’ button.
5. Browse and select file.
6. Press ‘Upload’ button.
Exceptions:
1. Network problem.
2. Connection problem.
3. System problem.
4. Data size is out-of-bound.
5. File is a possible threat (like *.exe or *.jar file).
Priority: Moderate, may be implemented.
Frequency of Use: Several times during a course.

Figure s1: Activity Diagram: Activity Diagram- Provide Course Resource
85
Provide Course Resource

Figure s2: Swim: Swim-Lane Diagram- Provide Course Resource
86
Provide Course Resource

87
4.3.6.2 Use Case: Submit Course Marks
Primary Actor: Course Teacher.
Secondary Actor: Program Officer.
Goal in Context: Publish marks of any exam.
Scenario:
2. Click on ‘Provide Course Resource & Marks’.
3. Press ‘Submit Course Marks’ button.
4. Upload marks.
Exceptions:
1. System error.
3. Unable to attach file.
4. Network error.
Frequency of Use: Several times during a course.

Figure t1: Activity Diagram: Activity Diagram- Submit Course Marks
88

Figure t2: Swim: Swim-Lane Diagram- Submit Course Marks
89
Submit Course Marks

90
Chapter 5
Data Model
5.1 Introduction
If software requirements include the need to create, extend, or interface with a
database or if complex data structures must be constructed and manipulated, the
software team may choose to create a data model as part of overall requirements
modeling.
5.2 Data Object Selection
A data object is a representation of information which has different properties or
attributes that must be understood by software. Here is the table of potential
data objects.
Noun Attributes Description Remark
Student
Information
System
Represents the whole
system
Rejected
Institute of
Information
Technology
An institute, out of
scope
Rejected
University of
Dhaka
An institute out of
scope
Student Student Id, Student
name, Student Present
Address, Student
Permanent Address
,Student Phone Number
Potential data object Accepted

91
Assigned Semester ,
Course Id, Assigned Hall,
Student Photo
PGDIT A course program
MIT A course program
System Alias of
SIS
Course Teacher Course Name, Teacher
Name, Course Id,
Teacher Photo,
Qualification(PhD,
From where, Papers
etc), Teacher Email
Information Can be an attribute Rejected
Course Materials An attribute of course Rejected
Financial
activities
Rejected
Academic life Admission test, Written
test, Viva test
A student’s whole
academic life
Rejected
Admission
process
A process Rejected
Year September, December can be an attribute Rejected
Circular can be an attribute of
Notice
Rejected
September A month Rejected
December A month Rejected
Course Program Course Id, Teacher
Name, Course Name,
Course Materials.
Admission test Out of scope Rejected
Written test Out of scope Rejected
Viva test Out of scope Rejected
Waiting list Can be an attribute of
Notice
Rejected

92
Regular
Program Office
Staff Name, Staff ID,
Staff Email.
Notices mark sheets, length of
semester, academic
calendar, class routine,
amount, submission
deadline, cultural
activity fees, cultural
activity forms, exam
routine, mark
distribution policies,
grades,
mark sheets, semester
fee, Waiting list
Registration
Process
Out of scope Rejected
Selection
procedure
Semester fee Can be an attribute of
Notice
Rejected
Bank Out of scope Rejected
Necessary
documents
Academic
documents
Assigned hall Rejected
Regular
students
Alias to student Rejected
Student profile Alias to student Rejected
Semester Alias to course Rejected
Length of
semester
Can be an attribute of
Notice
Rejected
Month Not necessary Rejected
Academic
calendar
Notice
Rejected

93
Class routine Can be an attribute of
Notice
Rejected
Amount Can be an attribute of
Notice
Rejected
Submission
deadline
Notice
Rejected
Cultural activity
fees
Notice
Rejected
Cultural activity
Forms
An attribute of Notice Rejected
Program officer External entity Rejected
Exam routine An attribute of Notice Rejected
Academic
papers
Character
certificate
Not necessary Rejected
Profile
information
An attribute of other
potential objects
Rejected
Phone number An attribute of other
potential objects
Rejected
Present address An attribute of other
potential objects
Rejected
Program
Accountant
External entity Rejected
Financial
activity
Can be an attribute Rejected
Submission Out of scope Rejected
Program Chair External entity Rejected
Administrator Out of scope Rejected
Program
coordinator
Documents An attribute of Course Rejected
Emergency
issues
Faculty
member
Knowledge Out of scope Rejected

94
Reference
books
An attribute of Course Rejected
Web links An attribute of Course Rejected
Course
objective
An attribute of Course Rejected
Mark
distribution
policies
An attribute of Notice Rejected
Resources An attribute of Course Rejected
Marks An attribute of Notice Rejected
Grades An attribute of Notice Rejected
Mark sheets An attribute of Notice Rejected
Dead line Defined in notice Rejected
Mark
distribution
Can be an attribute Rejected
Alumnus Alumnus Name,
Alumnus Email ,Alumnus
Achievements ,Alumnus
Present Address,
Alumnus Permanent
Address , Alumnus
Phone Number
Academic
profile
Alias of other
potential data objects
Rejected
Contribution Can be an attribute Rejected
Job position Can be an attribute Rejected
Address An attribute of other
objects
Rejected
Email address Can be an attribute Rejected
Individual
alumni
An individual person Rejected

95
5.3 Data Objects and Attributes
This is a brief view of all attributes we have found so far:
Student- studentName + studentId + studentPresentAddress +
studentPermanentAddress + studentPhoneNumber +
assignedSemester + courseID + assignedHall + studentPhoto +
studentEmail + studentPersonalAchievement
Teacher- courseName + teacherName + courseID + teacherPhoto +
qualification + teacherEmail
Alumnus- alumnusName + alumnusEmail + alumnusAchievements
+ alumnusPresentAddress + alumnusPermanentAddress +
alumnusPhoneNumber
Program Office(P.Ch., P.A., P.Co.)- staffName + staffID + staffEmail
Notice- publicNotice + academicNotice + programID
System- userName + password
Course- courseID + teacherName + courseName + courseMaterials

5.4 Relationship between Data O
Here we have shown pair wise
etween Data Objects
Here we have shown pair wise relation between two entities.
96

5.5 E-R Diagram
Here relationships among all entities are shown as a diagram.among all entities are shown as a diagram.
97

5.6 Schema Diagram
Here is the table of all entities carrying their attributes and types:Here is the table of all entities carrying their attributes and types:
98

99
5.7 Table Creation Statement:
Here is DDL, the statement for creating all the entities:
create table student (
studentID varchar(13) not null,
studentName varchar(25),
studentPresentAddress varchar(35),
studentPermanentAddress varchar(35),
studentPhoneNumber integer,
assignedSemester integer not null,
assignedHall varchar(7),
studentEmail varchar(25),
studentPersonalAchievements bolb,
studentPhoto BYTE IN photo_space,
primary key (studentID),
constraints_fk_programID foreign key (programID) references
notice(programID),
constraints_fk_courseID foreign key (courseID) references
course(courseID),
constraints_fk_username+passwordforeign key (username+password)
references system (username+password)
)
create table teacher (
teacherName char(25),
teacherEmail char(25),
teacherPhoto BYTE IN photo_space,
qualification bolb,
constraint_fk_programID foreign key (programID) references
notice(programID),
constraint_fk_courseID foreign key (courseID) references
course(courseID),
constraint_fk_username+password foreign key (username+password)
)
create table alumnus (
alumnusID varchar(13) not null,
alumnusName varchar(25),

100
alumnusEmail varchar(35),
alumnusPresentAddress varchar(35),
alumniPhoneNumber integer,
alumniPermanentAddress char(35),
alumniPhotoBYTE IN photo_space,
aluniAchievements bolb,
primary key (alumiID),
)
create table programOffice(
staffID char(7) not null,
staffName char(25),
staffEmail char(35),
staffPhoto BYTE IN photo_space,
primary key (staffID),
)
create table notice(
programID char(7) not null,
publicNotice bolb,
academicNotice bolb,
primary key (programID),
constraint_fk_staffID foreign key (staffID) references
programOffice(staffID)
)
create table course(
courseID varchar(7) not null,
courseName varchar(20),
courseMaterials bolb,
primary key (courseID)
)

101
Chapter 6
Class-Based Model
6.1 Introduction
Class-based modeling represents the objects that the system will manipulate, the
operations that will be applied to the objects, relationships between the objects
and the collaborations that occur between the classes that are defined.
6.2 General Classification
Analysis classes manifest themselves in one of the following ways:
1. External Entity
2. Thing
3. Occurrence
4. Role
5. Organizational Unit
6. Place
7. Structure
No. Noun
General
Classification
Remarks
1 Student Information
System
2 Problem Space (represents
whole system)
2 Institute of
Information
Technology
NULL Problem Space
3 University of Dhaka NULL Problem Space
4 Student 1, 4 Solution Space
5 PGDIT Problem Space

102
6 MIT Problem Space
7 System 2 Solution Space
8 Course Teachers 4 Solution Space (same
as 58)
9 Information 2 Problem Space
10 Course Materials 2 Solution Space (same
as 65)
11 Financial Activities 3 Problem Space
12 Academic Life Problem Space
13 Admission Process 3 Solution Space
14 Year Problem Space
15 Circulars 2, 3 Solution Space
16 September Problem Space
17 December Problem Space
18 Course Programs Problem Space
19 Admission Test 3 Problem Space
20 Written Test 3 Problem Space
21 Viva Test 3 Problem Space
22 Waiting Lists 2 Solution Space (same
as 24)
23 Regular Program
Office
4, 5 Solution Space
24 Notice 2, 3 Solution Space
25 Registration
Process
3 Solution Space
26 Selection Procedure 3 Problem Space
27 Semester Fee 2 Problem Space
28 Bank 6 Solution Space
29 Necessary Documents 2 Problem Space
30 Academic Documents 2 Problem Space
31 Assigned Hall 6 Solution Space
32 Regular Students 4 Solution Space (same
as 4)
33 Student Profile 2 Problem Space
34 Semester 2 Problem Space
35 Length of Semester Problem Space

103
36 Month Problem Space
37 Academic Calendar 2 Problem Space
38 Class Routine 2 Solution Space (same
as 24)
39 Amount 2 Problem Space
40 Submission Deadline 2 Problem Space
41 Cultural Activity Fees 2 Problem Space
42 Cultural Activity
Forms
2 Problem Space
43 Program Officer 4 Solution Space (same
as 23)
44 Exam Routine 2 Solution Space (same
as 24)
45 Academic Papers 2 Problem Space
46 Character Certificate 2 Problem Space
47 Profile Information 2 Problem Space
48 Phone Number 2 Problem Space
49 Present Address 2 Problem Space
50 Program Accountant 4 Solution Space (same
as 23)
51 Financial Activity 3 Problem Space
52 Submission Problem Space
53 Program Chair 4 Solution Space
54 Administrator 4 Solution Space (same
as 53)
55 Program
Coordinator
4 Solution Space
56 Documents 2 Problem Space
57 Emergency Issues Problem Space
58 Course Teacher 4 Solution Space
59 Course Teacher 4 Solution Space (same
as 58)
60 Knowledge Problem Space
61 Reference Books 2 Solution Space (same
as 65)
62 Web Links 2 Solution Space (same

104
as 65)
63 Course Objective 2 Solution Space (same
as 65)
64 Mark Distribution
Policies
2 Solution Space (same
as 65)
65 Resource 2 Solution Space
66 Marks 2 Problem Space
67 Grades 2 Problem Space
68 Mark Sheets 2 Solution Space (same
as 24)
69 Dead Line 2 Problem Space
70 Mark Distribution 2 Solution Space (same
as 65)
71 Alumnus 4 Solution Space
72 Academic Profile 2 Problem Space
73 Contribution Problem Space
74 Job Position Problem Space
75 Address 2 Problem Space
76 Email Address 2 Problem Space
77 Individual Alumni 4 Solution Space (same
as 71)
6.3 Selection Characteristics
Coad and Yourdon suggest six selection characteristics that should be used to
consider each potential class for inclusion in the analysis model:
1. Retained Information
2. Needed Services
3. Multiple Attributes
4. Common Attributes
5. Common operations
6. Essential Requirements

105
No. Potential Class Characteristics Remarks
1 Student 1, 2, 3, 4, 5, 6 Yes
2 System 1, 2 No
3 Admission Process 1, 2, 6 No
4 Regular Program Office 1, 2, 3, 4, 5, 6 Yes
5 Notice 1, 2, 3, 6 Yes
6 Registration Process 1, 2, 6 No
7 Bank 1, 2, 3 No
8 Assigned Hall 1, 2, 3 No
9 Program Chair 1, 2, 3, 4, 5, 6 Yes
10 Program Coordinator 1, 2, 3, 4, 5, 6 Yes
11 Course Teacher 1, 2, 3, 4, 5, 6 Yes
12 Resource 1, 2, 3, 4, 5, 6 Yes
13 Alumnus 1, 2, 3, 4, 5, 6 Yes
6.4 Attribute Selection
Here we find attributes for selected classes.
No. Class Attributes Remarks
1 Program Chair pc_name, pc_id,
pc_photo, pc_email,
pc_phoneNumber,
pc_rank
pc_name for Program
Chair’s name, pc_id for
Program Chair’s ID,
pc_photo for Program
Chair’s photo, pc_email for
Program Chair’s Email
Address, pc_phoneNumber
for Program Chair’s phone
number, pc_rank for
Program Chair’s Rank
2 Program
Coordinator
pco_name, pco_id,
pco_photo,
pco_email,
pco_phoneNumber,
pco_name for Program
Coordinator’s name, pco_id
for Program Coordinator’s
ID, pco_photo for Program

106
pco_rank Coordinator’s photo,
pco_email for Program
Coordinator’s Email
Address,
pco_phoneNumber for
Program Coordinator’s
phone number, pco_rank
for Program Coordinator’s
Rank
3 Regular
Program Office
rpo_name, rpo_id,
rpo_photo, rpo_email,
rpo_phoneNumber,
rpo_rank
rpo_name for Regular
Program Office Staff’s
name, rpo_id for Regular
Program Office Staff’s ID,
rpo_photo for Regular
photo, rpo_email for
Regular Program Office
Staff’s Email Address,
rpo_phoneNumber for
Regular Program Office
Staff’s phone number,
rpo_rank for Regular
Rank
4 Course Teacher fm_name, fm_id,
fm_photo, fm_email,
fm_phoneNumber,
fm_rank
fm_name for Faculty
Member’s name, fm_id for
Faculty Member’s ID,
fm_photo for Faculty
Member’s photo, fm_email
for Faculty Member’s Email
Address, fm_phoneNumber
for Faculty Member’s
phone number, fm_rank
for Faculty Member’s Rank
5 Student s_name, s_id,
s_photo, s_email,
s_phoneNumber,
s_regNo
s_name for Student’s
name, s_id for Student’s
ID, s_photo for Student’s
photo, s_email for

107
Student’s Email Address,
s_phoneNumber for
Student’s phone number,
s_regNo for Student’s
Registration Number
6 Alumnus a_name, a_id,
a_photo, a_email,
a_phoneNumber,
a_jobPosition
a_name for Alumnus’
name, a_id for Alumnus’
ID, a_photo for Alumnus’
photo, a_email for
Alumnus' Email Address,
a_phoneNumber for
Alumnus’ phone number,
a_jobPosition for Alumnus’
Job Position in a
corporation/company
7 Notice n_id, n_data, n_date n_id for Notice ID, n_data
for Notice File, n_date for
Publication Date
8 Resource r_id, r_data, n_date,
n_subjectId
r_id for Resource ID,
r_data for Resource File,
n_date for Resource
Publication Date,
n_subjectId for Subject Id
that the Resource belongs
to
6.5 Defining Methods
In this part we find all the verbs from usage scenario and include necessary
external verbs in a list; and select useful verbs as methods.
6.5.1 Verb List
Here we list all verbs from usage scenario.

108
No. Verb Remarks
1 provide information Out of Scope
2 publish circular Yes
3 select student Out of Scope
4 enroll student No Need
5 pay fee Out of Scope
6 register No Need
7 publish notice Yes
8 manage program office works Out of Scope
9 create student profile Yes
10 create faculty member profile Yes
11 change profile information Yes
12 keep financial records Yes
13 assign program coordinator Yes
14 assign program officer Yes
15 assign program accountant Yes
16 remove notice Yes
17 maintain course program Out of Scope
18 verify document Yes
19 control emergency issue Yes
20 register student Yes
21 register faculty member Yes
22 publish notice Yes
23 provide resource Yes
24 submit course mark sheet Yes
25 complete course program Out of Scope
26 make change in personal information Yes
27 get information Yes (external)
28 attach file Yes (external)
29 upload Yes (external)
30 sign in Yes (external)

109
6.5.2 Selected Methods
From the verb list above we have selected following methods for classes.
Class Methods
Program Chair sign_in(), get_information(),
assign_program_coordinator(),
assign_program_officer(),
assign_program_accountant(),
remove_notice()
Program Coordinator sign_in(), get_information(),
maintain_course_program(),
verify_document()
register_student(),
register_faculty_member(),
publish_notice()
Regular Program Office sign_in(), get_information(),
publish_circular(), publish_notice(),
create_student profile (),
create_faculty_member_profile(),
change_profile_information()
Course Teacher sign_in(), get_information(),
provide_resource(),
submit_course_mark_sheet()
Student sign_in(), get_information()
Alumnus sign_in(), get_information(),
make_change_in_personal_information()
Notice attach_file(), upload()
Resource attach_file(), upload()

6.6 Class Diagram
We have shown here, how the classes
goal.
We have shown here, how the classes interact together to accomplish certain
110
interact together to accomplish certain

6.7 Class Card
Class card represents a graphical view of responsibility and collaborator for each
class.
111

7.1 Introduction
Although data flow-oriented modeling is perceived as an outdated technique by
some software engineers, it continues to be one of the most widely used
requirements analysis notations in use today.
7.2 Data Flow Diagram (DFD)
The Data Flow Diagram (DFD) takes an input
Data objects flow into the software, are transformed by processing elements and
resultant data objects flow out of the software. Data objects are represented by
labeled arrows and transformations are represented by circles.
Chapter 7
Flow-Oriente
oriented modeling is perceived as an outdated technique by
requirements analysis notations in use today.
7.2 Data Flow Diagram (DFD)
iagram (DFD) takes an input-process-output view of a system.
sformations are represented by circles.
Figure 7.2: DFD Level-0
113
Chapter 7
Oriented Model
oriented modeling is perceived as an outdated technique by
output view of a system.

115
Figure 7.2.1.1: DFD Level-1.1

116

117

118
Chapter 8
Behavioral Model
8.1 Introduction
Behavior modeling is also referred to as State modeling, State machines and State
transition matrix. Behavior modeling is when one thinks of his ideas in terms of
states and transitions. This requires both identifying all of the interesting states of
being that software or its components are likely to be in. And also, at a high level,
abstracting what events are likely to cause software or its components to change
between states of being.
8.2 Identifying Events
Here we have identified events from the Usage Scenario and listed their
corresponding initiators & collaborators.
Event Initiator Collaborator
Create Student Profile Program Officer Student
Publish Notice Program Officer Student
Create Course Teacher
Profile
Program Officer Course Teacher
Change Student Profile
Information
Program Officer Student
Record Financial
Activity
Program Accountant Student

119
Notify Program Accountant Student
Assign Program
Coordinator
Program Officer Program Coordinator,
Program Officer, Program
Accountant
Create and Assign
Program Officer &
Program Accountant
Program Chair
Remove Notice Program Chair
Verify Document Program Coordinator
Control Emergency
Issue
Program Coordinator
Assign Course Teacher Program Coordinator Course Teacher
Publish Notice Program Coordinator
Provide Resource Course Teacher Student
Submit Course Marks Course Teacher Student/ Program Officer
Change Personal
Information
Alumnus

120
8.3 State Transition Diagram
State Transition Diagram represents active states for each class and the events
(triggers) that cause changes between these active states. Here we have provided
diagram for each of the actors.
Figure 8.3.1: Program Office

121
Figure 8.3.2: Program Accountant

122
Figure 8.3.3: Program Chair

123
Figure 8.3.4: Program Coordinator

124
Figure 8.3.5: Course Teacher

8.4 Sequence Diagram
Sequence Diagram indicates how events cause transitions from object to
is actually a representation of how events
as a function of time.
Figure
Sequence Diagram indicates how events cause transitions from object to
a representation of how events cause flow from one object to another
Figure 8.4.1: Create Student Profile
126
Sequence Diagram indicates how events cause transitions from object to object. It
object to another

Figure 8.4.2: Publish Notice
127

FigureFigure 8.4.3: Create Course Teacher Profile
128

Figure 8.4.4: Change Student Profile Information
129
Change Student Profile Information

Figure 8.4.5: Record Financial Activity
130

FigureFigure 8.4.7: Assign Program Coordinator
132

FigureFigure 8.4.8: Create & Assign PO & PA
133

Figure 8.4.9: Remove Notice
134

FigureFigure 8.4.10: Verify Document
135

FigureFigure 8.4.11: Control Emergency Issue
136

FigureFigure 8.4.12: Assign Course Teacher
137

Figure 8.4.13: Publish Notice
138

FigureFigure 8.4.14: Provide Resource
139

FigureFigure 8.4.15: Submit Course Marks
140

FigureFigure 8.4.16: Change Personal Information
141

142
Chapter 9
Conclusion
We are pleased to submit the final SRS report on Student
Information System. From this, the readers will get a clear and easy
view of IIT Program Office Function. To improve Office System
efficiency, Program Office Management needs to automate the
acquisition and circulation tasks. An Office with automated software
system is more effective than paper based manual system. This SRS
document can be used effectively to maintain software development
cycle. It will be very easy to conduct the whole project using this
SRS. Hopefully, this document can also help our junior BSSE batch
students. We tried our best to remove all dependencies and make
effective and fully designed SRS. We believe that reader will find it in
order.

143
Appendix
References
1. Pressman, Roger S. Software Engineering: A
Practitioner's Approach (7th ed.). Boston, Mass:
McGraw-Hill. ISBN 0-07-285318-2.
2. Ralph, Paul (2012). "The Illusion of Requirements in
Software Development".
3. Somerville, I. Software Engineering, 7th ed. Harlow,
UK: Addison Wesley, 2006.
4. httt://www.aiub.edu, accessed on 12th September, 2014.
5. http://en.wikipedia.org/wiki/Student_information_syste
m, accessed on 28th September, 2014.
6. http://techlearning.com/student-information-systems,
accessed on 28th
September, 2014.
7. http://www.scribd.com/doc/48111565/Software-
Requirements-Specification-for-online-student-
management-system, accessed on 22th October, 2014.
8. http://www.codeproject.com/Articles/6675/Behavior-
Modeling-Lesson, accessed on 6th November, 2014.

Software Requirements Specification on Student Information System (SRS on SIS)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software Requirements Specification on Student Information System (SRS on SIS)

Similar to Software Requirements Specification on Student Information System (SRS on SIS) (20)

More from Minhas Kamal

More from Minhas Kamal (20)

Recently uploaded

Recently uploaded (20)

Software Requirements Specification on Student Information System (SRS on SIS)