[ieee 2013 ieee 4th control and system graduate research colloquium (icsgrc) - shah alam, malaysia...

An Automated Method for Requirement Determination and Structuring Based on 5W1H

Elements Marzanah A. Jabar, Ramin Ahmadi, Mohammad Yaser Shafazand, Abdul Azim Abdul Ghani, Fatimah Sidi,

and Sa'adah Hasan Faculty of Computer Science and Information Technology

Universiti Putra Malaysia 43400, Serdang, Malaysia

{marzanah, ahmadi,shafazand, azim, fatimacd, saadah}@fsktm.upm.edu.my

Abstract— Information requirement determination is an important phase of software development. Since it happens at the beginning stages of software development, improvement in this process may lead to significant results for the entire software development. However, it is widely admitted that most of the conventional methods for collecting and analyzing requirements are not successful because several weaknesses such as lack of a certain automatic tool to elicit and analyze knowledge, or a well-structured model to facilitate the generation, analysis, and presentation of information requirements. In this paper, we discuss an integrated method to improve Information requirement determination and structuring in software development by asking questions based on 5W1H model of knowledge structure. Our unique contribution is that the proposed method uses a data mining method known as part-of-speech tagging tailored for requirement analysis to identify and organize target elements and their dependencies. We conduct experiments on a case study, demonstrating effectiveness of the method.

Index Terms— Information requirement determination, Data mining, Knowledge elicitation

I. INTRODUCTION

It has been argued that software requirement analysis is in fact the most important phase of software development. Requirement analysis is a collection of activities which system analyst performs to evaluate functionality that is required in a proposed system. These requirements include purpose of the system, business goals and process, list of data inputs, design decision constraints, and user’s behaviors [1], [2], [3] and [4]. Such information about requirements is sought from the stakeholders of the system by conducting interviews, reviews or surveys or perhaps be gathered by observing current system. This evaluation of requirements is indeed one of the key factors of a successful system [5]. Current Information requirement determination methods typically collect the information about system development with regard to how users would prefer to interact with system. These methods include interviews, questionnaires, observation, and prototyping. However, requirement determination using conventional methods is not

successful in general, because of many reasons such as fail in presenting a well-structured model to collect, analyze and present the information requirements or fail in understanding the users’ requirements accurately.

Many completed information systems which do not satisfy user requirements and expectations indicate that requirement determination and analysis can be improved [6]. Since requirement determination and analysis occur in early stages of development process, even small improvement is likely to enhance the overall performance of the developed system, therefore, have the capacity to reduce time and cost of the development process dramatically.

In this paper, we investigate a method to support information requirement determination while improving weaknesses of conventional methods. The proposed method first accepts user’s requirements through an online requirement gathering platform. This platform enables stakeholders to write their requirements based on their place in development process. Our proposed method includes four phases as follows:

1) Requirement elicitation, using an online requirementgathering platform.

2) Requirement determining, using a set of part-of-speechtagger.

3) Requirement structuring, storing answers in a well-structured knowledge base.

4) Requirement presentation.

The second phase of the method, Requirement analysis, uses a data mining technique known as part-of-speech (POS) tagging to analyze collected requirements and extract target elements and their dependencies. Target elements are entities that will answer 5W1H questions that have been collected through an online requirement gathering platform. The 5W1H method is a question answering method used to investigate the reason and effect of a relationship in a specific problem. The method includes 5Ws (i.e. who, what, where, when, why) and 1H (how) questions. In order for an answer to be regarded complete it should answer above questions, each of which includes an interrogative aspect of an answer. In the third phase, the method constructs a structured knowledge base to store and evaluate target elements and their dependencies. In the last phase, the method presents answer for a given

This work was supported in part by Research University Grant Scheme PROJECT NUMBER: 05-01-11-1258RU

2013 IEEE 4th Control and System Graduate Research Colloquium, 19 - 20 Aug. 2013, Shah Alam, Malaysia

978-1-4799-0552-2/13/$31.00 ©2013 IEEE 32

