Student Information System

Software Requirements Specification and Analysis

SE-406

November 29, 2014

Student Information System
Software Requirements Specification and Analysis
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
 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

i
 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.

ii
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

iii
Table
6
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.1 Introduction 113
7.2 Data Flow Diagram (DFD) 115

Chapter 8: Behavioral Model .................................................................. 118

8.1 Introduction 118
8.2 Identifying Events 118
8.3 State Transition Diagram 120
8.4 Sequence Diagram 126

Chapter 9: Conclusion .............................................................................. 142

Appendix ........................................................................................................ 143

iv
 Student Information System
Software Requirements
Requirement Specification & Analysis
 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.

1
 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.

2
 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?

3
  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.

4
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.

5
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:
a. Web-Based Interfaces.

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.

6
 6. Faculty Members:
a. Web-Based Interfaces.
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. Alumni:
a. Web-Based Interfaces.
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.

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

7
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.

8
  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

9
 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

Place: Institute of Information Technology, University of Dhaka

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

3. Date: September 08, 2014

Subject: Collecting requirements from the stakeholders

Place: Institute of Information Technology University of Dhaka

Members:

○ BSSE 0502- Jobayer Ahmmed

○ BSSE 0522- Md Abdul Mannan

10
4. Date: September 17, 2014

Subject: Collecting requirements from the stakeholders

Place: Institute of Information Technology, University of Dhaka

Members:

○ BSSE 0502- Jobayer Ahmmed

○ BSSE 0509- Minhas Kamal
○ BSSE 0516- Md Rakib Hossain
○ BSSE 0522- Md Abdul Mannan
○ BSSE 0535- Khandaker Mamun Ahmed

5. Date: September 22, 2014

Subject: Collecting requirements from the stakeholders

Place: Institute of Information Technology, University of Dhaka

Members:

○ BSSE 0502- Jobayer Ahmmed

○ BSSE 0509- Minhas Kamal
○ BSSE 0516- Md Rakib Hossain
○ BSSE 0522- Md Abdul Mannan
○ BSSE 0535- Khandaker Mamun Ahmed

11
 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.

12
  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.

13
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.

14
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,

15
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.

16
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

1. Date: September 24, 2014

Subject: Meeting with the Program Chair

Place: Institute of Information Technology, University of Dhaka

Members:

○ BSSE 0502- Jobayer Ahmmed

○ BSSE 0516- Md Rakib Hossain
○ BSSE 0522- Md Abdul Mannan
○ BSSE 0528- Naima Afroz
○ BSSE 0535- Khandaker Mamun Ahmed

2. Date: September 25, 2014

Subject: Meeting with Program Officer, Program Accountant

17
 Place: Institute of Information Technology, University of Dhaka

Members:

○ BSSE 0502- Jobayer Ahmmed

○ BSSE 0509- Minhas Kamal
○ BSSE 0516- Md Rakib Hossain
○ BSSE 0522- Md Abdul Mannan
○ BSSE 0528- Naima Afroz

3. Date: September 28, 2014

Subject: Meeting with the Program Chair, Registered Student

Place: Institute of Information Technology, University of Dhaka

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

4. Date: October 21, 2014

Subject: Meeting with the Program Coordinator

Place: Institute of Information Technology, University of Dhaka

Members:

○ BSSE 0502- Jobayer Ahmmed

○ BSSE 0509- Minhas Kamal
○ BSSE 0516- Md Rakib Hossain

18
 ○ BSSE 0522- Md Abdul Mannan
○ BSSE 0535- Khandaker Mamun Ahmed

5. Date: October 22, 2014

Subject: Discussion on the QFD

Place: Institute of Information Technology, University of Dhaka

Members:

○ BSSE 0502- Jobayer Ahmmed

○ BSSE 0509- Minhas Kamal
○ BSSE 0516- Md Rakib Hossain
○ BSSE 0522- Md Abdul Mannan
○ BSSE 0535- Khandaker Mamun Ahmed

6. Date: October 27, 2014

Subject: Preparing the user scenarios

Place: Institute of Information Technology, University of Dhaka

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

19
 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 Authentication Sign In Program Officer,
Information Program Coordinator,
System Program Chair,
Program Accountant,
Course Teacher,
Student, Alumnus
Sign Out Program Officer,
Program Coordinator,
Program Chair,
Program Accountant,
Course Teacher,
Student, Alumnus
Maintain Profile Program Officer,

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

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

Figure 4.3: Use Case Diagram of SIS

(Level-0)

22
4.3.1 Student Information System
This is the elaborated form of level-0
level for SIS:

Figure 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-systems:
sub systems:

Figure 4.3.1.1:: Use Case Diagram of Authentication

