Software Requirement Specification (SRS) on Result Analysis Tool

RESULT ANALYSIS TOOL (RAT)
SOFTWARE REQUIREMENTS SPECIFICATION AND ANALYSIS
05-April-2015

RESULT ANALYSIS TOOL
SOFTWARE REQUIREMENTS SPECIFICATION AND ANALYSIS
Submitted by
BSSE0509 - Minhas Kamal
BSSE0524 – Saif Uddin Mahmud
BSSE0530 – Mostaque Ahmed
Submitted to
Emon Kumar Dey
Lecturer
Institute of Information Technology
University of Dhaka
Supervised by
Sheikh Muhammad Sarwar
Lecturer
University of Dhaka
Submission Date
05th April, 2015

LETTER OF TRANSMITTAL
05th
April, 2015.
Emon Kumar Dey
Lecturer
University of Dhaka
Sir,
We have prepared the report on Software Requirements Specification
of ‘Result Analysis Tool’ 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,
Minhas Kamal (BSSE-0509)
Saif Uddin Mahmud (BSSE-0524)
Mostaque Ahmed (BSSE-0530)
Enclosure: SRS Report

i
Executive Summary
In an MCQ exam students answer through OMR sheet which is scanned
by a scanner. Result Analysis Tool is a complete package for processing
this OMR scanner educed data, make result sheet plus deliver report.
Instead of OMR machine, user also may use any other device to take
the photo. He does not need much theoretical or technical skill to run
this software.
Acknowledgements
By the grace of Almighty Allah we have completed our report on
Software Requirements Specification of Result Analysis Tool.
We are grateful to our honorable sir Sheikh Muhammad Sarwar for his
supervision throughout the working time. He helped us a lot by sharing
his invaluable knowledge with us.
Our honorable director sir Dr. K. M. Sakib assisted us with great care. It
was almost impossible for us to complete this SRS without him.
We are also thankful to the Program Coordinators of PGDIT. 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 4
2.1.3 Recognizing Multiple Viewpoints 5
2.1.4 Working towards Collaboration 6
2.2 Conclusion 7
Chapter 3: Elicitation ................................................................................ 10
3.1 Introduction 10
3.2 Eliciting Requirements 10
3.3 Collaborative Requirements Gathering 10
3.4 Quality Function Deployment 11
3.4.1 Normal Requirements 11
3.4.2 Expected Requirements 11
3.4.3 Exciting requirements 12
3.5 Usage Scenarios 12
3.6 Elicitation Work Product 13
Chapter 4: Scenario-Based Model ........................................................ 17
4.1 Introduction 17
4.2 Use Case Scenario 17
4.3 Use Case Descriptions 19
4.3.1 Result Analysis Tool 20
4.3.1.1 Process Image 21
4.3.1.2 Construct Database 31
4.3.1.3 Produce Result 38
4.3.1.4 Run Query 45
4.3.1.5 Produce Report 52
4.3.1.6 Deliver Work Product 59

iii
Table of Contents
Chapter 5: Data Model .............................................................................. 66
5.1 Introduction 66
5.2 Data Object Selection 66
5.3 Data Objects & Attributes 70
5.4 Relationship between Data Objects 71
5.5 E-R Diagram 72
5.6 Schema Diagram 73
Chapter 6: Class-Based Model .............................................................. 74
6.1 Introduction 74
6.2. General Classification 74
6.3 Selection Characteristics 77
6.4 Attribute Selection 78
6.5 Defining Methods 79
6.5.1 Verb List 79
6.5.2 Selected Methods 81
6.6 Class Diagram 83
6.7 Class Card 84
Chapter 7: Flow-Oriented Model .......................................................... 86
7.1 Introduction 86
7.2 Data Flow Diagram (DFD) 86
Chapter 8: Behavioral Model .................................................................. 93
8.1 Introduction 93
8.2 Identifying Events 93
8.3 State Transition Diagram 95
8.4 Sequence Diagram 97
Chapter 9: Conclusion .............................................................................. 110
Appendix ........................................................................................................ 111