information requirement question without missing target elements or their dependencies and finally improves precision of retrieved information by expanding answers to similar possible answers or target elements which improves precision in retrieved answers. The proposed method is unique in that it doesn’t only aim to collect and analyze requirement automatically but also makes a knowledge structure using an interrogatories technique. The method also differs from previous information requirement determination techniques in that it improves effectiveness of results by using POS technique tailored towards data originating from user requirements.

We perform experiments on a real life case study, demonstrating the improvement in effectiveness in terms of correctness and precision of retrieved answers. The rest of this paper is organized as follows: the next section proposes a method and elaborates its phases. In section III, we conduct experiments and report the results. Section IV is dedicated to related works which introduces the problem of conventional requirement determination methods, describes their weaknesses. Finally, last section concludes the paper.

II. REQUIREMENT DETERMINATION AND STRUCTURING METHOD

Given a statement of requirements of the system from the user, the task is to automatically determine and interpret expected behavior of the system. We define the basic notation that we use throughout the paper.

Target element: A target element can be a subject of a process (e.g. user, system component) that has been defined by the user while entering requirements. Also, it can be a category of entities (e.g. actions, responses). Target elements are gathered from user inputs and will be categorized later to form structured knowledge base which stores and evaluates target elements and their dependencies.

The 5W1H method: 5W1H is a popular interrogative method which describes a fact using who, what, where, when, and how questions to comprehend for details about the fact. The method explains a fact depicting an actor (who) is in a specific location (where) at certain time period (when) interacting with a specific action/object (what) while representing process of the action (how) in which should be taken into consideration because of a certain intention (why).

POS tagger: part-of-speech tagger is a system for automatic allocation of parts of speech to each word of a statement. By employing machine learning methods, POS tagger is able to assign tags to each word in order to categorize them.

To address issues related to information requirement determination and analysis, we define four phases for our proposed method as follows:

.

Phase1, Requirement elicitation: In this phase, we provide a platform for users to enter their requirements. We used Java Servlet technology which performs factions on the web server, Mysql database which stores all the data records and analysis information, Apache

Tomcat web server which is an open source web server to implement java Servlet. The technological specification of the system architecture is illustrated in Fig. 1. The system allows the user to enter requirements in text format via web-based user interface.

Fig. 1. System architecture overview

