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

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.


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.


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.


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.


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.


When Available: Fifth increment.


40

41

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.


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


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.

47

48

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.

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


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.

54

55

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.



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


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.




61

62

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.




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.

http://www.codeproject.com/Articles/6675/Behavior-Modeling-Lesson

http://www.codeproject.com/Articles/6675/Behavior-Modeling-Lesson