# Effort Estimation Approach through Extracting Use Cases via Informal Requirement Specifications
## 1 Introduction  
At the present time, current software is becoming increasingly more significant and complicated. For high-quality software, we must accurately analyze the natural language-oriented requirement specifications at the beginning of software development. In requirement engineering, use-case approaches are increasingly attracting attention in requirements engineering because the user-centered concept is valuable in eliciting analyzing requirements [1]. Use cases describe the behavior of system as seen from an actor's point of view [2]. One of the important things is how to correctly analyze requirement specifications to prevent potential errors in requirements and to reduce development and maintenance costs [3]. However, in real software projects, most of the informal requirement specification documents are written, so it is difficult to analyze informal requirement specifications with only linguistic, textual analysis. In software-industrial fields in Korea, some natural language-oriented requirement analysis methods have been mentioned. [PERSON] [4] mentioned a method of object extraction and modeling from the user requirements with [PERSON]'s textual approach, which identifies user requirements to extract objects and object modeling through a scenario-based analysis. [PERSON] [5] mentioned a method of requirement extraction with goal-based requirement analysis but just mentioned a requirement extraction method. [PERSON] [6] also mentioned his extraction methods with goal and scenario concepts, which generate use-case descriptions based on the scenario-based analysis. His approach had a problem requiring a change of requirements that are tailored in a defined scenario. Most of the requirement analysis and extraction methods use the concept of goal and scenarios. The primary purpose of these studies suggested to identify and analyze requirements theoretically because of analyzing no systematic way in existing use-case approaches to handle non/functional requirements [1]. Their focused researches are the use-case approach that shows the interaction betweenan actor and a system based on a user-centric analysis, which easily classify the high-level functionalities of the system. Our previous use-case approach is difficult to analyze the impact between use-cases [4; 5]. When using descriptive requirements, this approach makes use-case extraction impossible because of its ambiguous expressions and is not clear with the requirements analysis criteria [6]. In natural language analysis fields, some researched focused on developing formal grammars and parsers in order to perform analysis of the natural language sentence. [PERSON] [7; 8; 9] mentioned to find rules with lexical-functional grammar and case grammar to include semantic roles to represent the natural language sentence. Ye [10] mentioned to apply foreign language teaching and vocabulary teaching at new student with [PERSON]'s case theory. But they never mention about how to apply requirement engineering with linguistic analysis. To solve such a problem, we propose a use-case extraction method from natural language-oriented informal requirement specifications based on semantic analysis of [PERSON]'s mechanism. The suggested method identifies key verbs in requirement sentences and extracts arguments of the verb in a sentence. Then it can extract the use-case through constructing a recursive visual modeling mechanism until no more slightly connected. To make it easier and more accurate to extract use-cases, we have adopted [PERSON]'s Case Grammar and also have applied with [PERSON]'s Goal Use Case technique on Requirement Analysis to identify the goals of a system from an effective requirement identification approach. He mentioned \"It is the goal the primary actor has in trying to get work done or the user has in using the system\" [11]. The approach looks at the interactions of a single category of users at a time, considerably reducing the complexity of requirements determination without supporting use-case formalization [11; 12].