(Level-1.1)

24
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.

25
Figure a1: Activity Diagram- Sign In

26
Figure a2: Swim-Lane Diagram- Sign In

27
4.3.1.1.2 Use Case: Sign Out

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 exit from the system.

Scenario:

1. Click the ‘Sign Out’ button.

2. Get out of the system.

Exception:

1. System error.
2. Network error.

Priority: Essential, must be implemented.

Precondition: Must be logged in.

When Available: Last increment.

Frequency of Use: Many times per day.

28
Figure b1: Activity Diagram- Sign Out

29
Figure b2: Swim-Lane Diagram- Sign Out

30
4.3.1.1.3 Use Case: Maintain Profile

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 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.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Moderate frequency.

31
Figure c1:: Activity Diagram-
Diagram Maintain Profile

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

33
4.3.1.2
1.2 Admission Process
We can divide Admission Process into three following sub-systems:
systems:

Figure 4.3.1.2:: Use Case Diagram of Admission Process

(Level-1.2)

34
4.3.1.2.1 Use Case: Publish Admission Notice

Primary Actor: Program Officer

Secondary Actors:

1. Program Coordinator
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.

Priority: Essential, must be implemented.

When Available: First increment.

Frequency of Use: Once per six months.

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

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

37
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:

1. Sign in to the system.

2. Click on ‘Admission Process’.
3. Select ‘Publish Result’.
4. Attach result file.
5. Upload the file.

Exceptions:

1. File size out of bound.

2. File format mismatch.
3. Unable to upload.

Priority: Essential, must be implemented.

When Available: First increment.

Frequency of Use: Once per six months.

38
Figure e1
e1: Activity Diagram- Publish Result

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

40
4.3.1.2.3 Use Case: Create Student Profile

Primary Actor: Program Officer.

Goal in Context: To register students to the system.

Scenario:

1. Sign in to the system.

2. Click on ‘Admission Process’.
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.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Several times during a year.

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

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

43
4.3.1.3 Manage Program Office Work
We found six sub-systems
systems in this level:

Figure 4.3.1.3:: Use Case Diagram of Manage Program Office Work

(Level-1.3)

44
4.3.1.3.1 Use Case: Publish Notice

Primary Actor: Program Officer.

Secondary Actors:

1. Program Chair
2. Program Coordinator.

Goal in Context: To provided academic information.

Scenario:

1. Sign in to the system.

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.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Many times per week.

45
Figure g1
g1: Activity Diagram- Publish Notice

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

47
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.

2. Click on ‘Manage Program Office Work’.
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.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Several times per year.

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

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

50
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:

1. Sign in to the system.

2. Click on ‘Manage Program Office Work’.
3. Select ‘Create Course Teacher Profile’.
4. Input information.
5. Click ‘Create’ button.

Exceptions:

1. Profile already exists.

2. Missing required information.
3. System error.
4. Unable to create profile.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Many times per day.

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

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

53
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:

1. Sign in to the system.

2. Click on ‘Manage Program Office Work’.
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.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Many times per day.

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

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

56
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:

1. Sign in to the system.

2. Click on ‘Manage Program Office Work’.
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.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Several times per day.

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

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

59
4.3.1.3.6 Use Case: Provide Form

Primary Actor: Program Officer.

Goal in Context: To provide the students with necessary forms.

Scenario:

1. Sign in to the system.

2. Click on ‘Manage Program Office Work’.
3. Select ‘Provide Form’.
4. Attach the form.
5. Upload the form.

Exceptions:

1. System error.
2. Cannot attach the form.
3. File format mismatch.
4. Unable to upload the form.

Priority: Moderate, may be implemented.

When Available: Second increment.

Frequency of Use: Several times per month.

60
Figure l1: Activity Diagram- Provide Form

61
Figure l2
l2: Swim-Lane Diagram- Provide Form

62
4.3.1.4
1.4 Administrative Work
We divided administrative work in three sections:

Figure 4.3.1.4:: Use Case Diagram of Administrative Work

(Level-1.4)

63
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:

1. Sign in to the system.

2. Click on ‘Administrative Work’ button.
3. Select ‘Assign Program Office Staff’.
4. Input information.
5. Update the information.

Exceptions:

1. Null point error.

2. Wrong information provided.
3. Cannot update the information.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Few in a year.

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

65
Figure m2: Swim
Swim-Lane Diagram- Assign Program Office Staff

66
4.3.1.4.2 Use Case: Assign Program Coordinator

Primary Actor: Program Chair.

Goal in Context: To assign the program coordinator of each program

to the system.

Scenario:

1. Sign in to the system.

2. Click on ‘Administrative Work’ button.
3. Select ‘Assign Program Coordinator’.
4. Input information.
5. Update the information.

