Middle East Technical University. Department of Computer Engineering

Transcription

1 Middle East Technical University Department of Computer Engineering TurkHITs Software Requirements Specifications v1.1 Group fourbytes Safa Öz Mert Bahadır Özge Çevik Sema Ateş December 29,

2 İçindekiler 1. Introduction Problem Definition Purpose Scope Definitions, acronyms, and abbreviations References Overview Overall description Product perspective Product functions Overall Use Cases Use Cases Constraints Assumptions and dependencies Specific requirements System Environment Functional Requirements Non-functional Requirements Performance requirements Safety Requirements Security Requirements Portability Requirements Other Requirements GNU GPL License Data Model and Description Data Description User Class Requester Class Worker Class HITs Class Behavioral Model and Description Description for software behavior

3 5.2 State Transition Diagrams Human Intelligence Task Submission State Diagram Human Intelligence Task Evaluation State Diagram Ban user for a specified job State Diagram Planning Team Structure Estimation (Basic Schedule) Process Model Conclusion Appendix Appendix A: Definitions of Terms

4 1. Introduction This document provides the details of software requirements specification (SRS) for a project Turk Human Intelligence Tasks (TurkHITs). It is prepared according to the IEEE Recommended Practice for Software Requirements Specifications. This document will also give brief information about similar existing projects. 1.1 Problem Definition In our world, there are some tasks which need to be approved by humans because today s technology is not inadequate to handle. The problem is these tasks are impossible or so difficult for computers. In 2005, Amazon created a new service called Amazon Mechanical Turk to handle this problem. After that year, other crowd sourcing systems arise in United States. Today s, either Turkish workers or Turkish requesters and companies are not supported by any this kind of systems. Semiocast's latest study reveals Turkey is now the eleventh country according to the twitter account number. Hence understanding and interpreting of thousands of tweets become popular because of the some reasons such as advertising, development or understanding peoples idea on a specific topic. As a result of this, number of Turkish sentiment analysis companies is growing up. One of the parts of this project is helping to the Turkish sentiment analysis companies by approving or categorizing their data quickly. In our system, not only texts or tweets but also images or audio files are interpreted. These jobs are made by workers not computers or a artificial intelligence system. Our system makes a connection between companies and workers. This project helps a lot of business area such as Artistic & educational research, social science experiments and missing persons searches. Until this project, Turkish companies, institutions or researchers have to handle their problem by own. For example, a sentiment analysis company makes an announcement for a person who read and verifies their analysis. According to the experience, the cost of these tasks was considerably lower than other means of conducting surveys, with workers willing to complete tasks for less than half the minimum wage. 1.2 Purpose 4

5 The purpose of this document is to present a detailed description of the TurkHITs System. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system is designed. This document is intended for both the stakeholders and the developers of the system. 1.3 Scope The software product which we will develop is a web platform which performs task by using human intelligence. The system provides the processing data types according to demand of people from various business and ages. Sometimes, it can be a categorization of images and audio files or sentiment analysis of tweets. The objective of the project serving various needs such as academic, business and public in terms of requesters. 1.4 Definitions, acronyms, and abbreviations This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendixes in the SRS of by reference to other documents. 1.5 References IEEE. IEEE Std IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, StarUML 5.0 User Guide. (2005). Retrieved from 5

6 1.6 Overview The next chapter, the Overall Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The third chapter, Requirements Specification section of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product. The fourth chapter, Data model and behavioral model describes information domain for the software. Finally, we will introduce our plan and end the document with a conclusion part. Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language. 2. Overall description This section will give an overview of the whole system. The system will be explained in its context to show how the system interacts with other systems and introduce the basic functionality of it. It will also describe what type of stakeholders that will use the system and what functionality is available for each type. At last, the constraints and assumptions for the system will be presented. 2.1 Product perspective The TurkHITs is totally independent system that is not related to any other system and not a component of a larger system. The TurkHITs System is an Internet-based application executing on a Web server and connected to an enterprise database. The TurkHITs is a threetiered, web-based application. Three-tier architecture consists of 3 levels; database tier, middle and client tier. The presentation tier is a layer which users can access directly such as a web page, or an operating systems GUI. It communicates with other tiers by outputting results to the 6