iv
List of Figures
Figure No. Figure Name Page No.
Figure 4.3 Use Case Diagram of RAT (Level-0) 19
Figure 4.3.1 Use Case Diagram of RAT (Level-1) 20
Figure 4.3.1.1 Use Case Diagram of Process Image (Level-1.1) 21
Figure a1 Activity Diagram- Scan OMR Sheet 23
Figure a2 Swim-Lane Diagram- Scan OMR Sheet 24
Figure b1 Activity Diagram- Define Image Area 26
Figure b2 Swim-Lane Diagram- Define Image Area 27
Figure c1 Activity Diagram- Extract Image Data 29
Figure c2 Swim-Lane Diagram- Extract Image Data 30
Figure 4.3.1.2 Use Case Diagram of Construct Database (Level-1.2) 31
Figure d1 Activity Diagram- Define Table Attribute 33
Figure d2 Swim-Lane Diagram- Define Table Attribute 34
Figure e1 Activity Diagram- Import Student Answer File 36
Figure e2 Swim-Lane Diagram- Import Student Answer File 37
Figure 4.3.1.3 Use Case Diagram of Produce Result (Level-1.3) 38
Figure f1 Activity Diagram- Calculate Marks 40
Figure f2 Swim-Lane Diagram- Calculate Marks 41
Figure g1 Activity Diagram- Produce Final Result 43
Figure g2 Swim-Lane Diagram- Produce Final Result 44
Figure 4.3.1.4 Use Case Diagram of Run Query (Level-1.4) 45
Figure h1 Activity Diagram- Execute Default Query 47
Figure h2 Swim-Lane Diagram- Execute Default Query 48
Figure i1 Activity Diagram- Run Raw Query 50
Figure i1 Swim-Lane Diagram- Run Raw Query 51
Figure 4.3.1.5 Use Case Diagram of Produce Report (Level-1.5) 52
Figure j1 Activity Diagram- Design Report 54
Figure j2 Swim-Lane Diagram - Design Report 55
Figure k1 Activity Diagram- Generate Report 57
Figure k2 Swim-Lane Diagram- Generate Report 58
Figure 4.3.1.6 Use Case Diagram of Deliver Work Product (Level-1.6) 59
Figure l1 Activity Diagram- Email 61
Figure l2 Swim-Lane Diagram- Email 62
Figure m1 Activity Diagram- Print 64
Figure m2 Swim-Lane Diagram- Print 65

v
List of Figures
Figure No. Figure Name Page No.
Figure 5.4 Data Object Relational Diagram 71
Figure 5.5 E-R Diagram 72
Figure 5.6 Schema Diagram 73
Figure 6.6 Class Diagram (RAT) 83
Figure 7.2 DFD Level 0 86
Figure 7.2.1 DFD Level 1 87
Figure 7.2.1.1 DFD Level 1.1 88
Figure 8.3.1 State Transition Diagram- User 95
Figure 8.3.2 State Transition Diagram- User (continued) 96
Figure 8.4.1 Sequence Diagram- Scan Image 97
Figure 8.4.2 Sequence Diagram- Create Image Definition Graph 98
Figure 8.4.3 Sequence Diagram- Generate Comma Separated Data 99
Figure 8.4.4 Sequence Diagram- Create Table Attribute Information 100
Figure 8.4.5 Sequence Diagram- Generate Database Format 101
Figure 8.4.6 Sequence Diagram- Error Correction 102
Figure 8.4.7 Sequence Diagram- Generate Result 103
Figure 8.4.8 Sequence Diagram- Joining Information 104
Figure 8.4.9 Sequence Diagram- Create Report Definition Graph 105
Figure 8.4.10 Sequence Diagram- Generate Report 106
Figure 8.4.11 Sequence Diagram- Email Work Product 107
Figure 8.4.12 Sequence Diagram- Convert Format 108
Figure 8.4.13 Sequence Diagram- Print Report 109

RESULT ANALYSIS TOOL
SOFTWARE REQUIREMENT SPECIFICATION & ANALYSIS

1
Chapter 1
Introduction
1.1 Purpose
This document is the Software Requirements Specification (SRS) for the Result
Analysis Tool (RAT). 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 a
software project starts and what is the scope and nature of the problem in hand.
The goal of the inception phase is to identify concurrent 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. Although, we intend to develop RAT for industrial use, we are
building it for using only in the IIT premises for the sake of this project. For this
reason, we have selected the stakeholders from the scope of IIT only. To identify
the stakeholders, we consulted with Program Chair and asked him following
questions:
 Who will be using the project outcomes?
 Who gets to make the decisions about the project?
 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 project:
1. Director: The Director is the person who has the final authority on the
finished product. His position empowers him to veto a decision made by
the other stakeholders. As head of institute, the Director has direct
authority over our team— the people developing the software and
doing much of the “management” end of this project.
2. PGDIT Program Coordinator: This software will be used only in the
PGDIT program. So the PGDIT program coordinator will directly interact
with the system.
3. Registered Students: Although the students will not interact with the
system directly, but they are the biggest group affected by the system.
The software will analyze their OMR sheet and generate their result.
4. Faculty Members: Faculty members will define the type of questions
and the design pattern of the OMR sheets. They can also specify the
type of output they desire.
5. Developers: We have selected the developers as stakeholder because
they will develop this system and work for further development. In case
of any system interruption, they will find the problem and try to solve it.
6. Existing Service Provider: We talked with some existing service
providers, who do OMR processing, to understand the whole process of
OMR scanning and to get a clear idea on how to automate the whole
system.
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 customize 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