Exceptions:

1. Null point error.

2. Coordinator is already assigned.
3. Wrong information provided.
4. Cannot update the information.

Priority: Essential, must be implemented.

When Available: Second increment.

Frequency of Use: Once in a six month.

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

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

69
4.3.1.4.3 Use Case: System Manipulation

Primary Actor: Program Chair.

Goal in Context: To make any changes of the resources in the

system.

Scenario:

1. Sign in to the system.

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.

Priority: Essential, must be implemented.

When Available: Third increment.

Frequency of Use: No specific frequency.

70
Figure o1:: Activity Diagram-
Diagram System Manipulation

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

72
4.3.1.5
1.5 Maintain Course Program
We have found three sub-systems
sub in this system:

Figure 4.3.1.5:: Use Case Diagram of Maintain Course Program

(Level-1.5)

73
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:

1. Sign in to the system.

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.

When Available: Third increment.

Frequency of Use: Several times per week.

74
Figure p1
p1: Activity Diagram- Verify Document

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

76
4.3.1.5.2 Use Case: Control Emergency Issue

Primary Actor: Program Coordinator.

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.

When Available: Third increment.

Frequency of Use: Hardly once in a month.

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

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

79
4.3.1.5.3 Use Case: Assign Course Teacher

Primary Actor: Program Coordinator.

Goal in Context: Assigning right teacher to right subject.

Scenario:

1. Sign in to the system.

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.

Priority: Essential, must be implemented.

When Available: Third increment.

Frequency of Use: Few in six months.

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

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

82
4.3.1.6 Provide Resource & Marks
We have sectioned it into two following parts:

Figure 4.3.1.6:: Use Case Diagram of Provide Resource & Marks

(Level-1.6)

83
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.

When Available: Third increment.

Frequency of Use: Several times during a course.

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

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

86
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:

1. Sign in to the system.

2. Click on ‘Provide Course Resource & Marks’.
3. Press ‘Submit Course Marks’ button.
4. Upload marks.

Exceptions:

1. System error.
2. File format mismatch.
3. Unable to attach file.
4. Network error.

Priority: Essential, must be implemented.

When Available: Third increment.

Frequency of Use: Several times during a course.

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

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

89
 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 Represents the whole Rejected
Information system
System
Institute of An institute, out of Rejected
Information scope
Technology
University of An institute out of
Dhaka scope
Student Student Id, Student Potential data object Accepted
name, Student Present
Address, Student
Permanent Address
,Student Phone Number

90
 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 Potential data object Accepted
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 Rejected
activities
Academic life Admission test, Written A student’s whole Rejected
test, Viva test academic life
Admission A process Rejected
process
Year September, December can be an attribute Rejected
Circular can be an attribute of Rejected
Notice
September A month Rejected
December A month Rejected
Course Program Course Id, Teacher Potential data object Accepted
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 Rejected
Notice

91
Regular Staff Name, Staff ID, Potential data object Accepted
Program Office Staff Email.

Notices mark sheets, length of Potential data object Accepted

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 Out of scope Rejected

Process
Selection Out of scope Rejected
procedure
Semester fee Can be an attribute of Rejected
Notice
Bank Out of scope Rejected
Necessary Out of scope Rejected
documents
Academic Out of scope Rejected
documents
Assigned hall Rejected
Regular Alias to student Rejected
students
Student profile Alias to student Rejected
Semester Alias to course Rejected
Length of Can be an attribute of Rejected
semester Notice
Month Not necessary Rejected
Academic Can be an attribute of Rejected
calendar Notice

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

93
Reference An attribute of Course Rejected
books
Web links An attribute of Course Rejected
Course An attribute of Course Rejected
objective
Mark An attribute of Notice Rejected
distribution
policies
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 Can be an attribute Rejected
distribution
Alumnus Alumnus Name, Potential data object Accepted
Alumnus Email ,Alumnus
Achievements ,Alumnus
Present Address,
Alumnus Permanent
Address , Alumnus
Phone Number
Academic Alias of other Rejected
profile potential data objects
Contribution Can be an attribute Rejected
Job position Can be an attribute Rejected
Address An attribute of other Rejected
objects
Email address Can be an attribute Rejected
Individual An individual person Rejected
alumni

94
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

95
5.4 Relationship between
etween Data Objects
O
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.

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

98
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)
references system (username+password)
)

create table alumnus (

alumnusID varchar(13) not null,
alumnusName varchar(25),

99
 alumnusEmail varchar(35),
alumnusPresentAddress varchar(35),
alumniPhoneNumber integer,
alumniPermanentAddress char(35),
alumniPhotoBYTE IN photo_space,
aluniAchievements bolb,
primary key (alumiID),
constraint_fk_username+password foreign key (username+password)
references system (username+password)
)