7 browser/client tier and all other tiers in the network. User enters the system and then his/her requests are sent to the Web Server part. Middle tier (logic tier) coordinates the application, process commands, makes logical decision and evaluations, and performs calculations. It is also makes and process data between the two surrounding layers. All the data is stored in a database in the third tier (server-side). In the system there are two types customer who are requesters and workers. The worker or requester requests information via the user worker interface. If worker request information via this interface, system goes into the database, processes the request, fetches the related data and returns it to the worker and brings HITs in order worker to evaluate. A requester creates the HITs via system then the HITs can be ready to use. If requester requests information via this requester interface, system goes into the database, processes the request, fetches the related data and returns it to the requester and brings HITs in order requester to manage, system goes into the database. The requesters and workers can upload data or receive submitted data via these web services. Admin interface directly connects to the database and have authority of membership activation, block membership, payment approval and fix reported problems. Worker, requester and admin interface are connected to user interface because all sign-up, sign-in, sign-out and account settings are in user interface. We ll use HTTP protocol for handling Requests and responses. HTTP protocols are a request-response protocol in the clientserver computing model. Figure 1 The three-tier architecture model 7

8 2.2 Product functions Functional requirements are those that refer to the functionality of the system. Each functional requirement includes a description of every input into the system and every output from the system. Some of these are provided by using diagrams to make the system more clear Overall Use Cases 8

9 Diagram 1: Overall Use Cases Use Cases 9

10 User Use Cases Diagram: Diagram 2: User Use Cases Use Case: Sign-up Diagram: Diagram 3: Sign-up Brief Description: The user signs up the system Actor User 10

11 Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths User presses Sign Up button. The user has already in the main page 1. User presses Sign Up button. 2. User fills in necessary information in the form. 3. User presses Send Request button. 4. System sends verification to the user. 5. User activates the account by verifying the User wait for the admin s approval. If userid is taken, then s/he does not have to sign up the system Use Case: Sign-in Diagram: Diagram 4: Sign-in Brief Description: The user signs in the system. Actor Trigger Pre-condition User User presses Sing In button. The user has already in the main page. 11

12 Basic Path Alternative Paths Post-condition Exception Paths 1. User enters his/her username 2. User enters his/her password. 3. User presses Sing In button. 4. User is directed to the user s page. 1. User enters his/her address. 2. User enters his/her password. 3. User presses Sing In button. 4. User is directed to the user s page. The user is directed to the user interface. If user enters invalid username and/or password, s/he is warned and redirected to the sign in page Use Case: Sign-out Diagram: Diagram 5: Sign-out Brief Description: The user signs out the system. Actor Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths User User presses Sign Out button. User has already signed in to the system. 1. User presses Sign Out button. 2. The user is directed to the main page. The user directed to the main page. 12

13 Use Case: Account Settings Diagram: Diagram 6: Account Settings Brief Description: The user views his/her account settings. Actor Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths User User presses My Profile button. User has already signed in to the system. 1. User Presses My Profile button. User is directed to the Account Settings Page Worker Use Cases Diagram: Diagram 7: Worker Use Cases 13

14 Use Case: Evaluate HITs Diagram: Diagram 8: Evaluate HITs Brief Description: The worker evaluates HITs. Actor Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths Worker Worker presses Accept HIT button. Worker has already signed in to the system. 1. Worker presses View HIT button. 2. Worker presses Accept HIT button. Worker is directed to the evaulation page Requester Use Cases Diagram: 14

15 Use Case: Create HITs Diagram 9: Requester Use Cases Diagram: Diagram 10: Create HITs Brief Description: The Requester creates HITs. Actor Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths Requester Requester presses Create HITs button. Requester has already signed in to the system. 1. Requester presses Create HITs button. Requester is directed to the Create HIT page Use Case: Manage HITs 15

16 Diagram: Diagram 11: Manage HITs Brief Description: The requester manages his/her HITs Actor Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths Requester Requester presses Manage HITs button. Requester has already signed in to the system. 1. Requester presses Manage HITs button. Requester is directed to the Manage HIT page Admin Use Cases Diagram: 16

17 Use Case: Membership Activation Diagram 12: Admin Use Cases Diagram: Brief Description: Admin activates membership. Diagram 13: Membership Activation Actor Trigger Pre-condition Basic Path Admin Admin presses Membership Activation button Admin has already signed in to the system. 1.Admin presses Membership Activation button 17

