home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr6 / proceedings / ascii / park2.ascii < prev    next >
Text File  |  1993-10-19  |  13KB  |  355 lines
  1.  
  2.  
  3.  
  4.  
  5.                         Software  Requirement  Text  Reuse
  6.  
  7.  
  8.  
  9.                                                Sooyong Park
  10.  
  11.  
  12.  
  13.                             Center for Software Systems Engineering
  14.  
  15.                                        George Mason University
  16.  
  17.                                          4400 University Drive
  18.  
  19.                                          Fairfax, VA 22030-444
  20.  
  21.  
  22.  
  23.                                            Tel:  (703) 993-3684
  24.  
  25.                                           Fax: (703) 993-1521
  26.  
  27.                                   Email:  spark@mason1.gmu.edu
  28.  
  29.  
  30.  
  31.                                                   Abstract
  32.  
  33.  
  34.     Reuse is widely recognized as a solution to improving software productivity,  quality and
  35. reliability. While there has been much research on code and design reuse, there has been little
  36. research effort extended in the requirement reuse. However, among the software development
  37. phases, requirements analysis is one of the most important and least supported phase of the
  38. software development process. The requirement reuse is proposed to increase productivity and
  39. quality of requirement analysis phase.
  40.     We focus on requirement text reuse research since requirements are, inmost case, expressed
  41. in natural language.  We use conceptual and numerical clustering techniques to build reusable
  42. requirement components. Automatic indexing techniques are applied to classify the components.
  43. The architecture of a requirement reuse support system and the contributions of this research
  44. are included in the conclusion.
  45.  
  46.  
  47. Keywords:  Software Reuse,  Requirement Reuse, Text Reuse, Requirement Engineering, Re-
  48. quirement Clustering and Indexing
  49.  
  50.  
  51. Workshop Goals: Exchanging idea of current research issues
  52.  
  53.  
  54. Working Groups: Domain Analysis/engineering, Reuse and OO Method
  55.  
  56.  
  57.  
  58.                                                    Park- 1
  59.  
  60.  
  61. 1      Background
  62.  
  63.  
  64.  
  65. The George Mason University (GMU)Center for Software Systems Engineering (CSSE) researchin
  66. systems and software requirement engineering is directed to improve and promote the development
  67. of requirements that reflect the needs of the user. The framework for this research is an Advanced
  68. Integrated  Requirement  Engineering  System  (AIRES).  AIRES  includes  requirement  assessment,
  69. prototyping, transformation and reuse.  AIRES processes the requirements as a natural language
  70. text.
  71.  
  72.  
  73. The requirement reuse project was initiated by the observation that, even though there are many
  74. common requirements, we do not haveany method to reuse.  In development of complex software
  75. system, eliciting  and  analyzing  the  system  requirements  has  been  a  serious  problem.  In  many
  76. cases, erroneous requirements produced a wrong product[1].  One way to alleviate that problem
  77. is to reuse requirements from an already-developed system. The reused requirement can be used
  78. as an example so that it can be a solution of the well knownproblem "users often do not know
  79. what they want".  For example, in development of an Automatic Gas Station(AGS), users knew
  80. that they needed a security system but, in many cases, they did not know what sp ecific security
  81. they wanted. If we had security requirements in an Automatic Teller Machine (ATM) system, the
  82. security requirements of ATM system could be a good example in AGS system.
  83.  
  84.  
  85.  
  86. 2      Approach
  87.  
  88.  
  89.  
  90. Since we are dealing with natural language requirement, it is very to abstract or parameterize the
  91. natural language requirement automatically.  But our purpose in requirement reuse is to provide
  92. requirement  examples.  Therefore,  parameterization or  abstraction  of  natural  language  require-
  93. ment are not necessary. The issue is how to cluster the requirement sentences to build reusable
  94. requirement components. For example, a requirement about security can appear through out the
  95. requirement document. Extraction of these requirements is a key to building reusable requirement
  96. components.
  97.  
  98.  
  99. Our approach to requirement text reuse has two phases - the requirement component extraction
  100. phase, and the classification and retrieval phase.
  101.  
  102.  
  103.  
  104. 2.1     Requirement Reuse Process
  105.  
  106.  
  107.  
  108. The requirement reuse process consists of four steps. These are;
  109.  
  110.  
  111.  
  112. STEP 1:       Text Analysis
  113.  
  114.  
  115. STEP 2:       Component Extraction
  116.  
  117.  
  118. STEP 3:       Component Classification
  119.  
  120.  
  121. STEP 4:       Retrieval
  122.  
  123.  
  124.  
  125. The step 1 is to identify requirement concepts. We userequirement concepts for objects, functions,
  126. and  quality  goals  of  the  system  requirements.   Based  on  the  requirement  concepts,  clustering  is
  127.  
  128.  
  129.  
  130.                                                           Park- 2
  131.  
  132.  
  133. performed  to  create  reusable  components.  The  reusable  components  are  indexed  by  automatic
  134. indexing techniques. Following subsections discuss each processing step in detail.
  135.  
  136.  
  137.  
  138. 2.2     Text Analysis
  139.  
  140.  
  141.  
  142. The  purpose  of  this  process  is  to  develop  the  rules  and  algorithms  to identify  the  requirement
  143. concepts automatically. In the identification of requirement concepts, there are two approaches;
  144.  
  145.  
  146.  
  147.     1. Using extensive domain knowledge and reasoning process. - This is an AI approach.
  148.  
  149.  
  150.     2. Using lexical analysis and syntactic pattern analysis.
  151.  
  152.  
  153.  
  154. We adopted the second approach since it is typically more practical and also domain independent.
  155. The object and function concepts can be identified by syntactic patternanalysis and noun and verb
  156. classification. The identification of quality goals use of a quality goal table, thesaurus analysis, and
  157. syntactic pattern analysis.
  158.  
  159.  
  160.  
  161. 2.3     Reusable Component Extraction
  162.  
  163.  
  164.  
  165. Reusable component extraction is performed by clustering requirement with respect to identified
  166. requirement concepts.  We use both numerical clustering and conceptual clustering.  >From these
  167. two clustering techniques, we can extract requirements that relate to each identified requirement
  168. concept. The extracted requirements are body of reusable requirement component with respect to
  169. the requirement concept.
  170.  
  171.  
  172.  
  173. 2.4     Component Classification and Retrieval
  174.  
  175.  
  176.  
  177. This process is based on automatic text indexing techniques which have been established in informa-
  178. tion retrieval area[2, 3 , 4 ]. The main technique is extracting lexical affinities from the requirement
  179. component. The observation of lexical affinities in large textual document has been shown to convey
  180. information on both syntactic and semantic levelsand provides us with a powerful way of taking
  181. context into account[5]. Lexical affinities will serve as indices of the component.
  182.  
  183.  
  184.  
  185. 3      Related Work
  186.  
  187.  
  188.  
  189. There is no known directly related work, but the research is related to two other areas of research;
  190.  
  191.  
  192.  
  193.     fflInformal requirement specification process by linguistic analysis[6, 7 , 8 ].
  194.  
  195.  
  196.     fflSpecification reuse by analogy[9 , 10 ]
  197.  
  198.  
  199.  
  200. Since we are focusing on reuse in this paper, we will discuss the seconditem.
  201.  
  202.  
  203. Maiden  and  Sutcliffe[9]  proposed  to  reuse  domain  abstractions  by  analogy  analysis.  From  the
  204. description  of  the  system, they  try  to  find  the  similarities  among  the  already  prepared  domain
  205.  
  206.  
  207.                                                           Park- 3
  208.  
  209.  
  210. abstractions.  The  system  shows  the  domain  abstractions  with  analogical  mapping  between  the
  211. retrieved  domain  abstract  and  the  target  system  domain.   They  reported  that  it  was  useful  for
  212. novice  software  engineers  in  analyzing  the  problem  domain  since  domain  abstractions  can  be  a
  213. good example.
  214.  
  215.  
  216. The problem is that preparation and representation of domainabstractions is a non-trivial task.
  217. Also, there is no guidelines for domain abstraction. Tofind an analogy, the system need to be spec-
  218. ified or understanding of the abstract requirements is need. This means the software engineer need
  219. to understand the abstract requirement to reuse abstract requirement which can be contradiction.
  220.  
  221.  
  222. Miriyala and Harandi[10 ] proposed specification derivation from the existing specification by anal-
  223. ogy. The general concept is similar to that of Maiden and Sutcliffe but they found the similarity
  224. in the specification structure instead of in the domain abstraction. They view the system as a tree
  225. structure. By the similarities in edges and nodes, they retrieve the specifications. To be processed
  226. by analogy reasoning, all the system specification need to b e represented as structured diagram like
  227. tree structure.  The target system needs to be represented in the same way. The problem is that
  228. there is no unique system structure for a problem domain. In other words, the system structure
  229. can be represented in different tree structures depending on the perspective.
  230.  
  231.  
  232. In general, the analogy approach in specification sounds reasonable since we can only reuse when
  233. there are similarities. However, these approaches need a lot of domain knowledge. Preparation of
  234. that domain knowledge can be as difficult as requirement analysis.
  235.  
  236.  
  237.  
  238. 4      Conclusion
  239.  
  240.  
  241.  
  242. Based  on  discussed  requirement  reuse  process, we  are  developing  a  supporting  tool  called  the
  243. Requirement Reuse System (Re2S). The general architecture of Re2S  is shown in figure 1.
  244.  
  245.  
  246.  Component Extractor                Repository                     Component Finder
  247. _________________________        __________________________         __________
  248.  
  249.    ___________________                 ________________
  250.                                           Index
  251.      Text Analyzer                        Builder                    Retrie-
  252.                                                                      val
  253.    ____________________ __________-    ________________ _ oe________-
  254.    ____________________?           _______________________6_?        Proces-
  255.  
  256.                                                                      sor
  257.        Clusterer                     Component
  258.                                      Base
  259.    ___________________ _
  260.  
  261.                                    ________________________
  262. __________________________       ___________________________        ___________
  263.  
  264.  
  265.  
  266.   Figure 1 General Architecture of Requirement Reuse System
  267.  
  268.  
  269. The contribution of this research includes
  270.  
  271.  
  272.  
  273.     1. Increased productivity by reducing the risk and effort needed to develop requirements.
  274.  
  275.  
  276.     2. Increased  reuse  effect  by  improved  cross-referencing  of  requirement  comp onent  to  design,
  277.        code, and test segment.
  278.  
  279.  
  280.  
  281.                                                           Park- 4
  282.  
  283.  
  284.     3. Text reuse method can be applied to various software documentation reuse.
  285.  
  286.  
  287.  
  288. Besides implementation of Re2S, the future research will include an empirical study of requirement
  289. elicitation and analysis by reuse, andstudy of traceability between reusable requirement and design
  290. components.
  291.  
  292.  
  293.  
  294. References
  295.  
  296.  
  297.  
  298.   [1] A. Davis,  Software  Requirements  Analysis  and  Specification.  Englewood  Cliffs, New  Jersey
  299.       07632: Prentice Hall, 1990.
  300.  
  301.  
  302.   [2] Y. Maarek, D. Berry, and G. Kaiser, "An in formation retrieval approach for automatically
  303.       constructing software libraries,"IEEE Trans. on Software Engineering, pp. 800-813, Aug 1991.
  304.  
  305.  
  306.   [3] M. Luhn, "The automatic creation of literature abstracts," IBMJ. Res. Develop., pp. 159-165,
  307.       Apr 1958.
  308.  
  309.  
  310.   [4] J.  Palmer  and  Y.  Liang, "Indexing  and  clustering  of  software  requirements  specification,"
  311.       Information and Decision Technologies, vol. 18, pp. 283-299, 1992.
  312.  
  313.  
  314.   [5] F. Smadja, "Lexical co-occurrence: The missing link," J. Assoc, Literary andLinguistic Com-
  315.       puting, vol. 4, no. 3, 1989.
  316.  
  317.  
  318.   [6] M. Saeki, H. Horai, and H. Enomoto, "Software development process from natural language
  319.       specification," 11th International Conferenceon Software Engineering, pp. 64-73, 1989.
  320.  
  321.  
  322.   [7] R.  Abbott,  "Program  design  by  informal  english  description,"  Communication  of  ACM,
  323.       pp. 882-894, November 1983.
  324.  
  325.  
  326.   [8] C.  Rolland  and  C.  Proix, "A  natural  language  approach  to  requirement  engineering,"  4th
  327.       International CAiSE Conference, pp. 257-277, 1992.
  328.  
  329.  
  330.   [9] N. Maiden and A. Sutcliffe, "Exploitung reusable specifications through analogy," Communi-
  331.       cation of ACM, April 1992.
  332.  
  333.  
  334. [10]  K. Miriyala and M. Harandi, "The role of analogy in specification," 6th Annual Know ledge-
  335.       Based Software Engineering Conference, pp. 117-126, 1991.
  336.  
  337.  
  338.  
  339. 5      Biography
  340.  
  341.  
  342.  
  343. Sooyong Park is a research assistant and doctoral student in the School of Information Technology
  344. at George Mason University.  His research interests are software reuse, requirement engineering,and
  345. Object-Oriented domain analysis in real-time system. He has been researched in software reuse area
  346. for three years.
  347.  
  348.  
  349. Sooyong received a BS in computer science from the Sogang University in Seoul Korea, an MS in
  350. computer science from the Florida State University.
  351.  
  352.  
  353.  
  354.                                                           Park- 5
  355.