5
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 Director, Program
Coordinator, Registered Students, Faculty members of Institute of Information
Technology University Of Dhaka.
1. Director:
a. Maintain a database of all the examination and the results.
b. Verify all the unrecognized answers manually.
c. Keep no room for error.
d. Low cost.
2. Program Coordinator:
a. User friendly interface.
b. No technical ability required.
c. Fast processing.
d. A product reference manual describing how to install, setup, and
run the application shall be provided.
3. Registered Students:
a. Easy Access.
b. Get complete grade sheet.
c. Maintain student profile.
4. Faculty Members:
a. Easy Access.
b. Restrict access to any functionality of the system based upon proper
authentication system.

6
c. Enable to log in from smart phones or tablets.
d. The application can be accessed from any computer that has Internet
access.
5. Existing Service Provider:
a. Fast processing.
b. Easy to use.
c. Dynamic report producer.
d. Send email.
e. Print report.
f. Maintain database & run query.
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
Common Requirements:
 User friendliness.
 Maintain a database of all items in the student information system.
Conflicting Requirements:

7
 Easy access and Strong Authentication.
 Allow any user to use the system and allow valid user to use the system.
 Allow web based interface and allow no internet access.
Final Requirements:
We finalized following requirements for the system by categorizing and
prioritizing the requirements:
 Error free system (No error will be considerable).
 File will be encrypted and any user with password will be able to access the
file.
 Allow user to generate dynamic reports, print it and email it.
 Maintain database and run query.
2.2 Conclusion
Inception phase helped us to establish basic understanding about Result Analysis
Tool; identify the people who will be benefited if this software is developed,
define the nature of the student information software and establish a preliminary
communication with our stakeholders.
Group Meeting
1. Date: January 31, 2015
Subject: Identifying Stakeholders
Place: Institute of Information Technology, University of Dhaka

8
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
2. Date: February 03, 2015
Members:
3. Date: February 25, 2015
Members:
4. Date: March 19, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology University of Dhaka
Members:

9
5. Date: March 23, 2015
Members:
6. Date: March 24, 2015
Members: March 29, 2015

10
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 the
following steps to do it:

11
 The meetings were conducted with Program Chair. He was questioned
about their requirements and expectations from the Result Analysis Tool.
 He was asked about the problems he is facing with the current manual
system. We also inquired regarding the efficiency of the current process. 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. User can email the data from the software.
2. The files can be viewed, edited or deleted only through the software.
3. The user can sort or search the entire result.
4. A report based on various parameters can be generated.
5. The report can also be printed.
6. A product reference manual describing how to install, setup and run the
application will be provided.
7. The result can be converted to *.XLS or *.PDF format.
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. There will be files either with or without password protection.

12
2. Any user can view files that have no protection. He can delete or edit
them through the software also.
3. User needs to have a password to view, edit or delete a protected file.
4. Maintain a database of all the information.
5. 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 help.
2. The user can run any query on the database.
3. Extra tools will be included.
3.5 Usage Scenario
Result Analysis Tool (RAT)
Result Analysis Tool is a complete package for processing OMR scanner educed
data, make result sheet plus deliver report. Instead of OMR machine, user may
also use any other device to take the photo. He does not need much theoretical
or technical skill to run this software.
In an MCQ exam students answer through OMR sheet which goes into a scanner.
After processing each sheet the machine outputs extracted data as an image file.
The main answer file (contains right answers) is also prepared in this way, only
here the OMR sheet is filled up by the teachers. This will be later compared with
the student answer file to make the result.
At first, we shall define areas of an answer sheet (scanned image) and get an
output file in Image Definition Graph (IDG) format. In the process indicator areas

13
and answer areas are defined. Now, using this file we shall process all image files,
including main answer sheet, and extract their data as a Comma Separated Data
(CSD) file.
Secondly, a CSD file (main or student answer file) is used to make the Table
Attribute Information (TAI) file. In the process the user defines field names (like-
class, roll, set code, answer field and so on), their respective range as well as
answer fields’ values (number add/subtract for correct/incorrect answer). Then
student answer file (in CSD format) is imported which uses TAI file as standard
and a Data Base Format (DBF) file is made.
Now, the user will be able to perform various operations like- searching, sorting
and listing; over student answer file (DBF) for error correction like- wrong roll
number, registration number, set code, section and so on. After that user will
compare the file with main answer file (CSD format) and use Table Attribute
Information file to obtain initial result. User may also insert additional data like-
number of other subjects, or calculate grade and so forth; and finally produce the
complete result.
On this point, all is left is to attach additional information (name, father/mother
name, age, institute, address and so forth) from outer database with the result
and produce the final result.
Now, if necessary the user will be able to generate individual result, merit list,
waiting list. The main output will be published as report. Before that user designs
the report and creates a Report Definition Graph (RDG). In the process he defines
text area, image area & table area.
User can directly print or email the result as well. Moreover, he can convert the
data as XLS or PDF format too.
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 Result Analysis Tool.
 A bounded statement of scope for our system.

