software requirement specification (srs) on result analysis tool
Post on 15-Apr-2017
1.298 Views
Preview:
TRANSCRIPT
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 Institute of Information Technology
University of Dhaka
Submission Date 05th April, 2015
LETTER OF TRANSMITTAL
05th April, 2015.
Emon Kumar Dey Lecturer Institute of Information Technology 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 7.2.1.2 DFD Level 1.2 88
Figure 7.2.1.3 DFD Level 1.3 89
Figure 7.2.1.4 DFD Level 1.4 89
Figure 7.2.1.5 DFD Level 1.5 90
Figure 7.2.1.6 DFD Level 1.6 90
Figure 7.2.1.7 DFD Level 1.7 91
Figure 7.2.1.8 DFD Level 1.8 91
Figure 7.2.1.9 DFD Level 1.9 92
Figure 7.2.1.10 DFD Level 1.10 92
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
Subject: Identifying Stakeholders
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
3. Date: February 25, 2015
Subject: Identifying Stakeholders
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
4. Date: March 19, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
9
○ BSSE 0530- Mostaque Ahmed
5. Date: March 23, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
6. Date: March 24, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology, University of Dhaka
Members: March 29, 2015
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
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
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
3. Date: March 25, 2015
Subject: Meeting with Registered Students
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
15
4. Date: March 26, 2015
Subject: Meeting with the Faculty
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
5. Date: March 27, 2015
Subject: Discussion on the QFD
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
6. Date: March 27, 2015
Subject: Preparing the user scenarios
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
16
7. Date: March 28, 2015
Subject: Preparing the user scenarios
Place: Institute of Information Technology, University of Dhaka
Members:
○ BSSE 0509- Minhas Kamal
○ BSSE 0524- Saif Uddin Mahmud
○ BSSE 0530- Mostaque Ahmed
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.
23
24
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.
When Available: First increment.
Frequency of Use: Few times per month.
26
27
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.
Priority: Essential, must be implemented.
When Available: Second increment.
Frequency of Use: Moderate frequency.
29
30
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.
Priority: Essential, must be implemented.
When Available: Third increment.
Frequency of Use: Few in a month.
33
34
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.
Priority: Essential, must be implemented.
When Available: Fourth increment.
Frequency of Use: Several times in a month.
36
37
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.
Priority: Essential, must be implemented.
When Available: Fifth increment.
Frequency of Use: Several times per week.
40
41
42
4.3.1.3.2 Use Case: Produce Final Result
Primary Actor: User.
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.
Priority: Essential, must be implemented.
When Available: Sixth increment.
Frequency of Use: Several times per week.
43
44
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
Primary Actor: User.
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.
Priority: Essential, must be implemented.
When Available: Sixth increment.
Frequency of Use: Many times a week.
47
48
49
4.3.1.4.2 Use Case: Run Raw Query
Primary Actor: User.
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.
When Available: Sixth increment.
Frequency of Use: Several times a week.
50
51
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
Primary Actor: User.
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.
When Available: First increment.
Frequency of Use: Several times per month.
54
55
56
4.3.1.5.2 Use Case: Generate Report
Primary Actor: User.
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.
When Available: Sixth increment.
Frequency of Use: Several times per week.
57
58
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
Primary Actor: User.
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.
Priority: Moderate, may be implemented.
When Available: First increment.
Frequency of Use: Several times in a month.
61
62
63
4.3.6.2 Use Case: Print
Primary Actor: User.
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.
Priority: Moderate, may be implemented.
When Available: First increment.
Frequency of Use: Several times in a month.
64
65
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 Attribute Information
Rejected
Answer Fields’ Values
An attribute of Table Attribute Information
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.
85
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.
87
88
89
90
91
92
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.
top related