Hanan Hamed Elazhary / International Journal of Engineering Science and Technology Vol. 2(5), 2010, 957-961
REAS: An Interactive Semi-Automated System for Software Requirements Elicitation Assistance Hanan Hamed Elazhary* Electronics Research Institute, Cairo, Egypt
[email protected] ABSTRACT Faulty requirements specifications lead to developing a faulty software system. This may require repeating the whole software engineering cycle wasting time and money. This paper presents an interactive semi-automated system that is a compromise between two approaches. The first tries to avoid the introduction of imprecision while the software requirements are being written. The other attempts to detect and possibly correct many types of imprecision after the software requirements are written. This is achieved by imposing the use of a good writing style and by interactively emulating a conversation between the requirements engineer and the user. This helps free the requirements engineer from such a systematic task, helps in processing many ill-structured statements, and helps maintain consistency in the used terminology. Explanations produced by the system helps in detecting and correcting any missed imprecision. The proposed techniques are easy enough to be used by non-technical stakeholders in different domains.
Keywords Interactive information elicitation, user requirements elicitation, automated requirements elicitation, requirements engineering, software engineering.
1. Introduction Software requirements engineering is concerned with understanding and specifying the services and constraints of a given software system. It involves software requirements elicitation and specification [1]. Elicitation of software requirements from stakeholders typically results in user requirements, which are natural language statements that describe the high-level goals of a given software system [2]. Analysis of natural language user requirements is an important activity since imprecision in this stage causes errors in later stages. Imprecision [3] results not only due to syntax errors, but also due to the ambiguity of natural languages used to express the user requirements and the lack of consistency and/or completeness in the software requirements. Requirements imprecision is at least an order of magnitude more expensive to correct when undetected until late software engineering stages [4]. Thus, focusing on improving the precision of the elicited user requirements in the first cycle is one of the ambitious aims of software engineering [5]. Analyzing unrestricted natural language user requirements is mainly a manual task carried out by the software requirements engineer [6-11]. Since software requirements are usually written in hundreds of pages that need weeks or months to be examined, manual analysis takes a very long time and the probability of human error is very high. Consequently, using automated tools for this task would be of a great help. Lami [12] and Hussain et al. [13] developed systems that can automatically detect potential imprecision in natural language software requirements through indicators such as weak verbs. But, these systems don’t assist in correcting any imprecision. Thus, another approach in the literature attempts to avoid the introduction of imprecision while the software requirements are being written by imposing the use of natural language patterns. Most research studies in the literature have focused on developing such natural language patterns for specific
ISSN: 0975-5462
957
Hanan Hamed Elazhary / International Journal of Engineering Science and Technology Vol. 2(5), 2010, 957-961
domains such as database systems [14], scenarios [15], and embedded systems [3]. But, Jain et al. [16] developed the general-purpose RAT system that imposes the use of specific natural language patterns that help users adhere to best practices in writing software requirements in different situations. But, unfortunately, it is very hard for nontechnical stakeholders to stick to the suitable pattern in each situation. For the sake of consistency, the system requires predefining all the used terms in a glossary, which is impractical. Thus, our main concern was to develop a system that integrates these two approaches intelligently to exploit their advantages and avoid their disadvantages. In an attempt to achieve this goal, we developed the semi-automated software Requirements Elicitation Assistance System (REAS) discussed in the rest of the paper. The paper is organized as follows: Section 2 describes the operation of REAS. Section 3 provides the results and discussion. Finally, Section 4 provides the conclusions and directions for future research.
2. REAS REAS is a general-purpose system that attempts to avoid many causes of imprecision while the software requirements are being written and to help users adhere to best practices in writing software requirements [16]. But instead of imposing the use of specific natural language patterns, the idea of REAS is to impose the use of a specific writing style. This is achieved by enforcing a set of rules that are easy enough to be followed by non-technical stakeholders. REAS also interactively detects and helps correct many causes of imprecision such as syntax errors and ambiguities quickly and easily. Besides, it builds a glossary of terms incrementally to help ensure consistency in the used terminology. Finally, REAS produces explanations that can be easily inspected by the software engineer for detecting and correcting any missed imprecision. The block diagram of REAS is shown in Figure 1. It is formed of four main modules: the spelling checker, the rule imposer, the lexical analyzer, and the parser. These are described below.
Input statement
Modified statement
Spelling Checker
Spell-checked statement
Lexical Analyze
Classified Tokens
Rule Imposer
Parser
Output statement and explanations
Figure 1: Block diagram of REAS 2.1. The Spelling Checker As the name implies, the function of the spelling checker is to spell-check the words of the input statement by referring to a dictionary. If a word in not in the dictionary or is unnecessarily capitalized, the user is prompted to correct it and/or add it to the dictionary. In future versions of REAS, we intend to extend the spelling checker to be able to produce a list of suggestions for the user to select from. The spell-checked statement then enters the rule imposer. 2.2. The Rule Imposer The rule imposer enforces two simple rules and a set of warnings to help users adhere to the required writing style. In future versions, the warnings will be provided as enforced rules or will be omitted to increase the flexibility of REAS:
ISSN: 0975-5462
958
Hanan Hamed Elazhary / International Journal of Engineering Science and Technology Vol. 2(5), 2010, 957-961
Rule 1: Write short active declarative statements. This rule increases the probability of having a simple statement that can be quickly and easily processed. Generally, a short statement should include no more than 25 words [17]. In case the rule is violated, the user is prompted to shorten the statement or decompose it into two or more short statements. The rule also imposes writing active statements since with passive statements, it is not clear who or what is doing the action. The rule imposer can detect a passive case by detecting any combination of verb to be plus a past participle verb. In case this is violated, the user is prompted to rewrite the statement. Additionally, imperative (command or request), interrogative (question), and exclamatory (surprise or strong feelings) statements are not allowed since these types of statements are unnecessary in software requirements documents. For the same reason, in the current version of REAS, the rule imposer does not attempt to detect the violation of this. This will be handled in future versions. Rule 2: Do not use pronouns, possessive pronouns, or possessive adjectives. This rule tries to avoid referential ambiguity [6], [8] and the implicity problem [12] since it is not clear what these words refer to. Whenever such a word is detected, the user is prompted to replace it. Warning 1: Apostrophes should be used only to indicate possession. This warning tries to avoid the ambiguity that my result from the use of apostrophes. This is important since Rule 2 prevents the use of possessive pronouns and possessive adjectives. Whenever an apostrophe is detected, the user is warned that it will be interpreted as indicating possession. Warning 2: The words "and" and "or" are considered conjunctions and the word "not" is considered a descriptor (adverb). This tries to avoid the ambiguity that my result from the use of these words as logical operators. Whenever such a word is detected, the user is warned that it will be interpreted accordingly. The use of these words as logical operators will be handled in future versions of REAS. Warning 3: Words such as "on", "in", and "of" will be interpreted as prepositions. This tries to avoid the unusual use of these words. Whenever such a word is detected, the user is warned that it will be interpreted accordingly. Other interpretations of such words will be handled in future versions of REAS. Warning 4: Articles, demonstratives, apostrophes, or subordinate conjunctions should be followed by an item or descriptors and an item. This warning tries to avoid the use of these words in such a way that causes imprecision in the statement. For example, the word "this" can be used as an adverb as in the statement: “Don’t expect to wait this long”. It can be also used as a pronoun as in the statement: “This is good”. The word "this" in both statements need further explanation and so preventing such cases is an advantage. Violation of this rule is handled by the lexical analyzer. Warning 5: Always write statements formed of one clause only. In case of constraints, you can write statements formed of two clauses using subordinate conjunctions (When … ,) and (If … then). Other types of statements such as these formed of several clauses will be handled in future versions of REAS. This is why the rule imposer does not attempt to detect the violation of this warning. If any problem is detected by the rule imposer, the user is prompted to modify the input statement. The modified statement reenters the spelling checker and the rule imposer. This continues until both modules detect no further problems. The modified statement then enters the lexical analyzer. 2.3. The Lexical Analyzer The lexical analyzer and the parser try to emulate a conversation between the requirements engineer and the user in an attempt to detect and help correct many causes of imprecision such as syntax errors and ambiguities in each inspected statement quickly and easily. The goal of the lexical analyzer is to consult a dictionary to generate a set of classified tokens such as items, verbs, descriptors, conjunctions, etc. An item is any noun while a descriptor, on the other hand, is an adjective or an adverb. In case of more than one possibility, the following rules apply: Rule 3: Words followed by an apostrophe are items. Warning 1 dictates this. Violation of this rule is reported as an error in the inspected statement. Rule 4: Articles, demonstratives, apostrophes, prepositions (except “to”), or subordinate conjunctions are followed by an item or descriptors and an item. Warning 4 dictates this. If no item is detected following any of these words, an error in the inspected statement is reported. Rule 5: In case of any confusion, the user should be consulted. Because users are not always capable to differentiate between adverbs and adjectives, they are termed "descriptors". Rule 6: Each item is given a code.
ISSN: 0975-5462
959
Hanan Hamed Elazhary / International Journal of Engineering Science and Technology Vol. 2(5), 2010, 957-961
2.4. The Parser The classified tokens generated by the lexical analyzer are passed to the parser, which provides the user with lists of options to make selections to help resolve many causes of imprecision quickly and easily. The options are produced by applying the following set of rules: Rule 7: Actions are formed of combinations of verb (such as “can play”). Rule 8: Descriptors can describe other descriptors, items, verbs, or actions. For example, suppose that there is a descriptor "happy", an action "plays", and an item "boy". This descriptor can be associated with the action forming "plays happily" or with the item forming "happy boy". Rule 9: Apostrophes link the preceding item with another following item. Rule 10: Prepositional phrases are formed of prepositions plus following items or descriptors and items except "to" that may be followed by a simple verb form. Rule 11: Prepositional phrases act as descriptors except to its items. Rule 12: verbs and actions can be standalone or have following items or descriptors as their objects (where applicable). Rule 13: An item can perform any following verb or action. Rule 1 dictates this. Rule 14: Two options associated with the same term are separated by the conjunction in the statement between brackets. For example, consider the statement: He has a book and a pen. The words "book" and "pen" are both objects of the verb "has". This can be expressed as follows: “has (book and pen)”. Rule 15: In case of constraints, each clause should be handled separately and should be preceded by its subordinate conjunction. It is worth noting that we try many combinations to be able to deal with ill-structured statements. The user selections are produced as explanations that can be easily inspected by the software engineer for detecting and correcting any missed imprecision. REAS builds a glossary of terms incrementally. It is worth noting that while statements are being written, the user is allowed to select words from the glossary menu. This helps in maintaining consistency in the used terminology and in avoiding future requirements-document ambiguity or domain ambiguity [6], [8]. At the end, the user is prompted to provide a definition for each item in the glossary with its descriptors, verbs, and actions. Codes given to each item according to Rule 6 help ensure that no item is ever missed. 3. Results and Discussion REAS was used to process many input statements in real requirement documents. It was successful in dealing with many imprecision problems reported in the literature. For example, the statement “If it is not valid then the ATM rejects the card” [6] suffers from referential ambiguity [6, 8] and the implicity problem [12] since several interpretations are possible for the pronoun "it". Imposing Rule 2 enforces the user to replace this pronoun resolving this problem. The statement “The customer enters a card and a numeric personal code” [6] suffers from the multiplicity problem [12] since there are multiple objects for the word "enter" suggesting that there are multiple requirements. Also, the statement “The product shall show the weather for four hours” [6, 8] suffers from syntactic ambiguity [6, 8] since the phrase "for four hours" can be attached to the verb "show" or the noun "weather". These types of ambiguities are automatically easily and quickly resolved by consulting the user through the emulated conversation. The statement “When the pressurizer's pressure falls below a low threshold, the system sends the safety injection signal” [6] suffers from the vagueness problem [6, 8, 12] since a continuum of interpretations is available for the word "low". Also, the word “sends” is an example of action ambiguity [6, 8] since it is not clear whether this is also an exit condition or not. The statement “When the user presses the L- and R-button, the system stops the alarm” [6, 8] suffers from volatile-persistent ambiguity [6, 8]. This is because the word "alarm" refers to a volatile alarm sounded by the system or to the persistent general ability of the system to raise alarms. The statement “The system is a means for the protection of a small group of human beings from the hostile elements of their environment” [6] suffers from vagueness [6, 8, 12] since a continuum of interpretations is available for the word “small”. For the same reason, the word "hostile" is an example of generality [6, 8]. All these types of ambiguities could be easily resolved since the user is prompted to provide definition for each item in the glossary and its descriptors. Codes given to each item help ensure that no item is ever missed.
ISSN: 0975-5462
960
Hanan Hamed Elazhary / International Journal of Engineering Science and Technology Vol. 2(5), 2010, 957-961
4. Conclusions and Future Research This paper discussed the first version of the proposed semi-automated software requirements elicitation assistance system (REAS) that is a compromise between detection and correction of imprecision while and after the natural language software requirements are written. The system has proved to be successful in quickly and easily resolving many types of imprecision in the syntax and ambiguities. It also helps in maintaining consistency in the used terminology and produces explanations that can be easily inspected by the software engineer for detecting and correcting any missed imprecision. As a future work, the system should be extended to be more flexible by reducing rules and warnings and to handle other types of imprecision. 5. References [1] I. Sommerville. 2006. Software Engineering. Addison Wesley, 8, 2006. [2] A. Lamsweerde, R. Darimont, and E. Letier. 1998. Managing Conflicts in Goal-Driven Requirements Engineering. IEEE Transactions on Software Engineering, 24(11):908-926, 1998. [3] C. Denger, D. Berry, and E. Kamsties. 2003. Higher Quality Requirements Specifications through Natural Language Patterns. IEEE SwSTE'03, 2003. [4] S. Schach. 2006. Object-Oriented and Classical Software Engineering. McGraw-Hill, 7, 2006. [5] C. Rupp. 2002. Requirements and Psychology. IEEE Software, 19(3):16-18, 2002. [6] E. Kamsties and B. Paech. 2000. Taming Ambiguity in Natural Language Requirements. The 13th International Conference on Software & Systems Engineering and Their Applications, 2000. [7] V. Gervasi and B. Nuseibeh. 2000. Lightweight validation of Natural Language Requirements: A Case Study. The 4th International Conference on Requirements Engineering, 2000. [8] E. Kamsties, D. Berry, and B. Paech. 2001. Detecting Ambiguities in Requirements Documents Using Inspections. The 1st Workshop on Inspection in Software Engineering, 2001. [9] A. Fantechi, G. Gnesi, G. Lami, and A. Maccari. 2003. Application of Linguistic Techniques for Use Case Analysis. Requirements Engineering, 8(3):161-180, 2003. [10] N. Kiyavitskaya, N. Zeni, L. Mich, and D. Berry. 2008. Requirements for Tools for Ambiguity Identification and Measurement in Natural Language Requirements Specifications. Requirements Engineering, 13(3):207–239, 2008. [11] A. van Lamsweerde. 2009. Requirements Engineering from System Goals to UML Models to Software Specifications. Wiley, 2009. [12] G. Lami. 2005. QuARS: A Tool for Analyzing Requirements. Technical Report CMU/SEI-2005-TR-014, Carnegie Mellon Software Engineering Institute, PA, USA, 2005. [13] I. Hussain, O. Ormandjieva, and L. Kosseim. 2007. Automatic Quality Assessment of SRS Text by Means of a Decision-Tree-Based Text Classifier. The 7th International Conference on Quality Software, 2007. [14] A. Ohnishi. Software Requirements Specification Database Based on Requirements Frame Model. 1996. The 2nd International Conference on Requirements Engineering, 1996. [15] C. Ben Achour. 1998. Guiding Scenario Authoring. The 8th European-Japanese Conference on Information Modeling and Knowledge Bases, 1998. [16] P. Jain, K. Vema, A. Kass, and R. Vasquez. 2009. Automated Review of Natural Language Requirements Documents: Generating Useful Warnings with User-extensible Glossaries Driving a Simple State Machine. The 2nd India Software Engineering Conference, 2009. [17] P. Hoyt. 2002. Information Technology's Writing Survival Guide. A Technical Writing Primer for the Systems Professional. White Feather Press, 2002.
ISSN: 0975-5462
961