18 Alternative Paths Post-condition Exception Paths Admin is directed to the Activation approval page Use Case: Block Membership Diagram: Brief Description: Admin blocks membership. Diagram 14: Block Membership Actor Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths Admin Admin presses Block membership button. Admin has already signed in to the system. 1. Admin presses Memberships button. 2. Admin select a membership. 3. Admin presses Block Membership button. Memberships list is updated Use Case: Payment Approval 18

19 Diagram: Diagram 15: Payment Membership Brief Description: Admin approves payment from requester. Actor Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths Admin Admin presses Approve payment button Admin has already signed in to the system. 1. Admin presses Payments button. 2. Admin select a Payment. 3. Admin presses Approve Payment button. Payment from Requester is approved Use Case: Fix Reported Problems Diagram: Diagram 16: Fix Reported Problems Brief Description: Admin fixes any reported complaints, conflicts or other problems. 19

20 Actor Trigger Pre-condition Basic Path Alternative Paths Post-condition Exception Paths Admin Admin presses Reported Problems button. Admin has already signed in to the database. 1. Admin presses Reported Problems button. 2. A list of current conflicts and complaints appears. 3. Admin chooses one of the problems in this list and resolves it. 4. Admin repeats step 3 if any other problem exists. Reported problem(s) is solved and deleted from the list Constraints The project is implemented with MVC software architecture pattern which separates the representation of information from the user's interaction with it. We ll use Java MVC framework. This framework uses spring, hibernate and jsp java technologies. In client side, javascript, HTML and CSS will be used. In order to perform better while using the webpage, users should utilize the latest versions of these browsers. CSS is used as style sheet language for the HTML codes. On the whole, there are no strict restrictions without the specific web browsers usage. We choose Apache Tomcat 7.0 as a web server which implements the Java Servlet and the Java Server Pages (JSP) specifications and MySQL as an open-source database. The laws in Turkish regulatory system will be the basis of this project. Copyright and patent issues stated in the constitution and ethics related to them will not be violated. During the payments and other transactions with users, agreements between us and the banks will be valid. Moreover, for accommodation services, agreements between us and tourism agencies will be made. We will have strong responsibilities towards our employees and employers. 20

21 Apache License 2.0 is used as software license. All the rights of both Apache License and other programs used are valid. 2.4 Assumptions and dependencies Internet connection and supported web browsers (Netscape Navigator and Internet Explorer) are needed. 3. Specific requirements In this part, software requirements will be explained in detail, under system environment, external interface requirements, functional and non-functional requirements sections. 3.1 System Environment The TurkHITs application has worker, requester and admin as actors interacting with the system. The workers and requesters can use the system through the web page, whereas the admin has access to the entire system. 21

22 Diagram 17: System Environment 3.2 External Interface Requirements 3.3 Functional Requirements User s functions are sign-up, sign-in, sign-out, account settings. First of all user should sign-up the system. When he/she want to use system he/she must sign-in. His/her work s is done he/she can sign-out system. If necessary he/she can visit account settings. Worker is capable of what user can do. In addition to this worker can evaluate HITs if he/she wants. Requester is capable of what user can do. In addition to this requester can create HITs. When he/she wants he/she manage his/her HITs. Admin is capable of what user can do. In addition to this admin is responsible for the membership activation, membership blocking and he/she approve the payment from requesters. Admin will fix the reported problems if any. 3.4 Non-functional Requirements Performance requirements 22

23 The project TurkHITs is a web-service application which is desired to handle multiple users. Therefore, a server database will be used in order to provide support Safety Requirements The project TurkHITs is a crowd sourcing project so must guarantee that the uploaded data will not be lost and will sent to workers properly Security Requirements This system s database has to be reached securely and its data should not be broken in order to provide security and consistency Portability Requirements The TurkHITs mechanical Turk system should be portable and therefore can be operated on GNU/Linux distributions, Mac OS X and Microsoft Windows Other Requirements GNU GPL License The project will be released under GNU General Public License, which allows the use, change and redistribution of the software freely. The philosophy of this license is applied to this mechanical Turk system to achieve the greatest possible use and development by public. 4. Data Model and Description 23