14
 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: March 25, 2015
Subject: Meeting with the Director
Members:
3. Date: March 25, 2015
Subject: Meeting with Registered Students
Members:

15
4. Date: March 26, 2015
Subject: Meeting with the Faculty
Members:
5. Date: March 27, 2015
Subject: Discussion on the QFD
Members:
6. Date: March 27, 2015
Subject: Preparing the user scenarios
Members:

16
7. Date: March 28, 2015
Subject: Preparing the user scenarios
Members:

17
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.
Table-4.2 Use Case Scenario
Level-0 Level-1 Level-2 Actors
Result
Analysis
Tool
Process
Image
Scan OMR Sheet User, Scanner
Define Image
Area
User, Image
Definition Graph
Extract Image
Data
User, Image
Definition Graph,
Comma Separated
Data
Construct
Database
Define Table
Attribute
User, Table
Attribute

18
Information
Import Student
Answer File
User, Database ,
Table Attribute
Information,
Comma Separated
Data
Produce
Result
Calculate Marks User, Database,
Comma Separated
Data, Table
Attribute
Information
Produce Final
Result
User, Database
Run Query Execute Default
Query
User, Database
Run Raw Query User, Database
Produce
Report
Design Report User, Report
Definition Graph
Generate Report User, Report
Definition Graph,
Database
Deliver
Work
Product
Email User
Print User, Printer

19
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 RAT:
Figure 4.3: Use Case Diagram of RAT
(Level-0)

20
4.3.1 Result Analysis Tool
This is the elaborated form of level-0 for RAT:
Figure 4.3.1: Use Case Diagram of RAT
(Level-1)

21
4.3.1.1 Process Image
We can further section Image Processing system into three sub-systems:
Figure 4.3.1.1: Use Case Diagram of Process Image
(Level-1.1)

22
4.3.1.1.1 Use Case: Scan OMR Sheet
Primary Actor: User
Secondary Actor: Scanner
Goal in Context: Use roll-feed scanner to scan the sheet.
Scenario:
1. Place OMR sheet in scanner.
2. Read OMR sheet.
3. Collect image from scanner.
4. Preserve image in specific place.
Exceptions:
1. System failure.
2. Error in connection.
Priority: Moderate, may be implemented.
When Available: First increment.
Frequency of Use: Several times per week.

25
4.3.1.1.2 Use Case: Define Image Area
Primary Actor: User
Secondary Actor: Image Definition Graph
Goal in Context: Input data for image processing.
Scenario:
1. Select image.
2. Define ‘Indicator Area’.
3. Define ‘Option Area’.
4. Correct property of ‘Option Area’.
5. Save ‘Image Definition Graph’.
Exception:
1. Invalid area (out of range of OMR sheet).
2. Network error.
Priority: Essential, must be implemented.
Precondition: Must have image of OMR sheet.
Frequency of Use: Few times per month.

28
4.3.1.1.3 Use Case: Extract Image Data
Primary Actor: User
Secondary Actors:
1. Image Definition Graph
2. Comma Separated Data
Goal in Context: Get data from OMR sheet.
Precondition: Must have certain Image Definition Graph.
Scenario:
1. Browse and define image path.
2. Label consequent Image Definition Graph.
3. Click ‘Extract Data’ button.
4. Save extracted ‘Comma Separated Data’.
Exceptions:
1. Invalid Image Definition Graph.
2. Corrupted Image Definition Graph.
3. Invalid OMR sheet image.
When Available: Second increment.
Frequency of Use: Moderate frequency.

31
4.3.1.2 Construct Database
We can divide Construct Database into two following sub-systems:
Figure 4.3.1.2: Use Case Diagram of Construct Database
(Level-1.2)

32
4.3.1.2.1 Use Case: Define Table Attribute
Primary Actor: User
Secondary Actor: Table Attribute Information
Goal in Context: Input data about table structure of OMR sheet.
Scenario:
1. Browse and select a ‘Comma Separated Data’ file.
2. Define range of an attribute.
3. Name the attribute.
4. Mark answer field.
5. Define value of each answer.
6. Save data in a ‘Table Attribute Information’ file.
Exceptions:
1. Invalid table range.
2. Invalid table name.
When Available: Third increment.
Frequency of Use: Few in a month.

35
4.3.1.2.2 Use Case: Import Student Answer File
Primary Actor: User
Secondary Actors:
1. Table Attribute Information
2. Comma Separated Data
3. Database
Goal in Context: Insert data in database.
Scenario:
1. Browse and select a student answer file.
2. Select consequent ‘Table Attribute Information’ file.
3. Click button ‘Import’.
4. Save produced ‘Database Format’ file.
Exceptions:
1. Corrupted Table Attribute Information file.
2. Corrupted Comma Separated Data file.
3. Incompatible file.
When Available: Fourth increment.
Frequency of Use: Several times in a month.