create table programOffice(

staffID char(7) not null,
staffName char(25),
staffEmail char(35),
staffPhoto BYTE IN photo_space,
primary key (staffID),
constraint_fk_username+password foreign key (username+password)
references system (username+password)
)

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)
)

100
 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

General
No. Noun Remarks
Classification
1 Student Information 2 Problem Space (represents
System whole system)
2 Institute of NULL Problem Space
Information
Technology
3 University of Dhaka NULL Problem Space
4 Student 1, 4 Solution Space
5 PGDIT Problem Space

101
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 4, 5 Solution Space
Office
24 Notice 2, 3 Solution Space
25 Registration 3 Solution Space
Process
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

102
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 2 Problem Space
Forms
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 4 Solution Space
Coordinator
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

103
 as 65)
63 Course Objective 2 Solution Space (same
as 65)
64 Mark Distribution 2 Solution Space (same
Policies 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

104
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_name for Program
pc_photo, pc_email, Chair’s name, pc_id for
pc_phoneNumber, Program Chair’s ID,
pc_rank 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 pco_name, pco_id, pco_name for Program
Coordinator pco_photo, Coordinator’s name, pco_id
pco_email, for Program Coordinator’s
pco_phoneNumber, ID, pco_photo for Program

105
 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 rpo_name, rpo_id, rpo_name for Regular
Program Office rpo_photo, rpo_email, Program Office Staff’s
rpo_phoneNumber, name, rpo_id for Regular
rpo_rank Program Office Staff’s ID,
rpo_photo for Regular
Program Office Staff’s
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
Program Office Staff’s
Rank
4 Course Teacher fm_name, fm_id, fm_name for Faculty
fm_photo, fm_email, Member’s name, fm_id for
fm_phoneNumber, Faculty Member’s ID,
fm_rank 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_name for Student’s
s_photo, s_email, name, s_id for Student’s
s_phoneNumber, ID, s_photo for Student’s
s_regNo photo, s_email for

106
 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_name for Alumnus’
a_photo, a_email, name, a_id for Alumnus’
a_phoneNumber, ID, a_photo for Alumnus’
a_jobPosition 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, r_id for Resource ID,
n_subjectId 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.

107
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)

108
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()

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

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

111
112
 Chapter 7
Flow-Oriente
Oriented Model

7.1 Introduction
Although data flow-oriented
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
iagram (DFD) takes an input-process-output
input output view of a system.
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
sformations are represented by circles.

Figure 7.2: DFD Level-0

113
Figure 7.2.1: DFD Level-1

114
Figure 7.2.1.1: DFD Level-1.1

Figure 7.2.1.2: DFD Level-1.2

115
Figure 7.2.1.3: DFD Level-1.3

Figure 7.2.1.4: DFD Level-1.4

116
Figure 7.2.1.5: DFD Level-1.5

117
 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 Program Officer Course Teacher
Profile
Change Student Profile Program Officer Student
Information
Record Financial Program Accountant Student
Activity

118
Notify Program Accountant Student
Assign Program Program Officer Program Coordinator,
Coordinator Program Officer, Program
Accountant
Create and Assign Program Chair
Program Officer &
Program Accountant
Remove Notice Program Chair
Verify Document Program Coordinator
Control Emergency Program Coordinator
Issue
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 Alumnus
Information

119
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

120
Figure 8.3.2: Program Accountant

121
Figure 8.3.3: Program Chair

122
Figure 8.3.4: Program Coordinator

123
Figure 8.3.5: Course Teacher

124
Figure 8.3.6: Alumnus

125
8.4 Sequence Diagram

Sequence Diagram indicates how events cause transitions from object to object. It
is actually a representation of how events cause flow from one object to another
as a function of time.

Figure 8.4.1: Create Student Profile

126
Figure 8.4.2: Publish Notice

127
Figure 8.4.3: Create Course Teacher Profile

128
Figure 8.4.4: Change Student Profile Information

129
Figure 8.4.5: Record Financial Activity

130
Figure 8.4.6: Notify

131
Figure 8.4.7: Assign Program Coordinator

132
Figure 8.4.8: Create & Assign PO & PA

133
Figure 8.4.9: Remove Notice

134
Figure 8.4.10: Verify Document

135
Figure 8.4.11: Control Emergency Issue

136
Figure 8.4.12: Assign Course Teacher

137
Figure 8.4.13: Publish Notice

138
Figure 8.4.14: Provide Resource

139
Figure 8.4.15: Submit Course Marks

140
Figure 8.4.16: Change Personal Information

141
 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.

142
 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.

143