Phase2, Requirement determining: POS tagging: in second phase, we use POS tagger to identify part of speech of each word in a requirement statement gathered in first phase. For tagging method, we use a method based on cyclic dependency network which is proposed by [7]. Using lexical features (e.g. joint dependency on consecutive words) and, preceding and following tags via a cyclic dependency network, this method gives 97.24% accuracy. The method produces a graph in which edges are syntactic dependencies and nodes are each word of the sentence (i.e. requirement statement gathered from pervious phase). However, different word orders of sentences with the same meaning may alter the exact shape of the produced graph. In order to solve this issue, the method uses conditional Markov model to decompose the probability of produced sequence. The task is to find a sequence of tagged words , which finds a maximum for following probability of given observation , , , … , :

),|(),( 1 iiiiwttPwtP −∏= (1)

Where it is i th POS tagging of i th word in the sentence. For example, a requirement statement such as “The operator shall not be allowed to restart the system” will be tokenized as “The_DT operator_NN shall_MD not_RB be_VB allowed_VBN to_TO restart_VB the_DT system_NN” where ‘DT’, ‘NN’, ‘MD’, RB’, ‘VB’ and ‘VBN’ indicates Determiner, Noun (singular or mass), Modal, Adverb, Verb (base form) and Verb (past participle), respectively. Using the tag set introduced in [8], we identify target elements by tags. Since different views in the system requirements have different needs, determining target elements will help us to categorize and define them. Furthermore, by extracting target elements


33

from user requirements, we are able to define and add descriptive information for each one of them. 5W1H classification: after tokenizing the requirement statement, we identify 5W1H elements and add attribute description for target elements and their features, as illustrated in Fig. 2. Attribute description provides structured information about aspects of the target elements or their relationship with each other (metadata). ‘Who’ question asks about identification of user or system in a requirement statement and is a basic actor of a desired function. ‘Where’ describes location information about the user. The location illustrates available functions for each user since every function has its own location when it interacts with the user. ‘When’ provides information about time of availability of a function. ‘What’ represents information related to an object or function which the user is interested in. ‘Why’ indicates intention of the user, Although the basic role of this question is not to be identifying full mentality about a function but to represent a possible answer for intention behind a performed action. And finally ‘How’ question provides information about the user behaviors. Answer to those questions can be found in requirement statement. Since different expression of a requirement has different POS pattern, we focused on assigning target elements to each one of 5W1H questions based on described answers.

Phase3, Requirement structuring: Software requirements usually include opinions, perspectives and relations at different level of viewpoints. This section organizes domain requirements by representing a hierarchical structure that includes target elements in each level. In order to classify target elements based on 5W1H, we use rules to find corresponding elements or phrases in requirement statement. We classify preposition phrases by assigning POS tagged words to 5W1H phrases: subject/actor (who), location variables (where), time (when), Verbs and verb phrases (how/why). Since classifying parts of speech is a difficult task [9] and we do not focus on this part in our study, we used expert’s opinion to verify and select types of rules manually. For example, one of the rules indicates that if there is a subject at the beginning of the requirement sentence and it has a dependency to a verb, subject/noun could be the actor of the corresponding action. Other rules for the rest of 5W1H phrases can be identified by similar manners. Figure 3 illustrates an example of requirement structuring. The hierarchical structure of requirement domains includes function dependencies and relation between them. Such a structure of requirements allows analysts to explore requirements from different viewpoints (i.e. stakeholders, concerns, services, etc).

Fig. 2. Four phases of the method


34

Requirement structuring can be derived from assigning target elements in one of the 5W1H layers, as shown in Table I. The scope of the requirement structuring includes both functional and nonfunctional system requirements and relationship between them. Phase4, Presentation of requirements: Requirements structuring in conventional document-based methods is accomplished with proprietary templates and other similar methods. In contrast, our proposed method facilitates the usage of standard ontology schema languages to make a more formal and meaningful structure. We store information related to each target element and their dependencies on database. This allows consistency check for each element and makes a standard instance of knowledgebase.

Fig. 3. An example of requirement structuring. “user should be able to create reports about financial transactions located at user p age every 30 minutes”.

III. EXPERIMENTAL RESULTS The main tasks that influence the proposed method’s

effectiveness are requirement statement analysis and requirement determination. We notice that analysis performance can be measured by running experiments on the proposed method and observing user interactions with it. The main propose of conducting the experiment on our proposed method is to see whether it generates precise answer for a given requirement statement. By running tests on the tool made by our proposed method and gathering expert’s feedbacks on the generated results, we are able to validate the method. In this study, we focus more on objective of the method to determine the discern ability of the generated results, although we consider other subjective requirements such as usability of the tool.

The experiment: Since there is no automatic method to evaluate, to assess accuracy of the produced results we performed tests on proposed method, as described in section II. We used a dataset that have been made publicly available by the authors of [10]. The dataset includes 20 high level and 50 low level requirements. In this experiment, we assumed that correct information about the generated result can be found among expert’s feedback. Later we categorize both true links and false positives among feedbacks. At the beginning of the experiment, a requirement was loaded into the tool and answer was generated. For each answer, we used four different experts to judge the results. If the answer was found satisfying, it was marked as correct, otherwise false. We used two measurement to compare the experiment results: Recall, i.e., the number of correct discovered errors in generated answer divided by the number of all errors, Precision, i.e., the number of correct discovered errors divided by the number of discovered errors. Table II outlines the results of the experiment. We defined 5 types of factor and each one of them is placed on table with recall and precision measurements. We noticed that most of the recall metrics have high values which indicate most of the generated results for each 5W1H classification were correctly arranged. However, from precision perspective, results are not satisfying except for Adequacy which means some of the generated results do not fit into suggested arrangements. The worst result belongs to irrelevant factor in precision measurement. We assume this is because the defined rules for classification of the target elements could be inconsistence with requirement domain used in this excrement. The classification only checks target elements and their dependencies based on defined rules. If rules are not made for requirement domain, experts have to determine correct place for generated results manually. The other explanation could be that some parts in requirement statements might be double entendre. The correctness of these explanations could be considered as future research topics. In conclusion, the experiment results indicate that our proposed method has effectively detected and classified requirements.

TABLE I COLLAPSED CC-PROCESSED DEPENDENCIES

Dependencies Collapsed dependencies

root ROOT-0 , able-5

det user-2 , The-1

nsubj able-5 , user-2

aux able-5 , should-3

cop able-5 , be-4

aux create-7 , to-6

xcomp able-5 , create-7

dobj create-7 , reports-8

amod transactions-11 , financial-10

prep_about create-7 , transactions-11

partmod transactions-11 , located-12

nn age-16 , user-14

nn age-16 , p-15

prep_at age-16 , p-15

det minutes-19 , every-17

num minutes-19 , 30-18

tmod located-12 , minutes-19


35

TABLE II. TABLE TYPE STYLES

Recall Precision

Adequacy 1.0 0.44

consistency 1.0 1.0

transparency 0.85 0.80

relevancy 0.83 0.77

redundancy 0.66 0.66

IV. RELATED WORKS Until early 90s, software analysis, design and development

process depicted by the waterfall model had been very popular discipline among software engineers. This model originates in manufacturing industry which observes software development processes as a flow of activities. This approach organizes and manages different activities through the development processes [11]. However, this approach encourages software engineers to deal with the whole system at each step in flowing order: requirement specification, design, implementation and maintenance. The system verification of the requirements is not possible in any other steps [12]. Later, formal methods became popular for better understanding the system requirement. Theories such as verification, composition and specification have helped software engineers to improve the quality of developed system. Nevertheless, formal methods in requirement specification have inherited the same defects from the former model by implementing formal techniques on existing methods. This is the main reason why they are widely accepted in software development [13].

Object oriented requirement specification is another approach in the software development. UML is a standard modeling language which uses object oriented approach. In this method modeling diagrams are used to illustrate the system from different points of view at various levels of abstraction. This however raises the question of whether these model diagrams are consistence with each other. A unified framework of formal specification for conditions of relationship and consistency of the UML diagrams has been suggested by [14]. This study indicates formal methods suggested in [14] can be applied in the development of large systems if features of different model diagrams be identified by their framework. However, this study has focused on conceptual aspects of object oriented requirement specifications and doesn’t include requirement determination and validation.

Several recent studies have focused on the enterprise knowledge as a semantic tool for requirement determination and structure [15], [16] and [17]. In these studies semantic domain was used as domain requirements meta-model to describe requirement specification. Semantic domain describes how meaning is allocated in requirement specification. Nonetheless, the semantic domain presented in these studies only concentrated on static representation of domain information (e.g. entities and their relationship), which not only lacks understanding of real-life system but also limits their usage to simulated models. In most of information systems,

system requirements relationships are complex so mentioned methods are not able to provide coherent and complete description of system requirements.

V. CONCLUSION In this paper we proposed a method to automatically

determine and structure software requirements. Our proposed method contains 4 phases as follows: requirement gathering, requirement determination, requirement structuring and finally presentation of requirements. The method uses a POS tagging technique specially tailored for extracting words and their dependencies from requirement statements. By adopting 5W1H method on produced dependency graph, the method classifies parts of the requirement statements. Experiment on a dataset of 70 requirements indicates the effectiveness of the proposed method which supports our claim.

REFERENCES [1] O. Dieste and N. Juristo, "Systematic review and aggregation of

empirical studies on elicitation techniques," Software Engineering, IEEE Transactions on, vol. 37, pp. 283-304, 2011.

[2] M. Berkovich, J. Leimeister, and H. Krcmar, "Requirements Engineering for Product Service Systems," Business & Information Systems Engineering, vol. 3, pp. 369-380, 2011/12/01 2011.

[3] A. Al-Badareen, M. Selamat, M. Jabar, J. Din, and S. Turaev, "An Evaluation Model for Software Reuse Processes," in Software Engineering and Computer Systems. vol. 181, J. Zain, W. Wan Mohd, and E. El-Qawasmeh, Eds., ed: Springer Berlin Heidelberg, 2011, pp. 586-599.

[4] S. España, N. Condori-Fernandez, A. González, and Ó. Pastor, "An empirical comparative evaluation of requirements engineering methods," Journal of the Brazilian Computer Society, vol. 16, pp. 3-19, 2010/05/01 2010.

[5] K. Siau and M. Rossi, "Evaluation techniques for systems analysis and design modelling methods – a review and comparative analysis," Information Systems Journal, vol. 21, pp. 249-268, 2011.

[6] C. Barclay and K.-M. Osei-Bryson, "Project performance development framework: An approach for developing performance criteria & measures for information systems (IS) projects," International Journal of Production Economics, vol. 124, pp. 272-292, 2010.

[7] K. Toutanova, D. Klein, C. D. Manning, and Y. Singer, "Feature-rich part-of-speech tagging with a cyclic dependency network," presented at the Proceedings of the 2003 Conference of the North American Chapter of the Association for Computational Linguistics on Human Language Technology - Volume 1, Edmonton, Canada, 2003.

[8] M. P. Marcus, M. A. Marcinkiewicz, and B. Santorini, "Building a large annotated corpus of English: the penn treebank," Comput. Linguist. vol. 19, pp. 313-330, 1993.

[9] J. H. Hayes, A. Dekhtyar, and S. Sundaram, "Text mining for software engineering: how analyst feedback impacts final results," SIGSOFT Softw. Eng. Notes, vol. 30, pp. 1-5, 2005.

[10] A. Lucia, A. Marcus, R. Oliveto, and D. Poshyvanyk, "Information Retrieval Methods for Automated Traceability


36

Recovery," in Software and Systems Traceability, J. Cleland-Huang, O. Gotel, and A. Zisman, Eds., ed: Springer London, 2012, pp. 71-98.

[11] J. Li and A. Eberlein, "An analysis of the history of classical software development and agile development," in Systems, Man and Cybernetics, 2009. SMC 2009. IEEE International Conference on, 2009, pp. 3733-3738.

[12] B. V. Thummadi, O. Shiv, and K. Lyytinen, "Enacted Routines in Agile and Waterfall Processes," in Agile Conference (AGILE), 2011, 2011, pp. 67-76.

[13] J. Woodcock, P. G. Larsen, J. Bicarregui, and J. Fitzgerald, "Formal methods: Practice and experience," ACM Comput. Surv., vol. 41, pp. 1-36, 2009.

[14] P. Bera and J. Evermann, "Guidelines for using UML association classes and their effect on domain understanding in

requirements engineering," Requirements Engineering, pp. 1-18, 2012/07/01 2012.

[15] V. Uren, P. Cimiano, J. Iria, S. Handschuh, M. Vargas-Vera, E. Motta, et al., "Semantic annotation for knowledge management: Requirements and a survey of the state of the art," Web Semantics: Science, Services and Agents on the World Wide Web, vol. 4, pp. 14-28, 2006.

[16] D. Dang Viet and A. Ohnishi, "A Verification Method of Elicited Software Requirements Using Requirements Ontology," in Software Engineering Conference (APSEC), 2012 19th Asia-Pacific, 2012, pp. 553-558.

[17] H. Kaiya and M. Saeki, "Using Domain Ontology as Domain Knowledge for Requirements Elicitation," in Requirements Engineering, 14th IEEE International Conference, 2006, pp. 189-198.


37

[ieee 2013 ieee 4th control and system graduate research colloquium (icsgrc) - shah alam, malaysia...

Documents