38
4.3.1.3 Produce Result
We found two sub-systems in this level:
Figure 4.3.1.3: Use Case Diagram of Produce Result
(Level-1.3)

39
4.3.1.3.1 Use Case: Calculate Marks
Primary Actor: User.
Secondary Actors:
1. Table Attribute Information.
2. Comma Separated Data.
3. Database.
Goal in Context: Get marks obtained by each student.
Scenario:
1. Browse and select ‘Database Format’ file.
2. Select ‘Main Answer’ file.
3. Choose ‘Table Attribute Information’ file.
4. Click button ‘Calculate Marks’.
Exceptions:
1. Corrupted file.
2. Incompatible files.
When Available: Fifth increment.

42
4.3.1.3.2 Use Case: Produce Final Result
Secondary Actor: Database.
Goal in Context: Create a complete result of students.
Scenario:
1. Open consequent ‘Database Format’ file.
2. Calculate total marks, grade point, position, percentage
etc.
3. Save final result.
Exceptions:
1. System error.
2. Math error.
When Available: Sixth increment.

45
4.3.1.4 Run Query
We divided Run Query in two sections:
Figure 4.3.1.4: Use Case Diagram of Run Query
(Level-1.4)

46
4.3.1.4.1 Use Case: Execute Default Query
Secondary Actor: Database
Goal in Context: Run normal query like- sorting, searching etc.
Scenario:
1. Select ‘Database Format’ file.
2. Select query type.
3. Write parameter.
4. Run query.
5. Show output.
Exceptions:
1. Invalid input.
2. System error.
Frequency of Use: Many times a week.

49
4.3.1.4.2 Use Case: Run Raw Query
Secondary Actor: Database.
Goal in Context: Run any type of SQL query over the database.
Scenario:
1. Select ‘Database Format’ file.
2. Write query.
3. Check query for validation.
4. Run query.
5. Show output.
Exceptions:
1. Invalid query.
2. Query error.
3. System Error.
Priority: Moderate, should be implemented.
Frequency of Use: Several times a week.

52
4.3.1.5 Produce Report
We have found two sub-systems in this system:
Figure 4.3.1.5: Use Case Diagram of Produce Report
(Level-1.5)

53
4.3.1.5.1 Use Case: Design Report
Secondary Actor: Report Definition Graph.
Goal in Context: Design the template of report.
Scenario:
1. Open report design form.
2. Define ‘Text Area’.
3. Select property of ‘Text Area’.
4. Define ‘Image Area’.
5. Select property of ‘Image Area’.
6. Place ‘Table Area’.
7. Save data in a ‘Report Definition Graph’ file.
Exceptions:
1. System Error.
2. Report Design Error.
Priority: Moderate priority, should be implemented.
Frequency of Use: Several times per month.

56
4.3.1.5.2 Use Case: Generate Report
Secondary Actors:
1. Report Definition Graph
2. Database
Goal in Context: Generate report over certain data field using Report
Definition Graph.
Scenario:
1. Select ‘Report Definition Graph’ file.
2. Select data source for the ‘Table Area’.
3. Click ‘Generate Report’ button.
4. Save report in PDF file.
Exceptions:
5. System failure.
6. Error in Report Definition Graph.
7. Error in database.
Priority: High priority; should be implemented.

59
4.3.1.6 Deliver Work Product
We have sectioned it into two following parts:
Figure 4.3.1.6: Use Case Diagram of Deliver Work Product
(Level-1.6)

60
4.3.6.1 Use Case: Email
Goal in Context: Email final result, report etc.
Scenario:
1. Input sender’s email address.
2. Input sender’s email password.
3. Input receiver’s email address.
4. Write subject.
5. Write description.
6. Select attachment (file or folder).
7. Compress attachment.
8. Enter encryption password (optional).
9. Click button ‘Send’.
10. Deliver email.
Exceptions:
1. Network problem.
2. Connection problem.
3. System Error.
4. Wrong password.
5. Invalid Email address.

63
4.3.6.2 Use Case: Print
Secondary Actor: Printer.
Goal in Context: Print report directly with default printer.
Scenario:
1. Select file for printing.
2. Click ‘Print’ button.
Exceptions:
1. System error.
2. Null printer error.
3. Connection error.

66
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.
Table-5.2 Data Object Selection
Noun Attributes Description Remark
Result Analysis
Tool
Represents the whole
system
Rejected
RAT Alias of Result Analysis
Tool
Rejected
Package Out of scope Rejected
OMR Scanner A device, external entity Rejected
Data Represents all data Rejected
Result Sheet Alias of report Rejected
Report Generated from
Database Format &
Report Definition Graph
Rejected
User No separated
authentication system
Rejected