24 This part of the SRS is about classes which contains data and their relationships. 4.1 Data Description This system serves as a server-client web application. Client side, namely end-users of the system, requests service from server-side. This service may be getting information or downloading files from the system server. Also, information entered by the user (for example, during registration) is sent to the system database and causes updates on the server. In addition, file uploading is another request. These uploaded files are maintained in the server securely User Class The main purpose of this class is keeping information about users. Figure 2: User Class Diagram Requester Class The Requester class inherits the User class. It has also specific attributes which are companyinfo and createdhits and a member function called availablehits. 24

25 Figure 3: Requester Class Diagram Worker Class The Worker class inherits the User class. It has also specific attributes which are evaluatedhitscount and evaluatinghits HITs Class Figure 4: Worker Class Diagram We have Hits Class for Human Intelligence tasks. Later, we can create new subclasses for HITs in the design stage. Figure 5: Hits Class Diagram 25

26 Figure 6: Data Class Relations Diagram 26

27 5 Behavioral Model and Description 5.1 Description for software behavior After software is deployed to the server, an admin must be created with all accesses. Admin is a must for accepting worker and requester creation requests. Then users can apply for registering. If request is accepted by admin necessary access rights are given to requested users. Because in our project reliability is very important for either requester or worker. If a requester wants to give a job, admin must certify the job. Also if a user completes a job, admin must certify the job. Users can log out the system using sign out button. 5.2 State Transition Diagrams Human Intelligence Task Submission State Diagram Figure 7: State diagram of HIT submission As is seen in figure 7, creating HITs have to satisfy some requirements. First of all, user should have an account and then upload right file format. After that according system 27

28 calculation, payment has been made by requester. At the final, the job must be submitted by admin Human Intelligence Task Evaluation State Diagram Figure 8: State diagram of HIT evaluation As is seen in figure 8, evaluations of HITs have to satisfy some requirements. First of all, user should has an account and then satisfy some requirements like success rate. At the final, the evaluated job must be confirmed by admin Ban user for a specified job State Diagram 28

29 Figure 9: State diagram of User ban As is seen in figure 9, the requester of a HIT can ban a user from own HIT. This system helps to get better results. 6. Planning 6.1 Team Structure We are 4 people working on this project: Özge Çevik, Mert Bahadır, Sema Ateş and Safa Öz. We are all senior students at Middle East Technical University, Computer Engineering department. Safa Öz and Özge Çevik are responsible for research, Database module and software part of the project Mert Bahadır and Sema Ateş are responsible for Research, Design, Public Relations and development process. 6.2 Estimation (Basic Schedule) October 27 October 30 November Week 1-2 November Week 2 Determining the Characters and their functions SRS Completion Research on existing systems and tools Initial Design Report 29

30 November Week 3-4 Designing Web Page December Week 1 Iteration 1 December Week 2-3 Iteration 2 December 31 January Presentation Prototype Demo 6.3 Process Model As seen in the following figure, we decided the waterfall process model. Waterfall process model is a sequential process which includes requirements, software design and architecture, development and coding, quality assurance and software testing, implementation and maintenance and support. Hence, after the software requirements specification, we will write initial and detailed design reports and then start to develop the project. Figure 10: Process model 7. Conclusion 30

31 The Requirement Analysis Report describes the content of the system in both functional and non-functional aspects. Design constraints and system interfaces are also described in this report. In the first part as a brief introduction, the problem is described and background information is given. Scope of the project, definitions, acronyms and abbreviations are stated. In the second part, the overall description is given and perspective, functions, constraints, assumptions and dependencies of the product are given in detail. In the third part, specific requirements of the project in terms of system environment, functional requirements and nonfunctional requirements are covered. In the fourth section, data description is given and data model is shared. In the fifth, planning section of the report, team structure, estimation and process model is stated. 8. Appendix 8.1 Appendix A: Definitions of Terms HITs CSS Eclipse IDE IEEE JavaScript SRS UML GUI Human Intelligence Task Cascading Style Sheets Multi-language software development environment Integrated Development Environment Institute of Electrical and Electronics Engineers Client-side scripting language System Requirements Specification Unified Modeling Language Graphical User Interface 31

32 RGUI PC Requester Graphical User Interface Personal Computer 32