67
required
Device External entity Rejected
Photo Attribute of Database
Format &Comma
Separated Data
Rejected
Technical Skill Out of scope Rejected
Software Out of scope Rejected
MCQ Exam Out of scope Rejected
Student Out of scope Rejected
OMR Sheet Out of scope Rejected
Scanner External entity Rejected
Main Answer File Alias of Comma
Separated Data
Rejected
Answer An attribute of Comma
Separated Data &
Database Format
Rejected
Teacher Out of scope Rejected
Student Answer
Files
Alias of Comma
Separated Data
Rejected
Area Alias of Indicator Area &
Answer Area
Rejected
Main Answer Sheet Out of scope Rejected
Image Alias of Photo Rejected
Output File Indicates Image
Definition Graph
Rejected
Image Definition
Graph
Indicator Area,
Option Area
Potential Data Object Accepted
Indicator Area Attribute of Image
Definition Graph
Rejected
Option Area Attribute of Image
Definition Graph
Rejected
Comma Separated
Data
Photo, Answer Potential data object Accepted
Table Attribute
Information
Field Name,
Respective Range,
Answer Fields’ Values
Potential data object Accepted

68
Field Name Attribute of Table
Attribute Information
Rejected
Class An attribute of
Complete Result &
Database Format
Rejected
Roll An attribute of
Complete Result &
Database Format
Rejected
Set Code An attribute of Database
Format
Rejected
Answer Field Alias of Answer Rejected
Respective Range An attribute of Table
Rejected
Answer Fields’
Values
An attribute of Table
Rejected
Number Alias of Answer Fields’
Values
Rejected
Correct Answer Alias of Answer Field Rejected
Incorrect Answer Alias of Answer Field Rejected
Database Format Photo, Answer, Class,
Roll, Set Code, Name,
Father’s Name,
Mother’s Name, Roll,
Registration Number,
Section, Subject,
Grade, Age, Institute,
Address
Potential Data Object Accepted
Searching Out of scope Rejected
Sorting Out of scope Rejected
Registration
Number
Can be an attribute of
Database Format
Rejected
Roll Number Alias of Roll Rejected
Set Code Out of scope Rejected
Section Can be an attribute of Rejected

69
Database Format
Insert Additional
Data
Can be an attribute of
Notice
Rejected
Subject An attribute of Database
Format
Rejected
Grade An attribute of Database
Format
Rejected
Complete Result Alias of Database
Format
Rejected
Additional
Information
Name Attribute of Database
Format
Rejected
Father Name Attribute of Database
Format
Rejected
Mother Name Attribute of Database
Format
Rejected
Age Can be an attribute of
Database Format
Rejected
Institute Can be an attribute of
Database Format
Rejected
Address Can be an attribute of
Database Format
Rejected
Outer Database Alias of Database
Format
Rejected
Final Result Alias of Complete Result Rejected
Individual Result Alias of Complete Result Rejected
Merit List Alias of Database
Format
Rejected
Waiting List Alias of Database
Format
Rejected
Main Output Indicates Report Rejected
Report Definition
Graph
Text Area, Image
Area, Table Area
Potential data object Accepted
Text Area Attribute of Report
Definition Graph
Rejected

70
Image Area Attribute of Report
Definition Graph
Rejected
Table Area Attribute of Report
Definition Graph
Rejected
XLS Format Output of Database
Format
Rejected
PDF Format Output of Database
Format
Rejected
5.3 Data Objects and Attributes
This is a brief view of all attributes we have found so far:

71
5.4 Relationship between Data Objects
Here we have shown pair wise relation between two entities.
Figure 5.4: Data Object Relational Diagram

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

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

74
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
Table-6.2 General Classification
No. Noun
General
Classification
Remark
1 Result Analysis Tool 2 Problem Space (represents
whole system)
2 RAT 2 Problem Space (represents
whole system)
3 Package NULL Problem Space

75
4 OMR Scanner 1, 2 Solution Space
5 Data NULL Problem Space
6 Result Sheet 2 Solution Space (Same as No. 7)
7 Report 2 Solution Space
8 User 4, 1 Solution Space
9 Device 1, 2 Solution Space (Same as No. 4)
10 Photo 2 Solution Space
11 Technical Skill NULL Problem Space
12 Software 1, 7 Solution Space (Represents
whole system)
13 MCQ Exam 3 Problem Space
14 Student 4 Solution Space
15 OMR Sheet 1, 2 Solution Space
16 Scanner 1, 2 Solution Space (Same as No. 4)
17 Main Answer File NULL Problem Space
18 Answer NULL Problem Space
19 Teacher 1, 4 Solution Space
20 Student Answer Files NULL Problem Space
21 Area NULL Problem Space
22 Main Answer Sheet 1, 2 Solution Space (Same as No.
15)
23 Image 2 Solution Space (Same as No.
10)
24 Output File NULL Problem Space
25 Image Definition
Graph
1, 4 Solution Space
26 Indicator Area NULL Problem Space
27 Option Area NULL Problem Space
28 Comma Separated
Data
1, 4 Solution Space
29 Table Attribute
Information
1, 4 Solution Space
30 Field Name NULL Problem Space
31 Class NULL Problem Space
32 Roll NULL Problem Space
33 Set Code NULL Problem Space

76
34 Answer Field NULL Problem Space
35 Respective Range NULL Problem Space
36 Answer Fields’
Values
NULL Problem Space
37 Number NULL Problem Space
38 Correct Answer NULL Problem Space
39 Incorrect Answer NULL Problem Space
40 Database Format 1, 4 Solution Space
41 Searching 3 Solution Space
42 Sorting 3 Solution Space
43 Registration Number NULL Problem Space
44 Roll Number NULL Problem Space
45 Set Code NULL Problem Space
46 Section NULL Problem Space
47 Insert Additional
Data
3 Solution Space
48 Subject NULL Problem Space
49 Grade NULL Problem Space
50 Complete Result NULL Problem Space
51 Additional
Information
NULL Problem Space
52 Name NULL Problem Space
53 Father Name NULL Problem Space
54 Mother Name NULL Problem Space
55 Age NULL Problem Space
56 Institute 5 Problem Space
57 Address NULL Problem Space
58 Outer Database 1 Solution Space (Same as No.
40)
59 Final Result NULL Problem Space
60 Individual Result NULL Problem Space
61 Merit List NULL Problem Space
62 Waiting List NULL Problem Space
63 Main Output NULL Problem Space

77
64 Report Definition
Graph
1, 4 Solution Space
65 Text Area NULL Problem Space
66 Image Area NULL Problem Space
67 Table Area NULL Problem Space
68 XLS Format NULL Problem Space
69 PDF Format NULL Problem Space
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
Table-6.3 Selection Characteristics
No. Potential Class Characteristics Remarks
1 OMR Scanner 2, 6 No
2 Report 1, 2, 3, 4, 6 Yes
3 User 3 No
4 Photo 1, 2 No
5 Student 1, 3, 4 No
6 OMR Sheet 1, 6 No
7 Teacher 1, 3, 4 No
8 Image Definition Graph 1, 2, 3, 4, 5, 6 Yes
9 Comma Separated Data 1, 2, 3, 4, 5, 6 Yes

78
6.4 Attribute Selection
Here we find attributes for selected classes.
Table-6.4 Attribute Selection
No. Class Attributes Remarks
1 Report header, footer, table ins_logo for institute logo,
header for institute info,
footer for remarks, table
for data table
2 Image
Definition Graph
area_indicator,
area_option
area_indicator for the area
that may indicate the
validity of OMR sheets
image, area_option for the
available answer field area
3 Comma
Separated Data
photo, stu_answer photo for image path of
consequent data,
stu_answer for the options
the student marked
4 Table Attribute
Information
field_name, range,
answer_values
field_name for name of
attribute or field, range for
respective data range,
answer_values for the
answer fields’ values the
10 Table Attribute Information 1, 2, 3, 4, 5, 6 Yes
11 Database Format 1, 2, 3, 4, 5, 6 Yes
12 Searching 2, 6 No
13 Sorting 2, 6 No
14 Insert Additional Data 2, 6 No
15 Report Definition Graph 1, 2, 3, 4, 5, 6 Yes

79
student chose
5 Database
Format
photo, answer,
stu_class, roll_num,
set_code, stu_name,
father_name,
mother_name,
reg_num,
stu_section, subject,
stu_grade, stu_age,
stu_inst, stu_address
Photo for, answer for
image path of consequent
data, stu_class for class of
the student, roll_num for
student roll, set_code for
exam set code, stu_name
for name of student,
father_name for the name
of student’s father,
mother_name for the
name of student’s father,
reg_num for student
registration number,
stu_section for student
section, subject for exam
subject, stu_grade for the
grade the student got,
stu_age for student’s age,
stu_inst for the name of
institute, stu_address for
the address of student
6 Report
Definition
Graph
area_text,
area_image,
area_table
area_text for text area,
area_image for area
containing image,
area_table for area
containing table of data
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

80
Here we list all verbs from usage scenario.
Table-6.5.1 Verb List
No. Verb Remarks
1 make result sheet Yes
2 deliver report Yes
3 use device to take the photo No Need
4 run software Out of Scope
5 answer through OMR sheet Out of Scope
6 goes into scanner Out of Scope
7 process sheet Out of Scope
8 output extracted data No Need
9 prepare main answer file Out of Scope
10 fill OMR sheet Out of Scope
11 compare with student answer file No Need
12 define areas Yes
13 get output file in IDG format Yes
14 define indicator areas and option areas Yes
15 process image files No need
16 extract data Yes
17 make the TAI file Yes
18 define field names Yes
19 import student answer file Yes
20 perform operations Yes
21 compare Yes
22 obtain initial result Yes
23 insert additional data Yes
24 produce complete result Yes
25 attach additional information Yes

81
26 produce final result. Yes
27 generate individual result Yes
28 generate individual merit list Yes
29 generate individual waiting list Yes
30 publish report Yes
31 design report Yes
32 create RDG Yes
33 define text area Yes
34 define image area Yes
35 define table area Yes
36 print result Yes
37 email result Yes
38 convert data Yes
6.5.2 Selected Methods
From the verb list above we have selected following methods for classes.
Table-6.5.2 Selected Methods
Class Methods
Report email_result(), print_result(),
convert_result(), publish_report()
Image Definition Graph def_indicator(), def_option(),
create_IDG(), export_CSD()
Comma Separated Data range_data(), create_TAI()
Table Attribute Information define_fields(),import_CSD()
Database Format search(), sort(), compare(),

82
initial_result(), ins_add_data(),
complete_result(), attach_final_data(),
final_result(), gen_ind_result(),
gen_merit_list(), gen_waiting_list()
Report Definition Graph design_report(), define_text(),
define_image(), define_table(),
export_RDG()

83
6.6 Class Diagram
We have shown here, how the classes interact together to accomplish certain
goal.
Figure 6.6: Class Diagram (RAT)

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

86
Chapter 7
Flow-Oriented Model
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-process-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 are represented by circles.

93
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.
Table-8.2 Identifying Events
Event Initiator Collaborator
Take Image? User Scanner
Produce Image Definition Graph? User
Create Comma Separated Data
File?
User Image Definition Graph
Produce Table Attribute
Information?
User
Construct Database Format File? User Table Attribute Information,

94
Comma Separated Data
Check Error? User Database Format file
Generate Result? User Database Format file
Join More Information? User Database Format file
Produce Report Definition Graph User
Generate Report User Report Definition Graph
Print Report User Printer
Email Work Product User
Convert To Other Formats User Database Format file

95
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: State Transition Diagram- User

96
Figure 8.3.2: State Transition Diagram- User
(continued)

97
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: Sequence Diagram- Scan Image

98
Figure 8.4.2: Sequence Diagram- Create Image
Definition Graph

99
Figure 8.4.3: Sequence Diagram- Generate Comma
Separated Data

100
Figure 8.4.4: Sequence Diagram- Create Table Attribute
Information

101
Figure 8.4.5: Sequence Diagram- Generate Database
Format

102
Figure 8.4.6: Sequence Diagram- Error Correction

103
Figure 8.4.7: Sequence Diagram- Generate Result

104
Figure 8.4.8: Sequence Diagram- Joining Information

105
Figure 8.4.9: Sequence Diagram- Create Report
Definition Graph

106
Figure 8.4.10: Sequence Diagram- Generate Report

107
Figure 8.4.11: Sequence Diagram- Email Work Product

108
Figure 8.4.12: Sequence Diagram- Convert Format

109
Figure 8.4.13: Sequence Diagram- Print Report

110
Chapter 9
Conclusion
This marks the end of our report. We are pleased to submit the final
SRS report on Result Analysis Tool. From this, the readers will get a
clear and easy view of the MCQ exam system & OMR sheet result
processing.
To improve the efficiency of the institutions, the authority needs to
automate the exam evaluation task. A system with automated
software system is more effective than manual system. This SRS
document can be used effectively to maintain software development
cycle. We get a detailed description of the total system. It also gives
us a general overview of the project. It will be very easy to conduct
the whole project using this SRS. It also helps us to determine the
pitfalls that may come ahead. Hopefully, this document can also
help other Software Engineering students as well as practitioners.
We tried our best to remove all dependencies and make effective
and fully designed SRS. We believe that reader will find it in order.

111
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. Software Requirement Specification and Analysis projects
on Student Information System of BSSE-05th
batch.
5. http://www.codeproject.com/Articles/6675/Behavior-
Modeling-Lesson, accessed on 23th March, 2015.
6. http://remarksoftware.com/products/office/, accessed on
24th March, 2015.
7. http://omrhome.com/, accessed on 24th March, 2015.
8. https://www.formreturn.com/, accessed on 24th March, 2015.
9. http://en.wikipedia.org/wiki/Optical_mark_recognition,
accessed on 24th March, 2015.
10. http://www.yoctel.com/yomark-omr-reader.html, accessed
on 25th March, 2015.

Software Requirement Specification (SRS) on Result Analysis Tool

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Software Requirement Specification (SRS) on Result Analysis Tool

Similar to Software Requirement Specification (SRS) on Result Analysis Tool (20)

More from Minhas Kamal

More from Minhas Kamal (20)

Recently uploaded

Recently uploaded (20)

Software Requirement Specification (SRS) on Result Analysis Tool